用AI写更好的代码，但更慢

# 用 AI 更慢地写出更好的代码 来源：https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/ 很多人似乎坚信，AI 编码的意义在于以最快速度写出低质量的代码。大量输出勉强过关的“垃圾”，开出庞大的 PR，然后不经审查就合并。赶紧交付吧！ 但问题是，LLM 非常灵活。你可以同样有效地用它们**更慢地**写出**高质量的**代码。 这句话对我来说现在完全是显而易见的，我差点因为这个原因不想写这篇文章。但似乎有足够多的人相信 LLM 只能当“垃圾大炮”（https://x.com/i/status/2021617680525172840），所以值得提出相反的观点。 如果 **Mythos**（https://www.anthropic.com/research/glasswing-initial-update）教会了我们什么，那就是 LLM 代理**真的非常擅长**找 bug。让它们反复冲击同一个代码库，它们会发现数不清的 bug，让你几乎不知道怎么处理。 和**许多其他人**（https://xbow.com/blog/mythos-like-hacking-open-to-all）一样，我也发现这对非 Mythos 模型也成立 – 有些模型可能更擅长找微妙的 bug 或避免误报，但事实是，Anthropic 和 OpenAI 的最新公开模型已经足够好，能在未经审查的代码库中发现大量 bug。 问题与其说是**找到** bug，不如说是如何对它们进行优先级排序和确认。为此，我根据**这篇文章**（https://milvus.io/blog/ai-code-review-gets-better-when-models-debate-claude-vs-gemini-vs-codex-vs-qwen-vs-minimax.md）的核心洞见改编了一项 Claude 技能，其核心思想是：你用在 PR 审查上的模型越多样，就越不可能出现幻觉或虚假 bug。 这个技能大致是（转述）： > 运行一个 Claude 子代理、Codex 和 Cursor Bugbot 来找出这个 PR 中的 bug，按关键/高/中/低排序。等它们都完成后，审查它们的发现，自己做研究排除误报，然后写一份最终报告。 基本就是这样。如果你愿意，可以加入自己对“bug”的定义 – 我的定义包含了对**KISS**（https://en.wikipedia.org/wiki/KISS_principle）和**DRY**（https://en.wikipedia.org/wiki/Don%27t_repeat_yourself）原则的要求，编写无障碍 HTML/JSX，为 SQL 查询使用正确的索引等等。 根据我的经验，这个技能总能在 PR 中发现大量 bug，而且误报率接近零。它发现的 bug 多到如果你试图全部解决，会感到无聊透顶。从关键的安全性或正确性 bug，到更常见的中等性能 bug，再到低级的“这个注释误导人”之类的 bug，无所不包。 我的典型工作流程是： - 让一个代理修复所有关键和高优先级的 bug（在我的指导下给出合适的解法），然后重复直到没有关键/高优先级 bug。 - 跳过那些不值得花力气的中/低优先级 bug（例如，为了一个狭窄的边缘情况写 100 行代码）。 - 如果 PR 有太多关键问题，以至于我觉得整个方向都错了，就放弃这个 PR。 当我使用这种技术时，并没有明显看到我的速度提升。相反，审查过程经常发现**已有的** bug，所以我最后会陷入一个无关的支线任务：写单元测试，修复早就存在的细微缺陷。这与大多数人想到“氛围编码”（vibe coding）时想象的那种“10 倍生产力”的“垃圾大炮”式开发截然相反，但我觉得很满意。 这是改善代码库整体健康状况的好方法，同时也能让你了解代码库中一些奇怪的角落。根据我的经验，复杂架构的快乐路径远不如它的失败模式有趣。而在 LLM 出现之前，这通常也是我熟悉代码库的方式：理解假设在哪些地方失效，然后动手修复。 如果你是那种对 AI 编码**任何事**都持怀疑态度的人，那么我怀疑这篇文章无法说服你。但如果你是一个用代理写出数百行 PR 却自己都不太理解的开发者，我邀请你慢下来，试试这种更慢的“氛围编码”风格。让代理解释你的 PR 是如何工作的，以及它可能如何失败。如果有必要，让它用 **Mermaid 图表**（https://mermaid.ai/open-source）写 Markdown 文档。使用 **Matt Pocock** 的 `/grill-me`（https://www.aihero.dev/my-grill-me-skill-has-gone-viral）技能，直到你完全理解整个 PR。 按原始代码行数计算，你可能不会更“高效”。你可能为了发现整个计划从一开始就是错的而消耗大量 token。但我发现这种编码风格更像是我在 LLM 出现之前就已经在尝试的编程方式的超级增强版：细致、有条理、追求质量、专注于让下一个编码者更容易。 所以深呼吸，慢下来，试试这种技术，看看你是不是会更享受**更慢地写出更好的代码**。