Claude Code 交付说明常见错误

很多新手用 Claude Code 修完问题后，最后一步反而掉链子：交付说明只写“已修好”。客户不知道你改了哪里、怎么验证、还有什么没做，后面很容易要求继续改。交付说明不是客套话，它是保护工作边界的证据。

这篇适合搭配 Claude Code 交付说明检查清单 和 Claude Code 常用命令检查清单 使用。

适合谁

适合已经能用 Claude Code 做小范围修复，但交付时经常被客户追问“所以现在我该怎么看”的新手。

也适合做诊断单的人。诊断交付如果写不清，客户会误以为你没有完成工作。

不适合谁

不适合没有检查结果还想包装成交付完成的任务。没有验证，就必须如实说明验证限制。

也不适合高风险正式交付。涉及安全事故、生产数据、付款系统、账号权限时，需要更严谨的审批和记录。

具体步骤

错误一：只写“已修好”。修正方式是写清问题、修改、验证、未覆盖和验收动作。

错误二：不写验证。客户无法判断你是运行过检查，还是只看了代码。至少写出关键命令或手动检查结果。

错误三：不写未覆盖范围。你没有处理部署、数据库、真实数据、长期维护，就要明确写出来。

错误四：把 Claude Code 总结原样发给客户。工具总结可能太长、太技术化，也可能包含客户不需要看的推理。

错误五：暴露敏感信息。日志、路径、内部链接、账号、token 片段都要脱敏。

错误六：把诊断写得像完整修复。诊断交付要说明“本次未修改代码”或“本次只定位原因”，避免客户误解。

修正模板

本次处理了：
验证方式：
目前结果：
未覆盖内容：
请你这样验收：

这五行比“好了”更稳，也比一大段技术解释更容易让客户行动。

怎么避免返工误解

交付说明里要把“本次范围”写成可检查的句子。例如：“本次只处理登录页按钮点击后无响应的问题，不包含账号权限配置和生产发布。”客户如果后续提出账号权限问题，你就有依据重新确认范围。

同时，验收动作要具体。不要写“你看一下”，而是写“请在测试环境打开登录页，输入测试账号，点击按钮后确认跳转到控制台”。越具体，越少扯皮。

复盘问题

每次交付后，如果客户继续追问，回看交付说明缺了哪一项。是没写验证？没写未覆盖？没写验收动作？把漏项加入下一次模板。

Claude Code 可以帮你把 git diff 和测试输出整理成初稿，但你要负责把初稿改成客户能读懂、能验收、不过度承诺的版本。

交付说明改写示例

不推荐写：“已经修好了，你看一下。”这句话没有证据，也没有边界。

更稳的写法是：“本次处理了登录页按钮点击无响应的问题，修改了按钮提交逻辑；已在本地运行 build 通过；未执行生产部署，也未处理账号权限配置；请在测试环境使用测试账号确认点击后能进入控制台。”

这段话看起来更长，但它减少了后续来回确认。客户知道怎么验收，你也保留了范围边界。

什么时候暂停发送

如果你无法说明验证结果，先不要急着发最终交付。可以先发“当前进度说明”，明确还缺什么条件。比如缺测试账号、缺环境变量、缺客户确认的验收路径。

暂停不是拖慢，而是避免把半确认结果包装成完成。小单最怕的不是晚一点交付，而是交付后双方理解不同。

风险提醒

不要为了显得服务好，把后续所有问题都写成“可以继续帮你处理”。后续需求应该重新确认范围。

不要隐藏验证限制。无法运行测试、缺少账号、缺少环境变量，都应该写出来。

免责声明

本文仅供学习和项目流程参考，不构成安全、法律、财务或平台合规建议。Claude Code 功能、项目规则和客户验收要求可能变化，发布前需要人工复核。项目前请确认授权、脱敏、测试环境和交付边界。

CTA：发送前用 交付说明检查清单 复核；需要客户版措辞时，用 /tools/proposal-generator 起草后人工修改。