一、从一个真实困境说起：业务需求为什么总排不上研发的队#

2025 年 3 月，我在一家年营收约 12 亿元的制造企业做数字化调研。人力资源部的林主管打开一张 Excel 表格给我看，14 列，密密麻麻记录着员工的考勤异常申诉：迟到、忘打卡、外出未报备、加班调休——两年半下来，累计超过 6,800 条记录。

“这个流程我们手工跑了两年半，每个月大概 200 条。“她说，“前年我就提过需求，想做成系统，IT 说排期要等下个季度。”

结果这个”下个季度”一拖就是 26 个月。

这不是个例。现在的 AI 与低代码结合，让用自然语言搭建系统的门槛进一步降低，但在讲这个变化之前，有必要先把”旧世界”的困境说清楚，否则我们无法理解门槛降低到底省下了什么。

在我接触过的三十多家中型企业里，IT 部门的资源分配几乎都遵循同一条曲线：约 70%~80% 的研发精力被核心系统占据——ERP 改造、MES 对接、主数据治理、安全合规升级。剩下 20%~30% 的资源，要去承接数量上占绝对多数的”长尾需求”：一个审批流、一张巡检表、一套供应商打分卡、一个门店陈列检查清单。

某咨询机构 2024 年的调研数据印证了这一点：企业数字化需求中约 63% 属于长尾型需求，平均排队周期为 42 天，其中 18% 的需求最终因为”排不上队”而不了了之。

被放弃的需求不会消失，它会退化成 Excel、微信群和纸质单据。

林主管那 14 列 Excel 就是最好的证明。她告诉我，每个月因为填错、漏填、审批链路丢失导致的返工，大约要占用她 12 到 15 个小时。“我还得手动汇总给财务，每个月最后一周基本都在干这个。”

从用户体验的角度看，旧模式的痛点非常明确：

• 等待成本高：需求从提出到上线，中位数 42 天，长尾需求基本没有排期优先级。
• 沟通损耗大：业务说”我要一个能自动提醒的流程”，研发听到的是”需要定时任务 + 消息队列 + 权限模型”，中间要来回对齐三轮以上。
• 变更代价重：流程上线后改一个字，要重新走一遍需求、开发、测试流程，平均 5 个工作日。
• 责任真空：业务觉得是 IT 没做，IT 觉得是业务没说清楚。

这三个角色——业务、研发、管理层——各有各的委屈。而 AI 加持下的低代码，恰好在”表达”和”实现”之间，硬生生塞进了一层翻译器。

二、自然语言到底改变了什么：低代码门槛降低的三层表现#

要理解门槛降低，得先分清”低代码”这个概念本身经历的三个阶段。

第一代低代码（2015 年前后）解决的是”写代码”的问题。 它把增删改查、表单渲染、列表分页这些重复劳动封装成组件，开发者拖拽配置即可。但它仍然要求使用者理解数据模型、字段类型、主外键关联——本质上是”给程序员用的加速器”。

第二代低代码（2020 年前后）解决的是”搭积木”的问题。 可视化流程编排、API 连接器、权限矩阵配置逐渐成熟，产品经理和懂业务的 ITBP 开始能独立交付应用。门槛下降了一档，但仍然要求使用者具备结构化的系统思维。

第三代低代码（2024 年至今）解决的是”说人话”的问题。 大语言模型接入之后，平台可以理解自然语言描述的业务意图，并自动生成数据表结构、页面布局、流程节点和校验规则。使用者不需要先想清楚”这个字段是文本还是枚举”，只需要说”申请人、部门、异常日期、异常类型、说明、附件”。

从用户体验视角看，这一轮门槛降低具体体现在三个层次：

第一层：表达门槛。 过去要先把业务话术翻译成技术语言，现在可以直接说业务话术。我做过一个简单测试：让 8 位非技术岗位的同事（HR、行政、销售运营各若干）用同一段需求描述，分别尝试配置一个”差旅报销申请”表单。使用传统拖拽式低代码平台的 4 人，平均耗时 38 分钟，其中 3 人在”字段类型选择”和”关联关系设置”两个环节卡住超过 10 分钟；使用支持自然语言生成的平台的 4 人，平均耗时 9 分钟，无人求助。

