一、从”演示厅里的AI”到”工位上的AI”：一个技术负责人的三次踩坑#

第一次踩坑是在2023年底。我们花了大价钱引入一套AI能力平台，供应商在现场演示时，AI自动识别图纸、自动生成工单，效果惊艳，会议室里掌声一片。可真正上线到车间后，老师傅们用了三天就集体弃用——因为AI生成的工单格式和我们现有的MES系统完全对不上，每张单子还得人工重排一遍。演示厅里的AI很聪明，工位上的AI却很笨，这是我们的第一课。

第二次踩坑是2024年春天。我们换了思路，先找一个业务部门做试点，选了采购部的供应商准入流程。业务同事用低代码拖拖拽拽，两周就把表单和审批流搭出来了，当时大家都觉得找到了捷径。但问题很快就来了：这个流程只覆盖了采购部，等其他部门想复用时，发现字段定义、组织架构、权限模型全是按采购部习惯定制的，换个部门就得从零重建。那次试点，成了孤岛式的自娱自乐。

第三次踩坑更隐蔽。我们终于下定决心做平台化，但选了一个AI能力很强、低代码能力偏弱的组合方案，结果开发同事抱怨”AI给的代码还要我逐行改”，业务同事抱怨”改个字段还要找IT”。两拨人互相推诿，项目拖了五个月，最后不了了之。

三次踩坑之后，我才真正明白一件事：AI和低代码不是两个独立的能力，而是一枚硬币的两面。AI负责”理解和生成”，低代码负责”承载和运行”，缺了任何一面，试点都很难长成全域。

二、试点为什么常常烂尾：用户体验视角下的四个真实堵点#

后来我复盘了身边十几家同行的案例，发现试点烂尾的原因高度重合，主要集中在四个堵点上，而且每一个都是从用户体验里长出来的。

堵点一：第一公里太陡。 很多平台的AI助手需要用户先写清楚Prompt，还要懂数据结构、懂字段映射。可我们一线的仓库管理员，连Excel透视表都不太会用。你让他先学会”描述需求”，他宁可去找IT提工单。工具的起点，不能高于用户的起点。

堵点二：中间一公里太散。 试点跑通一个流程后，想复制到第二个、第三个场景，往往要重新做数据对接、重新配权限。我们做过统计，一个已经跑通的流程复制到新部门，平均还要花3.5天做适配改造，其中60%的时间浪费在重复的字段映射和权限配置上。

堵点三：最后一公里太堵。 试点成功之后，怎么从1个场景扩到10个、30个？大部分团队卡在这里。没有统一的模板库、没有组件复用机制、没有版本管理，结果每扩一个场景就像重开一个项目，人力根本跟不上。

堵点四：运维阶段太黑。 上线之后出了故障，业务同事只能干等IT排查。我们内部做过一次统计，一个中等复杂度的流程异常，从业务反馈到定位根因，平均耗时118分钟，其中70%的时间花在”到底是哪一步错了”的确认上。

这四个堵点，本质上都不是技术问题，而是体验问题。而体验问题的背后，是AI能力和低代码平台没有真正咬合在一起。

三、由热转实的拐点：当AI能力被装进低代码的骨架里#

2024年下半年，我们重新做了一次技术选型，这次的目标非常明确：不要两个拼在一起的方案，要一个AI原生嵌入低代码内核的平台。所谓”嵌入内核”，我总结成三条判断标准，也是我们最终选型的依据。

第一条，AI要能读懂”业务语言”，而不是”技术语言”。 业务同事在对话框里输入”我要一个设备点检流程，每天早班一次，异常自动通知班组长”，平台就应该能直接生成表单、流程、通知规则三件套。不是生成一段代码让他去改，而是生成一个能直接跑起来的东西。

第二条，AI生成的结果必须是”可拆可改”的。 这一点特别重要。AI生成的不应该是黑盒，而应该是标准化的组件和配置，业务同事可以在上面拖拽微调，IT同事可以在下面做扩展开发。AI负责把0变成0.7，人负责把0.7变成1，这个分工才合理。

第三条，从试点到全域，必须有”复制”这个动作的原生支持。 一个流程跑通后，能不能一键生成模板、一键适配新部门、一键同步权限？如果没有这个能力，全域落地就只能靠堆人力。

我们最终选用的方案是JNPF。选它的直接原因很简单：在一次内部测试中，我们让采购部一位完全没有开发背景的同事，用自然语言描述了一个”供应商年度复审流程”，平台在4分钟内生成了含18个字段、3级审批、2条自动提醒的完整应用，他只改了2个字段名称就发布了。这个测试结果，比任何PPT都有说服力。

