软件维护与新增需求的边界，不能按“改动大小”判断，而应看系统原有约定是否已经覆盖该行为。原功能无法按既定流程运行，通常属于维护；业务目标、角色权限、处理流程或数据范围发生扩展，则更接近新增需求。这个区分直接影响费用、排期和验收责任。
先判断：系统是否“应该这样做”
如果订单原本支持创建、支付、取消和退款，但某个既有流程无法提交、状态同步错误，或已明确的权限没有生效，这类问题属于缺陷修复。开发方应依据原功能清单、原型、合同约定和验收标准处理，而不能因为涉及代码修改就直接认定为新开发。
相反，如果原报价只包含订单创建和查询，项目后续要求增加退款、售后、导出、批量审核，或者新增客服、财务等角色及其数据权限，便是业务范围扩展。即使只是增加一个按钮，只要它引入了新的流程、权限、接口或数据处理，也不能简单归入维护。
四个边界判断
判断争议时，可以依次核对：
- 需求依据：原功能清单、原型或合同是否明确写过；
- 业务目标：是恢复既定行为，还是增加新的业务能力；
- 影响范围：是否新增页面、角色、接口、数据字段或异常处理；
- 验收标准：原验收条件能否覆盖本次改动，还是需要重新定义。
“免费维护一年”也不能自动等同于“免费开发新功能”。维护范围应明确包含程序缺陷、第三方接口适配、服务器问题还是仅限已有功能修复；新增分销、直播、多组织管理等需求，则应单独评估工作量和费用。
用变更单固定结论
遇到边界不清的事项，不要只在聊天记录中确认。应形成变更单，写明现状、目标、涉及角色、页面与流程、接口影响、测试范围、交付时间及费用。若双方无法证明某项能力已被原合同覆盖，就应回到功能清单和验收标准，而不是依据“改动看起来很小”作判断。
专业的维护管理，不是拒绝变化，而是把缺陷修复与业务扩展分开计量。这样既避免开发方把原本应修复的问题包装成增项，也防止需求方把新的业务目标塞进模糊的售后承诺中。
