最近我们新启了一个 AI 搭建的业财中台项目。

第一天测试，Bug 单挂了 80 多个。

Codex 自己又补了 29 个。

云效上一共 109 个 Bug。

晚上 10 点，我给 Codex 下指令：

严格按 bug 修复流程，帮我修复所有 bug，我明天上午检查结果。

中途我看了一眼。

Codex 没停，云效上的 Bug 单在往“已修复”流转。

我就睡了。

第二天起来，101 个已经修完。

调用超过 800 多次。

我抽检了一部分，效果还不错。

我敢把 109 个 Bug 交给 Codex，靠的是一套流程。

这套流程只盯五件事：

读取缺陷

→ 制定修复计划

→ 小步执行修复

→ 真实环境逐条验证

→ Git 提交（确保可追溯）

→ 更新缺陷状态（形成闭环）

批量修 Bug，最怕修乱。

所以第一步不是改代码，是让 Git 留回退点。

Bug 修复前自动提交一次。

后面每一个bug修复改动，都能看 diff。

改错了，可以退。

修偏了，可以回到干净现场重新来。

这一次，我没有让 Codex 自由改代码，我用 skill-creator 做了一个直连云效的 bug 修复技能，核心只有一件事：让 Codex 必须按流程工作。流程是固定的：理解问题 → 生成计划 → 创建测试 → 小步修复 → diff 校验 → 命令验证 → 真实环境验证 → 全量通过 → 提交代码不允许跳步，不允许直接给结果。当 109 个 Bug 同时进来时，流程是唯一的稳定器。 先管流程，再谈速度。

我的 bug 修复流程里，有几条硬约束：

不使用本地数据库。

不使用 mock 数据。

必须走真实服务端链路。

AI 很容易找一条“能成功”的路。

真实环境卡住了，它可能换成本地。

真实数据不好拿，它可能用 mock。

主链路不好跑，它可能换一个更轻的命令。

这些都不能算验收。

我通过skill-creator建的jira-bug-flow，原来基于 Jira，现在已迁移到云效。

它把每个 Bug 从发现、修复、提交、流转、验证到交付，都留下记录。

Codex 负责执行。

云效记录状态。

Git 保留回退点。

测试环境给反馈。

人最后做判断。

101 个已修复，不是交付完成。

800 多次调用，也不是交付证据。

我第二天看的是 Bug 单状态、测试结果和真实环境反馈，最后一步还是我们的测试再收一下口，毕竟首次这样用。

AI 提效的关键，不是更快，而是结果可验证。

我现在不相信 AI 说“完成了”。

我只相信验证记录。

先验证，再相信。

如果你把一批任务交给 AI，你会先看它完成了多少，还是先看它留下了哪些验证记录？