第二层：配置门槛。 流程分支、条件校验、权限控制这些最容易出错的环节，现在可以用一句话描述。“金额超过 5000 元自动加签财务总监，超过 20000 元再加签总经理，同时抄送申请人直属上级”——这类规则过去要靠流程图连线加条件表达式，现在验收方式是”我说一遍，你看对不对”。

第三层：维护门槛。 这是最容易被忽视的一层。系统上线后的变更才是真正的成本黑洞。传统模式下，业务提变更 → 研发理解 → 排期 → 改动 → 回归测试，平均 5 个工作日。而自然语言低代码平台的用户可以直接定位到对应节点，用一句话描述改动，系统实时给出修改预览。

某行业研究机构的实测数据显示，在引入自然语言交互能力后，企业低代码平台的平均需求交付周期从 21.4 天缩短至 8.1 天，降幅约 62%；非技术用户首次独立完成应用搭建的比例从 27% 提升到 71%。

这里需要强调一点：门槛降低不等于能力降级。企业级低代码平台在底层依然保留完整的元数据模型、权限体系、审计日志和 API 开放能力，自然语言只是新增了一个更友好的入口，而不是把系统做浅了。

三、AI 加持下的搭建现场：一段对话生成一套审批系统#

理论说完，我们回到林主管的现场。

那天下午两点半，她坐在会议室，我让她把平时提需求的方式换成”对着系统说话”。她打开的是我们测试用的云枢低代码平台（后文简称”云枢”），在 AI 助手的输入框里敲下了第一句话：

“我要做一个考勤异常申诉流程。员工提交异常日期、异常类型（迟到/忘打卡/外出未报备/其他）、说明和证明附件，直属主管审批，超过 3 天未审批自动提醒，审批通过后同步给 HR 备案。”

平台的响应过程分三步，界面上都能看到：

1. 意图解析：系统识别出这是一个”表单 + 审批流”类型应用，自动命名”考勤异常申诉”。
2. 结构生成：生成 6 个字段——申请人（自动带出）、所属部门（自动带出）、异常日期（日期选择）、异常类型（下拉枚举，4 个选项）、异常说明（多行文本）、证明附件（图片/文件上传）。
3. 流程编排：生成”提交 → 直属主管审批 → 抄送 HR”三节点流程，并在审批节点上挂了”超时 72 小时自动提醒”的定时规则。

整个过程，从敲下第一句话到生成可预览的应用草稿，用时 3 分 12 秒。

林主管盯着屏幕看了十几秒，然后说了一句让我印象很深的话：“如果我两年前能看到这个，我就不用求 IT 了。”

当然，第一版草稿不可能完美。她随后做了三轮调整，全部用自然语言完成：

第一轮：她说”异常类型要加一个’哺乳假外出’，而且要放在第三个位置”。系统重新生成枚举列表，顺序调整完成，耗时 20 秒。

第二轮：她说”如果申请人职级是经理及以上，主管审批这一步跳过，直接进 HR。“系统提示是否需要定义”职级”字段的数据来源，她选择了从组织架构接口同步，配置完成，耗时 1 分 40 秒。

第三轮：她说”我要一个看板，能看到本月各部门的异常申诉数量和审批通过率。“系统生成了一个带两个图表的仪表盘页面，耗时 1 分 05 秒。

下午三点四十分，她把应用链接发给了主管和 HR 同事试用。从开始到交付，总计 1 小时 10 分钟。 这个流程，两年前 IT 给出的排期是 6 到 8 周。

第二天她给我发消息：有 3 个同事提交了申请，主管审批用了不到 1 分钟，“比在群里发消息还快”。

这个故事里有几个细节值得技术决策者注意：

• AI 生成的不是”能跑就行”的玩具。生成的数据结构、流程节点都以标准元数据形式存储，后续可以导出、可以通过 API 调用、可以做权限细化，和手工搭建的应用是完全等价的对象。
• 迭代是实时的。传统模式下，“改一下顺序”要走一次完整的排期；这里只需要一句话的往返。
• 业务人员不需要理解技术概念。林主管全程没有接触”字段类型""主键""表达式""节点条件”这些词，她说的每一个词都是她原本就会说的。

四、用户体验实测：从需求到上线的五个环节对比#

为了让”门槛降低”这件事更可量化，我组织了一次对照测试。

