UI Output Protocol 架构拆解：Markdown、HTML 和 UI DSL 如何分工-编程阁

拆解 AI 产品输出从文本到工作台的协议分层：Markdown 写文档，HTML 承载页面，UI DSL 接住操作。
原文链接：AI 小老六

导语

最近不少 AI 产品开始把回答做得越来越"像页面"：有卡片、有筛选器、有图表，也有可点击操作。于是一个问题被反复拿出来讨论：HTML 会不会替代 Markdown？

这个问法容易把方向带偏。真正变化的不是某个标记语言赢了另一个，而是 AI 产品的输出对象变了。

早期 Chatbot 只需要把话说清楚，Markdown 已经够用；Agent 产品要把结果接到任务流里，用户不只看，还要点、筛、改、提交、回滚。到了这一步，产品需要的就不是"更强的文本格式"，而是一套模型和前端都能遵守的 UI Output Protocol。

图：AI 产品输出从可读文本，逐步走向可操作的任务工作台

Markdown、HTML、UI DSL 不是一条简单的替代链。它们更像三种不同层级的接口：Markdown 适合文档，HTML 适合页面，UI DSL 适合把模型意图变成受控组件。

先换个问题：模型到底在交付什么

如果用户问"帮我总结这篇文章"，模型交付的是内容。标题、列表、引用、表格，Markdown 很顺手。

如果用户问"帮我分析这组数据，异常项可以展开看，结论能一键生成工单"，模型交付的就不只是内容了。它还要表达信息层级、组件类型、操作入口、状态变化和下一步动作。

这两类需求放在一张表里，差别很明显：

维度	文档型输出	工作台型输出
用户目标	阅读、复制、转发	探索、筛选、操作、继续推进
内容结构	线性段落为主	多块信息并列，常有主从关系
状态管理	基本不需要	需要保存筛选、展开、选择和执行状态
系统风险	格式错了影响阅读	操作错了可能影响业务数据
前端职责	把文本渲染好	把结构映射成安全的可操作界面

所以，"HTML 会不会替代 Markdown"不是主问题。主问题是：当模型输出会进入产品流程时，用什么协议承接它，才能既灵活又可控。

Markdown：低摩擦，但天然偏静态

Markdown 的生命力很强，因为它足够简单。模型容易生成，人容易读，系统也容易存。报告、会议纪要、需求草稿、代码解释、PR 摘要，这些场景用 Markdown 反而更好。

它的优点很直接：

Token 成本低，模型生成稳定。
标题、列表、表格、代码块已经覆盖大多数线性表达。
可读性好，复制到文档、Issue、IM 里不太容易坏。
安全边界清楚，渲染器可以做严格白名单。

但 Markdown 的上限也清楚。它擅长"读"，不擅长"操作"。一旦用户想对结果继续筛选、展开、排序、局部刷新，Markdown 就只能靠链接、表格和文字说明硬撑。

Markdown 可以描述一个按钮，但不能自然地成为一个按钮。

HTML：交互能力强，但别让模型裸写页面

HTML 的优势在交互承载。Tab、折叠面板、表单、图表、局部刷新、响应式布局，这些能力本来就是前端页面的主场。

问题在于：让模型直接输出 HTML，工程上并不舒服。

稳定性不好：模型可能漏闭合标签，也可能把样式、数据和交互逻辑混在一起。
安全边界重：脚本、事件属性、外链资源、内联样式都要治理，否则 XSS 和数据泄露风险会冒出来。
设计系统会失控：每次回答都生成一套新 HTML，看起来灵活，长期会让产品视觉、交互和无障碍规范变成一锅粥。

所以在严肃产品里，HTML 更适合作为渲染层，而不是模型的直接输出目标。模型不该关心按钮圆角几像素，也不该自己拼一段随时可能越权的 DOM。它更适合交付结构和意图。

UI DSL：模型和前端之间的窄腰协议

UI DSL 可以理解成一份受控的界面描述。模型输出的不是最终页面，而是一棵组件树：这里是一张卡片，那里是一张表，某列可排序，某个按钮代表"创建工单"，某个筛选条件会回传给 Agent。

图：UI DSL 把模型意图收束为受控组件、数据引用和动作入口

一个很简化的例子可能长这样：

{"type":"dashboard","title":"异常订单分析","children":[{"type":"metricCard","title":"高风险订单","value":37,"action":{"type":"filter","payload":{"risk":"high"}}},{"type":"table","columns":["订单号","风险原因","负责人"],"dataRef":"risk_orders","actions":["openTicket","assignOwner"]}]}

这段 JSON 不负责视觉细节。它只告诉系统：该用什么组件、组件拿什么数据、用户能做什么动作。前端再把它映射到真实组件库里。

