# 用 AI 把代码写得更慢，更好
> When I use this technique, I haven't necessarily seen my velocity go up.
我用这套流程之后，速度并没变快。
PouchDB 作者 Nolan Lawson 在 2026 年 5 月发的博客《Using AI to write better code more slowly》里，中段轻描淡写写下这一句。过去两年关于 AI 编程的几乎每一篇文章都在比拼速度——"10x 工程师"、"vibe coding 一晚上盖 SaaS"、"PR 数量翻倍"。Lawson 这一句直接把自己从那个赛道里抽出来，标题就是他的论点。
他的方法本身倒是简单。三句话的 Claude Skill：
> Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR ranked by critical/high/medium/low. Once they're all done, review their findings, do your own research to rule out false positives, and write a final report.
让 Claude 子代理、Codex、Cursor Bugbot 三方并行审同一个 PR，按严重等级出缺陷清单，互相筛掉幻觉。Skill 里加了 KISS（Keep It Simple, Stupid）、DRY（Don't Repeat Yourself）、可访问的 HTML/JSX、SQL 索引、注释别误导这几条他自己关心的"缺陷定义"。就这。
效果他描述是"永远能挖出多到让你审到无聊的真实问题，从严重的安全漏洞到中等的性能缺陷到轻微的注释错位，误报率几乎为零"。然后是那句关键的转折：但我并没变快。
为什么没变快？因为这套流程经常**反向勾出 PR 之前就有的历史缺陷**。本来要审查当前 PR，结果绕去写单元测试修旧坑——他把这件事称作"tangential side-quest"，旁支任务。"这是大多数人脑里 vibe coding = 10x 生产力的反面，但我觉得很爽。"
他对 AI 编程的整套定位也跟着不一样。slop cannon（垃圾炮）派把 AI 当吐代码机器，10x 派把 AI 当效率倍增器，Lawson 走的是第三条：**AI 当代码考古工具**。"在我搞清楚一个复杂架构时，最有意思的从来不是 happy path（顺利路径），是它的失效模式。LLM 之前我熟悉一个新代码库的方式就是看哪里假设崩了，然后动手修。"AI 把这个学习路径加速了——但加速的是学习，不是产出。
2026 年 5 月 26 日的 HN 上，这文章攒了 558 分、210 条评论。反对火力出奇集中——几乎只打两个点。
最尖锐的是 TACIXAT：这文章名不副实，作者讲的全是代码审查，跟真正难的事——agentic 编程时那些**微观架构决策**——没关系。"我边写边出决策，没法把整个规格（spec）提前完整写下来，agent 接不住。"这条戳得有道理，但有意思的是 Lawson 其实**默认接受了这个边界**。他根本没声称 AI 能替你写代码，他只主张 AI 能帮你找代码里的错。这是个比"AI 编程"窄得多的命题——窄到几乎成立。
第二个吵得凶的是投资回报率（ROI）。一群人质疑：用三个付费 LLM 当 linter（静态检查），为啥不用 ruff、eslint、sonarlint？答案是 LLM 能找出静态分析覆盖不到的东西——逻辑缺陷、注释和代码不一致、SQL 索引缺失。但代价是每次审查烧掉的 token 加上三份订阅。这套方法只对**已经付了 Claude + Cursor 两份订阅、且业务逻辑无法用静态分析覆盖**的工程师划算。换句话说，要复刻 Lawson 的工作流你得先承担他的成本结构。
剩下两百多条评论几乎全是各种实战补充。bottlepalm 写得很坦白：他在 LLM 审查循环里花的时间常常比手写还长，"一旦进入心流我写得飞快，根本不需要审查"。一位 25 年经验的程序员补充了被忽视的副作用：agentic coding 真正能让人**学到东西**——你被迫读 agent 的每一条建议，比单干时对自己的盲区敏感得多。这条跟 Lawson 自己说的"AI 把学习路径加速了"对得严丝合缝。
也有人指出这文章踩中了一个微妙的叙事转向：一年前还在喊"比人类快 10 倍"，现在变成"慢下来让 AI 帮你想清楚"。"这是不是在迎合反 AI 情绪？"——一句没人接得住但谁都看到了的吐槽。
但仔细看 Lawson 这套定位，他不是反 AI 也不是迎合反 AI。他是在 AI 编程的销售话术里**留下了一个稀有的诚实声明**：这东西帮到我了，但不是帮我变快，是帮我看见之前看不见的缺陷。在一个所有人都在比拼"我用 AI 之后多快"的语境里，肯说"我没变快但我变好了"需要一定的勇气。
文章的真正价值就在这。"better code more slowly" 不是修辞，是一个具体的工程师在公开的话语场里**站到主流叙事的反面**，并且解释自己为什么愿意这么站。他可能错了——TACIXAT 那条反驳也许更接近 AI 编程的核心难题——但他做的事是诚实，这本身就稀少。
🔗 [HN 原帖](https://news.ycombinator.com/item?id=48272984) · [文章原文](https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/)