软件公司最值钱的东西,不在代码里

AI浪潮生存手册 · AI吞噬软件？

过去两年，三位科技行业最有名的CEO相继说了几乎同样的话。Satya Nadella说微软30%的代码已经由AI写成；Sundar Pichai说Google 25%的代码由AI辅助生成；Dario Amodei预测，六个月内90%的代码将由AI写成。

这些数字未必精确，但那种扑面而来的 FOMO（错失恐惧） 极其真实。它让包括我在内的一线软件从业者产生了一种感觉：如果代码能瞬间生成，那我们过去引以为傲的技能，是否正变得透明且廉价？

于是，一个极具冲击力的推断快速占领了社交媒体：AI即将吞噬软件

但这个听起来无法反驳的逻辑，其实经不住细想。

因为它建立在一个极其脆弱的隐含前提上：软件 = 代码

代码只是最外那层

把任何一个软件拆开看，至少有五层：

代码层： 最外面那层皮，是业务逻辑的载体。

架构层： 支撑高并发、高可用的骨架。

业务规则层： 几十年沉淀下来的业务逻辑和行业 Know-how。

产品决策层：对未来的判断与博弈，是一个演进能力。

生态层： 最核心的一层，包括用户关系、合作伙伴网络、行业信任和数据积累。

越往里，越值钱。但越往里，越和代码无关。

代码是业务逻辑的载体，不是软件的价值。AI写得更快，就像打字速度变快——但打字速度快从来不是一本书值钱的原因。

巨信能掀翻微信吗

假设你今天有足够的钱，还有最牛的 AI，你开发了一个叫“巨信”的东西，功能更全、代码更稳、长得也更漂亮——它能掀翻微信吗？

答案可能想都不用想，肯定不行

尽管代码层和架构层，巨信都能复制——界面、消息收发、高并发、分布式存储，只要有钱有技术都做得到。甚至toC软件的业务规则层往往也不太复杂，但这三层都不是护城河。真正麻烦的是从产品决策层开始的。

即使你可以光速生成代码，但你还需要持续判断：做成超级App还是App矩阵？支付和社交怎么绑定才不让用户反感？而微信的成功不是偶然，是持续博弈的结果——这背后的推理过程从没被结构化记录过，AI无法替你做这些决定。

生态层是最硬的一道墙：13亿人的社交关系链，家人、同事、客户全在里面；几百万小程序是第三方开发者建的，不是腾讯工程师写的；还有多年的聊天记录、红包历史。

数据可以迁，但关系迁不走。习惯迁不走。

护城河不在代码里。在关系里。

同样的逻辑看 ToB：SBP 能颠覆 SAP 吗？

假设你有足够的钱，还有最牛的 AI，开发了一个 SBP——能颠覆 SAP 吗？

代码层和架构层，SBP 都能复制，界面甚至能比几十年前的 SAP 漂亮十倍。但正如我们前面说的，这两层从来不是护城河。

真正的麻烦，是从深不见底的“业务规则层”开始的。

在 ToC 领域，业务规则可能只是“点赞”或“转发”；但在 SAP 里，一个物料主数据模块就有上百个字段。这些字段背后不是程序员随便起的变量名，而是全球各行各业几十年总结出的“最佳实践”。

什么情况下用哪个字段、哪些组合会触发审计风险、三单匹配里的例外场景怎么处理。这些知识不在 GitHub 上，也不在技术论坛里，它们锁在资深顾问的脑子里，烂在客户十几年的定制化代码注释里。

退一步说，就算 SBP 靠大力出奇迹，把现成的配置和代码逻辑全部“硬抄”过去，也无济于事。因为抄得了一次，却无法继续更新。

当行业里出现新场景时，AI 根本不知道下一条规则该怎么写。它读得懂代码的语法，却不知道这些规则当年的“来龙去脉”——不知道当年是为了填平哪次库存积压的坑，才特意加了那个看似累赘的校验条件。没有对业务教训的理解，面对新需求，AI 只能靠猜。

虽然还有另一条路：把这些顾问脑子里、实施文档里的隐性业务 Know-how，一条条教给 AI。但只要你在项目一线待过就知道，SAP 五十年积累的规则，每一条背后都有例外和触发场景。要把这些全部提取并结构化，工程量极其恐怖。这笔账完全算不平。

再往深一层，是产品决策的权衡：

ToB 的产品决策不是为了“好用”，而是为了“合规与稳健”**。为了支撑全球几百个国家的准则转换，系统必须在“灵活性”与“控制力”之间做极其痛苦的博弈。而这种决策推理过程，从未被公开记录过，AI 看到的只有最终那行结果。