测试对象：同一家企业内 6 位非技术岗位员工（HR、行政、销售运营各 2 人），平均司龄 5.2 年，无编程背景。

测试任务：搭建一个”门店巡检记录”应用，包含巡检表填写、照片上传、异常项自动派单、区域经理复核、月度统计看板。

对照组：使用传统拖拽式低代码平台（可视化配置，无自然语言入口）。 实验组：使用支持自然语言生成的企业级低代码平台。

测试结果如下：

除了耗时，还有几个值得关注的差异：

求助次数：对照组平均每人主动求助 4.3 次（主要卡在”关联查询”和”条件表达式”），实验组平均 1.2 次（主要是确认权限范围）。

完成率：对照组 6 人中 4 人独立完成，2 人中途放弃；实验组 6 人全部独立完成。

主观评分（10 分制，“我愿意在日常工作中继续使用这套工具”）：对照组平均 6.1 分，实验组平均 8.7 分。

一周后的留存使用：对照组有 1 人继续维护了该应用，实验组有 5 人在一周内又各自搭建了至少 1 个新应用——包括一个”办公用品领用登记”和一个”客户拜访记录”。

这组数据背后，其实是一个心理学层面的变化：当试错成本足够低时，用户会从”想清楚再动手”变成”先动手再调整”。 传统低代码平台上，配错一个关联关系可能要花 15 分钟排查；自然语言模式下，说错一句话，重新说一遍只要 20 秒。门槛降低的本质，不是功能变多，而是失败变得便宜了。

五、门槛降低之后：谁在真正用低代码搭建系统#

门槛降低带来的直接影响，是使用人群结构的变化。

在我跟踪的 12 家企业客户样本中（制造业 5 家、零售连锁 3 家、专业服务 4 家，员工规模 300~5000 人），2023 年低代码平台的活跃搭建者构成大致是：IT 部门 82%，业务部门 15%，其他 3%。

到 2025 年上半年，这个结构变成了：

• 业务部门人员：47%（HR、行政、运营、销售支持、质量、EHS 等）
• IT 部门人员：38%（ITBP、应用运维、数据岗）
• 外部合作伙伴与一线管理者：15%

某咨询机构在 2025 年发布的调研中给出了相近的数字：在部署了自然语言交互能力的低代码平台上，业务侧用户贡献的应用数量占比达到 54%，而在未部署该能力的平台上，这一比例仅为 19%。

这个变化对不同角色的意义完全不同。

对业务人员来说，他们第一次拥有了”自己解决问题”的工具。林主管后来告诉我，她在两个月内又做了四个小应用：员工生日提醒、培训签到、工牌补办、宿舍报修。她说：“以前我觉得系统是 IT 的事，现在我觉得这是我的事，只是我换了个工具。”

对 IT 部门来说，这既是解放也是挑战。我访谈过的一位 IT 经理张工（某零售企业，门店 260 家）说得很直接：“以前我 80% 的时间在处理业务提的表格和小流程，现在这些不用我管了。但我多了两个新活儿：一是管住数据边界，别让业务把敏感字段随便放出去；二是做复用，把业务搭得好用的东西沉淀成模板。”

对技术决策者来说，最需要关注的其实是第三点——治理。当 47% 的搭建者是业务人员时，平台的价值不再取决于”能搭多少应用”，而是取决于”能不能在放开的同时管得住”。这也是后文选型清单里权重最高的部分。

一个值得注意的趋势是：用自然语言搭建系统并没有让 IT 部门边缘化，反而让它从”实施者”转向了”平台运营者”。张工的团队从 9 人缩减了对外支持工作量后，把 3 个人转成了”低代码平台运营”角色，负责模板库建设、权限审计和跨部门数据打通。他给这个转变打了 9.2/10 分：“这是我做 IT 十五年来，第一次觉得自己在做架构，而不是在做需求。“

六、企业级场景的冷静审视：哪些系统适合，哪些不适合#

门槛降低是好事，但作为技术决策者，你必须清楚它的边界。我在实际项目里见过太多”什么都要上低代码”的冲动，结果往往是返工。

根据 30 多个真实项目的复盘，我把场景分成三类。

第一类：非常适合，建议优先落地（约占长尾需求的 70%）

