当业务需求可以直接对话 AI，低代码迎来应用生产新范式

一、一个真实的周一早晨：需求排期表上等着三周#

周一早上八点四十，我还没打开邮箱，生产部的王主管就站在了我工位旁边。他手里捏着一张打印出来的设备点检表，边角已经磨毛了。

“老张，这个表能不能做成手机上的？点检员现在填纸质表，下午我让人录进Excel，第二天才能看到异常。上周三号线的轴承温度异常，等我看到汇总表，已经停机两个小时了。”

我打开需求池看了一眼：47个待办需求，平均等待22个工作日。王主管这个需求，即便今天就立项，走完需求澄清、原型确认、开发、测试、上线，乐观估计也要到三周后。

这不是王主管一个人的困境。我统计过去年全年因信息传递延迟导致的生产异常闭环时间：从发现问题到责任人收到通知，平均4.7天；每月因设备异常处理滞后造成的非计划停机，约6.5小时。按我们产线的产值算，这6.5小时大约对应三十多万的直接损失。

而IT团队一共8个人，去年交付了23个应用。摊到每个人头上，一年不到3个。需求池却在以每月新增15个的速度膨胀。

坦白说，问题不在于我们不够努力，而在于整个应用生产的链条太长：业务方要用自然语言描述需求，我的人要把它翻译成需求文档，再翻译成数据模型，再翻译成页面和流程。每一次翻译，都有信息损耗；每一次损耗，都要靠开会来对齐。一个原本“一句话就能说清楚”的点检上报应用，硬是被拉成了三周的工程。

那天上午我做了一个决定：不走老路，用对话式的方式试一次。如果失败，大不了浪费一个上午；如果成功，我们可能找到了那个一直在等的新范式。

二、对话即开发：业务人员第一次“说”出一个应用#

我把王主管拉到了会议室，没有打开需求文档模板，而是打开了一个输入框。

我说：“你把刚才跟我说的话，原样打进去。”

他敲下了这段话：“我要一个设备点检应用，点检员每天扫码进入，按设备点位逐项打勾，异常项要拍照上传并填写说明，异常自动推送给设备主管，主管处理完要闭环，我要能看到每台设备最近30天的异常记录。”

大概二十几秒后，屏幕上出现了一个可运行的应用原型：设备台账表、点检任务表、点检明细表、异常流转表，四个数据表自动建好；扫码入口、逐项打勾的移动端表单、拍照上传控件、异常推送的审批流程、按设备维度聚合的看板，全部就位。

王主管愣了一下，然后自己动手改了两处：把“打勾”改成了“正常/异常/停机”三态选择，把异常推送的对象从设备主管改成了“设备主管+当班班组长”。整个过程他没问我一句“这个能不能做”。

从提出需求到可用原型，27分钟。

而在两个月前，同样一个应用，我们走的是这样的流程：

1. 需求澄清会（约0.5天）：业务方、IT、供应商三方对齐字段和流程；
2. 需求文档撰写与评审（约1.5天）：输出字段清单、流程说明、权限矩阵；
3. 原型设计（约2天）：画页面、确认交互；
4. 开发实现（约6天）：建表、写接口、配流程；
5. 测试与修正（约1.5天）：业务方验收，发现问题打回；
6. 部署上线（约0.2天）。

合计约15.9个工作日。而现在，这套流程里最耗时的三个环节——需求文档、原型设计、基础开发——被压缩成了一次对话。这不是把拖拉拽组件做得更顺手，而是把应用生产的起点，从“IT理解业务”前移到了“业务自己表达”。这正是对话AI给低代码带来的最本质的变化：它不再要求使用者先学会一套工具的语法，而是直接接受人类原本的语言。

三、交互变迁十年：低代码究竟在解决谁的痛#

回头看，企业应用的生产方式大致走了三段路，每一段都在修上一段的短板。

第一段是表单拖拽时代（大约2015—2019年）。 低代码平台把页面元素做成了可视化组件，拖一拖就能出表单。它解决的是“页面开发慢”的问题，但没解决“逻辑表达难”的问题。业务逻辑一旦超出配置项，就得写脚本。我们当时的实际情况是：拖拽5分钟，写脚本2小时。

第二段是模板加配置时代（大约2020—2023年）。 平台开始提供行业模板库，采购申请、报销、巡检这些常见场景开箱即用。它解决的是“从零搭建慢”的问题，但模板匹配度成了新瓶颈。业务方总说“我要的跟这个差不多，但差的那一点很关键”。差的那一点，又回到了定制开发。

第三段就是现在正在发生的对话式时代。 据行业报告显示，2025年国内低代码市场规模已突破148亿元，其中具备生成式AI能力的平台贡献了约三成的增量。这一次，被解决的是“需求翻译”这个最顽固的环节。

这三段路其实在回答同一个问题：企业里最懂业务的人，什么时候才能自己把应用做出来？ 前两段路，业务人员从旁观者变成了参与者，但真正的交付者仍然是IT。到了对话式这条路上，角色的天平第一次发生了实质性的倾斜。

