前两集做了两个产品。家庭日历暴露了方向问题，教育工具暴露了停机问题。但有一个更安静的问题一直在背景里：每次代码审查，所有审查者都说通过。
S1 建立了”做的人不评自己”的机制——AI 写完代码，由另一组独立 AI 审查。安全审查者不知道实现细节，测试审查者不看实现方案。每个审查者在独立上下文中工作，没有碍于面子放行这回事。
机制是对的。但两个产品做下来，一个模式浮出水面：安全审查者查安全，后端审查者查后端，前端审查者查前端——每个人在自己的车道上跑得很好，而且确实跑出了专业深度。当所有车道都绿灯的时候，谁来看路口？
全票通过的陷阱
做产品筛选工具的时候，OPC 跑了一次标准审查——安全、后端、前端三个审查者。工具的功能是去 Hacker News 挖痛点，生成产品探针（probe）。三个审查者看完代码，全部 PASS。
代码确实没问题。安全方面没有注入风险，后端逻辑正确，前端渲染正常。但我自己看了一眼输出——25 个探针，每一个都是 SQLite + argparse CLI 的变体。工具在忠实地执行同一个技术模板，25 次。
问题不在于 SQLite 或 argparse 本身有什么错——它们都是合理的技术选择。问题在于，当一个产品筛选器输出 25 条建议，而每条建议的技术架构、交付形式、目标用户群完全相同，这说明筛选器根本没有在做”筛选”这件事。它只是在用同一副模具批量冲压。真正有价值的产品探索应该覆盖不同的方向——有的探针该是 web app，有的该是 API 服务，有的该面向开发者，有的该面向终端消费者。25 条清一色的 CLI 工具，不是多样性，是重复。
这不是代码问题。从代码角度看，每个探针都是正确的。这是想象力的问题——工具卡在了训练数据里最常见的技术栈组合上，和 EP01 的日历网格是同一类失败。但安全审查者不会关心”为什么总用 SQLite”，后端审查者不会关心”探针的多样性够不够”。
全票通过是需要警惕的审查结果。 不是因为审查者错了——是因为他们可能一起错过了同一个盲区。每个人都完成了自己的职责，但没有人站在整体视角问一个问题：这个东西真的达到了目的吗？
这在人类团队里也会发生，但 AI 审查有一个放大因素。人类审查者在看代码的时候，可能顺便想到”等等，这个产品方向对吗？“——角色越界是人类审查的常见行为，有时候反而是好事，因为它打破了职责边界带来的盲区。AI 审查者不会越界。你让它审安全，它就严格审安全，不会顺便质疑产品方向；你让它审前端渲染，它就检查组件树和样式，不会质疑用户体验设计。职责隔离越干净，每个角色的专业深度越强，但盲区叠加的风险也越高。
第十人规则
以色列情报机构有一条制度规则：如果前九个分析师对某个情报判断达成共识，第十个分析师必须提出反面论证。不是因为第十人真的持不同意见，而是为了确保反面被认真考虑过。
据说这条规则源于 1973 年赎罪日战争的教训。战前情报机构收到了大量埃及即将进攻的信号，但分析师们形成了”埃及不会进攻”的共识——每个人都以为别人已经考虑过反面了，实际上没有人认真考虑过。
共识的危险不在于大家都错了。在于大家都以为别人已经检查过自己没检查的部分。而且审查者越多，这种虚假安全感越强——“前面已经有三个人 PASS 了，问题肯定被覆盖了。“这个推理在逻辑上站不住脚，因为三个审查者的覆盖范围可能高度重叠。十个人看同一类问题和一个人看十类问题，覆盖面完全不同。审查者的数量本应增加覆盖面，但如果所有人都在检查同一个维度，数量只是在加深同一条沟。
OPC 的多角色审查面对同样的结构性风险。每个审查者在独立上下文中工作——这是优势（防止互相影响），同时也是劣势（没有人看到全景）。当安全审查者说 PASS、后端说 PASS、前端说 PASS 时，编排者把三个 PASS 汇总成一个 PASS。但没有人做过的事是：把三个审查的盲区汇总起来，看看它们是否叠加成了一个更大的盲区。编排者的逻辑是”所有角色都 PASS = 整体 PASS”，但这个等式成立的前提是所有角色的审查范围加起来覆盖了整个问题空间——而实际上，它们之间存在大量的缝隙。
skeptic-owner：每次审查必须到场的第十人
我在 OPC 的角色系统里加了一个新角色：skeptic-owner（怀疑者）。
它和其他角色有两个根本区别。第一，标记为 mandatory: true——每一次审查都自动加入，编排者无法移除。其他角色可以根据任务类型选择性加入，skeptic-owner 不行。第二，它不看代码细节——它从产品负责人的视角审查整体方向。
skeptic-owner 关心三类问题：
方向质疑：这个实现真的解决了用户的问题吗？还是只解决了一个好解决的技术问题？这个区分之所以重要，是因为技术审查者天然倾向于评价”实现的质量”——代码干净吗？架构合理吗？性能够好吗？但实现质量再高，如果解决的不是用户真正痛的问题，产品价值就是零。EP01 的月视图日历就是一个实现质量极高但方向完全错误的例子。
覆盖盲区：测试覆盖了真实使用场景吗？还是只覆盖了容易测的主流程（happy path）？测试覆盖率数字好看不代表场景覆盖率高。AI 写测试时特别容易掉进这个陷阱——它会优先生成容易构造的测试用例，因为训练数据里最常见的就是 happy path 测试。真实用户的边缘场景往往需要复杂的上下文才能复现，而这些场景恰恰是 bug 最密集的地方。
共识挑战：当其他所有审查者都说 PASS，什么情况下这个 PASS 应该被质疑？这个问题本身就是在对抗群体确认偏误。在 AI 语境下，这种偏误不是源于社交压力，而是源于一个隐含的统计假设：“前面的角色都 PASS 了，所以这个代码大概率没问题。“但前面的角色只检查了各自负责的维度，它们的 PASS 不能叠加成一个全维度的 PASS。
上线后的第一次审查就验证了它的价值。还是那个产品筛选工具——前端、后端、安全三个审查者全部 PASS。skeptic-owner 的反馈是：
“工具生成的 25 个探针全部是 SQLite + argparse CLI 的变体。没有一个尝试了不同的技术栈、不同的交付形式、不同的目标用户群。这不是技术问题，这是想象力的失败。产品探索需要的是发散，而不是收敛。”
这条审查发现的严重度是建议级（suggestion）——不会触发门禁 FAIL。但它指向了一个所有技术审查者看不到的问题：技术审查者关心代码对不对，skeptic-owner 关心方向对不对。 代码可以完全正确地执行一个错误的方向——EP01 的日历网格就是这样。
devil-advocate（唱反调者）：共识形成时的自动注入
skeptic-owner 解决的是审查阶段的视角盲区。还有一类场景发生在讨论阶段——当多个智能体讨论方案时，如果太快达成共识。
OPC 的讨论节点会跑多轮。在自动模式下，第一轮各角色提出自己的观点，第二轮回应其他角色的观点。我加了一条规则：当讨论进入第二轮且所有角色趋于一致时，自动注入 devil-advocate 角色。
devil-advocate 的唯一职责是唱反调。不是为了否定——是为了确保反面论证存在。提示词里有一条硬规则：必须提出至少一个”如果这个方案失败了，最可能的失败原因是什么”的论证。
对不可逆决策——数据删除、公开 API 合约、破坏性迁移——devil-advocate 是强制参与的，不看共识程度。理由很直接：这些决策的纠错成本太高，即使团队有 99% 的把握也值得花额外的词元让一个角色认真想想剩下的 1%。这里的逻辑和工程中的安全裕度一样——桥梁设计不会说”我们算过了，这个载荷 99% 没问题，所以不加安全系数”。正是因为你有高置信度，那剩余的不确定性才更值得投入，因为一旦失败的代价远超额外审查的成本，不论概率多低都应该做对冲。
成本需要正面面对。每增加一个角色就增加一次独立的智能体调用——大约多花 30-60 秒和几千词元。skeptic-owner 是强制的，每次审查都多一个角色。devil-advocate 是条件触发的，只在共识形成时加入。两个角色合计让每次审查的成本大致增加了 15-25%（估算，取决于审查复杂度和词元用量）。
值得吗？在单人工具的语境下，这个成本增加换来的是：至少有一个角色在关心”方向对不对”，而不是只关心”代码对不对”。这笔账划算。但如果 OPC 被用在高频低风险的场景里——比如每天跑几十次的 lint 流程——skeptic-owner 的方向质疑就毫无意义了。角色的价值和审查的重要性成正比。
产品负责人（Owner）：人类不退场
16 个 AI 角色——安全审查者、后端、前端、测试、skeptic-owner、devil-advocate、PM、设计师、新用户代言人……阵容越来越大。但有一个角色不是 AI：Owner。
Owner 是我。
EP01 的教训已经讲得很清楚了：AI 执行计划，不生成计划。产品方向是 Owner 定的——日历要做智能推送流而不是月视图网格，教育工具需要多用户架构而不是单人工具。这些决策 AI 无法自主做出。
角色系统的每一层都是为了补偿 AI 的盲区：技术审查者看代码质量，skeptic-owner 看产品方向，devil-advocate 看反面论证。但所有这些角色的判断框架——什么是好的产品方向，什么样的技术取舍可接受——最终都来自 Owner 的设定。
Owner 不参与每一次审查。但 Owner 设定了每个角色的行为边界。这是间接控制：不是告诉每个角色该说什么，而是告诉它们该关心什么。为什么间接控制比直接控制更有效？因为直接控制不可扩展——你不可能预判每次审查会遇到什么具体情况，然后提前写好每个角色该怎么回应。但你可以设定一个判断框架：产品方向的评估标准是什么，什么级别的技术债务可接受，什么类型的决策必须有反面论证。角色拿着这个框架去应对具体情况，比 Owner 逐条审批高效得多——而且框架可以随产品阶段的变化动态调整。
角色分离能做什么、不能做什么
两个产品下来，角色系统确实改变了审查的质量。过去是”多个审查者看同一件事”——大家都在看代码有没有 bug。现在是”多个视角看不同的事”——有人看安全，有人看方向，有人专门唱反调。
但角色分离有一个它解决不了的问题：角色只加了更多的眼睛，没有加更多的牙齿。
skeptic-owner 可以提出”想象力的失败”，但这条审查发现是 suggestion 级别，不影响门禁。devil-advocate 可以指出”如果方案失败最可能的原因是 X”，但这个论证不会自动变成 FAIL 判定。角色系统改善了审查的广度和深度，但最终的强制机制——门禁——还是同一套 emoji 计数规则。
如果审查者一致认为没有 critical 问题，门禁就 PASS。如果 skeptic-owner 的方向质疑只标记为 suggestion，门禁也 PASS。角色系统让审查更全面了，但没有改变”什么条件下代码会被拦住”的规则。
换句话说，角色系统解决了”该看什么”的问题，但没有解决”看到问题之后该怎么办”的问题。一个审查者可以写出极其精准的方向质疑，但如果这个质疑在门禁规则里没有对应的强制拦截条件，它就只是一条有价值的建议——Owner 可以看到，也可以选择忽略。审查的视野拓宽了，但拦截的门槛没有随之调整。
这个局限在 EP08 会被正面面对：八集下来，门禁的 FAIL 路径从未被触发过。角色加了更多视角，但拦截从未发生——是角色太温和了，还是代码真的够好？
当所有人都同意的时候，不是推进的信号，是需要挑战的信号。第十人不一定是对的——但他确保了反面被认真考虑过。
硅基团队 S2: 在实战中进化工具链 ← S2E02: 40 个 Tick 推上线 | S2E04: 动手之前先看别人踩过的坑 →