背景
我的低代码引擎已具备完整的设计器能力，现在我要给它接入AI。
本文我将详细介绍我的 V1 版本AI 接入低代码的完整实现过程。
一、架构设计：AI 以何种方式接入
低代码平台发展到今天，从早期的拖拽搭建，到可视化属性编辑，再到现在的 AI 辅助生成，每一步都是在降低页面搭建的门槛。我认为 AI 不是替代设计器，而是给设计器加上了一种新的输入方式 —— 用自然语言描述，代替手动拖拽。
我的引擎从一开始就采用了插件化架构：物料、面板、快捷键、Command 命令都通过插件体系挂载。所以通过 AI 增强编辑体验，天然适合以插件的形式接入。
装上 AI 插件，设计器多一个 AI 设计器，对平台侵入性极低。一行代码接入 AI 能力：
engine.pluginManager.register(AIPlugin)
这里 AI 插件向引擎内部注册了两样东西：一个AI交互面板，一个自定义 Command；面板负责用户交互，Command 负责将 AI 生成的 Schema 写入引擎，并自动纳入 History，支持撤销。
整个流程：用户输入 → 组装 Prompt → 请求 AI → 返回结果 → 校验并修复结果 → Command 提交 → Renderer 更新
整体架构如下——AI 以插件形式挂在 Designer 与引擎之间，不修改引擎核心，只通过 Engine API 读写：
二、AI工具（AIPlugin）设计方案
AI 插件采用「4 层核心 + UI 编排」的分层设计：4 层核心各司其职，UI 编排层（AIPanel）负责串联调度全流程。
4 层核心流水线：
Prompt 层 → Service 层 → 校验层 → Command 层
↑___________________________________|
UI 编排层（AIPanel）串联调度
下面先逐层介绍 4 层核心，再说明 UI 编排层如何串联。
2.1 Prompt 层：让 AI 理解我的组件体系
Prompt 的质量直接决定 AI 生成的质量。这一层解决的核心问题是：AI 怎么知道我的平台有哪些组件、每个组件有什么属性、Schema 应该长什么样？
核心函数 buildSystemPrompt() 负责动态组装 System Prompt，组装规则分三步：
第一步：动态读取物料表。 从引擎的 MaterialRegistry 读取所有已注册组件。这样新增物料时 Prompt 会自动更新，不需要额外维护。
第二步：翻译属性描述。 遍历每个物料的 configure（属性配置），根据 setter 类型自动翻译成 AI 能理解的文字。比如 SelectSetter 会列出所有可选值（[{label,value}]数组），NumberSetter 翻译为"数字"。
第三步：拼装完整指令。 将角色定义、规则、组件列表、Schema 格式说明和示例拼成一段完整的 System Prompt。
场景化 Prompt 生成策略
一个通用 Prompt 不可能精准覆盖所有场景。为了做到 Prompt 更准确描述各类场景，我做了场景检测 + 按需追加，比如：
- 当用户输入"登录表单" → 命中关键词"登录" → 追加表单布局规范 + 完整表单 JSON 示例
- 用户输入"点击按钮弹出提示" → 命中"点击" → 追加 events/methods 交互规范
多场景可以叠加 —— "生成登录表单，点击按钮弹出提示"会同时追加表单规则和交互规则。
交互生成复用现有事件模型：引擎本身已有完整的事件体系 —— schema.events 声明事件绑定，schema.methods 定义 JSFunction 方法体。AI 只需在 Schema 中按格式输出 events 和 methods，运行时会自动绑定。校验器也做了 events 交互相关的兜底。
实践中一个经验：好的示例比好的规则更有效。 在 Prompt 中放一个完整的表单 JSON 示例，AI 模仿的成功率远高于用文字描述"每个字段行用 Container(direction=row) 包裹 Text + Input"这种抽象规则。
最终发给 AI 的 Prompt（System Prompt + user Prompt）大致结构如下：
你是一个低代码页面 Schema 生成器...
## 规则
1. 只使用可用组件，不要编造
2. 根节点必须是 Page
3. 每个节点有唯一 id
...
## 可用组件（← 动态生成）
- Container（容器，props: direction="column"|"row", gap=数字, padding=数字）
- Text（文本，props: text=字符串, fontSize=数字, color=颜色值）
- Button（按钮，props: text=字符串, type="default"|"primary"）
- Select（下拉选择，props: placeholder=字符串, options=[{label,value}]数组）
...
## Schema 格式 + 示例
{ "id": "page-root", "componentName": "Page", ... }
## user Prompt
生成一个登录表单，包含标题\"用户登录\"、用户名输入框、密码输入框和一个登录按钮
2.2 Service 层：与 AI 模型通信
服务层只做一件事：把 Prompt 发给 AI，把回复拿回来。
采用 OpenAI Chat Completions 兼容格式，可以切换任意厂商 —— DeepSeek、OpenAI、通义千问，只要兼容这个协议就能用，换模型只需改配置：
// aiConfig.ts
export const aiConfig: AIServiceConfig = {
apiKey: 'sk-xxx', // 从环境变量读取
baseUrl: 'https://api.chatanywhere.tech',
model: 'gpt-4o',
}
服务层还做了一个关键扩展 —— 多模态支持。当用户上传设计稿图片时，user message 从纯文本变为图文混合的数组格式：
// aiService.ts
const userContent = imageBase64
? [
{ type: 'image_url', image_url: { url: imageBase64 } },
{ type: 'text', text: userPrompt || '根据这张设计稿生成页面 Schema' },
]
: userPrompt
另外，temperature 固定为 0.2。Schema 是结构化数据，需要确定性输出，随机性不用太大。
2.3 校验层：AI 输出的安全网
AI 返回的 JSON 不一定完美 —— 可能缺 id、可能存在的无效组件等情况。校验器在 Schema 写入引擎之前，目前做了 5 层检查和自动修复：
- ① 基本类型检查 —— 是不是有效 JSON 对象
- ② 根节点修复 —— 不是 Page，则自动包裹
- ③ 递归校验 —— 逐节点检查：补 id、修 props、补 meta、过滤无效 children
- ④ ID 去重 —— 重复 id 自动重新生成
- ⑤ events + methods —— 校验方法格式、补全缺失的方法引用
校验器的设计原则是：能修复的修复，不能修复的报错，修复了什么会告诉用户。所以返回值同时包含 errors（致命问题）和 warnings（已自动修复的问题），面板 UI 也会展示这些信息。
2.4 Command 层：可撤销的写入
所有对 DocumentModel 的写操作 —— 都要通过引擎的 Command 提交。所以 AIPlugin 需要定义了一个自定义 Command：
export const aiReplaceSchemaCommand: ICommand = {
name: 'aiReplaceSchemaCommand',
/**
* 执行：用 AI 生成的 Schema 替换当前页面
*/
execute(documentModel, payload) {
const prevSchema = structuredClone(documentModel.toSchema())
ctx.documentModel.replaceSchema(payload.schema)
return { prevSchema }
},
/**
* 撤销：将页面恢复到 AI 生成之前的状态
*/
undo(documentModel, _payload, result) {
if (result?.prevSchema) {
ctx.documentModel.replaceSchema(result.prevSchema)
}
},
}
如果 AI 生成不满意？Ctrl+Z 一键回到生成前的状态。这里也体现了插件化的好处 —— Command 系统是引擎的基础能力，AI 插件只需注册了一个新命令，自然就获得了 Undo/Redo 的支持。
2.5 UI 编排层：AIPanel 串联 4 层核心
AIPanel 是用户看到的界面，也是整个流程的编排者——它不属于 4 层核心本身，而是调度 4 层核心的入口。低代码搭建者输入需求（如「生成一个登录页」），点击生成，就会执行：
const handleGenerate = async () => {
// ① Prompt 层：构造 System Prompt + 场景检测
const materials = engine.ctx.material.getAll()
let systemPrompt = buildSystemPrompt(materials)
if (isFormScenario(prompt)) systemPrompt += '\n\n' + buildFormPromptRules()
if (isInteractionScenario(prompt)) systemPrompt += '\n\n' + buildInteractionPromptRules()
// ② Service 层：调用 AI API
const result = await service.generate({ systemPrompt, userPrompt: prompt, imageBase64 })
// ③ 校验层：校验 + 修复
const validation = validateAndFixSchema(result.schema, materials)
// ④ Command 层：写入引擎
engine.command.execute('aiReplaceSchemaCommand', { schema: validation.schema })
}
面板 UI 还提供了 预设模板（一键填入常见场景描述）、图片上传（支持设计稿转 Schema）、状态反馈信息（加载中、成功、警告、错误等），如图：
三、踩过的坑：AI 上下文有限，如何保证输出可用
开发过程中遇到一个典型问题：AI 生成的内容页面渲染正常，能选中、能改属性，但完全无法拖拽。排查后发现，AI 生成的节点缺少 meta 字段——拖拽系统依赖 meta.isContainer（判断节点能否接收子节点），没有它拖拽就失效了。
但这不是 AI 的错。meta 是引擎内部的元信息，Prompt 里从未提及，AI 自然不会生成。
这个坑让我意识到：AI 的上下文窗口是有限的——它只能根据 Prompt 中给出的信息来生成 Schema。引擎内部的隐式约定（如 meta、根节点 id 必须为 root等）不可能全部塞进 Prompt，塞多了 token 成本高、AI 注意力也会分散。
这意味着 AI 输出的 JSON 必然存在和引擎 Schema 规范的偏差，这不是 AI 的问题，而是上下文有限的客观限制。所以如何避免”错误的生成结果” 替换掉 Schema 呢？
我的方案：AI 的原始输出的数据直接用风险太高，必须经过校验和清洗，转换为引擎能安全消费的格式。 就像数据管道中的 ETL 一样，是流程中的一环。
具体策略：
- Prompt 尽量做好 — 把 AI 能理解且需要遵守的规则（组件列表、props 格式、嵌套结构）讲清楚，用示例引导，减少 AI 犯错的概率。这决定了输出质量的上限。
- 校验层清洗和修复 — 对于 AI 不需要关心的内部约定（meta 补全、id 规范化等），在写入引擎前由校验器统一处理。能修则修，不能修则拦截，绝不让不合法的 Schema 进入引擎。
- Command 层保证可撤销 — 通过 Command 系统写入的 Schema 自动纳入 History，Ctrl+Z 即可回退。
三步流水线：Prompt 降低出错概率 → 校验层清洗和修复偏差 → Command 层保证可撤销。把 AI 上下文有限带来的风险控制在可接受范围内。
四、成果展示
V1 完成了「输入一句话 → 生成页面 → 画布可编辑」的最小闭环。下面以学生信息录入表单为例，展示从 Prompt 到成品的完整过程。
Step 1：输入需求，点击生成
在 AI 面板中选择预设模板或手动输入描述，点击「AI 生成」，等待 AI 返回结果。
Step 2：画布即时渲染，并可继续编辑
数秒后，AI 生成的内容经过处理写入画布：标题、各字段行、下拉选项、提交按钮一应俱全。生成结果与手动拖拽搭建一样——可选中、改属性、可拖拽调整，并支持撤销重做。
Step 3：Schema 源数据可查，支持二次修改
生成结果本质是标准 Schema JSON，可通过 Schema 编辑器查看完整结构。不满意的地方既可以在画布上手动改，也可以直接编辑 JSON 后应用。
除文本描述外，V1 同样支持上传设计稿图片做多模态生成。
五、总结与展望
V1 成果
V1 版完成了 AI 接入低代码的从零到一：自然语言或设计稿图片一键生成完整页面，覆盖表单、展示、交互等常见场景，生成结果支持撤销，对引擎现有功能零侵入。
核心设计原则
- 插件化接入 — AI 是可选增强，不是必要依赖。一行
register(AIPlugin)接入，移除也不影响引擎任何功能。 - Prompt 驱动质量，校验保障安全 — 场景化 Prompt 策略让 AI 输出尽可能准确，校验层作为必要的数据修复环节，确保最终写入引擎的 Schema 安全可用。
未来展望
当前版本是"一次性生成整个页面"，后期演进的方向是让 AI 更深度地融入编辑流程——支持多轮对话式编辑和局部修改，让 AI 成为真正的"低代码平台设计助手"。
