企业官网建设流程全解析

1. 从"让AI硬写"到"让AI画图"：Agent可视化生成到底在解决什么问题

如果你最近半年在折腾 Agent 相关的项目，大概率会遇到一个很尴尬的场景：你让模型直接输出一段结构化的东西——工作流、状态机、UI 布局、数据管道——它确实能吐出来，但吐出来的东西要么字段对不上，要么层级乱套，要么改一个地方整个结构崩掉。你反复调 prompt，加 few-shot，甚至上微调，结果还是"看起来对，跑起来错"。

这就是"AI 硬写"的典型困境。所谓硬写，就是让语言模型直接生成最终产物（一段 JSON、一份配置、一棵组件树），中间没有任何中间表示层做缓冲。模型在生成过程中没有结构约束，全靠概率一步步往下猜，token 一多，误差就累积，最后产出一个"语法合法但语义离谱"的东西。

Agent 可视化生成方案的核心思路，是把"生成"这件事拆成两段：第一段让模型生成一个中间表示（IR，Intermediate Representation），第二段由一个确定性的渲染器/编译器把 IR 转成最终产物。模型只负责它擅长的部分——理解意图、做决策、填语义；结构正确性、引用完整性、布局计算这些交给代码。这就是标题里"别再让 AI 硬写"的真正含义。

这套思路并不是新发明。编译器领域几十年前就这么干了：源码 → 抽象语法树（AST）→ 中间代码 → 目标代码。前端框架也是这个套路：JSX → 虚拟 DOM → 真实 DOM。Agent 可视化生成无非是把这套成熟范式搬到了 AI 生成场景里。关键词里出现的 IR、DSL、SDK，其实正好对应了这条链路上的三个关键角色：IR 是中间表示，DSL 是给模型用的领域特定语言，SDK 是把这套能力封装给业务方调用的工具包。

这篇文章适合三类人看：一是正在做 Agent 产品、被"生成结果不稳定"折磨的开发者；二是想给自己的工具链加一层可视化生成能力的技术负责人；三是对 Agent 架构感兴趣、想搞清楚"为什么有些 Agent 输出就是比别人稳"的学习者。我会从 IR 的设计、DSL 的取舍、SDK 的封装、以及实际落地时的坑，一层层拆开讲。

2. 为什么中间表示层是稳定性的分水岭

2.1 直接生成最终产物的误差累积问题

先做个思想实验。假设你要让模型生成一个包含 20 个节点的审批流，每个节点有 id、类型、入参、出参、下一跳。如果直接生成最终 JSON，模型需要同时保证：20 个 id 全局唯一、每个 next 指向的 id 真实存在、每个节点的入参类型和上游出参匹配、整体无环（或者有环但符合业务预期）。这些约束在生成第 1 个 token 的时候就已经存在了，但模型是自回归的，它生成第 18 个节点时，早就"忘了"第 3 个节点定义了哪些出参。

实测下来，20 个节点规模的工作流，直接生成 JSON 的一次通过率大概在 30% 到 50% 之间，节点越多越低。而且失败模式很隐蔽——不是语法错误，是引用错误，你光看 JSON 结构完全看不出来，得跑起来才发现某个 next 指向了不存在的节点。

中间表示层的作用，就是把这些约束从"模型脑子里"挪到"代码里"。模型生成 IR 的时候，只需要保证局部正确；全局约束由 IR 到最终产物的转换器来校验和修复。

2.2 IR 应该长什么样：三个设计原则

IR 的设计没有标准答案，但有三条原则我踩过坑之后觉得必须遵守。

第一，IR 要足够"扁平"，减少嵌套。嵌套结构对模型极不友好，因为模型生成嵌套时需要在脑子里维护一个栈，深度一超过 3 层就开始出错。我见过有人设计了一个五层嵌套的 IR，模型生成到第三层就开始丢括号。更好的做法是把树拍平成"节点列表 + 边列表"，模型只需要生成一堆平铺的条目，层级关系用 id 引用表达。

第二，IR 的字段要"自解释"，不要依赖位置。有些 IR 设计成数组，靠下标表达语义，比如[type, name, params]。这种设计对人来说紧凑，对模型来说是灾难，因为它得记住"第 0 位是类型"。改成对象{"type": "...", "name": "...", "params": {...}}，模型生成准确率会明显提升，因为每个字段名本身就是提示。

第三，IR 要允许"部分生成"。真实场景里，用户的需求往往是模糊的，模型不可能一次生成完整 IR。好的 IR 设计应该支持增量填充——先生成骨架，再逐个节点补细节，每一步都可以单独校验。这对应到 Agent 架构上，就是"规划"和"执行"分离：规划阶段生成节点列表，执行阶段填充每个节点的参数。

