拆解 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"，而是输出能力从低到高分层：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一个可落地的分层方案

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

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

每一层的职责要硬切开：

这样做的好处是，模型能力变强时，产品可以放宽协议；模型出错时，系统仍然有护栏。

结语

Markdown 不会因为 Agent 产品出现就过时。它仍然是 AI 内容输出里最便宜、最稳、最通用的一层。

HTML 也不会凭空"一统天下"。它适合承载交互，但模型裸写 HTML 不是一个让人放心的长期方案。

真正值得投入的是 ​UI Output Protocol​：一套让模型表达界面意图、让系统校验边界、让前端稳定渲染的协议。它不追求让模型变成前端工程师，而是让模型说清楚"这里应该是什么、用户能做什么、动作要交给谁执行"。

Agent 产品往深处走，输出就会从文本变成工作台。到那时，格式选择只是表层问题；​协议设计，才是工程问题​。

推荐阅读

GEPA 架构拆解：让 Prompt 和 Skill 优化不靠玄学

Agent Workflow Runtime 架构拆解：把 Agent Loop 从提示词搬进代码，长任务才真正稳了

Google AX 控制面拆解：分布式 Agent 如何把断点恢复、审计策略和执行调度收进同一条链路

AI Native 竞争力：真正稀缺的不是会用 AI，而是把事往前推的人

Harness Engineering：Agent 真正能交付，靠的不是更强模型，而是上下文、执行协议和验收闸门