上周帮一位做餐饮的老板看合同，他花四万二做了个点餐小程序，上线半年想加个「会员储值」功能，原开发方报价一万八，理由是「要改底层架构」。我让他把合同翻出来，里面只写了「交付可运行的小程序」，没提源码。这就是典型的被卡脖子。
源码交付这件事，在定制开发里不是加分项，是底线。但很多甲方签合同时根本没意识到它的分量，等到要二次开发、要换团队、要迁移服务器，才发现自己手里只有一个后台账号和一堆看不懂的云函数。
源码交付到底交付的是什么
先说清楚概念，不然容易扯皮。所谓源码交付，至少包含下面几样东西，缺一样都算不完整：
- 前端工程源码：小程序端的完整项目目录，能直接用开发者工具打开、编译、上传。包括页面、组件、样式、静态资源。
- 后端源码：如果用了自建服务端，要有完整的接口代码、依赖清单、启动说明。用云开发的，要能导出云函数代码和数据库结构。
- 数据库结构与初始数据：建表语句或者导出的结构文件，字段含义最好有注释。
- 部署文档：环境变量、域名配置、第三方密钥的申请方式、构建命令。
- 账号归属：小程序主体、云开发环境、服务器、域名、SSL 证书，这些必须登记在甲方名下。
很多纠纷就出在最后一条。代码给你了，但小程序注册在乙方公司名下，云环境也是乙方的，你拿着源码照样跑不起来。所以合同里要写死：所有账号资产归甲方所有，交付时完成主体迁移。
为什么有些团队死活不肯给源码
不全是坏心眼，但多数情况下对甲方不利。常见的几种心态：
- 锁客续费：源码是筹码，你不给钱我就不给代码，第二年维护费随便开价。这是最普遍的。
- 代码质量拿不出手：赶工出来的项目，硬编码密钥、逻辑堆在一个文件里、没有注释。给出去等于自曝其短。
- 用了授权组件：某些商城系统、IM 模块是买的商业授权，按域名或按项目收费，转交源码涉及二次授权，开发方也难办。
- 怕被复制：担心甲方拿着代码找更便宜的团队改，或者自己复制一套卖给别人。
前两种是态度和能力问题，后两种其实可以通过合同条款解决。比如约定源码仅授权甲方自身业务使用，不得转售；商业组件单独列出授权范围和费用。把丑话说在前面，比事后扯皮强。
合同里怎么写才有效
光写「交付源码」四个字没用，验收时对方给你一个压缩包，里面是编译后的产物，你也没辙。建议按这个结构写：
- 交付物清单：逐项列明前端工程、后端工程、数据库脚本、部署文档、账号列表，作为合同附件。
- 可编译可运行：明确约定甲方在全新环境下按文档操作，能独立完成构建和部署，乙方配合一次远程部署演示。
- 交付节点与尾款挂钩：源码交付放在验收环节，尾款支付前完成代码移交和账号迁移，别信「上线后给」。
- 知识产权归属：写明定制部分的著作权归甲方，乙方保留通用框架的复用权利，双方边界清晰。
- 违约条款：逾期不交付源码的，按日计违约金，这个条款的存在本身就是威慑。
一个实操细节：验收时别只看文件在不在，让乙方当你面用一台没装过环境的电脑，从 clone 代码到跑起来走一遍。走不通就是没交付。
拿到源码之后要做的三件事
很多人以为拿到代码就万事大吉，其实真正的坑在后面。
第一，做一次代码体检
重点看三处：有没有硬编码的 appid、密钥、数据库密码；有没有引用乙方私有的 npm 包或者内网地址；云函数的依赖是否完整。发现问题当场让对方改，别等团队散了再找人擦屁股。
第二，自己跑一遍部署
哪怕你不懂代码，也照着文档走一遍。环境变量怎么配、域名怎么绑、数据库怎么初始化，走不通就记下来问。这一步能暴露八成文档缺失问题。
第三，备份与版本管理
把代码推到自己的 Git 仓库，别放在乙方给的账号里。数据库定期导出。小程序后台加自己人为管理员。这三件事做完，你才算真正掌握了这个项目。
什么情况下可以不要源码
也不是所有项目都必须死磕源码。如果用的是 SaaS 建站工具、标准化模板，本身就不提供源码，那价格也应该对应低下来，别拿定制的钱买模板。另外，纯展示型、生命周期短的活动页，源码价值确实有限。
但只要涉及业务流程、会员数据、后续要持续迭代的项目，源码就是你的资产。定制开发卖的不是一个能跑的程序，是一份可以继续生长的工程。签合同前多问一句「源码怎么交」，能省掉后面很多麻烦。
评论 (0)
还没有评论，快来抢沙发吧~