通用方法 · 熟练
都合上了，可你已经读不懂自己的系统
不是它写得差，是你读得比它写得慢
它提交得越来越快，你却越来越没法逐条读懂 —— 这不是懒，是一种被起了名字的债：认知债（cognitive debt）。它和技术债不一样：技术债欠在代码里、看得见；认知债欠在你脑子里，等你发现自己不敢动那个模块的时候，已经攒了很多。这一页给的是把人重新放回环里的六个动作 —— 计划 → 批准 → 它写 → 你读 → 清理 → 上线，六个都不能省；但真正决定成败的是头尾两个：你要批的是「它打算怎么做」，不是代码；你要读的是「它真改了什么」，不是它的说明。
方法 · 一图看懂
1
把「计划」当产出物 — 你要批的不是代码，是它打算怎么做；计划里至少要说清改哪几个文件、动哪个接口、失败会怎样 —
2
批准之后才动手 — 一次只推进一步；⛔ 别让它一口气把三段做完再给你看 —
3
验收读代码不读说明 — 它说完成不等于完成；只看实际改动，对照计划逐条打勾 —
4
清理并写回 — 把这一轮踩到的坑写回规则文件，再进下一轮；⛔ 不写回下一轮必然重踩 —
原理 · 为什么有效
为什么这套顺序能防住认知债 —— 因为实现阶段的可靠性早就不是瓶颈了，瓶颈已经挪到计划与验证两端。现场实验里有人试过「只看计划、不读代码」，几周后崩得很惨，最后重置数周工作、重写五万行才拿到同样功能；反过来，纯靠逐行读代码也拦不住方向性错误 —— 一份实现完成之前，「这样做对不对」根本看不出来。把两端都占住，中间那段才可以放心交出去；只占一头，债就攒在另一头。还有一层量级原因：用 agent 的开发者每天产出的变更量是以前的 5~10 倍，逐行读的产能没有跟着涨 10 倍，硬读只会先崩在你自己身上。
适用场景
适合：已经在把整块功能交给 agent 的人 · 项目里有「不敢动」的模块 · 一份提交牵涉三个以上文件 · 团队里有人只在评审时第一次看到某段逻辑。
不适合：一次性脚本 · 用完即弃的原型 —— 那类东西没有维护窗口，逐条读反而是浪费；也不适合纯改错别字 / 调格式这类没有决策的改动。判据一句话：「三个月后还要不要有人读懂它？」要 ⇒ 走这六个动作；不要 ⇒ 直接让它做。
自测 · 5 问
上一轮它提交的东西，你能说出它改了哪几个文件吗
系统里那个最绕的分支，你还记得当初为什么这么写吗
最近三次它说「完成」，你逐条核过几次
有没有一处地方，已经从「不想动」变成了「不敢动」
上一次你真正读懂它写的东西，是几轮之前
怎么上手 · 验证步骤
第一周先只做一件事：把「批准」这一步真正用起来 —— 让它先交计划、你批了再动手。计划不合格就不批，让它重写；这一步不需要你懂代码，只需要你能问三句：改哪几处、动到什么边界、坏了怎么退。第二周再加「验收读代码」：不看它的总结，只看实际改动，对照计划打勾。第三周才加「写回」：把这两周重复出现的坑写成三五条规则，放进它每次都会读的那份文件里。
做完一轮后自问三句：① 这一轮我能说出「它改了什么」吗 ② 有哪一步我说不清但放过去了 ③ 这一轮的坑写回规则了吗 —— 三句都能答上，才算这一轮没欠债；第 ② 句答不上来，就把它单独拎出来补一次读。