这就是 UI DSL 的价值：给模型留表达空间，但把它限制在产品允许的组件、字段和权限里。

图：模型生成结构和意图，平台校验边界，前端负责渲染和交互

这条链路里，模型负责内容和意图，平台负责校验和权限，前端负责渲染和交互。三者分清楚，系统才不会变成"模型想怎么画就怎么画"。

从文本到工作台：输出形态的演进不是替代

更合理的演进路径不是"Markdown -> HTML -> UI DSL"，而是输出能力从低到高分层：

层级	输出形态	适合场景	用户行为	主要成本
L1	Plain Text	简单问答、短回复	读	结构弱
L2	Markdown	报告、说明、PRD、代码解释	读、复制、评论	交互弱
L3	HTML / Web View	可视化报告、轻量交互页	点击、筛选、展开	安全和一致性治理
L4	UI DSL / Component Tree	Agent Workspace、任务流、数据分析台	操作、回传、驱动下一步	需要协议、组件体系和权限模型

不同层级可以长期共存。一个 Agent 产品里，解释性文本继续用 Markdown；数据探索区用组件树；复杂详情页最终渲染成 HTML；高风险操作需要后端权限校验。没有必要为了"统一格式"把所有输出都塞进 UI DSL。

头部产品用的是同一种思路

很多成熟产品看起来形态不一样，底层思路接近：模型输出结构化结果，前端把它变成可操作界面。

产品形态	模型更像在输出什么	前端负责什么	如果只用 Markdown 会卡在哪里
搜索问答卡片	答案块、引用源、相关问题	卡片布局、引用跳转、折叠展开	引用只能变成普通列表
文档编辑器 AI	Block Tree、表格、数据库字段	渲染成可编辑块，保持文档结构	用户要手动复制到正确位置
办公 Copilot	操作意图、数据范围、图表配置	在 Excel、PPT、BI 中执行	只能给文字建议，不能直接生成对象
Agent IDE	文件操作、Diff、命令、检查结果	展示可 Apply 的变更和验证状态	Diff 只能读，无法安全执行
自动化工作流	节点、边、条件、状态	渲染流程图并绑定后端执行	流程只能写成说明文档

这些产品并不是简单地让模型写 HTML。它们把输出拆成数据、组件、动作三部分，再由系统接管渲染和执行。

决策树：什么时候该用哪一层

可以用一个很简单的判断逻辑：

图：从阅读、复杂布局、继续操作和事件回传四个问题选择输出层级

再换成工程问题，就是下面这张表：

判断问题	更偏 Markdown	更偏 HTML / UI DSL
用户读完之后会不会继续操作	读完就走	还要筛选、点击、提交
内容会不会持续变化	一次性结果	会被刷新、编辑、追踪
信息结构是不是线性的	段落、列表、表格即可	多区域、多状态、多联动
是否需要系统权限控制	基本没有	操作会影响任务、数据或外部系统
是否需要和 Agent 继续对话	结果即终点	用户动作会触发下一轮推理

协议设计比组件数量更重要

做 UI DSL 时，很多团队第一反应是多定义组件：卡片、表格、图表、时间线、流程图、表单、地图、文件树。组件当然重要，但更难的是协议边界。

图：真正难的是在组件表达力、权限边界和运行时治理之间取得平衡

至少要提前定清楚这些事：

协议问题	如果不设计清楚
模型能输出哪些组件	组件爆炸，前端无法维护
每个组件有哪些必填字段	渲染时大量兜底，错误难定位
数据是内联还是引用	大对象塞进上下文，成本和泄露风险上升
用户事件如何命名	前端事件和 Agent 动作对不上
哪些动作需要权限确认	模型可能诱导执行高风险操作
Schema 校验失败怎么办	用户看到半成品界面
版本如何演进	老回答、老会话、老组件全部兼容困难

我的建议是先做窄。只开放少量稳定组件，比如card、table、chart、form、actionList。等产品场景跑通，再扩展组件库。

UI DSL 不是越像前端框架越好。越早变成通用前端框架，越难管。

一个可落地的分层方案

如果要在 Agent 产品里落这套机制，可以按四层拆：

图：Model Output、Protocol、Render、Runtime 四层形成可校验、可渲染、可审计的闭环

每一层的职责要硬切开：

层	负责什么	不该负责什么
Model Output	生成内容、结构和操作意图	直接写业务权限逻辑
Protocol	校验 Schema、过滤动作、处理版本	决定视觉样式
Render	映射组件、处理交互和布局	信任未经校验的模型输出
Runtime	执行动作、记录状态、回传结果	让模型绕过审计直接操作