从程序员到 CTO 的十年创业血泪总结（六）：当大模型遇见 2B 软件

前文回顾

在上一篇文章从程序员到 CTO 的十年创业血泪总结（五）：PMF 避坑指南中，我们讨论了在 PMF 过程中，会有哪些需要注意的问题。按照原定的计划，PMF 之后应该是讨论产品规模化和 GTM 的。不过最近一段时间，一方面是参加了不少行业内关于大模型的会议和讨论，另一方面我自己也在思考在技术换代的新形势下应该如何做产品。所以临时插入了本篇文章，把自己的思考内容分享给大家。

1.对当前 2B 软件行业的一些思考

在过去几年，创投圈对于中国 2B 软件行业（包括企业级软件和 SaaS 两个有差异的细分行业，后文为了行文方便，统称 2B 软件行业）的前景有许多很有意义的讨论。作为有十年经验的参与者，虽然远远算不上行业老兵，但是也算是见证了中国 2B 软件行业从万众创新、到投资热点再到如今的“绝望之谷”，我自己也一直从这些讨论中获得了很多能够跟实践得到印证的观点。

这些观点中有一些可以初步认为是行业共识：

• 2B 软件的本质，是对企业现代管理最佳实践的系统化总结与数字化抽象。相较于发达国家企业管理百年沉淀的深厚土壤，中国企业管理自改革开放起算，仅有三四十年的探索历程。这种时间维度的积累差异，使得我们在管理实践的深度提炼、体系化构建与技术化抽象层面，仍存在显著的提升空间，也是当前 2B 软件面临困局的核心原因。
• 在市场规模方面，当前中国 2B 软件市场与北美软件市场有数量级上的巨大差距，并且这种差距在过去几年并没有如很多创业者与投资人预料的那样有缩小的迹象。中国市场不仅远远小于北美市场，甚至比欧洲、日本等单个市场都要小很多。这种市场规模的天然限制也是整个行业中单个个体难以通过努力来突破的问题，也是当前 2B 软件面临系统性资本风险的由来。
• 从对 2B 软件特别是 SaaS 的接受程度这个视角来看，北美市场才是异类。其余市场，从立项、论证、采购等流程代表的付费习惯和预算结构来看，其实更接近于中国市场。北美市场中仅仅各个 SaaS 公司互相之间的采购就已经是一个能够让很多中国同行羡慕的市场规模了。
• 当前宏观经济对企业预算的影响，软件采购预算首当其冲。
• 大模型这一前所未有的技术换代，会对 2B 软件行业带来巨大的影响。

除了上述这些共识以外，行业里面也存在非常多非共识。例如：

• 中国 2B 软件市场规模未来十年是会缩小还是扩大与北美市场的差距？
• 宏观经济影响下，中国企业的管理成熟度和标准化会如何演变？用于软件的预算会增长还是降低？
• 中国市场的公有云接受度与覆盖率会上升还是下降？
• 大模型对 2B 软件行业的影响，是彻底的颠覆，也即不再存在 2B 软件行业，还是会是整个行业重生涅槃的机会？

对这些非共识问题，悲观者和乐观者往往会有不同的答案，时间会给出最终的解答。但是，往往非共识中才蕴含着巨大的商业机会。历史反复证明，商业世界的重大变革往往始于非共识的萌芽。当悲观者在争议中观望，乐观者早已用行动将不确定性转化为确定性。这或许就是中国 2B 软件行业破局的关键所在。

在简单总结了我个人对于 2B 软件行业的一些思考后，下文主要会从如下几个方面讨论大模型对 2B 软件行业的影响。

2.商业模式

最近行业内慢慢在形成一个共识，大模型这个技术变革会带来 2B 软件行业商业模式根本性变更的机会。简单来说，就是大模型，使得 2B 软件公司可以从交付工具，变成交付最终效果。我个人对这一点也是比较笃定和兴奋的。

我们可以用汽车行业来类比：

在过去，2B 软件公司就类似于东风这样的主机厂，交付的软件就类似于东风交付的汽车。2B 软件公司客户需要自己有能力，或者通过雇佣内部外部的有能力的人来使用软件，就类似于购买汽车的消费者自己有能力驾驶汽车。但是本质上，客户要的其实并不是某一种好用的工具，而是能够解决某个具体的问题。类似于消费者要解决的是从 A 点到 B 点的问题，购买汽车只是解决这个问题的一种手段。消费者除了购买汽车，还可以坐地铁、打车等等。这某种意义上，也解释了很多时候对于企业客户来讲，为什么软件购买并不是刚需。除了购买现成的软件，客户也有很多其它解决问题的方式，例如雇佣定开公司专门做定制开发，或者让员工不依托 2B 软件自己想办法等。

