AI 都能写代码了，还要做企业级软件吗？

写这篇文章的缘起有两个，一个是最近尝试自己用氛围编程的方式做一些产品 demo；一个是前几天跟几位同行一起讨论中国 2B 行业时，有人提到一个观点，现在 AI 写代码效率这么高，用 AI 做外包会不会很赚钱？

这些尝试和讨论都让我有感而发，所以写下这篇文章，与大家分享我的一些思考。再次声明，本文仅代表个人观点。

01.标准软件是效率更高的方案吗？

神策从创立第一天起，就将自己定位为一家产品型公司，以打造卓越的产品为追求和努力的方向。这背后固然一方面是创始团队的个人偏好与倾向，一方面也是基于一个当时行业里的共识：标准软件是比项目型定制化开发效率更高的解决方案。

在创业初期，包括我在内，整个团队对于这一看法一直深信不疑，并且也为之付出了很多努力。到目前为止，神策累计服务了超过 2000 家国内外几十个不同行业的客户，虽然部署方式多种多样，但是依然保持是同一套代码、同一套产品。团队一直为这个目标的实现而感到自豪，背后也付出了软件工程、产品管理方面的很多努力与一些必要的代价。

只不过在过去有一段时间，总有一些场景让我会怀疑，标准软件真的是效率更高的方案吗？

例如，同样一个复杂项目，我们有标准产品，能够基本满足客户 70% 以上的需求。而某一个友商是一个地方性质的定开公司，完全没有产品积累，需要针对客户需求从头开始开发。然而，他们报出的价格只有我们的 60%，并且很顺利地低价中标。我一直以为他们没有办法顺利完成交付，过了一年之后，得知他们也顺利完成了客户的验收拿到了尾款。

很多产品公司在创业早期，都能找到那些能够覆盖大部分客户需求的一些功能点。但是，当软件迭代一段时间后，会发现客户提过来的需求从客户的角度来看是非常有道理的，却只有很少的客户才需要。做这样的功能，软件会变得臃肿，维护成本激增。不做的话，总有友商会承诺实现，导致客户流失，影响长期经营。

又比如，大家都知道目前中国 2B 软件公司，甚至包括某些“前辈”上市公司，大部分都还在努力通过削减成本来实现盈利。但是与此同时，国内存在着大量从几十人到几十万人规模的项目型公司，他们都有非常好的利润，甚至有些公司从成立第一年就一直保持盈利。

见到的这些案例越来越多，有的时候不仅会让我怀疑，在 2B 行业，标准软件相比定制开发真的是效率更高方案吗？是更好的商业模式吗？当然，这背后有很多中国特色的特殊情况，我在之前一篇文章中也专门讨论过：

从程序员到 CTO 的十年创业血泪总结（八）：原教旨主义 SaaS 与中国特色 2B 软件。

诚然，完全理性决策的“理性人”，只存在经济学家抽象化后的世界中。在实际的竞争中，甲方乙方都会有很多不理性决策，更何况公司不是一个人。

不过，抛开这些无法改变的背景，有些时候对这个问题的回答，我觉得可能还是需要回到软件的本质，思考企业级软件到底是什么？我们为什么需要企业级软件？

02.企业级软件是对主流客户的主流需求的抽象

之前有一个观点，认为企业级软件是对企业内部最佳管理实践的抽象。这一个观点我是非常认可的，不过我觉得也可以从另一个角度来阐述这个问题：企业级软件也是对主流客户的主流需求的抽象。

主流客户，说明我们解决的是我们目标客户群体中具有较大相似性的那部分客户的问题。其它的客户，则要么过于“先进”，要么过于“落后”，他们的需求我们暂时不考虑。

主流需求，说明在我们定义的问题域里面，我们只解决那些客户有共性的问题。其它的需求，我们在做软件设计的时候暂时也不考虑。

我们来做一个简单的数学题。

