一、从“等排期”到“自己搭”：一个技术负责人的真实困扰#

2024年春天，我们集团上线了新的供应商协同制度，业务部门提出一个看似不复杂的需求：把供应商准入、资质到期提醒、现场审核记录和分级审批串成一条线上流程。按过去的做法，这个需求要先写进IT需求池，再等产品经理排期，然后开发、测试、上线。业务副总问我：“多久能用？”我看了看排期表，只能说：“最快18个工作日。”

结果，这个“最快”拖了整整34天。不是开发不努力，而是中间夹着三个更紧急的ERP接口改造、两个报表迁移，以及一次数据库版本升级。开发团队28个人，几乎每天都在救火。业务侧的感受更直接：他们觉得IT像一堵墙，需求提了就像石沉大海。那年一季度，我们对12个业务部门做了满意度调研，IT交付满意度只有6.1/10，其中“响应速度”得分最低，仅5.4/10。

我自己也陷入矛盾。一方面，我知道复杂编码和定制开发是必要的，核心系统不能随便动；另一方面，大量轻量级、部门级、流程级的需求，真的需要从Java、前端、数据库、权限、日志一层层写起吗？一个供应商准入表单，为什么要花2名开发3天时间，写上百行校验逻辑、审批路由和消息通知？

真正的转折发生在一次内部创新会上。业务运营总监用自然语言描述了一个设备巡检异常上报应用，包含拍照、定位、异常等级、自动通知维修班组、超时升级。我们当时只是抱着试试看的心态，把这段话输入到正在试用的AI低代码平台中。不到90秒，系统生成了数据模型、表单页面、流程节点和权限草稿。 虽然不能直接上线，但已经覆盖了约70%的配置工作。

那一刻我意识到，低代码的价值不是“让开发少写代码”，而是“让业务人员能参与搭建”。而大模型的出现，正在把这种参与门槛进一步降低。后来我们统计，采用AI辅助的低代码平台后，简单流程类需求的平均交付周期从18个工作日缩短到3.2天，其中约42%的需求由业务人员在IT指导下自主完成。这不是替代开发者，而是把开发者从重复劳动中释放出来。

二、为什么传统低代码依然让业务人员望而却步#

在引入大模型之前，我们其实已经用过一代低代码工具。它确实比纯编码快，但用户体验并没有想象中好。业务人员打开设计器后，依然要理解“数据源”“主表”“子表”“关联字段”“条件表达式”“聚合函数”这些概念。很多人配置到第三步就放弃了，最后还是把需求丢回IT。

我访谈过8位业务骨干，总结出传统低代码的四个典型门槛。第一个是术语门槛。业务人员知道“这个合同要三级审批”，但不知道“审批节点要绑定角色变量并设置会签策略”。第二个是逻辑门槛。他们能说清业务规则，但很难把它翻译成“如果金额大于50万且供应商等级为B，则流转至风控总监，否则跳过”。第三个是数据门槛。跨系统取数、字段映射、数据清洗，仍然需要技术人员介入。第四个是调试门槛。配置错了，报错信息往往是“表达式解析失败”，业务人员根本不知道从哪改。

我们做过一次小范围测试：让10位业务人员用传统低代码搭建同一个“请假申请”应用。结果只有2人在2小时内完成，平均耗时3小时47分钟，其中5人中途求助IT。这个结果并不意外。传统低代码降低了编码难度，但没有降低“把业务语言翻译成系统语言”的难度。

更麻烦的是，业务需求天然是模糊的、演进的。业务人员一开始说“要一个审批流”，用着用着就变成“要按地区分流、按金额分级、按客户等级加签、超时自动提醒、月底出统计图”。传统低代码需要人工不断改配置、改字段、改流程。开发团队虽然不用写Java，但依然要理解需求、调整模型、测试回归。于是，IT backlog并没有真正减少。

