让 AI 修复 issue 时，最危险的提示词往往是：“看一下这个问题并修复。”

这句话把 triage、analysis 和 implementation 混成了一步。对小问题也许没事，但在真实仓库里，它会让 AI 在没有边界确认的情况下直接改代码。

更好的做法是分阶段。

Triage 决定这件事能不能交给 AI

Triage 不是实现前的形式动作。它是授权边界。

在 triage 阶段，系统或 human 应该回答：

  • issue 是否有足够的用户问题描述；
  • 是否有当前证据或复现路径；
  • 验收标准是否具体；
  • 非目标是否明确；
  • 是否涉及高风险区域；
  • automation mode 是 analysis-only、implement-after-triage，还是 manual-only。

如果这些问题回答不了，AI 不应该直接实现。

Triage 的输出可以很短，但必须明确：这次 worker 被允许推进到哪里，在哪里必须停下。

Analysis 是为了发现真实代码边界

即使 issue 写得很好，也不能直接相信 issue 就是真实系统。

代码才是当前实现的事实。

Analysis 阶段的目标，是让 worker 对照 issue 和代码，判断：

  • 问题是否真实存在；
  • 相关代码在哪里；
  • issue 描述是否与代码一致；
  • 修复可能触及哪些模块；
  • 是否需要测试、截图、数据证明；
  • 是否出现停工条件。

很多任务在 analysis 后就应该停下。

例如：issue 说是 UI 问题，但代码显示需要改变 API contract；issue 说是简单 bug，但实际涉及权限、支付、安全或持久化数据；issue 的验收标准与当前产品行为矛盾。

这些情况下，最好的 AI 输出不是 patch，而是清晰的 analysis report。

Implementation 只应该处理已授权范围

只有当 triage 允许实现，analysis 没有触发停工条件，worker 才应该进入 implementation。

实现阶段也不应该变成“顺手优化”。

worker 应该只做 issue contract 允许的最小一致改动：

  • 修复目标问题；
  • 增加或更新相关测试；
  • 不扩大到无关重构；
  • 不改变非目标；
  • 不绕开风险边界；
  • 保留 evidence。

这看起来限制很多，但正是这些限制让 AI 产出的 PR 更容易 review。

一个小而明确的 AI PR，比一个“顺便整理了很多东西”的 AI PR 更有价值。

Gate 的意义是允许停止

很多团队把流程设计成“让 AI 一路跑到 PR”。

这不是真正的 gate。

真正的 gate 必须允许任务停止、降级或回到 human。

例如：

  • triage gate 可以把任务标记为 manual-only；
  • risk gate 可以把任务降级为 analysis-only；
  • analysis gate 可以输出 needs-human；
  • implementation gate 可以因为测试失败而停在 blocked；
  • evidence gate 可以阻止 PR 被当作完成品。

如果每个 gate 最终都只是让任务继续前进，那它只是装饰。

分阶段不是降低速度，而是降低返工

AI coding 的表面效率很高：它很快能改很多文件。

但如果任务边界错了，返工也会很快出现。reviewer 要解释为什么不该这么改，AI 要回滚或重做，issue 里的原始意图还可能被覆盖。

分阶段的价值，是把错误尽早暴露在便宜的地方。

triage 阶段发现不适合自动化，比 PR 阶段发现要便宜。analysis 阶段发现需要 human 判断，比合并后发现要便宜。evidence gate 发现验证不足，比线上发现要便宜。

AI workflow 不应该追求“每个 issue 都自动修完”。它应该追求“每个 issue 都在正确的边界上前进或停止”。