项目进入验收阶段后，客户提出“修改”，并不意味着都应纳入原报价。判断关键不在于意见听起来有多具体，而在于它是否源于已确认的交付范围，以及是否改变了原约定的功能、内容、结构或工作量。

先看是否违反已确认范围

验收修改，是对既定成果进行纠偏或完善。典型情形包括：页面中的字段与已确认需求不一致、约定功能无法正常使用、交付文件缺少已承诺的内容，或成果未达到事先写明的验收标准。这类问题属于范围内问题，应在当前修订中处理，不能因为客户在验收阶段提出就重新收费。

范围变更则是客户提出了原清单中没有的内容，或者要求改变已经确认的方案。例如，原本只约定既有页面的字段调整，后来新增筛选条件、权限逻辑，或要求重做已经确认的核心流程。这些要求会增加工作量、改变排期，甚至影响技术方案，应作为新增需求单独评估。

用三个问题快速判断

收到反馈后，不要立即回复“可以修改”，而应逐项核对：

1. 该要求是否能在已确认的需求、交付清单或验收标准中找到依据？
2. 它是在修复“不符合约定”的结果，还是增加了原本没有的能力？
3. 是否会影响工作量、交付时间、技术方案或付款节点？

如果答案分别指向“有依据、修复偏差、影响有限”，通常属于验收修改；如果是“没有依据、增加能力、需要额外投入”，则属于范围变更。对无法直接判断的调整，应先暂停相关工作，避免默认承担成本。

反馈必须形成范围判断

交付时，建议把反馈分成两组：A组为原范围内问题，安排在本次修订中；B组为新增功能或方案变化，另行提交工期和报价。反馈记录应写明具体页面或文件、问题描述、期望结果、是否影响当前阶段，以及对应的处理决定。

最终验收不是追求客户“完全满意”，而是确认约定成果是否完成。只有把验收修改与范围变更分开，项目才不会因为无限追加的“最后修改”持续延期，尾款也才有清晰的形成依据。