需求冻结不是把项目“锁死”，而是为需求变化设置清晰的成本边界。开发预算失控，往往不是因为某个功能本身昂贵，而是因为需求在设计、开发、测试阶段反复变化，导致多个岗位同时返工，交付时间也随之延长。
真正有效的冻结，应当与项目阶段对应，而不是只约定一个模糊的“后续不再改需求”。
先冻结业务流程，再冻结功能清单
原型阶段应优先确认用户角色、核心操作路径和页面结构。比如“用户提交申请”这一描述，还需要明确是否包含审批节点、抄送人员、审批记录和消息提醒。若这些内容在开发后才补充，就不再是简单的页面调整，而可能涉及后台权限、接口、数据库和测试用例。
进入开发前，应形成明确的功能清单，并区分首期必须交付、后续迭代和明确不包含的内容。展示型项目可以优先保留核心流程，暂缓复杂后台和个性化功能；带有订单、支付或运营后台的项目，则更适合采用“核心版本先上线、附加功能后迭代”的方式。
冻结后，所有变化都要经过评估
需求冻结后并非不能修改，而是新增内容必须经过变更确认。变更单至少应写清变更内容、影响模块、增加人天、增加金额、是否顺延，以及双方的确认记录。
判断费用时，不能只看“增加了几个按钮”。若变化仅涉及文案、颜色或简单字段调整，可能属于原范围；若涉及业务流程、数据结构、权限或多个端同步修改，就应单独评估。延期新增费用可以拆成延期投入人天、返工费用和第三方费用，不能只按日历上多出的天数计算。
测试阶段只处理阻断问题
测试前应冻结核心规则，尤其是支付、审批和权限逻辑。测试阶段发现的原需求漏做或未按确认原型实现，通常属于交付责任；验收时提出文档中没有写明的新规则，则可能形成增项。
上线前应只处理影响发布的缺陷，普通优化放入下一版本。这样既能避免反复回归测试，也能减少错过上线窗口、重复培训和运营计划调整带来的隐性成本。需求冻结的本质，是让每一次变化都先被看见、被估价，再决定是否值得占用当前预算。
