102个AI工具0代码Bug：这家公司的Sprint 0玩砸了还

468个测试，464个通过，剩下4个失败还是因为Dev.to的API凭证过期。这不是传统开发团队的交付单，而是一个完全由AI代理（AI Agent，即自主执行任务的AI程序）担任主力开发者的Sprint 0成绩单。

更反常的是：零 flaky 测试（即不稳定、时过时不通过的测试），零环境配置地狱，零数据库。所有数据存在内存里，进程重启就清零——这种"自杀式架构"居然被团队称为"正确的Sprint 0选择"。

他们到底在干什么？

这是ORCHESTRATE平台的V3重建项目。V2版本已经跑在生产环境，管理4个LinkedIn主页的内容排期。V3要扩到YouTube、播客生成、AI新闻、多频道大规模发布。而Sprint 0的任务是：纯基础设施，零新功能，给V3搭地基。

团队用了102个工具的MCP（Model Context Protocol，模型上下文协议）服务器来约束AI代理，强制走敏捷流程。简单说，就是让AI像人类开发者一样：写文档→绑定文档→写失败测试→验证失败→实现→重构→验证→完成。

从5个故事砍到3个：计划过度乐观是通病

原定的Sprint 0有5个用户故事，覆盖V2数据迁移、API适配层、测试基础设施、MCP服务器核心、迁移验证器。中途砍了2个——OAS-040和OAS-041被重组为OAS-042和OAS-073，推到后面做。

「原始范围对于一个地基Sprint来说太激进了。」这是团队的复盘结论。

18张ticket走完了完整的文档驱动TDD（Test-Driven Development，测试驱动开发）。每张ticket 8个阶段，一步不能少。结果是：所有服务都带上了比"先写代码"更干净的接口，因为你在文档阶段就得想清楚"如果activity行是损坏的JSON怎么办"——这种问题在写第一行测试之前就得回答。

内存架构：快、确定、但会自杀

所有服务用TypeScript的Map和数组，没数据库，没文件I/O，没外部依赖。测试跑0.01秒一个，确定性拉满——没有I/O时序导致的 flaky 测试，没有"在我机器上能跑"的环境配置。

代价：进程重启，数据归零。

团队接受这个交易。Sprint 0不需要持久化，但需要速度。这也成了Sprint 1的首要风险：什么时候把数据落盘？怎么落？落多少？

审计追踪：让回滚有迹可循

V2迁移桥（Migration Bridge）的设计值得细品。每条迁移记录都是追加式的审计日志，V2源ID→V3目标ID，带SHA-256校验和。回滚不是"全删了重来"，而是"追踪每条记录回源头，精确删除"。迁移验证器再检查回滚是否干净。

验证用分层抽样：即使只抽10%，也保证每个实体类型（帖子、页面、活动）至少抽1条，且均匀分布在数据集里。这意味着任何实体类型的单条损坏记录都会被抓住，不用全表扫描。

AI代理的边界：能做什么，不能做什么

团队没避讳谈失败。Sprint规划高估了产能，5个故事砍成3个。这是人类产品经理的经典错误，AI代理没帮上忙——或者说，AI代理忠实地执行了过度乐观的计划，直到人类喊停。

文档驱动TDD的效果被验证：写文档→测试→代码的顺序，强迫你在编码前做契约思考。边缘情况在文档阶段暴露，接口设计更干净。

但AI代理的局限性也暴露：它能严格执行流程，但不能质疑流程本身的合理性。MCP服务器规定了敏捷方法论，AI就照做。计划太满？AI不会提醒。需要 descoping？人类得自己发现。

换句话说，AI是完美的执行者，但仍是糟糕的规划者。

Sprint 0的交付物已经上线：102-tool MCP服务器、React UI、Docker部署、4个LinkedIn页面的生产运行。V3的地基有了，但真正的硬仗——YouTube集成、播客生成、多频道规模发布——还没开始。

团队留下一个问题：当Sprint 1必须把数据落盘时，现在的内存架构要怎么迁移？审计追踪模式能撑住吗？AI代理在更复杂的业务逻辑面前，还能保持零 flaky 测试的记录吗？