最后是生态层：

生态层是最厚的一层，它由多年积累的信任和标准织成。

这套系统不仅是在服务器里跑的代码，它更像是一套行业通用的“商业语言”。全球的实施伙伴生态围绕SAP建立了服务网络，这意味着当你遇到业务难题，总能找到懂行的人帮你解决；四大审计师都能熟练的对着这些字段出具合规报告；这种深度的共识，不是重写一遍代码就能替换的。

更难逾越的是那些长在企业骨干里的“活数据”：十几年的业务往来记录、跟周边成百上千个接口的深度集成、以及为了适配自有业务做的无数次微调。这些沉淀是 AI 读不到的，也是新系统搬不走的。

护城河不在代码里。在这些由标准、习惯和历史积累构筑的信任网络里。AI 读得到代码，读不到这种复杂的“利益共生”与“业务默契”。

退一步说：AI连代码这层也没搞定

很多人觉得，就算业务逻辑复杂，只要代码写得快，堆量也能堆出个未来。但CodeRabbit分析了470个真实的开源GitHub PR，发现AI生成代码的缺陷率是人类的1.7倍——每个PR平均10.83个问题，人类是6.45个。安全问题高出2.74倍，性能I/O问题高出约8倍。

这个数字背后的工程逻辑，源于 AI 与复杂软件系统之间两个不可调和的矛盾：

1.局部正确 vs. 全局耦合

在现在的软件项目中，写好一个函数、补全一段逻辑对 AI 来说已经不是难事。但软件工程从来不是孤立功能的堆砌。

尤其在 ToB 领域，一个接口的变动可能牵动财务、库存、采购三个模块的勾稽关系。AI 拥有极强的局部生成能力，却缺乏对“全局上下文”的深度感知。它能帮你写出一段性能优异的 SQL，但它不知道这段语句在真实的生产环境下，会因为触碰了某个陈旧的业务锁，导致整个系统瞬间瘫痪。

2.产出通胀 vs. 验证成本

当代码生成的门槛降为零，我们其实陷入了“生产力通胀”的陷阱。在软件开发生命周期里，最贵的从来不是“写代码”，而是“定义需求”和“逻辑验证”。如果 AI 用 1 秒钟生成了 1000 行代码，但资深架构师需要花 3 天时间去逐行确认这些代码是否覆盖了所有的异常分支（Edge Case），这种效率提升就是一种致命的幻觉。

代码生成的通胀，并没有消灭门槛，反而让“能看懂全局、能修补漏洞、能为最终交付负责”的人变得更贵了。

更深层的断裂在于：AI 只有“瞬时逻辑”，没有“业务记忆”。

在企业里，业务不是孤立的瞬间，而是连续的流。AI 可能写得出一个完美的计提函数，但它不懂为什么你上个季度的坏账计提比例，会直接影响这个季度的供应链采购逻辑——这种跨模块、跨时间的关联，对 AI 来说是盲区，但在真实的 ERP 环境里，这就是足以让系统崩盘的“致命伤”。

这种对“业务演进”理解的缺失，不是偶尔的失误，而是底层架构的约束。

有些技术小坑会随算力进步而填平，但这种业务上的“前言不搭后语”，是目前 AI 无法跨越的硬伤。

既然 AI 面前还有这些结构性的硬伤，那么结论就很自然了。

这些断层和翻车现场，恰恰揭示了软件行业的终极真相：代码只是逻辑的载体，是洋葱最外面那层皮。真正的软件公司，从来不是“写代码的公司”。

所以，与其担心 AI 会像黑洞一样“吞噬”软件，不如换个视角：

当代码生成的幻觉褪去，AI 真正的位置才浮现出来。它不是那个手握镰刀的收割者，而更像是一台超级引擎。如果没有底盘承载动力、没有方向盘控制方向、没有深厚的工程调优，这台引擎只会原地空转，甚至烧毁。

而聪明的软件公司，早就不在原地等了。

SAP 把几十年的业务规则封装成 AI 可以直接调用的接口；Salesforce 让 AI 渗进了每一个销售和服务动作；微软把 Copilot 嵌入了 Office 的每个角落。它们没有在等AI 来改变自己——它们在主动决定 AI 能做什么、在哪里做、按照什么规则做。

这不是被整合。这是在做整合的那个。

护城河没有消失，它正在被改造成进攻的武器。但怎么改造，走哪条路——这才是更加值得说清楚的事。

AI浪潮必然来临，但你还有时间：AI浪潮生存手册 · 开篇