项目交付检查清单应该包含什么：新手检查清单

交付前最后一遍检查，是为了避免“感觉完成了”变成“证据不足”。新手尤其要区分已完成、已验证、待客户确认和不在范围内。

这篇仍是草稿。发布前需要人工补充交付样例和平台规则核对。

适合谁

适合已经准备把结果发给客户、但还没确认说明是否清楚的新手。无论是文案、页面、CSS、报错还是部署前诊断，都可以用这份清单。

也适合把 AI 输出转成客户可读交付说明的人。AI 写得顺不代表证据齐全。

不适合谁

不适合还没运行检查、没截图、没确认范围就准备收尾的人。也不适合高风险生产项目的简化交付。

如果涉及敏感账号、真实用户数据、支付、数据库或安全问题，必须升级复核。

检查清单

逐项确认：

1. 是否复述了客户原始需求。
2. 是否列出本次完成范围。
3. 是否列出未包含范围。
4. 是否说明修改文件或交付物。
5. 是否运行验证命令。
6. 是否有截图、预览链接或日志。
7. 是否写清客户要确认什么。
8. 是否删除敏感信息。
9. 是否说明未验证事项。
10. 是否保留内部记录。

具体步骤

1. 先看原始需求，确认没有漏交。
2. 再看文件改动，确认没有无关改动。
3. 把命令输出和截图放到交付记录里。
4. 写清不包含范围。
5. 检查所有链接是否能打开。
6. 遮盖截图中的账号、邮箱、token、订单和客户名称。
7. 发出前读一遍，删掉无法证明的承诺。

可复制清单

交付前复核

原始需求：已确认 / 未确认
完成范围：已写清 / 未写清
未包含范围：已写清 / 未写清
验证命令：已运行 / 未运行
截图或链接：已有 / 没有
客户确认问题：已有 / 没有
敏感信息检查：通过 / 待处理
是否可以交付：是 / 否

这份清单不是给客户看的全部内容，而是你发出前的刹车。

常见错误

第一个错误是只写 “done”。第二个错误是把构建通过写成所有流程通过。第三个错误是没有写未包含范围。第四个错误是截图里泄漏客户信息。

更稳的交付说明会承认限制。比如“本地构建已通过，生产环境需要客户确认发布”，这比假装全部完成更专业。

怎么处理新增需求

交付前如果客户突然补一句“顺便再改一下别的页面”，不要直接塞进当前交付。先判断它是不是原范围的一部分。如果不是，就写成新增需求：需要重新确认目标、材料、时间和报价。

新手容易因为不好意思拒绝，把新增需求当作小事顺手做。短期看像是配合，长期会让项目范围越来越模糊。清单里写“新增需求处理方式”，就是为了提醒自己把善意和边界同时保住。

交付质量分层

最低合格交付，是客户能看到结果并知道你做了什么。更好的交付，是客户还能看到验证证据、未包含范围和下一步建议。对新手来说，先追求“更好的交付”，不要只追求“快点发出去”。

如果清单里缺截图，客户可能不知道结果在哪里；如果缺命令，客户不知道你是否验证；如果缺未包含范围，客户可能默认你负责更多。每一项缺失都可能变成后续沟通成本。

检查清单最后要有一句明确判断：可以交付、需要补证据、需要客户确认、暂缓。不要让自己在模糊状态里点发送。

风险提醒

不要提交客户隐私、密钥、后台截图和无关文件。不要把客户未确认的事项写成完成。不要绕开平台沟通和交付流程。

需要客户注册、登录、授权、确认生产发布或补充账号的事项，记录为明日待办。

明日待办

• 做一份匿名交付截图样例。
• 检查交付模板是否适配不同任务类型。
• 人工核对平台规则。
• 把清单整理进模板下载页。

可以继续看的内容

• 模板下载
• 项目报价助手
• 报错解释器

免责声明

本文仅供学习和交付复核参考，不构成法律、财务或职业建议。真实项目交付需要结合客户授权、平台规则和人工判断。

CTA：你可以先用 模板下载 做交付前复核，再用 项目报价助手 判断新增需求是否应该另算范围。