建站价格：固定总价下范围变化怎样计算增减项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f21ceea9b272.html
📄
建站价格：固定总价下范围变化怎样计算增减项
固定总价合同并不等于价格永远不动，而是指在约定的范围基线内总价不变；一旦范围发生增减，就要按合同里预先写好的单价或费率表来调整。如果合同只写了总价、没写变更计价方式，退出旧系统或旧合作关系时最容易出现扯皮：供应商认为减少的页面不值钱、增加的功能要按新项目报价，而你需要的是可核算的增减项。
为什么“减了东西反而更贵”会同时出现两种解释
假设你退出旧合作关系，决定保留品牌站的一部分栏目，砍掉商城模块，同时新增一个会员登录入口。供应商报出的变更价可能比原总价还高。这不一定是在宰你，常见有两种解释。
解释一：固定总价里含有不可退的启动成本。需求调研、信息架构、设计规范、部署环境这些工作已经发生，砍掉商城模块并不会让这些投入退回。减少的范围只节省了尚未发生的开发工时，而已发生的部分仍要分摊到剩余范围上。
解释二：剩余范围的单价被重新计算。原报价是按整体规模给的折扣价，范围缩小后，供应商把设计、测试、沟通等固定开销重新摊到更小的工程量上，单位成本自然上升。这种情况下，减少范围带来的节省被摊薄，甚至被抵消。
用一组可核对的证据区分两种解释
要判断属于哪种情况，不要只看变更后的总价，而要看报价单里有没有可拆分的成本结构。可以要求供应商提供三样东西：原报价的工作量分解、已发生工时的记录方式、以及各模块的独立计价。如果原报价只有一行总价，任何解释都无法验证，这时应当先补一份范围基线，再谈增减。
能区分两种解释的证据包括：
- 被砍模块是否已有可交付物（设计稿、原型、已部署代码）。有，说明成本已发生，减少范围不等于退款。
- 剩余模块的单价是否与原报价一致。一致，说明只是固定开销被重新分摊；明显上浮，说明供应商在借变更重新定价。
- 变更工作是否触发了返工。例如退出旧系统时，数据迁移和旧链接重定向往往不在原范围内，这部分属于新增而非减少。
一个可操作的判断动作是：把变更拆成“删除项”“新增项”“因删除而必须做的补救项”三列，分别套用合同单价。如果合同没有单价，就用原报价中同类工作的单位价格作为参照，而不是让供应商重新报一个打包价。做完这一步，你会发现有些所谓的增加项其实是删除项的必要补救，例如删掉商城后仍需保留订单查询入口，这类工作应当按删除项的处理逻辑协商，而不是按全新功能计价。
退出旧系统时，哪些部分值得保留、哪些应当计入减项
旧内容、旧系统或旧合作关系退出时，保留仍然有价值的部分通常比全部推倒更省。判断标准不是“还能不能用”，而是“保留它是否需要持续付费或承担迁移成本”。
值得保留的通常是：已经积累的静态内容、有独立价值的数据、以及不依赖旧供应商专有技术的页面结构。这些部分的迁移成本可控，且迁移后不再产生旧合作关系下的周期性费用。
应当计入减项的是：旧系统特有的功能模块、与旧供应商绑定的部署方式、以及已经确认不再维护的栏目。减项的计算依据是这些工作在原合同中对应的金额，而不是供应商口头给出的“省不了多少”。
需要提醒的是，减项不等于退款。固定总价合同下，减少范围通常只影响后续付款节点，已支付的部分是否退还取决于合同约定和已完成工作量。这一点在退出谈判前必须确认，否则容易把“减项”误解为“应退金额”。
把增减项写进变更单的具体做法
无论退出还是继续合作，范围变化都应当落到一份变更单上，而不是聊天记录里的口头确认。变更单至少包含：变更前后的范围对照、每一项的计价依据、对总价和工期的影响、以及付款节点的调整。
计价依据优先使用合同附件中的单价表。如果合同没有单价表，可以约定按原报价中同类工作的平均单位价格计算，并注明这个平均值是怎么算出来的。对于无法对应到原报价的新增工作，单独列出来按新工作报价，不要和减项混在一起抵消。
在退出场景下，还要额外确认旧系统的数据导出格式、迁移完成标准和旧链接处理方式。这些工作如果不在原范围内，应当作为新增项单独计价，而不是默认包含在减项里。把这一步做完，后续的付款和验收才有依据，也才能判断继续保留的部分是否真的比全部重建更划算。
