软件开发合同必须写清的 9 条（少一条都可能扯皮）

软件开发的纠纷，绝大多数不是"做不出来"，而是"当初没说清"。这 9 条建议逐条对照。

1. 需求说明书作为附件

合同正文可以简单，但必须有一份《需求说明书》作为附件，逐条列出功能、字段、权限、异常处理。双方签字。这份文件是后面所有验收和变更的基准。

源码、数据库脚本、部署文档、接口文档、操作手册、测试账号，逐项写明。特别注意写"源代码指可编译的完整工程文件，不含第三方商业组件"。这句话能避免"给了一堆 dll 也算源码"的争议。

写明"本项目定制开发的源代码及文档著作权归甲方所有；乙方保留通用组件、框架、工具的所有权，并授权甲方永久免费使用"。这样既保护你的资产，也避免乙方无法复用自己积累的底层库。

标准：需求说明书列明功能均可正常使用，无阻断性缺陷。流程：乙方提交验收 → 甲方 10 个工作日内测试并反馈 → 无异议视为通过。要写清"逾期未反馈视为通过"，否则甲方一直不验收，尾款永远收不到。

写明：需求变更需双方书面确认，按人天计价，单价 XX 元/人天；累计变更不超过原合同金额 10% 的，可在尾款中结算。没有这条，所有口头加需求都会变成扯皮。

建议 3:4:3，并对齐可验证的里程碑（签约 / 中期演示 / 验收上线）。避免"按时间付款"，因为进度可能因需求变更而延后。

写明免费维护期（通常 6 – 12 个月）、维护范围（修 bug 免费，新增功能收费）、响应时间（比如工作日 4 小时内响应）、维护方式（远程/现场）。

乙方对甲方业务数据保密；项目结束后删除或归还甲方数据；不得将甲方数据用于其他项目。涉及个人信息的，要写明符合《个人信息保护法》。

延期交付的违约金（常见按日 0.5%，上限 10%）；甲方逾期付款的违约责任；一方严重违约时的终止与结算方式。写清楚不是为了打官司，是为了双方都认真对待时间。

一份好的合同，读起来应该是"双方都知道自己要做什么"，而不是"谁防着谁"。