软件外包合同里要写清的 8 件事：源码归属、验收与售后

先给结论

软件外包出问题，八成不是技术做不出来，而是「算不算做完了」双方没有共同标准。下面八项写进合同，绝大多数争议在发生之前就被消解了。这八项不需要复杂的法律措辞，用大白话写清楚同样有效。

一、功能范围：以什么文件为准

合同正文写不下全部功能，正确做法是约定一份附件作为范围依据：功能清单或定稿的交互原型，并注明版本与日期。写清楚「以 X 年 X 月 X 日定稿的原型文件为准」，比在正文里罗列功能名词可靠得多。没有这句话，后面所有关于「这个算不算范围内」的讨论都没有支点。

二、交付物清单：把要拿到的东西一件件列出来

典型清单包括：前端源码、后端服务源码、数据库结构与初始化脚本、接口文档、部署文档、操作手册、测试用例与验收记录、第三方依赖与账号清单。没列进清单的东西，交付时很可能拿不到。特别是部署文档——很多项目交付了源码却没有部署说明，换个环境就跑不起来，等于没交。

三、源码与知识产权归属

写明定制开发部分的源码与著作权归甲方所有，交付时间点与交付方式（提交到甲方代码仓库或交付源码包）也要写。同时要区分两类代码：为本项目定制开发的部分归甲方；服务商已有的通用框架或第三方开源组件，按各自的许可条款处理，服务商应授予甲方在本项目范围内的使用权。这个区分不写清楚，将来扩展或转让时会有麻烦。

四、里程碑与付款节点

把项目切成几个阶段，每个阶段有明确的完成标志与对应付款比例。常见节奏是：签约预付、原型定稿、开发完成进入测试、验收通过上线、保修期结束尾款。尾款比例不宜过低，它是保修期内响应质量的实际保障。

五、验收标准：怎样算通过

这是最容易被写虚的一项。可操作的写法是约定验收依据（功能清单或测试用例）、验收方式（在测试环境逐条走查）、验收期限（收到通知后多少个工作日内完成）、以及逾期未提出异议的处理方式。缺陷分级也要写：致命、严重、一般、轻微各自的定义与修复时限，避免把「有个按钮颜色不对」和「订单会丢」放在同一个筐里争论。

六、变更怎么算

写明变更的提出方式（书面或系统内记录）、评估流程、以及计价口径。同时约定判定标准：什么属于范围内的调整（不额外计费），什么属于新增（另行计价）。有了这条，双方可以就事论事地谈，而不是每次都变成情绪对抗。

七、保修与维护

区分两件事：保修是修复交付物本身的缺陷，通常有约定期限且不另行收费；维护是持续的运行支持与小幅优化，属于付费服务。合同里把保修期限、覆盖范围（因程序缺陷导致的问题）、不覆盖范围（甲方自行改动、第三方服务变更、环境故障）与响应时效写清楚。响应时效指开始处理的时间，修复时长取决于问题性质，两者不要混为一谈。

八、账号、密钥与资料的归还

项目过程中服务商会接触到域名、服务器、支付商户号、第三方平台等账号。合同里约定：这些账号的所有权归甲方，服务商在授权范围内使用；项目结束或合同终止时，服务商应归还资料、交出临时权限并删除其掌握的副本。这一条在更换服务商时特别重要。

最后一句提醒

合同的作用不是用来打官司的，是用来让双方在开工前把话说清楚的。上面八项如果对方不愿意写清楚，本身就是一个值得注意的信号。

本文为一般性说明，不构成法律意见；具体合同条款请咨询专业法律人士。