软件外包合同签之前，必须确认的 10 件事

软件外包合同纠纷，是中小企业信息化建设中最常见的法律风险之一。

很多企业在项目结束后才发现：合同里有利于乙方的条款，自己当初根本没有注意到。等到项目烂尾、拿不到源码、或者功能与预期严重不符时，才发现维权困难重重。

本文整理了签合同前最关键的 10 个确认点，可以当作检查清单使用。

---

1. 明确的功能清单，而不是模糊的"需求描述"

问题：很多合同附的"需求说明"只有几段话，比如"开发一个ERP系统，包含进销存、财务、生产管理功能"。这种描述没有任何约束力，后期扯皮的根源就在这里。

应该怎么做：合同附件里必须有一份功能清单，列出每个功能模块的具体内容。理想情况是有原型设计稿（即使是低保真的也可以），每个页面和操作都有对应的功能说明。

功能清单越详细，双方的期望差距越小，后期扯皮的概率越低。

---

2. 验收标准要写清楚

问题："开发完成后验收"——但什么叫"完成"？什么叫"验收通过"？如果没有明确标准，乙方可以以任何理由声称已经完成。

应该怎么做：合同里明确写出验收的标准，比如：

• 所有合同约定的功能均可正常使用
• 在指定的测试用例下，无阻断性 bug
• 性能要求（比如首页加载时间 < 2秒，并发用户数 > 100 等）

验收时建议写验收测试用例，按用例逐一测试，有争议时有客观依据。

---

3. 源码所有权和交付方式

问题：有些合同里写的是"源码加密交付"或者"代码在乙方服务器上运行，甲方通过接口使用"。这意味着甲方永远无法脱离乙方。

必须确认的条款：

• 项目源代码所有权归甲方所有
• 交付的源码不加密、不设访问限制
• 包含完整的代码仓库（含历史提交记录）
• 包含部署文档，甲方可以自行部署到任何服务器

只有满足以上条件，才算真正的"源码交付"。

---

4. 付款节点与交付物挂钩

问题：很多合同的付款方式是"签约付 50%，验收付 50%"，这意味着乙方在签约后就已经拿到一半资金，而甲方的剩余 50% 是验收后才付，但验收前乙方已经没有太大动力快速推进。

更好的付款结构：

• 签约付 30%（需求确认）
• 提交可测试版本付 30%（里程碑一）
• 用户测试通过付 30%（里程碑二）
• 上线运行 1 个月无重大 bug 付 10%（质量保证）

付款节点越多，乙方越有动力按节点交付，风险越分散。

---

5. 开发周期和延期责任

问题：合同写"约 3 个月完成"，但"约"是一个非常模糊的词，延期了也无法追责。

应该怎么做：

• 明确写出每个里程碑的截止日期（年月日）
• 明确延期的责任：比如每延期一周，乙方按合同总价的 1% 给予补偿
• 明确因甲方原因导致的延期不算在内（比如需求变更、提供资料延迟）

---

6. 需求变更的处理机制

问题：项目进行中，甲方的需求变更是常见情况。如果合同没有规定变更机制，双方经常在"这是合同范围内还是范围外"上产生争议。

应该怎么做：合同里明确：

• 合同范围外的需求变更，走书面变更单流程（双方签字确认）
• 变更单内写明额外的工作量、费用和对工期的影响
• 变更单未签署之前，乙方有权不执行变更内容

---

7. 售后保障期和 bug 修复责任

问题：软件上线后发现 bug 是正常的，但乙方是否有义务修复？修复是免费的还是收费的？

应该怎么做：

• 明确免费保修期：建议最少 6 个月，理想是 12 个月
• 明确保修范围：因乙方代码问题导致的 bug 免费修复；甲方操作不当或需求变更导致的问题另行计费
• 明确响应时间：严重 bug（影响核心功能使用）要求 24 小时内响应并修复

---

8. 第三方服务和额外费用

问题：软件开发过程中，经常需要用到第三方服务，比如服务器、短信服务、地图 API、支付接口年费等。这些费用是包含在合同里，还是额外收费？

应该怎么做：合同里明确：

• 哪些第三方服务由乙方承担，哪些由甲方自行采购
• 服务器、域名、SSL 证书等运维费用由谁承担
• 如有按量计费的 API（比如大模型调用费用、短信费用），费用归属和计费方式

---

9. 保密条款

问题：乙方在开发过程中会接触到甲方的业务数据、客户信息、商业策略等敏感信息。如果没有保密条款，这些信息可能被乙方用于其他项目。

应该怎么做：

• 明确乙方不得将甲方的业务信息用于其他商业目的
• 明确乙方不得将基于甲方需求开发的代码（尤其是核心业务逻辑）直接用于其他客户
• 保密期限：建议项目结束后至少 3 年

---

10. 争议解决方式

问题：出现纠纷时，双方去哪里解决？

应该怎么做：

• 明确约定争议解决的管辖法院（建议写甲方所在地的法院）
• 或者约定仲裁机构（仲裁比诉讼更快，成本更低）
• 避免合同里没有争议解决条款，或者写的是乙方所在地法院（对甲方不利）

---

小结：一份好合同的核心要素

条款	常见问题	应该怎么做
功能清单	模糊描述	详细的功能列表 + 原型
验收标准	没有明确标准	列出验收测试用例
源码权属	加密或不交付	明确源码归甲方
付款节点	签约付大比例	与里程碑挂钩的分期付款
开发周期	模糊的"约"	具体日期 + 延期责任
需求变更	无规定	书面变更单流程
售后保障	无或不明确	至少 6 个月免费保修
第三方费用	不明确归属	逐项列明
保密条款	无	明确范围和期限
争议解决	无或乙方主场	甲方所在地法院

---

如果你正在评估外包合同，可以预约一次免费咨询，我们会从甲方视角帮你审查合同条款，识别潜在风险点。