用 Claude Code 项目后交付说明怎么写

用 Claude Code 辅助完成代码小单后，交付说明不能只写“已经修好了”。客户需要知道你改了什么、怎么验证、哪些内容没有动、接下来该如何验收。交付说明写得清楚，才不会让一个小修复变成无边界返工。

这篇适合搭配 Claude Code 常用命令检查清单、Claude Code 项目客户问题检查清单、/tools/proposal-generator 和 /templates 使用。

适合谁

适合已经用 Claude Code 完成 bug 排查、页面小改、配置修复、构建问题诊断的新手。你可能能把问题修掉，但还不知道怎么把结果写成客户能验收的说明。

也适合做诊断单的人。有些任务最终没有进入修复阶段，但你仍然需要交付诊断记录、可能原因和下一步材料。

不适合谁

不适合没有验证就直接交付的任务。Claude Code 给出修改建议，不等于结果已经被验证。至少要说明运行过哪些检查，哪些检查没有条件运行。

也不适合把生产部署、真实数据、账号权限和长期维护默认写进交付范围。客户小单的边界要在说明里再次确认。

具体步骤

第一，写问题回顾。用一两句话复述客户最初的问题，不要写成泛泛的“项目报错”。例如“保存按钮点击后接口返回 500，客户希望确认原因并修复前端参数传递”。

第二，写处理内容。列出你实际改了哪些文件、配置或文案。不要贴大段代码，客户需要的是可读摘要。

第三，写验证方式。说明你运行了 lint、test、build、本地预览或手动流程检查中的哪些项。失败项也要写清楚原因。

第四，写未覆盖范围。比如没有处理生产部署、没有接触真实数据、没有修改数据库、没有新增功能、没有长期维护承诺。

第五，写客户验收动作。告诉客户该在哪个页面、用什么测试数据、看到什么结果才算完成。没有验收动作的交付，后面很容易争议。

第六，写后续建议。只写必要的下一步，不要顺手承诺额外工作。后续需求应该重新确认范围。

可复制交付模板

本次处理：
- 问题：
- 修改：
- 验证：
- 未覆盖：
- 请你验收：
- 后续建议：

把这份模板交给 Claude Code 前，可以先让它根据 git diff 和测试输出生成初稿，再由你人工删掉不适合客户看的技术细节。

怎么写得像交付而不是聊天

交付说明要短，但不能空。好的写法是“已处理保存按钮参数问题，并在本地运行 build 通过；未执行生产部署；请在测试环境用订单草稿数据验收保存流程”。这比“好了你看看”更专业。

如果任务只是诊断，也可以写：“本次未修改代码，已确认错误来自缺失测试环境变量；需要客户补充测试配置后再判断是否进入修复。”诊断不是失败，只要边界写清楚，就是有效交付。

验收证据怎么准备

交付前最好准备三类证据：修改证据、验证证据、限制证据。修改证据可以是文件列表或简短 diff 摘要；验证证据可以是 build、lint、测试或手动流程结果；限制证据则说明哪些环境和数据没有接触。

证据不一定全部发给客户，但你自己要能回看。客户后续追问时，你可以快速回答“本次验证过什么，没验证什么”。这比临时翻聊天记录可靠。

复盘怎么写进笔记

每次交付后，把客户是否顺利验收也写进笔记。如果客户一看就通过，说明交付说明足够清楚；如果客户反复追问，说明你的验收动作或未覆盖范围还不够具体。

这份复盘会反过来改进下一次报价。你会越来越清楚哪些内容必须提前问，哪些结果必须交付时写明。

风险提醒

不要把完整日志、密钥片段、后台链接或真实用户资料写进交付说明。需要证明问题时，用脱敏摘要。

不要把 Claude Code 的技术总结原样发给客户。工具可能写得很长，也可能包含客户不需要的内部推理。交付说明要面向验收，而不是面向炫技。

免责声明

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

CTA：交付前先用 /templates 补齐说明结构；需要写客户回复时，用 /tools/proposal-generator 起草后人工复核。