硅基团队 S1E11: 翻车之后怎么办

两张封面图，9 个 reviewer 全 PASS。我打开一看——标题字号缩了 40%，头像小了一圈，视觉效果全丢。

Gate 全绿。产出物不及格。

这是我在 OPC 系统上遇到的第一次”安全网失效”——不是 AI 写的代码有 bug，而是检查代码的那套系统本身有 bug。EP03 讲过安全审计，EP07 讲过全 PASS 假象。本集的故事是：当 gate 真的没拦住，你怎么办？

答案不是回滚。是让系统从翻车里学到东西。三次翻车教会了我三条规则：声明必须有执行、静默失败必须变成显式阻断、评价产出物的人自己也要被评价。下面是具体发生了什么。

翻车一：Gate 全绿，封面图不及格

具体发生了什么：OPC 的 review flow 走完了完整流程，9 个 reviewer agent 都提交了评审，gate 判定 PASS。但人眼一看封面图就知道不对——跟上一版比，标题字号缩了 40%，头像从正常大小变成了缩略图级别，原本有的视觉效果（渐变、阴影）全消失了。

为什么 gate 没拦住？四个原因同时发生：

原因一：缺少怀疑者。 9 个 reviewer 里没有一个角色的职责是”跟上一版比有没有退步”。所有 reviewer 都在独立评价”这个封面好不好”，没有人在做”这个封面比上一版好还是差”。当你只看当前版本，一个”还行”的封面很容易过关。但一旦跟前版对比，40% 的字号缩减是肉眼可见的退步。

原因二：声明不等于执行。 我给 skeptic-owner（怀疑者角色，S0 ch03）的 role 文件里写了 mandatory: true，意思是每次 review 都必须包含这个角色。但 OPC 的 orchestrator 代码里根本没读这个字段——mandatory 写在 frontmatter 里，code 不认。声明了”必须参加”，实际上从来没参加过。

S0 讲过”声明 vs 执行”这个概念（ch02），但我当时举的例子是测试。现在它出现在了 review 系统里——而且后果更严重，因为 review 是整个质量保证链条的最后一环。

原因三：测试 helper 生成了空 eval。 单元测试里用来生成 mock eval 文件的 helper 函数，生成的文件缺少关键的评分字段。这意味着某些测试”通过”了，但其实它们测的是空数据——相当于考试交了白卷但阅卷老师给了满分。

原因四：Parser 正则有四种误判。 解析 reviewer 输出的正则表达式有四个 bug：

1. 箭头前缀（→）被错误匹配为列表项
2. 行检测顺序错误，严重度标记被跳过
3. 表格行被错误解析为评审内容
4. 判定行（verdict）被当作普通文本

四个独立的 bug，凑在一起，让 parser 在某些情况下完全无法正确提取 reviewer 的评分。

修复过程（7 小时，$45）：

1. 给 skeptic-owner 加了 code-level 强制执行——不是 frontmatter 声明，是 transition 代码里硬写的检查。如果 review 没有包含 skeptic-owner，transition 拒绝执行。
2. 修了测试 helper，确保生成的 eval 文件包含所有必需字段。
3. 逐个修了四个正则 bug。

声明 ≠ 执行：你在配置文件里写了 mandatory: true，你以为它生效了，实际上从来没生效过。

修完之后我回头看这次翻车，最关键的不是四个 bug——而是这个模式。这是整个 OPC 系统里最危险的一类 bug：你以为安全网在，其实不在。每一行没有对应代码执行的配置声明，都是一颗定时炸弹。

翻车二：Harness 自己崩了

第二次翻车更有讽刺意味——我用 OPC 来测 OPC 自己的代码。

opc-harness synthesize 是 OPC 的核心命令之一，负责把多个 reviewer 的评审结果汇总成一个 verdict。正常情况下它输出 JSON。但当 eval 目录是空的（没有 reviewer 提交评审），它不输出 JSON——它把错误信息写到 stderr，stdout 是空的。

Orchestrator（调度器）调用 synthesize 之后试图 JSON.parse(stdout)——空字符串不是合法 JSON，直接崩溃。但这个崩溃是静默的（silent failure）——orchestrator 没有 crash，它只是拿到了一个错误，然后继续执行下一步。相当于一个质量检查节点说了句”我检查不了”，然后被系统当成了”检查通过”。

怎么发现的：用 OPC 自己的 loop 跑 OPC 的集成测试时，一个 negative path test（专门测边界条件的测试用例）调用了空目录的 synthesize，暴露了这个问题。

这就是 dogfooding（自己用自己的产品）的价值——你用正常路径测不出来的 bug，在自己当用户时反而能碰到。EP07 讲过”全 PASS 假象”，那是 reviewer 质量问题。这次是更底层的——连 harness 自己的工具链都会静默失败。

