生成式编码是我们拥有过的、在坚实基础之上构建的最好工具。错误在于用它来逃避构建这个基础。

我预计在未来两年会越来越多地看到这样的情形。一家制造企业启动了一次正式的软件选型：真实的需求、真实的候选清单、真实的尽职调查。评估中越来越常被提及的一个因素，就是”vibe code”（生成式编程）对决策的影响。然后，在流程后期，一个一开始并不在名单上的”候选者”出现了：我们自己来做。

生成式编码工具让这个选项显得前所未有地可信。一个小型内部团队可以在几周内搭建出一个可运行的原型：演示效果好，无需授权费用,并且完全贴合当下的流程——因为它本来就是照着当下的流程打造的。评估中最难对付的对手,不再是另一家供应商,而是客户自己的团队。

我想认真对待这一点,而不是一笔带过,因为做出这个选择的人并不天真。他们回应的是一个真实的转变,其中一些理由是站得住脚的:更快拿到第一个可用版本、避开采购流程、对路线图拥有完全的掌控权,还有一个在董事会上很难反驳的顺风逻辑——既然AI能写代码,为什么还要花钱买软件?

你可以用生成式编码做出一个应用。问题在于,你能不能(或者说,应不应该)用它做出一整套制造执行系统(MES)。这个问题的答案,与代码生成器有多强大关系不大,而更多地取决于MES本身究竟是什么。

难的部分从来不是代码,而是模型

一个MES不是一个背后连着数据库的界面。它是对工厂如何运转的一种建模。在任何工作流变得有用之前,系统必须先能表达清楚:什么是一个批次(lot),什么是一个单位(unit),它们之间如何关联,物料如何拆分与合并,一个产品如何沿着工艺路线移动,它可能处于什么状态,一道工序需要什么条件,一项资源具备什么资质来完成什么工作,以及这一切彼此之间是如何连接的。

这张意义之网,就是所谓的”运营本体”(operational ontology)。正是这一层,使得诸如”这个批次现在能不能在这台设备上跑”这样的问题成为可回答的问题——因为答案取决于谱系(genealogy)、资质状态、配方、当前工序节点,以及一系列只有相互关联才有意义的约束条件。

缺失的一层

这正是生成式代码触及不到的层面。代码生成器非常擅长处理”看得见”的表层:界面、表单、把一个事物从一个状态推进到下一个状态的工作流。但它在本体这一层几乎是盲的,因为本体不是一个编码问题,而是一个建模问题——它凝结着几十年制造业实践中积累下来的经验判断,而这些判断不会出现在任何提示词里。你可以在一个下午内,在一个浅层的数据模型之上生成出一个令人信服的界面。

但你无法生成模型本身,因为模型是关于”这类生产实际如何运作”的经验积累,是判断力的沉淀。

于是,那个在评估中赢得青睐的原型,表层做得很快,但底层实质却是空的。它看起来像一个MES,该有的界面都有,但缺少了那层能让这些界面在工厂发生变化时依然保持正确的底层结构。

需求从不会静止不变

“按我们的需求定制”这句话,悄悄地其实意味着”按我们今天的需求定制”。这正是破坏力最大的一个假设,因为工厂的需求从来不是一份固定的说明书,而是一部不断展开的过程。

一条新产品线上线,带来一道在现有模型中毫无先例的工艺步骤;监管要求发生变化,记录的内容和签核方式都要改变;第二个工厂投产,却用不同的方式生产同一款产品;一次供应商变更迫使系统新增一条谱系分支;一起质量事件,要求一条横跨现有工艺路线逻辑的遏制规则。

这些变化中的每一个,都不只是”加一个新界面”那么简单,而是对模型本身的改动。而一个为了适配某个时间快照而生成出来的模型,并没有一个干净的入口来吸收这种改动。

建立在一个明确、被治理的模型之上的平台,能把这些变化当作配置来吸收。本体中已经具备相应的概念,变化可以用系统能理解的术语来表达,被版本化管理,并在升级中被延续下去。而一个生成出来的系统,只能把同样的变化当作新代码,硬生生地嫁接到一个从未被设计用来承接它的结构之上。

前一条路径是复利式的积累;后一条路径积累的是技术债,而且这种债是结构性的,不是表面的。”贴合”只是一张快照,而运营本身不是快照,是一部电影。

你生成出来的系统,如今归你所有

知识变得脆弱。模型只存在于搭建它的那两三个人的脑子里,而在一个生成出来的系统中,往往根本没有任何书面模型,只有恰好能跑起来的代码。没有供应商,没有用户社区,也没有外部强加的文档规范。

