HANDOVER CHECKLIST / 项目交付
上线之前，把系统可接管所需材料逐项交清
交付不等于发送一个代码压缩包。真正可接管的系统需要说明代码对应的版本、怎样构建和部署、账号由谁持有、哪些组件受许可限制，以及上线时仍有哪些已知问题。
SCOPE / 项目范围
理解方法的适用要点。
- 01代码与版本
仓库、分支、提交版本、构建方式和第三方依赖保持对应。
- 02设计与测试
原型、设计源文件、验收脚本、测试记录和未通过项可追踪。
- 03部署与数据
环境结构、发布步骤、备份恢复、迁移记录和回滚方式写清楚。
- 04账号与限制
域名、云资源、应用商店、接口账号、许可证和已知问题明确归属。
DECISIONS / 关键判断
结合当前任务，核对关键判断。
交付物对应上线版本
避免代码、文档和生产环境分别停在不同时间点。
敏感信息安全移交
密钥和密码通过约定的安全渠道交付，不放进普通文档。
遗留问题公开确认
区分缺陷、已接受限制和后续需求，并记录处理决定。
WORKED EXAMPLE / 填写示例
交付核对时，不只问“有没有”，还要问“能否接管”
示例：一套小程序、管理后台和接口服务准备转入正式运维。
生产版本对应明确提交，构建产物可以从该版本重复生成。
新负责人能在预发布环境完成一次部署、健康检查与回滚。
域名、云资源、小程序、支付和消息账号均由约定主体控制。
已知限制、观察项和后续需求分别记录，不混入已完成范围。
- 01按系统组件建立交付目录
- 02在预发布环境完成接管演练
- 03双方确认版本、账号与遗留事项
BOUNDARY / 项目说明
清单帮助确认可接管性，具体权属仍以合同和许可为准。
FAQ / 常见问题
怎样确认系统已经完成移交
拿到源代码就算完成交付了吗？
不算。还要确认对应版本、依赖、构建部署方法、环境配置边界以及必要的设计和测试材料。
账号和密钥应该放进交付清单吗？
清单应记录账号用途、归属和交接状态；实际密码与密钥应通过受控渠道传递，不直接写在普通表格中。
NEXT / 继续了解
从相关服务、案例或资料继续判断。
可复制的源码与部署交接清单
可直接阅读下表，再复制空白模板填写。填写示例仅用于解释方法，不是真实客户案例、报价、合同条款或交付承诺；实际范围与责任由双方确认。
窄屏下可左右滑动表格，查看完整填写示例。
| 记录项 | 怎样填写 | 填写示例 |
|---|---|---|
| 源码与版本 | 仓库访问、发布版本、构建命令、依赖锁定 | 在接收方环境验证构建；仅收到压缩包不算完成核对 |
| 环境与配置 | 运行时、配置项说明、密钥交接方式 | 文档写配置项用途，密码通过独立安全渠道交接 |
| 数据与恢复 | 结构、迁移、备份、恢复步骤及演练结果 | 在隔离环境恢复备份，记录结果，不直接试生产数据 |
| 账号与外部许可 | 域名、服务器、第三方账号与许可归属 | 逐项确认接收人；第三方授权不因源码交付自动转移 |
| 设计与测试 | 原型、设计源文件、业务脚本、已知限制 | 按合同逐项勾选已收到、待补或不适用及理由 |
| 上线与维护 | 操作人、回退条件、质保边界和联系渠道 | 缺陷修复、功能迭代与运维分列，不承诺无限维护 |
在上方文本框中全选复制，粘贴到你的文档后填写；无需登录或提交联系方式。
PROJECT CONTEXT / 项目沟通
先说明实际情况，再讨论适合的范围。
不用先整理完整需求文档，说明当前做法、使用角色和首期目标即可；预算暂不确定时，也可以先沟通范围。