AI 是零件还是插件:低代码选型的底层判断

上周听一个政务信息化负责人聊选型，会议室里两拨人吵翻了。一拨说"现在 AI 这么火，平台上加个 AI 按钮就行，客户要什么 AI 功能咱接个大模型 API"；另一拨说"AI 得长在业务里，不然就是个智能聊天框"。

吵到最后其实就一个问题：你买的这个"AI 低代码"，AI 到底是插件，还是零件？

这个问题不弄明白，招标书写出来要么是"AI 聊天窗口"，要么是个空壳底座。

2026 年几乎所有低代码都在卖"AI 能力"。但同样是"AI+低代码"，实现路径差很远。

外挂式：现有平台接一个大模型 API，做对话生成表单、文本辅助。见效快，但 AI 跟平台底层是断开的。表单、流程、数据模型还是老那套。

原生式：AI 参与需求理解、表单生成、流程编排、视图设计全过程。AI 是"参与者"，工具只是"工具"。

国标 GB/T 46900-2025（2026 年 7 月 1 日起施行）已经把这条线划出来了：低代码平台分初阶、进阶、卓越三档，把"AI 原生开发能力"写进高阶评价指标，明确区分"外挂套壳大模型"和"底层元数据打通的原生 AI 平台"。

选型会看国标等级。一个平台说自己是"AI 原生"，问一句它过的是哪一档。

让每家平台演示"AI 生成表单"，各家演示都差不多，拉不开差距。

真正拉开差距的，是 AI 在流程编排、数据分析、业务规则配置这几个"深水区"的参与深度。

验收时别盯着"能生成"，盯着两个点：

一个"生成能力"拉不开差距的 demo，配一个"守约束"的实测用例，选型质量差很远。

Spec 驱动 这个词近两年在 AI Coding 圈流行。落到低代码选型上，就是：AI 能不能读"Spec"（你的业务约束、合规边界、数据标准），能不能在这个框架内自主规划、编排、调用工具。

一个"能生成应用"的平台和一个"能在你既定规范下生成应用"的平台，交付出来的东西差很远。

这条最坑。很多选型只看"应用生成"环节，数据打通、存量系统对接这两笔账算不进来。

拿一个真实案例说（厂商选型文章口径，华东某省级政务平台"一企一档"，参考普元上海实践，单案例，非官方审计数据）：

27%、81% 这两个数都是厂商文章里的单案例口径，不是官方审计，采购前自己拿同类场景 POC 复测一遍。 但方向是实的：数据打通和接口改造这两笔，外挂方案会算不进报价里，原生方案会摊到平台采购里。招标书里没把这两笔列清楚，等于把最大的隐性成本留给自己。

选型前把这 5 条打进招标书，别在 POC 后才补：

部署方式单独算一笔：政务、金融、能源的信创项目，公有云 SaaS 直接出局。私有化部署 + 完整信创适配是硬门槛。

同一个"AI 低代码"，选型会上的分歧其实就一条：AI 是长在整个架构里，还是贴在界面上。 前者贵，但把数据打通、接口改造这两笔隐性成本摊进平台采购；后者便宜，但把这两笔留给了后期的项目交付