一、从一个“等排期”的业务需求说起：被拖慢的数字化现场#

2024 年下半年，我们做了一次内部需求盘点，结果有点刺眼：IT 部门手上积压了 47 个待开发需求，平均等待时间 18 个工作日，最久的一个供应商管理需求排了 6 周还没开工。

而提出需求的人，等不了 6 周。

供应链的李姐是典型例子。她负责供应商准入，流程是：业务员填纸质表 → 主管签字 → 质量部现场审核 → 采购总监审批 → 归档。这套流程跑在微信、Excel 和打印机的组合上，一份单据平均要流转 5.5 天，月底对账还经常找不到签字页。她找我们提需求，我们给出的答复是“排队，预计三周后启动”。

三周后，她的业务节奏已经变了——新增了两类供应商，审核表单要改，流程节点要加人。等我们把第一版做出来，需求又变了。

这不是我们团队不努力，而是传统开发模式的结构性问题：

• 需求翻译损耗大：业务人员说的是“审核要能看到上次的整改记录”，开发听到的是“加一个关联查询字段”，中间隔着一层又一层的确认。
• 变更成本高：一个字段的调整，可能牵动表单、流程、报表三处改动，改一次要重新测试、重新发版。
• 长尾需求挤不进去：真正吃掉 IT 产能的，往往不是核心系统，而是大量“只有三个人用、但每天都在用”的小流程。

据某咨询机构 2025 年对 320 家中大型企业的调研，68.4% 的业务部门需求等待周期超过两周，其中近三成需求在等待期间发生了范围变更。换句话说，排期本身就在制造返工。

那段时间我一直在想一个问题：这些需求里，有多少真的需要“写代码”？如果业务人员能自己把表单、流程、权限搭出来，IT 只负责把关数据和集成，会不会是另一条路？

这个念头，成了后来所有事情的起点。

二、业务人员的真实困境：不是不懂业务，是缺少趁手的工具#

我们公司有一批“表哥表姐”——Excel 用得出神入化，VLOOKUP、数据透视表、条件格式信手拈来。他们对业务规则的理解，比任何一位开发都深。

但当我建议他们“自己搭个系统”时，得到的反馈几乎一致：“我连数据库是什么都不知道，怎么搭？”

这才是问题的核心。业务人员不缺业务理解，也不缺动手意愿，缺的是一个不需要先学编程语言、再学框架、再学部署的入口。传统开发的门槛是陡峭的：环境配置、语法、调试、上线，每一关都在筛人。

我们做过一次内部问卷，72.4% 的业务骨干表示“愿意自己搭建日常使用的工具”，但真正尝试过的只有 18%，放弃的原因排前三的是：不知道从哪开始（54%）、担心做错影响生产数据（41%）、学不会技术语言（37%）。

低代码最初进入我们视野时，解决的是第一层问题：把“写代码”变成“拖拽配置”。表单拖一个输入框，流程连一条线，权限勾几个选项。业务人员看得懂界面，也就敢动手。

但它只解决了大约一半。真正动手时，李姐卡在了第三个节点——她想实现“质量审核不通过则自动退回并抄送采购总监，同时生成整改任务”。拖拽界面里，这需要理解条件分支、抄送规则、子流程触发，她试了四十分钟，最后还是在群里问我：“这个‘并行网关’是什么意思？”

低代码降低了“写”的门槛，却没有降低“想清楚怎么表达”的门槛。直到 AI 出现，这一层才被真正打通。

三、AI 加入之后，低代码到底发生了哪些变化#

我把 AI 对低代码的改变归为三类，这三类恰好对应业务人员动手时的三个卡点。

第一类：从“拖拽”到“说出来”。

以前搭一个应用，第一步是设计表结构，业务人员最怕这一步。现在可以直接输入一句话：“做一个供应商准入申请，包含基本信息、资质附件、质量评分三部分，评分低于 80 分需要采购总监审批。”系统会在几十秒内生成表单初稿、字段类型和基础校验规则。我实测过一次，同样的表单，手工拖拽用了 38 分钟，自然语言生成初稿只用了 50 秒左右，剩下的时间全部花在业务细节微调上——而这部分恰恰是业务人员最擅长的。

第二类：把“技术语言”翻译成“业务语言”。

前面李姐卡住的并行网关问题，她后来直接把诉求写在对话框里：“质量审核不通过，退回申请人并抄送采购总监，同时给质量部生成一条整改任务。”系统给出了流程改法，还标出了需要她确认的两个分支条件。她说了一句让我印象很深的话：“它说的是人话。”

第三类：上线之后的“运维平权”。

应用做完只是开始。以前改一个下拉选项、加一个统计口径，都要提工单。现在业务人员可以自己调整字段、自己拉报表，甚至用自然语言问“上个月哪几家供应商的平均审核时长超过 3 天”，系统直接出结果。

