企业买来一套能用的系统，再按自己的流程改一改，听起来比全新定制省钱。真正开工之后，报价和工期却经常被改写。超预算通常不是某一行代码写慢了，而是开工前没把改动会碰到什么算清楚。

原系统的边界往往不透明

成品后台能点的菜单，不等于能安全扩展的接口。字段含义、权限判断、缓存和定时任务写在代码里，却没有维护文档。评估时只能按页面估算，进场后才发现一个小改动要绕过三处旧逻辑。勘查本身就要时间，而这段时间很少写进第一版报价。

需求会在开发过程中变长

业务部门看到演示，会自然地补上审批、导出和消息。如果合同只写了方向，没有冻结范围，这些补充就会吃掉原计划的缓冲。二次开发尤其容易发生这种情况，因为旧系统已经在用，新想法会不断对照着现网提出来。

兼容历史数据比新做功能更贵

旧数据里有空值、重复值和多年前的特例。新字段上线后，列表、统计、导入导出和权限都要一起回归。测试范围往往大于新增页面本身，返工也就出现在联调周，而不是需求评审那一天。

环境和对接经常被漏掉

正式服务器的语言版本、证书、对象存储、短信和支付回调，和演示环境并不一致。任何一项要等第三方开通，日历就会往后推，人力却还在等待中占用。

开工前先把范围写成清单

要把预算守住，应先做接口和数据勘查，并写清下面几件事。范围外的需求单独估价，分阶段交付，每阶段用真实数据做一次回归。

• 本次要改的页面，以及明确不改的模块。
• 验收时使用哪一批真实数据，由谁确认通过。
• 勘查、联调、数据修正是否已单独列入报价。

这样做，超支会变成可见的变更，而不是项目结束时才出现的总账。