AI 开发最常见的风险，不是模型不会写代码，而是它太早开始写代码。

人在聊天里说“帮我修一下这个问题”，AI 很容易马上读文件、猜原因、改代码、跑测试，然后给出一个看似完整的总结。但对真实项目来说，执行前最重要的问题还没有回答：这个需求到底成熟吗？这次允许 AI 做到哪一步？

所以项目专用 AI 交付流水线的第一步，不是 implementation，而是 task intake 和 execution mode routing。

聊天不是任务合同

聊天适合讨论，但不适合直接作为执行合同。

一段聊天里可能混合了抱怨、猜测、目标、背景、临时想法和真正的验收标准。人类可以凭经验分辨哪些是事实，哪些只是表达。AI 不一定能稳定做到。

任务合同的作用，是把讨论压缩成可执行边界。

一个最小任务合同应该包含：

  • 用户问题是什么；
  • 期望行为是什么；
  • 当前证据是什么；
  • 验收标准是什么；
  • 这次不做什么；
  • 已知风险是什么；
  • 哪个文件、系统或产品状态是真相源；
  • 哪些情况必须停下来。

没有这些字段，AI 就是在模糊任务里自由发挥。

先分流，再执行

任务合同之后，必须决定执行模式。

我通常把模式分成四类。

auto-run 适合低风险、边界明确、可测试、可回滚的任务。例如小 UI 文案、明显 bug、文档修复、局部测试补充。

manual-triage 适合目标还不清楚，或者可能触碰资金、权限、安全、schema、生产状态、核心业务语义的任务。AI 可以分析，但不能默认实现。

guarded-full-speed 适合复杂但边界清楚的任务。AI 可以连续推进，但必须遵守停工条件、证据要求和人工门禁。

spike 适合探索。spike 的产物是判断材料，不是 production-ready delivery。

这四种模式的区别，不是 AI 能力大小，而是项目愿意给它多少执行权限。

为什么 auto-run 必须 opt-in

自动化不应该默认开启。

GitHub issue、产品讨论、项目笔记里有很多内容并不适合自动执行。可能是用户反馈，可能是产品想法，可能是线上事故，可能是合规疑问，也可能只是暂存材料。

只有明确标记进入自动化的任务，才应该允许 AI 自动 claim、分析、实现和开 PR。

这个 opt-in 不只是标签。它代表项目已经确认：这个任务的范围、风险和验收条件足够清楚，可以交给流水线处理。

停工条件比提示词更重要

很多人会在 prompt 里写“如果不确定就问我”。这不够。

项目应该把停工条件写进任务合同或执行规则里。例如：

  • 验收标准缺失；
  • 需求互相矛盾；
  • 需要改变核心业务语义；
  • 需要修改生产数据；
  • 涉及资金、交易、权限、安全或合规；
  • 证据门禁失败；
  • AI 找不到可靠真相源。

这些条件触发时，AI 不应该继续“努力完成”，而应该转入 needs-input、review-required 或 failed-needs-human。

任务合同不是官僚主义

任务合同看起来像增加流程，其实是在减少返工。

没有合同，AI 可能很快给你一个 patch，但你要花更多时间判断它有没有解决真实问题、有没有扩大范围、有没有破坏边界。

有合同，AI 的工作会更窄、更清楚、更容易验证。即使它失败，也能说明失败在需求、上下文、实现、测试还是证据上。

这就是交付流水线的第一条原则：先把需求变成可执行合同，再决定 AI 能不能动手。