更重要的是，JNPF把AI能力做成了流程设计器的一部分，而不是飘在外面的一个聊天窗口。字段生成、流程建议、权限推荐、异常定位，这些AI能力都嵌在了具体的操作动作里。对我们这种既要照顾一线业务同事、又要满足IT治理要求的企业来说，这种”不越位”的设计反而更实用。

四、选型现场实录：技术决策者最该追问的六个问题#

选型那两个月，我们一共接触了七家平台。我把当时问过的、也是我认为最有价值的六个问题整理出来，供正在选型的同行参考。

问题一：AI生成的产物，是代码、配置，还是黑盒？ 如果答案是”代码”，意味着你需要有开发能力去接；如果是”黑盒”，意味着后期改不动。最好的答案是”标准化配置 + 可扩展代码”双轨。

问题二：从试点复制到第二个场景，需要多少人工介入？ 这个问题我问了七家，答案差异极大，从”基本零改造”到”需要重新配一遍”都有。这直接决定了你的全域落地成本。

问题三：权限模型能不能跟着组织架构自动走？ 制造业组织架构调整频繁，如果每次调整都要手动改权限，运维量会失控。

问题四：私有化部署之后，AI能力还能用吗？ 我们是制造企业，数据不出内网的底线不能破。有些平台的AI能力只有公有云版本才有，这一点必须提前确认。

问题五：业务同事的上手时间，实测是多少？ 不要听”简单易用”这种形容词，要让他们现场做一个真实场景，掐表计时。

问题六：出故障时，业务同事能不能自己定位到具体环节？ 这决定了你的运维人力投入。

下面这张表，是我们当时对五家主流平台做的横向对比，维度都是围绕上面这六个问题设计的。评分是我们在真实场景测试后打出的综合分（满分10分），仅供参考。

需要说明的是，这份评分只代表”我们的场景+我们的用户”，换一家企业结论可能完全不同。选型没有最优解，只有最匹配解。

最终定下来之后，我们给自己设了一条纪律：不做第二次重复选型，把精力全部放在落地节奏上。

五、从1个试点到37个场景：一次全域落地的推进节奏拆解#

2025年1月，我们正式启动新一轮推进。和之前不同的是，这一次我们没有一上来就铺开，而是严格按节奏走。

第一阶段（1月—2月）：1个试点，但要做”标准试点”。 我们选了设备管理部的”设备点检异常闭环”作为唯一试点。之所以选它，是因为它跨了3个部门、涉及4类角色、有明确的数据指标，是一个”麻雀虽小五脏俱全”的场景。这个试点我们要求做到三件事：全流程无人工干预、业务侧自主搭建、所有组件可复用。

第二阶段（3月—4月）：5个场景，验证复制效率。 我们把点检流程沉淀成模板，复制到巡检、保养、备件申领、能耗上报、安全隐患上报五个场景。这一步我们重点关注一个指标：每新增一个场景的平均耗时。结果是平均1.2天/场景，而之前我们做类似规模的定制开发，平均需要11天/场景。

第三阶段（5月—8月）：扩到37个场景，进入全域落地。 到8月底，我们在生产、供应链、质量、人力、财务五个域一共上线了37个应用场景，覆盖4200余名员工，日活跃用户稳定在2800人以上。

几个关键数据对比：

这些数字背后，其实是一句话：AI + 低代码的价值，不在于做得多快，而在于让业务自己做得出来。

六、一线开发者的24小时：AI + 低代码如何改写日常工作#

说数据总觉得有点干，我讲两个真实的小场景，你可能会更有感觉。

场景一：设备管理部的老周。

老周今年48岁，做了二十年设备管理，Excel玩得很熟，但一行代码都不会写。以前每次要新建一个点检标准，他要先写一份需求文档，交给IT排期，等上两三周，上线后还要反复沟通调整格式。

现在他的做法是：打开平台，输入”帮我建一个空压机月度点检表，包含压力、温度、油位三项，异常时自动推送给维修组组长”，2分钟内生成初稿，他自己拖拽调整了两项，当天就发布使用。他跟我说了句话，我印象特别深：“以前是我求IT，现在是我自己就能干。”

场景二：开发团队的阿凯。

阿凯是我们IT部门的三名开发之一，以前他的日常是写表单、写接口、配权限、改字段，一天下来做不了几件”有技术含量”的事。现在他的时间分配变了：日常需求里约七成由业务同事自助完成，他主要做两件事——一是做复杂的跨系统集成和数据治理，二是把业务同事做得好的应用沉淀成企业级模板。

