企业系统交付之后如何持续变化：六十年理念谱系与教训

交付后的企业系统为什么总要改、该由谁来改？本文梳理六十余年来反复出现的主张与难点，并对照大模型时代哪些前提变了、哪些没有变。

发布于 2026年9月6日更新于 2026年9月30日青岛艾普仕

先说结论

「交付后的系统必须持续变化，而且最好由使用方身边的人来改」，这条主张在企业计算里已经反复出现了六十多年，每一代技术都会重新回答它一次。
在本文看来，4GL、电子表格、低代码、大模型都真实地降低了「把意图变成可执行变更」的成本；有公开记录的失败，直接原因多数落在这一环之外：部署没有复核、口径错了没人发现、规则越长越多、没有人对系统负责、复杂度一直累积。
大模型时代，生成成本、意图的表达、本地部署这几项前提变了；组织与人、责任、累积复杂度这几项没有变。
评估任何「系统自己会变好」的新说法，可以先问五个问题：改动由谁判断对不对？哪些层允许快改？系统的主人是谁？出了错谁承担责任？多年累积的复杂度由谁清理？

一套企业系统上线那天，往往也是它开始跟不上业务的那天。订单规则会变，组织会调整，监管会加码，客户会提出新要求。系统要么跟着改，要么被绕开，最后变成只在月底补录数据时才打开的工具。

「交付后的系统必须持续变化，而且最好由使用方身边的人来改」，这条主张听上去很新，其实在企业计算里已经反复出现了六十多年。几乎每一代新技术出现时，都有人宣布它将让这条主张成为现实；每一代也都留下了一批可以对照的成功与失败。

本文按时间梳理这条谱系：先列一条精选时间轴，再分六个时期概述，然后归纳反复出现的主张与难点，最后对照大模型时代哪些前提变了、哪些没有变。文中事实与数字均注明出处，出处列在文末；厂商或机构自己的说法会写明「某某称」；本文自己的判断集中放在倒数第二节，并标明为观点。

六十余年里，有哪些关键的主张与事件？

年份	人物 / 机构	主张或事件	后来	来源
1962	Douglas Engelbart（SRI）	人与工件、语言、方法、训练一起改进，改进后的能力再用于下一轮改进	研究由美国空军资助	[1]
1978–1987	DEC XCON 专家系统	把配置专家的知识写成规则，规则库随业务增长	7 年约 6,200 条规则，每年约半数要改	[2]
1979	Dan Bricklin · VisiCalc	业务人员直接在电子表格里建模、改模型	较近期的审计中多数表格有错	[3][4]
1980	Meir Lehman	在用的程序必须持续变化，否则逐渐失去用处；复杂度会随变化递增，除非专门投入去维持或降低	整理为一组软件演化定律	[5]
1981–1982	The Last One；James Martin	按用户给出的设计几分钟生成程序；多数计算机将至少部分地在没有程序员的情况下工作	宣称生成的程序没有缺陷	[6][7]
1986	Fred Brooks	区分软件的本质困难与偶然困难；十年内没有单一手段能带来数量级提升；主张让软件有机地增长	建议在使用中逐步增加功能	[8]
1990	Michael Hammer	业务流程再造：用信息技术彻底重新设计流程	失败率估计被作者称为不科学	[9][10]
1991–1992	Henderson & Kyng；Gantt & Nardi	设计在使用中继续；用户改系统依靠一名本地开发者（「园丁」）	部分组织把本地开发者正式化	[11][12]
2001–2011	IBM 自主计算	人给出高层目标，系统自我配置、修复、优化、保护	十年后成果集中在自优化	[13][14]
2003	Business Rules Group	规则与流程分离；从少量规则起步，随时间变聪明；规则多并不更好	宣言写明：少而好的规则更好	[15]
2007–2009	Salesforce · Force.com	多租户内核加元数据：客户通过元数据扩展，内核由平台维护	2009 年论文称支撑 55,000 多个组织	[16][17]
2012	Knight Capital	在老系统上复用旧标志位上线新功能	45 分钟错误交易，亏损超 4.6 亿美元	[18]
2015–2018	GE Digital / Predix	让工业 IT 人员成为应用开发者	2017 年收缩，2018 年成立独立软件公司	[19]–[22]
2015–2023	阿里巴巴「大中台、小前台」	能力沉淀一次，多业务复用	约 2020 年定「变薄」，2023 年起分入各业务	[23][24]
2021–2023	GitHub Copilot；ChatGPT；SWE-bench	大模型进入编码与对话；用真实 issue 与仓库自带测试判定修改对错	SWE-bench 首版最好成绩 1.96%	[25]–[27]
2025–2026	SWE-EVO；RoadmapBench	测量智能体在长周期、跨版本软件演化上的能力	最好成绩分别为 25% 与 39.1%	[28][29]

