商业意图 · 2026-09

# 找外包做小程序，合同里必须写清楚什么？

几乎所有小程序外包纠纷，追溯到最后都是同一个原因：当时觉得"说清楚了"，但合同里没写清楚。

口头共识在合作顺利时看不出问题，一旦出现分歧——需求做了一半要改、交付日期一拖再拖、验收时双方对"做完了"的理解完全不同——能保护你的只有纸面条款。这篇文章把签约前必须落到合同里的内容逐条拆开。

## 一、需求范围：写"做什么"，更要写"不做什么"

合同必须附一份完整的功能清单作为附件，精确到页面和交互。比如"商品管理"要拆成：商品列表、商品编辑、上下架、库存修改、分类管理——每一个子项都列出来。

比功能清单更重要的是排除条款：明确写"本期不包含××功能"。小程序项目最常见的加价纠纷，就是乙方说"这个不在范围内"，甲方说"我以为肯定包含"。提前把边界画出来，这句话就不会出现在项目中期。

同时约定需求变更机制：变更如何提出、如何估价、如何影响工期。不写这条，后期每一次改动都是一次重新谈判。

## 二、验收标准：以功能点逐项验收，而不是"上线即验收"

"上线"不等于"验收通过"。合同里要写清验收方式：

• 以合同附件中的功能清单逐项验收，每一项可运行、符合描述即为通过
• 约定验收期（交付后若干个工作日内完成测试并反馈）
• 约定缺陷分级：阻断性缺陷必须修复后验收，一般性问题可记录后限期修复
• 约定验收异议的处理流程，避免"一直不验收"或"一直不通过"的僵局

验收标准越具体，尾款支付时的争议就越小。

## 三、交付物与知识产权：源码归属必须白纸黑字

很多企业在项目结束一年后才发现：自己手上只有一个能用的小程序，没有源码。想换服务商？从头再做一遍。

合同必须列明交付物清单：前端源码、后端源码、数据库结构文档、接口文档、设计源文件、部署说明、管理后台账号。并明确约定：源码及相关知识产权在结清款项后归委托方所有，乙方不得保留副本用于其他项目，不得使用加密、混淆或托管方式变相控制源码。

这一条直接影响你未来对系统的掌控力，是整个合同里最不能妥协的部分。

## 四、付款节点：钱跟着里程碑走，尾款握在验收后

常见且相对安全的结构是：启动款、中期款（核心功能演示通过后）、尾款（验收通过后）。比例可以谈，但原则不能变：

• 每一笔款项对应一个可验证的交付里程碑，而不是对应时间节点
• 尾款比例要足以构成乙方完成收尾和修复的动力
• 写清每个里程碑逾期未完成时，甲方有权暂缓支付对应款项

一次性预付大额款项，等于放弃了项目全过程的约束力。

## 五、工期与延期责任：把"尽快"变成可计算的条款

合同里写清开工日期、各里程碑日期、最终交付日期，以及延期的责任划分：

• 因乙方原因延期的违约金计算方式（按日或按周计）
• 因甲方原因（资料未提供、确认不及时）导致延期的，工期相应顺延——这条同样要写，它保护的是双方预期的确定性
• 延期超过一定限度时，甲方的解约权与已付款项处理方式

## 六、质保与运维：上线只是开始，责任边界要提前划

小程序上线后一定会暴露问题，合同要写清：

• 质保期时长，期内缺陷修复是否免费、响应时效如何承诺
• 质保范围：哪些属于"缺陷修复"（免费），哪些属于"新增需求"（另行报价）
• 微信官方规则变更、接口升级导致的适配工作如何计费
• 质保期后的运维服务如何衔接，避免系统在"无人负责"状态下裸奔

## 写在最后

合同不是不信任，而是让信任有地方安放。一份把边界、标准、归属、责任都写清的合同，实际上筛掉的是两类乙方：没能力按标准交付的，和没打算按标准交付的。

在协通，需求边界与验收标准在签约前就以文档形式确认，作为合同附件的一部分——这来自我们「八维需求工程体系」中"需求确认"环节的强制要求。前期多花几天对齐文档，远好过后期花几个月处理纠纷。