AI 写代码速度很快，所以很多失败也发生得很快。
最典型的任务是：“把支付功能完善一下”“全面优化 SEO”“把登录修好”。人类开发者看到这种任务也需要追问，模型却很可能直接开始改。最后代码不少，真正的业务规则反而被它顺手改掉。
解决办法不是研究一句更神的 Prompt，而是把开发任务写成能验收的施工单。
第一部分先写现状，不要让模型自己猜
至少说明仓库、技术栈、生产环境、相关模块现在做到哪里。更重要的是告诉它哪些事实已经成立。
例如：“收费模式是次数包，不是订阅”“只有任务真正生成成功才扣次数”“失败必须释放冻结额度”。这些不是实现建议，而是业务规则。模型不能因为某个支付 SDK 更适合订阅，就顺便把产品改成订阅。
如果有已经上线的模块、不能移动的目录、历史方案但尚未接入的代码，也要明确写出来。复杂仓库里，“存在”不等于“正在使用”。
第二部分写边界：这次不做什么
这是 AI Coding 特别需要的一段。人类工程师通常会凭经验判断不要顺便重构整个系统，模型却容易把“发现问题”理解成“应该一起解决”。因此可以直接写：不重新设计产品；不改商业规则；不扩大到移动端；不做无关性能优化；不要顺手更换框架。
边界越明确，任务越容易收口。
第三部分把模糊目标改成可观察状态
“支付正常”无法验收。可以拆成：创建订单成功；重复请求不会创建两笔订单；支付成功事件重复投递不会重复发权益；生成失败不消费次数；退款以后权益变化有确定结果；生产回调签名被验证。
每一条最好都能通过测试、数据库状态、接口响应或真实页面验证。
creat-web 这类模板项目会保留 typecheck、unit、integration、contract、security、SEO、commerce、E2E 等不同门禁。一次构建成功只能证明代码能被打包，不能证明业务链路成立。
第四部分告诉 AI 证据优先级
遇到文档、代码、生产状态互相矛盾时，模型需要知道信谁。已经锁定的业务规则优先；当前真实代码和数据库状态其次；历史设计文档只能提供背景；注释和 README 如果与运行事实冲突，需要先核实而不是盲从。
外部 API 也一样。支付、认证、框架能力会更新，涉及版本和当前行为时，应先看对应官方文档，而不是依赖模型记忆。
第五部分写清楚停止条件
很多任务失败不是修不好，而是没有停止条件。例如：“只修下面已经确认的 5 项；全部测试通过后停止，不继续做全面审计。”这会显著降低无限找 bug、无限扩范围的风险。
一份可执行任务至少有六块：背景和现状、目标、不可改变的业务规则、本轮范围、禁止范围、验收清单。涉及生产时，再增加部署、回滚和真实验证要求。
AI Coding 的瓶颈正在从“代码写不出来”变成“到底应该写什么、什么叫正确”。把施工单写清楚，就是把最贵的判断留在人手里，把大量实现工作交给机器。