思考手册：驾驭“生成—验证”回路
一份给开发者自学、内化的思考手册。 它不教你“用哪个功能”，而是教你“问题来了，脑子里第一步想什么、第二步想什么”。
0. 一句话内核
当你用 Claude Code 这类代理工具时，你要解决的核心问题，已经从“怎么让 AI 写出来”，变成了“我凭什么知道它写对了”。
所有的方法、所有的纪律，都是围绕这一个问题组织起来的。把这句话刻进去，后面所有内容都是它的展开。
一个有用的等式：
1
你的产出质量 ≈ 输入端上下文的质量 × 输出端验证的强度
AI 把“生产”（写代码、写文档、写测试）变快了一两个数量级，于是瓶颈整体迁移到了“验证”。最稀缺的能力，从“会写”变成了“会判断”。你对正确性的标准有多高、验证它的能力有多强，决定了这套工具是帮你造价值，还是帮你高速积累一座没人真正想清楚的债务山。
1. 第一性问题：这个问题的“正确”长什么样？
任何问题进来，脑子里第一个、也是不可压缩的问题永远是：
“做完之后，我凭什么判断它是对的？”
这个问题的答案，直接给你分流：
- 如果你答得出一个客观的、最好能机器检验的标准——这个函数对这组输入该输出什么、这个接口的契约是什么、重构后行为必须逐位不变——那这个问题是“AI 友好”的，你可以放心委托。
- 如果你的答案是“我读一遍，看着对就行”——这是警报。它说明要么问题你自己还没想清楚，要么它本质上难以验证。这两种情况下，AI 生成得越快，你积累的风险越大，因为你正在用“看起来对”悄悄替换“确实对”。
这一步是属于人的核心工作。AI 能把“实现”变快一百倍，但“想清楚到底要什么”这件事它替不了你——而且它会伪装成已经替你想清楚了。 一份看起来完整的方案、一段编译通过的代码，都会给你“已经想明白了”的错觉。要警惕这种廉价的完整感。
2. 给问题定位：两个轴，四种姿态
想清楚“正确长什么样”之后，用两个维度给问题定位。这个定位直接决定你该花多大力气委托、多大力气把关。
轴一 · 可验证性：正确与否，能不能被廉价、客观地检验？
- 高：纯逻辑、有明确输入输出、能写测试的东西。
- 低：UI 手感、“这个抽象合不合理”、架构选型这类需要品味和长期判断的东西。
轴二 · 可逆性 / 爆炸半径：做错了，撤销的代价多大？
- 低：一个局部重构，
git reset就回来了。 - 高：数据库迁移、对外 API 契约、权限鉴权、涉及钱的逻辑——错了代价极高，甚至不可逆。
两轴交叉，得到四种姿态：
| 低风险（易回滚） | 高风险（难回滚） | |
|---|---|---|
| 高可验证 | 放手委托：只看接口和测试结果，别浪费时间逐行读。（CRUD、工具函数、样板） | 委托但严审：让 AI 写，你逐行审 + 测试拉满，你为对错背书。（支付逻辑、迁移脚本） |
| 低可验证 | 快速试错：错了不疼，让 AI 多生成几版你挑。（调 UI、试探性原型） | AI 只当参谋：你亲自决策甚至亲自写。这是它最不可靠、你最不能赌的象限。（核心架构、关键抽象、安全模型） |
光是这个定位，就能帮你避开两个最常见的错误：在左上象限浪费精力死磕（过度把关），和在右下象限盲目信任（委托了不该委托的）。
3. 通用流程：问题来了，走这五步
定好位之后，任何具体问题都走同一条流水线。
第一步 · 分解到“每块都能产生一个验证信号”。 工作的最小单元不是“一个功能”，而是“最小的、能让我看到对错信号的改动”。一个大需求，拆成一串小改动，每一步做完都有东西告诉你“到这里还是绿的”。拆得越细，失控的可能越小——AI 跑偏时你最多损失一小步。
第二步 · 在生成之前，先放好验证锚点。 这是个顺序问题，极其关键。先定义“怎么算对”（写测试、定契约、明确不变量、准备一组 golden 输出），让目标处于“红”的状态，再让 AI 去把它跑绿。 反过来——先让它写实现、再补测试——它几乎一定会写出迎合自己实现的假测试，测了个寂寞。锚点必须在生成之前、独立于生成而存在。
第三步 · 按姿态选委托深度。 用第 2 节的四象限决定：全权委托 / 委托但严审 / 快速试错 / 我主导而 AI 打下手。
第四步 · 跑回路，但盯紧它的“自信”。 让 AI 小步实现、自己调用测试和编译器、读到反馈、自我修正——你要做的是把这个反馈闭环接通，而不是当人肉传话筒。 这里有一条必须刻进肌肉记忆的纪律：它说“完成了”“已修复”的时候，默认它没有。 代理系统性地高估自己。它的“完成”只是“我生成了看起来合理的东西”的同义词，不等于“通过了你的验证锚点”。那个“确实对了”的最终判断，永远不外包。
第五步 · 小步提交，控制爆炸半径。 每个可验证的小步过了就 commit，留 checkpoint。跑偏直接回滚，代价极低。把“一个大需求”拆成一串“每步都让测试保持绿色”的小改动，远比让它憋一个大 PR 出来再 review 靠谱。
4. 套到典型问题上：看“硬的地方”在哪
不同类型的问题，差别在于验证的难点落在哪个环节。识别出硬点，思考重心就有了。
改 Bug
最大的陷阱是 AI 爱“猜药方”：你描述个现象，它立刻甩给你一个看似合理的修复。别让它猜。 正确路径：强迫它先稳定复现 → 再定位根因 → 用一个能捕捉这个 bug 的失败测试把根因钉死 → 然后才允许动修复。 验证锚点 = 那个“原本失败、修完变绿、且只因为真正修对了才变绿”的测试。否则你收获的是一堆“看起来修好了”、根因还在的补丁。
重构
本质是“行为不变”，所以验证锚点天然就是“测试保持绿、行为完全一致”。 正确姿势：先用刻画测试（characterization test）把现有行为钉住，再重构。 有这层安全网，重构是 AI 的绝对甜区；没有这层网，它是危险区——因为行为有没有悄悄漂移，你肉眼根本看不出来。
做新功能
硬的地方在“它到底该干什么”——规格里的未知和歧义。AI 在“想清楚要什么”上帮助最小，在“把已经讲清楚的事做出来”上帮助最大。 所以人力前置投在规格上：接口长什么样、边界条件、错误怎么处理、影响哪些文件。规格一旦清晰，实现就近乎机械活，可以大胆委托。这一步在传统流程里叫设计评审，现在你能在几分钟内和 AI 一起完成。
架构 / 设计决策
低可验证 + 高风险，典型的右下象限。AI 的正确用法不是“替你决定”，而是当一个能驳你的参谋：让它列出几种方案的取舍、扮演反方挑你方案的毛病、提醒你没想到的边界。 但决策和后果由你扛——它没法为“三年后这个抽象变成屎山”负责。
读懂陌生代码库
纯上行、低风险（只读），放心让它当阅读向导、快速画地图。 唯一纪律：它的总结要对着真实代码抽查验证。 别全盘信它的转述，它会自信地编。
5. 元技能：知道什么时候跳出回路
这条最值钱，也最少人讲。
当你和 AI 来回三轮还在原地打转、不收敛时——99% 不是“再试一次”的问题，而是输入端坏了：
- 要么你的规格本身没讲清楚（那是你没想明白）；
- 要么缺关键上下文；
- 要么这事真的在它的能力分布之外。
这时正确动作是停下回路，回去重写规格、补上下文，或者干脆自己接管。继续在一个坏掉的输入上抽卡，只会浪费时间并积累垃圾。
更深一层，这整套方法论的内核是一种自我认知：
你要随时知道，此刻是“我在驾驭它”，还是“我在被它生成的东西牵着走、只是没察觉”。
前者是你拿着验证标准在指挥；后者是它快速产出、你疲于点头。区分这两种状态的能力，就是 AI 时代开发者最硬的护城河——它无关打字速度，只关乎你对正确性的标准有多高、以及你有没有真的在用这个标准做检验。
6. 一页速查
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
问题来了
│
├─ ① 正确长什么样？——能说出客观/可机检的标准吗？
│ 说不出 → 先停下想清楚，别急着让 AI 写
│
├─ ② 定位：可验证性 × 爆炸半径 → 四象限 → 定委托深度
│
├─ ③ 分解到“每块都有验证信号”的最小改动
│
├─ ④ 生成之前先放验证锚点（测试/契约/不变量）→ 红
│
├─ ⑤ 跑回路：AI 小步实现 + 自调测试/编译器 + 自我修正
│ 纪律：它说“完成了”，默认它没有 → 你亲自验到绿
│
├─ ⑥ 过了就 commit，留 checkpoint，跑偏即回滚
│
└─ ⚠ 三轮不收敛 → 不是再试一次，是输入端坏了 → 停下，修规格/补上下文/自己接管
7. 与传统软件工程的关系
这套东西不是对软件工程的否定，恰恰是它的灵魂换了个施力点。
规格、契约、测试先行、小步提交、代码评审——这些老纪律，以前是用来约束“人写代码”的，现在是用来约束“你驾驭一个又快又不可靠的生成器”的。方法没变，但你比以前更输不起松懈：因为生成速度快到足以让你在几个小时内，造出一座没人真正想清楚的债务山。
传统瀑布里那几个阶段（需求、设计、开发、测试、交付）并没有消失，而是被压缩进了你一个人、以小时甚至分钟计的循环里。你同时在扮演产品、开发、测试、评审，而把“打字”这一件事外包给了代理。
所以，真正的升级不是“学会用工具”，而是：把自己从一个写代码的人，升级成一个拿着正确性标准、驾驭生成回路的人。
📚 系列导航
这是「AI 时代程序员方法论」专题的第一篇 — 思考手册（为什么）。建议按顺序阅读：