2.3 一个可落地的 IR 示例

拿一个"数据看板生成"的场景举例。用户说"给我做一个销售看板，上面有总销售额、月度趋势、Top 10 商品"。直接生成前端代码肯定崩，但生成 IR 就很稳：

{ "version": "1.0", "layout": "grid", "widgets": [ {"id": "w1", "type": "metric", "title": "总销售额", "source": "sales.total"}, {"id": "w2", "type": "line", "title": "月度趋势", "source": "sales.by_month", "x": "month", "y": "amount"}, {"id": "w3", "type": "bar", "title": "Top 10 商品", "source": "sales.top_products", "limit": 10} ] }

这个 IR 里，模型只需要决定"放哪几个组件、每个组件绑哪个数据源"，至于组件怎么渲染、数据源怎么查、布局怎么算，全是渲染器的事。模型的工作量从"写一个看板"降到了"填三个字段"，稳定性自然上来了。

提示：IR 的 version 字段别省。你后面一定会改 IR 结构，没有版本号的话，老数据迁移会让你痛不欲生。

3. DSL 的取舍：给模型用的语言和给人用的语言不是一回事

3.1 DSL 和 IR 的区别，很多人搞混

经常有人把 DSL 和 IR 混着说，其实它俩是不同层次的东西。IR 是"系统内部的数据结构"，DSL 是"暴露给模型或用户的书写语法"。IR 是 JSON 对象，DSL 可能是metric("总销售额", source="sales.total")这样的函数调用，也可能是 YAML，甚至是一段自然语言模板。

为什么要多一层 DSL？因为模型对不同的书写形式敏感度差异很大。同一个语义，用 JSON 表达和用类 SQL 表达，模型的生成准确率能差 20 个百分点。DSL 的价值就是找到"模型最容易生成正确"的那种表达形式。

3.2 三种 DSL 形态的实测对比

我拿同一个"生成数据查询"的任务，试过三种 DSL 形态，结果挺有意思：

函数式和类 SQL 明显优于纯 JSON。原因在于：函数式和 SQL 有"语法惯性"，模型在预训练阶段见过海量类似结构，生成时更容易沿着熟悉的模式走。而 JSON 的括号和引号对模型来说是纯负担，多一层嵌套就多一份出错概率。

但类 SQL 有个问题：表达能力受限，遇到复杂逻辑（比如条件分支、循环）就不好表达。函数式 DSL 在这点上更灵活，可以嵌套、可以组合。所以我的建议是：查询类任务用类 SQL，编排类任务用函数式，配置类任务用 YAML。

3.3 DSL 设计里最容易犯的错：追求"完备"

新手设计 DSL 时，总想一步到位，把所有可能的操作都定义成语法。结果 DSL 变得极其庞大，模型反而学不会。我见过一个 DSL 定义了 80 多个关键字，模型生成时经常把关键字拼错或者用错。

正确的做法是"最小可用集"。先定义 10 到 15 个核心操作，覆盖 80% 的场景，剩下的用"通用扩展"兜底。比如定义一个custom(op, params)作为逃生舱，模型遇到没见过的需求就往这里塞。等实际使用中某个 custom 模式反复出现，再把它提升为正式语法。

注意：DSL 的报错信息一定要写清楚。模型生成错了之后，如果你能把错误信息回灌给它，它往往能自己修。但前提是错误信息得是"人话"，比如"字段 amount 不存在，可用字段有：price, quantity, total"，而不是"ParseError at line 3"。

4. SDK 封装：把可视化生成能力变成别人能用的东西

4.1 SDK 要解决的核心问题：让调用方不关心 IR

前面讲的 IR 和 DSL，都是"内部实现"。真正交付给业务方的时候，他们不应该看到这些。业务方想要的是一行调用：generateDashboard("销售看板")，然后拿到一个能渲染的东西。SDK 的职责就是把这层复杂度包起来。

一个合格的 Agent 可视化生成 SDK，对外暴露的接口应该极简，对内则要处理一堆脏活：prompt 组装、模型调用、IR 校验、错误重试、渲染器调度、缓存。这些脏活如果让业务方自己做，那 SDK 就没有存在意义。

4.2 SDK 的接口设计：三个层次

我倾向于把 SDK 设计成三个层次，对应不同的使用深度：

第一层，一键生成。sdk.generate(intent)直接返回最终产物。适合 90% 的简单场景，业务方不需要懂 IR。

第二层，分步控制。sdk.plan(intent)返回 IR，业务方可以修改 IR 后再sdk.render(ir)。适合需要人工干预的场景，比如让用户确认一下再渲染。

