夜雨聆风现在做软件、AI这种项目制的公司，合同其实已经写得越来越细了。
需求清单、开发周期、付款节点、验收标准、违约责任，有的再配上需求说明书、原型图、会议纪要，几十页材料放在一起，看起来已经没什么能漏的了。
但真的到了项目后期，还是会出现一种很熟悉的场面：
甲方说，这东西根本没做完。
乙方说，合同里的功能我都做了。
甲方说，我后来提的那些需求本来就应该包含在里面。
乙方说，那明明属于新增需求。
这个项目到底算没算做完？
很多人的第一反应是，合同还是写得不够细。
但这个解释有一个问题。
如果合同继续往下写，真的能把这个问题解决吗？
01
有些合同不是没写完整，而是根本不可能写完整
2016年诺贝尔经济学奖授予 Oliver Hart 和 Bengt Holmström，表彰他们对契约理论的贡献。
Hart研究里有一个很重要的概念，叫“不完全契约”。
简单说就是：
真实世界太复杂了，签合同时，人不可能提前把未来会发生的每一种情况都写进去。
诺贝尔奖官方对这个理论的介绍里就提到，因为未来存在大量无法事先写明的情况，一个重要的问题就变成了：当合同没有规定时，谁拥有作决定的权利。
这个问题放到软件开发里尤其明显。
假设今天你给客户开发一套CRM。
签约的时候，双方都觉得需求已经确定了。
开发一个月，客户突然发现：
销售部门想增加一个权限。
财务部门说原来的统计逻辑不能用。
老板看过Demo，又觉得这个流程应该再改一下。
问题来了。
原需求的完善？
Bug修复？
合理优化？
还是新增需求？
你当然可以在合同里把“新增需求”定义得更细。
但你不可能在项目开始之前，就把未来所有可能发生的变化全部列出来。
越是需要长期协作的项目，越不可能只靠签约那一天把未来全部锁死。
但这还只解释了一半。
因为合同写不完，并不意味着项目一定会失控。
真正的问题是：合同没写到的那些事情，后来是怎么被决定的？
02
合同没变，项目先变了
最高人民法院在一起计算机软件开发合同案件里，专门提到过软件开发的这个特点：
委托方对软件功能的需求往往不是一成不变的，而是会随着开发进程进行灵活、动态的调整。
这句话看起来很普通，但它其实改变了一个理解软件合同的方式。
很多老板理解合同，是一张地图：
签合同的时候把终点画出来，开发公司照着走，走到了就验收，验收以后付款。
但真实的软件项目更像一场不断修改路线的旅行。
走到一半才发现前面修路了。
客户临时想去另一个地方。
开发方发现原来的技术路线成本太高。
于是双方开始不断沟通：
这个改一下。
那个顺手加一下。
这个先做。
那个下个版本再说。
这些单独看都没什么。
真正麻烦的是，项目已经变了，判断项目是否完成的那套标准却没有跟着变。
项目管理领域把未经相应时间、成本调整而不断增加功能和要求的现象称为 scope creep，也就是范围不断蔓延。PMI长期讨论的解决方向，也不是简单地“拒绝变化”，而是让需求变化进入明确的变更管理程序。
换句话说：
变化本身未必危险。
没有重新定义变化之后的边界，才危险。
03
真正容易出问题的，是“谁来定义做完了”
有一个公开的软件开发案件很有意思。
双方原来的项目之外，后来又出现了24个标签修改任务。
发生争议以后，其中一方主张，这些修改本来就是原项目的一部分。
法院最后去看什么？
不只是看一句笼统的“乙方负责完成系统开发”。
它去看原来的需求说明书怎么写，新增功能应该走什么审批流程，后来双方实际用了什么工单，甚至比较了不同项目使用的验收单。
最后法院认定，这24个标签修改任务已经被双方排除在原项目范围之外，属于独立的合同关系。
表面上争的是：24个标签到底该不该做。
再往下一层争的是：到底用什么东西，来定义“原来的活”与“新增加的活”。
这时候你会发现，合同长度已经不是最重要的变量了。
真正重要的是一个项目有没有一套机制，不断回答下面这些问题：
谁能提出需求？
谁能确认需求？
什么叫修改，什么叫新增？
新增以后，价格和工期怎么算？
做到什么状态算交付？
谁有权确认验收？
对方一直不确认怎么办？
假如这些问题没有机制，合同即使写了50页，项目实际履行半年以后，双方也可能已经生活在两份完全不同的“合同”里。
甲方脑子里有一份。
乙方脑子里还有一份。
04
很多尾款纠纷，其实早在“项目边界失控”时就开始了
所以，如果一定要从这些事情里提炼一个判断，我觉得不是：
合同不重要。
恰恰相反，合同很重要。
也不是：
合同越详细越好。
更准确的说法可能是：
静态的合同，只解决了项目开始时的共识；真正决定一个长期项目能不能顺利收尾的，是变化发生以后，双方还能不能持续生产新的共识。
这也是“不完全契约”真正有意思的地方。
既然未来不可能被提前写完，那就不能只考虑“现在写什么”，还得考虑：
未来出现合同没有写过的事情时，到底怎么决定。
这么看，软件公司的法律风险有时候并不是从“对方违约”那一天才突然产生。
客户第一次说“这个很简单，你们顺便改一下”；
项目经理第一次没有确认，就答应了一个额外需求；
双方第一次对“已经完成”产生不同理解，却决定先把项目往下推进；
风险可能已经开始积累了。
以前我们总喜欢问：
合同写清楚了吗？
但对软件、AI、代运营这类持续变化的项目来说，也许还有一个更值得问的问题：
项目变了以后，你还有没有能力重新定义边界？
因为很多时候，真正决定最后那笔尾款能不能拿回来的，未必是合同有多少页。
而是一路走到最后，
“什么叫做完”这件事，到底还有没有一套双方承认的答案。
