AI 驱动下软件市场的 4 块蛋糕

引言

随着大模型 ai coding 能力越来越好，软件市场将会发生剧烈的变化。我的思考是：将来软件需求会分化为如下 4 块蛋糕。

• 小 B 市场，有容错的软件需求。

• 小 B 市场，非容错的软件需求。

• 中大 B，不需要高度抽象设计的普通软件需求。

• 中大 B，需要高度抽象设计的专业软件需求。

下面解释为什么这么划分，以及这些市场将会被谁吃掉。

1. 大模型存在幻觉且短期内不可能被消除

众所周知，大语言模型其实是个神经网络的概率模型，其本质上是一个巨大的矩阵行列式计算。这种海量参数（百亿、千亿甚至万亿个参数）的矩阵计算，所表达的是一种知识的“压缩”，而并不是知识的“精确存储”。在这种背景下，大模型的 AI 能力，几乎是不可能消除“幻觉”的。

关于“大模型不可能消除幻觉”这个结论，下面就是我亲手测试的一个例证：

问：999999994646x99999568758等于多少。

下面分别是 DeepSeek、通义千问、豆包给出的答案：

很明显可以看出：这 3 个大模型都在“一本正经的胡说八道”，答案都是错的！正确的答案是：99999568222602308869668。如果你有兴趣，可以用 python，写如下一行脚本就能出来答案：

print("999999994646x99999568758=", 999999994646*99999568758)

计算结果如下图：

本质上来看，这种基于概率计算基础上的大语言模型，是无法彻底消除“幻觉”的。如果要彻底消除这种“幻觉”，只能依赖于神经网络底层算法架构的创新。而这种创新的时间周期，一般以十年以上为单位，少则 10 多年、多则几十年。可以肯定地说，大模型幻觉问题，在“短期内”是无法消除的。

无法 100%消除“幻觉”的问题，就导致使用大模型写出来的软件代码，无法做到 100%准确。这就涉及到要软件需求本身的容错性问题。

2. 软件需求的容错性与否，决定了人类程序员是否退场

人们对软件的功能需求，其实是可以区分为容错和非容错两种的。

容错性需求，指的是那些软件反馈的结果不稳定、有偏差、但对实际结果几乎无影响的功能需求。典型的如：自动生成演讲稿、自动编故事、自动画 PPT，甚至包括根据数据生成分析图表等等。这一类的需求，并没有标准答案，人们也并不指望 IT 系统给出一个确定性的答案，而只要软件系统给出的反馈，在某个可接受的“模糊区间”内，都是可接受的。就以统计图表为例，假设要生成某企业最近 12 个月的销售额变化趋势，其实人们需要的并不要求那个曲线上每个点的绝对坐标值正确，而只要那个曲线展示出来的变化趋势正确即可。

而非容错性需求，指的就是那种“绝对不允许出错”的情况。比如：软件根据销售团队的业绩贡献，计算销售人员的绩效提成；或者，需要系统支持某个业务流程，在 A 角色完成业务操作后，自动判断后续 B 角色需要执行什么业务操作。这一类的需求，是绝对不允许软件有哪怕一点点偏差的。甚至，在医疗、能源、交通等领域，这种一点点的偏差，可能会涉及到人身安全问题。

很容易就能得出这样的结论：对于有容错性的软件需求，完全可以交给大模型来自动生成软件代码，而几乎不用人类程序员的参与软件代码的纠错——也就是人类程序员可以退场；而非容错性的需求，就一定需要富有经验的人类程序员来对代码进行纠错（即：DEBUG）过程，才有可能最终让代码执行正确无误的业务逻辑。

所谓软件行业的市场蛋糕，本质上是由“人类程序员”这个角色处于产业链的哪个位置来决定的。知道了哪些场景下人类程序员可以安全退场，就可以进一步结合企业对“人类程序员”这一角色的组织能力，来判断软件产业链的蛋糕划分了。

3. 即便在人类程序员无法退场的领域，AI 也会提升开发效率 5~10 倍以上

前面已经说到，对于“非容错性软件需求”的开发，人类程序员是无法完全退场的。

但是，即使在这样的软件开发领域，AI 也会使得“软件开发”这一生产过程，效率得到极大的提升。在敏捷软件开发过程中，主要的工作量，可分为“需求与设计、代码编程、测试修错”3 大阶段（还有一个部署发布，但现在的部署发布一般都是自动化的，人工工作量可以忽略不计）。根据实际统计数据，其中代码编程、测试修错一般认为会占 80%以上的工作量。

关于“需求与设计”环节，其实这个部分的工作，除了特大型软件系统，大多数软件系统的开发过程中，并不一定需要由外部的软件厂商来提供服务，可能反而企业客户自身更适合做这件事。因为真正的业务知识是掌握在企业客户内部的，作为外部软件厂商，反而要向客户“学习”这部分知识。