而大模型带来的新的机会，使得软件公司可以基于大模型的能力，加上过往积累的知识，不仅仅是交付工具，而是直接解决某种问题。此时，大模型公司就类似于已经具备了自动驾驶能力的滴滴。消费者只需要在 App 上告诉滴滴，我需要从哪里到哪里，不需要去买车，更不需要去雇佣司机。

这种转变带来的是商业模式上的根本性的变化：

从收费模式上，2B 软件公司收入可以不再是订阅制年费，或者说一次性买断加维保费，而是直接可以和最终的效果挂钩，有了更加巨大的想象力，也有了更多的努力空间。

从预算出口上，2B 软件公司不再是需要去拿客户的 IT 建设类预算，而是直接可以去拿类似于客户的营销预算。经济形势不好时，客户肯定先削减的是 IT 类预算。而且两种预算不仅在在优先级上天差地别，在规模上也有数量级上的差异。而当收入规模有数量级上的差距时，就形成了新的高维打低维的竞争态势。

从价值创造的角度，2B 软件公司不再是通过服务客户的 IT 团队来间接服务客户的业务团队，而是可以直接与业务团队打交道。软件公司不再是满足客户 IT 团队的系统建设类需求，而是真正致力于如何提升业务团队的核心 KPI。这种变化对于与客户的深度绑定和协同也是非常至关重要的。

在有了大模型之前，很多 2B 软件公司也在尝试最终对客户交付最终效果。但是很多时候，为了交付最终效果，需要在每个客户上投入相当大的陪跑、咨询的人力。从效率、内部管理和组织、知识的传承等几个角度，这种人力密集型的模式都是很难规模化的。同时，2B 软件公司天然会追求同样的一套软件服务所有的目标客户，这都会对最终交付业务效果带来负面影响。所以大部分尝试最终都是没有走通。

而有了大模型之后，咨询、陪跑都可以用 Agent+知识库 的方式来替代，效率得到了巨大的提高。同时，2B 软件本身的形态也能够变得更加灵活，客户的一次性需求，也可以由很高效率快速开发的一次性软件来满足，标准产品与客户个性化需求之间的矛盾有了解决的可能。

这种大模型对商业模式的根本性影响，虽然逐渐在行业内成为共识，但并没有完全走通，背后一方面取决于大模型能力的进步，另一方面也取决于如何将分散在软件公司内部和客户内部的知识进行有效的汲取、组织和应用。但不管怎么样，交付效果的商业模式总是会打赢交付工具的商业模式，这种商业模式上的根本性的变化给中国的 2B 软件行业带来了新的可能和希望。

3.交互方式

大模型对于软件行业（不仅仅是 2B 软件，面向普通消费者的 2C 软件也一样），带来了一个新的课题：未来的软件与用户交互的形态，应该依然是 GUI（图形用户交互界面） 还是 LUI（自然语言用户交互界面）。

GUI 指通过图形元素（如图标、窗口、按钮、菜单等）和可视化界面与用户交互的方式，用户通过鼠标、键盘、触摸等操作完成任务。LUI 则指通过自然语言（语音或文本）与用户交互的方式，用户直接输入指令或提问，系统通过语义理解、对话管理等技术响应。

在 2B 软件行业：

• GUI 的优点主要是操作精度高，能够支持非常精细的操作；缺点则是有一定的开发成本，新的功能就需要开发新的 UI。
• LUI 的优点是交互自然便捷，扩展性强，通过能力升级就可以适配更多的功能，不需要开发新的界面；缺点则是操作精度目前较差，任务精度不足，在做复杂任务时效率低于 GUI。

在上手门槛上，则两者各有千秋：

• GUI 有图形界面做引导，但是在操作上，特别是一些完成一些专业任务还是需要理解业务相关的一些基本语义与概念。
• LUI 则是接近自然对话，几乎没有成本，但是碰到复杂指令和语言歧义，则还是需要理解相应的语言规范。

从目前大模型的实际能力与我们具体的实践来看，短期内我认为并不会发生 LUI 全面替代 GUI 这种根本性变化。在 2B 软件行业，可能是这样一种思路：

