元数据，不是代码生成：AI 应用为什么可治理

先给结论：AI 原生应用的核心不是把需求变成一堆代码，而是生成对象、权限、流程、agent 工具共同受控的元数据——代码能跑，元数据才改得动、治得住。

过去几年，低代码平台解决了一个很具体的问题：不要每个内部系统都从零写页面、写表单、写流程。

现在 AI 又把这个问题往前推了一步：既然低代码可以拖拽搭应用，那能不能直接用一句话生成应用？

答案是可以，但这里有一个很容易踩的坑：如果把“AI 生成应用”理解成“AI 生成一堆代码”，很快会遇到企业应用的老问题。第一版看起来很快，第二版开始变慢；页面能跑，权限不好管；表单能提交，流程难追踪；AI 能回答，Agent 不知道哪些动作能做、哪些动作不能做。

真正的 AI 原生应用平台，核心不是代码生成，而是元数据生成。

读者真正关心的不是代码，而是系统能不能改

站在业务负责人和 IT 负责人的角度，看一个应用平台，最重要的问题通常不是“第一版能不能生成出来”，而是：

• 业务变化时能不能改；
• 改了字段以后，表单、列表、权限、流程是否同步；
• 新增审批规则时，旧数据和旧流程是否还能解释；
• AI Agent 是否继承用户权限；
• 谁看过什么、改过什么、批准过什么，能不能审计；
• 这个系统半年后是不是还可维护。

代码生成解决的是“从无到有”的速度。元数据解决的是“持续演进”的结构。

这就是低代码平台过去十几年得到的经验：企业应用不是一组页面，而是一套可配置、可治理、可升级的业务模型。AI Builder 如果只回到代码生成，就会绕开低代码最有价值的部分。

代码生成为什么容易在企业应用里失控

代码生成适合做原型、小工具和一次性页面。它能快速生成 React 组件、API、数据库 schema 和一些校验逻辑。

但企业应用的复杂度通常不在这些地方，而在跨层一致性。

举个例子。用户说：

给客户增加一个“续约风险”字段，高风险客户每周提醒客户成功经理跟进。

如果这是代码生成任务，AI 可能会改数据库、改表单、改列表，再写一个定时任务。看起来完成了。

但在真实企业系统里，这个字段还会影响：

• 客户详情页是否展示；
• 谁能编辑风险等级；
• 主管能否看到团队风险；
• 导出报表是否包含该字段；
• Agent 总结客户时能否引用；
• 高风险规则是否进入审计；
• 修改风险等级是否触发通知；
• 未来字段名称变化时如何迁移。

这些内容如果散落在代码里，每次修改都像小型重构。系统越用越重，最后又回到传统定制开发的泥潭。

元数据不是配置表，而是应用运行时的业务语言

很多人听到“元数据”，会以为只是配置项。这里说的元数据要更完整：它是应用运行时理解业务的语言。

元数据层	它回答的问题
对象	业务里有哪些核心实体，比如客户、合同、工单、任务
字段	每个对象有哪些属性，类型、必填、公式、敏感性是什么
关系	对象之间如何关联，一对多、多对多、引用和反向引用是什么
视图	不同角色如何查看数据，列表、看板、表单、详情、仪表盘如何组织
权限	谁能看、谁能改、能看哪些记录、能操作哪些字段
流程	状态如何流转，哪些条件触发审批、通知和自动化
动作	创建任务、发起审批、生成报告、发送提醒等业务动作
Agent 工具	AI 能查询什么、建议什么、执行什么、什么时候必须停下来等人确认
审计	AI 建议了什么，人确认了什么，系统最终执行了什么

这些元数据共同驱动 UI、API、权限、自动化和 Agent。

页面只是元数据的一种表现。API 也是。Agent 工具也是。这样系统才不会因为入口不同而行为不一致。

AI Builder 应该生成“应用规格”，不是直接甩出代码

一个成熟的 AI Builder 收到需求后，不应该第一反应就是写代码。它更像一个懂低代码平台的业务架构师，先生成应用规格。

例如用户说：

帮我搭建一个售后工单应用，客户可以提交问题，AI 自动分类并推荐回复，企业客户超时自动升级。

Builder 应该先产出：

1. 主对象：客户、工单、消息、知识库、SLA、升级记录；
2. 字段：问题类型、优先级、情绪、影响范围、截止时间；
3. 视图：客服队列、主管看板、快超时工单、高风险客户；
4. 权限：客户、客服、主管、管理员分别能看什么；
5. 流程：提交、分类、处理、升级、关闭、复盘；
6. Agent 工具：摘要、分类、知识匹配、回复草稿、升级建议；
7. 审计：AI 初判、人工修改、发送确认、升级原因。

这份规格确认后，平台再生成页面、数据结构、自动化和工具调用。

这比直接生成代码慢不了多少，但后续会稳很多。

和传统低代码相比，AI 改变了什么

传统低代码平台通常要求用户理解配置界面：对象设计器、字段面板、流程画布、权限矩阵、表达式编辑器。

AI Builder 不应该推翻这些能力，而应该降低表达成本。

用户不需要知道应该打开哪个配置面板。他可以说：

把高风险合同单独放到一个法务看板里，金额超过 50 万的再加财务复核。

平台把这句话拆成对象筛选、视图、流程条件、审批节点和权限变更，并展示变更计划让用户确认。

这才是 AI 对低代码的真正增强：不是让平台变成黑盒，而是让业务语言直接进入平台结构。

判断一个 AI Builder 是否靠谱，可以看 6 件事

如果你在评估 AI 应用平台，不要只看它能不能生成一个漂亮页面。更应该问：

1. 它生成的是代码，还是可解释的对象、字段、视图、权限和流程？
2. 业务人员后续能否用自然语言修改应用结构？
3. 权限是否是运行时统一能力，而不是页面里的临时判断？
4. AI Agent 是否只能通过受控工具访问和修改数据？
5. 每次 AI 建议、人工确认和系统执行是否有审计？
6. 当业务规则变化时，是改元数据，还是重新生成代码？

这几个问题的答案，决定了它是演示工具，还是企业应用平台。

ObjectStack 的差异

ObjectStack 的方向，是让自然语言生成元数据，再由元数据驱动运行时。

用户说一句需求，平台生成对象、字段、关系、视图、权限、流程、动作和 Agent 工具。应用运行后，业务人员继续用自然语言修改它。AI Agent 也在同一套对象、权限和动作边界内工作。

代码仍然存在，但它不再是业务变化的唯一承载物。业务结构进入元数据层，才能被生成、理解、修改、治理和审计。

代码生成让第一版更快。元数据生成让第十版仍然可控。