企业应用的新形态：再议「自进化」落地的可能性

说明：本文发表后，我们把这一主张改称「可进化」，用意是强调改动由人确认、可以退回，见本栏目《AI 原生、本体与可进化：我们对 AI 时代企业应用的主张》；本文保留原来的「自进化」一词。

先说结论

• 我们把企业应用的「自进化」看作一条值得验证的假设：应用在日常使用中积累，在人的确认之下逐步调整；是否成立要看实践，其中每一步都可能被证伪。
• 设想中的新形态：内置的智能助手先备好草稿和待办，人的动作收敛为确认、驳回、修改约束；现场提出的调整落到参数、规则、流程上，每一次改动都留下来由。
• 落地前必须先满足七个前提：人来拍板，每一步可以回退，改动过守门检查，改动分层、核心少动，定期全面巡检，数据不出厂，企业里有人对系统负责。
• 风险在一次次改动之间累积、企业内部运行的模型能否胜任等问题，今天还没有答案；比较稳妥的顺序是先在真实项目里完善已有应用，从改动风险低的参数和规则开始，每一步设可以观察的指标和停下来的条件。

一套企业应用交付之后怎样持续变化，是个老问题。订单规则会变，车间会调整工序，新客户会带来新的检验要求，系统要么跟着改，要么慢慢被绕开。

本栏目《企业系统交付之后如何持续变化：六十年理念谱系与教训》梳理过这个问题的来龙去脉：「系统要跟着业务变，最好由身边的人来改」这条主张，六十多年里换过很多名字反复出现；规则越积越多、改错了没人发现、系统缺少真正负责的人、复杂度一年年累积，这些难点也反复出现。那篇文章末尾留下了几个问题：改动由谁判断对不对？哪些层允许快改？系统的主人是谁？出了错谁负责？累积的复杂度由谁清理？

这篇接着往下谈：有了大模型之后，企业应用能不能在日常使用中积累，在人的确认之下逐步调整，也就是常说的「自进化」。

先交代我们的态度：这是一条值得验证的假设，是否成立要看实践，其中每一步都可能被证伪。下文依次讲四件事：新形态可能是什么样子，落地需要哪些前提，哪些问题今天还没有答案，可以怎样一步步验证。外部事实标注出处，列在文末；我们自己的看法集中放在倒数第二节，并标明为观点。

有了大模型，这一次多了哪些条件？

谱系一文用一张表对照过大模型时代哪些前提变了、哪些没变，这里只挑与本题直接相关的几项。

把想法变成改动的成本降下来了。 过去一处改动要排进开发计划、按人天计价；现在，用自然语言把要求说清楚，写代码这一步的成本明显降低，谱系一文列过相关的公开数据。

自动检查成了日常做法。 用一组事先写好的检查去判断「这次改动有没有把原来能用的功能改坏」，已经是软件开发里的常规做法。

模型可以留在企业内部。 许可宽松的开源模型让「模型跟着数据留在厂里」在许可层面成为可能，本栏目《二十余年企业信息化的观察：七种形态、几条规律与大模型时代》谈过这一点。

同时也有几件事没有变：业务口径改得对不对，仍然要懂行的人来判断；持续变化中的复杂度会累积；出了错，后果仍由企业承担。下文讨论的前提与难题，大多落在这几件没有变的事情上。

新形态的企业应用可能是什么样子？

下面是本文讨论的一种设想，还没有经过实践验证。

一、内置的智能助手先做，人来拍板

今天使用企业应用，大多是人打开菜单，找到要处理的事。新形态里，工作的起点可能会换过来：内置的智能助手按时间或事件，先把准备工作做好，比如排好一版计划草稿、列出可能缺料的订单、汇总当天的异常，再把需要拍板的事推给对应的人。

执行的人收到的是备好的草稿和待办，负责人收到的是简报和待拍板的事项。人的动作收敛为三种：确认、驳回、修改约束。智能助手只准备、只提醒，不直接下发指令，也不替人批准。

二、现场提出的调整，能被理解并落到改动上

车间提出「这类订单以后优先排」「这道工序之后要加一次检验」，系统能理解这句话，把它落到相应的改动上。多数调整落在参数和规则上，一部分落到流程上，少数需要改代码。越靠近系统核心的改动，越要慎重。

每一次改动都留下来由：谁提出的，为什么改，改了什么，谁确认的，用什么方法验证过。过了一年，您仍然能查到系统为什么是现在这个样子。

三、系统在使用中积累业务规则和现场经验

