一般来说，人们都认为LLM适合批量生成大量低质代码，但Nolan Lawson这篇文章反过来，介绍了一种用 AI 更慢地写出更好的代码的方法。

用 AI 更慢地写出更好的代码

2026 年 5 月 25 日，Nolan Lawson 发布于软件工程分类。标签：AI。4 条评论。

很多人似乎都相信，AI 编程的意义就是尽可能快地写出低质量代码：吐出勉强能过的垃圾代码，开出巨大的 PR，然后不经审查就合并。发布上线！

但问题是，LLM 非常灵活。你完全可以同样有效地用它们来更慢地写出高质量代码。

在我看来，这一点现在已经非常明显，我甚至差点因此不想写这篇文章。但似乎还是有不少人坚信 LLM 只适合当“垃圾代码发射器”，所以有必要提出相反的观点。

如果 Mythos 教会了我们什么，那就是：LLM agent 非常擅长发现 bug。只要把它们反复投向一个代码库，它们会找出多到让你几乎不知道该怎么处理的 bug。

和很多人一样，我也发现这不只适用于 Mythos 模型，其他模型也一样。有些模型可能更擅长发现隐蔽 bug，或者更少产生误报，但事实是，Anthropic 和 OpenAI 最新的公开模型已经足够好，可以在一个缺少细致审查的代码库里找出大量 bug。

问题不太在于找到 bug，而在于给它们排优先级，并验证它们是否真实存在。出于这个原因，我有一个 Claude skill，是根据这篇文章的核心洞见改出来的：你投入到 PR 审查里的不同模型越多，就越不容易得到幻觉结果或虚假的 bug。

这个 skill 大致会这样说：

> 运行一个 Claude 子 agent、Codex 和 Cursor Bugbot，找出这个 PR 中的 bug，并按 critical / high / medium / low 排级。等它们全部完成后，审查它们的发现，做你自己的研究来排除误报，然后写一份最终报告。

基本就是这样。你也可以加入自己对“bug”的定义。我的定义里包含一些约束，比如 KISS 和 DRY 原则、编写可访问的 HTML/JSX、SQL 查询要使用合适的索引，等等。

根据我的经验，这个 skill 总能在一个 PR 里找到大量 bug，而且误报率接近于零。它找到的 bug 多到如果你试图全部处理，可能会无聊到麻木。它们的范围很广：从严重的安全或正确性 bug，到比较普通的中等性能 bug，再到低级别的“这条注释有误导性”这类问题。

我通常的工作流程是：

1. 让 agent 修复所有 critical 和 high 问题，并由我指导正确的解决方案；然后重复，直到没有 critical 和 high。2. 跳过那些 high 或 medium 但收益不值得投入的问题，比如为了修复一个很窄的边界情况要写 100 行代码。3. 如果一个 PR 有太多 critical 问题，以至于我意识到整个方案方向都有问题，那就放弃这个 PR。

使用这种技术时，我并不一定感觉自己的开发速度变快了。事实上，审查过程经常会发现原本就存在的 bug，于是我会进入一个旁支任务：写单元测试，修复那些早在这个 PR 之前就存在的隐蔽缺陷。

这和大多数人想到 vibe coding 时脑中那种“10 倍生产力”的垃圾代码发射器式开发正好相反，但我觉得这很有满足感。

这是一种很好的方式：既能改善代码库整体健康状况，也能让你了解它那些奇怪的角落。以我的经验，复杂架构里的正常路径，远没有它的失败模式有意思。而在 LLM 出现之前，我通常也是这样熟悉一个代码库的：理解那些假设会在哪里失效，然后亲自动手把问题修好。

如果你是那种怀疑 AI 编程是否有任何价值的人，我不指望这篇文章能说服你。但如果你是那种会用 agent 写出几百行 PR、而自己都不太理解的人，我建议你放慢一点，试试这种更慢的“vibe coding”。

问问 agent：你的 PR 是怎么工作的？它可能在哪里失败？必要的话，让它写 Markdown 文档，并配上 Mermaid 图表。使用 Matt Pocock 的 `/grill-me` skill，直到你从头到尾理解整个 PR。

按原始代码行数来看，你可能不会更“有生产力”。你可能会消耗大量 token，最后只是发现自己整个计划从一开始就是错的。

但我发现，这种编程方式更像是我在 LLM 出现之前就已经努力实践的那种编程方式的增强版：谨慎、有方法、重视质量，专注于让事情对下一个写代码的人变得更好。

所以，深呼吸，慢下来，试试这种技术，看看你是否也会喜欢这种“更慢地写出更好代码”的方式。

AI创造营