修复：修了四个 error exit path，确保所有情况下 stdout 都输出合法 JSON。引入了一个新的 verdict 语义：BLOCKED——意思是”我无法评估”，区别于 FAIL（“我评估了，不及格”）和 PASS（“我评估了，合格”）。

BLOCKED 的引入解决了一个长期困扰的语义模糊：之前碰到无法评估的情况，系统要么崩溃，要么默认 PASS。现在有了第三个状态，orchestrator 可以做出正确的决策——遇到 BLOCKED 不是跳过，是暂停并上报。

新规则：CLI 协议不变量——stdout 永远是合法 JSON，诊断信息永远在 stderr。这个规则听起来简单，但在修复之前，有 4 个 exit path 违反了它。

翻车三：Eval 自己需要被 Eval

前两次翻车都有明确的故障事件。第三次不同——它是一个月里逐渐浮出水面的发现。

触发时刻：我在做 EP09 的封面图 review 时，随手抽查了几个 reviewer 的评分。其中一个 reviewer 给了封面 8.5/10——“色彩搭配和谐，排版清晰”。我打开封面一看：标题被裁进了安全区域外，在手机端根本看不完整。如果让我打分，最多 4/10。

这不是个例。我又抽查了几轮 review 的记录，发现多次出现类似的偏差：reviewer 给的分和人类判断差距不小，有的 reviewer 倾向于打高分（rubber stamp），有的会指出实际不存在的问题然后给低分。

但我没有任何机制来系统地衡量这种偏差有多大。我知道封面图不及格（因为我看了），但我不知道 reviewer 的评分整体有多不准。eval 系统评价产出物，但没有人评价 eval 系统。

解决方案：引入 external rubric（外部评分标准）。

Rubric 是一个结构化的评估框架：维度（dimension）→ 标准（criteria）→ 证据（evidence）三层结构。每个维度有明确的打分标准，reviewer 必须给出具体证据支撑评分。

关键设计决策：rubric 是”信息性旁路”（informational sidecar），不改变核心 eval 流程。核心的 synthesize 和 gate 逻辑不变——rubric 评分是附加信息，不是替代品。这意味着即使 rubric 有问题，最差情况是”多了一组可能不准确的参考数据”，不会影响现有的 gate 判定。

额外加了两个 meta-evaluation 机制：

1. 版本漂移检测（version drift detection）：在 flow-state 里记录 rubric 版本号。如果 rubric 改了，之前的评分不能跟新评分直接比较——防止 apples-to-oranges 的评分对比。
2. 收敛预警（convergence warning）：如果同一个产出物连续 3 轮评分方差 < 0.5，停止迭代。为什么是 0.5 和 3 轮？0.5 是经验阈值——在 1-10 的评分尺度上，方差 < 0.5 意味着 reviewer 之间的分歧已经小于半分，继续跑大概率不会出现新角度；3 轮是为了排除偶发收敛（2 轮可能巧合，3 轮更稳定）。这不是理论推导的数字，是跑了几十次 review loop 之后的实测经验值。

教训：当你的系统有一个 eval 层，问一个问题——谁在 eval 这个 eval？如果答案是”没有人”，你有一个不可观测的质量风险。meta-evaluation 不需要多复杂——一个 rubric sidecar 加版本追踪就够了。关键是让它存在。

三次翻车的共同模式

三次翻车看起来各不相同——一次是 reviewer 配置问题，一次是 CLI 协议问题，一次是 eval 框架问题。但它们有一个共同的底层模式：

错误路径（error path）是最大的盲区。

正常路径（happy path）测了无数次——reviewer 提交评审、synthesize 汇总、gate 判定。但 reviewer 缺席了怎么办？synthesize 的输入是空的怎么办？评分标准本身不靠谱怎么办？

这些问题不在”功能正确”的范畴里。功能是正确的——synthesize 在正常输入下工作正常。问题出在”功能之外”——边界条件、缺失状态、元层面的质量保证。

EP03 的安全审计是从外部视角审视系统。本集的三次翻车是从内部——系统在运行中暴露了自己的盲区。修复的方式不是打补丁，而是：

1. 声明 → 执行：把配置文件里的约束变成代码里的强制检查
2. 静默失败 → 显式阻断：把”无法判断”从”跳过”改成”暂停上报”
3. 评价产出物 → 也评价评价者：加一层 meta-evaluation 衡量 reviewer 自身的质量

S0 讲过”gate 是最后一道防线”（ch03）。现在我要补一句：gate 自己也会坏。 当 gate 坏了，你需要的不是更多的 gate——是检测 gate 是否正常工作的机制。这就是 meta-evaluation。