• 针对有一定经验的用户，如数据分析师等，在完成复杂的精确的任务，如通过下钻分析指标异常，创建报表等，则依然应该以 GUI 为主，提供最高的效率和最准确的操作精度。大模型则主要结合行业知识和内部知识，以启发、联想等方式，给使用者更多信息作为参考。
• 针对新手用户，或者说仅仅是完成简单的任务，例如管理者想知道某个具体指标，则可以以对话框或者机器人这种 LUI 的方式，嵌入到企业内部的 IM，例如企业微信中，以最低的上手成本让用户获取想要的信息。

当然，在讨论 GUI 还是 LUI 这种交互方式时，所限定的场景是以人为准，大模型为辅，目标是让使用者更好的使用工具，类似于自动驾驶中的 L2 级别。如果未来真的 2B 软件变成以 Agent 为核心，直接交付最终结果，那么软件的交互方式就不再是一个关键问题了。

4.效率提升与组织形态

最近一段时间一直在使用 AI 辅助进行调研和做一些 demo 的开发，对于大模型在这方面的效率提升还是有很深的体会的。在做类似于资料收集、报告整理、竞品调研、简易程序开发的场景时，大模型能够带来十倍以上的效率提升。当然，从神策研发团队内部使用大模型辅助在已有代码上做渐进式迭代的情况来看，在这类场合，则可以只有一到三倍的效率提升。虽然在这方面的效率提升不那么夸张，但是已经可以让单个卓越个体的能力和效率得到极大的放大，这可能也是为什么类似于“一人公司”之类的概念最近被提起的越来越多的原因。

当生产效率得到提升，一个 2B 软件企业的生产力组织形式，可能也需要发生改变。我觉得可能会有以下一些变化：

产品经理与软件工程师两个岗位的分界会不再那么明显，有融合的趋势。有技术背景的产品经理和有产品 sense 的工程师，都可以在 AI 辅助下一个人完成整个产品从调研、用户研究、商业模式设计再到产品原型开发的全过程，直到进入规模化阶段时才可能需要一个分工协作的小团队来接手后续的工作。这对于新产品推出和尝试的效率都是翻天覆地的变化。

团队规模将进一步变小，人效会有巨大提升。字节、腾讯这类 2C 互联网巨头有几百万的人均营收，而中国的 2B 软件公司的人均营收通常不会超过一百万。相比较广告、游戏这类“印钞机”业务，2B 软件本身就是一个重规模、重流程、重管理、重运营的商业模式，其中每一份利润都是省出来的。这种商业模式上的巨大差距，也让 2B 软件行业天然在人才密度上落后于 2C 互联网巨头。大部分 2B 软件公司随着规模的扩大，员工的平均水平都是一个显著的下降趋势。

而大模型带来的效率提升，可以让类似于研发团队、解决方案团队这样的典型的知识工作类团队，完成同样产出的人数有大幅度的减少。而考虑到人数减少带来的沟通、开会、文档等协作环节的减少，人数减少 50% 带来的人效提升远远不止两倍。团队人数减少给每个成员带来的工作满意度的正面影响也不可忽略。绩效卓越的个体大部分都是宁愿不与人合作也不愿意与不那么“聪明”的同事合作。如果 2B 公司的管理者能够抓住这个大的技术变量，果断对团队组织和协作方式进行调整，也许 2B 公司的人效和人均利润可以有一个持续的提升。我最近参加的几次闭门会上，2B 软件行业已经出现了人数越少、业绩越好的大趋势了。

传统软件工程中对中台架构与通用化设计的依赖正逐渐弱化。大模型为公共能力复用开辟了全新路径——无需复杂的中台搭建或架构抽象，通过代码级直接复用即可实现能力共享。不同产品间的协同边界被重新定义：除操作系统、网络安全等底层基础设施外，其余业务逻辑在工程层面可彻底解耦，形成更灵活的独立部署单元。借助大模型对企业内部代码库的深度解析，结合Agent与Copilot工具，开发者得以突破传统复用模式的限制。

Agent可自动检索、调用历史代码片段，Copilot则实时辅助代码编写与优化，使代码复用效率指数级提升。这种智能化复用方式，不仅大幅降低了开发成本，更推动企业技术架构从“强耦合、重架构”向“轻量灵活、敏捷迭代”转型，让软件系统的构建与迭代进入全新范式。

按照职能来组织团队将不再是最优解。由于一个较小规模的团队，就可以完成产品研发的全流程，并且不同产品与业务之间的工程协作与业务耦合被解开，那么过往在公司内部按照产品、研发、交付、销售、售后这类职能方式来组织团队，或者是职能与业务交叉的矩阵式团队组织方式将不再是最优解。完全可以将一个业务线所有的角色整合到一起，由一个角色来负责，从而大幅度减少内耗和内部不同职能之间的协作成本。

