Claude Code 交付之后 怎样验证真的完成

先把完成标准写出来

一段“已修复并测试”的回复还不足以判断工作是否完成。交付前要能回答：原问题是什么、改了哪里、运行了什么、结果如何、还有什么没有验证。Claude Code 官方最佳实践强调提供测试或其他可检查的标准，并要求结果证据。本文的检查表是独立教学设计。

第一步 对照需求检查行为

假设一个虚构文章站需要修正搜索：输入只含空格时应显示全部文章；有关键词时按约定字段筛选；没有匹配时应显示空结果提示。先逐条写出预期，再核对实现。若需求没有约定大小写、标点或多个关键词的规则，应先确认，不能让测试偷偷定义产品需求。

第二步 分开看三类检查

代码检查关注语法、类型和静态问题；自动测试关注具体输入与断言；浏览器检查关注真实页面的布局与操作。它们提供不同证据。构建成功不能证明按钮可用，单元测试通过也不能证明手机上没有遮挡。根据改动选择必要项目，未做的项目明确写出。

本例可准备一组固定测试文章，并测试空字符串、全空格、中文关键词、无匹配词和重复操作。浏览器中再检查输入与清空后的列表、空状态文字、键盘焦点及窄屏布局。这里列的是测试设计，没有声称已经运行或全部通过。

第三步 索要可以复核的记录

让 Claude 报告执行命令、工作目录、对应版本、开始与结束状态以及关键输出。自动测试应能看见执行数量和失败项，不能只给“绿色通过”的口头总结。涉及截图时，要能对应到测试页面、视口与操作步骤；截图也不能替代无法从画面观察的后台行为。

如果检查运行失败，应区分代码缺陷、环境缺依赖、网络受限和测试本身有问题。不要把环境阻塞改写成通过，也不要随意删除测试。交付记录可以诚实写“构建已通过，浏览器回归尚未执行”，再说明这对上线判断有什么影响。

第四步 审查范围和剩余风险

检查最终差异，确认没有顺带修改权限、删除数据、增加不必要依赖或泄露凭据。核对旧功能是否仍满足关键用例，并记录需要人工确认的部分。测试覆盖有限时，不把“没有发现问题”扩大成“绝对没有问题”。

最终清单：需求逐项有结论；命令与结果可追溯；失败项没有被隐藏；未验证内容可见；恢复步骤清楚；部署目标与当前授权一致。内容包、提交代码、发布预览和替换生产站是不同状态，交付说明应准确写出当前到哪一步。