网站优化报价：报价按工时计费时怎样判断返工归属
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dc204dccb66a.html
📄
网站优化报价：报价按工时计费时怎样判断返工归属
判断返工归属，先看返工针对的是原有交付物本身，还是新暴露的需求或旧系统历史遗留。前者通常由执行方承担工时，后者应单独确认是否追加预算。如果合同只写“按工时计费”，却没有把返工触发条件写清，结算时双方都会陷入各说各话。
先把返工分成三类，再谈谁付工时
按工时计费的优化项目，返工大致落在三个来源：一是执行方交付未达约定标准，比如页面结构与约定不符、改错页面、遗漏约定项；二是需求方在验收后新增或改变目标，比如原本只改标题与内链，后来要求重做栏目结构；三是旧系统或旧内容本身的问题在改动中被暴露，比如旧模板无响应式结构、旧页面存在大量重复内容、旧接口无人维护。
这三类的工时归属不同。第一类应计入执行方成本，不应计入结算工时；第二类属于变更，应走变更单；第三类要看合同是否包含“现状勘查”义务，以及报价时是否已说明旧系统风险。
保留、改写还是退出：先判断旧资产还有没有承接价值
返工争议常出现在旧内容、旧系统或旧合作关系需要退出的时候。此时真正的决策不是“谁多干了几小时”，而是这块旧资产值不值得继续投入。
- 保留适用前提：旧页面仍有稳定访问入口、有外部链接指向、内容主体仍准确，只是结构或元数据过时。此时返工范围小，按工时追加通常合理。
- 改写适用前提：旧内容主题仍与当前业务相关，但表达、结构、内链已明显落后。改写比新建省时间，但前提是原素材可复用，否则工时不会比新建低。
- 退出适用前提：旧页面无访问、无外链、内容已失效，或旧系统维护成本持续高于替换成本。退出时若还要求“顺手优化”，这部分工时不应混入原报价。
把这三条判断写进变更单，返工归属就有了依据：保留和改写产生的额外工时，按变更处理；退出产生的清理工时，单独列项。
报价单里要能区分“修复”和“变更”的触发条件
按工时计费时，最容易模糊的是“修复”与“变更”的边界。建议在报价说明中写明：交付物与约定清单不一致，属于修复，不计入追加工时；约定清单之外的新要求，属于变更，需确认工时后再执行。
一个假设例子：原报价约定“调整 20 个页面的标题与描述”，执行中发现其中 8 个页面因旧系统模板限制无法直接修改，需要先改模板。若合同写明“现状勘查由需求方提供”，这 8 个页面的模板改动应作为变更单独立项；若合同写明“执行方负责现状勘查并承担适配”，则这部分属于执行方应预见的工作。两种写法都成立，但结算结果完全不同。
发现返工后，先做一次范围确认再继续
当执行方报告“需要返工”时，需求方不要直接同意追加，也不要直接拒绝。可以要求对方提供三样东西：返工涉及的具体页面或文件清单、每项对应的原约定条目、预计工时。拿到清单后，对照报价单逐项判断属于修复还是变更。
这个动作的结果会直接影响下一步：如果多数项目属于修复，应要求执行方在不变更报价的前提下完成；如果多数属于变更，应评估是否值得继续，还是缩小范围、只保留仍有承接价值的部分。若判断结果是旧系统拖累过大，退出旧系统可能比继续按工时修补更省总成本。
结算前把工时记录和交付物对应起来
按工时计费的项目，结算依据不应只是工时总数，而应能对应到具体交付物。可以要求执行方按“日期—页面或文件—动作—工时”记录，并在验收时与变更单核对。这样做的结果是：修复类工时被识别出来，不会重复计费；变更类工时被确认，不会在结算时突然出现。
如果双方对某几项归属仍有分歧，可以先就无争议部分结算，把争议项单独列出，注明各自依据。这比整体拖延结算更能保护继续合作的部分，也便于决定哪些旧内容或旧系统确实应该退出。
