Claude Code 交付说明检查清单

交付说明是代码小单的最后一道边界。你用 Claude Code 改完文件、跑完命令后，仍然需要把结果整理成客户能验收的语言。否则客户只看到“已修好”，很难判断你到底做了什么。

建议先读 用 Claude Code 项目后交付说明怎么写，再搭配 Claude Code 常用命令检查清单 和 /templates 使用。

适合谁

适合已经完成小范围修复或诊断，准备发最终消息给客户的新手。你需要在发送前确认说明是否完整、清楚、可验收。

也适合团队内部复核草稿。即使是一个人项目，也可以用清单模拟一次“交付前复核”。

不适合谁

不适合没有任何验证结果的任务。如果你没法运行检查，要在说明里写“未验证”和原因，而不是把未验证包装成完成。

也不适合需要正式安全、法务或运维审批的高风险交付。这类任务需要更严格流程，不是普通小单说明能覆盖。

具体步骤

1. 是否复述了客户原始问题？不要让客户猜你处理的是哪一个需求。
2. 是否写清修改摘要？列文件、配置、页面或流程，不要只写“优化了代码”。
3. 是否写清验证方式？lint、test、build、本地预览、手动流程分别说明。
4. 是否写清验证结果？通过、失败、未运行都要有原因。
5. 是否写清未覆盖范围？部署、数据、账号、长期维护、新增功能不要默认包含。
6. 是否写清客户验收动作？客户应在哪看、用什么数据、看到什么结果。
7. 是否去掉敏感信息？日志、路径、内部链接、账号和 token 片段要脱敏。
8. 是否避免过度承诺？说明已经完成本次范围，不要暗示所有未来问题都包含。
9. 是否保留下一步建议？只写一到两条必要建议。
10. 是否适合客户阅读？不要直接发送 Claude Code 的长推理。

交付消息模板

本次已完成：
- 处理问题：
- 修改摘要：
- 验证结果：
- 未覆盖范围：
- 请按以下方式验收：
- 后续建议：

如果你是诊断交付，可以把“本次已完成”改成“本次诊断结果”，并明确是否修改了代码。

发送前自查

发送前读一遍，看客户能不能回答三个问题：你做了什么？我怎么确认？还有什么没有做？如果这三个问题不清楚，就继续改说明。

还要检查语气。交付说明应该稳定、具体、克制，不要把工具能力写成夸张承诺，也不要把客户不需要的技术细节堆进去。

证据怎么留

交付前可以保留脱敏截图、命令输出摘要、测试数据说明和修改文件列表。证据不一定都发给客户，但你自己要能回看。

如果客户后续提出返工，先对照交付说明判断是否属于本次范围。属于就处理，不属于就重新确认新需求和报价。

交付前最后一遍

最后一遍检查时，把交付说明当成客户唯一能看到的上下文。客户不一定记得前面聊过什么，也不一定懂你的技术过程。说明里必须能独立回答“这次交付对应哪个问题”。

如果说明里出现“应该、可能、差不多、你再试试”这类含糊表达，要改成可验证动作。比如“请打开测试环境订单页，使用测试订单编号提交，确认状态变为已保存”。具体动作越清楚，验收越快。

复盘记录字段

客户是否一次验收：
客户追问了什么：
是否属于本次范围：
下次模板要补充什么：

这几项能帮你把交付能力慢慢沉淀下来。项目不是只靠工具速度，也靠每次交付后的复盘。

风险提醒

不要把未验证内容写成已完成。没有测试条件时，要明确写出限制。

不要在交付说明里暴露客户隐私材料。需要说明时，用“测试账号”“脱敏日志”“预览环境”这类泛化表达。

免责声明

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

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