如果 AI 要进入真实项目，它不应该直接在你的主工作区里随意修改。

主工作区里可能有你未提交的改动、临时调试、未同步的文档、生产配置、个人脚本。AI 一旦在这里误删、误改、误跑命令，责任很难追。

所以项目专用 AI 交付流水线需要两件事：work isolation 和 stage-gated worker。

隔离不是不信任 AI

隔离不是因为 AI 一定会犯错。隔离是工程常识。

人类工程师也会用分支、PR、CI、review、release gate。AI 更应该被放进可追踪的工作空间里。

隔离可以有很多形态：

  • Git branch；
  • worktree；
  • slot workspace；
  • sandbox；
  • 临时项目目录；
  • 专用 evidence directory；
  • 受控的工具权限。

关键不是形式，而是 AI 的执行结果必须和用户主工作区分开。

分支也是 claim lock

在多人或多 worker 场景里，隔离还解决并发问题。

如果两个 AI worker 同时处理同一个 issue，它们可能互相覆盖、重复开 PR，或者把状态写乱。一个明确的 branch claim 或 workspace slot 可以告诉系统：这件任务已经有人在处理。

这比只在聊天里说“我在处理”可靠得多。

项目状态应该存在 GitHub、issue comment、label、branch、manifest 或其他外部系统里，而不是只存在模型上下文里。

Worker 不应该一步到位

AI 很容易把任务看成一个连续动作：读、改、测、总结。

真实项目更需要阶段。

一个更稳的 worker 流程可以是：

triage
-> analysis
-> implementation
-> validation
-> evidence packaging
-> PR or handoff

高风险项目还应该继续拆：

release readiness
-> release approval
-> deployment
-> production verification
-> done

每个阶段都有不同权限。triage 阶段可以读代码，但不应该随便改业务代码。analysis 阶段可以提出方案，但遇到高风险要停。implementation 阶段可以修改，但必须产生证据。release 阶段通常不应该由同一个 worker 自动跨过去。

stage gate 的作用

stage gate 不是为了让流程变慢，而是为了让失败更早、更便宜。

triage 阶段发现需求不清，比 PR 阶段发现便宜。analysis 阶段发现风险过高，比实现后发现便宜。evidence gate 发现验证不足，比线上发现便宜。

这和传统 deployment pipeline 的逻辑一致：每个阶段增加一点信心，也增加一点成本。越靠后，越应该谨慎。

guarded full-speed 不是无脑执行

我认可“全速执行”，但它必须是 guarded full-speed。

guarded 的意思是：

  • 任务合同已经明确；
  • 上下文包已经准备；
  • 工作区已经隔离；
  • 高风险边界已经写清；
  • 验证命令和证据要求已经定义；
  • 触发停工条件时必须停。

在这个前提下，AI 可以少问废话、连续推进、自己修复测试失败、自己补证据。

没有这些前提的“全速执行”，只是更快的失控。

结论

AI worker 要进入真实项目，必须被放进隔离工作区，并且按阶段推进。

这不是降低效率，而是让 AI 的效率可以被项目吸收。

真正有用的不是“AI 一口气做完”，而是“AI 在正确空间里、用正确权限、经过正确门禁，推进到正确交付边界”。