1. 为什么让 AI 硬写这条路越来越走不通过去一年我接触了不少 Agent 项目从内部工具到面向用户的产品都有。一个非常普遍的现象是大家一开始都倾向于让大模型直接输出最终产物——直接写代码、直接生成页面、直接产出配置。刚开始 demo 阶段看着很惊艳一旦进入真实场景问题就集中爆发了。最典型的症状是输出不稳定。同一个需求今天生成的代码能跑明天换个措辞就崩了。你让模型生成一个带分页的表格它可能给你三种完全不同的实现字段命名、事件绑定、样式结构全都不一样。这不是模型不行而是让模型同时承担理解意图和精确构造两件事本身就超出了它擅长的范围。我在一个内部工具项目里踩过这个坑。当时的需求是根据用户描述生成数据看板最初方案是让模型直接吐 HTML JS。结果就是稍微复杂一点的图表配置模型就开始编造不存在的 API布局稍微嵌套深一点标签闭合就出错。每次出错都要重新调 prompt调完这个场景好了另一个场景又坏了。这种打地鼠式的调试本质上是因为我们把结构正确性这件事完全押在了模型的自由发挥上。后来我们换了个思路不让模型直接写最终产物而是让它生成一个中间表示IR再由确定性的渲染层把 IR 转成最终产物。这一下子就把问题拆开了——模型只负责它最擅长的理解 决策而精确构造交给代码。这就是标题里说的可视化生成方案的核心思路也是 IR 和 SDK 这两个词频繁出现在热搜里的原因。这篇文章我想把这条路线讲透为什么 IR 是关键、可视化生成到底怎么落地、SDK 在其中扮演什么角色、以及我在实操中总结的那些坑。不管你是刚接触 Agent 开发还是已经在做生成式产品应该都能从中拿到能直接用的东西。2. 把生成拆成两段IR 才是那个真正的中间层2.1 直接生成 vs 中间表示一次直观的对比先把这个核心概念说清楚。所谓 IRIntermediate Representation中间表示你可以理解成一份结构化的、机器可校验的施工图纸。模型不直接盖房子而是先画图纸画完图纸后由一套确定性的程序按图纸施工。我用一个具体例子对比一下。假设需求是生成一个用户信息卡片包含头像、姓名、邮箱和一个编辑按钮。直接生成路线模型输出的是最终 HTMLdiv classcard img src{{avatar}} / h3{{name}}/h3 p{{email}}/p button onclickedit()编辑/button /div看着没问题但问题在于这个 HTML 的结构、类名、事件绑定方式每次生成都可能不一样。你想统一改个样式得去改 prompt你想加个字段校验得重新生成。而且模型偶尔会漏掉闭合标签、写错属性名这些错误在文本层面很难被及时发现。IR 路线模型输出的是这样一份结构化数据{ type: Card, props: { padding: md, shadow: true }, children: [ { type: Avatar, props: { src: {{avatar}}, size: lg } }, { type: Text, props: { value: {{name}}, variant: title } }, { type: Text, props: { value: {{email}}, variant: body } }, { type: Button, props: { label: 编辑, action: edit } } ] }这份 IR 有几个关键好处。第一它是可校验的——你可以用 JSON Schema 直接验证字段类型、必填项、枚举值模型写错了立刻能发现。第二它是可组合的——Card 里能放任何合法子节点组合逻辑由渲染层保证。第三它是可复用的——同一份 IR 可以渲染成 Web、移动端、甚至导出成设计稿只要渲染层不同。2.2 为什么 IR 能显著提升稳定性这里有个很多人没意识到的点模型的自由度和稳定性是此消彼长的。你让它自由发挥写 HTML它能表达的东西很多但出错空间也大你把它约束在一个有限的组件集合和属性集合里它的表达空间小了但每一步都在你的掌控之内。IR 的本质就是给模型划定一个受控的表达空间。这个空间里所有合法的节点类型、属性、嵌套规则都是预先定义好的。模型要做的不是创造语法而是在给定语法里做选择。这跟让一个人写文章和让他做选择题的区别是一样的——选择题的正确率天然更高。我在项目里做过一个粗略统计同一个需求直接生成 HTML 的一次通过率大概在 60% 左右而生成 IR 的一次通过率能到 90% 以上。剩下的 10% 里大部分是语义理解偏差比如把编辑理解成了删除而不是结构错误。结构错误基本被 IR 的校验层挡在了外面。2.3 IR 的粒度设计太粗和太细都是坑设计 IR 的时候粒度是个关键决策。我见过两种极端。一种是粒度过粗比如 IR 里只有一个type: Page然后所有内容塞在一个html字符串字段里。这等于没做抽象模型还是在自由写 HTML校验层也帮不上忙。另一种是粒度过细把每个像素、每个样式属性都拆成独立字段。结果 IR 变得极其冗长模型生成时容易顾此失彼而且维护成本高得离谱。我的经验是IR 的粒度应该对齐业务语义单元。也就是说一个节点应该对应一个用户能理解、产品能复用的概念——按钮、表单、图表、列表。而不是对齐 DOM 节点或 CSS 属性。这样模型生成时是在搭积木而不是在描像素。具体到实践我一般会先梳理出这个产品里高频出现的 20 到 30 个组件把它们定义成 IR 的节点类型然后给每个类型定义清晰的属性 schema。这个集合不用一开始就很全够用就行后续按需扩展。3. 可视化生成方案的完整链路拆解3.1 从用户意图到 IR模型这一层到底该做什么整条链路的第一段是把用户的自然语言意图转成 IR。这一步模型要做的事情其实比想象中要聚焦识别意图、选择组件、填充属性、组织层级。我通常会把这一步拆成两个子步骤而不是让模型一步到位。第一步是意图解析把用户的话转成一个结构化的需求描述比如用户想要一个展示个人信息的卡片包含头像、姓名、邮箱和编辑入口。第二步才是IR 生成根据这个需求描述去选择组件、组装结构。为什么要拆因为一步到位的时候模型容易在理解和构造之间来回跳跃导致理解还没到位就开始拼结构。拆开之后每一步的输入输出都很明确出错也容易定位——是理解错了还是构造错了。在 prompt 设计上我有个很实用的技巧把 IR 的 schema 直接作为约束喂给模型并且给出 2 到 3 个完整的示例。示例比规则管用得多模型看几个输入需求 → 输出 IR的样例比读一大段 schema 说明要准得多。同时我会明确告诉模型只输出 JSON不要输出任何解释文字。这一条能省掉大量后处理工作。3.2 校验层把模型的错误挡在渲染之前IR 生成出来之后绝对不能直接扔给渲染层。中间必须有一道校验层这是整个方案稳定性的关键保障。校验层要做的事情包括结构校验JSON 是否合法、必填字段是否齐全、类型校验属性值是否符合 schema 定义的类型和枚举、语义校验引用的数据字段是否存在、组件嵌套是否合法。我一般用 JSON Schema 做前两层用自定义的校验函数做第三层。比如一个Chart组件它的dataSource字段必须指向一个已注册的数据源这个用 schema 表达不了得写代码校验。校验失败的时候怎么办这里有个很重要的设计选择不要让模型重新生成整个 IR而是把校验错误信息回传给模型让它只修复出错的部分。我实测下来这种局部修复的成功率远高于整体重生成而且省 token。错误信息要写得具体比如节点 children[2] 的 type 为 Buton不是合法组件类型合法类型包括 Button、Input、Text 等模型看到这种信息基本一次就能改对。3.3 渲染层确定性代码接管精确构造校验通过的 IR交给渲染层。渲染层是一套完全确定性的代码它接收 IR输出最终产物。这套代码里没有任何模型参与所以它的行为是完全可预测的。渲染层的实现方式取决于你的目标产物。如果目标是 Web 页面渲染层就是一套组件库加一个递归渲染函数如果目标是移动端渲染层就是对应的原生组件映射如果目标是设计稿渲染层就是一套导出逻辑。我特别想强调一点渲染层和 IR 的 schema 必须严格对齐。IR 里定义了哪些组件类型渲染层就必须实现哪些IR 里定义了哪些属性渲染层就必须处理哪些。这个对齐关系最好用类型系统来保证比如用 TypeScript 定义 IR 的类型渲染层的组件 props 直接引用这些类型编译期就能发现不一致。3.4 一条完整的链路示例把上面几段串起来一个完整的流程是这样的用户输入帮我做一个商品列表每个商品显示图片、名称、价格和加入购物车按钮意图解析模型输出结构化需求描述IR 生成模型输出符合 schema 的 IR JSON校验层验证 IR通过则进入下一步不通过则回传错误让模型修复渲染层把 IR 转成最终页面用户看到结果可以继续用自然语言调整调整同样走 IR 这条路这条链路里模型只在第 2、3 步参与而且每一步的职责都很单一。这就是别再让 AI 硬写的真正含义——不是不用 AI而是把 AI 放在它该在的位置上。4. SDK 在可视化生成里的角色与选型思路4.1 SDK 到底解决什么问题热搜里 SDK 这个词出现频率很高但很多人对它在 Agent 可视化生成里的定位是模糊的。我的理解是SDK 是把IR 校验 渲染这套能力封装成可复用、可分发的东西。如果没有 SDK你每做一个新项目都要重新定义 IR、重新写校验、重新实现渲染。有了 SDK这些能力就是现成的你只需要关注业务层的组件扩展和 prompt 调优。一个成熟的可视化生成 SDK通常包含这几块IR 的 schema 定义和类型、校验器、渲染器、组件注册机制、以及和模型交互的适配层。组件注册机制尤其重要它决定了你能不能方便地扩展自己的业务组件。4.2 自研还是用现成的我的判断标准这个问题我被问过很多次。我的判断标准其实很简单看你的组件体系是不是标准的。如果你做的是通用场景比如通用的表单、表格、图表那用现成的 SDK 完全够用能省下大量时间。但如果你做的是垂直领域比如工业控制界面、医疗数据看板组件体系高度定制那现成 SDK 的组件库大概率不够用你还是要自己扩展这时候自研一套轻量的 IR 渲染层可能更划算。我自己的做法是混合底层的 IR 定义、校验框架、渲染调度用现成的或者开源的业务组件自己实现。这样既拿到了基础设施的稳定性又保留了业务灵活性。选型的时候我会重点看几个指标schema 是否支持扩展、渲染层是否支持自定义组件、是否有类型定义、社区活跃度。前两个决定了你能不能落地后两个决定了你踩坑时有没有人帮你。4.3 组件注册SDK 里最容易被低估的机制组件注册机制是我认为 SDK 里最值得花时间研究的部分。它决定了从 IR 到最终产物这一步的映射关系怎么建立。好的注册机制应该支持按类型注册type 为 Button 的节点用哪个组件渲染、属性映射IR 里的 props 怎么转成组件的实际 props、插槽处理children 怎么渲染到组件的对应位置、事件绑定IR 里的 action 怎么接到实际的处理函数。我踩过的一个坑是早期我们的注册机制只支持按类型注册不支持属性映射导致 IR 里的属性名必须和组件 props 完全一致。后来业务组件多了命名风格不统一就非常痛苦。加上属性映射层之后IR 可以用一套统一的命名规范组件那边保持自己的风格中间做转换灵活多了。5. 实操中真正会卡住你的几个地方5.1 模型对 IR schema 的记忆问题这是我在多个项目里反复遇到的头号问题。当 IR 的组件类型和属性多起来之后模型开始记不住——它会编造不存在的属性或者把两个相似组件的属性搞混。我的应对策略有三条。第一控制单次生成涉及的组件数量。如果一次生成要用到 30 个组件模型出错概率会飙升。我会在意图解析阶段就判断这个需求涉及哪些组件只把相关的 schema 片段喂给模型而不是把整个 schema 都塞进去。第二用 few-shot 示例覆盖高频组合。把产品里最常见的几种页面结构做成示例模型照着套准确率会高很多。第三给属性加约束提示。比如某个属性只接受特定枚举值我会在 schema 描述里明确写出来而不是只靠类型定义。模型对自然语言描述比纯类型定义更敏感。5.2 校验错误回传的信息量陷阱前面提到校验失败要回传错误让模型修复但这里有个陷阱错误信息太少模型改不对错误信息太多模型被淹没。我一开始的做法是把所有校验错误一次性回传结果模型面对十几条错误时经常顾此失彼改了这个忘了那个。后来改成按优先级排序只回传最关键的 3 条并且明确告诉模型先修复这几条。修复一轮之后再校验如果还有错再回传下一批。这种分批修复的策略实测成功率比一次性回传高不少。另外错误信息里最好带上上下文。比如不要只说children[2] 类型非法而要说children[2] 是 Card 节点的第三个子节点其 type 为 Buton不是合法类型。带上路径和父节点信息模型定位问题会快很多。5.3 渲染层的兜底设计渲染层虽然接收的是校验过的 IR但永远不要假设 IR 一定完美。我在渲染层里加了一层兜底逻辑遇到无法识别的组件类型渲染成一个占位符并记录日志而不是直接抛异常导致整个页面白屏。这个兜底设计救过我好几次。有一次线上出现了一个 schema 里没定义但模型生成的组件类型因为兜底逻辑页面只是那一块显示异常其他部分正常用户几乎没感知。如果没有兜底整个页面就崩了。兜底逻辑还要配合监控。占位符出现的时候要上报这样你能及时发现是 schema 漏了定义还是模型在乱生成然后针对性修复。5.4 迭代时的回归问题可视化生成方案上线之后你会不断调整 prompt、扩展组件、修改 schema。每次调整都可能影响已有的生成效果这就是回归问题。我的做法是建一套回归测试集。把产品里高频的需求场景整理成测试用例每次改动之后跑一遍看 IR 生成的成功率和正确率有没有下降。这套测试集不用很大二三十个典型场景就够但能帮你挡住大部分改一处坏一片的问题。测试集的评估标准我一般分三档结构正确IR 能通过校验、语义正确组件选择和属性填充符合预期、渲染正确最终产物符合预期。前两档可以自动化第三档需要人工抽查。6. 关于 Agent 扛并发与架构的一点实战体会热搜里ai agent 怎么扛并发这个问题在可视化生成场景里其实有很具体的答案。因为整条链路被拆成了模型生成 IR和确定性渲染两段并发压力主要落在模型调用这一段而渲染是纯计算扩展起来很容易。我的做法是模型调用层做队列和限流渲染层做水平扩展。模型调用是瓶颈所以要控制并发数超出部分排队渲染层是无状态的加机器就能扛。这种拆分让整个系统的容量规划变得清晰——你只需要关注模型调用的 QPS渲染层按需扩容就行。另外IR 这一层天然适合缓存。相同的用户意图往往对应相同的 IR把意图 → IR的映射缓存起来能省掉大量重复的模型调用。缓存 key 可以用意图描述的哈希命中率在真实场景里通常不低。架构上我倾向于把 IR 生成做成独立的服务和渲染服务解耦。这样模型升级、prompt 调整都不影响渲染渲染层的扩容也不影响模型调用。两边的迭代节奏可以完全独立这对快速迭代的产品来说非常重要。7. 我在实际项目里沉淀下来的几条经验做了几个 Agent 可视化生成项目之后有几条经验是我觉得最值得分享的。第一IR 的设计要面向未来。你现在的组件集合可能只有十几个但产品一定会扩展。IR 的 schema 要预留扩展空间比如属性里留一个extra字段放非标准配置节点类型支持自定义扩展。我见过太多项目因为 IR 设计得太死后期扩展时不得不推倒重来。第二模型的能力边界要摸清楚。不同模型对结构化输出的支持程度差别很大。有的模型天生擅长输出 JSON有的需要大量示例才能稳定。选模型的时候不要只看通用能力要专门测它在你的 IR schema 上的表现。我一般会准备一组测试用例横向对比几个候选模型选那个在你的场景下最稳的。第三可视化不是终点可编辑才是。用户看到生成结果之后大概率会想调整。如果每次调整都要重新走一遍模型体验会很差。我的做法是让用户可以直接在 IR 层面编辑——拖拽、改属性、调顺序这些操作直接改 IR然后重新渲染。模型只在从零生成和大改的时候参与微调交给用户手动完成。这样既保证了灵活性又降低了模型调用成本。第四日志和可观测性要从第一天就做。IR 生成、校验、渲染每一步都要有日志记录输入、输出、耗时、错误。出问题的时候你能快速定位是模型理解错了、校验拦错了、还是渲染实现有 bug。没有这套日志排查问题基本靠猜。最后说个我自己的体会可视化生成方案的价值不在于让 AI 更聪明而在于让 AI 更可控。把模型的自由发挥约束在一个结构化的框架里用确定性的代码兜住精确构造的部分这才是让生成式产品真正能上生产的关键。那些还在让 AI 硬写最终产物的项目早晚会走到我当年踩过的那个坑里。早点把 IR 这一层加上后面会省太多事。