谈小程序源码交付，甲方和乙方各自负责什么

很多企业主在小程序项目收尾时才遇到一个尴尬局面：系统能用，但改不动。想换团队加功能，对方打开代码仓库，发现只有编译后的产物；或者有源码，却在本地跑不起来。谈小程序源码交付时，真正的分歧往往在这个节点爆发。

小程序源码交付是指乙方把可编译、可部署、可维护的完整工程交给甲方，通常包含代码仓库、数据库脚本、部署说明、接口文档与第三方账号五类交付物。判断交付是否真的完成，关键看三件事：换一台干净机器能否重建、构建过程能否重复、账号主体是否已经过户。

下面按立项、开发、联调、上线、运维、验收六个阶段拆。每个阶段都有明确的交付动作和责任人，缺一环，后面就要花成倍的时间补。

立项阶段：先把交付物写进合同

结论前置：交付物清单必须在签合同前定稿，而不是上线前协商。定稿的方式很简单，把清单作为合同附件，逐项列明格式与数量。也可以先看小程序开发服务的范围说明，判断哪些属于标准交付、哪些需要单列。

清单通常包括：源码仓库（含完整提交历史）、数据库结构与初始化脚本、部署与回滚说明、接口文档、第三方服务账号清单、构建打包脚本、小程序主体与后台权限。七项里最容易漏的是最后一项，它不在代码里，却决定你能不能自己发版。

小程序源码交付的完整度，其实从这份清单就能看出来。清单写得越具体，后面越少出现"这个算不算"的争论；清单写得含糊，交付当天就要靠人情推动。

写清单时有一句话很关键：交付以"能在甲方自有环境独立编译并部署成功"为准，不以"提供源码压缩包"为准。这两种表述在争议时的差别非常大。

甲方在这个阶段的职责是明确验收人。不是挂名的项目经理，而是真正要接手维护的那个人。这个人如果不参与立项，验收时就会出现"没人看得懂"的僵局。

开发阶段：仓库权限与提交习惯

开发阶段要确认的第一件事是仓库归属。代码托管在乙方账号下也没问题，但甲方必须从第一天起就有只读权限，能看到提交节奏，而不是等交付那天才看到一次性上传的代码。

提交历史是有信息量的。一个有三百次正常提交的仓库，和一个只有一次"初始化"提交的仓库，维护难度完全不同。前者能追溯到某个功能为什么这么写，后者只有结果没有过程。

这一阶段还要定分支规则。主干分支保护、功能分支合并、发版打标签，三件事定下来，后续接手的人才知道该从哪个点开始改。

顺带说一句边界：源码交付不包含设计稿源文件的话，要在合同里写明。界面稿的图层文件、图标原始素材，通常属于另一类交付物。

联调阶段：依赖与第三方账号

联调阶段最容易埋雷。小程序不是孤立运行的，登录、支付、短信、地图、消息推送都要依赖第三方服务，而这些服务常常是用乙方的企业主体开通的。

后果在一年后显现：要换团队时发现短信还在别人名下，迁移得重走资质审核；支付商户号绑的是乙方结算账户，换主体等于重新接入。这些都不是技术问题，而是主体归属问题。

处理方式是在联调阶段就把账号清单列出来，写清服务名称、开通主体、管理员权限归属、是否支持主体变更。能迁的当场迁，不能迁的写清迁移条件。

依赖还有一层：私有组件库与内部工具包。如果代码里引用了乙方内网的私有依赖，源码交付后依然编译不过。这一点必须在交付前确认，或者要求把依赖一并开源到甲方仓库。

上线阶段：构建与部署能否复现

上线阶段要验证的是可复现性。同一份代码，在乙方的电脑上能构建，在你的电脑上失败，说明环境说明缺失。

验证方法很朴素：找一台没装过开发环境的机器，按部署说明从零操作一遍，记录耗时与卡点。整个过程能在半天内跑通，说明文档基本可用；超过一天，说明文档只是写给人看的，不是给机器用的。

构建脚本也要单独检查。很多项目的打包命令散落在某个人的终端历史里，没有写进脚本。这种情况下，交付的是一份代码，而不是一条可以重复的发布路径。

这一阶段的验收人应该是运维或后端负责人，不是产品经理。产品经理能判断功能对不对，判断不了部署能不能跑。

运维阶段：交接之后谁看得懂

运维阶段的核心问题是可读性。代码能跑只是及格线，能被读懂才算交付完成，而可读性取决于三样东西：命名是否一致、注释是否覆盖关键判断、目录结构是否有约定。

