很多人使用 AI 写代码时，会把整个流程放进一个聊天窗口：描述需求，让 AI 读仓库、改代码、跑测试、总结结果。

这在小实验里可以工作。但只要进入长期项目、多人协作、生产系统或专业软件控制，这种方式就开始不稳。问题不是 AI 不够聪明，而是它承担了太多本不该由模型承担的流程责任。

我更认可的方式是：把 AI 能力嵌入项目专用的交付流水线。

AI 是 worker。项目流水线负责约束、验证、记录和升级。

为什么必须是项目专用

通用 AI 工具无法天然知道一个项目真正的风险边界。

在交易系统里，提现、KYC、资金账户、订单状态和生产发布都是高风险边界。在 SketchUp 建模工具里，真正的边界是 design_model、source evidence、bridge trace、SketchUp 执行结果和视觉审阅。在个人知识发布系统里，边界又变成来源追踪、双语 publication candidate、站点渲染和部署责任。

这些约束都不是通用模型可以自动猜出来的。它们来自项目事实。

所以我们要做的不是开发一个更通用的 Codex 或 Claude Code，而是在具体项目里建立一条稳定的 AI 交付流水线。

流水线到底负责什么

一条可用的项目专用 AI 交付流水线，至少要回答这些问题：

  • 这个需求是否已经成熟到可以执行？
  • AI 应该自动执行、只做分析、全速但受控，还是只做 spike？
  • 执行前应该给 AI 哪些上下文？
  • AI 可以改什么，不能改什么？
  • 哪些情况必须停下来找人？
  • 怎样证明它真的完成了，而不是只是说完成了？
  • 结果应该进入 PR、release、知识库，还是只作为实验记录？

如果这些问题没有被项目机制回答，那 AI 仍然是在聊天里自由发挥。

一个最小结构

我会把这条流水线拆成几个部件：

Task Intake 把人的讨论转成任务合同。

Execution Mode Router 决定 AI 获得多少自治权。

Context Package 给 AI 准备它该看的窄上下文。

Work Isolation 让 AI 在独立分支、worktree、slot workspace 或 sandbox 中工作。

Stage-Gated Worker 把任务拆成 triage、analysis、implementation、validation、evidence packaging 和 handoff。

Evidence Contract 要求 AI 交付测试、截图、API 输出、日志、trace 或其他可复核证据。

Human Gate 把人放在真正的风险边界。

Feedback Capture 把重复失败沉淀成规则、测试、skill、模板或知识库内容。

这些部件加在一起，才是我说的 harness。它不是一个 prompt，也不是一个单独工具，而是项目把 AI 纳入交付流程的控制层。

TDD 在这里的位置

TDD 是有用的，但它不是全部。

如果需求边界清楚、行为可测试，先写测试再实现是很好的方式。可是很多真实任务不是函数题。前端需要截图，数据链路需要 API 或日志证明，SketchUp 建模需要结构化模型和视觉审阅，知识发布需要来源和双语路由验证。

所以更准确的说法不是“所有事情都 TDD”，而是“所有交付都必须有证据合同”。

测试是证据的一种。不是唯一一种。

为什么这比 vibe coding 更稳

vibe coding 的优势是快。它的问题是边界和证据太弱。

项目专用 AI 交付流水线不是要牺牲速度。它要把速度放在可控轨道里。

低风险任务可以 auto-run。复杂但边界清楚的任务可以 guarded full-speed。高风险任务只能分析或等待人工确认。探索性任务可以 spike，但不能被当成完成品。

这样 AI 仍然可以快，但不会把不成熟需求、高风险操作和无证据交付混成同一种“完成”。

核心判断

未来更有价值的，不是让 AI 在聊天窗口里更会表现，而是让项目拥有更好的 AI 交付流水线。

模型会变。CLI 工具会变。MCP、hooks、skills、subagents 也会变。

真正应该沉淀下来的，是项目如何定义任务、如何给上下文、如何限制执行、如何收集证据、如何让人介入、如何把失败变成下一次更稳的流程。

这就是项目专用 AI 交付流水线的价值。