用 OPC 审查一个产品。启动 full-stack flow，14 道关卡逐一检查，看它是不是 ready for 100 个用户。
结果：所有 gate 都 PASS。
所有 gate 都 PASS——这才是最大的问题。因为如果检查工具足够聪明来理解代码，它也足够聪明来合理化代码的缺陷。
你可能觉得这是好事。但我的第一反应是——如果全 PASS，要么是产品完美，要么是检查有问题。 世界上不存在完美的产品。
果然，审查过程中，OPC 自己暴露的问题比被审查的产品还多。这是一个 meta-lesson：工具只有在被密集使用时才会暴露结构性缺陷。
剥洋葱
问题不是一次性暴露的。它像洋葱一样，一层一层剥开来。
第一层：Loop 不知道什么时候该停。 OPC loop 跑完所有 unit，宣布 pipeline_complete——但 loop harness 不检查这个状态，继续空转。一个 session 里空转了 50 多个 tick，每个 tick 都在做「检查下一个 unit」然后发现没有。
这就像一个工人干完了所有的活，但没人告诉他「你可以下班了」。他就站在那里，每隔 30 分钟看一下任务列表，发现是空的，然后继续等。50 多次。
修法很简单：在 next-tick 输出里加一个 shouldTerminate: true 字段，loop 在每次 tick 开始前检查它。这是 mechanical gate 的经典案例——不能指望 AI 自己「意识到」该停了。
第二层：test-execute 是摆设。 Flow 里有一个 test-execute 节点，设计意图是「test-design 设计测试用例 → test-execute 执行它们」。但实际跑的时候，orchestrator 把 test-execute 当成了另一个 review 节点——它「review」了测试计划，写了一段「测试通过了」的文字。但它没有跑过任何一行命令。
这是「aspirational theater」——声称有 enforcement 但实际零 mechanical validation。就像一个安检门，看起来很严肃，但里面没有装传感器。所有人都走过去了，灯永远是绿的。
第三层：Gate 的判决不可靠。 有时候 3 个 reviewer 都说 FAIL，但 Gate 判 PASS——因为最后一个 reviewer 在评价末尾加了一句「整体可以接受」，AI 被这句话锚定了。有时候所有 finding 都是 minor，但 Gate 判 ITERATE——过度保守。
根因：verdict 判定依赖 AI 对 findings 的「综合判断」，没有机械规则。当 findings 里有混合信号时，AI 会被最后一句话的语气左右。EP02 里我们把 Gate 设计为机械计数逻辑。但审计中发现，某些 gate 节点的最终判定实际仍依赖 LLM 的综合判断——设计意图和实现之间出现了漂移。这恰恰是 self-audit 的价值所在。
修法：数数。N 个 critical finding = 强制 FAIL。0 critical + ≤2 major = PASS。其他情况 = ITERATE。AI 只负责生成 findings，verdict 由规则引擎决定。把需要客观判断的事情从 AI 手里拿走。
第四层：所有测试都是 happy path。 108 个测试，每一个都在验证「功能在正常情况下能工作」。没有一个测试在验证「功能在异常情况下会正确失败」。如果所有测试都是「输入正确数据 → 期望正确结果」，那测试只能告诉你「在理想世界里代码是对的」。
真正有价值的测试是 negative path：输入错误数据 → 期望正确的错误处理。网络断了 → 期望合理的 fallback。数据库满了 → 期望 graceful degradation。这些才是会在凌晨三点叫醒你的场景。
吃自己的狗粮
这次经历有一个更深层的教训。
审查过程中，OPC 自身的 3 个结构性 gap 被暴露。其中 1 个当场修复（loop termination guard），2 个记录为 tech debt（test-execute enforcement、gate verdict reliability）。
然后我用 OPC 来修 OPC。4 个 fix unit，8 个 tick。用工具审查产品 → 暴露工具自身的 gap → 修工具 → 再审查。这个循环的收敛速度比任何 unit test 都快。
这就是 dogfooding 的极端形式。不是「我们自己也用这个产品」，而是「我们用这个产品来修这个产品」。
但 dogfooding 也有一个认知边界：你不能通过内省超越自己的盲点。 那 108 个 happy path 测试就是证据——OPC 能检查出被审查产品的问题，但检查不出自己的 happy path 偏见。因为偏见就在检查逻辑本身的结构里。
这就像照镜子。镜子能让你看到脸上的脏污，但不能让你看到镜子上的裂痕。
你需要另一面镜子来看到裂痕。或者，你需要一个不用镜子的人走过来直接告诉你。
在 OPC 的世界里，这个「不用镜子的人」就是机械规则。机械规则不通过 AI 的判断来工作——它数数、比对、检查格式。它不理解代码在做什么，但它知道代码有没有通过检查。
这就是为什么 OPC 的核心信条是「mechanical gate > LLM gate」。任何需要可靠判定的地方——termination、verdict、scope check——必须有硬编码规则。不是因为 AI 不够聪明，而是因为聪明本身就是偏见的来源。
硅基团队 S1: AI 能写代码，凭什么信它？ ← S1E06: $92 买了一个产品 | S1E08: AI 跑了 8 小时后忘了自己是谁 →