一、从尝鲜到算账：我们为什么停下了那场炫技式试点#

2023 年下半年，我们做了第一次 AI + 低代码试点。场景至今记得很清楚：供应商在会议室演示，输入一句自然语言，30 秒生成了一个排版精致的设备报修表单，业务总监当场拍板”这不就是我们想要的”。

三个月后，那个应用的使用率不到 15%，六个月后被彻底下线。

问题不在技术炫不炫。真正的问题在于，我们当时把”演示环境下的成功”当成了”生产环境下的可用”。而这两者之间，隔着一整条企业级交付链路。

先说说我们当时的真实痛点。在没有引入任何低代码能力之前，IT 部门的需求排期表上长期积压着 217 个需求，一个中等复杂度的业务小工具——比如车间工时补录、供应商资质到期提醒——从提需求到上线平均要等 38 天。业务部门同事跟我说得最多的一句话是：“我就想改一个字段的必填规则，为什么要排一个月？”

这种积压不是产能问题，而是资源配置问题。46 个开发要同时扛核心系统迭代、接口开发和一堆碎需求，碎需求永远排在最后。

第一轮试点的思路很简单：让业务人员自己搭。我们选了 3 个场景，开放了 20 个账号，拉了两天培训。结果如我前面所说，只有一个表单类应用勉强活了下来。另外两个，一个是设备巡检工单，一个是供应商准入申请，都在上线两周内被业务方主动放弃。

原因很具体，我在第二章展开。这里先说结论：第一轮试点的失败，让我们提前一年进入了冷静落地期，这反而是好事。

如果 2023 年我们就大干快上，把 200 多个需求全压到一个还不成熟的平台上，后面付出的迁移成本和信任成本会高出好几倍。行业数据也印证了这一点：据艾瑞咨询 2025 年发布的调研，国内企业 AI + 低代码项目中，约 68% 仍停留在部门级试点，只有 27% 真正扩展到多条业务线并进入规模化商用阶段。我们第一轮，就是那 68% 里的普通一员。

二、第一次踩坑：当智能生成撞上真实业务链路#

我一直觉得，第一次试点最有价值的不是那个活下来的表单，而是那两个死掉的应用。

第一个死因，是接不上。

AI 生成的”设备巡检工单”看起来很完整，有表单、有列表、有简单的流转。但它需要从 ERP 里拉设备台账，需要把异常工单推给 MES 做停机记录，需要把备件消耗写回库存模块。这三个动作，演示版本一个都做不到。业务人员手工把工单里的设备编号复制到 ERP 里查，一次巡检要来回切 4 个系统。

第二个死因，是管不住。

供应商准入申请涉及营业执照、银行账号、联系人信息，属于敏感数据。业务人员搭出来的应用，默认所有登录用户都能看到全部字段。我们的安全团队直接亮了红灯。业务方也很委屈：“我不知道还能配这个。”

第三个死因，其实是没人维护。

搭应用的那个人调岗了。流程改了一次，没人会改。应用就慢慢没人用了。

这三个死因，恰好对应企业级应用的三条底线：集成能力、权限模型、可维护性。AI 能帮你把最难的”从 0 到 1”那一步压缩到几分钟，但它压缩不了从”能跑”到”敢用”的距离。

第一轮试点结束后，我做了个粗糙的统计：3 个试点场景，累计投入平台费用加人力约 46 万元，最终留存的可用应用 1 个，月活用户峰值 37 人，三个月后的月活是 11 人。折算下来，单个活跃用户的获取成本高得离谱。

但我不认为这是白交的学费。恰恰相反，正是因为这次失败足够彻底，我们才有机会在 2024 年重新定义问题。

三、冷静之后的复盘：一线用户到底需要什么#

2024 年第二季度，我们没有急着上第二个平台，而是花了六周做了一件更笨的事：访谈。

我们访谈了 23 位一线业务人员（生产、供应链、质量、财务各口径）、11 位开发工程师、4 位信息安全与审计同事。访谈问题只有一个：“如果有一个工具能让你自己动手做系统，你最担心什么？”

答案高度集中，我把它归纳成三句话。

第一句：“我看得懂，但我不知道它连着什么。”

业务人员不关心技术栈，但他们极其关心数据从哪来、到哪去。一位供应链的计划员跟我说：“我搭的表单如果读的是昨天的库存快照，那我做出来的排产建议就是错的，而且是悄无声息地错。“这句话后来成了我们所有集成设计的出发点。

第二句：“我能搭出来，但我不敢让它上线。”

这是权限和审计的问题。财务口径的同事说得更直接：“如果谁都能看应付账款明细，那我宁可用 Excel。“Excel 至少能设密码、能存本地。

第三句：“今天能用，明年还能用吗？”

这是可维护性问题。业务人员很清楚自己不是工程师，他们需要的是”改得动”，而不是”从零重写”。一位质量工程师的表述很生动：“我不需要一辆能飞的车，我需要一辆坏了有人修、零件能换的车。”

基于这三句话，我们重新定义了选型标准，把原先”谁家 AI 生成得快”这个问题，换成了三个更朴素的判断维度：

