随需而变：交付之后，系统要跟得上业务

先说结论

• 业务一直在变，系统要跟得上：定制系统的价值很大一部分发生在交付之后，改得动、改得稳，决定了一套系统能用多少年。
• AI 让改动来得快，我们用自研的「可持续交付的底座」APSer-Atelier 管住改动的秩序：每次改动有计划、有核验、有记录，改错了能回到上一个验证过的版本；它只在我们这一侧使用，交付给您的系统独立运行，不依赖它在线。
• 系统要分层看待：参数和规则可以改得快一些，流程配置其次，核心代码改得越少越好；一些基本关系固定下来，守不住的改动不上线；一次改动在业务上该不该做，由企业里懂行的人判断。
• AI 加持下，应用在交付之后可进化是一条值得验证的方向；我们计划先从改动风险低的参数和规则开始尝试，这不构成对任何产品功能的承诺。

青岛艾普仕做企业信息化，有三条价值主张：求真务实、唯有定制、随需而变。这是第三篇。

我们的第三条主张是：业务在变，系统要跟得上。

什么是随需而变。 随需而变，指一套系统在交付上线之后，随着企业的订单、工艺、设备和人员变化持续调整：每次调整有来由、有核验、可以回退，系统始终和现场的实际对得上。软件工程里很早就有人把这件事写成了规律：Lehman 1980 年提出的软件演化第一定律「持续变化」说，一个被实际使用、反映现实业务的程序，要么持续变化，要么逐渐变得不再有用 [1]。

2020 年，我们在一次公开课上讲中小企业信息化的难题，归纳过三条：预算有限，知识储备有限，需求一直在变。第三条说的是：企业的需求会不断变化，最初做系统的人一换，新接手的人对系统和业务都不够了解，需求一变就很难及时跟上。那时我们想找的，是一种能在有限的预算里做到「按需定制、随需而变」的做法。

六年过去，实现手段从写代码、低代码一路换到 AI，这八个字一直是我们的追求。前两篇讲了落到实处、贴合现场；这一篇讲交付之后：系统怎样跟着业务一起变，而且变得对、变得稳。

一、系统上线之后，业务会怎样变？

一套为工厂定制的系统，上线那一天，往往是它和当时业务最贴合的一天。

之后，变化一件接一件地来：新客户带来新的检验要求，车间调整了工序，一台新设备进了厂，订单的插单规则改了，一位熟悉系统的同事调了岗。每一次变化，系统都要跟上。跟不上的地方，现场就会在系统外面另起一张表，久而久之，系统里的数据和现场的实际就对不上了。

「系统要跟着业务变」这个问题由来已久，六十多年里换过很多名字反复出现，难点也反复出现：规则越积越多，改错了没人发现，系统缺少真正负责的人。这段历史，我们梳理在《企业系统交付之后如何持续变化：六十年理念谱系与教训》里。

所以在我们看来，定制系统的价值，很大一部分发生在交付之后。交付之后改得动、改得稳，决定了一套系统能用多少年。

系统跟上业务的几种做法

业务变了之后，系统常见的跟法有下面几种，各有适合的情形：

几种做法可以并存。我们的体会是，变化越是本企业特有、越是持续发生，越需要最后一种做法兜底。

二、改得快了，怎样还能改得稳？

AI 让写一段改动的成本降了下来。改动来得快了，计划、复核、留痕、回退这几件事的分量反而更重。

这一点有调查数据可以参照。谷歌云的软件交付研究项目 DORA 在 2024 年的《加速：DevOps 现状报告》里调查了近 3,000 名软件从业者，统计估计：团队对 AI 的采用程度每提高 25%，软件交付的稳定性约下降 7.2%（稳定性用变更失败率和返工率衡量）[2]。报告的解读是，开发过程变快，并不会自动带来更好的交付，小批量改动、扎实的测试这些基本功仍然要守住。

为此，我们给自己的交付搭了一块「可持续交付的底座」：APSer-Atelier。它是我们自研、用在自身交付中的工作平台，在 2026 年用 AI 做项目交付的过程中，碰到一个真实的痛点就长出一种做法，一点点积累起来。它管的是改动的秩序：

• 每一次改动有计划。 先写明目标、范围和验收标准，再动手。
• 每一次改动有核验。 执行的一方报告完成不算数，检查和测试另行重跑，最终在真实环境里验收。
• 每一次改动有记录。 计划、验证和上线结果都留有记录，能追溯到是哪一次改动、为什么改。
• 改错了能退回去。 真实验收通过的版本另做标记，新改动出了问题，先回到上一个验证过的版本，让业务照常运转，再查原因。
• 知识不随人和工具流失。 项目知识写进项目自己的开放格式文档，换人、换工具都能接手。

APSer-Atelier 只在我们这一侧使用，不安装到您的工厂里；交付给您的系统独立运行，不依赖它在线。它目前仍在持续打磨中。它的来历和边界，写在《APSer-Atelier 的场景锚定与价值定位，以及实践总结》里；它背后的几条原则，写在《APSer-Atelier 的几条原则》里。

