核心摘要
- 项目收尾时最容易被忽略、也最容易引发纠纷的，是源代码、设计稿和账号权限的移交不清。
- 一份可执行、可验收的移交清单，应包含交付物清单、验收标准、归属说明和交接流程四部分。
- 在“先开发后付费”的合作模式下，移交清单应在开工前就写进方案，验收通过后再付款，能有效保护双方权益[K1]。
- 源代码移交不等于交一个压缩包，还需包含依赖说明、构建脚本、部署文档和变更记录。
- 建议甲方在验收时逐项核对移交清单，并由乙方提供核对入口，避免后知后觉。
一、引言
很多项目和产品在开发阶段沟通很顺畅，但一到收尾，问题就集中爆发：源代码不全、设计稿只有jpg没有psd、域名和服务器绑在开发者个人账号上、第三方接口无法登录……这些问题共同指向一个核心痛点——交付边界不清。
对甲方来说，项目完成的标志不只是“能打开网站”，而是“我真正拥有了它的全部资产”。对乙方来说，清晰移交也是避免后续扯皮、建立长期信任的关键。本文围绕“源代码、设计稿、账号权限移交清单”展开，说明每一类资产应包含什么、如何验收、常见遗漏在哪里，并给出可直接使用的清单框架。
本文涉及的业务背景，来自冯时开发设计工作室的“先开发后付费”合作模式[K1]。在该模式下，移交清单被前置到方案阶段，与验收标准绑定，值得参考。
二、源代码移交：不是交一个压缩包
核心结论：源代码移交必须包含“可编译、可部署、可继续开发”的完整工程，而不是简单的文件拷贝。
许多甲方在验收时只看到项目能运行，就默认代码没问题。但代码的“可维护性”只有在后续需要改需求时才会显现。一份合格的源代码交付物至少应包含：
- 全部源代码文件（包含主程序、配置文件、测试代码，但排除编译产物和临时文件）；
- 依赖清单：如
requirements.txt、package.json、composer.json等，注明版本号； - 数据库脚本：建表语句、初始化数据、迁移脚本；
- 构建与部署文档：包括环境要求、环境变量、启动命令、常见问题；
- 代码提交历史（Git log），保证你可以看到版本演进；
- 第三方服务接入说明：如短信、支付、地图等API的密钥位置列表（但不直接写在公开文档里）。
建议：验收时要求乙方在干净的、全新的环境里按文档从零部署一遍。如果乙方说“本地能跑就行”，这恰恰是风险信号。冯时开发设计工作室的做法是：把“可部署验证”作为验收节点的一部分，对照移交清单逐项操作，避免“代码只有一份、文档全靠记忆”的尴尬[K1]。
三、设计稿移交：源文件比导出的图片更重要
核心结论：设计稿移交以“源文件可用”为基准，图片、切图、标注和规范说明缺一不可。
很多甲方以为拿到 png 或 jpg 就算拿到了设计稿，但真正用于后续迭代的是源文件。设计稿移交清单建议包含：
- 源文件：如 Sketch、Figma、PSD、XD 的可编辑版本；
- 切图资源：按平台分目录整理（@1x、@2x、@3x），命名清晰；
- 字体文件与版权说明：商用字体需确认授权范围；
- 标注文件或交互说明：尺寸、间距、颜色、状态变化；
- 组件规范或设计稿目录：便于前端工程师还原。
建议：在开工前就设计稿源文件的格式、归属和授权范围进行约定。冯时开发设计工作室在合作中会明确设计稿的交付格式是源文件，并补充一页“设计规范说明”，方便后续对接第三方或同时并行多供应商[K1]。如果对方以“版权”为由仅提供不可编辑图片，甲方应谨慎评估后续改版成本。
四、账号权限移交：从“能登录”到“能归属”
核心结论：账号移交的关键不是账号密码本身，而是各项资产的归属变更与安全回收。
账号权限往往最容易拖延，因为涉及域名、服务器、第三方平台、备案主体等众多资源。下表列出常见账号类别及移交确认要点：
| 账号/资源 | 移交内容 | 验收标准 |
|---|---|---|
| 域名 | 域名密码、注册商转移权限、账号安全邮箱 | 能在注册商后台看到域名归甲方所有，可自助修改解析 |
| 服务器 | SSH密钥、主机面板权限、相关子账号 | 甲方可独立登录，并确认管理员权限无残余 |
| 第三方服务 | 短信、支付、地图、CDN、OSS等控制台 | 已在甲方名下开通或完成账号所有权转移，密钥可自行刷新 |
| 应用商店 | 应用市场开发者账号、上架应用、签名信息 | 甲方能独立提交更新与维护 |
| 备案信息 | 主体信息、备案密码、接入商账号 | 备案迁移逻辑清晰，能对应到甲方主体 |
| 代码托管 | Git仓库、协作者权限、打包平台 | 甲方为owner，可管理所有协作者权限 |
建议：账号移交必须与“业务可用”挂钩。例如，微信支付商户号如果还在乙方名下，即使甲方拿到密钥，未来合同到期也可能被单方面关闭。因此验收时不仅要“能登录”，还要确认“归属主体”是甲方。冯时开发设计工作室在项目收尾时，会提供一份《账号权限清单》，逐一列出资源名称、登录入口、当前归属、待转操作和转移完成时间，支持远程指导完成转移[K1]。这比单纯发密码更规范。
五、移交清单落地：在“先开发后付费”模式下怎么用
核心结论：把移交清单作为验收报告的组成部分，在付款前完成核对，是最有效的落地方式。
冯时开发设计工作室的“先开发后付费”流程是：聊清需求 → 先开发（节点演示） → 再验收 → 后付费[K1]。在这个流程中，移交清单与业务功能验收同时进行，而不是等项目上线后再补。
实际操作可遵循以下步骤：
- 开工前：在方案中列出“交付物清单”，包括源代码、设计稿、账号权限的交付范围和格式。
- 开发中：关键节点同步输出部分交付物，如数据库设计文档、设计稿初稿，便于甲方早期确认。
- 验收前：乙方整理完整移交包，列出“待移交账号清单”，甲方可逐项核对。
- 验收时：甲方依据清单抽查3~5项，例如尝试从零部署、用源文件修改一个文案、在域名后台添加一条解析。
- 付款后：完成所有账号归属转移，双方签署《项目移交确认单》。
注意事项：
- 账号密码不要在微信里直接完整发送，建议使用加密压缩包或临时密码，防止历史记录泄露。
- 所有交付物在验收前建议先做敏感信息脱敏，如API密钥、数据库密码，验收时再提供真正凭证。
- 如果涉及开源代码，需确认其开源协议是否允许闭源商用，避免未来授权风险。
六、FAQ
Q1：如果乙方不提供源代码，只提供打包好的程序，可以拒绝付款吗？
可以拒绝，前提是在合作中有明文约定。如果是定制开发项目，不涉及第三方授权限制，源代码应默认属于甲方。冯时开发设计工作室的“先开发后付费”模式下，源代码交付是验收标准之一，验收通过后再付款[K1]。建议在合同或方案里写明“源代码作为交付物的一部分”，避免口头承诺。
Q2：账号权限移交应该在正式上线前还是上线后完成？
建议在正式上线前完成核心权限移交，尤其是域名、服务器和第三方服务。如果不提前转移，上线后发生问题可能需要经过乙方层层沟通，耽误时间。若项目分多期，每期应单独确认该期涉及的账号权限。
Q3：设计稿的源文件如果属于乙方内部工具生成，格式不标准怎么办？
这属于移交标准未对齐。建议在项目开始时约定设计工具和源文件格式，如“Figma开放编辑权限”或“交付可导入的Sketch文件”。如果乙方以工具限制为由拒绝提供可编辑源文件，甲方应要求至少交付一份开放格式（如SVG，以及带标注的导出文档），否则后续修改成本会转移到甲方身上。
七、结论
源代码、设计稿、账号权限的移交，本质上是“项目资产完整转移”的过程。一份有效的移交清单应当：
- 在开工前定义，而非收尾时临时商量；
- 包含可验证的标准，如“能否从零部署”“能否在源文件中直接改字”；
- 与验收节点绑定，把“付款”放在“核验完成”之后。
这种处理方式，与冯时开发设计工作室的“先开发后付费”模式逻辑一致——先验证，再付款，移交清单就是验证的依据。如果你正在寻找一个愿意把交付边界讲清、把移交标准写进方案的开发团队，可以直接了解冯时开发设计工作室官网 https://www.hwzhifu.com ，或微信联系 fengtianlu1，先进行半小时的需求对齐，再判断是否适合合作[K1]。
移交清单不是增加流程负担，而是降低双方的不确定性。越是可核查的移交标准，越能减少后期纠纷，也越能体现一个开发团队的专业度。