客户验收清单新手检查清单

交付前最后十分钟，最容易漏掉关键说明。文件发出去了，但没写验证方式；截图给了，但没说未覆盖范围；客户回复“再顺手改一下”，你才发现修改规则从来没说过。验收清单就是为了避免这些小洞变成返工。

这份清单是草稿，适合配合 客户验收清单怎么减少返工、/templates 和 /tools/proposal-generator 使用。它不替代合同，只帮助新手把交付说清楚。

适合谁

适合准备交付网页修改、文案整理、模板调整、报错诊断、小脚本或工具配置的新手。任务越小，越容易觉得不用写说明，结果反而更容易误会。

也适合刚开始建立项目 SOP 的人。每次交付前按同一张清单走，会让客户沟通更稳定。

不适合谁

不适合大型项目、复杂合同、企业级验收、生产运维和安全修复。这些需要更严格的正式流程。

也不适合没有实际验证的交付。没有看到结果、没有运行命令、没有客户确认材料，就不要把清单当成完成证明。

具体步骤

1. 对照原需求，确认本次承诺范围。
2. 核对交付物是否齐全。
3. 记录验证方式和结果。
4. 准备截图、链接或文件说明。
5. 写出未覆盖范围。
6. 标出客户需要确认的事项。
7. 写清修改规则和新增需求处理方式。
8. 保存交付消息和客户反馈。

交付前清单

• 原始需求是否可追溯？
• 本次完成范围是否写清？
• 交付文件或链接是否可打开？
• 截图是否包含关键结果？
• 是否记录命令输出或人工检查结果？
• 是否说明未覆盖范围？
• 是否列出客户待确认项？
• 是否说明修改轮次或新增需求规则？
• 是否去除了客户隐私和敏感信息？

验证记录模板

项目名称：
本次范围：
交付物：
验证方式：
截图位置：
未覆盖范围：
客户待确认：
可包含修改：
新增需求处理：
交付日期：

这个模板可以放在每次交付说明下方。客户不一定需要看所有字段，但你自己要保留完整记录。

常见漏项

最常见的漏项有三个：没有写测试环境、没有写未覆盖范围、没有写客户需要确认什么。客户看到“已完成”时，通常会默认你已经处理了所有相关内容。新手要主动把边界写出来。

另一个漏项是没有留版本记录。交付文件如果后续被客户改过，你需要知道自己交付的是哪一版。可以用日期、文件名或截图编号做简单记录。

客户确认句

可以在交付消息最后加一句：

请按上面的验收项确认本次交付是否符合预期。如果有原范围内遗漏，我会继续补齐；如果是新增功能或新增页面，我们先重新确认范围和时间。

这句话能把“返工”和“新增需求”分开。语气不用强硬，但边界要清楚。

复盘字段

交付结束后，建议补三项复盘：客户是否一次通过、是否出现新增需求、下次清单要补什么。很多新手只记录成交和收款，不记录返工原因，结果下一次又踩同一个坑。

如果客户反复要求新增内容，不要只归因于客户难沟通，也要检查自己一开始有没有写清未覆盖范围。如果没有写清，下次就在验收模板里提前加一句“本次不包含新增页面、长期维护和生产部署”。

什么时候重新确认范围

客户提出的问题如果改变了目标、增加了页面、要求连接新工具、影响生产环境，或者需要你接触新的账号权限，就应该重新确认范围。不要把这些内容塞进“顺手修改”里。

重新确认时可以很简短：“这部分已经超出本次验收范围，我可以先整理新增需求和预计时间，确认后再继续。”这样既不直接拒绝客户，也不会把边界说丢。

风险提醒

不要承诺无限修改。新手为了拿到好评，很容易把小项目做成无底洞。更稳的方式是提前说明哪些属于本轮验收，哪些需要重新确认。

不要把未验证的 AI 结果发给客户。AI 可以辅助写交付说明，但最终验收必须看真实文件、页面、截图、命令或客户确认。

免责声明

本文仅供学习和交付流程参考，不构成法律、合同或平台合规建议。真实项目请根据双方约定、平台规则和客户授权处理。发布前请人工复核模板和示例。

CTA：交付前先用 /templates 保存验收记录；如果要写客户交付消息，可以先用 /tools/proposal-generator 起草，再按本文清单复核。