2B 软件加 AI,只是换汤不换药

你好，我是曹犟，欢迎关注我的公众号。

在之前的多篇文章中，我都曾经表达过一个观点：出于对 AI 终局能力的不同判断，AI 时代的 2B 软件大概有两种构建方式。

第一种，是给现有软件增加 AI 功能。在已有产品上逐步添加 Copilot、Agent、自然语言交互等 AI 能力，用渐进式迭代的方式过渡到下一代产品。这条路径的核心假设是：大模型能力有天花板，或者能力增长斜率足够平缓，现有软件架构可以逐步吸纳 AI 能力，而不被彻底颠覆。

第二种，是直接构建 AI Native 的软件。从一开始就围绕大模型能力，重新设计产品形态、交互方式、交付流程和商业模式。这条路径的核心假设是：大模型能力会持续快速提升，最终足以让软件从“交付工具”变为“交付结果”，传统软件架构会从资产变成包袱。

这有点类似智能驾驶行业中的路径之争：到底是从 L2 辅助驾驶逐步演进到 L4 自动驾驶，还是直接以 L4 为目标来构建自动驾驶能力？到今天为止，行业里并没有形成共识。

但在此时此刻，经历了过去半年 AI Coding 和 Agentic 能力的快速增长之后，我个人的判断变得越来越明确：给 2B 软件加 AI 这条路，在根上不成立。

需要说明的是，我这里说的“给 2B 软件加 AI”，并不是指存量 2B 软件公司不能使用 AI，也不是说存量 2B 软件公司在 AI 时代没有机会。恰恰相反，很多存量 2B 软件公司拥有客户关系、行业 Know-how 和客户信任，这些仍然是非常重要的资产。

我想批判的是：在原有 2B 软件产品、原有交互方式、原有收费模式、原有组织流程基本不变的前提下，只是给产品增加一些 Copilot、Chatbot、Agent 作为入口。

这种做法看起来是在拥抱 AI，但本质上仍然是旧软件范式的延续。它试图让 AI 学会使用软件，而不是让客户不再需要使用软件。

这也是为什么我觉得，给 2B 软件加 AI 只是换汤不换药。

PART 01 应用层软件正在失去必要性

从更底层的角度来看，软件到底是什么？

过去几十年，应用层软件的核心价值，是为人类提供一个操作数字世界的界面。人想要改变数字世界，但人不会直接操作数据库、API、代码、权限系统和各种底层服务，所以需要软件把这些复杂能力包装成按钮、菜单、表单、报表和工作流。

换句话说，应用层软件本质上是一个“手柄”。它让人可以用自己能够理解和掌控的方式，去操作背后复杂的数字系统。

企业软件尤其如此。

CRM、ERP、HRM、BI、CDP、MA，本质上都是把企业内部的业务流程、管理动作、数据分析、审批协作，抽象成一套人可以操作的界面和功能。过去企业买 2B 软件，是买一套让员工操作业务流程的工具。

但 AI 的出现正在改变这个前提。

当 AI 具备足够强的 Coding 和 Agentic 能力之后，它不再只是一个帮人写文案、查资料、补全代码的助手，而是开始具备直接操作数字世界的能力。它可以理解目标、拆解任务、调用工具、运行验证，最重要的是可以根据反馈持续修正。

在这种情况下，“让人使用软件”这件事本身就会变得越来越不重要。

举个简单的例子。过去一个运营同学想做一次召回，需要登录营销系统，选择人群，配置规则，编辑文案，设置触达渠道，观察效果，再根据数据调整策略。2B 软件的价值，就是把这些动作产品化，让人可以一步步完成。

如果 AI 足够强，用户真正需要说的可能只是：“帮我把最近 30 天下过单但没有复购的人群召回，在不伤害毛利的前提下，把复购率提升 10%。”

后面的事情，应该由系统自己完成：圈选人群、设计策略、生成营销内容、选择触达通道、观察用户数据、调整策略方案，并最终汇报结果。

这时，传统应用层软件的很多界面和功能就会退到幕后。它们可能仍然存在，但不再是主要入口，也不再是主要价值载体。

需要特别说明的是，我不是说数据库、权限系统、计算引擎、API、日志、审计、基础设施都不需要了。恰恰相反，这些东西会变得更加重要。只不过，那些给人类操作的应用层软件，会从“主产品”变成 AI 系统背后的基础设施、控制台和审计界面。