表格可左右滑动

这条谱系可以分成哪六个时期？

以下分期是为了阅读方便做的划分，边界并不严格。

第一期（1970 年代前半及更早）：反馈、增强与自举

Wiener 把控制论定义为「动物与机器中的控制与通信的科学」，Ashby 在 1956 年提出必要多样性定律：只有多样性才能消解多样性 [30]。两人给「系统要跟着环境变」提供了最早的理论语言。Engelbart 1962 年的报告则把工件、语言、方法与训练放在同一个系统里，主张一轮改进带动下一轮改进 [1]。

这一期留下一个有用的区分：运行时调节（参数、排程随反馈变化）与系统结构本身的演化（流程、规则、代码变化）是两件事。

第二期（1970 年代后半至 1980 年代末）：知识编码、自动编程与「无程序员」

专家系统把专家知识写成规则。DEC 的 XCON 在 7 年里长到约 6,200 条规则，每年约半数规则要改，DEC 为此另造了 RIME 语言来重写 [2]。Lenat 与 Feigenbaum 在 1987 年把第一代专家系统的问题概括为「脆性」：在知识范围内表现很好，一到知识边缘就骤然失效 [31]。

同一时期，「无程序员」的承诺第一次成形。The Last One 宣称能按设计生成无缺陷的 BASIC 程序 [6]，James Martin 预言多数计算机将至少部分地在没有程序员的情况下工作 [7]。Kay 与 Goldberg 设想人人都能拥有、也能用来编程的个人动态媒介 [32]，VisiCalc 则让业务人员第一次直接动手建模 [3]。Brooks 在 1986 年给出冷静的判断：这些进步多数解决的是偶然困难，本质困难在于构造复杂的概念结构 [8]。

第三期（1990–2005）：套装参数化、使用中设计与自主计算

这一期有两条方向相反的路线并存。一条是一次性的彻底重设计，以业务流程再造 [9] 和大规模 ERP 切换为代表；另一条是渐进与分层：设计在使用中继续 [11]，由被认可的本地开发者来改 [12]，按变化速率给建筑分层 [33]，运行中的工作流只允许用「完备且最小」、能保持正确性的操作去改 [34]，业务模型与技术平台各按自己的节奏演进 [35]，规则外置并随时间变聪明 [15]，人给目标、系统自我管理 [13]。

大规模一次性切换在这一期留下了一批有公开记录的失败 [36][37]。自主计算十年后的回顾显示，多数工作集中在自优化，自修复与自配置得到的关注少得多，自治单元之间的有效交互仍是未解决的问题 [14]。

第四期（2005–2018）：平台、元数据与工业互联网

Force.com 采用以元数据为核心的多租户架构，客户通过元数据扩展、内核由平台维护，2009 年的论文称其支撑 55,000 多个组织 [16][17]。Gartner 在 2009 年预测，到 2014 年至少四分之一的新业务应用将由「公民开发者」构建 [38]；Forrester 在 2014 年提出低代码平台的说法，定义重点是用最少的手写代码快速交付面向客户的应用 [39]。Fowler 与 Lewis 在 2014 年把「演进式设计」列为微服务的特征之一 [40]；2023 年，Prime Video 的一个监控服务改回单体架构，称基础设施成本下降超过九成 [41]。