现场的经验，比如某台设备换模要多久、某类订单能不能插单、某道工序为什么要隔夜，过去多半在老师傅脑子里，或者散在聊天记录和表格里。新形态里，这些经验会随着一次次调整，被整理成能追溯到原始出处的业务规则，留在系统里。

这方面的研究提醒过：让用户在使用中改自己的软件，单靠 AI 生成代码并不能消除全部障碍，还需要共享的数据，以及「每多一分定制能力，只需多学一点」这样平缓的上手坡度 [1]。所以，能积累下来的前提，是规则和数据本身有清楚的结构。

「自进化」要落地，必须先满足哪些前提？

下面这些，是我们认为「自进化」要落地必须先满足的条件。它们是前提条件，缺了其中任何一条，前面设想的样子都不宜在企业的真实系统上尝试。

一、人来拍板。 每一次改动在业务上对不对，由人判断。改动可以由智能助手起草，判断的权力留在人手里。有一项公开实验值得记住：一个能改写自身代码的智能体，不顾研究者的明确指示，移除了研究者用来检测其幻觉的标记，使检测结果显示出虚假的成功 [2]。评判标准不能交给被评判的一方。

二、每一步可以回退。 每次改动都是一个可以单独撤回的单位；每个验证通过的版本做好标记。新改动出了问题，先回到上一个验证过的版本，让业务照常运转，再查原因。

三、改动要过守门检查。 这里说的「守门」，是每次改动上线前自动运行的一组检查，核对系统里那些无论怎么改都必须成立的基本关系，比如领料不能超过库存，同一台设备同一时间只做一件事。检查不通过，改动就不上线。守门需要独立于生成改动的那一方：一项 2025 年的测试覆盖 100 多个大模型，结果显示 45% 的代码样例没有通过安全测试；模型写出能运行的代码越来越熟练，写出安全代码的水平却没有提高 [3]。看起来对，和确实对，是两件事。

四、改动分层，核心少动。 参数、规则、流程配置这些事先留好的扩展位置，可以改得快一些；核心代码改得越少越好。大型企业软件也是这样分级的：SAP 2025 年发布的扩展分级里，修改标准代码、直接写标准表、隐式增强被列为风险最高的一级 [4]。

五、定期全面巡检。 守门只看这一次改动；巡检定期把整个系统从头查一遍：基本关系是否仍然成立，规则之间有没有冲突，有没有长期不用、应该清退的规则。每漏过一个问题，就补上一条巡检项。巡检的意义，是把要求从「每一次都改对」降为「改错了能被及时发现」。

六、数据不出厂。 企业的业务数据、参数和原始单据留在企业内部；如果用到大模型，模型在企业内部运行；确需外部服务时，只让不含业务数据的内容离开企业，并事先取得企业同意。

七、企业里要有人对系统负责。 系统在使用中调整，需要企业里有一位「系统主人」：懂业务，能判断一次改动在业务上对不对，也有时间做这件事。1992 年一项对计算机辅助设计（CAD）软件用户的研究发现，用户群体里至少有一位同样懂业务的本地专家在支持其他人；部分组织把这个角色正式化，给予正式的认可、时间和资源，效果总体是好的 [5]。DORA 2025 年的报告也指出，AI 的主要作用是放大器，会放大组织原有的长处和短处 [6]。有人负责的系统，工具能帮它变得更好；没有人负责的系统，工具也会让问题来得更快。

哪些问题今天还没有答案？

满足了上面这些前提，也还有几个问题今天没有答案。

一、风险会在一次次改动之间累积。 单看一次改动，通常是一件范围不大的短任务；在只修单个问题的公开基准上，模型的成绩已经比较高 [7]。难的是长期：每一次改动单独看都对，合在一起却可能出问题，比如两条各自合理的规则放在一起相互打架。公开研究也显示，长周期的软件演化仍然困难。SWE-EVO 从七个成熟开源项目的版本说明中整理出 48 项任务，平均每项涉及 21 个文件；GPT-5.4 配合 OpenHands 只完成了 25%，作为对照，GPT-5.2 在只修单个问题的 SWE-bench Verified 上达到 72.80% [7]。RoadmapBench 用 115 项真实的版本升级任务测试 13 个前沿模型，最强的 Claude-Opus-4.7 解决了 39.1%，作者认为长周期软件开发「基本仍未解决」[8]。这两项测的是大规模版本升级，规模比工厂里一次次的小调整大得多，不能直接套用；它们提示的是，风险要放到多年、成百上千次改动的尺度上看。