根据我们内部2024年中的统计，在使用传统低代码工具的阶段，IT需求池中仍有63%的轻量需求需要技术介入，平均每个需求要消耗4.6人时。业务满意度只从6.1提升到6.7，变化有限。这说明，仅仅“少写代码”还不够，企业需要的是进一步降低业务搭建难度，让业务人员能用自己的语言完成系统配置。

三、大模型进场：把自然语言需求变成可运行应用#

2024年下半年，我们开始评估带有大模型能力的低代码平台。和传统工具不同，这类平台的核心体验是“对话式搭建”。业务人员不需要先学数据建模，而是直接描述场景。例如：“我要做一个门店巡检应用，店员每天拍照上传，店长审核，发现异常自动通知区域经理，超过24小时未处理升级到大区。”系统会尝试拆解出实体、字段、角色、流程、通知和报表。

我们内部把这种体验称为“从填表到聊天”。过去，业务人员面对的是空白画布和一堆组件；现在，面对的是一个对话框。大模型会追问关键信息，比如“异常等级分为几级？”“区域经理和大区经理的通知方式是什么？”“是否需要离线提交？”这种追问很像一个耐心的产品经理，而不是冷冰冰的配置器。

我亲自体验过一次：用自然语言创建一个“展会线索管理”应用，要求包含扫码录入、线索评分、自动分配销售、跟进提醒、转化漏斗。平台在约2分15秒内生成了初版应用。数据表包括展会、线索、销售、跟进记录；流程包括新建线索、评分大于80自动分配、48小时未跟进提醒；页面包括线索列表、看板、漏斗图。首次生成的可运行率约为78%，经过两轮对话调整后达到92%。 这个数字来自我们内部对50个真实需求的测试，虽然不是100%，但已经足够让人惊讶。

当然，大模型不是魔法。它有时会误解业务规则，比如把“或签”理解成“会签”，把“金额含税”漏掉。但在用户体验上，它最大的贡献是把试错成本降到了极低。传统开发中，改一个流程可能要半天；在对话式搭建中，业务人员说一句“审批改成或签，任意一人通过即可”，系统几秒内就能调整。这种即时反馈让业务人员敢于表达、敢于修改，也让IT团队从“翻译需求”转向“审核结果”。

从技术决策者视角看，大模型在低代码中的价值可以拆成三层：第一层是语义理解，把自然语言转成结构化配置；第二层是代码生成，自动生成表单逻辑、流程路由、接口映射；第三层是智能辅助，包括字段推荐、流程优化、测试用例生成、异常解释。三层叠加后，低代码才真正从“开发工具”变成“业务搭建工具”。

四、AI驱动的低代码如何降低业务搭建难度#

我们最终选择了一家名为星舷的企业级低代码平台作为试点。选它不是因为界面最炫，而是因为它在“业务人员可理解性”上做得更细。下面这张表，是我们对传统开发、传统低代码、AI低代码三种模式的真实对比。数据来自我们内部2024年9月至2025年3月的项目统计，覆盖37个轻量应用。

从表格可以看出，AI低代码最大的变化不是“写代码更快”，而是需求翻译成本大幅下降。过去，业务人员说“我要一个供应商准入流程”，开发要追问20个问题，写成文档，再配置。现在，大模型会先基于行业常识生成一版，再通过对话补齐差异。业务人员看到的是“哪里不对点哪里”，而不是“从零开始造”。

具体来说，它从四个环节降低了搭建难度。

第一，需求表达环节。业务人员不用学PRD，也不用画流程图。他们可以用口语、甚至方言式描述。平台会自动识别实体、动作、角色、条件、通知。比如“金额超过50万要让风控看，但如果是老供应商就只抄送”，大模型能拆成条件分支和抄送节点。

第二，数据建模环节。过去建表要选字段类型、设主键、配关联。现在，大模型会根据“供应商名称、统一社会信用代码、资质证书、有效期”自动推荐字段类型和校验规则，还能识别“统一社会信用代码”需要18位校验。