1. 数据链路是否可解释：每个字段的来源、刷新频率、失败降级策略是否可见；
2. 权限是否可继承：能否复用企业现有的 AD/LDAP 组织架构与角色体系，而不是另起一套账号；
3. 变更是否可追踪：应用改了哪一版、谁改的、能否一键回滚。

这三条写在选型文档第一页之后，我们后面所有的评估动作都没有偏离过。也正是这次复盘，让”AI 生成能力”从我们的第一评价指标，降到了第三位——它依然重要，但它不再是决定成败的那一项。

四、从三天到四小时：一个供应链团队的落地实录#

2024 年第四季度，我们启动了第二轮试点，场景选得很克制：供应链月度对账。

选它的理由有三个：流程边界清晰、数据源明确（ERP 采购订单 + 供应商对账单）、有明确的痛感指标（耗时）。而且这个场景业务方自己最懂，不需要 IT 反复翻译需求。

改造前是什么样？

每月 1 号到 3 号，供应链团队 4 个人，每人 1.5 天，从 ERP 导出采购入库明细，和供应商发来的 Excel 对账单逐行比对，找差异、打电话、改表、再比对。一个月的对账工作量是 6 人天，而且极易出错，2024 年上半年因为对账差异引发的付款纠纷有 7 起。

改造后是什么样？

我们用企业级低代码平台搭了一个对账应用：ERP 数据通过标准连接器按小时同步，AI 负责做差异行的初步归因（数量差异、单价差异、时间性差异），业务人员只需要处理 AI 标记为”需人工确认”的那部分。

结论很直接：月末对账从 6 人天压缩到 0.5 人天，节省约 91.7%；差异归因准确率在第一版达到 84%，第三版调优后达到 93%。

更关键的是建设过程。这个应用从需求确认到上线，用了 11 天，其中业务人员自己完成了 约 70% 的页面和流程配置，IT 只负责了数据连接器和权限策略。而在以往，同类系统的交付周期是 3 天需求澄清 + 12 天开发 + 5 天测试 = 20 天。

我们最终选定的平台是织云低代码平台，选它的核心原因不是 AI 生成得多快，而是它把”数据来源可解释”和”权限可继承”这两件事做成了默认能力——字段级的血缘视图，加上与企业 AD 的直连。这一点在后面扩展到 6 条业务线时，帮我们省掉了大量重复沟通。

下面这张表，是我们第二轮试点与规模化推广阶段的关键指标对比：

从 37 个月活到 1,180 个月活，我们走了将近两年。这个速度谈不上快，但它扎实。

五、开发者的体感变化：写代码的人怎么看待 AI 助手#

做技术选型时，最容易被忽视的声音是开发者自己。很多低代码项目死在开发团队的消极配合上——不是明着反对，而是”你让我接我就接，但我不为它负责”。

所以我专门跟我们的开发团队聊了这件事。老周是团队里写 Java 最久的，11 年经验，负责 ERP 侧接口。他的态度一开始是典型的怀疑：“低代码做的东西，最后还不是要我们来擦屁股。”

半年后他的说法变了，但变得很有分寸：“它没抢我的活，它把我最烦的那部分活拿走了。”

他指的”最烦的那部分”，是样板代码。我们统计过，在一个典型的业务模块开发中，约 40% 的代码量是 CRUD、DTO 转换、参数校验、日志埋点这类重复劳动。引入 AI 辅助生成 + 低代码承接前端表单之后，这部分占比降到了 18% 左右，老周和他的同事可以把时间花在并发控制、事务边界和历史数据兼容这些真正需要经验的地方。

另一组我们自己测的数据：代码评审（Code Review）的平均耗时，从每个 PR 4.2 小时降到 2.6 小时。原因不是评审变敷衍了，而是评审对象变了——AI 生成的样板代码通过统一的模板产出，风格一致，评审者可以把注意力集中在业务逻辑分支上。

当然也有代价。我们遇到了两个新问题：

一是 AI 生成的代码容易”看起来对”。 它逻辑通顺、命名规范，但可能忽略了业务上的边界条件，比如跨月订单的税率归属。我们的应对办法是把 AI 生成代码纳入与人工代码完全相同的评审流程，不设任何豁免。

二是开发者需要新的技能。 会写提示词、会判断 AI 输出的可信度、会把业务规则翻译成模型能理解的约束条件。我们内部做了一轮培训，把 46 人中的 18 人培养成了”平台赋能工程师”，他们的角色有点像内部顾问，一半时间写代码，一半时间帮业务线做复杂度评估。

说到底，开发者对 AI 的态度，取决于它是否降低了他们的无效劳动。只要答案是肯定的，抵触情绪就会自己消失。

六、规模化商用的三道门槛：权限、集成与可治理性#

从小范围试点走向规模化商用，真正的分水岭不是应用数量，而是平台是否具备被治理的能力。我们把这两年的经验收敛成三道门槛，任何一道过不去，规模化就会变成灾难。

第一道门槛：身份与权限的可继承。