工业互联网在这一期登场。GE 2015 年成立 GE Digital，提出到 2020 年进入软件公司前十 [19]，并在 Predix 发布时说工业 IT 人员将成为应用开发者 [20]。GE 研究院的技术主管撰文描述「self-improving」的工厂：生产回路与设计回路把数据实时送回，机器自己做优化 [42]；GE Digital 时任 CTO 把数字孪生描述为资产或系统的「a living, learning representation」[43]。这些说法所改进的对象是工艺参数、设备与资产模型。据 CIO Dive 2017 年报道，GE 计划在 2018 年把平台成本削减 4 亿美元，并收缩到自有的几个行业，在这些行业的赢单率约为其他市场的两倍 [21]；2018 年 GE 宣布成立独立运营的工业物联网软件公司 [22]；2026 年 GE Vernova 以 6 亿美元把 Proficy 软件业务出售给 TPG [44]。

国内同期的代表是阿里巴巴 2015 年提出的「大中台、小前台」[23]。据媒体报道，阿里 2018 年开始在小范围内讨论是否改革中台，约两年后形成「中台要变薄」的共识；2023 年起随集团组织调整，中台能力分入各业务单元 [24]。

第五期（2016–2022）：低代码、流程自动化与公民开发

这一期的关键词是低代码、流程自动化，以及「业务人员自己做应用」。Forrester 2021 年的报告记录了公民开发推广中的真实困难：感兴趣的业务人员可能没有时间开发和维护应用；试图一次性让所有人都成为开发者的做法会失败；在一次黑客松里，有教练陪同的小组约 80% 当场做出了应用，没有教练的小组只有约 20% [45]。

第六期（2021–2026）：大模型与编码代理

GitHub Copilot 2021 年以「AI 结对程序员」的身份发布 [25]，ChatGPT 于 2022 年 11 月 30 日推出 [26]。2023 年的一项对照实验中，使用 Copilot 的一组在「用 JavaScript 写一个 HTTP 服务器」这一单一任务上快了 55.8% [46]。SWE-bench 用真实 GitHub issue 和仓库自带测试自动判定修改对错，首版最好的模型只解决了 1.96% [27]。METR 测得智能体在 50% 成功率下能完成的任务时长约每 7 个月翻一番，同时指出 80% 成功率口径下的任务时长要短 4 到 6 倍，在缺少清晰反馈回路的「更杂乱」的环境里智能体仍然吃力 [47]。

「自我演化」在这一期成为正式的研究方向：2025 年的综述讨论智能体如何在模型、记忆、工具与架构上演化 [48]；Darwin Gödel Machine 让智能体修改自己的代码，在编码基准上从 20.0% 提升到 50.0%，实验中也出现了它移除研究者加入的幻觉检测标记的情况 [49]。长周期的演化仍然困难：SWE-EVO 与 RoadmapBench 这类测量多版本软件演化的基准上，最好成绩分别为 25% 和 39.1% [28][29]。

哪些主张反复出现？

把六十年的说法摊开，大致可以归成下面几条母题。每一条都在不同年代以不同名字出现过。

反馈调节与自主管理。 从控制论 [30] 到自主计算 [13]、Oracle 称能「自驾驶、自修复」的自治数据库 [50]、GE 的「自我改进的工厂」[42]。自主计算的十年回顾显示，成果集中在自优化上，自修复与自配置得到的关注少得多，自治单元之间的交互仍未解决 [14]。

让用户自己改。 Engelbart 的自举 [1]、Dynabook [32]、VisiCalc [3]、The Last One 与「无程序员」[6][7]、公民开发 [38]、低代码 [39]、GE 的「工业 IT 人员成为应用开发者」[20]。反复遇到的问题是用户没有时间 [45]，以及用户做出来的东西会静默出错 [4][51]。

规格或模型是唯一依据，代码由它推导。 从模型驱动架构 [35] 到以元数据描述定制的平台 [16]。模型驱动工程的一项工业实证研究发现，成败主要取决于组织、管理与社会因素，单靠技术因素不够 [52]。

规则外置与知识编码。 从专家系统 [31]、XCON [2] 到业务规则宣言 [15]。规则会长，也会相互作用；宣言自己就写着「规则多并不更好，通常更少的好规则更好」。