我拿我们自己做过的一个对比：同样是“展会客户线索收集”这个需求，2023年我们用模板改了三天，最后还是因为“线索去重规则”这个逻辑写了脚本；2025年市场部同事自己在对话窗口里描述了五分钟，包括“同一手机号扫码只能提交一次，超过三次要标记为高意向”，系统直接生成了对应的校验规则。那天下午，这个应用就上线了。

从“IT替业务做”到“业务自己做、IT管规则”，这就是低代码在对话能力加持下完成的一次身份切换。

四、五款平台实测：对话式应用生产的体验差异#

说体验不能只说自己家的。今年三月，我们用同一个测试任务，在六款平台上做了一轮对照体验。

测试任务：用一段自然语言描述，生成“设备点检异常上报”应用，要求包含移动端表单、拍照上传、条件分支审批、按设备维度的统计看板，并支持一次多轮追问修改。

测试环境：统一由我们团队的两名业务人员（非开发背景）和一名IT工程师各操作一遍，取平均感受。

需要说明几点，避免误读：

第一，评分只代表我们这一个场景下的主观体验，不构成任何选型结论。 不同企业的场景差异极大，一家零售企业和一家装备制造企业的诉求完全不同。

第二，差距主要体现在“多轮追问”的能力上。 单轮生成的表现，六款平台差距不大；但当业务人员说“把审批人改成动态取值，根据设备所属车间自动带出对应主管”时，有的平台能理解并直接修改流程节点，有的则退回表单修改模式，需要人工重配。

第三，我们看到的一个明显趋势是，能力正在向“生成完整业务对象”靠拢。 以我们最终选用的 JNPF 为例，它在这个测试里做到的不只是生成一张表单，而是把数据表、权限、流程、看板作为一个整体一次性生成，后续修改也支持用自然语言描述。这对业务人员来说，体验差别是巨大的——因为他们脑子里想的是“一个完整的应用”，而不是“一张表单加一个流程”。

五、效率账本：从三周等待到两天上线省掉了什么#

体验归体验，决策还是要看账。我们统计了实施对话式应用生产前后各半年的数据，覆盖96个业务应用需求。

先看交付周期。 取“设备点检异常上报”这类中等复杂度应用为样本：

交付周期从15.9个工作日压缩到4.3个工作日，缩短约73%。部署环节略有上升，原因是应用发布频次变高了，原来一个月发一次，现在几乎每周都有，但单次发布本身已经全部自动化，额外的时间主要花在发布前的业务确认上。

再看产能。 同一个8人团队，年度交付应用数从23个增加到118个，增幅超过4倍。这里面有个关键变化：业务人员自助搭建的应用占比，从不足10%提升到54%。也就是说，IT团队承接的需求绝对值并没有暴涨，增加的部分被业务侧消化掉了。

第三看质量指标。 因为需求不再经过两次翻译，返工率明显下降。我们统计的“上线后一周内因需求理解偏差导致的修改工单”，从平均每个应用1.8个下降到0.6个，下降约67%。

这些数字与外部调研基本吻合。据某咨询机构2025年对312家企业的调研，采用对话式低代码能力后，简单业务应用的平均交付周期缩短61.8%，业务人员自助搭建比例从12%提升到49%。我们自身的提升幅度略高于这个均值，可能与我们前期做了较充分的数据字典和权限模型治理有关。

需要强调的是，省下来的不是“开发的工作量”，而是沟通与翻译的损耗。真正复杂的业务逻辑，该写的代码一行都没少。

六、IT团队的新位置：从接单者变成规则制定者#

业务能自己搭应用了，IT是不是就没事干了？恰恰相反，我们团队今年比去年更忙了，只是忙的内容完全变了。

过去我们是“接单—开发—交付”的流水线，现在我们把精力放在了四件事上：

一是建数据字典。 对话式生成的表结构好不好用，取决于平台是否理解你的业务术语。我们花了六周时间，把设备、工单、物料、客户这四类核心对象的字段标准整理出来，导入到平台的知识库里。之后业务人员说“设备编号”，生成的字段就和ERP里的编码规则完全一致，不用再人工对齐。以 JNPF 为例，它支持把企业自有的数据字典和字段规范作为生成时的约束条件，这一层配置是后期数据能打通的前提。

二是定权限模型。 谁可以看哪些数据、哪些操作需要审批、哪些字段可以做脱敏，这些规则必须由IT统一制定。我们做了一套“权限模板”，业务人员新建应用时默认继承模板，个别调整需要走审批。这一步把原来散落在各个应用里的安全隐患，收敛成了一套可管理的规则。

三是做集成规范。 业务自助搭建的应用，最大风险是与核心系统脱节。我们规定：任何涉及ERP、MES、财务系统的数据读写，必须通过统一的集成网关，不允许应用直连数据库。这条规则看似限制了自由度，实际上防止了后来的大麻烦。

四是建立发布门禁。 应用上线前要过三道关：数据权限校验、接口调用审计、性能压测。前两道自动跑，第三道只对高频应用执行。整个过程平均耗时从原来的1.5天降到2小时。

调整之后，我们团队的分工变成了：2人负责数据与集成治理，3人负责复杂应用开发，2人负责平台运维与培训，1人负责需求分级与调度。

