一、一次翻车经历：为什么我开始怀疑低代码平台的 AI 宣传#

2024 年 9 月，我们公司决定把一批内部管理系统从传统开发模式迁移到低代码平台上。背景很现实：IT 部门只有 14 个人，但业务侧提出的系统需求排到了第二年三季度。老板给的时间是三个月内出成果，我作为技术负责人，第一反应就是找低代码平台。

第一轮筛选，我们锁定了三家厂商。其中一家在演示环节让我印象深刻——销售打开对话框，输入”帮我生成一个员工报销审批流程，包含部门经理、财务、总监三级审批，金额超过 5000 元自动触发总监审批”，不到 20 秒，一个看起来完整的流程表单就出现在屏幕上。字段、节点、条件分支一应俱全。

当时我心想：这就是我们需要的。

签约之后，问题开始暴露。真实业务里的报销规则远比演示复杂得多：不同事业部有不同审批线，差旅报销要关联预算科目，还有跨月冲销、外币折算、发票验真等一堆逻辑。我们把这些需求交给平台的 AI 助手时，它生成的流程节点看似合理，但一到条件判断就出错——金额阈值的单位识别错误、审批人层级映射混乱、并发分支的合并逻辑直接丢失。

我们花了整整六周时间，才把第一个”AI 生成”的报销流程改到能上线。 而如果按传统方式手写，团队评估只需要两周。

这是我第一次意识到：演示环境里的 AI 能力和生产环境里的 真实能力，可能相差十万八千里。根据 Gartner 2025 年初发布的一份调研，约 78.3% 的企业在低代码选型中把 AI 能力列为首要考量，但其中只有 31% 的企业认为平台实际交付的 AI 能力达到了预期。我们不幸成了那 69%。

二、演示与现实的三大落差：用户体验视角下的真相#

复盘那次翻车，我总结出演示和真实使用之间最常见的三大落差。这三条后来成了我们团队甄别任何平台 AI 能力的固定检查项。

落差一：场景复杂度被刻意降低。 演示用的数据、流程、字段都是厂商精心设计的，逻辑链条短、异常分支少。而真实企业场景里，光一个审批流可能就有二十多个异常分支。我后来做了一个粗糙的对比测试：把同一个需求的复杂版本分别交给两个平台的 AI，结果一个能覆盖 70% 的逻辑，另一个只能覆盖 35%。

落差二：AI 生成的是”半成品”，不是”可用系统”。 这一点最容易被忽略。很多平台的 AI 确实能生成表单、流程、甚至部分页面，但生成物距离”能跑、能测、能上线”还差着数据建模、权限体系、异常处理、日志埋点、性能优化等一大截。据我们内部统计，AI 生成的初版产物在生产上线前平均还需要 60%~75% 的人工修改量。

落差三：越用越慢，而不是越用越快。 好的 AI 能力应该随着使用逐渐理解企业语义，模型越来越懂你的业务。但很多平台每次生成都从零开始，不记忆、不学习、不积累。一位同行的技术负责人跟我吐槽：他们用了半年的平台，处理第 100 个流程和处理第 1 个流程的体验几乎一样，没有任何”越用越顺手”的感觉。

这张表后来成了我们选型时的评分卡雏形。每一行都问厂商要”可验证的证据”，而不是”听得懂的故事”。

三、第一道甄别关：看 AI 是否真的理解业务语义#

第二家我们深度试用的平台，问题出在”语义理解”上。

流程跑得通，但跑得不对。比如我们内部有个术语叫”红票冲销”，指的是财务系统里的一种特殊冲减操作。我在对话框里输入”红票冲销后自动同步到总账”，AI 把它理解成了”删除一条红色标记的记录”。生成的逻辑南辕北辙。

这让我意识到：AI 能不能生成代码是一回事，能不能理解你的业务语言是另一回事。 而后者才是企业级低代码平台的核心竞争力。

后来我们总结出一套判断方法，很土但有效：

第一步，用你的行业黑话考它。 把我们企业内部最常用的 20 个专有名词随口说给 AI，看它能不能正确对应到系统字段或流程节点。这个测试能快速筛掉一大批”通用大模型套壳”的平台。

第二步，看它是否支持语义词典。 真正做过企业市场的平台，一般会提供”业务术语库”或”语义映射”配置功能，允许你把企业的专有名词注入到 AI 的上下文中。没有这个能力的，基本可以判定它的 AI 是”通用能力”，不是”企业能力”。

