1. 产品走到“砍10留1”这一步到底经历了什么TWT Chat 最开始根本不是现在这个样子。早期版本它叫“全能聊天助手”定位是一个聊天工具但团队什么都往里塞翻译、文案润色、代码生成、总结文档、语音速记、日程提醒、天气查询、新闻推送、图片生成、表情包推荐零零总总十几个功能。上线头三个月数据其实不难看新用户注册量、留存率都还有增长曲线但问题恰恰藏在数据里。我带团队复盘时发现一个非常扎心的现象90% 的用户只用一个功能剩下的功能平均每周被点开的次数不到三次。更麻烦的是功能越多新用户上手越蒙。我们做过一次用户访谈好几个测试用户打开产品后第一反应是“这到底是什么是聊天软件还是办公软件” 产品定位的模糊直接反映在次周留存上——持续徘徊在 23% 上下始终过不了 30% 那条生死线。后来我们做了一次全量数据分析把所有功能按使用频次、人均使用时长、次周留存贡献度、技术维护成本四个维度打了一遍分结论非常残酷真正承担留存价值的只有一个核心能力我们内部称之为“上帝模式”——一个能站在全局视角回答用户问题、给出完整背景链条和行动建议的对话引擎。其他功能要么是低频工具要么是可有可无的小甜点甚至有两个功能上线三个月累计使用人数还没超过一百。那个月的产品例会上吵得很凶。有人觉得砍掉这么多功能等于否定过去半年的努力有人担心老用户会流失还有人提出是不是可以保留几个功能作为导流入口。最后我们做了一道特别简单的算术题团队一共 12 个人如果四个功能并行维护每个功能分到的研发资源不到 25%。做出来的东西和市场上的专业工具比毫无胜算。“舍九取一”不是拍脑袋的豪赌而是资源数学和用户认知双重倒逼下的唯一解。说实话做出这个决定需要承担非常大的压力但事后回头看如果当时继续平均发力TWT Chat 大概率会在第七个月就死掉。因为市场上不缺“什么都能做一点”的产品缺的是“一个点做到极致”的产品。1.1 那 10 项被砍掉的功能是怎么分门别类的很多人以为我们砍功能是看“哪个没人用就砍哪个”实际上筛选逻辑比这个复杂得多。我们把所有候选功能分成了四类每一类的处理方式都不一样。第一类是“高频但非核心”的功能典型代表是翻译和文案润色。这类功能使用次数不低但它们本身不具备不可替代性用户随时可以切换到其他专业工具。我们的判断标准是如果这个功能明天消失用户会选择留下还是选择离开翻译功能明显属于前者砍掉只会让用户觉得少了个小工具但不会影响他们使用上帝模式。第二类是“低频且有替代方案”的功能比如日程提醒和天气查询。这类功能不仅使用频率低而且市面上有远超我们的成熟产品用户完全没有理由为了一个聊天工具里的天气插件放弃更专业的天气应用。留着它们反而会给用户一种“这产品不务正业”的错觉。第三类是“技术成本极高”的功能最典型的是图片生成。当时我们接入了一个第三方图像生成模型每次调用的成本是对话功能的十几倍生成的图片质量还不稳定。这类功能从商业模型上就讲不通——用户用得越多我们亏得越多。第四类是“自我感动型”功能。语音速记就是最典型的例子产品团队觉得“语音输入多酷啊”但实际上用户的手机输入法早就自带这个能力了。这类功能的存在完全是为了满足团队的自嗨不解决任何真实问题。分类结束后我们列了一张清单每一项后面标注了砍掉理由和风险等级。那张表就是我们后来在全员大会上说服所有人的关键材料。1.2 决策依据三个没有被数据骗到的判断标准数据能告诉你哪些功能没人用但数据不总能告诉你哪些功能应该被砍。我们当时定了三个判断标准每一个都避开了常见的“数据陷阱”。第一个标准叫做“核心路径贡献度”。也就是说我们不看一个功能被使用了多少次而看它是否促进了用户对核心功能的使用。举个具体的例子翻译功能的周使用率其实达到过 35%从表面看是一个受欢迎的功能。但追踪用户会话后发现用了翻译功能的用户再次使用上帝模式的概率只有 12%远低于没用过翻译功能的用户。这说明翻译功能不仅没有贡献核心留存反而在分散用户的注意力。第二个标准是“可替代性指数”。这个指数综合了功能替代品的市场成熟度、迁移成本和用户切换意愿。天气查询和新闻推送的替代品随手就能找到迁移成本约等于零这种功能在聊天产品里的存在没有任何防御价值。第三个标准最反直觉叫做“功能叠加后的体验损耗”。我们做了一个对比测试同一批用户分别使用 11 个功能的完整版和只有上帝模式的单功能版结果出人意料单功能版的用户完成任务的成功率高了 41%平均完成任务的时间缩短了 1.8 倍。功能多并不等于体验好功能拥挤本身就是一种伤害。这其实就是心理学里的“选择过载效应”——选项太多用户反而失去了选择的能力。撑着这三个标准我们最终确定了方案只保留上帝模式其他功能全部降级为“后续按需接入的插件”核心产品收敛为单一功能。现在回头看这个决策的价值怎么强调都不过分砍掉的是枝桠留下的才能长成树干。2. “上帝模式”凭什么活下来拆解一个功能的完整价值链条既然决定只留一个功能那我们必须把“上帝模式”是什么、为什么选它、以及它能撑起整个产品的原因讲清楚。这三个问题当时在团队内部被反复追问后来我们总结成了一套完整的价值论证体系这里原原本本分享出来。“上帝模式”本质上是一个全知视角的智能对话引擎。普通聊天助手是“你问我答”它能做的只是检索知识库并生成一个看起来合理的答案。“上帝模式”的不同之处在于它会在回答之前先完成三件事第一扫描并理解对话的全部上下文包括那些隐含的、没说透的需求第二主动拉取相关知识背景搭建一个立体的信息框架第三站在全局角度给出带推演过程的结论和建议而不是直接甩给你一个孤零零的答案。打一个生活化的比方普通聊天助手像是一个图书馆管理员你问什么他就帮你找什么书效率很高但没有主动性上帝模式则像是一个熟悉所有馆藏、并且读过其中大部分内容的老学者他会告诉你“你可能真正需要的不只是那本书还有这里、这里的资料综合之后得出的结论才是最有用的”。这个差异让 TWT Chat 从“搜索引擎的聊天版”升级成了“真正帮你做判断的伙伴”。2.1 “上帝模式”的前世今生从实验功能到核心引擎上帝模式并不是某一天灵光乍现想出来的它的雏形最早出现在 TWT Chat 的第三轮迭代里。当时我们给对话引擎加了一个“深度思考”开关开启后模型会先生成一份内部推理草稿再根据草稿给出最终回答。最初这只是一个小范围的实验但测试数据让人吃惊。开启“深度思考”的用户平均会话长度是普通模式的两倍以上次日回流率比普通模式高 67%。用户访谈里出现频率最高的一句话是“它好像真的懂我在问什么”。这个反馈坚定了我们的判断用户需要的不是更多功能而是一个能深度处理问题的核心能力。之后两个月我们把“深度思考”逐步升级为完整版的上帝模式。技术上主要做了三件事一是扩展上下文记忆窗口让模型能记住更早的对话细节二是重构了推理链路让模型在生成回答前先完成信息收集、事实校验、逻辑推演三个内部步骤三是调整了回答的呈现结构不再是一口气吐出一大段话而是分层次给出背景、分析、结论和建议用户可以跳过自己不需要的部分直达最关心的信息。当时这些改动在模型响应速度上是有代价的回答首字延迟增加了一秒左右。有工程师提出要压缩推理步骤来提速但产品侧顶住了这个压力理由很直接用户为什么愿意多等一秒因为他们等来的是一个明显更聪明、更完整的回答。事实证明这个取舍是对的留存数据和用户付费意愿都证明用户愿意为深度思考等待。2.2 为什么选择“上帝模式”而不是保留一个“小而全的工具箱”这个问题的答案其实隐藏在我们做过的另一组对比测试里。当时团队有另一种声音保留两到三个核心功能做一个“小而美”的产品也许比只做一个功能更稳。于是我们跑了三组测试A组用完整版B组只用上帝模式C组保留上帝模式加文案润色加图片生成。结果非常有意思。B组的用户平均会话时长最长达到 12.7 分钟A 组只有 6.4 分钟C 组居中9.2 分钟。但在“会话结束后的满意度评分”上C组反而比 B 组低了 14%。原因也很明显当用户同时面对三个功能入口时他们会产生选择焦虑甚至开始怀疑“我到底应该用哪个来解决问题还是全都用一遍”这其实印证了产品设计领域的一个经典理论用户在心智中只会给一个产品贴一个标签。微信的标签是聊天支付宝的标签是支付百度的标签是搜索。产品团队最怕的是什么就是用户说不清楚你的标签。你看起来什么都能做但用户没有理由记住你。我们还做了另一个小实验——把上帝模式单独拎出来做成一个极简界面只有一个对话框、一个思考深度调节滑杆、左侧展示推理过程。结果这个极简版本的自愿分享率是完整版的 5.3 倍。用户会主动把“上帝模式”的回答截图发到朋友圈但几乎没有人会截图分享一个翻译功能的结果。乐趣和惊喜来自深度能力而不来自功能的多少。所以最终选择上帝模式表面看是产品战略的选择底层其实是用户心理的选择。人们来聊天工具里寻找的不是“能做各种琐事的助手”而是一个“能听懂话、想得明白、给得出建议”的对话对象。这个需求在任何时代都存在只是过去技术不够如今刚好能实现了。3. 砍功能只是第一步技术侧到底动了哪些刀子很多人以为砍功能就是把前端页面上的按钮删掉程序员改几行代码就完事了。真正做过这次重构的人才明白砍功能最重的成本不在前端而在后端架构、数据管道、模型调用链路的全部收缩。这一节讲技术侧的执行细节程序员朋友可以重点参考产品经理同学也能从中理解为什么砍功能需要预留足够的技术改造时间。我们当时的后端技术栈是典型的微服务架构每个功能对应一到两个独立服务服务之间有复杂的互相调用关系。翻译功能虽然看起来独立但它底层挂钩了一个通用的多语言模型服务而那个服务同时也在为上帝模式的跨国资料检索提供支持。图片生成功能则占用了独立的 GPU 资源池砍掉之后资源可以释放出来给上帝模式做更长的上下文推理。3.1 服务缩编与依赖清理的完整流程动手之前我们先用两周时间做了一次全景依赖分析。目标是回答一个关键问题“砍掉这个功能会影响哪些其他服务”方法很简单但极其费时——把代码仓库里每一个跨服务调用点都抓出来人工确认调用方和被调用方的依赖关系。当时画了一张巨型依赖图截图出来差不多有 A2 纸那么大上面密密麻麻的箭头让所有人都吸了口冷气。清理依赖的策略我们分了三步走。第一步标记出“纯独立型功能服务”例如天气查询和新闻推送它们与上帝模式没有任何数据交换可以直接下线这条路径最干净。第二步处理“共享依赖型功能服务”比如翻译和语音速记共享了同一个统一语言层我们先把某个功能对应的路由调用点全部摘除再检查共享层是否还有错误调用最后逐步缩容服务实例数到零。第三步处理“数据回流型功能服务”比如文案润色它虽然不做主功能却会把用户改写后的内容回传到训练数据集里这些数据管道不能直接停掉必须先把积累的数据导出备份再做管道切断。整个缩编过程持续了整整三周比预期的两周多出了一倍。中间最痛苦的是处理各种隐藏依赖——比如某个服务看起来已经没人调用了但监控系统里仍然有零星请求进来。原因排查到最后发现是一个老版本客户端还在持续发心跳请求。这个教训直接促使我们做了两个改进一是在所有服务入口上加版本号过滤二是建立“死代码清理专项通道”任何超过一个月没有流量的接口自动进入待下线清单。3.2 上帝模式专项优化把省下的资源全部砸在一件事上砍掉 10 个功能的最大收益不在于界面看起来清爽了而在于我们释放出了约 70% 的 GPU 算力和大量研发精力可以全部投注到上帝模式这一个点上。第一项优化是推理链路升级。原来上帝模式和普通对话框共用同一个推理管道模型生成回答前只有一次提示词拼接没有独立的推理过程。重构后我们把推理分成四段意图识别、事实检索、逻辑推演、回答生成每一段有独立的模型子调用和参数配置。效果立竿见影模型回答的事实准确率从 78% 提升到了 92%。第二项优化是上下文记忆加强。我们给上帝模式增加了一个独立的外部记忆模块可以跨会话保存用户的偏好和背景信息。比如用户上一次提到过自己在做跨境电商下次再问营销策略时上帝模式会主动结合之前的背景信息给出针对性建议。这个改动让老用户的日均会话次数从 1.8 次提升到了 3.4 次效果比任何推送提醒都好。第三项优化是响应速度回补。推理链路变长了以后首字延迟一度超过 4 秒这在产品侧是不可接受的。我们做了两个针对性优化一是把意图识别和事实检索并行走节省约 30% 的耗时二是针对高频问题做了结果缓存大约 25% 的请求可以直接命中缓存不需要走完整推理链路。最终首字延迟回落到 1.6 秒左右兼顾了回答质量和响应速度。技术侧的收缩让整个系统变得更简单维护成本显著下降。上线两周后我们的线上故障率降低了 62%原因很简单——需要监控的模块少了会出问题的面也就小了。这个收益当时没写入战略文档但客观上成了做对决策的又一个佐证。3.3 数据管道和埋点体系的前后对比砍功能顺便给我们带来了一个重要的额外收益数据视野从“大而全”变成了“深而透”。以前埋点体系为了覆盖所有功能埋了几百个事件数据仓库每次跑任务都很慢分析时要在这几百个事件里做筛选效率极低。很多数据其实根本没有人在看但基础设施成本一分不少。砍功能之后我们把事件从 500 多个收敛到了 70 多个每一个事件都对应上帝模式的完整链路。现在分析留存只看四个数字新增用户数、首次对话完成率、次日回访率、深度对话占比。数据指标变少反让团队更清楚每天该看什么每周的产品例会从讨论一堆浮动数字变成了只针对几个关键漏斗深挖。这个变化也直接改变了我们做产品决策的方式。以前遇到问题团队先问“我们是不是该加个功能”现在遇到问题团队先问“上帝模式的哪个环节让用户卡住了”。功能收敛让问题变得更容易归因这是砍掉十项功能后最快感受到的红利之一。举个例子我们发现部分用户完成首次对话后就流失了顺着数据一查——首次回答长度超过 800 字的用户流失率明显偏高于是我们在新用户的前三次对话中限制了回答长度上限流失率立刻下降了 19 个百分点。4. 功能精简后踩过的坑三个差点翻车的典型问题这次战略收缩不是一路顺风顺水的中间至少有三次差点翻车。我把这些实际操作中的问题和排查过程整理出来给准备做类似功能精简的团队当个参考。避坑经验这个事很多时候只有自己踩过才知道有多疼但别人的教训多少能帮你少走一段弯路。第一次翻车发生在砍掉图片生成功能后的第三天。当时我们发布了新版本结果应用商店的评分在四个小时内从 4.7 跳水到 3.2。原因是有两个 KOL 发现了“不能再生成图片”这个变化发了一条吐槽动态评论区就被“产品是不是要凉了”的声音占领了。那两天团队相当焦虑有人在群里说“要不先恢复功能再慢慢推进精简”。后来我们冷静下来分析了实际数据吐槽的用户大多是功能迁移前的老用户他们只占日活比例的 6%但贡献了 42% 的负面评论。与此同时新用户的次日留存率从 31% 提升到了 39%说明精简对目标用户的效果正在显现。最后我们做了一个决定——公开向所有用户说明版本调整的考虑并把过去的图片生成功能做成一个可选安装的扩展包不在主菜单展示。这样一来喜欢用图片的用户依然能用但核心产品的界面保持极简。风波在一周内基本平息评分也重新回升到了 4.5。第二次翻车更有意思。我们集中全部算力优化上帝模式后发现回答质量确实提升了但新用户会频繁退出。排查用户行为录屏才发现关键问题当用户第一次打开产品时那个带着完整推理链路的长回答直接把他们吓跑了。老用户会觉得这个回答太专业太有价值了新用户却觉得“我只是想试试这个产品结果它给我写了一份论文”。这个问题的解法其实特别简单——在新用户路径上增加一个“轻量模式”第一周默认开启回答更简短、语气更温和等用户使用超过七天后再自动切换为完整的上帝模式。修改上线后新用户的首次会话完成率从 64% 提升到 83%而老用户可以随时手动切回深度模式。第三次翻车则暴露了我们在运营侧的短板。砍掉大部分功能后老用户再也找不到他们熟悉的“语音速记”“文档总结”等入口即使这些功能已经被打包到扩展包里入口藏得深很多用户根本不知道从哪里找。我们的解决方案是设计了一个“推荐功能区”在上线后的第一个月内主动向老用户推送他们曾经用过的功能入口并配上“已为你打包”的引导文案。这次推送让扩展包的激活率在两周内达到了 70%。4.1 用户反弹的真实来源你以为他们在意功能其实他们在意“失去感”三次翻车有一个共同的内核值得所有做产品的人记住用户反弹的根源通常不是某个功能消失了而是用户失去了对产品走向的掌控感。人对损失比获得更敏感这在心理学上叫作“损失厌恶”。功能在那里不用是一回事功能没了又是另一回事——即使那个功能只是躺在一个角落里积灰。所以我们在后续的任何改动里都强制要求团队回答一个问题这个变化让用户失去了什么我们如何用另一种形式补偿这份失去像是把图片生成做成扩展包本质上就是在补偿用户的“失去感”。你依然可以用只是不再占着主菜单的位置。这个思路后来也贯穿到了上帝模式本身的设计中。比如用户从轻量模式切到深度模式后我们不会立刻减少轻量模式的入口而是提供“随时切回”的按钮。用户反馈这个细节让他们觉得产品是尊重他们意愿的而不是自说自话地替他们做决定。4.2 功能精简后的指标复盘哪些数字真正变好了把时间刻度拉到改动上线后的第八周我们来看一组对比数据这是整个精简行动最有力的成绩单。指标改版前改版后第八周变化幅度次日留存率23.5%42.1%79.1%7日留存率9.8%21.3%117.3%平均会话时长4.6分钟12.7分钟176.1%深度对话占比超过10轮8%26%225.0%自然分享率3.2%11.4%256.3%崩溃率0.8%0.3%-62.5%月活跃用户数8.2万12.9万57.3%第一个值得注意的数字是月活的增长。按理说砍掉大部分功能应该会损失一部分用户但实际结果反而是月活从 8.2 万涨到了 12.9 万增长了 57% 以上。这说明一个新的增长飞轮正在形成产品定位清晰了用户愿意用用户用得多推荐给朋友的意愿更强新用户多了我们又有了更多数据去优化上帝模式。第二个让我在意的是自然分享率的提升从 3.2% 涨到了 11.4%。没有做任何推广投放纯靠用户自发分享实现了这个增长。背后的机理其实很朴素功能多了用户没东西可分享因为他们自己都不知道该推荐你的哪个功能功能收敛了之后用户记住了一句话——找 TWT Chat 开上帝模式然后在朋友圈转发一份看起来很厉害的回答截图。把产品浓缩成一个可以被记住、被转述的亮点比功能繁多更容易形成传播。5. 如果想复现“舍九取一”这里有可以直接抄的三条作业整个项目走完我把这个过程浓缩成了三条可复用的操作依据。任何团队在做功能精简决策时都可以把它们当作初始框架来用至少可以避开我们踩过的大部分坑。第一条作业动手砍功能之前先建立一张“功能价值评估表”。每一个待评估功能都要打分维度包括用户使用频率、核心留存贡献度、替代品市场成熟度、技术维护成本、未来增长潜力。分值全部公开透明团队一起打分避免产品经理一个人拍脑袋。我们当时给翻译功能的“替代品成熟度”打出了 9 分满分 10这个分数从客观上说明它不该被留在主产品里。打分的过程本身也是一次团队共识的建立。评分表用起来有一个注意点不要让“未来增长潜力”成为阻碍砍功能的万能借口。每个功能在理论上都有增长潜力如果这个维度占比过大最后你会发现什么都不敢砍。我们的做法是给“未来增长潜力”设置一个前置条件——如果该功能所在赛道的市场规模半年内没有增长 50% 以上潜力分一律强制打低。第二条作业功能可以砍用户必须陪。这是我们从三次翻车中学到的最核心心法。功能收敛的消息要在正式上线前告知核心用户给用户一个心理准备期。同时所有被砍功能都要有一个显性的去向——要么进扩展包要么引导用户换用替代工具。最忌讳的就是悄无声息地消失等用户某一天打开发现“东西不见了”那种失控感带来的反感远超你的想象。我们在通知用户时用了一个小技巧主动说明被砍功能里有哪些其实很好用但为了产品更聚焦才暂时移出主界面并且告诉他们后续要如何找到这些功能。承认“这是个好功能”会让用户感觉自己的判断被验证了反抗情绪会小很多。第三条作业用“单一核心功能是否能讲出完整故事”作为最终验收标准。砍完功能之后我们做了一个特别的检验动作让团队的每个人都尝试只用一句话向陌生人介绍 TWT Chat。如果这句话能清楚说明产品是干什么的、为什么值得用说明聚焦到位了如果还需要解释半天“它既能这个也能那个”说明收敛还没做到位。改版前的典型介绍是“这是个聊天软件可以翻译、总结、查天气还有一个能深度分析问题的功能。” 改版后的介绍是“这是个会从全局视角思考问题的智能对话工具。” 后者很容易被记住也更容易产生使用兴趣。一个好产品应该让用户在三秒内理解它的价值这也是“舍九取一”最终要实现的目标。回到开头那个争议砍掉 10 项功能到底是不是件正确的事数据上的答案是确定的产品战略的底层逻辑也是清楚的——资源和用户注意力都是稀缺品只有把两个稀缺品全部投入一处才有可能在一件事上做出压倒性的优势。用户今天留下的理由不是因为你什么都做了一点而是因为你把他们在意的那一件事做到了远超预期。做产品久了你会发现“做减法”这件事最难的不是动手而是下定决心之后还要有足够的定力扛住来自内外部的各种噪音。那次过后我把“舍九取一”写进了团队的默认原则里每次有人说“要不再加个功能”的时候我们都先问一个问题这件事能比上帝模式做得更好吗如果不能那就先不做。