拆解 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而是输出能力从低到高分层层级输出形态适合场景用户行为主要成本L1Plain Text简单问答、短回复读结构弱L2Markdown报告、说明、PRD、代码解释读、复制、评论交互弱L3HTML / Web View可视化报告、轻量交互页点击、筛选、展开安全和一致性治理L4UI DSL / Component TreeAgent Workspace、任务流、数据分析台操作、回传、驱动下一步需要协议、组件体系和权限模型不同层级可以长期共存。一个 Agent 产品里解释性文本继续用 Markdown数据探索区用组件树复杂详情页最终渲染成 HTML高风险操作需要后端权限校验。没有必要为了统一格式把所有输出都塞进 UI DSL。头部产品用的是同一种思路很多成熟产品看起来形态不一样底层思路接近模型输出结构化结果前端把它变成可操作界面。产品形态模型更像在输出什么前端负责什么如果只用 Markdown 会卡在哪里搜索问答卡片答案块、引用源、相关问题卡片布局、引用跳转、折叠展开引用只能变成普通列表文档编辑器 AIBlock 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执行动作、记录状态、回传结果让模型绕过审计直接操作这样做的好处是模型能力变强时产品可以放宽协议模型出错时系统仍然有护栏。结语Markdown 不会因为 Agent 产品出现就过时。它仍然是 AI 内容输出里最便宜、最稳、最通用的一层。HTML 也不会凭空一统天下。它适合承载交互但模型裸写 HTML 不是一个让人放心的长期方案。真正值得投入的是 ​UI Output Protocol​一套让模型表达界面意图、让系统校验边界、让前端稳定渲染的协议。它不追求让模型变成前端工程师而是让模型说清楚这里应该是什么、用户能做什么、动作要交给谁执行。Agent 产品往深处走输出就会从文本变成工作台。到那时格式选择只是表层问题​协议设计才是工程问题​。推荐阅读GEPA 架构拆解让 Prompt 和 Skill 优化不靠玄学Agent Workflow Runtime 架构拆解把 Agent Loop 从提示词搬进代码长任务才真正稳了Google AX 控制面拆解分布式 Agent 如何把断点恢复、审计策略和执行调度收进同一条链路AI Native 竞争力真正稀缺的不是会用 AI而是把事往前推的人Harness EngineeringAgent 真正能交付靠的不是更强模型而是上下文、执行协议和验收闸门