前情提要： 先导季里，我用 AI 搭了一个完整的项目管理工具 — 从需求到部署全程 AI 执行。一个人 + AI，真的做出了东西。但”能做出来”和”做得好”是两回事。这一季的问题是：AI 写的代码，你敢直接上线吗？
我写了一个程序，让多个 AI 按照流程分工合作——一个写代码，一个检查代码，一个专门挑毛病。这个程序叫 OPC（One Person Company，一个人的公司）。
然后有一天，我让 OPC 检查它自己。
四个 AI 审查员各自独立阅读代码，互相看不到对方的报告。结果出来的时候我愣了——四个角色，每一个都判了不合格：有人发现测试写得怎么跑都通过（等于没测），有人发现 95% 的测试文件根本没被执行过，有人发现安全漏洞，有人发现架构设计有错误。
四个角色，互不通气，全部判 FAIL。
一个专门用来检查其他项目代码质量的工具，自己的测试是假的。
这是整个故事的起点。
实习生很快，但不懂规矩
想象你招了一个实习生。写代码的速度是你的十倍，什么语言都会，什么框架都敢上手。你说「帮我搭个网站」，三分钟后一个完整的页面就出来了。
听起来完美。
然后你发现：它写的测试永远是绿的——不是因为代码没 bug，而是因为测试本身被写成了「无论如何都通过」。你发现 npm test 只跑了 11 个测试文件中的 1 个，剩下 10 个从来没有人执行过。你发现评估文件可以是空的——系统只检查文件存不存在，不检查里面有没有内容。
这不是偶发的马虎。这是 AI 写代码的结构性盲区：它能生成符合要求的代码，但不理解「要求」本身为什么存在。
测试的意义不是「产出一个绿色的勾」，而是「在代码出错时报红」。如果测试永远是绿的，它就不是测试——它是一个安慰剂。AI 不理解这个区别，因为它从来没有经历过「半夜被测试不通过的告警叫醒」的那种恐惧。
三个工具其实是同一个东西
在发现这个问题之前，我手头有三个独立的工具在跑。它们做的事情看起来完全不一样——一个管 AI 写代码的流程，一个评估工具好不好用，一个筛选商业点子——但跑了几周之后，我突然意识到：
等等，这三个东西是不是同一个东西？
你可能也有过类似的体验。做产品也是这样：设计稿出来 → 设计评审 → 老板拍板。写文章也是这样：初稿 → 编辑审核 → 发布。甚至做饭也是：炒菜 → 试味 → 上桌。
构建 → 审查 → 关卡决定能不能通过。 这个模式无处不在。
我的三个工具背后都是这同一个模式。所以它们合并成了一条流水线。OPC 成了这条流水线的引擎。
28 个 AI 员工，$130，两天一夜
合并之后的第一件事，是让 OPC 审计自己。
我启动了 4 个独立的 reviewer agent：工程师、安全专家、架构师、魔鬼代言人（Devil’s Advocate，专门唱反调）。它们各自独立阅读代码，各自独立给出评价——互相看不到对方写了什么。
结果是 7 个 Critical 和 High 级别的问题。前面说的恒真测试、1/11 执行率、空文件作弊，都在这一轮被抓出来。
修完这 7 个问题之后，又发现了更深层的问题：OPC 做出来的产品「能用」，但不够好——没有深色模式、没有流畅的动画、排版用的是系统默认字体。打分总是卡在 6.5 到 8.5 之间，怎么都上不去。
问题出在哪？不是 AI 不会做这些，而是没人要求它做。验收标准（Definition of Done）里只写了功能需求，没写「要有深色模式」。AI 的激励是「通过审查」，不是「让用户愿意付钱」。
于是我们设计了一套 Quality Tier 系统：三个等级，从「能跑」到「好用」到「让人惊喜」。等级在项目开始时选定，写进配置文件，然后整条流水线的每个环节都按这个等级来检查。不靠 AI 自觉，靠代码强制执行。
整个过程用了两天一夜。28 个 AI 助手被派出去执行各种任务。总共消耗了 1.48 亿个 token（token 是 AI 处理文字的基本单位，大约等于一个词；1.48 亿个 token 差不多相当于读完 200 本书的文字量），花费 $130。
最贵的一课是什么？我们尝试让 AI 模拟「用户愿不愿意付钱」。设计了 5 个虚拟买家，每个有不同的背景，让它们独立评估产品，给出「愿意付多少钱」的数字。
结果被 4 个审查员同时击穿：AI 给出的「愿意付钱」不是真正的经济信号——它只是在你给定的价格范围里随机挑了一个数。 AI 能告诉你「这个东西做得好不好」（品质判断），但不能告诉你「值不值得花钱买」（购买决策）。因为 AI 没有钱包，没有预算约束，没有「上个月信用卡账单太高所以这个月省着点」的真实压力。
写代码 ≠ 做工程
这次审计之后，我理解了一件事：
写代码是把需求翻译成机器能执行的指令。AI 很擅长这个。
做工程是设计一套系统，让代码在出错时被拦住，让质量随时间提升而不是随机波动，让一个人也能像一支团队那样工作。AI 不擅长这个——不是因为它不够聪明，而是因为「工程」的核心不是写代码，而是检查写代码的人。
OPC 就是为了解决这个问题而诞生的。它不让写代码的 AI 自己判断代码好不好——而是派另一个 AI 去检查，再派一个 AI 去检查检查者，最后用代码写死的规则做最终裁决。
做事的人不评判自己。这是 OPC 的第一原则。
如果你现在在用 AI 写代码，至少记住一件事：永远不要让写代码的 AI 自己判断代码好不好。 让另一个人（或者另一个 AI）来检查。这一条规则能帮你避开 90% 的坑。
接下来的 10 集，我会完整讲述 OPC 从一个「会翻车的原型」变成「一个人的工程团队」的全过程。每个数字都是真的，每次翻车都有记录。
硅基团队 S1: AI 能写代码，凭什么信它？ S1E02: 一个人的工程团队长什么样 →