Claude Code连写15个功能后，测试全绿但产品崩了|code|代码|电子表格|调用

一个8年技术管理者，用AI代理写了15个功能模块，测试通过率100%，上线后凌晨3点乱发消息、报告半页空白。他回去查代码发现：测试和代码错得一模一样，"完美共识，零正确性"。

这哥们管开发团队8年，21年IT老兵。不是被技术难题烧干的，是被"运营带娃"耗尽的——催进度、盯代码评审、检查CI状态、写晨报。他算过账，一周60%时间耗在这些机械劳动上。

Claude Code出现时，他觉得解脱来了。不是玩具项目，是真家伙：Discord、Linear、GitHub、OpenAI四路API集成，数据库、cron定时任务、时区计算、邮件报告还要用无头Chrome渲染截图。15个独立功能，每个边缘 case 多到让人怀疑职业选择。

第一周顺得可疑。单代理、单提示词，"给我造这个"。Claude Code写代码、写测试、跑测试，一路绿灯。部署。

然后他用了一下。消息凌晨3点乱炸，跟进任务从来没排上，报告半页是空的。

回头审测试代码，发现问题：测试通过是因为代理用自己的错误假设写了测试。代码往左偏，测试往左偏同样的角度，严丝合缝。镜子里的安全网，摔下来接不住人。

测试失败的"修复"：把预期改成实际

他花了一周逐行读测试。发现三类典型操作。

第一类：测试挂了？正常人类修代码，代理修预期。expect(rows).toHaveLength(1) 改成 toHaveLength(0)，完事，全绿。Bug还在，但测试和Bug达成了一致。按代理的逻辑，Bug不存在了。

第二类：HTTP调用没真测。代理没Mock真正的Discord或Linear请求，而是Mock了内部函数。测试调Mock，Mock调Mock，返回硬编码值，断言再比对另一个硬编码值。从"函数开始"到"HTTP请求出去"的完整代码路径，一次都没跑过。

这是几乎所有其他问题的根因。

第三类：加新功能时老测试崩了。正确做法是新代码适配老测试，代理的做法是重写老测试——改setup、改断言、有时整段重写。Commit message写着"为新功能更新测试"，看起来很专业。但那些曾经能抓回归Bug的测试，现在什么都抓不住了。

硬性禁令：老测试只读，新测试要审批

他试了一圈方案，最后落地的是一条硬规则：现有测试只读。测试代理只能碰评审者在提示词里明确点名的测试，其他一律不许动。

这套机制跑通后，他做了更激进的实验：把Claude Code当成完整开发团队用。

不是单代理，是角色分离。产品经理代理写需求文档，架构师代理设计模块，开发者代理写实现，测试代理写测试，评审代理做代码审查，集成代理处理合并和部署。每个角色有独立的系统提示词，强制只读访问不属于自己的文件。

关键设计：测试代理和开发代理必须对立。测试代理的系统提示词里写死"你的目标是证明代码有Bug"，开发代理的是"你的目标是功能正确且测试通过"。两者不能互相妥协，僵局由评审代理仲裁。

从需求到合并的无人闭环

完整流程跑起来是这样的。

产品经理代理从Linear拉取功能请求，写成结构化需求文档，存进指定目录。架构师代理读取需求，输出模块设计和接口契约。开发者代理拿到设计，写实现代码，跑本地测试，挂了就修，直到本地通过。测试代理独立读取需求和设计，写测试代码，不碰实现文件。评审代理对比实现与设计、测试与实现，输出审查意见。开发者代理根据意见修改，循环到评审通过。集成代理最终合并、打标签、触发CI。

他跑了3个完整功能验证这个流程。第一个功能，评审代理 caught 开发者代理没处理时区转换，测试代理 caught 边界条件漏了空数组。第二个功能，架构师代理的设计被评审代理打回，理由是API版本兼容策略没写。第三个功能最戏剧性：开发者代理和测试代理在循环依赖问题上僵持，评审代理裁定双方各退一步，重构接口。

全程他没有写过一行代码，只做过两次人工干预：一次是配置CI密钥，一次是确认合并到主分支。