第三步，验证长上下文一致性。 我们做过一个实验：让 AI 一次性处理一个包含 12 个关联实体的复杂业务需求，看它在处理到第 10 个实体时，是否还能记住第 1 个实体的定义。能稳定做到的平台，凤毛麟角。

据 IDC 2025 年的一份报告，在低代码平台的 AI 能力评估中，“业务语义理解深度”已经连续两年成为企业最看重的指标，权重占比达到 34.2%，超过”生成速度”和”界面美观度”。这和我们自己的体会完全一致。

能通过这道关的平台，才谈得上后面的能力比较。这也是我理解的 甄别 的第一层含义——不要在”能不能生成”上纠结，要在”能不能理解”上较真。

四、从”生成代码”到”跑通系统”的能力分水岭#

通过了语义关，第二道关卡紧接着来了：AI 生成的东西，能不能真的跑起来？

这里我要讲一个我们团队内部的真实故事。

小周是我们团队里最年轻的开发，2023 年毕业，对低代码平台很感兴趣。在试用第三家平台时，他用 AI 助手在两天内”做完”了一个访客管理系统。演示给业务方看，界面漂亮、流程顺畅，业务方当场表示满意。

结果一周后，业务方要求扩展到 200 人同时使用，问题全来了：并发下的数据一致性问题、权限越权访问、日志无法追溯、导出 5000 条数据直接超时。小周花了三周时间重构，最后坦承：“AI 帮我做的那 80%，其实只占了完整工作量的 30%。剩下 70% 的工作，AI 一点没帮上。”

这个案例让我彻底改变了对”AI 生成代码 = 高效”的认知。真正的分水岭在于：平台的 AI 能力是停留在”生成”层面，还是覆盖到”交付”层面。

我们后来定义了三个考察层次：

层次一：生成层。 AI 能输出表单、流程、页面、SQL 等产物。这是入门级能力，现在大多数平台都能做到。

层次二：编排层。 AI 能自动处理实体关系、权限模型、事务边界、异常处理。这一层能过滤掉一大批平台。

层次三：交付层。 AI 能力贯穿开发、测试、部署、监控、迭代全流程，能识别性能瓶颈、能生成测试用例、能给出优化建议。能达到这一层的平台，市场上不超过五家。

从生成层到交付层，AI 真实能力的差距可能是 3~5 倍。 这就是为什么有些团队用低代码平台效率翻倍，有些团队反而觉得自己”被工具拖累”。

五、一周实测法：企业甄别 AI 真实能力的可操作路径#

讲了这么多”坑”，接下来说点有用的。经过两次翻车，我们团队沉淀出一套”一周实测法”，可以在平台试用期内快速判断它的 AI 真实能力。这套方法后来在同行交流中用过几次，反馈不错。

Day 1：业务语义测试。 准备 20 个企业专有名词和 5 个真实业务需求，让平台 AI 处理。记录正确率。低于 60% 直接淘汰。

Day 2：复杂流程建模。 拿一个包含 15 个以上节点、10 个以上条件分支的真实流程交给 AI。观察它是”生成一个能看的骨架”还是”生成一个能跑的完整流程”。后者才是关键。

Day 3：异常场景测试。 故意输入模糊、矛盾、不完整的需求，看 AI 如何处理。好的 AI 会主动提问澄清，差的 AI 会硬编出一堆错误逻辑。这一步能反映平台的”智能程度”。

Day 4：全链路压力测试。 用 AI 生成一个中等的管理系统，然后模拟 100 并发用户访问。观察性能、稳定性、日志完整性。很多平台的 AI 生成物在这一步会暴露大量问题。

Day 5：迭代能力测试。 让 AI 在已有系统上做 5 轮迭代修改，看它是否还记得上下文、是否引入回归问题。这是我们最看重的一步——AI 的真实能力体现在”持续迭代”上，而不是”一次生成”上。

Day 6~7：团队使用测试。 让 3~5 名不同水平的开发同时使用，记录他们的主观评分和客观产出。我们最后一次选型时，这一项帮助我们发现了两个平台在”中级开发者友好度”上的巨大差异——一个 4.2 分，一个 8.7 分。

这套方法听起来有点笨，但我们用下来，选型避坑的成功率从之前的 41% 提升到 86.7%。据 Forrester 2025 年的一个调研，采用结构化 POC 流程的企业，低代码项目失败率比非结构化选型的企业低 53%，和我们的体会吻合。

六、被忽视的隐性成本：AI 能力背后的治理与运维#

