从自然语言到应用元数据：AI Builder 如何生成对象和权限

先给结论：好的 AI Builder 不是把一句话变成几个页面，而是把一句业务需求拆成对象、字段、视图、流程、权限和 agent 工具——一份可运行、可修改、可治理的应用规格。

“一句话生成应用”听起来很有冲击力，但这句话本身容易误导。

如果读者以为它只是“输入一句话，然后生成几个页面”，那它和很多代码生成演示没有本质区别。真正值得关注的是：AI Builder 如何把一句业务需求拆成可运行、可修改、可治理的应用元数据。

我们用一个具体需求来看：

帮我搭建一个供应商风险管理应用。系统要管理供应商、资质、报价、采购订单、交付和质量问题；AI 能识别资质过期、报价异常和交付风险；关键物料供应商出现高风险时，要采购经理审批。

读者真正想知道的是：这句话进入平台以后，到底发生了什么？

第一步不是生成页面，而是生成业务对象图

AI Builder 首先要识别业务里的“名词”。

在这个例子里，主对象不是一个笼统的“供应商表”，而是一组相关对象：

• supplier：供应商主体；
• supplier_qualification：资质证照；
• quotation：报价记录；
• purchase_order：采购订单；
• delivery_record：交付记录；
• quality_issue：质量问题；
• supplier_risk：风险记录；
• approval_task：审批任务。

这一步很关键。因为对象决定了后续应用的边界。

如果只有一张大表，用户后面想问“这个风险来自哪次交付、哪张报价、哪份资质”，系统很难回答。对象拆清楚以后，风险就能关联证据，审批就能关联原因，Agent 也能解释依据。

第二步：字段和关系要带业务语义

低质量生成器会把字段当成表单项。高质量 Builder 会把字段当成业务语义。

例如资质对象不只是“附件”：

• 资质类型；
• 证书编号；
• 生效日期；
• 到期日期；
• 审核状态；
• 审核人；
• 关联供应商；
• 是否关键资质。

报价对象也不只是金额：

• 物料；
• 数量；
• 单价；
• 有效期；
• 历史均价偏差；
• 是否包含运输和售后；
• 关联采购申请。

关系同样重要：供应商有多份资质、多次报价、多张订单、多条交付记录和多个质量问题。风险记录要能反向指向这些证据。

这一步生成得好，后面的 AI 分析才不是“模型猜测”，而是“基于对象关系的解释”。

第三步：生成视图，让不同角色看到不同工作

企业应用不是给所有人看同一张表。

AI Builder 应该根据角色生成初始视图：

角色	视图
采购专员	我的供应商、待补资质、报价对比
采购经理	高风险供应商、待审批采购、关键物料风险
质量负责人	最近质量问题、重复缺陷、整改状态
法务/合规	资质缺口、合同条款风险、供应商黑名单
管理层	风险分布、供应商集中度、采购决策趋势

这一步很像低代码平台里的视图配置，但 AI Builder 的价值在于：它能从业务需求里先生成一套合理起点。

用户不需要从空白画布开始。

第四步：生成权限和动作边界

权限是 AI Builder 最容易被忽略、但最能区分专业度的地方。

在这个供应商应用里，至少要生成几类边界：

• 采购可以维护供应商档案，但不能直接修改质量结论；
• 质量负责人可以关闭质量问题，但不能审批采购订单；
• 采购经理可以审批高风险采购；
• 普通用户不能查看供应商敏感财务信息；
• AI 可以生成风险建议，但不能自动把供应商拉黑；
• 关键物料采购的高风险动作必须审批。

这些不是页面交互细节，而是运行时规则。

如果 Agent 后续能“帮我找出高风险供应商并暂停采购”，它必须先经过这些动作边界。否则 AI Builder 生成得越多，风险越大。

第五步：生成流程、自动化和 SLA

业务对象静态存在还不够。应用要能推动事情流转。

这个例子里的流程可能包括：

1. 新供应商建档；
2. 上传资质；
3. AI 检查资质完整性；
4. 报价进入比价；
5. 采购订单生成；
6. 交付记录回写；
7. AI 识别风险；
8. 高风险进入审批；
9. 整改或替代供应商建议；
10. 风险关闭并留痕。

自动化也应该从需求中生成：

• 资质到期前 30 天提醒；
• 关键资质过期时阻止新采购；
• 交付准时率低于阈值时生成风险；
• 同类质量问题重复出现时创建复审任务；
• 高风险审批超时提醒采购经理。

这才是“生成应用”，而不是“生成页面”。

第六步：生成 Agent 工具，并解释它能做什么

AI 原生应用的最后一层，是 Agent 工具。

平台应该生成受控工具，而不是让模型直接访问数据库。例如：

• 查询供应商风险；
• 比较报价；
• 解释风险来源；
• 创建复审任务；
• 发起高风险采购审批；
• 生成供应商月度风险报告。

每个工具都要有输入、输出、权限和审计。

当用户问：

这个供应商还能不能下单？

Agent 应该先查供应商、资质、交付、质量和报价，再给出结论和证据。它可以建议“降低首批采购量”或“要求补充资质”，但真正暂停采购或发起审批，要走平台动作。

好的 Builder 会展示“生成计划”

从读者角度看，AI Builder 最需要建立信任。

所以它不应该静默生成一切，而应该展示生成计划：

• 将创建哪些对象；
• 每个对象有哪些关键字段；
• 对象之间有哪些关系；
• 将生成哪些视图；
• 哪些权限规则会生效；
• 哪些自动化会运行；
• Agent 可以调用哪些工具；
• 哪些动作需要人工确认。

用户确认后再生成应用。这样 AI Builder 不是黑盒，而是一个可以协作的应用架构师。

ObjectStack 的生成链路

ObjectStack 的 AI Builder 应该把自然语言转成应用规格，再由规格驱动运行时。

这条链路是：

自然语言需求 → 业务对象 → 字段关系 → 视图表单 → 权限边界 → 流程自动化 → Agent 工具 → 审计运行时

这条链路越清楚，读者越容易理解平台差异。

一句话生成应用不是魔法。真正的价值，是平台知道这句话应该落到哪一层元数据，以及这些元数据如何一起驱动一个可运行的业务系统。