据 Gartner 在 2025 年发布的相关观察，到 2026 年，超过一半的新建企业应用将来自低代码或零代码平台，其中相当一部分由业务侧人员主导。这个判断放在两年前我会觉得激进，现在我觉得保守了。

四、实测记录：一位业务人员两天半搭出一套审批应用#

这一节我把李姐的完整过程记录出来，因为它比我讲任何道理都有说服力。

第 0 天下午：梳理需求（1.5 小时）。 我们没有让她直接上手，而是先用一张纸把流程画清楚：谁发起、谁审核、什么条件下走哪条分支、异常怎么处理。这一步不能省，AI 能帮你实现，但替代不了你想清楚。

第 1 天上午：生成应用骨架（2 小时）。 她用自然语言描述表单和流程，系统生成了初稿。中间有两次调整：一次是资质附件的分类，一次是评分项的权重。整个过程她没有写一行代码。

第 1 天下午：配置权限与规则（2.5 小时）。 这部分她卡了一次，卡在“不同事业部的采购负责人只能看到本部门单据”。这类数据权限以前必须找开发，现在通过角色 + 组织架构的配置组合完成了。我们团队只做了一次远程确认。

第 2 天：移动端适配与试运行（3 小时）。 我们集团大量审批在手机上完成，这一步必须验证。她在手机上走了一遍完整流程，发现附件上传在弱网下会失败，调整了文件大小限制。

第 2.5 天：上线，接入统一身份认证。 这一步由我们 IT 完成，因为涉及 SSO 和组织架构同步，属于必须由技术侧把关的部分。

结果对比很清楚：

我们团队在选型阶段对比过几套方案，最终给李姐开通的是 JNPF 的账号。原因不复杂：它支持私有化部署，能和我们现有的组织架构、单点登录打通，表单、流程、报表、移动端是一套体系，业务人员不用在四五个工具之间跳转。对 IT 来说，能私有化部署、能导出标准代码这两点，意味着我们不会被平台锁死。

五、三条路径对比：传统开发、纯低代码、AI 加低代码#

很多同行问我：“AI 加低代码，和原来的低代码到底差在哪？”我把三条路径放在一起比，会更清楚。

从我们的实际数据看，上线一年后：IT 需求积压从 47 项降到 9 项，业务侧自助搭建的应用有 31 个，覆盖供应商管理、费用报销、设备点检、门店巡检等场景；IT 团队在需求交付上的人力投入下降约 35%，但需求吞吐量反而提升了 2.3 倍。

需要说明的是，市面上主流平台各有侧重，选型时不能只看宣传页。我的观察是：明道云在业务应用搭建的易用性上口碑不错，适合从零起步的团队；简道云在表单和数据收集场景上手快，中小企业接受度高；轻流在流程自动化方面做得比较细；钉钉宜搭的优势是与钉钉生态天然融合，适合已经把办公协同放在钉钉上的组织；织信在复杂业务模型和数据关系处理上有自己的路子；用友 YonBuilder 更适合已经在用友体系内、需要与 ERP 深度打通的企业；泛微则在 OA 与流程场景中有长期积累。JNPF 的特点在于私有化部署、多端一体和代码可导出的组合，比较契合我们对数据自主可控的要求。

选型没有标准答案，但有一条原则：先想清楚你要让谁来做开发，再去选平台。如果目标使用者是业务人员，易用性和 AI 辅助能力就是第一优先级；如果目标是 IT 提效，那集成能力和扩展性更重要。

六、技术决策者视角：这不是玩具，而是架构里的新选项#

作为技术负责人，我最担心的从来不是“业务人员能不能搭出来”，而是“搭出来之后怎么办”。

第一年上线后，我们内部平台上有 31 个业务应用。如果没有治理，这 31 个应用很快就会变成 31 个孤岛、31 套口径、31 份没人维护的数据。所以我们做了三件事：

一是把平台当成基础设施，而不是工具。 我们要求所有自助搭建的应用必须通过统一身份认证，必须使用标准组织架构，涉及客户和供应商主数据的字段必须从主数据接口取，不允许自行维护一套。这一步把“影子 IT”变成了“受控的自助开发”。

二是明确边界。 我们把场景分成三类：一类是核心交易系统（ERP、MES），继续走传统开发；二类是部门级流程和数据应用，允许业务人员自助搭建；三类是跨系统集成和对外接口，必须由 IT 承接。边界清楚，双方都不越界。

三是保留技术兜底能力。 这一点在选型时权重很高。业务应用做大了，迟早会遇到平台能力边界，这时候能不能导出标准代码、能不能通过 API 与外部系统对接、能不能私有化部署，决定了你是被平台绑住还是能继续演进。JNPF 在这方面的表现，是我们把它留在架构里的重要原因之一。

