做完之后你们支持交接吗？

结论：支持，而且交接条款可以写进合同。真正完成交接的标准不是“文件已发送”，而是客户团队能用自己的账号独立构建、发布、回滚、恢复数据和处理一次常见故障。

滚水科技会在项目开始时确认最终由谁接管，而不是上线前才临时补文档。因为交接对象不同，准备重点也不同：有研发团队的客户需要代码结构、流水线和故障定位培训；只有运营团队的客户需要账号、内容配置、数据导出和工单机制；暂时继续委托运维的客户，也必须保有源码、数据和核心账号，确保未来能切换服务商。

在约定交付物、接管方式与责任边界时，还可以对照 源码交付后，我们自己的技术团队能顺利接手维护吗？；这些内容补充了需要放在同一项决策中考虑的上下文。

三种交接安排的差异如下：

交接安排	适合情况	客户必须取得	验收动作	主要风险
一次性资料交接	系统简单且客户团队熟悉技术栈	仓库、文档、账号与备份	客户在干净环境独立部署	隐性知识容易遗漏
资料加培训陪跑	多端、第三方接口或业务规则较多	完整资产及排障方法	客户完成一次发布、回滚和故障演练	需要预留双方人员时间
过渡运维后接管	客户团队尚未到岗	资产先归客户，滚水科技暂时运维	按月移交权限并在截止日前撤场	没有退出日期会变成长期依赖

交付物至少包括客户可控制的代码仓库、版本标签、构建与部署脚本、依赖锁定文件、数据库迁移和备份恢复说明、接口定义、数据字典、设计源文件、测试记录、监控告警、第三方服务与续费清单。生产密钥不能放进文档或源码，应在客户控制的密钥环境中轮换；滚水科技的临时账号在陪跑结束后撤销。源码里包含开源或商业组件时，还应交许可证和授权状态，不能把“拿到代码”误认为取得第三方权利。

接口文档可采用 OpenAPI 规范 固化请求、响应和错误码，仓库则由客户组织账号持有。GitHub 的 仓库角色说明 展示了按角色分配读取、维护和管理权限的方式；无论实际使用 GitHub、GitLab 还是自建平台，都应让客户内部至少两人拥有管理能力，供应商只保留完成工作所需的权限。

交接应有明确窗口和责任人。第一阶段核对资产清单及未解决问题；第二阶段由滚水科技演示部署、日志查询、告警处理、备份恢复和回滚；第三阶段角色互换，由客户操作、滚水科技旁站；最后关闭供应商高权限账号，双方签署遗留事项和维保边界。培训录像可以辅助复习，但不能替代可搜索、与版本对应的书面文档。

验收指标要能够复现。例如从指定空环境到系统可用所需时间、恢复点目标和恢复时间目标、关键告警是否到达客户联系人、客户独立发布成功率、未关闭问题的级别和解决日期。至少演练一次错误版本回滚和备份恢复，因为“能部署”不代表“出事能恢复”。第三方支付、短信或地图还要测试客户能否自行查看账单、轮换密钥和提交工单。

如果客户没有研发人员，滚水科技可以继续提供维保，但托管与交接不是二选一。合同仍应写清数据导出格式、工单响应范围、版本和文档同步频率、迁出协助工时、服务终止后的数据删除与账号撤销。新增功能与缺陷修复也要分开定义，避免把所有变化都笼统算作“免费维护”。

详细资产边界可查看滚水科技的 透明交付标准；具体项目的源码范围、交接窗口与维保责任仍以合同附件为准。