用 AI 写出更好的代码，但慢一点

原文来源：Nolan Lawson — Using AI to write better code more slowly — 一位资深 Web 开发者分享如何用 AI Agent 做深度代码审查，而非批量产出糙代码。

很多人现在对 AI 编程的印象是这样的：写一段破烂代码，开一个巨大的 PR，不评审直接合并。能跑就行，越快越好。

但 Nolan Lawson——知名前端开发者、PouchDB 作者——在一篇 2026 年 5 月发表的文章里提出了完全相反的论点：AI 完全可以用来写出高质量的代码，只不过需要慢一点。

这个观点听起来有些反直觉，但它的内核值得每一个用 AI 写代码的人认真思考。

AI 编程的两种姿态

Lawson 观察到，当前 AI 编程领域存在两种截然不同的使用方式：

第一种是"糙快猛模式"：让 AI Agent 快速生成大量代码，不加审视地合并。这个模式的核心假设是——代码量等于生产力。

第二种是"精审模式"：把 AI 当作一个不知疲倦的审阅者，用它来反复检查代码质量、发现潜在问题，直到你完全理解每一行代码做了什么。

Lawson 明确站队第二种。

他说了一句很有意思的话：

「如果你觉得 AI 编程一无是处，这篇文章大概说服不了你。但如果你是一个让 Agent 写出数百行代码但自己几乎看不懂的开发者，我想请你慢下来，试试另一种节奏。」

Lawson 分享了他实际使用的一套工作流。核心思路是让多个不同的 AI 模型独立审查同一段代码，然后交叉验证结果。

他为此编写了一个 Claude Skill（灵感来自另一篇关于 Bug 发现的研究）。这个 Skill 做的事情概括起来就是：

同时运行 Claude 子 Agent、Codex 和 Cursor Bugbot，让它们各自找出当前 PR 中的 Bug，按 Critical / High / Medium / Low 分级。等三个模型都完成后，再由人类开发者汇总审查，排除误报，撰写最终报告。

这个方案的精髓在于：不同模型的训练数据和推理方式不同，各自看到的盲区也不同。当三个独立的模型都指向同一个问题，那基本可以确定是真的 Bug。

Lawson 还提到，他自己的 Bug 定义还包括了 KISS 和 DRY 原则检查、可访问 HTML/JSX 规范、SQL 查询索引正确性等非功能性标准。

Lawson 的经验是，这个工作流下误报率几乎为零，而且每次都能发现一堆 Bug。多到什么程度呢？"你会无聊到不想全部修完。"

他的典型处理流程是：

这个流程和李世石下围棋时的复盘逻辑有异曲同工之妙：最重要的不是下得多快，而是能不能在下棋的过程中发现自己思路上的系统性缺陷。

有趣的是，Lawson 承认用了这个工作流之后，他的开发速度并没有变快。甚至在审阅过程中常常会发现 PR 以外的既有 Bug，于是他就"跑偏"去写额外的单元测试和修复——

但这正是他想要的效果。

「在我的经验里，复杂架构的 happy path 其实没什么意思，更有价值的是理解它的 failure mode。在 AI 出现之前，我熟悉一个代码库的方式本来就是这样：搞清楚哪些假设是错的，然后动手修复它。」

这种"慢速 AI 编程"的理念和王垠多年前说的"慢即是快"不谋而合。如果你把时间跨度拉长到一年来看，一个 bug 更少、设计更清晰的代码库带来的维护速度提升，远超短期内多写的那几行代码。

Lawson 在文章最后给那些习惯了"Vibe Coding"（让 AI 海量生成代码然后祈祷它能用）的开发者提了几个具体建议：

如果你这样做了，你可能会发现自己消耗了大量 Token，最终发现方案本身就有问题——但这恰恰是值得的，因为你在错误酿成灾难之前就发现了它。

在 2026 年的 AI 编程热潮中，"写更多代码"几乎成了一种政治正确。各种 AI 编程工具的基准测试衡量的都是完成速度，而不是代码的长期质量。

Lawson 的文章提供了一个宝贵的反叙事：AI 最强大的能力也许不是加速产出，而是加速理解。

当你用 AI 来帮你理解一个库、审查一段代码、发现一个漏洞，而不是帮你跳过思考直接产出代码时，AI 的价值可能更大。它把你从"写代码的体力劳动"中解放出来，让你有时间去思考"应该写什么样的代码"——而这恰恰是编程中最有价值的部分。

这篇文章来自对 Nolan Lawson 博客文章的翻译和整理。我补充了一些个人观察和对比分析，欢迎在评论区讨论你在实际工作中如何使用 AI 编程工具。