三、哪里可以快改，哪里要少动？

随需而变，并不意味着哪里都可以随手改。我们的做法是把系统分层看待。

参数和规则这一层，比如班次日历、换型时间、优先级，是事先留好的调整位置，可以改得快一些；流程配置其次；核心代码改得越少越好。越靠近系统核心的改动，越要慎重。

同时，一些基本关系要固定下来，比如同一台设备同一时间只做一件事，领料不能超过库存。我们的做法是：每次改动都要守住这些关系，守不住的改动不上线。

我们的体会是：系统越想灵活，越需要一部分固定不动。能灵活调整的，是这些固定部分之外的那一层。

一次业务变化，怎样落到系统里

1. 记下变化和来由。 写清现场哪里变了、由谁提出、影响哪些单据。来由写清楚，日后才知道这条规则为什么存在。
2. 判断改动落在哪一层。 是参数和规则、流程配置，还是核心代码。层级决定了改动的风险，也决定了验证要做到多深。
3. 先定验收标准，再动手。 用哪几张真实单据、看到什么结果算改对。标准定在前面，验收时才不会以「看起来差不多」收场。
4. 过守门检查。 逐条核对那些固定下来的基本关系，守不住的改动不上线。在 APSer-Aps 里，这一步已经用在数据写入上：一键排产写回，以及派工、报工等写入，在同一笔提交里前后各核对一遍几条跨模块规则，比如生产订单的开工不早于所挂物料的到货，同一批供给分出去的数量不超过供给量；违例变多，整笔撤回、不保存。
5. 在真实环境验收，标记验证过的版本。 用第 3 步定下的单据走一遍，通过后另做标记。新改动出了问题，有一个确定的版本可以退回。
6. 交企业里的负责人确认，并留档。 把来由、影响和验证结果交代清楚。业务上该不该这样改，由懂行的人判断；留下的记录，让下一位接手的人看得懂。

四、系统跟着业务变，由谁来照看？

系统跟着业务变，需要企业里有人对它负责：懂业务，能判断一次改动在业务上对不对，也有时间做这件事。

交付方能做的，是把改动做对、做稳、做得可追溯；一次改动在业务上该不该做，要由企业里懂行的人来判断。所以我们主张在交付中和客户一起明确这个角色，并把每次改动的来由、影响和验证结果交代清楚，让判断的人心里有底。系统上线之后由谁照看、需要什么授权，我们在《系统上线之后，谁来对它负责》里专门写过。

五、AI 加持下，应用能不能在交付之后持续进化？

说到这里，我们想把「随需而变」再往前推一步。

过去，系统跟上业务的方式，是等下一轮需求、下一轮开发。我们在实践中感受到，AI 加持下，这件事有了新的机遇：大模型把「改」的成本降了下来，可持续交付的底座把「改对、改稳、改错能退」管住了。两者合在一起，我们相信，应用在交付之后，可以继续生长。

我们设想的样子是这样的：系统在客户的日常使用中，积累业务规则和现场经验，比如某台设备换模要多久，某类订单能不能插单，某道工序为什么要隔夜；现场提出的调整，由智能助手先起草，再由懂业务的人确认；每一步都小步推进、留下来由、可以回退。这样，系统越用越贴合这家工厂。

这是一条值得验证的方向，要走通，前提很多：改动要由人确认，每一步可以回退，改动上线前要过守门检查，核心少动，定期全面巡检，数据留在企业内部，企业里有人对系统负责。哪一条缺了，都不宜在真实的系统上尝试。

我们计划在自己的项目中尝试这个方向，先从改动风险低的参数和规则开始，逐步往前走。是否可行、能做到什么程度，要看实践；有了结果，我们再来报告。这里写的是我们的主张和正在尝试的方向，不构成对任何产品功能的承诺。

以下是我们的看法

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

第一，随需而变，是定制系统的应有之义。 定制，贴合的是一家工厂此刻的样子；随需而变，贴合的是它往后每一天的样子。两者缺一不可。

第二，变得快，靠工具；变得稳，靠规矩。 模型和工具会一代代更替，改动的秩序要比工具更稳定。规矩稳定下来，工具才可以放心地换。

第三，评价一套会变的系统，先问它怎样对待改错。 改错了能不能被发现，多久能发现，能不能退回，谁来负责。这几个问题的答案，比演示时改得有多快更能说明问题。

第四，交付之后的持续进化，值得认真试一试。 AI 让「系统在交付之后跟着业务一起慢慢长」有了更现实的可能。我们愿意在自己的项目里小步验证，把看到的结果如实讲出来。

如果您的工厂也在想，系统交付之后怎样持续改、改得稳，欢迎预约交流。青岛艾普仕以制造业深度定制化交付为主业，做过注塑、五金、电子整机、铸造、假发、化工等行业，自研 APSer-One 制造运营管理平台与 APSer-Aps 生产排程系统。

---

本系列其它篇：《求真务实》《唯有定制》

参考来源