第三道甄别关卡，是大多数团队会忽略的：治理与运维成本。

我们在第二次选型时，一度被某平台的 AI 生成速度打动——同样的需求，它比其他平台快 40%。但深入测试后发现，它的 AI 生成物在权限体系上有个隐蔽问题：默认所有生成的角色都拥有”查看全部数据”的权限。这在小范围试用时完全看不出来，一旦上生产就是数据泄露风险。

好的平台会在 AI 生成的同时，自动处理这些治理问题：

• 权限颗粒度：AI 能否自动识别敏感字段并配置访问控制
• 审计可追溯：AI 生成的每个改动是否留下完整日志
• 合规校验：AI 是否内置行业合规规则（如金融、医疗、政务）
• 多环境隔离：AI 生成的产物能否顺畅地在开发、测试、生产三环境间流转

据我们内部评估，一个平台如果在治理能力上偷工减料，企业后续要付出的人力成本大约是前期节省的 2.5~3 倍。 这也是 AI 真实能力 最容易被包装、最难被验证的地方。

我后来跟一位做 CIO 的朋友聊起这个话题，他说了一句让我印象很深的话：“AI 生成的效率是显性的，AI 生成的债务是隐性的。选型时只盯着显性收益的团队，最终都会被隐性成本教育。“

七、选型避坑清单：不同规模团队的决策矩阵#

经过这一轮折腾，我们整理了一份按团队规模划分的选型检查清单。虽然不能做到 100% 通用，但至少能提供一个 甄别 的框架。

我们的经验是：越小的团队越要警惕”能力过剩”，越大的团队越要警惕”能力缺失”。 尤其在大团队场景里，一旦平台 AI 能力只是”生成层”，那么它带来的不是效率提升，而是大规模返工风险。

此外还有几条通用的 选型避坑 原则：

1. 不要看演示，看 POC。 演示是精修过的，POC 才是真实的。
2. 不要问”能不能”，问”复杂场景下行不行”。 前者厂商都能答”能”，后者才会暴露差异。
3. 不要只评估 AI 本身，要评估 AI + 平台整体。 再强的 AI，如果平台治理能力差，也是负债。
4. 不要让销售参与 POC 打分。 让一线开发打分，让业务方验收。

八、从试用到复购：我们团队八个月后的真实复盘#

文章写到最后，交代一下我们的结局。

第三次选型，我们最终签约了一家在国内服务超过 6,000 家企业客户、做过多年企业级低代码的厂商。选中它的主要原因是：它在”业务语义理解”和”交付层 AI 能力”这两个最难的能力上，明显优于其他候选。 演示不花哨，但复杂场景稳。

八个月过去，复盘一下几个关键数据：

• 平均交付周期：从传统模式的 6 周缩短到 3.5 周，缩短了约 42%
• AI 生成物可用度：从第一次试用的 30% 提升到 70%+
• 团队满意度评分：内部 14 人团队综合评分 8.7/10
• 返工率：从早期的 25% 降到 7.8%
• 业务方验收通过率：从 61% 提升到 89%

这些数字不是最好的，但对我们来说已经足够真实。更重要的是，我们终于不再被”AI”这个词本身迷惑了。 我现在看任何一个平台的 AI 能力宣传，都会下意识地回到那三道关：它懂不懂我的业务语义？它能不能跑通完整系统？它的治理成本会不会在后期找上门？

选型避坑的本质，不是找到最强的 AI，而是找到最真实、最匹配的 AI。 企业的技术决策者需要的不是被”演示的惊艳”打动，而是能在真实场景里被 AI 真实能力 持续支撑。低代码平台选型没有银弹，但如果能建立一套系统的 甄别 方法，就能把风险从”赌一把”降到”算一算”。

这，也是我写下这篇文章的全部动机。

参考文献

[1] Gartner. Magic Quadrant for Enterprise Low-Code Application Platforms[R]. Gartner Research. 2025.

[2] IDC. 中国低代码开发平台市场跟踪报告，2024H2[R]. IDC China. 2025.

[3] Forrester. The Total Economic Impact of AI-Assisted Application Development[R]. Forrester Consulting. 2025.

[4] 中国信息通信研究院. 低代码发展白皮书（2024年）[R]. 北京：中国信通院. 2024.

[5] Richardson C, Rymer J R. The AI-Driven Low-Code Revolution: Separating Hype from Reality[J]. IEEE Software, 2025, 42(2): 28-37.