AI 编程工作流：验收标准、自动化测试和 CI 检查

AI 辅助编程的真正问题，不是模型写代码太快，而是很多团队仍然用最慢的方式验证它：疲惫的工程师在事后逐行阅读一个很大的 diff，并把这种阅读当成控制感。它看起来认真，但往往不如在提示词之前写下五分钟的验收合同。

人工 review 仍然重要，只是位置要前移。人擅长定义行为、边界、权限、失败条件、迁移风险和成功标准；人不擅长在脑中模拟漂亮代码里的所有分支、竞态、状态错误和安全边缘。格式整洁并不等于设计正确。

更好的流程从可验证的工作单开始：目标、范围、禁止改动、验收标准、负面案例、测试命令、隐私规则，以及代理必须停下来询问的条件。“加入 JWT 登录”太含糊；“保留现有哈希服务，拒绝停用用户，轮换 refresh token，测试 replay、rate limit 和审计事件”才是合同。

Anthropic 关于 Claude Code 的材料强调项目上下文、仓库指令和受控执行命令；GitHub Copilot coding agent 文档强调 issue、pull request、日志和人工批准；OpenAI 的 Codex 与 prompting 指南也强调目标、约束和评估。共同点很清楚：代理式编程需要流程，而不只是模型。

阻力来自工程文化。多年里，敲代码和严肃看 PR 是能力的可见标志；写验收标准像文书工作。AI 改变了层级：普通实现变便宜，定义不变量、边界、拒绝条件、最小权限和回滚路径变得更稀缺。

自动化 gate 是这次对话的记忆。模型可能在长会话里忘记要求，失败的测试不会。单元测试、集成测试、类型检查、lint、安全扫描和简短的产品检查表，比“我认真读过每一行”更可靠。

隐私、成本和供应商锁定也要写进合同。助手可能看到仓库上下文、日志或敏感样例。团队需要知道数据保留、训练策略、权限范围，以及是否需要本地工具。结果应能在 CI 中复现，而不是只存在于某个聊天窗口。

这种方法适合已经让 Copilot、Claude Code、Codex 或类似代理处理真实代码的团队，尤其是认证、计费、API、内部自动化和迁移。如果没有测试、staging 和 rollback，第一项 AI 工作应是建立这些护栏。

角色变化并不浪漫，但更接近工程本质。开发者不再做机器的人肉 linter，而是设计系统证明变更的条件。AI 让打字更便宜，也让清晰的约束更重要。

一个有用的团队习惯，是让助手先证明最危险的假设。改动依赖权限规则，就先写会失败的测试；依赖性能，就写基准命令和预算；依赖第三方 API，就写失败 mock、重试规则和降级方案。这样 review 不再靠代码外观寻找信心。

人仍然要读关键部分：架构、可维护性、产品意图和风险。但人不再同时扮演编译器、测试器和安全审计员。机器负责可执行检查，人负责判断检查是否覆盖了真正的问题。

这也能降低成本。模糊会话会消耗更多上下文和更多尝试，而清晰合同让模型少走弯路。即使以后换模型、换供应商或让人接手，ticket、测试和 CI 记录仍然存在。

最小模板可以直接放在 issue 里：目标、范围、禁止事项、验收标准、负面案例、验证命令、review 负责人和 rollback。几周后它会变成团队习惯。新人更快知道哪些任务可以交给代理，哪些必须先做架构讨论；资深工程师也能把精力从格式挑剔转向真正的系统边界。

还有一个现实好处：写清楚 gate 后，失败更早出现。早失败的测试便宜，晚发现的生产事故昂贵。AI 让实现速度上升，如果验证速度不跟上，团队只是更快地制造未知风险。

所以问题不该是“这个模型能不能写代码”。更有用的问题是：“我们是否能描述正确结果，并让工具自动证明它？” 能回答这个问题的团队，才真正拥有 AI 编程流程。

落地不必很重。每个 ticket 先要求两条必须通过的命令、一个负面测试和一句禁止使用的数据说明，就足够开始。之后团队根据事故、bug 和 review 发现的盲点继续补充。gate 不是仪式，而是操作记忆，防止同样的错误被更快的模型重复制造。

管理者也应改变衡量方式。不要只奖励“写了多少代码”或“review 了多少行”，而要看一个变更是否有清楚的成功定义、是否可回滚、是否没有扩大权限、是否能被另一名工程师复现。AI 时代的产能指标如果只看输出量，会鼓励更快的混乱。

对个人开发者来说，这不是降级。写 contract、tests 和 gates 并不比写实现低级。它要求理解用户、系统、失败成本和团队维护能力。模型可以补全函数，但不能替团队承担生产责任。

最后，review 的语言也会改变。以前常问“这段代码写得漂不漂亮”；现在更应该问“这个测试是否真的保护了业务风险”。以前常问“模型有没有听话”；现在更应该问“我们的指令是否足够明确，失败时是否会停止”。这种问题听起来不那么英雄化，却能让团队在速度提升时仍然保持质量。

最危险的状态不是不用 AI，而是把 AI 当成无限实习生，再让资深工程师用眼睛补救一切。那会带来疲惫、延迟和虚假的安全感。真正有效的做法，是让代码、测试、权限和 review 形成闭环。每次变更都留下可执行证据、复现步骤和明确责任，而不是只留下一个看起来很专业却无法验证、也难以交接和长期维护、审计、复盘和追责的对话记录。这个原则同样适用于文档、数据处理和内部自动化。