二、企业内部运行的模型能否胜任。 前沿模型在长周期任务上尚且如此，企业内部服务器上能运行的模型能做到哪一步，要在真实的硬件和真实的改动上实测，目前没有现成的答案。

三、企业里有没有能对系统负责的人。 有信息部门，不等于有人能判断「这类订单该不该插单」「交期该按哪个日期算」。就我们所见，能接住这些判断、又有时间的人，在很多中小制造企业里本来就稀缺。

四、企业自己能改到哪一层。 让企业自己改得越深，系统越贴合现场；改到核心，又会回到旧式二次开发的老路：版本分叉，升级困难。这条线划在哪里，需要在实践中找。

五、从零新建应用，比完善已有应用难得多。 能改代码的方法，理论上也能从零写出一个新应用。但新建是更长的任务；新应用一开始没有守门，基本关系要先设计出来；每多一个应用，就多一份需要主人、守门和巡检的系统，否则很容易变成没人维护的应用。

还有一个容易被忽略的前后顺序。《权力与预测》一书指出，预测和判断之间有一个「先有鸡还是先有蛋」的困境：不知道拿预测去做什么，就不愿投资预测；没有预测，也想不清该怎么判断 [9]。放到企业应用里，要让系统提出改动，先得把判断写下来：哪些口径不能动，改错了各付什么代价，谁来拍板。这一步做扎实了，模型提出的改动才有对照的尺子。

可以怎样一步步验证？

按上面的前提和问题，比较稳妥的验证顺序是：先在真实项目里完善已有应用，其他的放在后面。

• 先从改动风险低的一层开始。 先是参数和规则，再是流程，代码改动放在最后；从零新建应用，排在完善已有应用验证通过之后。
• 每一步设可以观察的指标。 从现场提出到上线用了多久；守门检查拦下了多少改动、是哪些类型；有多少问题漏过了检查、上线后才被发现，每一个是否都补上了一条巡检项；智能助手准备的草稿有多少被直接确认；回退了几次、每次用了多久；企业一方自己提出并确认的改动有多少；巡检发现并清退了多少规则。
• 每一步都设停下来的条件。 草稿很少被直接确认，说明助手只是多加了一层待办；漏检的问题持续出现，说明守门和巡检还不够；企业里没有人接得住判断，或者内部运行的模型达不到要求，相应那一步就先停下。

这些前提里，有几项在我们交付方这一侧的工作中已经在用，用的是我们自研的 APSer-Atelier（它的来历和边界见《APSer-Atelier 的场景锚定与价值定位，以及实践总结》）：需要人拍板的事项单独列出，等人答复后再往下走；上线结果以实际观察到的版本和运行状态为准，执行一方自己报告的「成功」不算数，上线失败时有没有退回、退到了哪个版本，也按实际状态记录；每天早上对我们自己的各个项目做一次只读巡检，查文档和代码是否与约定一致，发现的问题列进待处理清单，只报告、不自动修改。这些做法用在交付方这一侧。放到企业自己的系统上，能否同样成立，正是要验证的。

以下是我们的看法

以下内容是我们的观点，供您参考。

第一，大模型降低的主要是「改」的成本。 判断一次改动在业务上对不对的成本，基本没有下降。「自进化」能不能落地，要看这一部分由谁承担、怎么承担。

第二，系统越想灵活，越需要一部分固定不动。 基本关系要写死，核心计算要少动，验证过的版本要留好。能灵活调整的，是这些固定部分之外的那一层。

第三，「自进化」能否成立，取决于改动的秩序。 谁提出，谁判断，怎么检查，怎么退回，多久全面查一次。这几件事有清楚的答案，才谈得上让系统在使用中逐步调整。

第四，评价一个「会自己变好」的系统，可以先问它怎样处理改错。 改错了能不能被发现，多久能发现，能不能退回，谁来负责。这几个问题的答案，比演示时改得有多快更能说明问题。

我们接下来计划做什么？

我们计划在项目中尝试这个方向。想验证的是：系统交付之后，业务规则、现场经验和每一次改动的来由，能否在日常使用中持续沉淀下来；在此基础上，系统能否在人的确认之下逐步调整，而且每一步都可以回退。

是否可行、能做到什么程度，要看实践。有了结果，我们再来报告。本文是对可能性的探讨，不构成对任何产品功能的承诺。如果您的企业也在想系统交付之后怎样持续改、改得稳，欢迎预约交流。

参考来源