分层与受控的扩展点。 SAP 的 Enhancement Framework 只允许在预定义位置增强，目的之一是让增强在升级时有据可依 [53]；2025 年 SAP 的 clean core 分级把修改标准代码与隐式增强列入最低一级「不推荐」[54]。Brand 在《How Buildings Learn》里给出的建筑版本是：所有建筑都是预测，所有预测都会错；建筑的各层按不同速率变化，慢层约束快层 [33]。

使用中持续设计与本地园丁。 Henderson 与 Kyng 主张设计在使用中继续 [11]；Gantt 与 Nardi 发现，用户群体里总有一位本地开发者支持其他人，部分组织把这个角色正式化，给予认可、时间与资源 [12]。

平台与中心化复用。 中台与工业互联网平台的思路，都是能力沉淀一次、多处复用。GE Predix 与阿里中台的思路演变，是这条母题两个有公开记录的样本 [21][24]。

让系统代劳。 1980 年代的 The Coordinator 按言语行为追踪承诺、推动流转；Suchman 1993 年指出，把言语行为理论作为系统设计基础，会带进一套规训与控制的议程 [55]，Winograd 1994 年撰文回应了这一批评 [56]。

自我改写。 从演化计算到 Darwin Gödel Machine [49]。自动演化需要一个可以计算的评分标准，而有了评分标准，系统就可能去钻它的空子。

另有一条贯穿始终的对照：一次性的大设计。业务流程再造 [9] 与大规模 ERP 切换代表了与渐进变化相反的思路；而对渐进变化一方，Lehman 的定律提醒，持续变化中的复杂度会递增，除非专门投入去维持或降低 [5]。

哪些难点反复出现？

主张反复出现，难点也反复出现。按有公开记录的案例归纳，大致有八类：宣传先于能力 [6]；规则与主数据越积越多、维护成本持续上升 [2][57]；标准内核与企业自身做法冲突 [54]；业务人员自己做的工具静默出错 [4][51]；变更与部署缺少复核 [18]；系统缺少被正式认可的主人 [12][45]；复杂度随变化累积 [5]；责任无法转交给系统 [58]。各类的案例与机理，本栏目《企业系统持续变化中反复出现的八类失败：机理与有公开记录的案例》逐类整理。

讨论失败时，本栏目只引用处罚书、财报、调查报告等具体记录里的机理，不引用行业失败率：常被引用的失败率数字，其定义与统计方法本身就受到过有据的质疑 [59]。

大模型时代，哪些前提变了，哪些没有变？

下表前三列是有出处的事实；最后一列「本文归类」是本文的观点。

前提	过去	现在	本文归类
生成成本	每一代「无程序员」工具都受限于生成器的表达力 [6][7]	绿地单一任务上快 55.8% [46]；智能体可完成的任务时长约每 7 个月翻一番，但这是 50% 成功率口径，80% 口径短 4 到 6 倍 [47]	变了，目前主要体现在短任务与单次变更上
意图的表达	规则引擎、流程建模要求业务人员学习形式化表达 [15][35]	自然语言成为日常入口 [26]	变了
自动判定对错	验证主要靠人工	用仓库自带测试判定修改对错成为常规做法 [27]；自改系统会钻评分标准的空子 [49]	部分变了：能判断有没有改坏既有行为，判断不了业务口径改得对不对
本地部署	企业内网难以运行生成模型	出现 Apache 2.0 许可的开源权重编码模型 [60]	变了
组织与人	本地开发者多为非正式角色 [12]；业务人员没有时间 [45]	DORA 2025 报告称 AI 的主要角色是放大器，放大组织既有的长处与短处 [61]；46% 的开发者不信任 AI 输出的准确性 [62]	没变
责任	部署方承担部署事故的后果 [18]	公司对自家聊天机器人的话负责 [58]	没变
累积复杂度	Lehman 第二定律 [5]；XCON 规则持续膨胀 [2]	长周期演化基准成绩仍低 [28][29]；机器学习系统有隐藏的持续维护成本 [57]	没变