第一次觉得 OPC 像一支真正的团队，是在一次 code review 里。
我让四个 AI reviewer 分别审查同一个项目。PM 说「功能达标，但用户等待时没有任何反馈——loading 状态缺失」。安全专家说「路径穿越漏洞没防住——黑客可以通过主题文件路径偷看系统目录下的文件」。工程师说「输入校验不够严——有些非法输入没被挡住」。Skeptic 说「PM 说的 loading 缺失——你确定不是故意的？代码里有相关注释。」
四份报告，零重叠，有一份还在质疑另一份的结论。
这不是「让 AI 帮忙看看」。这是一个有角色分工、有证据要求、有最终裁决的审查流程。它之所以能做到这一点，靠的不是更强的模型，而是一条设计过的流水线。
做菜的不能试菜
厨房里有一条铁律：做菜的厨师不能当最终试菜的人。
不是因为厨师的舌头不好使。而是因为他从切第一刀开始就在调整——尝了十几次之后，他的味觉已经被自己的调整过程校准过了。他觉得「刚刚好」的味道，对第一次吃的人来说可能太咸、太淡、或者不对味。
这个道理在写代码的时候完全一样。你写了一个函数，写了配套的测试，测试通过了，你觉得完美。但你测试的是你以为代码应该做的事——如果你对需求的理解就是错的，你的测试也会是错的，而且它们会完美地通过。
这就是为什么上一集里 OPC 自己的测试全是假的——做事的人评判了自己，结果测试永远是绿的。
OPC 的第一原则就是从这个教训来的：做事的人不评判自己。 写代码的 AI 不能评审自己写的代码。设计测试的 AI 不能执行自己设计的测试。做出判断的 AI 不能裁决自己的判断。
这不是哲学。这是架构。
四种角色
OPC 把一支工程团队拆成了四种角色。不是因为四个好听，而是因为这是确保质量所需的最小分工。
建造者（Builder）就像工厂里拿到图纸的工人——不需要自己设计图纸，但要把图纸精确地变成产品。它收到的是明确的验收标准（acceptance criteria，提前写好的「做到这些算合格」的清单）——不是「做个网站」，而是「用户可以用邮箱登录，session 刷新后不丢失，logout 后 session 清除」。每条标准都有对应的验证方式。
审查者（Reviewer）就像论文的匿名审稿人——每个审稿人独立打分，互不通气。OPC 的审查者不是一个人，而是多个角色独立审查，互相看不到对方的报告。其中一个是固定的 Skeptic Owner——专门唱反调的人，他存在的意义就是说「等等，你们是不是漏了什么」。别的 reviewer 可能会说「整体还行」，Skeptic Owner 负责找出「整体还行」里藏着的坑。
测试者就像军队里的参谋和前线指挥官——两个角色，分工明确。一个 AI 负责设计测试用例：应该测什么场景、什么边界、什么异常。另一个 AI 负责执行：拿到测试计划后真正跑命令，收集通过/失败的证据。设计的人不碰代码，跑的人不改计划。为什么拆开？因为设计测试的人如果同时执行，会下意识地回避自己设计中的盲区。
裁决者（Gate）是最后一道关。它不是 AI——它是一段写死的代码逻辑，只会做一件事：数数。每个 reviewer 在评价时会对发现的问题做分类——Critical（致命）还是 Major（严重）还是 Minor（轻微）。Gate 拿到这些分类后：Critical ≥ 1 个？直接 FAIL。Major ≤ 2 个且没有 Critical？PASS。其他情况？ITERATE，回到建造者重新来过。
为什么裁决者不能是 AI？因为 AI 在看到混合信号时会被最后一句话锚定。三个 reviewer 都说 FAIL，但最后一个加了一句「整体可以接受」——AI 就可能判 PASS。数数不会被锚定。规则不会被说服。
一条 14 个节点的流水线
把这四种角色串起来，就得到了 OPC 的 full-stack flow——从讨论到交付的完整流水线。
讨论 → 建造 → 代码审查 → 测试设计 → 测试执行 → 测试门禁
→ 验收审查 → 验收门禁 → 安全审计 → 审计门禁
→ 端到端测试 → 端到端门禁 → UX 模拟 → 最终门禁14 个节点。每个节点有明确的输入、产出和交接协议。讨论节点的产出是一份需求规格书（不是一段对话记录）；代码审查的产出是 evaluation report；测试设计的产出是 test plan；测试执行的产出是 test evidence（真正跑过的命令输出）；门禁的产出是 PASS / FAIL / ITERATE 三种状态之一。
不是每个项目都需要跑全部 14 个节点。一个简单的 CSS 修复可能只走 build-verify flow（建造 → 审查 → 测试 → 门禁，4 个节点）。一个新功能可能走 8 个节点。只有产品发布前的正式审查才需要全部 14 个。流水线的长度由任务的风险决定，不是一刀切。
但不管跑多少节点，有一条规则是铁的：每个节点的产出都必须是 artifact——文件、截图、命令输出、评分报告——不是 AI 说的一句「我检查了，没问题」。
这条规则解决了上一集提到的「aspirational theater」问题。如果一个 test-execute 节点声称「测试通过了」但没有附上任何命令输出，它就不是测试——它是一篇关于测试的散文。
Gate 让「差不多」变得困难
流水线里最有价值的不是任何一个角色，而是 Gate——那些节点之间的门禁。
没有 Gate 的工作流是这样的：你让 AI 写代码，让另一个 AI review，review 发现三个问题，你看了看觉得「不严重」，标记为「下次再说」，然后发布。三个问题就此被遗忘。
有 Gate 的工作流是这样的：review 发现三个问题。每个 reviewer 在写报告时就对问题做分类——blocker（必须修）、yellow（应该修）、blue（可以不修）、false positive（误报）、out of scope（不在范围内）。Gate 拿到所有报告后只做一件事：按分类数数。分类本身是 reviewer 的工程判断；Gate 只是执行规则。你不能说「下次再说」——reviewer 必须给每个 finding 贴标签，Gate 拿标签做裁决。
Gate 就像大坝——它不让雨下得更好，它让洪水过不去。
在一次真实的审查中，Round 1 的 reviewer 发现了三个问题：一个正则校验只检查了开头没检查结尾（门只关了一半），两处测试用了不同的写法风格（不一致容易埋坑），一个错误处理范围太宽（什么异常都一律吞掉，包括不该吞的）。三个问题都被 reviewer 分类为 yellow（应该修），Gate 拿到标签一数——ITERATE，回到建造者。Round 2 把三个问题全修了。再过 Gate，PASS。
如果没有 Gate，第一轮 review 的三个 finding 会变成注释里的 TODO，永远不会被修。Gate 让「差不多做完了」这句话变得很难说出口。
1686 行机械规范
到这里你可能会问：这些 Gate 的规则是谁写的？谁决定什么是 Critical 什么是 Major？
答案是：1686 行 TypeScript 代码。
这些代码把所有模糊的质量标准变成了可执行的检查。举个例子，OPC 定义了 10 个「红旗」（red flag）——这不是一个随便往里加的开放列表，而是一个封闭清单（closed enum），写死了 10 个固定的检查项：
default-favicon：还在用默认的浏览器图标stack-trace-visible：错误页面暴露了完整的堆栈信息broken-link：有链接点不通data-loss-on-error：出错时会丢用户数据
每个红旗在不同的质量等级下有不同的严重程度。default-favicon 在 functional 等级下不管（你做一个命令行工具，谁在乎图标）；到了 polished 等级变成 warning；到了 delightful 等级变成 critical——因为一个追求极致体验的产品居然还用默认图标，说明你根本没打磨细节。
这比「总分 7.5」有用 100 倍。因为 7.5 分你不知道该改什么；而「default-favicon 是 critical」，你知道该去换图标。
同样的逻辑延伸到了 acceptance criteria 的审查。一个叫 criteria-lint 的工具会检查 14 项：你的验收标准里有没有用模糊词（「fast」、「clean」、「intuitive」——这些词没有配量化指标就不合格）；有没有不可能失败的条件（「should work as expected」——这句话永远为真，等于没说）；有没有重复的条目（两条 criteria 80% 的词一样，大概率是复制粘贴的冗余）。
这些规则不靠 AI 的判断。它们是代码。跑完给你一个结果，通过或者不通过，没有「整体还行」的中间地带。
有和没有的区别
在有流水线之前，我让 AI 建了一个家庭日历应用。做出来的东西能跑——但没有深色模式、没有 loading 动画、错误页面直接展示完整的报错堆栈。看起来像一个课程作业。
在有流水线之后，同样的任务跑了一轮 build-verify。Reviewer 抓出了缺失的深色模式和 loading 状态；测试用例覆盖了错误处理路径；Gate 判 ITERATE，回去修了两轮。最终产出：同一个 AI，同样的提示词，但结果从「课程作业」变成了「可以给人用的产品」。
区别不是 AI 变聪明了。区别是烂东西被挡住了。
$130 的教训
上一集讲过那次 27 小时马拉松的完整账本（28 个 subagent、$130、1.48 亿 token）。数字不重复了。重要的是那次经历教会我的一件事：
流水线的价值不在于让 AI 做得更好，而在于让坏东西过不去。
AI 不会因为你有了流水线就突然写出更好的代码。它依然会犯同样的错——用默认图标、不处理边界情况、写恒真的测试。但是有了流水线之后，这些错会被拦住。在它们变成用户的问题之前，被拦住。
OPC 不是一个让 AI 变强的工具。它是一个让一个人能像一支团队那样工作的系统——有建造、有审查、有测试、有裁决。每一步都有人（或者说有角色）在检查上一步的工作。没有人既是运动员又是裁判。
这就是一个人的工程团队。
硅基团队 S1: AI 能写代码，凭什么信它？ ← S1E01: 为什么 AI 能写代码却不能做工程 | S1E03: 从「能跑」到「能信」 →