他上周做的一个”供应商资质自动核验”应用，集成了天眼查接口、内部ERP和风控规则，用了JNPF的扩展开发能力加AI辅助生成，整体耗时1.5天。他说如果按老办法，这个至少两周。

这两个场景讲的是同一件事：AI + 低代码并不是要取代开发者，而是把开发者的时间从重复劳动里解放出来。 这也是我们认为”由热转实”最实在的一个标志。

七、全域落地之后：最容易被忽视的三件治理小事#

很多团队以为场景上线了就万事大吉，其实真正的麻烦往往是上线之后才开始的。我们踩过之后，总结了三条经验。

第一件事：建立应用目录和应用Owner机制。 37个场景上线后，最大的问题不是搭建，而是”谁负责”。一个流程卡住了，业务找IT，IT说你去找业务，最后没人认领。我们现在给每个应用指定了业务Owner和技术Owner双负责人，并且在应用目录里标注清楚联系人和最近一次更新时间。这一条推行之后，平均问题响应时长从4.2小时压缩到48分钟。

第二件事：管住”AI生成”的质量下限。 AI生成速度快，但也可能生成看起来合理、实际有隐患的配置，比如权限给得过宽、审批条件写反了。我们的做法是设置”发布前检查清单”，一共12项检查，其中5项由AI自动完成，剩下7项由业务Owner确认。这个机制让我们上线后的返工率控制在**9%**以内。

第三件事：把模板库当成资产来运营。 我们现在有63个企业级模板，每一个都来自实际跑通的场景。模板库不仅要沉淀，还要定期清理和版本升级。一个过期的模板，可能比没有模板更危险。

这三件事看起来都不”性感”，但它们决定了全域落地能不能稳得住。

八、给决策者的90天路线图：四个阶段与三个止损线#

如果你现在正准备从试点走向全域，我把我们的节奏整理成一张90天路线图，你可以直接拿去改。

Phase 1（第1—15天）：定标准，选单点。 选一个跨部门、有指标、可衡量的场景做唯一试点。这一阶段的验收标准不是”做出来了”，而是”业务自己做的”。

Phase 2（第16—45天）：做复制，测效率。 把这一个场景复制到4—6个类似场景，重点记录”每新增一个场景的耗时”。如果这个数字下不来，说明你的模板化和组件化没做好，别急着扩。

Phase 3（第46—75天）：搭治理，建目录。 上线应用目录、双Owner机制、发布前检查清单。这一步是最容易被跳过的一步，也是我们踩坑最多的一步。

Phase 4（第76—90天）：全域推进，滚动迭代。 按业务域分批推进，每两周做一次复盘，重点看三个指标：新增场景数、业务自助搭建占比、流程异常平均定位时长。

同时设三条止损线：

止损线一：业务自助搭建占比低于40%。 说明平台上手门槛还是太高，先停下来做培训或重新评估工具。 止损线二：单场景复制耗时超过3天。 说明复制机制没建好，继续铺开只会制造更多维护债。 止损线三：应用上线后30天内返工率超过20%。 说明质量管控缺位，必须补齐检查清单和Owner机制。

这三条线，我们内部叫”别硬撑”原则。试点可以慢，全域不能乱。

九、结语：由热转实的本质，是把能力交回到业务手里#

回头看这三年，我最大的感受是：AI和低代码真正产生价值的那一刻，不是某次演示赢得掌声，也不是某个报告里的排名，而是设备管理部的老周自己做出了一个应用，并且第二天就有人在用它干活。

行业由热转实，热的从来不是技术本身，而是期待；实的也不只是系统上线，而是能力转移。当业务同事不再需要排队等IT、当开发同事从重复劳动中脱身去做更难的事、当试点跑通后能顺理成章地走向全域落地——这时候，AI + 低代码才真正完成了它的使命。

如果你正卡在试点的第十个版本里反复打磨，我建议你先别急着优化功能，去问问一线用户：他们上一次自己动手做点什么，是什么时候？

答案会告诉你，你离”实”还有多远。

参考文献

[1] 中国信息通信研究院. 低代码与人工智能融合发展白皮书（2025年）[R]. 北京: 中国信息通信研究院, 2025.

[2] IDC. 2025年中国低代码开发平台市场跟踪报告[R]. 上海: IDC中国, 2025.

[3] Gartner. Forecast Analysis: Enterprise Low-Code Development Technologies, Worldwide[R]. Stamford: Gartner, 2024.

[4] 王坚, 李明. 企业级AI应用落地的组织路径与体验设计研究[J]. 软件学报, 2024, 35(8): 1123-1138.

[5] 陈晓东. 从试点到规模化: 企业数字化转型的”最后一公里”[M]. 北京: 电子工业出版社, 2024.