AI coding workflow 很容易把 PR 当成终点。

worker 改完代码，测试通过，打开 PR；human review 之后 merge。看起来任务完成了。

但在真实软件系统里，PR merged 往往不是 done。

它只是一个边界：代码已经进入主干。发布、验证、回滚准备和用户问题是否真正解决，仍然是后续问题。

为什么 AI 更容易混淆 merge 和 done

AI worker 的工作空间通常是本地仓库。

它能看到文件，能跑测试，能提交 diff，能写 PR summary。它天然会把“代码改完”当成任务闭环。

但生产系统的闭环通常在仓库之外：

  • 部署是否发生；
  • feature flag 是否打开；
  • 数据是否需要 backfill；
  • 队列或缓存是否需要观察；
  • 用户是否还看到问题；
  • 监控是否异常；
  • 是否需要 rollback plan；
  • 客服、运营或产品是否需要同步。

这些不应该默认交给一次 coding worker 决定。

把状态拆开

一个更可靠的 workflow 应该把这些状态拆开：

  • PR opened；
  • PR reviewed；
  • PR merged；
  • release prepared；
  • release deployed；
  • production verified；
  • issue closed。

不同团队可以合并其中一些状态，但不应该在概念上把它们混成一个 done。

如果一个 issue 是纯文档修改，PR merged 也许就可以 close。

如果一个 issue 涉及用户可见行为、数据链路、支付、安全、权限或生产任务，那么 PR merged 只是进入 release boundary。

Release boundary 应该由 human 或明确自动化拥有

Codex worker 可以帮助准备 release notes，也可以根据 PR evidence 写出验证步骤。

但谁决定发布，应该明确。

可以是 human release owner，可以是 CI/CD pipeline，可以是某个 release bot。关键是：这个 owner 不能被隐藏在 AI worker 的 prompt 里。

如果团队确实有成熟自动发布，也应该把规则写清楚：

  • 哪类变更可以自动部署；
  • 哪类变更必须人工确认；
  • 部署失败如何回滚；
  • 线上验证由谁负责；
  • issue 什么时候可以关闭。

没有这些规则时，AI worker 不应该把 merge 当成 done。

Issue comment 应该记录 release 状态

一个简单但有效的做法，是在 PR merge 后回写 issue comment：

PR merged, release verification still required.
Release owner: human
Verification plan:
- confirm dashboard status refresh after deploy
- check error logs for 30 minutes
Final issue closure: after production verification

这个 comment 的价值是把后续责任说清楚。

即使暂时没有自动化，human 也能从 issue 里看到任务没有真正结束。

Done 应该绑定用户问题，而不是绑定代码动作

issue 的起点是用户问题，不是代码任务。

所以 done 的定义也应该回到用户问题：

  • 用户看到的问题是否消失；
  • 预期行为是否出现；
  • 证据是否覆盖验收标准；
  • 生产或目标环境是否已验证；
  • 残余风险是否被接受。

如果这些问题还没有答案，PR merged 就只是中间状态。

AI 工程协作最需要避免的，不是 PR 开得慢，而是把未验证的代码动作误标为已解决的用户问题。