AI 协同开发时代，活字格低代码平台的价值分析

先说结论

• AI 编程工具把写代码的成本压得很低，低代码平台「少写代码」的优势随之缩小：常规的增删改查、表单页面、简单报表，几分钟就能写出一版能运行的代码。
• 另一部分价值在 AI 时代更重要了：有限的构件划定了改动的范围，运行平台由平台方长期维护，结构看得懂、交接接得住，客户能自己改一部分。
• 一次交付里两者配合使用：结构化的表单、流程、权限放在平台里；接口、迁移、专门算法和文档交给 AI 与代码，由人审查和验收。
• 选型时要看清边界：应用运行依赖平台授权，换平台工程基本要重建；通用 AI 编程工具能直接读懂、改动的平台工程范围比普通代码小；业务规则和数据口径，仍要用真实数据在真实环境里验证。

活字格是葡萄城的低代码开发平台。我们用它给制造企业做过多年定制交付，《传统代码、制造业甲方、低代码、AI开发：我的四段从业经历》写过当时为什么选它：能部署在客户自己的服务器上，支持手机端，能多人协同开发，价格合适，遇到复杂业务可以直接操作数据库，也可以写代码扩展。

2026 年起，我们把 AI 编程工具正式用进开发：人定目标和规矩，AI 写代码、写测试、改代码，人审查和验收。组织这些 AI 编程工具的，是我们自研的工作平台 APSer-Atelier：它作为主控，登记每一件事，决定交给哪个执行器，核对结果，挂起待拍板的问题，见《APSer-Atelier 的场景锚定与价值定位，以及实践总结》。本文说的「AI 协同开发」，指的就是这种分工。

这里说的 APSer-Atelier 主控包括两部分：面对我们的主控会话（一段 Claude Code 或 Codex 对话），负责组织和派出；Atelier 平台，负责登记每一件事、挂起待拍板、记下要求、按规矩放行并留下记录。

用了一段时间，一个问题绕不开：写代码已经这么便宜，低代码平台「少写代码」的价值还剩多少？我们的回答是：一部分确实被冲淡了，另一部分反而更重要了。下面分开说。

低代码平台原本解决哪两件事？

低代码平台一直在解决两件事。

一是搭建成本。 表单、列表、流程、报表可以用拖拽和配置搭起来，客户能更早看到、更早用上，改起来也快。这是「少写代码」直接带来的。

二是运行平台。 用户与组织、权限、审批流程、报表打印、手机端、部署与升级，这些每个企业应用都要有、又和业务本身关系不大的部分，由平台现成提供，并由平台方持续维护。

AI 编程工具出现以后，这两件事受到的影响很不一样。

AI 冲淡了低代码平台的哪些价值？

常规的增删改查、表单页面、简单报表，现在用 AI 编程工具几分钟就能写出一版能运行的代码。只看「做出一个能用的页面要多久」，低代码平台的领先幅度比过去小了很多。

「业务人员自己也能做应用」这一条也有了新的实现路径：用自然语言描述需求，由大模型生成应用，已经有不少工具在做。

这部分我们如实承认：如果选低代码平台只是为了写得快，这个理由在 AI 时代弱了。

AI 时代，低代码平台的哪些价值更重要了？

生成便宜了，确认还贵

我们在《AI 写代码快了，交付怎么才靠得住：我们踩过的坑和现在的做法》里写过：AI 降低了写的成本，确认的成本没有随之降低。几分钟写出来的改动，要确认它没有改坏别的东西、在真实环境里确实能用，所需的时间并没有同比例缩短。

低代码平台在这里有一个容易被忽略的优势：构件的种类是有限的。页面、数据表、命令、权限、流程，每一种构件的行为由平台保证，审查一处改动时，看的是「配置了什么」，能出错的范围已经被平台划定。自由代码的每一行都可能带来新的行为，每一处都要审、要测。

AI 做的改动越多，这个差别越明显。有限的构件集合，相当于给 AI 的改动加了一道护栏。

运行平台由平台方长期维护

权限、组织、流程、审批、打印、手机端，AI 都能写出来。可写出来之后，每一项都成了交付方自己的代码，要长期维护、修补漏洞、跟着操作系统和浏览器升级。

活字格把这部分交给平台：支持本地部署，兼容国产化操作系统、数据库及软硬件 [3]；权限可以做到集团、公司、部门多级，细到字段；2026 年 5 月发布的 V12.0 又加入了统一流程中心，多个应用可以共用一套流程体系 [1][2]。这些长期成本由平台方分摊，交付方和客户都不必各自重做一遍。