• 流程审批类：请假、报销、用章、合同评审、采购申请
• 数据采集类：巡检、点检、质检记录、客户拜访、门店陈列
• 台账管理类：资产、设备、证照、供应商、合同
• 轻量看板类：部门级 KPI、项目进度、销售漏斗
• 表单分发类：问卷、报名、信息收集

这类场景的共同特征是：数据结构相对简单（1030 个字段）、并发量低（日均几百到几千条）、流程节点少（38 个）、变更频率高。自然语言低代码在这类场景下的交付效率优势最明显，实测平均缩短 60%~75%。

第二类：可以做，但需要架构评估（约占 20%）

• 与核心系统（ERP/MES/CRM）有双向数据写入的应用
• 涉及跨部门数据权限矩阵的复杂应用
• 日均数据量在 10 万条以上的应用
• 需要与外部系统做实时接口调用的应用

这类场景不是不能做，而是要求平台必须具备完善的 API 网关、数据权限模型和性能监控。选型时要重点验证，不能让业务人员”先搭起来再说”。

第三类：不建议用低代码承载（约占 10%）

• 高并发交易类场景（如订单中心、支付）
• 强一致性要求的核心账务处理
• 复杂算法与大规模数据计算
• 需要满足特定行业强制认证的场景（部分金融、医疗核心系统）

我在一家制造业客户那里就见过一个反面案例：业务部门用低代码搭了一个”生产工单实时看板”，直接连了 MES 的数据库做实时查询，结果在月初盘点时把 MES 拖慢了，影响了产线。后来改成”低代码前端 + 数据中台中间层”，问题才解决。

这个案例的教训是：门槛降低的是搭建能力，不是架构判断力。 恰恰因为业务人员现在能自己动手了，IT 部门更需要提前把”什么能连、连到什么程度、数据往哪里落”这些边界定义清楚。企业级低代码平台的价值，一半在生成能力，一半在约束能力。

七、选型清单：技术决策者应该问的七个问题#

如果你正在评估 AI 加持下的低代码开发工具，下面这七个问题可以直接拿去问厂商。每一个都对应一个真实的踩坑场景。

问题一：自然语言生成的应用，和手工搭建的应用，底层对象是否完全等价？

为什么重要：有些平台的自然语言功能是”生成一段配置代码然后导入”，生成结果和手工搭建的结果在元数据层不是同一类对象，后续修改、迁移、导出都会受限。正确回答应该是：生成结果与手工创建的应用共享同一套元数据模型，可以互相编辑、可以导出。

问题二：AI 修改应用时，是否提供变更预览和回滚？

为什么重要：业务人员说错一句话的概率远高于程序员写错一行代码。如果没有预览和回滚，一次误操作可能破坏已上线流程。至少要支持”修改前对比 + 一键回滚到上一版本”。

问题三：数据权限模型是平台级的还是应用级的？

为什么重要：业务人员自建应用时最容易忽略权限。如果权限只能应用内配置，260 个门店就会产生 260 套权限规则，治理成本爆炸。正确做法是平台级统一身份与数据权限，应用继承。

问题四：是否支持与现有系统（ERP/HR/CRM）的标准连接器？

为什么重要：决定了应用能走多远。建议验证至少 3 个你实际在用的系统的连接器成熟度，而不是看厂商的清单长度。

问题五：AI 能力的调用边界在哪里？数据会不会出域？

为什么重要：涉及合规。要明确哪些请求走本地模型、哪些走云端、业务数据是否参与模型训练、日志留存多久。 对金融、医疗、制造业客户，这一条往往是否决项。

问题六：应用数量增长到 500 个以上时，平台如何管理？

为什么重要：门槛降低的直接后果就是应用数量爆炸。我见过一家企业两年内积累了 1,100 多个低代码应用，如果没有分类、标签、负责人、生命周期管理，很快就会变成”数字垃圾场”。要提前问清楚有没有应用目录、模板复用机制和下线流程。

问题七：业务人员搭的东西，IT 能不能接管？

为什么重要：这是治理的最后一道防线。当某个业务自建应用突然变成关键系统时，IT 必须能把它纳入正式运维体系。正确回答是：可以指定接管人、可以加入代码/配置审计、可以纳入统一监控。

这七个问题问下来，基本能筛掉大部分”演示好看、落地吃力”的产品。

八、落地路线图：从第一个应用到规模化复用的四步走#

