软件外包的失败案例里，技术问题其实很少，绝大多数栽在合同与流程上。把最常见的 4 个坑提前认清，就能避开大部分损失。本文逐条拆开，并给出对应的"正确写法"。
坑一：合同只写"开发某系统"
问题：范围模糊，任何新增需求都要重新谈价，项目变成无底洞。
正确写法：以《需求规格说明书》或 SOW 作为合同附件，写明功能清单、页面清单、集成清单，以及不包含项。约定变更流程，需求版本号固定。
范围是外包的地基，地基不清，后面全是争议。
坑二：源码条款写"提供使用权"
问题：后期换供应商或自建团队时被卡住，业务连续性掌握在对方手里。
正确写法：直接写明"著作权归甲方"，并约定源码交付形式（完整可编译仓库、含提交历史、依赖清单、构建与部署文档）。若开发方要保留通用组件权利，逐项列明清单与授权范围。
记住法律默认规则：无书面约定，著作权默认归受托人。
坑三：验收标准写成形容词
问题："界面美观、运行稳定"无法作为验收依据，争议时只能靠协商。
正确写法：用"可执行的动作 + 可观察的结果"描述，例如"用例 1-50 全部执行通过、P0/P1 缺陷为 0、源码可在干净环境按文档构建成功"。
形容词不可验证，动作和结果可以。
坑四：账号在乙方名下
问题：域名、服务器、第三方服务都在对方实名下，等于把业务连续性交给了对方。
正确写法：一律以甲方实名注册，乙方只给约定范围内的操作权限；项目结束后收回权限、移交账号与数据，并删除本地副本。
账号的控制权，就是业务的控制权。
这四个坑的共同点
它们都不是技术问题，而是合同与流程问题。技术上能实现的功能，谁来做都能做；但合同没写清的权利，事后很难再补回来。
签约前对照这四条
- □ 需求范围有附件、有版本号、有"不包含项"
- □ 著作权归甲方、源码交付形式明确
- □ 验收标准可量化、可复现
- □ 域名与账号以甲方实名
这四个坑之外的第五个：没有验收流程
除了上面四个，还有一个更隐蔽的坑：合同里没有验收流程。表现为验收没有标准、没有期限、没有记录，全靠口头一句"没问题"。
它的后果是：付款没有依据，缺陷没有边界，责任无法追溯。验收流程不是形式，而是把前面四个坑"关进笼子"的机制——有了它，范围、源码、标准、账号才有被逐项确认的机会。
怎么把这份清单用起来
建议按三步落地：
- 签约前：把四个坑对应的写法逐条对照合同，缺什么补什么；
- 执行中：把需求版本、变更单、沟通记录留存归档；
- 验收时：用交付物清单与验收标准逐项打钩，未完成不付尾款。
一份"签约前对照表"
把四个坑对应的动作压缩成一张表，签约前逐行确认：
| 检查项 | 合格标准 |
|---|---|
| 范围 | 需求文档作为附件，有版本号与"不包含项" |
| 源码 | 著作权归甲方，交付形式与时限明确 |
| 验收 | 标准可量化、可复现，有验收流程 |
| 账号 | 域名与账号以甲方实名，交接写入验收项 |
| 变更 | 有书面变更流程与变更单模板 |
| 责任期 | 缺陷责任期与 SLA 明确可考核 |
这张表的价值在于"可执行"：它不是一堆原则，而是一行行可以打钩、可以要求对方给出书面答复的具体项。谈得越具体，后期的意外越少。
外包的风险大多不在代码里，而在合同里。把这四个坑对应的写法逐条落进合同，项目成功的概率会高出一大截。