为什么所有产品都在偷偷变"重"？

你有没有发现，曾经轻快的工具软件，用着用着就卡了？

不是电脑变慢了。是产品自己长胖了——而且胖得悄无声息，胖得理直气壮。这篇文章想聊的，就是这种"温水煮青蛙"式的体验劣化：它最初根本不是问题，也从来不是某个具体决策导致的。

原文作者用亲身经历拆解了这个过程。我把它整理成五个要点，看看你的产品是不是也在走这条路。

一、第一阶段的幻觉：这叫"迭代"，不叫"膨胀"

事情通常从小功能开始。

作者描述的场景很典型：团队收到用户反馈，"能不能加个导出按钮？"——合理需求，两天做完。下周另一个声音："导出格式能不能多几种？"——也合理，再排一期。再然后："能不能设置自动导出？"

每个需求单独看都没毛病。但作者指出关键盲区：「没有人计算过这三个功能叠加后的内存占用」。导出模块调用的库、自动任务的后台进程、多格式兼容的代码分支——它们像阁楼里的旧家具，越堆越多，却从不上清单。

更隐蔽的是"临时方案"的永久性。作者提到一个细节：某次为了赶版本，团队用了一个「"先这样，上线后再优化"的缓存机制」。三年后，这个临时方案仍在服役，而当初写代码的人已经离职。

技术债（Technical Debt，指为短期目标而妥协的技术代价）就是这样变成技术遗产的。

二、第二阶段的共谋：数据好看，体验沉默

产品变重的过程中，仪表盘（Dashboard，数据可视化界面）通常是帮凶。

作者观察到一种结构性矛盾：「新增功能的使用率、用户停留时长、功能覆盖率——这些指标全在涨」，但「页面加载时间、崩溃率、用户投诉量」要么不在考核范围，要么被归入"技术团队的事"。

结果就是：产品经理有动力做加法，没动力做减法。作者举了一个具体例子：某次A/B测试显示，新加的"智能推荐"模块让点击率提升12%，于是全量上线。但测试周期只有两周，「没人追踪三个月后的卸载率变化」。

更讽刺的是"性能预算"的形同虚设。作者提到团队其实有过规定：「每个新功能必须通过性能基线测试」。但实际操作中，"基线"本身在悄悄上移——第一次是200ms，半年后变成500ms，一年后变成"只要不崩溃就行"。

数字不会撒谎，但数字的选择性呈现会。

三、第三阶段的麻木：用户学会了忍受

这是最残酷的转折点。

作者描述了一个被忽视的现象：「重度用户往往是最沉默的抱怨者」。他们已经投入学习时间、建立了工作流、甚至形成了肌肉记忆。软件变慢？他们会换更贵的电脑，而不是换软件。

作者引用了一位用户的原话：「"我以为是我老了，跟不上新版本的节奏"」。这种自我归因让产品团队错失了关键信号。客服工单里很少出现"软件太卡"，更多的是"这个功能怎么用"——后者被解读为教育机会，前者根本不存在。

竞争环境还加速了这种麻木。作者指出：「当所有竞品都在变重时，用户的参照系也被重置了」。五年前3秒启动算慢，现在8秒启动"还能接受"——不是技术进步了，是预期管理成功了。

作者甚至提到一个黑色幽默：某次用户调研，「有人把"启动速度"列为满意项，理由是"比隔壁竞品快2秒"」。

四、第四阶段的结构性困境：谁该为"变重"负责？

作者试图追溯责任，发现指向四面八方。

技术团队说：「需求排期太紧，没时间重构」。产品团队说：「竞品有这个功能，我们必须跟」。设计团队说：「交互流程已经最简了，是技术实现的问题」。管理层说：「Q3要冲DAU（日活跃用户），性能优化排Q4」——然后Q4永远有更重要的战役。

作者特别提到了一种组织层面的"责任稀释"：「每个决策都有合理的业务理由，但没人对体验的整体性负责」。架构师关心系统稳定性，产品经理关心功能交付，运营关心活动数据——「性能体验成了三不管地带」。

更深层的问题是考核周期的错配。作者观察到：「新功能上线两周就能看到数据反馈，性能劣化需要六个月才能显现」。在季度OKR（目标与关键成果）的驱动下，选择不言而喻。

作者引用了一位工程师的私下吐槽：「"我们都知道代码在腐烂，但腐烂是线性的，而裁员是突然的"」。

五、第五阶段的破局点：什么时候"减肥"来得及？

作者没有只给诊断，也尝试开药方——虽然承认都很艰难。

第一个可行方向是「"性能预算"的硬约束」。不是设目标，而是设红线：作者提到某团队的实践，「新功能若使核心路径延迟超过100ms，直接打回，无例外」。关键是这个红线不随版本浮动，「三年没变过」。代价是功能上线速度变慢，但「技术债增速被遏制住了」。

第二个方向是「用户分层的勇气」。作者质疑了"一个版本服务所有人"的默认假设：「为什么重度编辑用户和偶尔查看的用户，必须用同一套代码？」某产品尝试将核心功能与高级功能物理分离，「基础包保持轻量，插件包按需加载」——结果基础用户的留存反而上升。

第三个方向最反直觉：「主动淘汰旧功能」。作者强调这不是"冻结维护"，而是「彻底移除代码」。某团队每季度强制下线使用率低于5%的功能，「无论当初是谁力推的」。阻力极大，但「代码库的可维护性显著改善，新功能开发速度反而提升」。

作者最后提到一个检验标准：「如果你的产品需要写"使用技巧"来教用户绕过卡顿，说明已经病得不轻」。

这篇文章的价值不在于技术方案，而在于它命名了一种被忽视的慢性病。产品变重不是事故，是系统性的组织行为结果；不是某个坏决策，是无数个"合理"决策的累积效应。

对科技从业者来说，警惕信号其实很明显：当你的团队开始用"用户电脑配置太低"来解释体验问题时，胖症已经进入晚期。