AI可以在几秒钟内生成一个落地页。
这部分已经不再令人印象深刻。
难点在于你问了一个不同的问题：
AI真的能理解你正在编辑的页面吗？
它能修改一个部分而不破坏文档的其他部分吗？它能保留你的变量吗？它能翻译一个现有页面而不破坏其布局吗？它能生成一个新章节，在编辑器中表现得像原生组件一样吗？
这些就是我们在构建 GJSDocs时遇到的问题，GJSDocs是一款基于 GrapesJS编辑体验的AI驱动的可视化文档编辑器。
在本文中，我们将带你了解AI驱动的可视化编辑器背后的架构，哪些方面有效，哪些无效，以及我们在为生产构建过程中学到的经验教训。
AI生成器和AI编辑器的区别
有两种非常不同的产品，通常被称为“AI页面构建器”。
第一个看起来是这样的：
Prompt ↓ AI ↓ HTML ↓ Preview 你进入：
“创建一个现代化的SaaS登陆页面。”
该模型生成HTML和CSS。
演示版看起来很有印象。
但接下来会发生什么？
你想更改定价部分。
你想翻译英雄。
你想更换CTA。
你想改变间距。
你想连接 {customer.name} 你的CRM。
现在你又得手动编辑页面了。
第二种方法更有趣：
在这里，AI并不能取代视觉编辑器。
AI成为控制编辑的另一种方式。
这一区分成为我们在建设GJSDocs时做出的最重要建筑决策之一。
我们为何选择 GrapesJS
当你从零开始构建一个可视化编辑器时，画布只是开始。
你需要：
组件管理;
拖放;
选拔;
风格;
反应性行为;
撤销/重做;
方块;
序列化;
存储;
键盘交互;
插件;
指挥;
资产管理;
以及让一切协同运作的方式。
自己组装这些东西很贵。
GrapesJS 给你编辑引擎，同时让你围绕它构建自己的产品体验。
这正是我们希望 GJSDocs 拥有的架构。
重要的是， GrapesJS 不需要知道人工智能的存在。
你的应用就是编排层。
这种分离非常实用。
编辑器负责管理视觉状态。
你的应用管理业务逻辑。
AI层将自然语言转化为结构化操作。
人工智能驱动 GrapesJS 编辑器的架构
我们的架构可以简化为五个层次。
1. 编辑
GrapesJS画布包含了实际的文件。
2. 背景
我们收集人工智能所需的信息，以理解用户当前正在编辑的内容。
3. 人工智能提供者
请求可以发送给 OpenAI、Gemini 或 Claude 等大型语言模型。
4. 结构化输出
模型返回的是可预测的结构，而非任意的 HTML。
5. 编辑器适配器
应用程序将该结构转换为 GrapesJS 组件。
完整的流程如下：
上下文构建器是最重要的部分之一。
没有上下文，人工智能就是在猜测。
有了上下文，AI就是在编辑。
步骤1：赋予AI对编辑器上下文的访问权限
一个常见错误是只向模型发送用户提示。
例如：
Translate this section to Spanish. AI根本不知道“这部分”是什么意思。
相反，我们可以发送类似概念的代码：
{ instruction: "Translate this section to Spanish", scope: "selection", document: { title: "Sales Proposal", page: 2 }, selection: { type: "section", html: "...", text: "...", components: [...] }, variables: [ "client.name", "company.name", "proposal.total" ] } 现在模型有了有意义的语境。
它知道：
用户选择了什么;
它属于哪个页面;
文件内容;
存在哪些变量;
以及用户请求的操作。
这会带来巨大的区别。
步骤2：不要让AI返回随机的HTML
这又是一个重要的教训。
最简单的实现方式是：
Prompt → AI → HTML string 但这也带来了问题。
生成的HTML可能包含：
无效结构;
意外的CSS;
不必要的包装;
与现有文件相冲突的风格;
剧本;
无支撑元素;
或者内容之后难以编辑。
更好的架构是：
例如：
{ "type": "section", "layout": "three-column", "heading": "Choose your plan", "columns": [ { "title": "Starter", "price": "{pricing.starter}" }, { "title": "Pro", "price": "{pricing.pro}", "featured": true }, { "title": "Business", "price": "{pricing.business}" } ] } 然后你的应用程序决定这个结构如何映射到实际的编辑器组件。
这会让你有更多的控制权。
第三步：让AI生成组件，而不仅仅是内容
一旦AI输出结构化，我们就能用它做远不止文案写作。
例如，用户可以问：
创建一个三栏定价板块，包含入门计划、专业计划和商业计划。将专业方案设为高亮选项。
AI可以返回该部分的结构化表示。
你的编辑器适配器会将其转换为：
现在生成的结果不仅仅是一段HTML代码。
它确实是一个可编辑的文档结构。
那是一个更强大的模型。
步骤4：引入AI瞄准镜
我们在GJSDocs中实现的最好的用户体验改进之一是允许AI操作有明确的范围。
与其有一个巨大的“AI生成”按钮，不如考虑：
选择
只修改用户选择的内容。
Selection → AI → Selection 章节
修改整段。
Section → AI → Updated Section 页面
转换当前页面。
Page → AI → Updated Page 文件
彻底改变整个文档。
Document → AI → Updated Document 这听起来像是个小细节。
其实不是。
它大大减少了用户对请求AI修改的恐惧。
如果我选一个段落问：
“让这更专业点。”
我不指望AI重新设计我的整个文档。
范围设定了自然的安全边界。
步骤5：AI应理解变量
当你的编辑不仅仅是网站建设者时，这一点尤为重要。
考虑一份包含以下内容的商业文件：
Dear {client.name}, Thank you for choosing {company.name}. Your total is {invoice.total}. 一个盲目重写HTML的AI系统可能会意外更改或删除这些变量。
在自动化平台里，这是不可接受的。
GJSDocs 将变量视为独立的层。
模板可以包含：
{client.name} {client.email} {company.name} {invoice.total} AI可以围绕这些变量生成内容，而变量系统则负责后续的解决。
这形成了一个有用的分离：
该架构允许同一模板生成数百份个性化文档。
步骤6：将AI与真实数据连接起来
变量之后的下一步是外部数据。
当生成内容能够与实际业务数据结合时，页面构建器会变得更加有用。
例如：
GJSDocs 支持诸如 Airtable、HubSpot 和 Google Sheets 等集成，以及自定义的 REST API 源。
这意味着编辑器不再只是设计工具。
它成为一个数据驱动的发电系统。
想象一下，一个销售团队曾经创建过一份提案模板。
该模板包含：
{client.name} {client.company} {project.name} {project.price} 应用程序会检索客户的数据。
AI可以生成或重写相应的章节。
模板已经渲染出来。
最终文档被导出。
这和传统的页面构建器是完全不同的产品。
步骤7：多家AI提供商
我们还了解到，人工智能不应不必要地与单一供应商绑定。
不同型号擅长不同领域。
有些用户更喜欢OpenAI。
还有人更喜欢双子座。
还有人想要克劳德。
因此，应用程序理想情况下应暴露提供者的抽象：
const ai = createAIProvider({ provider: "openai", apiKey: process.env.OPENAI_API_KEY }); 概念上：
编辑不应该关心是哪个模型生成了回应。
它只应该关心合同内容：
Input → Structured Output 这让系统更容易进化。
GJSDocs 目前支持 Gemini、OpenAI 和 Claude 进行基于 AI 驱动的文档生成与转换。
第八步：人工智能应能够编辑现有内容
生成新页面很有用。
编辑现有页面可以说更有价值。
想象一下，选择一段话问：
把这段说得简短点。
或者：
将此页翻译成法语。
或者：
将此提案重写为更适合企业的读者。
或者：
将此部分替换为对比表。
这些本质上是剪辑操作。
AI工作流程变为：
这更接近人类实际使用视觉编辑器的方式。
第九步：永远不要让AI无限控制
AI驱动的编辑器不应盲目执行模型返回的所有内容。
当生成的结果可能影响以下方面时，这一点尤为重要：
HTML;
CSS;
JavaScript;
外部网址;
形式;
嵌入;
API 调用;
或者用户数据。
我们建议将AI输出视为 不可信输入。
验证它。
消毒它。
限制可生成的组件。
除非有非常充分的理由，否则不要允许随意 JavaScript 。
并且尽可能使用支持组件类型的白名单。
例如：
const allowedComponents = [ "section", "container", "heading", "text", "image", "button", "columns", "table" ]; 如果模型返回了允许模式之外的内容，就拒绝或转换它。
LLM应该提出建议。
你的应用应该保持控制。
我们推荐的AI页面构建架构
整合所有内容：
这种架构有一个主要优势：
每一层都有明确的责任。
我们绝不会做的事
在构建了一个AI驱动的编辑器后，有几种方法我们会避免。
1. 不要为每个请求生成整页
如果用户要求你更改标题，不要重新生成整个文档。
小规模的操作应当带来小幅度的改变。
2. 不要完全依赖原始 HTML
HTML是一种输出格式。
这不一定是你内部AI协议的问题。
结构化数据能让你有更多控制权。
3. 不要对用户隐藏AI状态
用户应该了解人工智能即将发生的变化。
良好的用户体验可以包括：
预览;
diff;
撤销;
再生;
接受/拒绝;
选择范围。
4. 不要让人工智能成为唯一的界面
有些用户想输入：
“把纽扣做成蓝色。”
还有人想点击色彩选择器。
一个好的视觉编辑器应该同时支持这两者。
人工智能和传统用户界面应当互补。
我们认为最重要的用户体验
最有趣的课程不是技术层面的。
是用户体验。
AI在情 境化时效果最佳。
与其在编辑旁边放置一个巨大的聊天机器人，不如在用户已经在工作的地方放置AI操作。
例如：
现在AI感觉像是编辑器的一部分。
不是单独的产品。
这种区分让体验更加自然。
构建第一个版本
你不需要第一天就建好整个系统。
一个好的MVP只能包含三种AI操作：
1. 生成
Prompt → New Section 2. 重写
Selected Content → Improved Content 3. 翻译
Selected Content → Translated Content 然后补充：
全页生成
样式修改
布局生成
变量提取
数据感知生成
AI模板
人工智能工作流程
重要的是从一开始就正确建立架构。
从页面构建器到AI应用平台
这时事情变得非常有趣。
一旦你的人工智能理解了编辑器的组件树，它能做的事情远不止生成页面。
它可以成为一个编排层。
例如：
"Create a proposal for Acme Corp." 可能最终会触发：
到那时，你就不再只是做页面构建器了。
你正在构建一个 AI原生内容应用。
我们认为视觉编辑正朝着这个方向发展。
我们在建设GJSDocs中学到的
构建 GJSDocs 改变了我们对AI编辑器应有的认知。
起初，人们很容易想：
“我们只需要把一个大型语言模型连接到编辑器。”
实际上，模型只是系统的一部分。
难题有：
背景;
结构;
验证;
编辑状态;
变量;
数据;
许可;
用户体验;
以及可预测的变形。
AI模型是智能层。
编辑者是智能运作的环境。
这就是为什么 GrapesJS 成为这类产品如此有趣的基础。
它提供可视化编辑引擎，同时让应用自由构建AI、数据、业务逻辑和用户体验。
最终架构
如果我们今天启动一个新的人工智能驱动 GrapesJS 项目，我们的基线架构大概会是这样的：
具体的堆栈可能会变化。
原则上没有。
编辑器、AI和业务逻辑保持独立图层。
未来不是AI对抗视觉编辑
我们不认为人工智能会取代视觉编辑器。
我们认为情况会恰恰相反。
视觉编辑为人工智能带来了极其宝贵的东西：
一个结构化的环境，供内部操作。
而人工智能为视觉编辑带来了他们历来缺乏的东西：
一种用于操作复杂结构的自然语言接口。
未来的页面构建器可能不会像：
拖→放→配置→重复
更像是：
“帮我建一个B2B SaaS公司的定价页面。”
然后：
“让职业计划更突出。”
然后：
“翻译成德语。”
然后：
“把价格连接到我们的API。”
然后：
“让它移动优先。”
最后：
“发表它。”
用户依然掌控着自己。
可视化编辑器依然是事实的来源。
人工智能只是成为表达用户需求最快的方式。
这正是我们通过GJSDocs打造的模式。
最终总结
如果你在2026年开发一款需要视觉编辑器的SaaS产品，不要把AI当作附加聊天机器人。
把它当作编辑器的新交互层。
从 GrapesJS开始。
建立一个强有力的上下文层。
使用结构化AI输出。
将变量和数据与生成内容分开。
验证一切。
给予用户空间和控制权。
最重要的是：
不要让AI取代编辑器。让AI理解编辑器。
这正是AI驱动的页面构建器真正强大的地方。