软件曾经是人操作数字世界的手柄。而现在，AI 正在成为操作数字世界的主体，手柄当然会变得不重要。

PART 02 给 2B 软件加 AI 为什么不够

理解了这一点，再来看给 2B 软件加 AI 的问题，就比较清楚了。

传统 2B 软件的基本假设是：客户通过使用软件，把自己的业务流程变得更高效。

给 2B 软件加 AI 的基本假设是：客户仍然使用软件，只是 AI 帮他更容易、更快地使用软件。

AI Native 的基本假设则完全不同：客户不再使用软件，而是把目标委托给系统，由系统直接执行、验证、迭代，并最终交付结果。

这三者之间的核心差异，不是交互方式，而是基本的产品假设。

在旧 2B 软件上加一个自然语言入口，当然有价值。它可以降低学习成本，让用户少点几个按钮，少看几页文档，少培训几天。对于很多复杂软件来说，这些改进并不是小事。

但它仍然没有改变最关键的前提：软件还是主体，AI 只是功能；客户还是使用者，AI 只是助手；价值还是来自功能，结果仍然主要由客户自己负责。

所以，给 2B 软件加 AI 最大的问题，不是它没有用，而是它不够彻底。

它让旧软件变得更好用，但没有让客户从“使用软件”变成“委托结果”。

这有点像智能驾驶里的 L2。L2 辅助驾驶可以让司机轻松一些，但车的责任主体仍然是司机。司机还要盯着路面，还要随时接管，还要为最终结果负责。

而 AI Native 想做的是 L4。用户设定目标，系统在限定边界内自主完成任务，人只在关键节点做判断、授权和监督。

从这个意义上讲，给 2B 软件加 AI 并不是通向 AI Native 的自然中间态。很多时候，它反而会强化旧范式。

因为一旦团队沿着给 2B 软件加 AI 的路径走，产品团队会自然地问：现有页面上加什么 AI 入口？研发团队会自然地问：现有系统怎么接大模型？销售团队会自然地问：AI 模块怎么打包售卖？客户成功团队会自然地问：怎么培训客户使用新的 AI 功能？

这些问题都不是错的。

但它们共同指向的是旧答案：继续围绕软件功能组织一家公司。

而真正的问题应该是：

客户最终想交付什么业务结果？这个结果能不能拆成可执行、可验证、可持续优化的工作流？哪些环节可以交给 Agent，哪些环节必须由人来判断？商业模式能不能从卖账号、卖模块，变成卖任务、卖结果？

这才是 AI 时代真正应该思考的问题。

PART 03 存量 2B 软件公司的资产需要重新估值

如果沿着这个逻辑继续推演，就会遇到一个很现实的问题：存量 2B 软件公司过去多年积累下来的东西，到底是资产，还是包袱？

我的判断是：代码和功能，更多会变成包袱；客户需求理解、行业 Know-how、客户信任和客户关系，仍然是资产。

先说代码和功能。

传统 2B 软件，本质上是对行业内优秀管理实践的抽象和总结。这句话在过去是成立的，也是很多企业软件公司能够成立的基础。

但问题在于，这些代码和功能固化的依然是上一代软件范式。它固化了“人来操作系统”的交互方式，固化了部门分工、审批流、菜单、报表和配置项。甚至不只是产品层面，连带着按模块、按席位卖的商业模式，以及整个组织围绕“软件功能”运转的惯性，也一起被固化了。

当 AI 让企业管理方式发生变化之后，原有代码和功能当然不一定完全没有用，但它们很容易变成路径依赖。

旧代码越厚，旧功能越多，团队越容易下意识地问：“怎么给现有功能加 AI？”而不是问：“如果 AI 是执行主体，这个业务目标应该怎么被重新完成？”

从这个意义上说，过往积累的代码和功能，不再天然是资产。它们甚至可能成为让组织无法转身的负债。

但这并不意味着存量 2B 软件公司没有优势。恰恰相反，很多真正重要的资产并不在代码里，而在组织多年服务客户的过程中。

第一，是对客户真实需求的理解。做 2B 久了就会知道，客户嘴上说的需求和真正想要的结果，往往不是一回事。哪些需求是伪需求，哪些流程只是历史包袱，哪些指标才真正牵动业务，哪些场景看起来简单但落地很难，这些判断不是通用大模型看几篇文档就能学会的。

