验证责任转移

上一章讲了 spec 从工作台变成载体。同一条物理事实（执行时人不在每个子空间的现场）对验证也起作用，方向不同。载体解决的是意图怎么在人不在场时被传输。验证解决的是产出怎么在人不在场时被判定可信。这一章从后一个问题开始。

卷一验证的最后一道是人

卷一的验证是三层结构。测试查代码行为是否符合 spec 规定的行为契约。Code review 查代码意图是否忠实于 spec 里的意图。前两层都会漏。漏的地方靠人对项目的理解补位。

这个结构里最关键的是人。测试和 review 可以自动化到相当程度，最后拿主意的是人。整体的可信度从人这一层来。前两层做得相对宽松没问题，因为最后一层能补位。

Ryan 的实践就是这个结构。他写测试覆盖 feature spec 里的每一条 Gherkin 场景，跑 code review 查 Agent 输出的 pattern，最后自己看一遍产出。他有一句话说得很直白："我看了几行就知道 Agent 的输出对不对，直觉先响。"这里的直觉就是人在第三层的补位。测试和 review 抓不到的地方，人凭对项目的整体理解一眼看出问题。

卷二的带宽约束

卷一时你一天可能 review 三四段代码。每段代码几百行以内。你从头到尾扫一遍，能过一遍眼，能捕捉到直觉响起的地方。这个节奏跟你的 review 速度匹配。

卷二不一样。五个 Agent 并行，每个 Agent 在自己的子空间里跑。你同时打开的窗口可能就有五个。每个 Agent 每小时产出几百行代码。加起来一天几千行。你就算全时段守着，也只能扫过其中一小部分。

带宽是硬约束。看不完等于漏检。装作看过等于放过。这跟你有多勤奋无关。人在物理层面追不上产出速度。

卷二的盲区约束

带宽是一个问题。盲区是另一个独立的问题，往往同时出现。

卷一时项目通常在你熟悉的领域里。你做过多年 Web 后端，项目也是一个 Web 应用。看到 API 端点的实现、看到数据库查询的写法、看到错误处理的策略，你凭业务理解就能判断代码对不对。

卷二时项目常常跨出你熟悉的领域。做后端出身的人接手一个 CV 算法项目，看代码符号都认识，看含义就发懵。数据流是不是对，损失函数用得合不合理，超参数选择的理由是什么，都在他的知识范围外。看得懂符号看不懂含义。

这是盲区。盲区里人的判定率接近零。就算你把每一行代码都扫一遍，你也判断不出来产出到底对不对。让人在这种情况下做兜底等于放过。

胥克谦对这个现象有一句直接的描述。他做过十几年教育行业的产品，判定率能到六七成。他后来做开发工具项目，同一个人换了行业，他的原话："里边百分之九十九都是盲区。"跨领域时判定率骤降是任何一个人换行业都会遇到的物理现实。

两个约束常同时出现

带宽和盲区看起来独立，实际相关。大规模项目常常覆盖多个专业面。你熟悉其中一两个，其他都是盲区。同时产出速度又超过你的 review 速度。两个约束不独立。

一个人做一个 SaaS 后端项目，几万行代码，多数在他的领域内。这时候可能带宽是主要约束，盲区偶尔出现。项目规模再扩，需要 AI 模块、数据管道、分布式基础设施。他的领域覆盖降到不到一半。这时候带宽和盲区同时起作用。他既盯不过来也判定不了。

任意一个约束成立，卷一模式都失效。两个都成立时更加成立。