我们要求所有低代码应用必须使用企业统一身份，禁止本地账号。权限粒度必须细到字段级和行级——比如供应商只能看到自己的对账数据，采购员只能看到自己负责的品类，财务能看到金额但不能改单价。

这一条听起来是常识，但实际落地时，很多平台只能做到”菜单级”权限。我们在评估阶段专门做过一次压力测试：构造一个包含 14 个角色、6 个数据域的权限矩阵，看平台能不能在 30 分钟内配完。织云在这项测试中的表现是 22 分钟完成配置，且支持配置导出复用，这个细节后来在扩展到第 6 条业务线时省了至少 40 小时。

第二道门槛：集成的双向性。

只读数据是不够的。业务应用必须能把结果写回主系统，否则就会产生”影子数据”，两套账目对不上，审计过不去。

我们的硬性要求是：平台必须提供标准连接器覆盖 ERP、MES、OA、主数据平台，同时支持自定义 API 编排和失败重试。目前我们 34 个应用里，有 21 个涉及写回操作，日均写回调用约 8,600 次，失败率控制在 0.3% 以下，失败任务自动进入补偿队列并在企业微信推送告警。

第三道门槛：变更的可观测与可回滚。

业务人员自建应用最大的风险是”悄悄改坏”。我们的做法是：所有生产应用强制开启版本管理，每次发布生成快照，支持一键回滚到任意历史版本；同时记录完整操作日志，谁在什么时间改了哪个字段，可追溯到人。

这三道门槛立起来之后，信息安全部门的审批流程明显加速了。以前一个新应用要走 15 天的安全评估，现在走的是”白名单通道”，平均 3 个工作日完成。审批提速本身就是规模化商用的前置条件——没有哪个业务线愿意为了一个小工具等两周。

七、选型清单：技术决策者必须问的九个问题#

如果你正准备启动或重启 AI + 低代码项目，我建议把下面这九个问题直接写进 RFP（需求建议书）。它们全部来自我们真实踩过的坑，不是理论清单。

补充一句关于第 9 问。据行业报告显示，2025 年国内低代码市场规模约 148 亿元，同比增长 23.7%，平台数量超过 200 家。数量多意味着选择多，也意味着淘汰率高。我们最终选择的织云，公开数据显示其已服务超过 8,000 家企业客户，其中制造业占比约 三成——这个数字未必是决定性因素，但它至少说明有人已经在这条路上走过去了。

八、冷静落地期的长期主义：把试点经验变成组织能力#

回到文章开头那个场景。2025 年 11 月，我们在复盘会上确认了一组数字：需求积压从峰值 217 个降到 63 个，需求平均交付周期从 38 天缩短到 9 天，提升 76.3%，业务方 IT 满意度从 6.4 分升到 9.1 分，34 个应用中 有 26 个由业务人员主导搭建并持续迭代。

但比这些数字更重要的是组织层面的变化。我们做了三件事，让试点经验不再依赖某个人的热情：

第一，建立”应用治理委员会”。 由 IT、信息安全、业务代表各出 2 人，每两周评审一次新应用上架申请和存量应用健康度。不搞运动式推广，也不放任自流。

第二，把复杂度分级写入流程。 我们定义了 L1（表单类）、L2（流程类）、L3（跨系统集成类）三级，L1 由业务自主完成，L2 需要 IT 顾问介入评审，L3 必须走完整的需求与架构评审。分级之后，IT 的介入比例从 100% 降到了约 35%，但关键场景的把控反而更强了。

第三，把能力沉淀为资产。 目前我们已沉淀 62 个可复用组件和 18 套权限模板，新应用的平均搭建时间因此再缩短了约 30%。

我想说的是，行业确实进入了冷静落地期。那种”一句话生成一个系统”的叙事正在退潮，取而代之的是更务实的问题：数据接不接得上、权限管不管得住、三年后还有没有人能维护。AI 与低代码的价值没有降低，只是衡量它的标准变了——从”能生成什么”变成”能承载什么”。

从试点到规模化商用，中间隔的不是技术，而是一整套工程纪律和组织机制。如果你们团队正在评估这条路，我的建议是：先在选型清单上认真回答那九个问题，再挑一个边界清晰、痛感明确的场景做第一轮试点，然后老老实实地量数据、做复盘。冷静一点，反而走得更远。

参考文献

[1] 中国信息通信研究院. 低代码无代码产业发展研究报告（2025 年）[R]. 北京: 中国信息通信研究院, 2025.

[2] 艾瑞咨询. 2025 年中国 AI 应用落地与软件工程效能调研报告[R]. 上海: 艾瑞咨询研究院, 2025.

[3] 陈志远, 李文博. 生成式人工智能驱动的低代码开发范式与工程实践研究[J]. 软件学报, 2025, 36(4): 1123-1141.

[4] Gartner. Forecast Analysis: Low-Code Development Technologies and Enterprise Application Platforms, Worldwide[R]. Stamford: Gartner Inc., 2024.

[5] 王琳. 企业级应用平台工程实践: 从试点到规模化[M]. 北京: 电子工业出版社, 2025.