另外一个容易被忽略的收益是数据资产的正规化。以前散落在各人电脑里的 Excel，现在变成了平台上的结构化数据。上线一年，我们新增了 14 个可复用的数据模型，报表口径统一后，月度经营分析会的准备时间从 2 天缩短到 4 小时。

从架构角度看，AI 加低代码不是要替代专业开发，而是在“通用软件买不到、定制开发排不上”的中间地带，补上了一块长期空缺的能力。它把 IT 的定位从“开发工厂”推向“平台运营方和架构守门人”，这可能是更深远的变化。

七、落地避坑指南：企业引入 AI 低代码的五个关键动作#

我们踩过坑，也见过同行踩坑。这五条是我认为最值得优先做的。

第一，选对第一批场景。 判断标准三条：高频（每天都在用）、规则清晰（能画得出流程）、跨部门（能体现协同价值）。我们第一批选了 5 个场景，其中 3 个成功推广，2 个失败。失败原因很一致：业务流程本身还在频繁变动，规则没定下来，搭出来的东西一周就作废了。不要用低代码去固化一个还没想清楚的流程。

第二，培养“业务开发者”，而不是培训“工具使用”。 我们第一批培养了 12 位业务骨干，给他们一个正式的身份（内部叫“流程数字化专员”）和明确的激励。培训内容里，工具操作只占 40%，剩下 60% 是流程梳理、数据规范和权限意识。这套机制比发账号重要得多。

第三，先立规矩，再放开手。 命名规范、权限申请流程、数据字段标准、应用上线前的检查清单，这四样必须在开放前定好。我们的经验是：治理规则前置的成本，远低于事后收拾的成本。

第四，IT 不做甩手掌柜。 业务人员负责“搭”，IT 负责“接”和“守”：接入统一认证、打通主数据、审核敏感权限、做性能和安全评估。我们设了一个“平台运营岗”，一个人对接全部业务开发者，效率比想象中高。

第五，对 AI 生成的结果保留人工确认。 这是我在内部反复强调的一条。AI 能快速给出表单结构、流程分支、统计口径，但它不了解你们公司三年前定下的那条例外规则。我们的做法是：AI 出初稿，业务人员逐条确认，IT 做上线前复核。三道关，一道都不能少。

顺带说一句，工具选型时容易被忽略的是长期维护成本。据 IDC 在 2025 年的相关统计，中国低代码与零代码市场规模已接近 130 亿元，年复合增长率保持在 25% 以上，平台数量快速增长的同时，也意味着未来会有平台退出市场。选一个能私有化部署、数据能完整导出的方案，本质上是在为三五年后的自己留退路。

八、回到价值本身：让业务人员站上数字化的一线#

写到这里，我想回到最初那个走廊里的问题：“我们的需求什么时候能排上？”

现在李姐已经很少问我这句话了。她自己维护着三个应用，最近还在帮质量部搭设备点检的移动端表单。上个月的数字化例会上，她说了句让我印象很深的话：“以前我觉得系统是 IT 给的，现在我觉得系统是我们自己长出来的。”

这句话背后是几个实打实的数字：业务需求平均交付周期从 18 个工作日缩短到 4.8 天，IT 需求积压从 47 项降到 9 项，业务侧自助应用 31 个，单据平均流转时长下降 六成以上。但比数字更重要的是角色的变化——业务人员从“提需求的人”变成了“解决问题的人”，IT 从“接单的人”变成了“搭台的人”。

我并不认为 AI 加低代码能解决企业数字化的所有问题。核心系统、复杂算法、高并发交易，该写代码还得写代码。但在那些“买不到合适软件、又不值得排期开发”的大量中间地带，低代码加上AI，确实打开了一扇以前关着的门。它让业务人员第一次真正拥有了开发的能力，也让技术团队把精力还给了更值得投入的地方。

如果你正在为需求积压发愁，我的建议是：别急着全面推广，先挑一个业务同事天天抱怨的小流程，给他一个账号、一次两小时的辅导，让他自己搭出来。两周后你会看到答案。这大概是我这两年见过的，性价比最高的一次数字化投入——也是我最愿意推荐给同行的一件宝藏。

参考文献

[1] 艾瑞咨询. 2025 年中国低代码与零代码行业研究报告[R]. 上海: 艾瑞咨询, 2025.

[2] Gartner. Forecast Analysis: Low-Code Development Technologies, Worldwide[R]. Stamford: Gartner Research, 2025.

[3] IDC. 中国低代码与零代码软件市场跟踪报告（2025 年上半年）[R]. 北京: IDC 中国, 2025.

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

[5] 王建国, 李明轩. 公民开发者模式下的企业应用治理框架研究[J]. 信息化建设, 2025(6): 45-52.