假设市面上一共有 100 个客户，每个客户有 100 个需求。这中间有 80 个客户，他们的 80% 的需求是有共性的。我们基于这 80 个客户共同的 80 个需求来打造一款标准软件。

我们假设定开公司，完成一个客户的一个需求的成本是 1 元。而因为打造标准软件，毕竟需要考虑各种通用型、可扩展性、稳定性等，我们假设把需求抽象成软件的时候，一个需求的成本是 10 元。因此，软件公司花在软件打造上的研发成本就是 800 元。

同时，由于定开公司是专门为了做定制化开发而生存的，管理定开本身有相当的难度，所以他们通过定开方式解决客户需求的效率更高。因此我们假设标准软件公司用定开方式解决客户一个需求的的成本是 2 元。

我们假设市场是没有竞争的，这 80 个客户都变成了这家软件公司的客户，软件研发成本可以充分摊薄。那么，为了解决这 80 个客户中的一个客户的所有需求，标准软件公司的成本是 800/80+20*2 = 50 元，定开公司的成本是 100*1 = 100 元。标准软件公司效率更高。并且，标准软件公司能够拿下 100 个客户中 80 个客户，市场规模也更大。

从这个角度看，在目标客户上，标准软件好像的确是一个更好的商业模式。但是，在这个计算过程中，有很多变量都会影响最终的结论，例如：

• 市场上如果有多家标准软件公司，那么每家公司的客户数量有限，研发成本就不能充分摊薄，结论可能会不一样。
• 是否真的有 80% 的客户有 80% 的需求是相同的？如果这个数字变成两个 50%，结论又会不一样。
• 我们假设的是这 100 个需求的难度和重要性都是一样的，但是在现实中，通常情况下，那些长尾需求可能在实现难度上和竞争的重要性上，都比共同需求要更加复杂。

这几个变量中，客户的个性化需求是目前标准软件公司和定开公司在竞争上最大的差异点，也是目前看 AI 最有可能带来变化的，我们主要来讨论一下这个话题。

03.每家公司都觉得自己是“特殊”的

基本上每一家公司，不论大小，都会觉得自己是特殊的，自己的需求是特殊的。

神策是一家并不大的公司，并且自己就是做企业级软件的。所以，团队内部肯定也是倾向于，只要能买的软件就一定不要自己开发，毕竟买软件又便宜出问题又有乙方可以甩锅，而且也是支持包括自己在内的国内 2B 软件行业。我们也的确采购了很多企业级软件，用起来也没有什么大的问题。

但是很遗憾，我们依然有部分重要的内部系统是自己招人开发的。因为我们也觉得自己的需求是“特殊”的，我们的管理理念是更“先进”的，现有的标准产品满足不了我们。而面对内部流程和标准产品不一致的情况，我们和大部分公司一样，没有选择改变自己。

除了存在特殊情况特殊需求之外，我们也发现，有时候部分企业并不一定希望自己的能力能够被某一个标准软件标准化，从而扩散出去。特别是如果这部分能力是核心能力。

04.客户的“个性化陷阱”

面对标准软件无法满足内部需求的情况，从甲方的视角看，企业有两种选择。第一种选择就是自己通过内包或者外包的方式来进行研发，就是我们通常所说的“自研”和“定开”。第二种选择则是基于已有的标准软件来做扩展和定制。

面对第二种选择，从乙方也就是标准软件公司的角度来看，可以有如下几种方式来满足客户的个性化需求：

• 增加研发成本，增强标准产品的可配置能力，用配置的方式来满足客户的需求；低代码可以视作一种特殊的配置能力。
• 增加研发成本，完善标准产品的 Open API，基于 Open API 来用定开的方式满足客户的需求。
• 完全从零开始用定开的方式来满足客户的需求。

第一种和第二种方式，都需要额外增加研发成本，并且也会增加产品复杂度提高维护成本。同时，从实践中我发现，对于很多标准软件公司来讲，由于它的组织、流程建设等的原因，它并不擅长管理定开，所以使用第二种或者第三种方式，它的效率会低于从一开始就把自己定位为定开的企业。更何况，定开企业虽然没有标准产品，但在不同项目之间，也有很多组件、模块级别的复用。

