前阵子朋友找我哭诉，说他的项目预算本来谈好十几万，做到一半，钱不够了。我问是不是被报价坑了，他说不是——报价挺实在。问题出在中间那几个月，业务方每次开会都"顺手加一点"：加个导出、加个审批流、加个角色权限。每一次单独看都不大，加起来就是另一回事了。
这就是需求蔓延最讨厌的地方。它不是某天突然冒出一个巨型需求把预算炸掉，而是很多个"这个应该很快吧"悄悄累加。你很难在某个具体节点上喊停，因为每一次改动看起来都合理，都值得做。
钱到底是怎么一点点没的
原来源里有一组数字，我觉得挺有说服力：一个中等复杂度的功能调整，评估下来常见是 3 到 10 人天。按 1000 到 1800 元每人天换算，一次变更就是几千到一两万。项目周期里来上五六次，十几万就被吃掉了。
关键在于单次金额看着不心疼。几千块钱，跟总价比起来不算什么，决策时很容易点头。可预算不看单次，看累计。而且变更的成本往往不止开发那一块：改完要重新联调，要回归测试，要重新走验收，原本排好的工期还得往后挪。真正贵的不是那几行代码，是它牵连出来的一整串动作。
还有一个隐形推手——口头答应。会上说一句"这里加个筛选"，没人记账，没人评估，等做完了才发现工时对不上。需求蔓延之所以蔓延，本质上就是因为缺少一个把"随口一提"变成"书面记录"的关卡。
我自己踩过之后总结的三道闸
第一道，范围要写成能签字的东西。不是几十页文档，就一页：谁用、核心流程走到哪、必做和暂缓分开列，最重要的是把"不做什么"也写清楚。我记得有一次就是漏了这条，后面为了"要不要支持多语言"来回扯了快两周。
第二道，原型得有个冻结时点。冻结不是不许改，而是把改动从讨论变成流程：提变更单、估工时、算费用、看要不要顺延。评审完留几天冷静期让大家集中提意见，能挡掉不少反复。
第三道，变更单价提前谈。合同里附上人天单价表，再约定一个累计上限，比如变更金额超过总额某个比例就触发一次范围重评审。这条特别有用，它逼着双方在项目还没变形之前坐下来重新排优先级。
说白了，需求蔓延防的不是客户想加东西——想加是正常的。防的是加得没数。把边界、冻结点和单价这三件事在开工前摆到桌面上，比事后吵谁该掏钱高效得多。