当那些人离开时,系统就不再被理解,而开始被人畏惧——这正是变革陷入停滞的时刻。

关于AI辅助编码的证据,并没有让这一点变得更乐观。

GitClear对2.11亿行代码变更的2025年分析发现,复制粘贴式的代码首次在历史上超过了重构式代码,重构代码占比从2021年的约25%降至2024年的不到10%。DORA的2025年《DevOps现状报告》(覆盖了AI使用已近乎普及的团队)发现,AI今年首次对交付吞吐量产生了正向影响,但它与交付稳定性之间的关系依然是负向的,表现为更多的变更失败与更多的返工。在Stack Overflow对超过4.9万名开发者的2025年调查中,66%的人提到的最大困扰是AI输出”几乎对,但又差一点”;46%的人表示不信任这种输出的准确性。

这些数据并不是在反对用AI写代码,而是在提醒我们:生成出来的代码随着时间推移会发生什么。而一套MES,是要用十五年的系统,不是用十五个迭代周期的系统。

由此而来的是经济账。初始搭建成本低且显而易见,而全生命周期成本高且隐蔽。软件的大部分生命周期,历来都花在维护而非初始搭建上,AI只改变了这本账的一侧:它降低了编写代码的成本,却没有降低验证、加固安全、集成以及每年重新认证这套系统的成本——而且是无限期地降低不了。

当你选择”自建”时,你买到的不是一个工具,而是决定要成为一家只服务一个客户的软件供应商,并承担永久性的人力投入义务。

关于跨工厂一致性的侵蚀、关于每一个连接ERP、设备和质量系统的接口都变得定制化而导致的”集成熵”,以及所谓升级路径实际上是一次重建——这些都值得单独成文。但贯穿其中的模式,值得在这里点明。

增强基础,而不是取代基础

我们并不是处在一个AI辜负了炒作的时刻,而是处在一个AI把软件生成得太好、以至于诱使我们把它对准了错误的那一层的时刻。

有两种哲学,在第一天看起来完全一样,却存在一条清晰的分界线。一种是用AI来增强一个坚实的基础:先把运营正确地建模出来,建立真正的本体,然后让AI去加速建立在这个基础之上的一切——用配置取代定制代码,用平台能理解、治理、版本化并能安全升级的逻辑。

同样的生成速度,一旦是作用在”意义”之上,而不是去发明一个替代意义的东西,就会成为真正的加速器,并且能够复利式地积累。

另一种哲学,则是用AI去取代基础工作本身。它生成的软件,充当了模型的替身,而不是建立在一个已经存在的模型之上。它演示起来很漂亮,却在悄无声息中退化,因为它上面的每一层——包括你之后想加上去的任何AI——都是在对从未被赋予真正意义的数据进行推理。这正是我一直在描述的”工业AI悬崖”(Industrial AI Cliff)这种失败模式。

AI的成熟度,受限于执行的成熟度。你只能对一个被正确建模过的运营采取智能行动,而一个生成出来的MES,恰恰跳过了让智能行动成为可能的那一步。

更广泛的证据也一致指向这一点。麦肯锡的报告显示,超过80%的组织没有从生成式AI中看到实质性的企业级息税前利润(EBIT)提升。BCG发现,只有大约5%的公司称得上”面向AI的未来型企业”(AI-future-built),而正是这一小部分企业,实现了最高达5倍的营收增长和3倍的成本削减——靠的不是更好的算法,而是更扎实的基础:规范化的数据模型、可执行的架构,以及一套真正反映业务运作方式的模型。

那些领先者并没有把AI对准基础层来省去建立基础的功夫,他们先建好了基础,然后才把AI瞄准了基础之上的一切。

问题已经变了

生成式编码并没有终结旧有的”自建还是购买”之争,而是把这个问题挪了个位置。现在的问题不再是”我们能不能自己写出代码”,这个问题的答案早已是肯定的,而且每个月都更加肯定。真正的问题是:”我们愿不愿意在工厂的整个生命周期里,拥有并验证这套执行模型,并为此变成一家软件公司?”

对少数组织来说,诚实的答案是”愿意”。但对大多数组织而言,这是一笔要到第十八个月才会显现出来的代价——那时,那个在评估中胜出的原型,不得不变成真正运行整座工厂的系统,承接此后发生的每一次产品变更、每一次审计,以及每一个新的AI项目。

结构先行,智能随之而来,改进才能复利式积累。

你可以用生成式编码做出一个应用,而且应该这样做——对于站在坚实基础之上的团队而言,它是我们拥有过的最好的增强工具。但用它做出一整套MES,恰恰是最有说服力的方式,让你误以为自己根本不需要那个基础。