| 环节 | 之前 | 之后 |
|---|---|---|
| 提需求 | 写详细任务 | 跟 Planner 说一句 |
| 批准待办 | 人 | 人（唯一保留） |
| 选人 | 凭感觉 | 按额度和成绩单 |
| 评审 | 人排队 | 另一个账号的 Reviewer + 自动检查 |
| 合并部署 | 人点按钮 | 自动 |
| 验收 | 人或没人 | Planner 线上验证 |
| 代码健康 | 没人管 | Auditor 每周报告 |
代价：
- “已批准”状态 agent 也能改。平台拦不住，靠指令约束和每日摘要里的批准核对来发现；代码仍然要过检查和独立评审才能合入。
- 先部署后验收。新功能建议放在功能开关后面，验收通过再全量打开。
- 额度规则变化快。比如 Codex 的 5 小时限制在 2026 年 7 月取消、8 月底又恢复，registry.yaml 要每月核对。
- 人参与少了会对代码变陌生。建议每周抽读一两个合入的 PR，调试和架构决策刻意保留给人做。
- 平台闸门取决于 GitHub 套餐。Free 的私有仓库只有指令约束（降级模式），见保护等级。
- Multica 迭代很快。几乎每个工作日都发版，行为可能变化（0.5 就改了状态模型）。升级后跑一次
aiwf doctor，再演练一个小需求；aiwf 用的都是公开 CLI，只有建自定义状态直接调了 Multica 的 HTTP 接口，失败时会退回手工步骤。
还没验证的部分
Section titled “还没验证的部分”- 没在长期运行的大型项目上验证过整套配置，效果要用每周指标自己衡量。
- 跨文件调用数这类可维护性指标和语言强相关，
health-metrics.sh没有内置。 - Multica agent 的调用权限：默认 private，autopilot 和 agent 由同一个人创建时链路能走通；多人协作时要改成 workspace。
什么时候不该用
Section titled “什么时候不该用”- 还没有一条命令能跑完的严格检查。先做
make check。 - 需求模糊、需要大量探索的阶段。
- 没人愿意批准任务、处理升级、每周看指标。这套流程把人的工作压缩到了最少，但不是零。