我如何修复我的Steam游戏中的错误：从将错误复制粘贴到克劳德到编写自己的任务运行器

我是 Codex Mortis的开发者 的开发者，它是一款暗影亡灵发射器，完全基于自定义的ECS引擎，TypeScript编写，几乎完全由AI编写。 我在之前的帖子中写了开发过程的描述，但我想讨论的不是那么具体的东西：我的错误修复工作流程如何从“描述错误，祈求解决方案” evolves成我没想到要采取的步骤。

简单的版本（并且为什么它比预期的要好工作 )

开始时并没有多多少。 我碰到一个问题后，会打开克劳德代码，描述发生的事情，然后要求分析。 什么让我高兴的是整个架构是从一开始就由AI写成，并且在一个 md 文件中得到良好的文档。 Claude已经了解了因为它帮助写出了整个代码库的结构。

Opus在问题追踪方面表现得很出色——读取系统、减小来源。如果分析看起来不够合适，我会推回要求它再来一遍。如果一个解决方案不能起作用，我会再试两到三次。如果它仍然不能抓住它，我会回滚变化并开始新的通话。 无需在死胡同上挣扎时，就有一个新上下文窗口可能会看到它的不同部分。

关键原料并不是AI 本身， 良好的QA 本身。 清晰的 bug报告，复现步骤，写作如同读者不了解应用一样。 ickets中写得越好，修复速度越快。 这与与任何开发人员合作的原理相同。

延伸至并行终端

当我变得舒适后，我开始创建多个克劳德代码终端——每个终端都处理一个不同的bug。 在一个测试运行会遇到三点问题时，我会将每一点问题都交付给自己的会话，并且带有适当的背景、在结果飞给来时的分析中去看，并平行地修复这些问题。

这在两到三个终端上工作得很好。 在五个时，问题就变得混乱了。 我需要进行不断的按Alt快捷键切换，以便弄清楚哪个会话卡住了，哪个需要我的输入，哪一点已经完成了。 缓慢的瓶颈从“修复问题”转变为了“修复问题的过程管理”。

所以我建造了我自己的工具

我做了任何使用AI开发者会做的那些事——建造了一个解决方案。 它是个电子应用，一个任务运行器/仪表板，专门为我的工作流程打造。 它从我的bug tracker中拉取票，打开一个克劳德代码终端会话并且呈现所有活动服务单的单个视图——每一个服务单现在处于哪里，需要我关注什么，正在处理什么。

UI由我构建了全套的界面，并且每一个界面都与我当前的工作需求相匹配。 没有多余的功能，没有任何我需要视野中的功能。 我也从AI写出来。

今天，这基本上成了我的主要开发环境。 我会打开仪表板、看看我的票、放给克劳德代码处理它，然后集中我的精力在看待和做出决定而不是在终端窗中进出和等待这些终端完成。

过程

回看过后，发展的进展是：

手动模式

描述bug，向AI祈求解决方案，等待验证，重复上过程。

并行模式

与上述过程一样，但是同时多个终端使用，并由我手动管理。

自动模式

我自己构建的自定义工具来处理协调工作，而我则集中我的精力在做出判断和做出决定。

每步没有取代基础技能——写下好的bug报告、判断分析是否合理、知道何时回滚。 但它只是从过程中降低了阻力。 AI越来越擅长于修复了，我的bug报告越来越清晰，那么在阻力瓶颈变成管理噪音时，我也就自行了此了。

久而久之使用AI开发时，我学会了不仅仅使用它来建造它的产品，而是会使用它来建造它帮助我的工具。