我想没有太多 2B 软件行业的创业者，在创业之初，会希望公司变成一个人数虚多、组织庞杂、流程复杂、协作痛苦的虚胖的重运营的公司。但是公司某种意义上是被客户定义的。客户需要什么，反过来决定了公司会变成什么样子，这一点并不以创始人的个人意志而转移。幸好大模型这一技术变革，让创建一个小而美的、高人才密度的、高人均收入的、内部协作和运营简单的 2B 软件公司成为可能。

5.软件架构

对于 2B 领域而言，软件架构不仅是技术问题，更是企业战略的落地载体，是企业战略决策的重中之重。软件架构设计，决定了产品的功能边界和服务范围，决定了软件能否在长期使用中持续创造价值。

2B 软件公司在尝试引入 Agent + 知识库，从交付工具转为交付最终效果后，整个软件架构也应该随之发生一些变化。

我把我的一些思考用下图来做一个简单的描述：

整个软件架构的设计依然需要遵从第一性原理，从客户的痛点这一最原始需求出发，例如，客户的痛点是如何用更少的钱来获取更好的拉新效果。

在进行实际的架构设计时，需要从客户的痛点回到客户的具体业务场景，例如，在用户拉新这个问题上，一个电商公司的具体的业务场景可能包括：日常根据数据分析不同媒体的投放效果并对投放进行调整；根据数据分析用户进入落地页之后的转化率对落地页和后续产品使用流程进行优化。

而产品功能这一层，则是在之前 2B 软件设计时最为关注也是讨论最多的一部分。产品功能层是对同一领域不同客户业务场景的共性进行抽象后的结果，是按照功能点进行组织的。例如，在上面描述的这个场景中，我们将产品功能抽象成了漏斗分析、渠道分析、热力图等。这种抽象必然会导致一些具体场景的损失，也会带来很多对于客户而言新的“概念”。随着服务的客户增多，接到的需求越来越多，功能点也必然会越来越多，同一个功能也必然会越来越复杂。这些最终都导致客户必然会有相当大的上手成本，需要通过专门的培训、学习甚至是考试来解决。

按照过往的工具定位，客户内部必须由人能够根据 2B 软件公司抽象出来的功能点，结合自己的实际业务场景，来构造出具体的解决方案而最终解决问题，带来业务效果。如果客户内部没有具有这种能力的人，则要么由 2B 软件公司或者专门的实施咨询 Partner 来补位（这也代表了巨大的人力成本，会导致能够分到软件上的成本会被大幅度积压），要么就得面临工具在客户内部没有真正效果的结局，也就是客户经常会说的，“你的产品功能很强大，但是我们用不起来”。

Agent 和知识库的引入，则是为这一点的解决提供了一种可能。2B 软件公司除了行业共识之外，还能够在服务不同客户的过程中，积累非常多的客户怎么样使用产品功能解决具体问题的实际的私有知识。这些私有知识天生就是脱敏的，是可以在不同客户间共享的，也是一个深耕行业的 2B 软件公司可见的最大的竞争壁垒。

上面这个简单的软件架构设计的层级划分，是目前我个人基于过去一段时间的尝试、沟通的一些粗浅的认知。对于 Agent + 知识库是否真的能够解决功能用不起来的问题，让软件公司从交付工具变为交付效果，大家都还在探索的过程中。希望能够听到各位的观点和看法。

6.以终为始还是逐步迭代

在智能驾驶行业中，有一个大家还没形成共识的问题：L2 级别的辅助驾驶是否能演进到 L4 级别的自动驾驶。

而在 2B 软件行业中，也有一个类似的问题，我们是应该从现有的软件开始迭代，逐步添加 Copilot 和 Agent，逐步过渡到新一代的 2B 软件？还是应该从零开始，从头设计一个 AI Native 的 2B 软件？

这两条路径的背后，代表了对大模型能力天花板，以及对大模型能力增长斜率的不同看法。目前我觉得可能也很难说清楚到底哪条道路是对的，或者说两条道路最终会殊途同归。

不过，有一点是明确的，不管底层技术发生什么样的变革，2B 软件本身依然是对客户业务流程的抽象和实践，是为了解决目标客户具体的业务问题，帮助客户取得业务效果从而获得进步。AI 的引入，只不过让这个目标，可能有了一个更高效率更优雅的解决方式。

上述文字仅代表个人观点，其中肯定有非常多错误的地方。如果能够给各位读者带来一点收获和启发，就是我莫大的荣幸~

END