内容
很多人似乎都坚信，AI 编程的目的就是尽可能快地写出低质量代码。拼命吐出勉强能用的劣质产物，开出巨大的 PR，然后不经审查就合并。直接上线！
但问题在于，大语言模型（LLM）非常灵活。你完全也可以用它们以更慢的方式，同样有效地编写高质量代码。
到了现在，这个说法对我来说已经显而易见了，我几乎都不太想写这篇文章了。但似乎确实有足够多的人坚信，LLM 只适合当 劣质代码炮，所以有必要专门说说相反的观点。
如果 Mythos 教会了我们什么，那就是 LLM 代理非常擅长发现漏洞。只要把它们反复扔进一个代码库，它们就会找出多到让你几乎不知道该怎么处理的 bug。
和很多人一样，我也发现这对非 Mythos 模型同样成立——有些模型在发现微妙 bug 或避免误报方面可能更强，但事实是，Anthropic 和 OpenAI 最新的公开模型已经足够在未经审查的代码库中找出大量 bug 了。
问题与其说在于发现 bug，不如说在于对它们进行优先级排序和验证。出于这个原因，我有一个 Claude 技能，它是根据这篇文章的核心洞见改写而来：你把参与 PR 审查的模型数量和种类越多，就越不容易出现幻觉或错误的 bug。
这个技能大致是这么说的（意译）：
运行一个 Claude 子代理、Codex 和 Cursor Bugbot，按严重/高/中/低等级查找这个 PR 中的 bug。等它们都完成后，检查它们的发现，自己再做一轮研究以排除误报，并写出最终报告。
基本就是这样。你也可以按自己的需要给“bug”下定义——我这里的定义包含对 KISS 和 DRY 原则的要求、编写可访问的 HTML/JSX、为 SQL 查询使用正确的索引等等。
以我的经验，这个技能总能在一个 PR 里找出大量 bug，而且误报率接近于零。它能找出的 bug 多到让你如果想全都处理掉，最后只会无聊到发懵。从严重的安全或正确性 bug，到更常见的中等级性能 bug，再到低级别的“这个注释有误导性”之类的问题，应有尽有。
我通常的工作流程是：
-
让一个代理把所有严重和高优先级问题修掉（在我的指导下采用正确方案），然后重复，直到没有严重/高优先级问题
-
跳过那些投入产出比不高的高/中优先级问题（例如要写 100 行代码才能修掉一个很窄的边界情况）
-
如果这个 PR 的严重问题多到让我意识到整个方案都不对，就直接放弃这个 PR
当我使用这种方法时，我未必感觉自己的速度变快了。事实上，审查过程往往会发现原本就存在的 bug，于是我最后常常会跑去做一些旁支任务：写单元测试、修复那些早于这个 PR 就存在的微妙缺陷。这和大多数人想到“氛围编程”时脑海里那种“10 倍生产力”的劣质代码炮式开发完全相反，但我觉得它非常令人满足。
这是一种改善整个代码库健康状况的好方法，同时也能让你了解它那些不寻常的角落。以我的经验，复杂架构的顺利路径远没有它的失败模式有意思。而在 LLM 出现之前，我通常也是这样熟悉一个代码库的：理解哪些假设会失效，然后亲自动手去修。
如果你属于那种怀疑 AI 编程任何方面都没什么用的人，我怀疑这篇文章说服不了你。但如果你是那种会用代理来写自己都几乎看不懂的几百行 PR 的开发者，我建议你稍微放慢一点，试试这种更慢的“氛围编程”方式。让代理解释你的 PR 是怎么工作的，以及它可能会在哪些地方失败。必要时让它写带有 Mermaid 图表 的 Markdown 文档。用 Matt Pocock 的 /grill-me 技能，直到你从头到尾彻底理解整个 PR。
从原始代码行数来看，你也许不会更“高产”。你可能会消耗大量 token，最后才发现你的整个方案从一开始就是错的。但我觉得，这种编程方式，其实是我在 LLM 出现之前就一直想做的那种编程的一个更强力版本：谨慎、系统、执着于质量，专注于让事情对下一位编码者变得更好。
所以，深吸一口气，慢下来，试试这个方法，看看你会不会喜欢用更慢的速度写出更好的代码。