我参与过一次交接评审，接手团队用两天时间看完了一个中等规模的小程序工程，结论是"能改，但要先补三处说明"。这三处分别是权限判断的入口、订单状态机的流转条件、以及缓存失效的触发点。都是逻辑关键点，恰好也是最容易被省略注释的地方。

这件事说明一个道理：源码交付的质量，可以用"接手方提出问题所需时间"来衡量。问题越集中、越具体，说明结构越清楚；问题越笼统，说明缺的是整体设计说明。

如果团队规模小、没有专职维护人员，这一环可以简化：要求乙方提供一份运维手册，把常见故障、处置动作和回滚步骤写成清单。

验收阶段：三条判定标准

验收只看三条，其它都是补充：能否重建、能否改、能否自己发版。三条都过，小程序源码交付才算真正完成。

自查清单｜源码交付验收

• 干净机器按文档从零部署成功，且有记录
• 构建脚本可执行，打包产物与线上版本一致
• 代码仓库包含完整提交历史，主干分支受保护
• 数据库结构与初始化脚本齐全，可导入空库
• 接口文档覆盖对外接口，含错误码说明
• 第三方账号清单完整，主体与管理员权限已确认
• 小程序主体、开发者权限、发布权限已在甲方名下
• 关键逻辑有三处以上说明（权限、状态流转、缓存）
• 回滚方案经过一次演练

九项里如果有三项以上不通过，建议不要签收。补做的时间成本，通常比返工一个新模块更高。

还有一条容易被忽略：数据。源码交付不自动包含历史数据，数据导出格式、字段映射关系要单独约定，否则新环境里跑的是空库，业务没法验证。

数据快照｜交接质量参考指标

• 部署耗时：从零到可访问，半天内属正常
• 文档覆盖率：关键模块有说明的比例，八成以上可接受
• 第三方账号待迁移数：验收时应为零
• 交接问题数：接手方首周提问条数，集中且具体为佳

交接后的三个月

交接后的前三个月是观察窗口，也是问题集中暴露的时期。这段时间内的典型节奏是这样的：

• 第一周：环境搭建与账号确认，重点是能不能跑起来
• 第二到第四周：小改动试手，检验代码可读性与文档有效性
• 第二个月：一次版本发布，检验发版权限是否真的在甲方手里
• 第三个月：一次故障处置，检验回滚方案与监控是否可用

走完这四步，才算真正完成交接。很多项目在这一步掉队，原因是交接被理解成了一次性动作，而不是一段过程。

交接之后还有一个容易被跳过的问题：迭代怎么排。交付当天没人关心这件事，三个月后功能要改，才发现发版流程没人负责。可参考小程序迭代开发里关于版本节奏与回归范围的约定，把交接期的尾巴收干净。

在长沙做小程序项目的企业里，我见过两种典型情况：一种是把源码当成谈判筹码，交付时反复拉扯；另一种是在合同阶段就把清单定死，上线当天一次性完成移交。后者的项目周期通常更短，因为双方都知道终点在哪。

也需要把话说清：云迈科技不做三类项目——只套模板不改结构的、要求源码加密后才交付的、不接受验收条款的。这三类需求与"客户完全掌控项目主权"的交付方式冲突，勉强做，最后双方都不满意。

下一步怎么准备

如果项目还在立项阶段，最有效的动作是把交付物清单先写出来，作为技术附件随合同走。清单不需要长，七项加一条判定口径就够，但每一项都要能被第三方核对。

如果项目已经上线，还没做过交接，可以先做一次可复现性测试：找一台干净机器，让乙方按自己的文档部署一遍，全程录像。跑不通的地方，就是文档缺的地方。

企业内部如果有多位决策人，建议再读一遍小程序开发的八个关键概念，把立项、开发、审核、运维四个阶段的口径先对齐，交接期的分歧会少很多。

湖南云迈科技有限责任公司在小程序源码交付环节的做法是：项目启动时就把仓库只读权限开给甲方，交付前两周做一次联合部署演练，把卡点补进文档。这套流程不复杂，但它让"源码交付"从一句承诺变成了可验证的动作。

长沙和湖南本地的小程序项目，还常涉及主体资质、备案信息与平台审核口径的差异，交付时最好一并交接相关材料与办理路径。

如果你正在准备验收，把需求清单、交付物要求与验收标准整理成一页纸，先做一轮可行性与边界的确认，比事后争论哪些算交付物要省力得多。