有意思的是，业务部门对我们的满意度反而更高了。因为他们不再需要“等IT”，而是“在IT划定的跑道里自己跑”。一位车间主任跟我说过一句话，我记到现在：“以前我提需求，像在点菜，不知道后厨怎么做；现在我是在自己家厨房做，只是油盐酱醋是你们统一配的。”

这就是应用生产新范式下IT的新位置：不是交付者，而是规则的设计者和能力的供给者。

七、清醒一点：对话式应用生产目前还做不到什么#

如果这篇文章只讲好处，那它就没有价值。我必须把踩过的坑和仍然跨不过去的边界说清楚。

第一个边界：复杂业务逻辑仍然需要人工介入。 我们统计了那118个应用，对话式一次成型、业务人员独立完成的占62%，需要IT介入修改的占38%。需要介入的部分，集中在三类：多条件组合的业务规则、跨系统的数据一致性处理、有性能要求的批量运算。

举个具体例子：我们试过用对话方式做一个“多工厂协同排产”的应用。业务描述写了三轮，生成的原型框架没问题，但核心的排产算法——考虑设备产能、模具换型时间、交期优先级的综合寻优——对话式生成完全没有办法处理。最后这个需求还是回到了传统开发路径。

第二个边界：需求描述本身可能是模糊的。 对话式开发的前提是“你能说清楚”。但现实里，很多业务人员自己也说不清。我们遇到过一个需求：“我要一个能看出问题在哪的报表。”这句话无论给AI还是给人，都做不出来。这种情况下，平台生成的往往是一个看着完整、实际没用的东西，反而制造了“已经做了”的假象。需求澄清这一步，AI能帮你提速，但没法帮你完成。

第三个边界：合规与审计的适配。 在受监管的业务场景里（比如质量追溯、财务相关），AI生成的应用逻辑需要可解释、可审计。目前大部分平台只能做到记录修改日志，还做不到“说明为什么这样生成”。我们目前的处理方式是，这类场景一律走人工复核流程，不直接上线。

第四个边界：复杂审批流与组织架构的深度耦合。 当审批链涉及跨法人、代理关系、临时授权等场景时，对话式生成的流程节点往往只能覆盖主干路径，分支需要人工补全。

这些边界不意味着方向错了，而是提醒我们：对话式应用生产不是万能钥匙，它更适合“需求明确、逻辑中等、变动频繁”的长尾场景。 把这部分场景从IT手里解放出来，本身就是巨大的价值。至于复杂场景，该写代码还是得写代码。

八、选型清单与下一站：新范式会走向哪里#

如果你正准备在团队里引入对话式应用生产，我把我们踩过坑后总结的清单分享出来，一共七条：

1. 多轮追问能力优先。 单轮生成看Demo都很好看，真正决定体验的是能不能连续改三轮还不崩。
2. 数据和流程能不能一起生成。 只生成表单的平台，业务人员还得自己配流程，实际效率提升有限。
3. 企业知识库的导入能力。 能不能把你的字段规范、权限模板、组织架构喂进去，这是决定后期数据能否打通的关键。
4. 私有化与数据主权。 制造、金融类企业必须确认数据不出域，这一点在选型初期就要问清楚。
5. 生成结果的可解释性。 至少要能看到“为什么生成了这条规则”，否则后期排查问题会非常痛苦。
6. 与现有系统的集成方式。 有没有标准化的集成网关，比支持多少个接口更重要。
7. 业务侧的学习成本。 我建议的做法是，让三个不同部门的业务人员各试用半天，看他们能不能独立完成一个真实需求。

至于下一站，我的判断是：对话式应用生产不会止步于“生成应用”，而会走向“应用自己会干活”。 现在是我们描述需求、生成应用、人来使用；下一步会是应用里嵌入智能体，能自己读取数据、判断异常、发起流程。到那个时候，低代码平台的角色会从“生产工具的工厂”变成“业务能力的运行时”。

对我们这些技术决策者来说，需要提前想清楚的问题不是“要不要用”，而是“规则由谁定、边界画在哪、数据怎么管”。工具会越来越聪明，但治理责任永远在人身上。

回头看王主管那个点检应用，它现在已经跑了五个多月，累计上报异常1,347条，平均闭环时间从4.7天降到了6.2小时。上个月他见到我，第一句话从“能不能做”变成了“我又做了一个”。

我想，这就是应用生产新范式最朴素的样子：不是技术多炫，而是让懂业务的人，终于能把脑子里那张表，第一时间变成手里能用的东西。

参考文献

[1] 中国信息通信研究院. 低代码与无代码开发平台发展白皮书[R]. 北京: 中国信息通信研究院, 2025.

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

[3] 王建国, 李思远. 生成式人工智能驱动的企业应用开发范式演进研究[J]. 计算机应用与软件, 2025, 42(3): 118-127.

[4] IDC. 中国企业级低代码平台市场跟踪报告（2025年上半年）[R]. 北京: IDC中国, 2025.

[5] 张明. 对话式交互在企业软件中的用户体验度量方法[M]. 北京: 电子工业出版社, 2024.