选型之后是落地。基于 12 家企业的实践复盘，我总结出一条相对稳妥的四步路径。

第一步：选一个”低风险、高痛点”的试点（第 1~2 周）

不要一上来就搞全员培训。选一个部门级、流程简单、当前靠 Excel 维持的场景，比如考勤异常申诉、办公用品领用、会议室预定。判断标准有三条：流程节点不超过 5 个、涉及人数不超过 50 人、不写入核心系统数据。

这一阶段的目标不是产出多好的应用，而是让第一批用户建立”我能自己搞定”的信心。实测中，试点用户的首次独立完成率如果能达到 70% 以上，后续推广的成功率会显著提高。

第二步：建立模板库与边界规则（第 3~8 周）

试点跑通后，把其中可复用的部分沉淀成模板：审批流模板、巡检表模板、台账模板。同时，IT 部门要发布一份《低代码应用建设边界说明》，明确：

• 哪些数据源可以直连，哪些必须走中间层
• 哪些字段属于敏感数据，需要额外审批
• 哪些场景（如高并发查询）不建议使用平台
• 应用上线前需要经过哪些检查

这份说明不需要很长，两页纸足够，但它决定了后面能走多远。在我跟踪的样本中，发布了边界说明的企业，一年后低代码应用的平均返工率为 8.3%；未发布的企业，返工率高达 31%。

第三步：规模化推广与角色分工（第 3~6 个月）

这一阶段的关键是角色定义。建议明确三类角色：

• 业务搭建者：负责本部门应用的搭建与日常维护，接受基础培训
• 平台运营者（通常由 IT 承担）：负责模板库、权限审计、应用目录、跨部门数据打通
• 架构把关者：负责边界规则的制定与例外审批

我们跟踪的企业中，采用这种分工模式后，低代码平台的年度活跃搭建者数量平均增长 3.4 倍，而 IT 部门的支持工单量反而下降了 41%。

第四步：与 AI 能力持续对齐（持续）

大语言模型的能力还在快速迭代。建议每季度做一次复盘：哪些过去需要人工配置的环节，现在可以交给自然语言了？哪些 AI 生成的规则需要人工复核？ 保持这个节奏，平台的”门槛”会持续下降，而不是停留在某个固定水平。

九、结语：门槛降低不是终点，而是组织能力重构的起点#

回到林主管。上个月她给我发了一张截图：她所在的 HR 部门在企业低代码平台上已经有 9 个在跑的应用，累计处理了 4,700 多条业务记录。她说：“我现在提需求的方式变了，以前是写邮件给 IT，现在是直接说出来。”

这个变化看起来很轻，但它背后是三层重构：

第一层是工具层。 AI 加持下的低代码，用自然语言把”业务意图”和”系统实现”之间的距离压缩到了几乎为零，让搭建系统的门槛真正降到了普通业务人员可以跨过的水平。

第二层是协作层。 IT 从需求承接方变成了平台运营方，业务从提需求的人变成了做应用的人。这个转变会重新定义两个部门之间的价值交换方式。

第三层是组织层。 当一线的数字化需求可以在小时级被满足时，企业的数字化节奏就从”项目制”变成了”持续迭代制”。这对管理者的要求不是更低，而是更高——因为你需要判断的，不再是”这个需求排不排期”，而是”这个应用该不该存在、数据边界在哪里、谁来对它负责”。

所以，AI、低代码、自然语言三者的结合，带来的不只是搭建系统门槛的降低，它同时把治理能力推到了新的位置。工具的普惠和治理的收紧，必须同步发生，缺了任何一半，都会走向失控。

对技术决策者来说，现在的窗口期其实很清晰：尽早让业务人员用自然语言把第一个应用搭出来，同时尽早把边界规则写出来。 这两件事，越早做，复利越大。

参考文献

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

[2] Gartner. Magic Quadrant for Enterprise Low-Code Application Platforms[R]. Stamford: Gartner Inc. 2024.

[3] 王海涛, 李明. 大语言模型驱动的企业应用自动生成技术综述[J]. 软件学报, 2025, 36(4): 1587-1612.

[4] IDC 中国. 中国企业级低代码平台用户实践与ROI调研报告[R]. 北京: IDC 中国. 2025.

[5] 张倩. 自然语言交互在企业软件配置场景中的应用研究[D]. 杭州: 浙江大学. 2024.