总账

值不值？换个角度算：如果不修翻车一，下次封面图出错还是 9 个 reviewer 全 PASS，你还是要人工看——那 reviewer 存在的意义是什么？如果不修翻车二，每次遇到空目录 harness 静默 PASS——所有依赖 harness 的下游判断都不可信。

修复不是回滚到上一个”好的版本”。回滚只解决症状。真正的修复是让系统从翻车中学到新规则。翻车之后的系统，比翻车之前更强——不是因为测了更多，是因为真的坏过。

验证系统能走多远

三次翻车暴露了一个更深的问题：谁来验证验证系统本身？

这就是 meta-evaluation——评估评估者。OPC 的应对方式是分层的：

第一层：机械规则自检。 60 条 rule 有对应的 450 个 assertion。Rule 本身是代码，assertion 验证代码行为。这一层是确定性的——通过就是通过，不通过就是不通过。

第二层：统计校准。 用 Cohen’s kappa 系数衡量 AI 评审的一致性。如果两个独立的 reviewer 对同一组代码的评价一致性低于 0.6，说明评审标准不够清晰——不是 reviewer 的问题，是 rubric 的问题。

第三层：dogfooding 循环。 用 OPC 做真实项目 → 暴露 OPC 的问题 → 用 OPC 修 OPC → 重复。本集的三次翻车就是 dogfooding 循环的产出。

没有第四层。 Meta-evaluation 不能无限递归。到了某个层次，你需要接受一个事实：系统不能完全验证自己。 这是哥德尔不完备定理的工程版本。你能做的是让验证层数足够多、覆盖面足够广，使得漏网的问题越来越少——但不是零。

S1 总账

十一集，一个月，大约 $2000 的 API 花费——包括所有的 loop run、review、test generation、dogfooding 循环。

$2000 买到了什么？不是一个完美的框架。翻车一到翻车三讲得很清楚——OPC 仍然有盲区。$2000 买到的是一套可重复的质量保证流程，和一组从实战中长出来的规则。

十一集串起来：

EP01：写代码 ≠ 做工程。 AI 是一个写代码极快的实习生，但它不理解「为什么需要测试」和「为什么需要审查」。OPC 的故事从这个矛盾开始。

EP02：一个人的工程团队。 四种角色（建造者、审查者、测试者、裁决者），14 个节点，做事的人不评判自己。

EP03：从能跑到能信。 安全审计 47 分到 90 分。60 条 enforcement rule。不让 AI 变好，让坏后果变小。

EP04：让框架长出骨骼。 从 hardcoded 到 capability contract。关节是扩展点，骨头中间不能挂肌肉。

EP05：睡觉的时候让 AI 替我干活。 Tick-based loop。AI 擅长增量打磨，不擅长创造性跳跃。一句人类反馈 > 8 小时 AI 工作。

EP06：$92 买了一个产品。 Loop 执行计划，不生成计划。方向在 loop 之外定。

EP07：当工具开始检查自己。 全 PASS = 最大的问题。你不能通过内省超越自己的盲点。Mechanical gate > LLM gate。

EP08：AI 跑了 8 小时后忘了自己是谁。 Context compaction 导致记忆丢失。文件系统 > AI 记忆。PreCompact / PostCompact 双 hook。

EP09：不让 AI 变好，让坏后果变小。 Gate 是底线不是来源。AI 能做 ordinal 判断，不能做 cardinal 判断。Gate 数数，不做判断。

EP10：人什么时候该介入。 125 小时 autonomous loop，五种人工介入信号。方向、context、protocol、环境、终止——autonomous ≠ unattended。

EP11（本集）：翻车之后怎么办。 Gate 自己也会坏。声明 ≠ 执行，静默失败 → 显式阻断，评价产出物 → 也评价评价者。

这不是「AI 替代人类」的故事。这是「一个人用 AI 做了以前需要一支团队做的事」的故事。区别在于：人始终在场。人定方向，人做判断，人守品味。AI 做执行，AI 做打磨，AI 做那些明确的、可检验的、重复性的工作。

这套流程让一个人能像一支团队那样工作。它不依赖 AI 的自觉——它用代码强制执行检查。它不假设 AI 会做正确的事——它假设 AI 会犯错，然后确保犯错的后果被控制住。

Season 2 会讲什么？OPC 之上的应用层——当你有了一个可靠的工程流水线之后，你能用它做什么。第一个故事：一句话需求，$92，23 小时，一个家庭 AI 日历。

硅基团队 S1: AI 能写代码，凭什么信它？ ← S1E10: 人什么时候该介入 | S2E01: 23 小时 $92 的家庭产品 →