第三层，底层原语。暴露 DSL 解析器、IR 校验器、渲染器，让高级用户自己组装。适合需要深度定制的团队。

这三层不是互斥的，而是同一套内核的不同封装。内核只有一份，接口按需暴露。

4.3 一个 SDK 调用的完整链路

拿"生成一个表单"举例，走一遍完整链路：

from agent_viz import VizSDK sdk = VizSDK(model="your-model", renderer="react") # 第一层：一键生成 result = sdk.generate("做一个用户注册表单，包含用户名、邮箱、密码、确认密码") # result.component 是可直接渲染的组件描述 # result.ir 是中间表示，方便调试 # 第二层：分步控制 ir = sdk.plan("做一个用户注册表单") ir.widgets.append({"id": "w5", "type": "checkbox", "title": "同意协议"}) result = sdk.render(ir) # 第三层：底层原语 ast = sdk.dsl.parse("form { input(username); input(email) }") validated = sdk.ir.validate(ast) component = sdk.renderer.render(validated)

这条链路里，最容易被忽略的是result.ir的暴露。很多 SDK 只返回最终产物，业务方遇到问题时完全没法调试。把 IR 暴露出来，业务方就能看到"模型到底理解成了什么"，定位问题快很多。

4.4 SDK 的版本兼容：IR 演进的血泪教训

IR 一定会演进。今天你的 metric 组件只有 title 和 source，明天产品经理要加个"同比环比"，后天要加"下钻"。如果 IR 没有兼容策略，每次改动都会让老数据失效。

我的做法是：IR 只增字段，不改字段，不删字段。新字段给默认值，老数据读进来照样能渲染。真要废弃某个字段，先标记 deprecated，跑两个大版本再删。同时 IR 里带 version，渲染器根据 version 走不同的兼容分支。

这套策略听起来笨，但能省掉无数次数据迁移。我见过一个团队因为 IR 改字段没做兼容，导致线上几万个已保存的看板全部渲染失败，回滚都回滚不了。

5. 落地时真正会卡住你的几个坑

5.1 模型生成的 IR "语法对但语义错"

这是最常见的问题。模型生成的 IR 完全符合 schema，字段都在，类型也对，但语义是错的。比如用户要"月度趋势"，模型生成了{"type": "line", "source": "sales.by_month"}，看起来没问题，但sales.by_month这个数据源在系统里根本不存在。

这类错误的根因是：模型不知道你的系统里有哪些数据源。解决办法是在 prompt 里注入"可用资源清单"。但清单不能太长，太长会挤占上下文。我的做法是分层注入：先注入资源类别，模型选定类别后再注入该类别的具体资源。这样每轮注入的清单都很短，模型准确率反而更高。

5.2 渲染器和 IR 的"契约漂移"

IR 定义了字段，渲染器实现了字段，但两者经常对不齐。IR 说limit是数字，渲染器却按字符串处理；IR 说source必填，渲染器却给了默认值。这种漂移在早期不明显，项目一大就到处是坑。

解决办法是用同一份 schema 生成两边的校验代码。IR 的 schema 用 JSON Schema 或者 Zod 定义，然后自动生成模型侧的校验器和渲染器侧的解析器。这样只要 schema 不变，两边就不会漂移。schema 变了，两边同时重新生成，也不会漏。

5.3 增量生成的"上下文爆炸"

支持增量生成之后，每轮都要把已有的 IR 塞回 prompt，让模型在此基础上修改。IR 一大，prompt 就爆。我试过一个 50 节点的看板，IR 序列化后 8000 多 token，加上系统提示和资源清单，直接超了上下文窗口。

解法有两个：一是只回灌相关部分，用户要改哪个组件，就只把那个组件和它的邻居塞回去；二是用 diff 而不是全量，让模型输出"在 w3 后面插入 w4"这样的操作指令，而不是重新生成整个 IR。第二种更优雅，但要求模型有较强的指令遵循能力，实测下来用能力强的模型效果不错。

5.4 可视化生成的"最后一公里"：用户不信任

技术上跑通了，产品上还有一关：用户不信任 AI 生成的东西。你给他生成一个看板，他第一反应是"这数据对吗"，然后手动核对每一个数字。

这一关的解法不是技术，是交互。我的经验是：生成结果要可解释、可追溯、可回退。可解释，就是告诉用户"这个组件绑的是 sales.total 数据源"；可追溯，就是用户点一下能看到原始意图和 IR；可回退，就是用户能一键回到生成前的状态。做到这三点，用户的信任度会明显提升。

6. 从"能生成"到"生成得好"：几个进阶方向

6.1 用约束解码替代 prompt 约束

