宝软数字 · 产品设计哲学 · 2026-01-17
如果你问一个产品经理"你们的产品有什么功能"，他可能会滔滔不绝地讲上十分钟。但如果你问他"你们的产品去掉了哪些功能"，他大概率会愣住。这是因为在绝大多数产品团队的文化里，加功能被视为成绩，减功能被视为风险。加一个功能对应的是PRD、排期、开发、测试、上线——一条完整的价值创造链条。而砍掉一个功能呢？什么都没有，只会收到几个老用户的投诉邮件。
但我们在EIOS的建设过程中发现了一件事：真正决定产品好坏的，往往不是加了多少功能，而是敢不敢砍掉那些不该存在的东西。加功能是本能，做减法是能力。这篇文章将完整阐述为什么简单是能力，以及我们如何在EIOS的产品演进中持续践行减法哲学。
任何一个超过两年的软件产品，都会面临同一个魔咒：功能熵增。产品从简单优雅开始，然后一个功能一个功能地加上去——每个功能都有充分的理由，每个功能都解决了某个用户的某个问题，每个功能上线的决策在当时都是正确的。但当这些"正确"叠加在一起的时候，产品就变成了一个臃肿的庞然大物。
这种现象背后有三个驱动因素。第一个是销售驱动——"客户说如果有这个功能他们就签约"，这句话是产品经理最常听到也最无力拒绝的。当一个功能和一个具体的合同额绑定在一起时，拒绝它需要的不是产品判断力，而是政治勇气。第二个是竞争驱动——"竞争对手有这个功能，我们不能没有"，这种恐惧驱动的功能堆砌在B2B领域尤其普遍。第三个是内部驱动——工程师做了个有趣的特性，产品经理觉得这个想法很酷，管理者想在季度汇报里多写一行亮点。
这三种驱动力的共同特点是：它们都从开发者或销售方的角度出发，而不是从用户的角度出发。用户不需要"功能多"，用户需要"完成任务快"。但功能的增加从来不会让完成任务的路径变短——每条新功能路径都是对用户注意力的分流，都是在增加用户的认知负担。
更可怕的是，功能的增加是不可逆的。上线一个功能只需要一个发布周期，但要移除一个功能，你需要先确认没有用户还在依赖它，然后通知所有可能受影响的用户，处理投诉和迁移需求，最后才能小心翼翼地移除——这个过程的成本往往是添加功能的三到五倍。所以大多数产品选择了"什么都留着"，这就是为什么你会看到一些企业软件里藏着十年前的功能入口，点进去还能用。
如果做减法只是技术问题，那它早就被解决了。真正让减法变难的，是三个结构性的障碍。
人性障碍：损失厌恶。行为经济学告诉我们，人们对失去的厌恶强度大约是获得快乐的两倍。砍掉一个功能，意味着有一部分用户会"失去"他们曾经拥有的东西，即使这个东西他们几乎不用。这种"失去"引发的情感反应远比"没有这个功能"强烈得多。产品团队为了避免用户的负面情绪，宁可不做减法。克服这个人性障碍需要的不是数据分析能力，而是在深刻理解用户价值的基础上做出果断决策的勇气。
组织障碍：衡量体系。大多数公司的绩效考核体系天然偏向加法。开发了多少新功能、上线了多少新模块、新增了多少功能点——这些都是容易被量化和展示的业绩。而"砍掉了多少不必要的功能"不在任何人的KPI里。如果一个产品经理花一个季度的时间做减法，让产品的用户满意度提升了15%，但他的OKR里没有任何一条能体现这个价值。在这种情况下，做减法成了一种需要牺牲个人利益来完成的公益行为，这显然不可持续。
市场障碍：客户期望。在B2B软件采购的评估中，功能数量仍然是很多企业决策者依赖的最直观比较维度。"A产品有200个功能，B产品只有50个"——在没有深入体验的情况下，这个数字对比天然倾向于功能更多的产品。虽然采购决策者最终也会考虑易用性和实施成本，但在筛选阶段，功能数量仍然是第一关的通行证。这意味着做减法的产品在获客漏斗的最上端就面临劣势。
最大的误解就是认为"简单"等于"功能少"。真正的简单不是功能的缺失，而是用更少的界面元素覆盖同样甚至更多的使用场景。把一百个功能塞进一百个菜单里叫复杂，把一百个功能整合成十个能力叫简单。减法减的是界面元素，不是业务能力。
了解障碍之后，重要的是建立可执行的方法论。我们在EIOS的产品迭代中总结出了四条减法原则，每一条都对应着大量的实践和教训。
原则一：高频需求做减法，低频需求做隐藏。对于每天都会被用到的高频功能，我们再怎么简化都不为过。EIOS的日报生成功能，最早的版本需要用户选择时间范围、选择数据维度、选择展示格式、选择接收方式——四个步骤。经过三轮减法迭代后，用户只需要输入"/日报"或者直接说"给我今天的日报"，系统会根据历史习惯自动配置所有参数。而对于一年只用一两次的低频功能——比如年度数据归档——我们不需要做减法，我们只需要确保它存在且可用，但不要让它出现在日常操作路径上分散注意力。
原则二：用户需要的是结果，不是工具。这是传统企业软件最常见的错误——把内部工具直接暴露给用户。像一个BI工具的"字段拖拽器"，它在技术上很强大，但它要求用户先理解数据表结构、字段含义和聚合逻辑才能开始工作。在EIOS里，我们不提供字段拖拽器，我们提供的是"你能帮我看看哪些产品的退货率在上升吗"这种直接的问题入口。用户要的是答案，不是通往答案的工具链。
原则三：合并胜过新增。每次面对一个新的功能需求，我们的第一反应不是"在哪加一个新的入口"，而是"这个需求能不能被已有的某个能力覆盖"。EIOS的客户分析Agent最早只支持活跃度分析，当我们需要增加流失预警功能时，我们没有加一个新的"流失分析"入口，而是扩展了客户分析Agent的能力范围。对于用户来说，他的操作路径没有变——仍然是找客户分析Agent——但能做的事情变多了。这比每次新需求都加一个新入口带来的体验好得多。
原则四：砍功能不砍价值。做减法最大的风险是误伤——为了追求简洁而砍掉了用户真正依赖的功能。我们的防线是数据驱动的删除决策。在考虑移除任何功能之前，我们必须先回答三个问题：这个功能过去一个月的实际使用频次是多少？有多少用户在过去一周内使用过它？移除后的替代路径是否存在且比原路径更优？只有三个答案都满意时，删除才会被执行。
很多人以为简单就是"少做一点"，这是一个根本性的误解。真正的简单恰恰需要更多的投入——更多的思考、更多的设计迭代、更多的用户测试、更多的工程优化。把一件事做得看起来简单，是设计领域最难的事情之一。
以EIOS的Agent配置流程为例。在第一个版本中，配置一个客户分析Agent需要用户完成七个步骤：命名Agent、选择数据源、选择分析维度、设置刷新频率、配置预警规则、设置通知方式、预览并激活。每一步都有详细的说明文字和多个选项。我们以为这是在帮助用户做精细化的配置，但实际上用户面对这七个步骤时的感受是——"太复杂了，我还是用原来的Excel吧"。
于是我们投入了三周时间重新设计这个流程。最终的版本是：用户只需要输入一句话，描述他们想要什么。"帮我监控华东区客户的活跃度变化，如果周活跃度下降超过20%就通知我"——系统自动解析这句话中的Agent类型、数据范围、监控指标和触发条件，一键完成配置。用户看到的是一个极简的输入框，但在这个框背后，是自然语言理解、参数提取、智能补全、规则生成四层技术栈的协同工作。
这就是减法设计的本质：表面上砍掉的是用户的操作步骤，实际上转移的是系统的处理复杂度。用户觉得简单，是因为有人替他们承担了那部分复杂。那个"有人"就是产品设计团队和工程团队。我们说"把简单留给用户，把复杂留给自己"，这不应该是一句口号，而应该体现在每一个功能的设计决策中。
简单不是一种审美选择，而是一种工程承诺。每一次用户觉得"这个功能真好用"，背后都是一系列技术决策的结果——理解输入、推断意图、补全信息、处理异常、优雅降级。用户只看到了冰山浮出水面的那一小部分，而水面以下的巨大体量，才是产品真正的能力基础。
一次性的减法不难，难的是让减法成为团队的肌肉记忆。这需要组织层面的系统建设，不是靠某个人的意志力就能维持的。
建立减法审查机制。我们在每个版本的需求评审中增加了一个固定环节："这个版本我们要移除哪些东西？" 每个版本不仅要有新功能的增加，也必须有旧功能的退役。这种强制性要求改变了团队的思考习惯——从"这个版本我加了多少功能"变成了"这个版本我让产品变得更好了多少"。
量化简化的价值。减法之所以难做，很大程度上是因为它的价值难以量化。我们建立了一套"简化度"指标体系：关键任务完成时间的变化、新用户首次成功的步骤数、功能使用集中度（前10个功能占总使用量的比例）。这些指标让减法的效果变得可视化和可论证，为团队持续做减法提供了数据支撑。
培养减法文化。在团队日常沟通中，我们会刻意鼓励和表扬减法行为。当一个工程师提出"这个功能其实可以合并到那个里面去"，或者一个产品经理说"我们尝试减少这个流程的步骤数"，这些行为应该被认可和放大。文化不是一天建成的，但每一天的微小正向反馈都在塑造团队的集体认知。
接受不完美。做减法的过程必然会有判断失误的时候——砍掉了一个功能后发现确实有用户在依赖它。这时候最重要的是快速恢复和坦诚沟通，而不是因为害怕失误就不再尝试。我们建立了功能退役的观察期机制：一个功能被标记为"待退役"后，先隐藏两周观察用户反馈和客服工单，如果没有实质性的依赖证据再正式移除。这种"软删除"机制给了我们安全尝试的空间。
这是一个有悖直觉的结论：一个真正好用的企业软件，用户应该几乎想不起来它的存在。这不是说软件不重要，恰恰相反——正是因为软件已经无缝融入了用户的工作流，用户才不需要刻意去想它。
想想你每天用的计算器——你不会觉得它"好用"或者"不好用"，你只是需要算个数的时候打开它，算完就关掉。你不会花时间去研究它的功能，不会去看它的更新日志，甚至不会对它的界面有任何感觉。但如果在需要算个数的时候它不在，或者打了半天按键它没反应，你会立刻感到强烈的挫败。这就是工具的理想状态：存在时不被感知，缺失时不可替代。
企业软件应该追求同样的境界。EIOS的理想状态是：一个销售经理每天的工作流自然包含了与EIOS的交互——早上看日报，上午分析客户，下午跟进机会——但他从不会把"操作EIOS"作为一个独立的动作。他只是在做自己的工作，而EIOS是工作中顺手的工具，就像笔和电话一样自然。这不是功能少能实现的，而是功能与工作流的深度融合。
要达到这种状态，减法哲学必须贯穿产品的整个生命周期。不是设计完了再做减法，而是减法就是设计本身。每一个功能从构思阶段就要接受减法的审视——这个功能是否必要？能否通过更简单的方式实现？能否与已有能力合并？当减法成为设计的起点而非终点时，产品才能始终保持简单。
在EIOS的下一阶段，我们正在探索一个更激进的方向：主动隐藏系统本身。让EIOS的能力通过企业微信、邮件、短信等已有的沟通渠道触达用户，用户甚至不需要打开EIOS的界面就能完成大部分日常工作。这才是简单的终极形态——不是把界面做得更简约，而是让用户根本不需要看到界面。当然，这是一个长期方向，需要大量的技术积累和场景打磨，但它指向了我们做减法这件事的终极信念：最好的工具，是让人忘记自己在使用工具。