维护是产品生命周期中最容易被忽视的环节，但它决定了用户是否会在关键时刻“放弃”。当系统里堆积了数百个遗留bug，产品经理往往面对的是“先修哪个？”的难题。

我在多家 SaaS 公司工作时发现，最容易让团队陷入死循环的不是技术难度，而是“心理门槛”。我们需要把注意力从技术层面抽离，回到用户的心智模型上去。这里的核心工具就是心智模型：把用户的思考方式、期望和痛点用模型化的方式梳理出来，然后根据模型来排序。

先举个数据：Zendesk 2019 年的《客户满意度调查》显示，63% 的受访者在遇到软件 bug 后表示对该产品失去信任，并且其中 40% 在同一天内更换了供应商。再看一家中型 B2B SaaS，客户支持团队每月收到约 12,000 条工单，其中 30% 归因于老旧功能的错误。显而易见，老 bug 的“感知损失”远大于它们的技术难度。

如何用心智模型来评估优先级？我通常用以下三步：

① 映射用户痛点：先把所有 bug 按“导致用户误操作/误判”与“仅影响功能性/性能”分组；② 应用“损失厌恶”模型：对那些导致用户决策错误的 bug，给它们更高的权重；③ 加上“可视化成本”——修复难度 + 预期收益（比如用户留存、升级转化）。在这套体系下，一个小 bug 只要在用户决策链条中被“触发”，它的优先级就可能超过一个大但“隐形”的 bug。

案例回顾：Atlassian 在 2020 年的 JIRA 维护会议上，团队将“错误提示信息不清晰”与“功能不一致”排在同等重要的列表上。通过心智模型分析，团队发现后者虽然技术上更难，但用户在使用过程中更易误解项目状态，导致错误的任务分配。最终他们决定先修复前者，因为它在用户心智中占据了更高的“痛点优先级”。修复后，JIRA 的工单量在三个月内下降了 18%。

总结一句：老旧 bug 的“优先级”不应由代码行数决定，而由它们在用户心智模型中的位置决定。用心智模型，你可以把每一次“修复”变成一次“赢得信任”的机会。

你们在日常维护中，是不是也遇到过类似的“先关机”抉择？如果可以，你会如何用心智模型来重新排列它们的先后顺序？