AI Coding 项目交付流程：从需求到可验收成果

AI 编程工具越来越擅长生成代码，但“代码能生成”不等于“项目已经交付”。真正容易出问题的地方，通常是需求没有说清、修改范围失控、测试没有覆盖，以及最后没有把变更和已知风险交代清楚。

这份流程适合个人开发者、独立开发者，以及使用 Codex、Claude Code 等编程 Agent 的小团队。它不是要求每个任务都走完繁琐流程，而是让风险与任务规模相匹配。

一套可重复使用的交付流程

1. 先把需求变成可验收条件

开始改代码前，先写清楚：

• 要解决什么问题，谁会使用这个功能？
• 哪些行为必须改变，哪些现有行为不能被破坏？
• 什么结果算完成？用可以观察或测试的条件描述。
• 哪些信息仍不确定，需要先向用户确认？

避免只写“优化页面”“重构模块”这类没有边界的任务。一个好的任务说明应当能让另一个开发者判断结果是否符合要求。

2. 先检查现状，再制定计划

让 Agent 先阅读相关目录、配置、测试和现有实现，再提出最小变更计划。计划至少列出要修改的文件、可能影响的模块、验证命令和风险点。

如果任务涉及支付、身份验证、数据迁移、线上写操作或权限边界，应当先明确安全约束，不要直接让 Agent 自由探索并执行。

3. 小步实现，不要把所有工作塞进一次生成

按可独立验证的步骤修改。每一步都尽量保持范围清晰，先完成关键路径，再处理边界情况和体验细节。遇到需求冲突或发现假设不成立时，应先停下来澄清，而不是默默扩大范围。

4. 用工具验证，而不是让模型自我评价

至少区分四类检查：

• 静态检查： 类型、格式、依赖和构建是否通过。
• 功能检查： 核心路径是否按预期工作。
• 回归检查： 既有功能是否被破坏。
• 交付检查： 文档、配置、迁移步骤和限制是否完整。

模型说“测试通过”不能代替真实命令输出。没有运行的测试应明确标为未运行。

5. 交付时说明结果与风险

最终交付至少包含：完成了什么、修改了哪些关键文件、执行了哪些验证、哪些验证没有执行、仍有哪些限制，以及如何回滚或继续排查。

可直接复用的任务模板

目标：
用户与使用场景：
必须满足的验收条件：
不可破坏的现有行为：
允许修改的范围：
需要先确认的问题：
实施计划：
验证命令与预期结果：
安全/兼容性风险：
最终交付格式：

如何判断交付真的完成？

不要只看代码量或提交次数。至少检查：验收条件是否逐项对应结果、关键验证是否真实运行、失败是否被如实报告、变更是否可回滚，以及其他人是否能接手维护。

如果你希望把这套方法交给编程 Agent 持续执行，可以从AI 项目交付技能开始，再结合网站上线验收技能完成发布前检查。

常见问题

所有任务都需要完整流程吗？

不需要。小改动可以缩短计划和验证步骤；涉及数据、权限、线上服务或大范围重构时，应提高验证强度。

AI 已经生成了测试，为什么还要自己检查？

测试本身也可能遗漏关键条件，甚至只验证实现者预期的行为。需要结合需求验收条件、真实运行结果和必要的人工检查。

怎样降低 Token 消耗？

先让 Agent 定位相关文件并明确计划，限制无关目录探索；让脚本执行确定性检查；只把需要判断的部分交给模型。把完整历史反复塞进每轮上下文，通常不是最省钱的做法。