对中小制造企业来说，系统上线之后谁来负责，往往比上线本身更难回答，《系统上线之后，谁来对它负责》专门谈过这个问题。运行平台交给平台方持续维护，是这个问题的一部分答案。

看得懂，接得住

在平台设计器里，数据表、页面、流程的结构一目了然。客户的 IT 人员，或者下一位接手的服务商，打开工程就能看懂系统大致怎么搭的，改小处不必先读懂大量代码。

AI 一次生成的代码量可能很大，写的人省了力，读的人未必省力。我们在 2020 年一次公开课上归纳过中小企业信息化的难题，其中一条是：最初做系统的人一换，新接手的人对系统和业务都不够了解，需求一变就很难跟上。这个问题在 AI 时代依然存在，结构清楚、看得懂的系统，交接起来更稳。

客户能自己改一部分

系统要跟着业务变，《随需而变：交付之后，系统要跟得上业务》写过我们的追求。低代码平台让客户身边懂业务的人，经过一些培训，就能自己改表单、加字段、调流程。小改动不必每次都等服务方排期，大改动再由服务方来做。

低代码平台正在怎样把 AI 接进来？

低代码平台也在向 AI 开放。从葡萄城公开的资料看，活字格的做法可以分成三个方向：

我们认为管控侧最值得制造企业留意。大模型接进业务系统以后，谁调用了、用了多少、结果能不能追溯，这些问题迟早要回答。平台把计量和管控做成现成能力，企业不必每个应用各做一套。

说明一点：表中能力来自葡萄城公开发布的资料，我们没有逐项在客户项目中验证；选型时请以实际版本的试用结果为准。

按《权力与预测》一书对新技术落地的分级 [4]，平台开放 MCP、让 AI 编程工具帮着搭应用，属于带来一种新做法的应用级；要走到价值最大的系统级，还要一起改变谁提需求、谁拍板、谁验收，这正是定制交付要做的事。

一次交付里，低代码平台和 AI 编程工具怎样分工？

按我们的经验和看法，AI 编程工具和低代码平台在一次交付里，比较合理的分工大致如下：

排程这类专门求解的逻辑，我们在《二十余年企业信息化的观察：七种形态、几条规律与大模型时代》里写过，常与代码或专用引擎配合实现，这一点在 AI 时代没有变。

选用低代码平台，要看清哪些边界？

• 平台授权与迁移成本：应用建在平台上，运行依赖平台授权；将来要换平台，工程基本要重建。选型时请把长期的授权费用和迁出成本一起算清。
• AI 对平台工程的可见度：平台工程主要在设计器里维护，通用 AI 编程工具能直接读懂、改动的范围，比普通代码小。官方的 MCP 服务正是在补这一环 [2]，实际效果要按版本和场景验证。
• 复杂算法与高并发场景：交给代码或专用引擎更合适，平台负责周边的录入、流程与展示。
• 平台构件不替业务把关：构件的行为由平台保证，业务规则对不对、数据口径对不对，平台保证不了。无论改动来自人还是 AI，都要用真实数据在真实环境里走一遍，才算完成。

以下是我们的看法

AI 时代，低代码平台的价值从「写得快」移到了「管得住、接得住、改得动」。 写的成本降了，维护、交接、确认的成本还在。平台用有限的构件划定改动的范围，用长期维护的运行平台分摊运行成本，用看得懂的结构降低交接成本，这三点在 AI 做的改动越来越多时更有分量。

两者配合使用，各做擅长的部分。 结构化的表单、流程、权限放在平台里；接口、迁移、专门算法和文档交给 AI 与代码。一次交付里同时用两种手段，按工作的性质分，不按工具的新旧分。

工具在换，交付的规矩不变。 从写代码到低代码，再到 AI，实现手段换了三种。系统要贴合业务、跟得上变化、出了问题能退回，这些要求一直没变，选什么工具，都要回到这几条上检验。

如果您正在考虑要不要用低代码平台建系统，可以先问自己四个问题：上线以后，谁来维护？日常的小改动，希望谁来改？系统里有没有需要专门算法的部分？大模型接进来以后，用量和调用要不要管、谁来管？这几个问题的答案，比「哪种方式写得更快」更能决定选择。

参考来源