结论先说:一次修复的价值应按“可被验证的问题消除”计价,长期维护应按“维持某组前提条件所需投入”计价;两者混在一张账单里,规模小的时候看不出问题,一旦页面、模板或站点数量上升,就会因为例外不断出现而无法解释为什么同样的钱买到的结果不一样。更适合的判断方式不是问“这次诊断值多少”,而是先确认哪些问题属于一次性收敛,哪些问题会随规模反复出现。
假设一个站有二十个页面存在同一类模板错误,比如标题标签重复或分页链接指向错误。一次修复的合理计价对象是“这类错误在全部受影响页面中是否被消除”,而不是“改了几个文件”。因为前者可以被复查,后者不能说明结果。
但要注意一个边界:当页面数量从二十增加到两千,同一类错误可能不再来自模板,而是来自不同编辑、不同栏目或不同导入流程。此时原本按“一次修复”计价的方式会失效,因为问题源头不是一处,而是多处。继续按原来的单价乘以页面数,会把维护工作伪装成修复工作。
长期维护不是“定期看一眼”,而是维持一组前提:模板不被覆盖、新发布内容沿用既定结构、站点改版不重新引入旧问题。它的价值不体现在某次修复是否完成,而体现在例外出现时能否被及时发现并归位。
如果维护合同只写“每月检查”,却不说明检查哪些前提、例外由谁处理,那么规模扩大后就会出现争议:执行方认为已按约定检查,需求方认为问题仍然存在。这不是态度问题,而是计价对象没有对齐。
假设一个内容站最初只有主栏目,结构统一,一次修复可以覆盖大部分页面。后来新增了专题、聚合页和用户投稿,发布流程不再统一。此时如果仍按“一次修复”报价,执行方会遇到两类额外工作:一类是识别哪些新页面属于例外,另一类是决定例外是否要纳入统一规则。
这两类工作既不是原来的修复,也不是简单的维护,而是规则扩展。继续用旧的计价方式,要么执行方不断让利,要么需求方不断为同一类问题重复付费。两种结果都不健康。合理的做法是把规则扩展单独列出,说明它触发的前提,例如新增内容类型或发布流程变更。
下一步动作不是先谈价格,而是先约定一个可复查的节点。例如:在修复完成后,随机抽取若干页面,确认目标问题是否不再出现;在维护期内,记录例外出现的来源,并判断它属于原有前提失效,还是新增前提。
这个动作会直接影响后续计价:如果复查显示问题来自原有前提失效,属于维护范围;如果来自新增前提,属于规则扩展,需要重新评估。这样拆分之后,一次修复和长期维护各自对应不同的验证方式,也各自对应不同的投入依据。免费诊断可以作为起点,但它本身有时间或额度成本,不能替代后续的复查与归位工作。