在金边做软件外包这12年，团队一直是28个人，没有扩过。每年交付的项目量在一百个上下，客户主要在东南亚——柬埔寨本地之外，菲律宾、越南、老挝、泰国、印尼、马来西亚都有长期合作方。主攻五个行业：电商、娱乐、金融/交易、地产、物流。合同纠纷见过不少，绝大多数不是技术做不出来，而是合同里没写清楚，最后双方对“什么算做完”“什么算额外工作”理解不一致。这篇不聊虚的，直接讲软件外包合同里几个真正要命的条款怎么写。
需求范围：把“做一个系统”变成“做这些功能点”
合同里最怕出现的一句话是“开发一个类似某某平台的系统”。这句话等于什么都没约定，后面UI调整、功能追加、流程改动都会从这里钻出来。需求范围要做的，就是把模糊描述翻译成可核对的清单。
我们接项目，习惯按“模块—子模块—功能点”三级来拆。比如用户模块下面的注册登录，不能只写“支持手机号登录”，要写到验证码有效期多少秒、一个号码每天最多发几次、密码错误几次后锁定多久。电商和金融/交易类系统尤其如此，一个促销规则或对账逻辑没写清，后面改起来就是一轮重新谈价。
另外有三件事值得写进合同：
- 排除清单：明确写“本需求范围不包括什么”。比如不含后台数据大屏、不含第三方支付渠道对接、不含多语言支持。没写排除项，甲方很容易默认“这些应该都有吧”。电商类项目里，支付对接默认是客户提供通道资源，我们只负责技术对接。东南亚各国本地支付通道差异很大，柬埔寨、菲律宾、印尼的通道都不互通，这条如果不在排除项里提前讲清，后面很容易变成争议点。
- 需求变更机制：约定所有变更必须走书面确认单，并且绑定工期和费用。比如单个变更导致开发工作量超过原合同一定比例，双方重新评估交付时间。这个比例要在合同里写成一个具体数字，而不是“重大变更再协商”这种话——什么叫重大，到时候双方各执一词。
- 原型图锚定：合同附件放高保真原型或交互流程图，写明“页面布局以原型图为准，色彩、字体、间距以设计稿为准”。UI返工是外包项目里最常见的隐性成本，提前锚定能减少大量无谓往返。
源码与账号：资产归属比功能开发更重要
功能做完了，源码拿不到，或者服务器账号不在自己手里，这种项目等于白做。源码交付和资产归属必须在合同里单独成章。我们手上有部分成品系统，几十家客户在运营使用，这类项目尤其要提前把授权边界写死，不然后面客户转手、二次开发、甚至换供应商都会卡在源码上。
源码交付一般分两种模式：
| 交付模式 | 适用场景 | 合同关键条款 |
|---|---|---|
| 一次性买断 | 自有产品、独立上线 | 验收通过后约定工作日内，提供完整可编译源码、数据库建表脚本、部署手册、第三方账号密码 |
| 分期授权 | 联合运营、SaaS租用 | 源码归属乙方，甲方拥有永久使用权，但不得转售或用于其他项目 |
服务器和第三方账号要逐项列清楚。服务器如果是甲方提供的，合同里应明确乙方只有部署权限，没有数据读取和删除权限。如果是乙方代购或乙方账号注册的，交付后要在约定期限内完成迁移，并确认乙方不再保留任何备份和管理权限。微信支付商户号、短信通道、OSS存储这些账号，哪个归谁，交付后谁有权限，都要一项一项写。我们做东南亚多国项目时，支付通道这块尤其复杂，账号归属不写清，交付后连对账都做不了。
还有一个容易被忽略的点：开源组件披露。合同里应当要求乙方提前披露使用了哪些开源组件和第三方库，并保证这些组件的授权协议不限制甲方后续商业化使用。否则项目上线后才发现某个核心库的许可证有问题，处理起来非常被动。
验收标准：把“能用”写成“可以逐项核对”
验收不是“甲方点一下觉得没问题”就过了。验收标准写不细，项目大概率会在“这里好像不太对”“那里再改一下”中无限拖延。交付量大的团队和交付量小的团队，差别往往就在验收条款的颗粒度上。
验收建议分三层来定义：
- 功能验收：所有功能点通过测试用例，测试用例由甲方提供或双方确认。用例要覆盖正常流程、异常流程和边界条件，比如网络中断、输入非法字符、并发登录、大数据量查询。测试用例本身可以作为合同附件，每一行一条，通过打勾才算完成。
- 性能验收：写量化指标，不要写“加载快”。具体指标需要根据项目类型和部署环境来定，【此处待填：性能验收指标示例】。数字越具体，验收越没有争议。如果甲方没有技术人员能提出指标，可以要求乙方在报价阶段就给出建议值，写进合同后双方按此验收。
- 安全验收：至少覆盖无OWASP Top 10高危漏洞、用户密码加密存储、API接口有签名鉴权机制。安全项建议要求乙方提供一份自测清单，逐项勾选并签字确认。
付款节点建议绑定具体交付物，而不是按时间付款。我们自己的报价是按功能清单评估后报，付款走先付30%启动需求调研和UI设计，核心模块开发完成并能在测试环境演示后付40%，正式部署、通过全部验收、交付源码和文档后结清尾款。这个结构对双方都有约束力，客户接受度也比较高。合同里要写清楚每一笔款对应的交付物是什么，而不是只写“开发中期付40%”——什么叫中期，到时候又是争议点。
延期责任不能只写“每日罚金”。要同时约定一个终止线，比如延期超过一定天数，甲方有权单方面终止合同，乙方退还已付款项并赔偿直接损失。直接损失可以列出服务器租赁费、第三方接口费用等具体项目。
售后条款：交付之后才是长期关系的开始
系统上线后出问题是常态，售后条款决定这些问题由谁处理、多久处理、要不要额外收费。我们日常用中文沟通，系统bug修复免费，新增功能按工作量收费。这些如果不在合同里体现，交付后要么乙方被无限消耗，要么甲方觉得没人管。
免费维护期一般在3到12个月之间，覆盖范围要写清楚：生产环境故障修复、高危安全漏洞修复、服务器环境变更导致的兼容性问题。响应等级按严重程度分级，P0级系统不可用应在约定小时内响应、约定小时内修复，P1级功能异常对应什么响应时间，都要有明确数字。具体的响应时限需要根据项目规模和部署环境来定，【此处待填：响应时限示例】。
排除项同样重要。甲方自行修改代码导致的问题、第三方接口变更、操作系统版本升级引发的不兼容，通常不在免费维护范围内。这些不写清楚，售后阶段乙方容易变成“无限责任技术支持”。
二次开发条款建议加入优先合作权：同等报价条件下乙方优先承接，但乙方不得以“源码未交付”或“框架不开放”为理由拒绝提供支持或设置不合理费用。二次开发产生的代码知识产权归甲方所有，这一条也要写明。
合同末尾最好附一份技术文档交付清单：API接口文档、数据库ER图、部署运维手册、第三方服务配置说明。系统能不能自主运维，能不能换团队接着开发，很大程度上取决于这些文档是否齐全。