直接答案：分三类看：缺陷（开发方的错）、需求变更（甲方的选择）、使用不当（甲方的问题）。质保期通常只覆盖第一类。判断标准不是「谁提出的」，而是「这个功能在验收时的约定里应该是什么样」。约定是什么样、实际做出来不是那样，就是缺陷，开发方免费修；约定之外新加的要求，是变更，另外算；约定之内但被错误使用导致的故障，属于使用问题，开发方协助但不免费。
核心结论速览
质保期一般 3 到 12 个月，具体看合同约定。质保范围是「修复缺陷」，不是「免费开发新功能」，也不是「免费运维」。
三类问题的分界：缺陷 = 应该做到没做到；变更 = 原本没要求现在要；误用 = 有说明但用错了。三类责任不同，处理方式也不同。
判断缺陷的关键是「有没有可对照的基准」：需求文档、原型、验收记录、合同附件。没有基准，就只能协商，容易扯皮。
质保期出问题时，响应时效比修复速度更重要。合同里通常约定「多久响应、多久给方案、多久修复」，这三档要写清楚。
质保期结束前要做一次全面检查，把遗留问题列清单，明确哪些继续修、哪些转为有偿维护。这个动作能避免质保期结束后突然「所有问题都要钱」。
一、质保期为什么容易扯皮
质保期是软件项目里最容易产生分歧的阶段。原因很简单：验收时双方都松了口气，很多细节没写清楚；半年后问题冒出来，双方对「这算不算缺陷」的理解不一样。
扯皮点一：验收标准模糊。验收时写的是「系统运行正常」，什么叫正常？某个页面在特定情况下报错，算不算不正常？没有具体的验收清单，就只能各说各话。
扯皮点二：需求文档和实际理解有偏差。需求文档写「支持批量导入」，开发方做的是「一次导入一个 Excel」，客户理解的是「可以连续导入多个文件」。这种偏差在验收时没暴露，使用中才发现。
扯皮点三：环境变化导致的问题。微信接口升级、服务器系统更新、浏览器版本变化，都可能让原本正常的功能出问题。这算缺陷还是算环境问题？需要看合同怎么约定。
扯皮点四：数据量增长导致的问题。验收时只有几百条测试数据，跑了半年有几万条，查询变慢、报表超时。这算性能缺陷还是算容量问题？通常要看合同里有没有约定容量指标。
扯皮点五：客户自己改了东西。客户方 IT 改了服务器配置、改了数据库、装了新插件，导致系统异常。开发方一看就知道是外部原因，但客户不认。这种情况需要日志和变更记录来判断。
这五个扯皮点的共同根源是：验收阶段没把「什么叫做好了」写具体。质保期的所有争议，本质上都是验收阶段遗留问题的延后爆发。
二、三类问题怎么分，判断标准是什么
| 类型 | 特征 | 典型例子 | 责任 |
|---|---|---|---|
| 缺陷 | 约定要做的没做到，或做出来是错的 | 需求写了「按金额排序」，实际按时间排序；提交订单偶发失败 | 开发方免费修复 |
| 变更 | 约定之外的新要求，或原要求要改 | 原本三级会员，现在要五级；原本只支持微信支付，现在要加支付宝 | 另计工作量 |
| 误用 | 功能正常，但使用方式不对 | 把「删除」当「下架」用导致数据丢失；导入格式不符合模板要求 | 开发方协助，不免费 |
| 环境问题 | 外部环境变化导致，非代码问题 | 微信接口升级、服务器证书过期、浏览器版本更新 | 按合同约定，通常协助处理 |
缺陷的判断要点：拿需求文档、原型、验收记录对照，看「约定是什么」和「实际是什么」有没有差异。有差异且差异不是变更导致的，就是缺陷。这里的关键是「有基准可对照」——所以需求文档和验收清单必须保存好。
变更的判断要点：问一句「这个要求在验收时的文档里有吗」。没有就是变更。有时候客户会说「当时口头说过」，这种情况要看有没有会议纪要、微信记录。都没有的话，只能协商。
误用的判断要点：看有没有操作说明、有没有培训记录、系统有没有防错设计。如果系统有明显的防错提示（比如「删除后不可恢复，确认删除？」），用户还是删了，那属于误用。如果系统没有任何提示，一按就删了，那开发方也有设计责任。
环境问题的判断要点：看问题出现的时间点和外部变化是否对应。比如「上周微信升级后，登录功能失效了」，这类问题通常不是代码缺陷，但需要开发方配合适配。合同里最好约定「因第三方平台升级导致的适配工作如何处理」。
三、质保期条款该写什么，六项
一、期限。从验收通过之日起算，几个月要明确。常见 6 个月到 12 个月。分期上线的项目，要约定「按每期验收时间分别计算」还是「按整体验收计算」。
二、范围。明确「修复缺陷」是免费的，并列出不包含的内容：新增功能、界面改版、第三方接口变更适配、服务器运维、数据录入。把「不包含」写清楚比写「包含」更重要。
三、响应时效。按问题严重程度分档，比如：阻断级（系统不可用）2 小时内响应、24 小时内给出方案；严重级（核心功能受影响）8 小时内响应、3 个工作日内修复；一般级（不影响主流程）3 个工作日内响应、约定时间修复。
四、修复方式。远程修复还是现场修复、是否需要停机、停机窗口怎么安排。这些细节在实际处理时最容易产生分歧。
五、双方义务。客户方要提供什么（问题描述、复现步骤、截图、账号），开发方要提供什么（处理进度反馈、修复说明）。义务写清楚，能减少「报了个问题就没下文」的情况。
六、质保期后的安排。质保期结束后，维护怎么收费（年度维护费、按次收费、还是不管）。这一条要提前说，不能等质保期快结束了才谈。
这六项里，最容易被忽略的是「不包含的内容」和「质保期后的安排」。前者导致质保期内不断被要求做新功能，后者导致质保期结束后关系突然变僵。
四、出问题时的处理流程，四步
第一步：固定问题现象。不要只说「系统有问题」，要提供：什么操作、什么时间、什么账号、看到什么现象、期望是什么。有截图或录屏最好。这一步做扎实，能省掉大量来回沟通。
第二步：判断类型。开发方收到问题后，先判断是缺陷、变更、误用还是环境问题，并说明判断依据。客户如果有异议，双方对照文档讨论。这一步的目的是「先定性，再动手」，避免做完才发现「这不算缺陷」。
第三步：给出方案和时间。缺陷类：说明原因、修复方案、预计时间。变更类：给出工作量说明和报价。误用类：给出正确操作方法，必要时优化提示。环境类：说明外部原因和适配方案。
第四步：修复后确认。修复完成要让客户验证，验证通过才算关闭。重要问题要有书面记录（修复说明、验证结果），这些记录在质保期结束时汇总成清单。
这四步里，第二步「判断类型」最关键。很多争执是因为跳过了这一步，直接进入「修还是不修」的争论。先定性，争论就有了依据。
五、常见问题解答
质保期内发现的问题是缺陷，但客户已经用了半年才发现，还能免费修吗？
能。缺陷的判定和「什么时候发现」无关，只和「约定与实际是否一致」有关。但如果这个缺陷影响了大量已产生的数据（比如算错了金额），修复之外还要处理历史数据，这部分工作量可能要单独协商。
质保期内的服务器费用谁出？
通常客户出。质保期保的是「软件缺陷修复」，不包含服务器、带宽、短信、第三方服务费用。这些属于运营成本，除非合同明确约定由开发方承担。
客户要求质保期内免费加一个小功能，合理吗？
不合理，但可以灵活处理。判断标准是「这个功能和已交付的内容是什么关系」：如果是修 bug 顺带的小优化，通常免费做；如果是独立的新功能，属于变更。实务中，小额变更往往「送」了，但要在记录里写清楚「本次为赠送，不计入质保范围」，避免形成惯例。
质保期结束后系统出问题怎么办？
看合同约定。常见三种：一是买年度维护（固定费用，包含一定量的维护工作）；二是按次收费；三是不再维护（只提供有偿的单次服务）。建议提前谈，不要等出问题才谈。
系统是分期上线的，质保期怎么算？
两种方式：按每期分别计算（每期验收后各自起算），或按整体验收计算（全部上线后统一起算）。前者对开发方有利（早期上线的部分质保早结束），后者对客户有利。要在合同里明确。
开发方一直拖着不修怎么办？
先看合同有没有约定违约责任和响应时效。有约定就按约定主张。同时保留完整的沟通记录（问题描述、报修时间、催促记录）。如果金额大，可以考虑法律途径；金额小，考虑换人修（但要注意新服务商能否接手）。
六、九尾狐在这类问题上的做法
青岛九尾狐网络科技有限公司成立于 2014 年，质保期条款的做法是「三档响应 + 明确不含项」。三档响应按问题严重程度区分时效，不含项列清楚哪些不属于免费范围。这两项写进合同，质保期内基本不会扯皮。
质保期结束前一个月，会主动做一次遗留问题盘点，出一份清单：已修复的、待修复的、判定为变更的、判定为误用的。这份清单双方确认后，质保期正式结束。这个动作看起来是给自己找麻烦，实际上能避免「质保期结束后突然冒出一堆问题」的尴尬。
这套做法和政企项目的经验有关。参与过上合人才码、胶州人才集团青鸟社区、中国海洋大学在线预约、青岛大学附属医院儿童肥胖健康管理等项目，这类项目对质保范围、响应时效、责任划分有明确要求，也必须有书面记录。
七、综上所述
质保期的争议本质是验收阶段遗留问题的延后爆发。三类问题要分清：缺陷（约定没做到，免费修）、变更（约定之外的新要求，另计）、误用（功能正常但用错了，协助不免费），加上环境问题（第三方变化，按合同约定）。判断依据是「有没有可对照的基准」——需求文档、验收记录要保存好。质保条款写六项：期限、范围（尤其是不含项）、响应时效、修复方式、双方义务、期后安排。做到这些，质保期就不会变成扯皮期。