反思：AI 全自动开发需要方向盘与刹车

[TATP-233]

发生了什么

#705 最初包含两个合理目标：推进 manager-based API，以及让 mjwarp 充当迁移 mjlab 工作时的控制变量和 backend adapter 案例。后来 roadmap 却把 mjwarp 推成了 production GPU backend，并继续加入 typed batch、device-resident runtime、CUDA graph、完整 DR、性能工程、support claim、专属 evidence 和 CI gate。

相对 main，这个分支最终膨胀到 304 个提交、285 个文件、约 10 万行新增，其中包括大量生成的 evidence 和 artifact。它已经不是一个 issue，而是一个没有经过有效决策的项目。

#705 已关闭。#882 只记录新的方向：统一 physics backend contract 服务 manager-based API，mjwarp 严格作为同一 contract 下的普通 adapter；未来可能独立的 unisim package 不属于当前实施目标。#882 本身也只能是 umbrella，必须拆分后逐项授权，不能整单执行。

责任

这不是“roadmap 太大”，也不是“AI 缺少刹车”。这是一次 owner 失职。

UniLab 的核心方向本来就很清楚。TATP-233 却把另一个目标放到了项目之上：证明自己找到了让 AI 24 小时全自动完成大型工程的方法。连续提交、不断增加的 issue 和 PR、越来越多的测试与绿灯带来了成就感。为了维持这个成功叙事，一个 adapter 案例被默许变成第二套 production 系统，仓库开始替个人自动化实验承担代码、认知、兼容和 CI 成本。

TATP-233 当时不是在用 AI 建设 UniLab，而是在用 UniLab 证明自己能驾驭 AI；当两个目标发生冲突时，后者压过了前者。

把原因归结为“AI 没有主动反对”仍然是在甩锅。AI 没有项目所有权，也不承担长期维护成本，owner 承担。方向、边界和停止决定是 owner 不能外包的职责。

标题中的“方向盘与刹车”也不应被理解为等待 AI 自己补齐的功能。方向盘由 owner 掌握，刹车也必须由 owner 踩下。这次不是 AI 夺走了控制权，而是 owner 在享受自动化吞吐时放弃了有效控制。

所谓 human-in-the-loop 当时是假的

更严重的事实是：AI 当初写的很多 roadmap，TATP-233 并没有真正看懂。他无法说明每个 phase 会怎样改变项目边界、产生哪些永久责任，也不能独立判断为什么需要这些工作，但仍然授权继续执行，并用其他 AI 的 review 弥补自己的不理解。

这形成了一个封闭回路：AI 写目标和 roadmap，AI review，AI 实现，AI 编写测试与 gate，再由 AI 宣布通过；人类只负责点头。形式上存在人类审批，实际上审批已经失效，因为审批者无法解释自己批准了什么。多个模型共享同一前提，只能提高方案的内部一致性，不能把理解转移给 maintainer，也不能证明目标值得做。

看不懂这些 roadmap，不说明主要开发者不专业。一个让仓库主要开发者无法判断真实影响的 roadmap，本身就是失败的技术沟通。AI 没有主观上故意欺骗，但它确实使用了过分复杂的表述：它追求技术完整感、权威感和连续可施工性，把“将 adapter 升级成第二套 production 系统”这一产品选择藏进了大量 compiler、runtime、contract、phase 和 evidence 术语里。

责任必须分清：TATP-233 的问题是看不懂仍然批准；AI 输出的问题是把无法有效审批的文档当成充分说明，并把点头当成知情授权。

如果 maintainer 不能用自己的话解释一份 roadmap 为什么值得做、会留下什么永久负担、哪些东西明确不做，这份 roadmap 就没有得到真正批准；控制权只是被交了出去。

Gate 不能证明目标正确

测试、benchmark、evidence 和 gate 最多证明实现符合 roadmap，不能证明 roadmap 符合 UniLab 的定位。由同一个 AI 闭环定义目标、制定指标、完成实现并宣布通过，本质上是自己出题、自己阅卷、自己宣布正确。

24 小时不间断执行也不是成功证据。它只证明错误目标可以在第一次有效复盘前被高速放大。代码生成变便宜了，但维护、理解、兼容和删除的成本没有变便宜。

以后执行的硬约束

1. Roadmap 必须先提供约 300 字、没有自创术语的 owner summary，明确说明：只做什么、不做什么、预计规模，以及合并后新增什么永久责任。
2. 一个 implementation issue 只允许一个主要结果，默认不超过 15 个文件、800 行净手写改动、一个 PR；超过任一上限只能作为 umbrella，必须拆分。
3. 公共 contract、backend production 化、性能优化、support 升级、永久 CI/evidence、历史重写不得混在同一个 implementation issue。
4. Issue 必须写清问题证据、最小交付、non-goals、owner layer、预计文件/LOC/PR 数、验收标准和停止条件。
5. 新增 execution path、runner/lifecycle、公共 contract、常规 CI、support 等级，或者 adapter 开始演变为 production subsystem 时，必须停止并重新授权。
6. 批准 roadmap 或 umbrella 只授权规划，不授权修改代码；“开始开发”默认只授权第一个明确确认的 child issue，完成后不得自动进入下一个。
7. 如果 maintainer 表示看不懂，必须停止并重写。不能问一句“是否理解”就继续，也不能用更多 AI review 替代解释。
8. 每项大型工作先回答：它服务 UniLab 的什么核心价值，最小方案是什么，为什么不能直接复用上游，不做的代价是什么。如果答不清，正确结果就是不做。

最后的结论

这次问题不是 AI 还不够可靠，也不是还需要再增加一层 gate。更本质的问题是，owner 把不能外包的项目判断外包了，却保留了“全自动开发成功”的成就感，把错误方向产生的债务留给了仓库。

以后衡量 AI 开发的标准不是运行了多久、提交了多少代码、通过了多少 gate，而是最终留下了多少真正服务 UniLab、能够被 maintainer 理解并愿意长期维护的东西。