上面的种种因素导致，标准软件公司在满足客户的长尾个性化需求方面，相比定开公司在竞争时并不占据优势。而这些需求对于甲方来讲又非常重要，所以很多时候会导致甲方和乙方都非常痛苦。

05.AI 带来的变量

这种不平衡的竞争态势，以及甲乙方之间的不匹配所带来的痛苦，在 AI 代码能力快速增长的今天，可能会面临一些新的变化。

在我自己之前用氛围编程尝试做一些产品 demo 的过程中（一个四十岁“老”程序员如何使用 AI 提升效率），我对于当前 AI 写代码的能力，有如下一个总结：AI 非常擅长做快速原型开发，降低试错成本；擅长从零开始开发一个新的项目；擅长做标准功能模块的快速生成；擅长做接口对接和数据处理自动化。AI 不擅长对已有的复杂代码做维护；暂时做不了复杂业务逻辑的深度理解；做不了跨部门协调和流程优化；也做不了用户体验的精细化设计。

那么，对于定开公司来说，每一个客户都是一个新的项目，新项目的开发其实是特别适合使用 AI 来提效的，这方面应该能够有比较多的利润增量可以挖掘。如果发展到了极致，可能就是对于任何一个客户的任何一个需求，都由 AI 专门来生成对应的代码解决。

而对于标准软件公司来说，除了在定开过程中的提效以外（虽然我觉得标准软件公司在这方面永远竞争不过定开公司），最重要的还是要将 AI 应用到标准软件本身的开发中。这方面除了软件开发本身有一定的提效（AI 处理已有项目远不如开发新项目）之外，最重要的还是产品形态本身的一些改变。例如：

• 产品形态从 GUI 逐步向 LUI 变化，降低软件的使用成本；
• AI 可以帮客户完成智能的配置，降低为满足客户个性化需求的交付门槛；
• 产品的 OpenAPI 应该是 AI 友好的，例如提供 MCP，方便 AI 基于产品本身来进行扩展开发满足客户个性化需求。

除了这些工程上的工作之外，更重要的还是应该考虑商业模式的变更，来寻求与定开公司的错位竞争。如最近行业里面火热的从 SaaS 到 RaaS（Result as a Service），标准软件公司可以寻求从交付工具变成交付结果。一方面，预算不再是 IT 口径的预算，而可能是营销类预算，不仅预算规模上有数量级上的差距，也不会再与定开公司竞争同一份预算出口。另一方面，交付结果需要大量的行业认知，需要服务过相当数量的客户才能形成竞争壁垒，能够真正地发挥规模优势。

毕竟，客户从来都是只在意最终结果的好坏，并不太在乎是通过使用什么工具来达成最终结果，更不在乎这个工具是由 AI 还是人打造的。如果睡一觉起来数据就能够增长了，客户一定不会选择去用一个复杂、精美的软件来自己干活。

06.新的可能性

很难知道 RaaS 模式是否能够顺利推行下去，但是我们不妨还是对企业级软件未来做一些展望。

未来的企业级软件，固化下来的所谓平台/中台部分的范围可能会进一步缩小，更多的应用层、UI 层、展现层都是 AI 根据每一个客户的个性化需求和使用习惯单独生成的，每一个觉得自己是“特殊的”客户，都能够得到一个独一无二的“软件”。

未来的企业级软件的用户，不仅仅是“人”使用友好的，也应该是 AI 友好的，不同软件、不同 Agent 能够很好地互相协作、访问、对接。

未来的企业软件，也许不再是"一套系统用十年"，而是"十分钟配出一套系统"。

未来的进化趋势，可能会是客户不需要自己使用软件功能，而是直接告诉系统自己的目标，让系统自己去向目标进行逼近。客户不再是软件功能的使用者，而仅仅是监督者。

END