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

只交源码不交文档，后续维护基本等于黑盒拆弹。建议在合同里把交付物清单、账号资源移交、交接节点和验收标准写死，并由双方在交接会上逐项过一遍，签字确认后再结项。滚水科技通常会把这块在签合同前就摆到桌面，避免上线后扯皮。

我们一般把交付物分成四类，在合同附件里逐项列清楚：

• 代码与制品：源码仓库地址（含分支策略说明）、构建产物、依赖清单、第三方 SDK 与授权证书、Docker 镜像或部署包。
• 文档：需求与原型存档、接口文档（含示例和错误码）、数据库 ER 图与字段说明、部署架构图、运维手册、常见故障排查手册。复杂项目还会加一份"二次开发指南"。
• 账号与资源：服务器/云资源、域名、SSL 证书、CDN、对象存储、数据库、各平台开发者账号（苹果、Google、微信小程序、商户号等）、第三方 API Key 的所有权与移交清单。
• 数据：测试账号、种子数据、历史数据迁移脚本、备份策略说明。

交接流程上，我们一般会安排三个节点：一是预交接（上线前一两周），把文档初稿发给客户的运维或技术对接人，提前看是否能照着跑通环境；二是正式交接会，按清单逐项 demo，包括打开后台、查日志、改配置、回滚发布这类实操动作；三是质保期内的"应答式"答疑，遇到问题随时回应，但不再做需求变更。

容易被忽略的几个点：账号体系尽量从一开始就建在客户主体名下，避免后期改主体；云资源建议客户自己开通账号、我们以协作角色加入，离场时只需移除权限；密钥、证书这类敏感信息走加密渠道一次性交付并备案，不留在聊天记录里。我们在过往企业管理系统、IoT 平台和 工厂数字化项目 的交接里，基本都是按这套节奏走，结项后客户自己换团队接手也不会卡住。