很多人用AI写代码的方式是：打开一个聊天窗口，描述任务，让AI读取仓库、修改文件、运行测试、总结结果，全部在一个对话里完成。
小实验这么做没问题。但放到长期项目、共享仓库、生产系统或专业软件自动化场景里，这套玩法会变得极其脆弱。问题不在于模型够不够聪明，而在于它被要求承担了太多交付流程的责任。
更好的模式是把AI能力嵌入一个项目专属的交付流水线。AI是工人，流水线负责约束、验证、记录和升级。
为什么必须是"项目专属"
通用AI工具默认不可能知道一个项目的真实风险边界。交易系统中，支付、KYC、资金账户、订单状态、生产发布是硬边界。SketchUp建模工具里，真正的边界是结构化设计模型、源证据、桥接追踪、SketchUp执行和视觉审查。个人知识发布系统中，边界变成源可追溯性、双语发布候选、站点渲染和部署所有权。
这些约束不是来自通用模型，而是来自项目本身的真实情况。所以目标不是打造一个更通用的Codex或Claude Code替代品，而是在真实项目内部构建一个稳定的AI交付流水线。
流水线要回答什么问题
一个可用的项目专属AI交付流水线必须能回答：这个请求是否成熟到可以执行？AI应该自动运行、仅分析、在护栏下快速推进，还是只做技术预研？执行前AI应该接收什么上下文？AI能改什么、什么是禁区？什么时候必须停下来找人？什么证据能证明工作完成？结果应该变成PR、发布候选、知识笔记，还是仅作为实验记录？
如果项目没有通过自身机制回答这些问题，AI就还是在聊天窗口里即兴发挥。
最小结构拆解
我把流水线拆成几个部分。任务接收（Task Intake）把讨论变成可执行的任务合约。执行模式路由（Execution Mode Router）决定AI获得多少自主权。上下文包（Context Package）给AI提供它应该看到的窄上下文。工作隔离（Work Isolation）把AI执行限制在分支、工作树、槽位工作区或沙箱内。阶段门控工人（Stage-Gated Worker）把分类、分析、实现、验证、证据打包和交接分开。证据合约（Evidence Contract）要求测试、截图、API输出、日志、追踪或其他可审查的证明。人工关卡（Human Gate）把真人放在真正的风险边界上。反馈捕获（Feedback Capture）把重复失败变成规则、测试、技能、模板或知识库条目。
这些部分合起来就是我所说的"约束装置"。它不是提示词，不是单一工具，而是让AI参与交付的项目控制层。
TDD的位置
测试驱动开发有用，但不是全部答案。
热门跟贴