第二，是行业 Know-how。服务过足够多客户之后，企业软件公司会积累大量跨客户、跨行业的共性认知。它知道最佳实践是什么，常见坑在哪里，不同类型客户之间的差异在哪里。这些知识如果能被整理成 AI 可以使用的 Context、Skill、Workflow 和 Evaluation，就会变成 AI Native 产品的核心燃料。

第三，是客户信任和客户关系。2B 市场里，客户不会随便把关键业务交给一个陌生系统自动执行。尤其当产品从“提供工具”走向“交付结果”时，客户把更大的权限、更关键的数据、更真实的目标交给你，本质上依赖的是信任。

所以，存量 2B 软件公司不是没有机会。它们的问题不是没有资产，而是能不能重新理解自己的资产。

旧代码和旧功能，不一定是未来的护城河；客户理解、行业知识和客户信任，才可能是。

PART 04 真正要重构的是组织

如果只是产品形态变化，问题还没有那么复杂。

真正困难的是，软件企业本身也要发生变化。不是简单引入几个 AI 工具，不是多招几个 PM 开会讨论怎么做 AI 产品，也不是让每个团队都给自己的功能加一个 Agent。

真正要做的是：把组织从“软件功能生产线”，重构为“数字劳动力运营系统”。

传统 2B 软件组织擅长的是把需求变成功能。

客户提需求，产品经理写 PRD，研发实现功能，测试验证质量，交付负责上线，客户成功教客户使用，销售再把功能打包成模块卖出去。整个组织都围绕“软件功能”运转。

但 AI Native 组织要擅长的是把业务目标变成可执行、可验证、可持续优化的 AI 工作流。

产品经理首当其冲。过去定义页面和功能就够了，现在要定义的是业务目标、成功标准和人机协作的边界。

工程师也一样。写功能代码变成了搭 Agent 的执行环境——工具、权限、护栏、验证机制，这些才是核心产出。

交付和客户成功可能变化最大。以前是教客户把软件用起来，以后是帮客户把业务目标拆成可以委托给 Agent 的工作流。

销售就更不用说了。客户不再按席位买单，销售得能跟客户聊业务结果、试点效果和风险边界。当然，销售依然要跟客户搞好关系，维持好客情。毕竟，中国 2B 的本质是甲方和乙方有良好的关系，而甲方有一个问题恰好乙方能够解决。

这些变化都不只是岗位职责的调整，而是组织重心的迁移。

存量 2B 软件公司最大的危险，不是技术落后，而是组织惯性。

如果组织的 KPI、流程、会议、预算、销售话术、客户成功方法都还围绕旧软件功能展开，那么即使接入再强的大模型，也很难进入新范式。最后做出来的东西，大概率还是一个更聪明、更会聊天、更容易上手的旧软件。

但如果一家存量 2B 软件公司能够在新的商业模式下，重新构建组织，把过去积累的客户关系、行业 Know-how 和客户信任转化为 AI Native 产品所需要的上下文、工作流和执行闭环，那么它不但不是没有机会，甚至可能比纯粹的新创业公司更有优势。

关键在于，它必须先放弃一个旧身份，它不能再只把自己看成一家软件公司，而是要把自己重构成一家数字劳动力公司。

写在最后

客户最终要的从来都不是软件。不管是难用的、复杂的软件，还是经过 AI 改造之后变得更易用、可以用自然语言描述需求的软件，本质上都只是中间层。客户真正要的，是业务结果。

过去我们没有能力直接交付结果，所以只能交付工具，让客户自己使用工具去逼近结果。2B 软件过去的“黄金时代”，建立在这个前提之上。

但随着 AI 的能力，特别是 Coding 和 Agentic 能力的持续提升，这个前提已经发生变化。系统开始有能力直接理解目标、执行动作、验证效果、持续优化。那时，应用层软件作为主要产品形态的必要性就会下降。

所以我说给 2B 软件加 AI 只是换汤不换药，并不是说 AI 功能没有价值，也不是说存量 2B 软件公司没有机会。

我想表达的是：不改组织、不改商业模式、不改产品假设，只是在旧 2B 软件上加一层 AI，这条路不可能真正进入 AI Native 时代。

存量 2B 软件公司的机会，不在于把旧软件包装得更智能，而在于把自己从“交付工具”的公司，重构为“交付结果”的公司。

这个过程一定很难。因为真正要被重构的，不只是产品和代码，更是组织、流程、商业模式，以及一家软件公司对自己的基本想象。

以上是我现阶段的一些思考，一家之言，仅供参考。欢迎大家交流讨论。