所以，真正评估 AI 给“软件开发”这一生产过程带来的效率提升，应该主要关注“代码编程、测试修错”这两部分。

拿最近的大模型评测数据来看，其中代码编程部分，80%以上的工作量已经可以被大模型取代；而测试修错部分，其实有 70%以上的工作量，是程序员在编写代码做自动化测试代码。另据统计，“代码编程”与“测试修错”的工作量占比，目前是 3:2 的关系，也就是 60%在代码编程、40%在测试修错。

这样一来，在当前的大模型技术水平下，AI 能够替代“人类程序员”的工作量，就有 (60% + 40%*70%) *80% = 70%的比例。这实际上，就是让“人类程序员”的工作效率提升了 3 倍以上。

这还只是当前大模型发展水平下，可以不夸张的说，随着大模型的发展，预计 2~3 年内，人类程序员的工作效率可以提升 5 倍、甚至 10 倍以上。

4. 企业客户的组织能力和软件抽象能力，决定了市场蛋糕划分

在大模型加持下，对于企业客户来说，要满足自身的软件应用需求，无非就是三种方式：AI 自动生成软件、自己开发软件、对外采购软件。

显然，对于那种“容错性”软件，是可以直接用第一种方式来满足需求的。而对于“非容错性”软件，只能要么自己开发、要么对外采购。我们分别来看。

首先，对于“容错性”软件来说，很自然的就需要通过“软件开发 AI 平台”来完成。企业客户要决策的问题就变成了：这个“软件开发 AI 平台”从哪里来？

关于“软件开发 AI 平台”的来源，因为技术难度高、投资风险大、而又可以跨行业使用，无论对于大 B 还是小 B 来说，其都完全没有必要自己开发建设，而由专业的平台来提供。目前市面上，既有类似字节 coze 这样的 AI 应用开发平台，也有类似 devin 这样的“AI 程序员”创业项目，还有宜搭、简道云、明道云等这些零代码或低代码平台。

其次，对于“非容错性”软件来说，到底是自己开发、还是对外采购，完全取决于企业自身的投资水平和组织能力，很显然小 B 和大 B 是不同的。

对于小 B 来说，其组织规模一般在百人以下，甚至只有 10~20 人。在这样的组织里，哪怕“人类程序员”效率提升了 10 倍以上，但即使只招聘一个月成本 2 万（按工资、社保、办公费用等）以上的程序员，显然是不现实也是没必要的。

而对于大 B 来说，其组织规模一般几百人、甚至千人万人，既然“人类程序员”效率提升了 10 倍，那就可以通过招聘很少的程序员（很可能是个位数），来实现之前由一个庞大程序员团队才能完成的软件开发工作。也就是说，大 B 不需要对外采购专业软件公司的服务了。

但是，问题就是这么简单吗？其实不是，软件还有个“抽象设计”水平的问题。好的软件，不仅仅是满足某个大 B 客户的个性化业务流程的，还会根据多个同行业不同大 B 客户的业务流程进行“抽象归纳”，将“最佳业务实践”固化到软件设计中。很多大 B 购买某个软件，更多的不是看重该软件有多少功能，而是因为需要引入该软件所内置的某个“最佳业务实践”。

很显然，这部分“软件抽象设计”的工作不是 AI 大模型目前能够满足的。而且，在可预见的未来，这部分能力大模型也很难具备。所以，这部分工作，是需要由专业的软件公司才能胜任的。

当然，并不是说，所有的“非容错性”软件，都需要很高的“抽象设计”水平。事实上，80%以上的软件，是不需要进行“抽象设计”的——只满足当前的简单需求就好，根本不用考虑引入“行业最佳实践”这种东西。

总结起来看，软件需求的满足，将分为下图所示的 4 块蛋糕：

上图中，白底蓝字的，就不是软件市场，而是企业客户自我满足；而绿底白底的，才是软件市场之所在。分别解释如下：

• 软件开发 AI 平台。这部分市场，大概率是诸如字节 coze、宜搭+通义灵码等这些互联网大厂平台的机会。

• 为小 B 提供“非容错性”软件的服务公司。这是软件市场的机会，而且大厂一般看不上，所以是小创业公司的机会。

• 为大 B 提供专业的软件产品。这部分软件市场，典型的如 SAP、Salesforce 等，需要理解特定行业的多客户 know how，进行高水平的软件抽象设计后，才能在软件中内置“行业最佳实践”，从而为大 B 提供额外的价值增量。

到此为止，本文的分析就完成了。作为软件从业人员或企业，您考虑好了自己要吃 4 块蛋糕、3 个市场的哪部分了吗？