如何约定交付文档与交接，避免只给源码就走？

Question

Accepted Answer

结论：不要只在合同写“交付源码”。应附一份可勾选的交付物清单，覆盖代码与制品、数据、账号、配置与密钥、架构接口、部署运维、测试验收和第三方许可；尾款前由客户或新团队实际完成一次构建、部署、备份恢复和核心流程验证。

源码只是系统的一部分。缺少数据库、对象文件、环境配置、证书、第三方账号、部署脚本和业务规则，源码仓库可能根本无法运行。真正的交接标准，是一个没有参与原开发的人能依照材料，在约定环境恢复系统并完成核心操作。

在约定交付物、接管方式与责任边界时，还可以对照定制开发合同里，我该重点确认哪些条款才能少踩坑？；这些内容补充了需要放在同一项决策中考虑的上下文。

交付物清单直接对比

类别	最低交付内容	验收动作	常见遗漏
代码与制品	完整仓库、分支/tag、依赖锁、构建产物、许可证清单	从干净环境构建指定版本	只有压缩包、缺历史和私有依赖
数据	schema、字段字典、迁移脚本、备份与文件目录	恢复脱敏备份并核对核心数据	只交数据库，不交对象存储
账号资源	云、域名、证书、商店、支付、短信、邮件等管理员与归属	客户登录、检查权限并轮换凭证	资源挂在乙方个人或公司账号
架构与接口	架构图、服务清单、API、回调、错误码和外部依赖	调通关键接口与失败场景	只给在线 API 页面，服务停后失效
部署运维	环境、配置项、流水线、发布、回滚、监控、备份和故障手册	部署、回滚、恢复与告警演练	密钥散在群聊、流程靠口头记忆
产品与测试	PRD/原型、权限矩阵、业务规则、测试与已知问题	按核心场景 UAT	只有页面截图，没有状态与规则

在 SOW 或附件中逐项写名称、格式、版本、交付时间、验收人和通过条件。说明哪些源码归客户、哪些是第三方或滚水科技既有组件、客户获得何种使用和修改权；列出商业 SDK、开源许可证、订阅和续费责任。不要用“相关文档”“全套资料”这类无法验收的词代替明细。

账号原则上从立项起建在客户主体下，开发方通过子账号协作。若暂由乙方托管，合同写明迁移日期、数据导出、费用、停机、删除和退出协助。密钥不直接贴在普通文档或聊天记录中，使用密码管理或安全渠道交付；交接后轮换原团队接触过的生产凭证。

预交接可在上线前或里程碑末开始，客户先收到文档草稿并提出缺口；正式交接由开发人员演示架构、发布、监控、数据恢复和常见故障，客户技术人员亲自操作；保障期内处理原范围缺陷和交接疑问，并把新发现补回文档。新增功能、环境迁移或长期代运维属于新的服务范围，不应与质保混淆。

选择与生产相近但隔离的环境，由客户或未参与原项目的人员执行：拉取指定 tag、准备配置、构建部署、导入脱敏数据、访问核心流程、触发一条告警、做一次应用回滚和数据恢复。记录耗时、失败原因和缺失材料，整改后复验。若合同约定客户无技术团队，则可指定第三方或采用录屏加远程操作，但不能只听开发方口头讲解。

滚水科技会依据项目规模提供相应交付深度，并在透明交付标准中公开资产边界。小程序和普通网站与复杂 IoT、支付系统的文档量不同，但账号归属、可构建代码、数据恢复和部署说明这些底线不能省。

具体知识产权、许可证和质保责任以双方合同为准，必要时由法律顾问审阅。