项目上线后最容易产生争议的一句话是：“这个本来就应该有吧？”客户认为是Bug，供应商认为是新增。双方都可能有道理，因为项目开始时没有把范围写清。
要减少争议，不能只在合同里写“免费维护一年”，还要明确什么叫缺陷、什么叫变化、以什么版本和环境作为判断依据。
01 先建立可追溯的项目基线
需求确认书、原型、视觉稿、功能清单、技术说明、测试用例和验收记录共同构成基线。聊天里零散说过但未确认的内容，最容易产生不同理解。
上线后每次变更也要记录版本、原因和影响，不能继续沿用最初一份过时文档。
Bug与新增需求的典型判断
| 情况 | 更接近Bug | 更接近新增需求 |
|---|---|---|
| 已确认按钮无响应 | 确认范围内但无法完成 | 新增另一种操作方式 |
| 某浏览器显示异常 | 承诺支持范围内 | 要求支持未约定旧环境 |
| 内容需要修改 | 系统无法保存既有字段 | 新增字段、栏目或批量规则 |
| 第三方接口变化 | 原实现错误或未按文档 | 平台政策变化导致重做 |
| 移动端问题 | 已约定断点或设备失效 | 新增平板、横屏或特殊终端 |
| 性能问题 | 明显不符合约定指标 | 新增更高流量或更多媒体后优化 |
02 判断Bug需要三个条件
第一，有明确预期；第二，能稳定复现；第三，发生在约定环境和数据范围内。缺少预期时，应先确认产品规则，而不是直接要求开发“修”。
错误报告至少包含页面、账号、设备、步骤、预期、实际结果、截图或日志，避免只说“这里不对”。
03 环境变化不应全部归给任何一方
浏览器更新、服务器迁移、第三方接口、插件版本和安全政策变化可能导致原功能失效。合同应说明哪些属于维护，哪些需要评估。
供应商应及时说明风险，客户也应避免未经沟通自行修改代码、配置和插件后仍要求免费兜底。
04 小变更也会积累成范围失控
换一段文案通常很小，但“再加一个筛选”“顺便做个后台”可能影响数据、权限、设计、开发和测试。按影响而不是按一句话长度判断。
可以设置小额维护池处理零散调整，超过阈值进入变更单，兼顾效率与边界。
05 合同中写清维护响应和排期
免费Bug修复不等于7×24即时处理。应约定严重程度、响应时间、复现确认、修复窗口、发布方式和紧急回滚。
新增需求则需要确认范围、费用、周期、验收和对原计划的影响。
06 把争议转化为可验证的问题
遇到模糊情况，先共同复现、查看文档、确认业务影响，再决定免费修复、变更报价或双方分担。
长期合作中，一次小问题的责任归属没有关系透明重要。规则清楚，反而更容易灵活处理。
常见问题
上线后发现文案错字算Bug吗？
若供应商录入时与确认稿不一致，通常属于修复；若客户后续改文案，则属于内容更新。
浏览器升级后页面异常算Bug吗？
需看维护范围和兼容约定。可能是维护，也可能是环境变化产生的新工作。
免费维护是否包含新增页面？
通常不包含，除非合同明确。新增页面会涉及设计、开发、内容和测试。
如何处理难以复现的问题？
收集日志、设备、账号、时间和操作路径，先提高可复现性，再判断责任。
客户自己改代码后出问题怎么办？
应先定位改动影响。合同通常会把第三方修改导致的问题排除在免费维护外。
链接复制成功