前面讲的都是"用 prompt 引导模型生成正确 IR"。更硬核的做法是约束解码：在模型生成每个 token 的时候，直接屏蔽掉不合法的 token。比如 IR 要求type字段只能是metric/line/bar三个值之一，那模型生成到type的值时，解码器直接把其他 token 的概率置零。

约束解码能把 IR 的语法正确率拉到接近 100%，代价是需要对模型推理过程做改造，工程成本不低。如果你的场景对稳定性要求极高，值得投入；如果只是内部工具，prompt 引导就够了。

6.2 IR 的"语义校验"层

语法校验只能保证 IR 结构对，语义校验才能保证 IR 有意义。语义校验包括：引用的数据源是否存在、组件之间的依赖是否有环、参数类型是否匹配、必填项是否齐全。这一层用普通代码写就行，不需要模型参与。

我建议把语义校验做成"可插拔"的。不同业务方的校验规则不一样，SDK 提供默认校验器，业务方可以注册自己的校验器。这样 SDK 保持通用，业务方保持灵活。

6.3 生成结果的"缓存与复用"

很多生成请求是重复的。用户 A 要"销售看板"，用户 B 也要"销售看板"，两次生成的 IR 大概率高度相似。如果每次都调模型，成本高、延迟大。

做法是建一个"意图到 IR"的缓存。用户意图先做归一化（去停用词、同义词替换），然后查缓存。命中就直接返回，没命中再调模型，调完把结果写回缓存。实测下来，企业内部工具的缓存命中率能到 40% 以上，省下的模型调用成本相当可观。

6.4 多模态输入的接入

现在很多场景用户不是打字，而是上传一张截图说"照这个做"。这时候 IR 的生成就要接入视觉模型。视觉模型先理解截图里的布局和组件，转成一个"视觉 IR"，再和文本意图融合，生成最终的"逻辑 IR"。

这一步的难点在于视觉 IR 和逻辑 IR 的对齐。截图里有个"看起来像折线图"的东西，视觉 IR 标成 line，但用户实际想要的是面积图。这种歧义只能靠交互澄清，不能靠模型猜。所以多模态场景下，生成流程里一定要留一个"确认"环节。

7. 我在这套方案上踩过的几个真实坑

第一个坑是过早优化 IR。项目初期我就想把 IR 设计得很完备，支持各种组件、各种布局、各种交互。结果 IR 复杂到模型根本学不会，生成准确率还不如直接用 JSON。后来砍到只剩 5 种组件、2 种布局，准确率立刻上来了。IR 是长出来的，不是设计出来的。

第二个坑是忽略渲染器的性能。IR 生成得再快，渲染器慢也没用。我遇到过一个看板 IR 只有 20 个组件，但渲染出来要 3 秒，因为每个组件都独立请求数据。后来改成批量请求 + 增量渲染，降到 300 毫秒。可视化生成是个端到端的事，任何一环慢都会拖垮体验。

第三个坑是没有给模型"退路"。早期设计 DSL 时，我没留custom逃生舱，模型遇到没见过的需求只能硬编，结果生成一堆非法语法。加了逃生舱之后，模型遇到不确定的情况会主动用 custom，虽然需要人工兜底，但至少不会崩。

第四个坑是低估了 prompt 的维护成本。prompt 不是写一次就完事的，IR 改了要改 prompt，DSL 改了要改 prompt，资源清单变了要改 prompt。后来我把 prompt 模板化，用变量注入，改起来才轻松点。如果你打算长期维护这套东西，prompt 的工程化要趁早做。

8. 写在最后：可视化生成不是银弹

说了这么多，得泼盆冷水。Agent 可视化生成方案能显著提升稳定性，但它不是万能的。它适合"结构相对固定、组件可枚举"的场景，比如看板、表单、工作流、报表。如果你的场景是"完全开放式的创意生成"，比如让 AI 画一幅画、写一首诗，那 IR 这套东西反而会限制它。

判断标准很简单：如果你的最终产物有明确的 schema，那 IR 方案就值得上；如果没有，那就老老实实让模型自由发挥，别硬套。

另外，这套方案的收益是随规模增长的。你只生成一两个组件，直接让模型写可能更快；你要生成几百个组件、还要保证一致性，IR 方案的优势才体现出来。别为了架构而架构，先想清楚你的真实痛点是什么。

最后分享一个我自己的判断习惯：每次想引入新架构，我都会问自己"如果不用这套东西，最坏会怎样"。如果最坏结果只是"偶尔生成错，用户重试一下"，那可能不值得上 IR；如果最坏结果是"生成错导致线上事故"，那 IR 就是必需品。技术选型从来不是选最好的，是选最匹配你风险承受能力的。