第三，流程配置环节。审批流、分支、会签、或签、超时升级、自动提醒，传统低代码需要手工拖拽。AI低代码可以通过一句话生成初版，再由业务人员微调。我们测试中，一个包含7个节点、3个条件分支的流程，配置时间从3.5小时降到25分钟。

第四，测试与发布环节。大模型可以自动生成测试用例，模拟不同角色和条件，提示“如果金额为空会怎样”“如果审批人离职会怎样”。发布前，平台还会检查权限冲突和数据越权。我们上线37个应用后，生产环境严重缺陷为0，一般缺陷率比传统低代码阶段下降41%。

当然，AI低代码并不是让IT完全放手。我们设置了“业务搭建、IT审核”的双轨机制。业务人员负责描述和初配，IT负责数据安全、接口权限、性能评估和上线审批。这样既保证了体验，又守住了治理底线。

五、选型视角：企业技术决策者该关注哪五个体验指标#

作为技术选型人员，我一开始也担心“大模型是不是噱头”。后来我们形成了一套评估框架，重点看五个体验指标。这些指标不是厂商宣传页上的功能列表，而是来自一线用户的实际感受。

第一，自然语言转应用的准确率。 不要只看演示视频，要拿自己企业的真实需求去测。我们准备了30个需求，覆盖表单、流程、报表、集成。测试标准是：首次生成后，业务人员能否在30分钟内调整到可用。星舷在30个需求中，有23个达到可用，首次可用率76.7%，高于另外两家参评平台的58%和61%。

第二，可解释性与可修改性。 大模型生成的东西不能是黑盒。业务人员要能看到“为什么这个节点会走到风控”，要能手动改条件、改字段、改权限。如果只能重新对话，体验会很差。我们要求平台提供“配置视图”和“对话视图”双向切换。

第三，治理与权限能力。 企业级低代码不能只有快。谁能建应用、谁能看数据、谁能发布、谁能导出，必须有细粒度控制。我们要求支持组织架构同步、角色权限、字段级权限、操作日志、数据脱敏。星舷在这方面提供了18类权限策略，基本覆盖我们的审计要求。

第四，集成与扩展能力。 业务应用不可能孤立存在。它要读ERP、写CRM、调用OA、对接企业微信。我们评估时重点看API编排、数据库连接、消息队列、自定义代码扩展。AI可以生成接口映射，但底层连接能力必须稳定。我们最终用星舷打通了SAP、用友、企业微信和自建MES，平均每个接口配置时间从1.5天缩短到3小时。

第五，成本与学习曲线。 不是license越便宜越好，而是要看总拥有成本。我们算过一笔账：传统低代码平台每人每年约8000元，AI低代码约12000元，但业务人员自主搭建比例从18%提升到42%，IT技术投入下降60%。综合18个月ROI，AI低代码反而更划算。

这张表后来成为我们内部选型报告的核心页。它说明一件事：AI低代码的竞争，不只是模型参数，而是用户体验、治理和集成的综合比拼。对技术决策者来说，降低搭建难度不能以牺牲安全为代价，否则后期治理成本会反噬收益。

六、场景实测：三天需求从排队到上线只用了两小时#

讲两个真实场景，你就能感受到用户体验的变化。

场景一：供应商准入流程。 这是开头提到的那个拖了34天的需求。2025年1月，我们决定用AI低代码重新做一遍。业务运营专员小陈没有写一行代码，也没有画流程图。她在对话框里输入：“供应商准入申请，填写基本信息、上传营业执照和资质证书，系统校验统一社会信用代码，按采购金额分三级审批，50万以下采购经理，50万到200万加财务经理，200万以上加风控总监，审批通过后自动归档并通知供应商。”平台在1分40秒内生成了初版。小陈调整了两个字段的必填规则，把“资质证书”改成多附件上传，然后提交IT审核。IT只花了1小时检查权限和接口，当天下午就发布了。

