很多人用 Claude Code 改代码时，最容易卡在最后一步：它说“已经完成”，你也看到了代码变化，但上线前还是不放心。真正的问题不是 Claude Code 会不会写代码，而是你有没有把“完成”的标准说清楚。
如果没有测试验收流程，AI 编程会变成一种看起来很快、实际很容易返工的协作方式。今天这篇不讲复杂理论，只讲一套普通个人站长、小团队也能用的 Claude Code 测试验收流程：先定义边界，再让它执行检查，最后留下可复盘的交付记录。
为什么 Claude Code 改完代码后还要单独验收
Claude Code 很适合处理多文件项目、长上下文和局部重构，但它和人一样，会受到任务描述的影响。你让它“修一下按钮样式”，它可能只关注按钮；你让它“优化发布流程”，它可能改了脚本，却没有检查旧文章、移动端页面或 SEO 输出。
所以验收不是不信任工具，而是把项目质量门槛显式化。老达更建议把 Claude Code 当成一个能执行任务的协作者，而不是一个永远知道项目隐含规则的外包程序员。
如果你还没有搭好基础环境，可以先看 AI编程环境怎么搭；如果你已经在用 Cursor、Codex 或 Claude Code，可以把本文和 AI编程工具专题 里的流程一起用。
第一步：先把“改什么”和“不改什么”写清楚
Claude Code 测试验收的第一步，不是立刻跑测试，而是写清楚任务边界。很多翻车都不是测试没跑，而是一开始就没有说清楚范围。
建议每次开始前给 Claude Code 一段短任务说明，至少包含四项：
- 目标：这次到底要解决什么问题，比如修复登录页报错、优化文章页内链、调整表单校验。
- 范围：允许修改哪些目录、组件、脚本或配置。
- 禁区：不要改数据库结构、不要重命名公共 API、不要顺手重构无关页面。
- 验收标准：哪些命令通过、哪些页面正常、哪些旧功能不能坏。
一个可直接复用的提示词可以这样写：
请先阅读项目规则和相关文件，只修改与本任务直接相关的代码。
目标：修复文章发布后检查脚本对特色图 alt 的识别问题。
范围：tools/wordpress-publisher/scripts 以及必要的测试样例。
不要改：发布脚本的认证逻辑、分类标签配置、已有草稿内容。
验收：给出修改摘要、运行命令、检查结果和仍需人工确认的风险。这类任务说明可以参考我之前写的 AI编程任务说明怎么写。区别在于，今天这篇更强调“改完之后怎么判定可交付”。
第二步：让 Claude Code 先列验收计划
直接让 Claude Code 改代码，通常也能得到结果。但更稳的做法是先让它列一个验收计划，尤其是多文件修改、前端页面、自动化脚本、WordPress 主题这类容易牵连旧功能的任务。
你可以这样要求：
在动手修改前，请先输出验收计划。
计划里要包含：
1. 需要阅读的关键文件；
2. 可能受影响的旧功能；
3. 修改完成后要运行的命令；
4. 需要人工打开页面确认的地方；
5. 如果测试环境缺少依赖，如何降级验证。这一步的价值，是让 Claude Code 在写代码前先暴露自己的判断。你可以很快看出它有没有漏掉关键文件、有没有误解任务目标。对于复杂任务，也可以结合 Claude Code Plan Mode，先规划再执行。
第三步：把测试命令写成固定清单
很多项目不是没有测试，而是测试入口分散：前端有 lint，后端有单元测试，WordPress 脚本有 dry-run，页面还要手动打开。每次临时想一遍，AI 和人都会漏。
建议在项目规则或任务说明里维护一份最小测试清单：
- 静态检查：例如
npm run lint、npm run typecheck、格式化检查。 - 单元测试：例如
npm test、pytest或项目里的专用测试命令。 - 构建检查：例如
npm run build，确认改动不会破坏生产构建。 - 脚本 dry-run：发布、同步、清理类脚本先用 dry-run 看 payload。
- 页面验收：打开关键页面，检查按钮、表单、图片、meta、移动端布局。
如果项目还没有自动化测试，也不要跳过验收。可以先让 Claude Code 补一个“人工可执行检查表”，比如哪些页面要打开、哪些输入要测试、哪些边界值要看。更完整的自动化思路，可以看 AI编程测试自动化怎么做。
第四步：页面和交互必须单独检查
Claude Code 改前端页面、WordPress 主题或内容发布流程时，命令通过并不等于用户看到的页面正常。尤其是样式、图片、移动端布局、SEO meta、表单交互，很多问题只有打开页面才明显。
对于页面类任务，我建议至少检查四类结果：
- 首屏：标题、图片、按钮、主要内容是否正常显示，没有遮挡和溢出。
- 交互：按钮、表单、搜索、筛选、复制、下载等动作是否可用。
- 结构：标题层级、内链、alt、meta description 是否符合项目规则。
- 移动端：导航、卡片、表格、代码块是否能正常阅读。
如果你在本地有浏览器自动化能力，可以让 Claude Code 调用浏览器打开页面、截图或检查 DOM。相关做法可以参考 MCP浏览器自动化怎么用。
第五步：让它输出“证据”，不要只输出总结
AI 编程最常见的低质量交付话术是：“已完成修改并通过测试。”这句话听起来完整，但对接手的人帮助不大。你需要的是证据，而不是一句结果。
建议让 Claude Code 在收尾时固定输出：
- 改了哪些文件，每个文件解决什么问题；
- 运行了哪些命令，结果是通过、失败还是未能运行；
- 哪些检查是自动完成的，哪些仍需人工确认；
- 是否存在兼容性、数据迁移、权限、性能或回滚风险；
- 如果要继续优化，下一步最值得做什么。
这一步能明显减少“看不懂 AI 到底做了什么”的问题。尤其是多人协作时，交付记录比一句“完成了”更重要。
一个 Claude Code 测试验收提示词模板
下面这段可以直接放到你的项目里，作为每次改代码后的收尾提示：
请对本次修改做交付前验收：
1. 检查是否只修改了任务相关文件；
2. 运行项目中合适的 lint、test、build 或 dry-run 命令；
3. 如果无法运行某个命令，说明原因，不要假装通过；
4. 对用户可见页面列出需要人工确认的检查项；
5. 输出修改摘要、验证结果、风险和后续建议；
6. 不要用“应该没问题”代替具体证据。如果是前端页面，可以再加一句：“请重点检查桌面端和移动端是否有遮挡、溢出、按钮不可点、图片比例异常。”这和 AI编程前端页面怎么验收 的思路是一致的。
哪些场景最需要严格验收
并不是每次改动都要跑完整流程。改一个文案、补一个注释，可以轻一点。但下面几类任务，建议不要省：
- 发布流程：会影响文章、图片、标签、SEO meta 或自动发布脚本。
- 登录和权限：涉及账号、后台、API Key、文件读写或服务器权限。
- 支付和表单：涉及订单、线索、客户信息、通知或提交成功状态。
- 公共组件：一个按钮、卡片、布局组件可能影响很多页面。
- 自动化任务：定时任务、批量脚本、Webhook 和 Agent 工作流都要防止重复执行。
这些任务一旦出错，损失往往不是“页面丑一点”，而是数据错、客户漏、内容重复、权限暴露。所以宁愿多花十分钟验收，也不要让 AI 带着隐患上线。
老达点评
Claude Code 的强项不是“替你省掉所有判断”，而是把原来需要你手动阅读、修改、运行、记录的流程压缩成一次协作。真正能拉开差距的，不是谁更会写一句神奇提示词，而是谁能把自己的项目质量标准写成可执行流程。
我的建议很简单：从今天开始，不要再接受“已完成”这种空泛交付。让 Claude Code 告诉你它改了什么、跑了什么、没跑什么、哪里需要人工看。这样 AI 编程才不是碰运气，而是逐步变成可交付的生产流程。
