AuraBoot 是什么

AuraBoot 是一个 AI 原生的企业应用运行时——以模型驱动、以命令治理、以插件交付。

它不是一个 CRUD 构建器,也不是一套打包好的 ERP。它是这两者底下的运行时层:业务操作在这里被定义、执行、授权、审计,并通过统一契约向 AI Agent 开放。

这个市场上的三种位置

不同产品针对不同的目标进行优化。我们用类别而不是品牌来描述这个版图,因为客户在做选择时,需要看清"选择的形状",而不是某个功能清单。

位置主要优化目标强项边界
数据应用构建器把数据库快速变成一个可用后台可视化建模、出屏快、数据源丰富跨模块业务逻辑、治理、受监管的工作流深度有限
成熟业务套件买一套现成可跑的 ERP/CRM标准模块成熟、实施方法论清晰深度非标流程、垂直行业差异、AI 驱动的业务操作
AuraBoot长生命周期、操作复杂的企业应用受治理的业务命令、分层权限、插件式交付的行业方案、AI 可安全执行学习曲线高于纯表单工具;不是开箱即用的会计套件替代品

如果客户的诉求是"周五前出一个部门级表单",应该选数据应用构建器。如果诉求是"下个季度上线一套会计系统",应该选成熟套件。AuraBoot 的位置是第三种:业务复杂、生命周期以年为单位、业务操作需要被自动化和 AI 安全调用

核心抽象

AuraBoot 建立在六个一等公民概念之上。所有插件、页面、AI 工具都用这六个概念来表达。

概念职责
Model(模型)定义业务实体、字段、关系和底层存储。驱动 schema、列表/详情/表单页、API。
Page(页面)通过 DSL 描述、由块组合而成的 UI。业务 CRUD 不允许写零散 TSX,渲染器由契约驱动。
Command(命令)唯一受认可的写入路径。每条命令都流经多阶段管线:授权、entitlement、schema 校验、前置条件、状态守护、执行、审计、事件、副作用。
Permission(权限)分层访问控制,结合基于角色、基于关系、基于属性的判定,覆盖菜单、记录、组织、属性、字段五个维度。
Process(流程)长流程编排(BPMN 2.0),每个任务都可以归一到 Command,让流程步骤留在同一个治理契约里。
Plugin(插件)交付的单位。一个插件声明它贡献的 model、field、command、permission、menu、page、process、namedQuery。行业方案本身就是插件包。

这六个概念不是抽象目标,而是平台层面强制约束的契约。架构总览和核心概念章节会逐一展开。

这套抽象在日常工作中的三个后果

1. 业务操作不是按钮,是命令。 用户点"提交"时,前端 dispatch 的是一个 command code。这条命令的权限、前置条件、状态迁移、副作用、审计记录都写在元数据里,而不是藏在 handler 代码中。同一条命令可以从 UI 调用、自动化规则调用、外部集成调用——当它声明了风险等级和幂等性,也可以被 AI Agent 调用。

2. 权限不是堆规则,是分层判定。 功能权限(RBAC)、记录共享(ReBAC)、组织数据范围、属性策略、字段级可见性,按定义好的顺序判定,主体是租户成员(tenant member)而不是裸用户。正是这套机制让企业可以做到 "销售经理可见本组织下所有商机,只能编辑自己创建且金额超过 5 万的,对非财务角色隐藏折扣字段"——而不需要为每种权限场景写定制代码。

3. 交付是插件形状,不是定制形状。 行业垂直(制造、合同、资产管理)以插件包的形式发布,自带 model、command、permission、page。升级平台不会打坏你的定制,因为你的定制不是补丁——而是声明了依赖的插件。

AuraBoot 不适合做什么

我们把不适合的场景明确说出来,让团队挑对工具:

  • 纯部门级表单工具或单一用途的内部跟踪表。 数据应用构建器出屏更快,AuraBoot 提供的深度(命令、分层权限、BPM)你在这种场景下用不上,反而是负担。
  • 第一个季度内替换标准会计或薪酬套件。 国别合规、本地化、一级 ERP 的审计预期不是一个运行时能解决的。AuraBoot 连接这些系统并运行外围业务操作,但不会在第一天就替代它们。
  • 没人会读审计日志的内部小工具。 如果审计、权限、可追溯不是要求,那学习 AuraBoot 契约的时间不会被收益覆盖。

AuraBoot 赢的场景

  • 业务有复杂的跨模块流转(报价 → 订单 → 采购 → ASN → 批次追溯),现成模块没有一个能精确覆盖
  • 客户要求记录级、组织级、字段级治理,而不是只看角色
  • 路线图里有 AI Agent,需要它执行业务操作,而不只是回答数据问题
  • 行业差异化能力要作为长期产品交付,而不是长期咨询项目

下一步