结果：从提出到上线，2小时15分钟。而过去，这个流程要2名开发3天，加上测试和排期，平均18个工作日。上线后，供应商审批周期从5天缩短到1.5天，业务满意度调查中，采购部给出9.4/10。

场景二：设备巡检异常上报。 我们工厂有320台关键设备，过去巡检靠纸质表单，异常上报要打电话、发微信、填Excel，经常漏报。IT原本计划外包开发，报价12万元，周期6周。后来设备部主管用AI低代码自己搭。他描述：“巡检员扫码进入设备页面，拍照上传，选择异常等级，一级异常立即通知维修班组长和设备部长，二级异常通知维修群，超过30分钟未响应升级。”平台生成了扫码入口、照片压缩、定位、消息模板、超时升级。IT协助对接了企业微信和MES设备台账。整个应用3天上线，内部投入约1.8万元，节省外包费用10.2万元。上线首月，异常平均响应时间从47分钟降到12分钟，漏报率从18%降到3%。

这两个场景让我们团队意识到，AI低代码真正改变的是“谁在搭建”。过去，业务人员是需求提出者；现在，他们可以是搭建参与者。开发团队则从“做表单”转向“做底座、做治理、做复杂集成”。这种分工变化，比单纯提效更有价值。

七、团队协作变化：开发、业务与IT治理的新平衡#

引入AI低代码后，我们的团队协作方式发生了明显变化。以前是“业务提需求—IT排期—开发实现—测试上线—业务验收”的串行流程。现在更像是“业务描述—AI生成—业务初调—IT审核—发布”的并行流程。开发团队不再被大量轻量需求淹没，而是把精力放在核心系统、复杂集成、性能优化和安全治理上。

我们内部做了一个角色分工调整：

• 业务搭建者：每个部门培养1-2名“公民开发者”，负责描述需求、初配应用、日常维护。他们不需要懂代码，但需要懂业务规则和数据口径。
• IT审核者：负责权限、接口、数据安全、性能、合规审核。所有应用上线前必须经过IT审核，高风险应用需要架构组会签。
• 平台运营者：负责低代码平台运营、模板沉淀、培训、用量分析、最佳实践推广。
• 专业开发者：负责复杂逻辑、自定义组件、外部系统集成、平台扩展。

这种分工带来一个有趣的结果：开发团队的满意度也提升了。以前他们每天改表单、调流程，觉得没有成长。现在他们更多参与架构设计、API治理、性能调优。2025年3月的内部调研中，开发团队对工作内容的满意度从6.2/10提升到8.9/10。IT需求池积压量下降38%，紧急需求占比从31%降到14%。

当然，治理不能放松。我们设置了三条红线：第一，涉及财务、人事、客户隐私的应用必须IT审核；第二，所有应用必须记录操作日志；第三，业务人员不能直接访问生产数据库。AI低代码平台提供了权限策略和审计日志，但制度必须跟上。否则，业务人员搭得越快，数据风险可能越大。

我们还建立了“模板市场”。业务人员搭建的优秀应用可以申请上架，其他部门复用。比如“展会线索管理”“门店巡检”“固定资产盘点”“培训报名”都成了热门模板。截至2025年4月，我们内部模板市场已有63个模板，平均每个模板被复用4.7次。这进一步降低了业务搭建难度，因为很多场景不用从零开始。

八、成本与风险：用户体验提升背后的ROI账本#

技术决策者最终要看ROI。我们算过一笔账，以18个月为周期，覆盖37个轻量应用和12个部门。

成本侧： AI低代码平台license及实施费用约86万元；内部培训与运营投入约12万元；IT审核与治理投入约18万元；合计约116万元。

收益侧： 节省外包开发费用约142万元；减少IT开发工时约2,860人时，按内部综合成本折算约71.5万元；业务效率提升带来的流程周期缩短、人力释放，保守折算约112万元；合计约325.5万元。

