用 AI 写出更好的代码，但速度要慢。
大多数人用 AI Coding 的方式是：prompt 进去，代码出来，commit，push，merge。速度飞快，PR 越来越大，但没人真正理解里面发生了什么。
工程师 Nolan Lawson 的文章，提出一个观点：LLM 完全可以用来写更高质量的代码，只是你得放弃"快"这个执念。

LLM 是天生的 bug 猎手，但判断力很差
把一个 Claude agent 扔进一个没有仔细审计的代码库，它能找出大量问题——SQL 查询缺索引、HTML 无障碍属性缺失、违反 DRY 原则的重复逻辑、潜在的竞态条件……
但问题在于：LLM 找出的 bug 里，假阳性率很高。它会把"风格不一致"报成"安全漏洞"，把"不影响功能的冗余代码"报成"高危问题"。

如果你直接相信它的输出，你会陷在无意义的修复里浪费大量时间。
解法：用多模型交叉验证，减少误报
Nolan 的方案是同时跑三个模型来 review 同一个 PR：
1）Claude sub-agent — Anthropic 模型，擅长理解上下文和代码意图
2）OpenAI Codex — 对常见编程模式和反模式有深入训练
3）Cursor Bugbot — 针对代码库结构做了优化
三个模型各自输出 bug 列表，按 critical / high / medium / low 分级。跑完之后，让主模型汇总三份报告，重点找"三个模型都提到的问题"——这类问题误报率极低，几乎可以直接处理。

本质上是用模型的多样性对冲单个模型的幻觉倾向。类似于多个独立评审员对同一份代码做审计，交集才算是真问题。

"慢 AI coding"的具体工作流是什么样的
不是生成完就 merge，而是：
1）写完一个功能后，先不急着提 PR，让 agent 跑一遍 KISS 原则检查（代码是不是最简单的实现方式？）
2）提 PR 之前，跑多模型 bug review，重点看交叉命中的问题
3）让 AI 解释这个 PR 的每一个关键决策——如果它解释不清楚，说明代码本身逻辑有问题
4）对 AI 生成的修复方案，要求它同时给出"这个改法可能引入什么新问题"
这套流程比"直接 merge"慢很多，但产出的代码质量和可维护性完全不在同一个层级。

"如果你用 agent 写了几百行你自己都看不懂的 PR，我建议你慢下来，问问 agent 这个 PR 是怎么工作的、它可能在哪里失败。"

原文：nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/

#HOW I AI# #程序员#