人类逐行阅读 diff 的传统 review 已经失效。注意力应该放在链条的两端—— 在源头把意图讲清楚，在终点把证据看明白，中间的代码让 agent 们自己去吵。
2023 年聊测试时，AI 编程还处在 Kite / Tabnine 时代，Copilot 只是刚起步的补全工具。当时写下的判断，今天几乎全部应验。
“也许在未来，AI 才是主驾，而人类开发者则变成副驾。如果那一天到来，编程就不再是程序员所需要掌握的核心技能了。”
—— 王巍《开发的杂谈：测试》· 2023-04
业界至少需要 五年，才能把人类从编程任务中解放出来。
Opus 4.5、GPT-5.2-Codex 相继发布，agent coding 时代提前到来。
软件开发已经不是同一个工种；过去的技能与方法正在过时，老兵和新手都在探索与挣扎。
整篇文章就是在回答这三个问题，一个比一个更具体、更落地。
agent 不知疲倦地实际验证、几分钟理解全仓库——人类 review AI 代码主观不必要、客观不可能，但 review 的形式仍有价值。
信息链变长，人能发挥作用的只有两头：上浮到需求与规格（spec），下沉到最终产物（证据）；中间代码交给 agent 互审。
docs-ai 目录：spec 先行、留档决策；Review Loop workflow：两个 agent（不同模型）循环互审，人只读最终结论。
在讨论 AI 代码之前，得先弄清软件工程里 review 本来是干什么的——其实就两条。
在合并进主干、提交 QA 之前把问题解决掉。但想抓全是不可能的：reviewer 的时间、精力与信念有限，diff 给不出全貌，总有错过的细节和 edge case。
好听的说法是“维护可读性、增进团队理解、保持对代码库的掌控”；实际价值是原开发者跑路后有人能顶上——review 过代码的人总比从零开始的人可靠。
企业现实：通过 review 抓住明显问题，其余交给 QA，是更直接、更经济的做法。
个人开发者：两条理由同样成立——对 bug 负责、保持对自己代码库的理解；自我审核仍是开发者的美德。
人类 review 的两个传统目标，在 agent 面前都站不住了。
只要有电就能持续工作，动辄连续十几甚至几十小时。前提被摧毁后，正确做法是建立验收标准、把 E2E 测试提前并强制化，把验证交给 agent——review 下沉到最终产物，在实际验证中找缺陷。
几分钟甚至数十秒理解代码库，自主调用工具完成结构化理解已是基本能力。agent 真正缺的是人类的决策过程——代码为什么发展到现在的样子。所以要把 review 上浮到需求和规格（spec）。
结论：人类去 review AI 产出的代码——主观上已经不必要（只剩背锅），考虑 AI 的产出速度，客观上也变得不可能（几千行 diff 看不过来）。逐行读 diff 的老式 review 已经没有意义，但 review 这个动作本身，依然值得保留。
信息每传一手，就失真一分（semantic drift）。AI 开发的信息链比传统开发长得多——中间要是完全没人核查，跑偏只是时间问题。
review 上浮到需求和规格，逐字逐句认真审。
review 下沉到最终产物，直接去审核证据。
代码本身不必逐行审，交给 agent 之间互相审核。
越靠近源头，修正代价越小。spec 里的一句含糊，到代码里就是一整套错误抽象——而且 agent 会把它实现得接近完美：除了整个是错的以外，简直无懈可击。
好的 spec 通常只有一两百行自然语言——人类完全能应付、也应该花心思琢磨的规模。
agent 先调查代码库、起草方案 → 人类挑毛病、提问题 → 往返几轮定稿。没把握时交给不同模型交叉检查（盲区通常不一样）。
这个阶段多花一小时，往往省下后面一整天的返工。定稿的 spec 要留档——它记录了 agent 最缺乏的决策信息。
“不要相信 agent 的结论，只相信 agent 给出的证据。”
Agent 喜欢发大本营战报：“已完成所有修改，测试全部通过”——其中多少测试有意义、多少靠猜、多少是改了测试去迁就实现，光看这句话完全判断不了。
单测 / 集成 / E2E 能自动跑的都让 agent 自己跑，给出真实的命令与输出。修 bug 必须 TDD：先写红测看失败，再修复看通过——先红后绿本身就是证据。
agent 已能驱动模拟器和浏览器，把关键界面截图、操作录屏作为交付的一部分。一张截图胜过一万句“我已确认 UI 正常”。
要求报告中明确区分“实际运行观察到的”与“推断或假设”，没有验证的部分也要老实写出来。
人类最后的动作：对照 spec 里的验收标准检查证据；有空最好亲自上手用一用最终产物——这才是人类 review 时间最好的去处。
按人类的标准逐行审 AI 代码既不可能也没必要——这部分本来就在 agent 的能力区内。
不用逐行读代码，看审核的结论就够了——关注结论、被拒绝的意见和搁置的疑点。
和 spec 交叉检查同理：不同模型的盲区通常不一样，互相审更容易暴露单模型的系统性问题。
Prowl 仓库里的 docs-ai/ 目录，按编号组织设计记录——每个重要功能或非平凡修复一个文件夹。
# 每个重要功能一个编号目录 docs-ai/NNN-<slug>/ ├── 000-plan.md # 实现前的计划（RFC 式 spec） │ # 背景 / 目标与非目标 / 设计方案 │ # 备选方案与决策 ← 最看重 ├── 001-action.md # 实际做了什么（对照代码验证） │ # 与计划不一致的地方（坦白） │ # 尚未验证的疑问（坦白） └── 002-<topic>.md # 增补 / 修正 / 后续切片 # 方向根本变化 → 另开新编号 # 旧计划标记 Superseded
流程：几句话描述需求 → agent 调查代码库起草 plan → 逐字读完、争论、修改直到满意 → 开始实现。这是作者投入注意力最多的环节，占整个开发流程八成以上。
① 不是每个任务都写——小修小补不写，否则目录变工作日志、噪声没人看；
② 文档里每个文件路径必须真实存在，不能验证的内容只能进 Open questions；
③ 没实际跑过的构建和测试，不能写成已通过。
效果：已积累 70+ 条目。新 agent 碰到奇怪的代码，读对应条目即知来龙去脉，不用去 git 历史里考古。
Prowl 内置的多 agent workflow：main 负责实现，reviewer 独立审核，循环直到干净。
改动范围、对应计划、已做过的验证
问题带编号 / 严重度 / 位置 / 触发条件；给出 clean 或 issues
真实问题：先写失败的回归测试再修复；不认同：用证据拒绝
复核遗留问题，同时把完整 diff 当第一次看到重新审
main 写总结：已解决 / 未解决 / 修了未复审
首轮 clean 往往只是看得不够仔细，不直接结束。
reviewer 区分事实与推测、列已查 / 未查文件；main 拒绝要给理由，被拒问题不算 clean。
防止 reviewer 注意力锚定在上一轮报告上，漏掉新问题。
达轮数上限时，总结必须分清三类状态，不能含糊报捷。
人的位置：两个 agent 跑在真实终端分屏里，可随时旁观介入；人基本只读最后那份总结，以及被拒绝和搁置的意见。workflow 用 YAML 编排，可自定义——spec 交叉检查、强制截图、多 reviewer 分工（正确性 / 性能 / 安全性）都能配出来。
需要——但肯定不是逐行阅读 diff 的那种传统审核。人类的注意力应该放在两头：
“至于在企业开发中背锅这件事，大概还是逃不掉的，但至少在这套流程下，我能把这口锅背得明明白白。”