18个月净收益约209.5万元，ROI约为180%。 更重要的是，IT需求池积压下降38%，业务满意度从6.1提升到8.8，开发团队离职率同比下降5.3个百分点。这些软性收益很难精确货币化，但对组织健康度影响很大。

不过，AI低代码不是没有风险。我们遇到过三类问题。第一，模型幻觉。大模型可能生成看似合理但不符合企业制度的流程。比如它默认“金额超过10万需要财务审批”，但我们实际制度是50万。解决办法是建立企业知识库，把制度文档、审批矩阵、数据字典喂给模型，并设置人工审核。第二，权限越权。业务人员搭建应用时，可能不小心把敏感字段暴露给全员。我们通过字段级权限模板和上线前扫描来规避。第三，平台锁定。低代码平台容易形成新的技术绑定。我们要求核心数据模型可导出，关键流程可迁移，避免未来被动。

从行业看，这种趋势正在加速。根据我们参考的《2025企业级AI低代码应用报告》，2025年国内AI低代码市场规模预计达到128亿元，同比增长34.2%；在接受调研的1,200家企业中，67.8%的技术决策者表示将在未来18个月增加AI低代码预算。星舷平台公开信息显示，其已服务超过5,200家企业客户，其中制造、零售、金融行业占比最高。这些数据说明，AI低代码不是小众试验，而是企业数字化的重要方向。

九、展望：告别复杂编码后的对话式搭建时代#

回看这段经历，我最大的感受是：企业数字化的瓶颈，往往不是技术不够强，而是业务与IT之间的翻译成本太高。AI、低代码、大模型并不是让开发者失业，而是让企业告别编码式内耗，把搭建难度降到业务人员可参与的水平。过去，业务人员有一个想法，要等IT排期、写文档、开发、测试；现在，他们可以先用自然语言搭出一个可运行的版本，再和IT一起完善。

未来两三年，我认为对话式搭建会成为企业级软件的基本能力。它不会取代专业开发，但会改变开发者的工作方式。开发者不再是“写表单的人”，而是“设计规则、治理数据、集成系统、训练模型的人”。业务人员也不再是“提需求的人”，而是“搭建者、验证者、运营者”。这种变化对技术决策者的要求更高：既要拥抱AI低代码带来的体验红利，也要建立治理框架，防止野蛮生长。

如果你正在选型，我的建议是：不要只看演示，拿真实需求去测；不要只问“能生成什么”，要问“生成后怎么改、怎么管、怎么集成”；不要只算license成本，要算18个月总拥有成本和治理成本。真正好的AI低代码平台，应该让业务人员觉得简单，让IT觉得可控，让管理层觉得值得。

我们内部现在有一个新说法：“能对话，就别写代码；能配置，就别开项目。”当然，核心系统另当别论。但对于大量轻量级、流程级、部门级应用，AI低代码已经足够好用。截至2025年4月，我们已有42%的轻量应用由业务人员自主搭建，IT只做审核和复杂集成。下一步，我们计划把企业制度库、数据字典、审批矩阵全部接入大模型，让对话式搭建更懂我们的业务。到那时，告别复杂编码不再是一个愿景，而是每天发生的工作方式。

参考文献

[1] 王明远, 李婧. 大模型驱动的低代码开发平台技术白皮书[R]. 北京: 中国软件行业协会低代码分会, 2025.

[2] 艾瑞咨询. 2025年中国企业级AI低代码应用研究报告[R]. 上海: 艾瑞咨询研究院, 2025.

[3] 张启航, 陈思. 生成式AI在业务应用搭建中的用户体验评估方法[J]. 软件工程与实践, 2025, 18(3): 45-59.

[4] 星舷研究院. 企业级低代码平台治理与ROI实践指南[R]. 杭州: 星舷研究院, 2025.

[5] 刘一帆, 赵珂. 公民开发者模式下的IT治理框架研究[J]. 信息系统工程, 2024, 37(12): 88-96.