AI 编程工具越来越会改代码，但“能改”不等于“能交付”。Cursor、Claude Code、Codex 都可以帮你读文件、写代码、补测试、跑命令，可最后要不要上线，仍然需要一个明确的验收清单。
很多项目的问题不是 AI 不够聪明，而是人没有告诉它什么叫完成。任务说明写的是“帮我优化页面”，实际验收时却要看移动端、SEO、数据兼容、旧功能不坏、能回滚。标准没有提前写清楚，AI 改得越多，后面越难收口。
如果你已经看过 AI编程工具专题 里的任务拆解、调试、测试、版本管理文章，本文可以当作最后一环：改完之后，怎样判断这次 AI 编程结果可以交付。更多站长和内容项目里的真实用法，也可以放到 老达AI实践专题 里对照理解。
为什么 AI 编程更需要验收清单
传统开发也需要验收，但 AI 编程更依赖清单，原因有三个。
第一，AI 很容易只优化当前指令。你让它修一个按钮，它可能改了组件样式，却没有检查同组件在其他页面的复用。你让它提升文章页 SEO，它可能补了 meta，却忘了分类页、专题页或移动端导航。
第二，AI 改代码的速度很快，人工阅读容易跟不上。一次任务里可能涉及多个文件、样式、脚本和配置，如果没有固定检查项，最后只能凭感觉看一遍。
第三，AI 工具之间的能力边界不同。Cursor 适合在编辑器里快速修改，Claude Code 适合项目内执行和分工，Codex 适合把跨文件任务、命令验证和交付说明串起来。工具不同，但验收标准应该一致。
所以，AI 编程验收清单不是额外负担，而是把“AI 帮我改了”变成“这个改动可以上线”的桥梁。
一份合格验收清单包含什么
老达建议把 AI 编程验收拆成七块：
- 目标是否完成：这次任务最核心的用户结果是否已经出现。
- 影响范围是否清楚：改了哪些文件、哪些页面、哪些接口。
- 测试是否跑过：自动测试、构建、静态检查或手动验证。
- 旧功能是否回归：相关入口、边界条件、历史数据是否还正常。
- 异常和权限是否处理：空数据、失败请求、登录态、危险操作是否有保护。
- 上线和回滚是否可执行：出了问题知道撤回哪一步。
- 交接记录是否清楚：别人能看懂这次改动和剩余风险。
这七块不一定每次都写得很长，但每次都要过一遍。小任务可以压缩成 5 行，大任务可以展开成详细 checklist。
先验收目标，不要先看代码漂不漂亮
AI 编程最容易让人分心：它会生成很完整的解释，也可能顺手重构一些代码。但验收第一步永远是目标。
例如任务是“修复 WordPress 文章页特色图 alt 不显示”，验收目标就不是“代码更优雅”，而是：
- 打开文章页能看到特色图。
- HTML 里特色图存在清晰 alt。
- 没有正文里的重复 h1。
- 移动端文章头图不溢出。
- 旧文章和新文章都能正常显示。
代码质量当然重要，但如果用户结果没有出现，其他优化都只是旁枝。你可以把目标验收写进任务开头，让 AI 在最终回复里逐项说明是否完成。
这部分和 AI编程任务说明怎么写 是配套的：任务说明负责开始前讲清楚，验收清单负责结束时逐项对账。
第二步：让 AI 交代影响范围
AI 改完代码后，不要只问“完成了吗”。更好的问法是：
请列出本次修改涉及的文件、每个文件承担的变化、可能受影响的页面或流程，以及你没有修改但需要人工注意的地方。
这个问题能逼 AI 从“写代码模式”切换到“交付模式”。如果它只回答“已完成优化”，说明上下文还不够；如果它能说清楚改了组件、样式、接口、测试和配置，你再进入下一步验收。
对于 Cursor、Claude Code、Codex 这类工具，影响范围最好包含三类信息：
- 文件范围：新增、修改、删除了哪些文件。
- 行为范围：用户能感知到什么变化。
- 风险范围：哪些地方可能受牵连。
如果项目使用 Git，还要看 diff，而不是只看 AI 总结。相关流程可以参考 AI编程版本管理怎么做。
第三步：测试不是只有自动测试
很多个人项目没有完整测试套件，这不代表不能验收。AI 编程里的测试可以分三层。
第一层是机器能跑的检查，例如单元测试、构建、类型检查、lint、脚本 dry-run。只要项目里有这些命令，就应该让 AI 跑，并把结果写出来。
第二层是页面或流程验证。例如打开本地页面、提交表单、检查按钮、抓取 HTML、确认 meta、查看接口返回。前端和 WordPress 项目尤其需要这一层。
第三层是人工判断。例如文案是否自然、布局是否符合品牌、业务规则是否合理、客户能否理解。这部分 AI 可以辅助列清单，但不能完全替你拍板。
如果你还没有测试习惯，可以先看 AI编程测试怎么做。验收清单不是替代测试，而是把测试结果纳入最终交付判断。
第四步：回归旧功能
AI 编程最隐蔽的风险，是修好了 A，顺手影响了 B。验收清单必须包含回归项。
举个例子，你让 AI 优化博客发布脚本，不能只验收“新文章发布成功”，还要检查：
- 摘要是否仍能写入 WordPress。
- SEO description 是否来自摘要。
- keywords 是否由标签输出。
- 特色图是否上传并设置 alt。
- 正文是否没有 h1。
- 站内链接数量是否符合要求。
这些不是额外要求，而是旧流程已经存在的质量门槛。每个项目都应该有自己的“不能坏清单”。老达AI博客的发布流程就把摘要、SEO meta、图片、内链和发布后检查写成固定规则，这比每次临时提醒 AI 稳定得多。
第五步：检查异常、权限和数据
AI 生成代码时，常常默认一切顺利：接口一定返回数据、用户一定有权限、文件一定存在、网络一定正常。上线验收不能这样。
至少要问四个问题：
- 空数据时页面或脚本会怎样？
- 接口失败、超时或返回格式变化时会怎样？
- 用户没有权限时会不会暴露敏感信息？
- 任务执行一半失败时，是否会留下脏数据？
如果涉及 MCP、浏览器、数据库、服务器或 WordPress 后台，更要检查权限边界。可以参考 MCP 权限安全检查清单，它的思路同样适合 AI 编程：先只读、再写入、重要动作保留人工确认。
第六步：给回滚留入口
能上线的改动，应该能回滚。AI 编程验收时，至少要知道：
- 这次改动是否有独立提交或清晰 diff。
- 是否修改了数据库、远程配置或第三方服务。
- 回滚代码是否足够，还是还要恢复数据。
- 如果只想撤销部分变化，应该从哪里改。
对于个人站长和内容项目，最实用的做法是小步提交。一次任务只解决一个明确问题，验收通过再进入下一步。不要让 AI 同时改主题、改脚本、写文章、清标签、调服务器，最后很难判断问题来自哪里。
第七步：让最终回复可交接
AI 完成任务后的最终回复，最好固定成四段：
- 做了什么：用普通人能看懂的话说明结果。
- 改了哪里：列出关键文件或模块。
- 怎么验证：写出跑过的命令、检查过的页面和结果。
- 还有什么风险：说明未跑的测试、依赖人工判断的地方。
这比“已完成，请检查”有用得多。尤其是团队协作时，后一个人不一定知道你和 AI 刚才聊了什么，交接记录就是未来排查问题的入口。相关代码审查流程可以继续看 AI代码审查怎么做。
可以直接复用的 AI 编程验收提示词
你可以把下面这段放进 Cursor、Claude Code 或 Codex 的任务结尾：
请按验收清单检查本次改动：1. 核心目标是否完成；2. 涉及哪些文件和用户流程；3. 已运行哪些测试或检查，结果是什么；4. 相关旧功能是否回归；5. 异常、权限、空数据是否处理；6. 是否具备回滚方式；7. 还有哪些未验证风险。回答要具体，不要只说“已完成”。
如果是前端页面，再追加：
请打开桌面和移动端视口检查布局，确认文字不重叠、按钮不溢出、主要交互可用、图片正常加载，并说明截图或浏览器检查结果。
如果是 WordPress 或 SEO 任务，再追加：
请检查页面 title、meta description、meta keywords、特色图 alt、正文 h1、站内链接数量、分类标签和摘要是否符合项目规则。
老达建议：把验收清单写进项目规则
AI 编程验收清单最好的位置，不是临时聊天记录，而是项目规则文件。Cursor 可以放在规则里，Claude Code 可以放在项目记忆里，Codex 可以放在 AGENTS.md 或 Skill 工作流里。这样每次任务都会自动继承同一套标准。
当你开始用 AI 编程做真实项目，不要只追求“写得快”。更重要的是每次改动都能说清楚：为什么改、改了哪里、怎么验证、如何回滚。能回答这些问题，AI 编程才真正从工具体验走向项目交付。
最后，把验收清单当成你和 AI 之间的合同。AI 负责执行和解释，人负责设定标准和最终判断。这个分工清楚了，Cursor、Claude Code、Codex 才会越来越像可靠的项目助手，而不是只会快速生成代码的聊天窗口。
