394 个问题之后：每个任务都做对了，产品为什么还是错的

CreatorOS 曾经有一个很难解释的状态。

我们按完整工作流做了 50 多个任务：

• 先写 spec；
• 过审核 gate；
• 拆成垂直切片；
• 每片都有测试、类型检查和截图验收；
• 每个任务都从 0 到 1 做完。

从任务看板看，一切都很健康。

但真正使用产品时，感觉始终是：怪怪的。

后来我组织 14 组审计，逐页检查 22 个页面。每一条发现都要求带文件位置或真实请求证据。

最后得到 394 个问题。

其中包括：

• 三个时代的数据同时存在；
• 7 处点了没反应的 tab；
• 6 处“写入真数据，读取却仍展示假数据”；
• 核心业务主线有 4 个硬断点。

最扎心的结论是：

每个任务单独看都正确，叠加起来的产品却是错的。

局部验收，抓不到切片之间的缝

垂直切片是一种很有效的交付方式。它能让一个功能从接口到页面一次闭环，避免“后端做完等前端”。

但切片验收天然只关心这次增量。

很多产品问题恰好不属于任何一个切片：

• 两代导入管线各自都能工作，叠加后同一条数据重复入库；
• 三个页面各自给阶段起了合理名称，放在一起却变成三套词表；
• 写入功能已经接真，读取页面仍在使用 fixture；
• 每个按钮单独有实现，但核心旅程仍然走不通。

单元正确性不会自动组合成整体正确性。

组合层需要自己的 owner，也需要自己的验收动作。

Mock 最大的问题，不是它假，而是没人负责让它退休

我们的开发路径是：

mock 数据 → 前端实现 → 后端接真 → 完成。

这里有一个默认前提：接入真数据时，旧 mock 应该被删除。

但工作流没有任何步骤真正负责这件事。

于是 fixture 从开发脚手架变成了永久数据源。后续功能看到它就继续 import，最后同一套系统里出现三代数据。

我后来把规则改成：

“接真”不是增加一条真实路径，而是真路径替换假路径、删除假数据，并验证旧消费点归零。

一句原则如果没有 owner、验收和销账条件，就等于没有。

最可靠的 demo，往往是最危险的验收对象

开发时大家都喜欢用数据最完整的 demo 项目验收。

它页面最好看，状态最齐，也最容易截图。

问题在于，真实用户的数据不会这么完整。空字段、null、还没生成的内容、没有历史版本，才是更常见的状态。

我们遇到过一个极端案例：

项目列表的“打开”链接有身份解析 bug。fixture 项目恰好能正常打开，所有真实项目打开后都会丢失身份。

开发、测试和截图都在 demo 世界里自洽，真实世界从来没有被走过。

所以现在我要求：

• 验收至少使用一个非 fixture 实体；
• 读失败时显式报错，不允许静默回退到假数据；
• 截图好看不能替代真实路径正确。

高吞吐会放大整体性缺失

AI 自治开发能把吞吐拉得非常高。过去一周完成的工作，现在可能一天就能做完。

但多个 Agent 并行时，每个 Agent 只对自己的切片负责。跨切片的一致性，没有人天然拥有。

速度越快，局部正确叠加成整体错误的速度也越快。

我们后来增加了六个机制：

1. Mock 退役 gate：引入 mock 时，同时登记退役条件；
2. 定期产品审计：每完成约十个任务，抽核心页面走真实链路；
3. UI 负债台账：假按钮、壳页面和未接线交互必须登记；
4. 真实数据验收：截图和走查至少使用一条真实数据；
5. 横切概念注册表：阶段名、状态词和 formatter 只能有一套；
6. 里程碑旅程验收：以用户身份走完整主线，而不是只看页面。

测试全绿，不是产品完成的证据

测试依然重要，但它只能证明被写进测试的问题。

用户感受到的是：

• 前后是否一致；
• 写完能不能读到；
• 页面之间的词是不是同一种语言；
• 一条任务能不能从开始走到结束；
• 出错时看到的是真错误，还是一份看起来正常的假数据。

这些问题没有哪一个能靠“某个任务的测试全绿”自动回答。

394 个问题最后被归成少数几个根因。它们让我意识到，AI 产品开发真正缺的不是更多执行 Agent，而是一个长期站在产品整体上、定期回头看的角色。

这个角色可以由人承担，也可以被做成审计工作流。

但它必须存在。

否则我们会不断完成正确的任务，然后得到一个错误的产品。