引言

当 Anthropic Claude Code 团队开始系统性地使用 HTML 替代 Markdown 作为 Agent 输出格式时，一个更深层的问题浮出水面：如果 HTML 输出从个别实践演变为行业标准，大模型的训练体系需要做出哪些根本性调整？

这不是一个遥远的假设。随着 Agent 应用的普及，模型输出的消费方式正在从"人类阅读文本"转向"浏览器渲染页面"。这一转变将从评估指标、训练数据、对齐方法到底层 Tokenizer 等多个层面，对现有训练体系产生连锁影响。

一、评估指标的根本性变化

1.1 当前评估体系的局限

现有大模型的评估主要围绕文本质量展开：

• 准确性：回答是否正确
• 逻辑性：推理链是否连贯
• 流畅度：语言是否自然
• 有用性：是否解决了用户问题

这些指标在纯文本输出场景下是充分的。但当输出变为 HTML 时，一段"文本质量优秀"的输出可能在浏览器中渲染为一团混乱——布局错位、样式冲突、交互失效。

1.2 新增评估维度

HTML 输出模式下，评估体系需要扩展以下维度：

渲染正确性：生成的 HTML 在主流浏览器中是否能正确渲染，是否存在布局崩溃、元素重叠等问题。

视觉质量：页面的视觉呈现是否美观、专业，排版是否合理，色彩搭配是否协调。

交互正确性：JavaScript 逻辑是否能正常执行，按钮点击、表单提交、拖拽操作等是否按预期工作。

信息传递效率：相比纯文本，HTML 格式是否更有效地将信息传递给了人类用户。

响应式适配：在不同屏幕尺寸下是否保持可用性。

1.3 评估工具链的变革

这些新维度意味着评估 pipeline 需要集成全新的工具：

传统评估：Model Output → Text Metrics → Score

HTML 评估：Model Output → Browser Rendering Engine → Screenshot
                        → Visual Quality Model → Score
                        → Interaction Testing (Puppeteer/Playwright) → Score
                        → Accessibility Checker → Score
                        → Responsive Testing → Score
                        → 综合加权 → Final Score

评估一次模型输出的计算成本将显著上升。这对训练效率和成本控制提出了新的挑战。

二、训练数据的质量重新定义

2.1 互联网 HTML 的质量问题

大模型的预训练数据中本就包含海量 HTML——整个互联网的网页都是 HTML。但这些数据存在严重的质量问题：

• 历史遗留代码：大量 2000-2010 年代的 table 布局、内联样式、浏览器 hack
• 框架生成代码：Webpack/React 打包后的代码对人类和模型都不可读
• 低质量模板：WordPress 主题、Bootstrap 模板等高度同质化的代码
• 广告和追踪代码：大量与内容无关的第三方脚本

如果训练目标从"理解 HTML"转变为"生成高质量 HTML"，这些数据的价值需要重新评估。

2.2 高质量训练数据的特征

适合训练"HTML 生成能力"的数据应具备：

• 语义化标签：正确使用 header、nav、main、article 等语义元素
• 现代布局技术：CSS Grid、Flexbox 而非 float 和 table 布局
• 可访问性标注：ARIA 属性、合理的标题层级、键盘导航支持
• 响应式设计：媒体查询、相对单位、弹性布局
• 简洁高效：最少的代码实现最佳的效果

2.3 合成数据的必要性

满足上述标准的"自然"数据可能不足以支撑训练需求。这指向了合成数据的必要性：

方案一：任务驱动的合成

给定一个信息展示需求（如"展示一个项目的架构图"），由专业前端工程师编写最佳 HTML 实现，形成 (需求, HTML) 配对数据。

方案二：改写优化

取互联网上的低质量 HTML，由专家改写为高质量版本，形成 (低质量HTML, 高质量HTML) 配对数据，用于训练模型的"HTML 优化"能力。

方案三：设计稿到代码

收集设计稿（Figma、Sketch 导出）与对应的高质量前端实现，训练模型的"视觉到代码"能力。

三、对齐方法的适配

3.1 SFT 阶段的变化

监督微调（Supervised Fine-Tuning）阶段需要大量高质量的 (instruction, response) 配对。当 response 从文本变为 HTML 时：

标注员能力要求升级：

• 传统：具备良好的语言表达能力即可
• 新增：需要前端开发能力 + 设计审美 + 交互设计经验

标注成本上升：

• 编写一段高质量 HTML 的时间远超编写等价文本
• 验证 HTML 质量需要在浏览器中实际渲染和测试
• 可能需要前端工程师和设计师协同标注

标注工具链变化：

• 标注平台需要集成实时 HTML 预览
• 需要提供设计系统参考和组件库
• 需要自动化的代码质量检查（lint、格式化）

3.2 RLHF 阶段的变化

基于人类反馈的强化学习在 HTML 输出场景下面临新的挑战：

偏好对比的复杂度增加：

传统 RLHF：给标注员展示两段文本，选择更好的一段。判断时间通常在 30 秒以内。

HTML RLHF：给标注员展示两个渲染后的页面，需要：

1. 在浏览器中打开两个页面
2. 检查视觉效果
3. 测试交互功能
4. 在不同屏幕尺寸下查看
5. 做出偏好判断

单次判断时间可能从 30 秒上升到 5-10 分钟，标注效率大幅下降。

AI Judge 的必要性：

人工标注效率的下降使得 AI Judge（用另一个模型来评估输出质量）变得更加必要。一个可能的方案是：

Agent 生成 HTML → 渲染引擎截图 → 视觉质量评估模型打分
                → Playwright 执行交互测试 → 交互正确性评分
                → Lighthouse 审计 → 性能和可访问性评分
                → 综合 Reward Signal

这本质上是用一套自动化工具链替代人类标注员的部分判断工作。

3.3 Constitutional AI 的扩展

Anthropic 的 Constitutional AI 方法通过一组"宪法原则"来指导模型行为。在 HTML 输出场景下，这些原则需要扩展：

• “输出应当在所有主流浏览器中正确渲染”
• “交互元素应当有明确的视觉反馈”
• “页面应当在 3 秒内完成首次有意义渲染”
• “所有交互应当支持键盘操作”
• “色彩对比度应当满足 WCAG AA 标准”

四、Tokenizer 层面的优化空间

4.1 当前 Tokenizer 对 HTML 的低效编码

现有主流 Tokenizer（如 GPT-4 的 cl100k_base、Claude 的 Tokenizer）是在通用文本语料上训练的。对于 HTML 代码，存在明显的编码低效：

<div class="container flex items-center justify-between p-4">

这段常见的 HTML 可能被切分为 10+ 个 token，而其中的模式（<div class="、flex items-center）在 HTML 中出现频率极高。

4.2 优化方向

方向一：HTML 感知的 Tokenizer

在 Tokenizer 训练时增加 HTML 语料的权重，使常见 HTML 模式获得更短的编码：

• <div class=" → 1 token
• </div> → 1 token
• <script> → 1 token
• 常见 CSS 类名组合 → 1-2 tokens

方向二：分层 Tokenizer

对不同类型的内容使用不同的编码策略：

• 自然语言部分：使用标准 BPE
• HTML 标签部分：使用专用的 HTML token 词表
• CSS 部分：使用专用的 CSS token 词表

方向三：模板 Token

将常见的 HTML 结构模式作为"宏 token"：

[FLEX_CONTAINER] → <div class="flex items-center justify-between">
[GRID_2COL] → <div class="grid grid-cols-2 gap-4">
[CARD_WRAPPER] → <div class="rounded-lg shadow-md p-6 bg-white">

这类似于编程语言中的"代码片段"概念，但在 token 层面实现。

4.3 Token 效率的量化影响

假设通过 Tokenizer 优化，HTML 的平均 token 效率提升 30-40%：

• 生成同等复杂度的 HTML 页面，token 消耗从 2000 降至 1200-1400
• 推理成本相应下降
• 上下文窗口中可容纳更多 HTML 内容
• 生成速度提升（更少的 token 意味着更少的推理步骤）

这一优化的 ROI 可能非常显著，尤其是在 HTML 输出成为高频场景之后。

五、模型架构层面的可能演进

5.1 专用 HTML 生成模型

类似于代码生成领域出现了 Codex、DeepSeek-Coder、StarCoder 等专用模型，HTML 生成领域也可能出现专门优化的模型分支：

训练目标：给定信息需求和设计约束，生成最优的 HTML 实现

特殊能力：

• 理解设计系统约束并严格遵循
• 生成的代码天然具备响应式和可访问性
• 能够预判渲染效果并自我优化

应用场景：

• 作为通用模型的"HTML 输出头"（类似于多模态模型的视觉编码器）
• 独立部署为 UI 生成服务

5.2 多模态闭环训练

一个更激进的方向是将 HTML 生成纳入多模态训练闭环：

训练循环：
1. 模型生成 HTML
2. 渲染引擎将 HTML 渲染为图像
3. 视觉模型评估渲染效果
4. 评估结果作为 reward signal 反馈给生成模型
5. 模型调整生成策略

这本质上是将"前端工程师看到渲染效果后调整代码"的过程自动化了。模型不仅学会生成 HTML，还学会了"看效果、改代码"的迭代能力。

5.3 对推理能力的新要求

生成高质量 HTML 需要模型具备一些特殊的推理能力：

• 空间推理：理解元素在页面上的空间关系
• 视觉预测：在生成代码时预判渲染效果
• 交互逻辑：理解用户操作的因果链（点击 → 状态变化 → UI 更新）
• 约束满足：在设计系统约束下找到最优实现

这些能力在当前的纯文本训练范式下难以充分发展，可能需要新的训练方法来强化。

六、对 HTML 标准本身的反向影响

6.1 当 AI 成为 HTML 的主要生产者

一个值得思考的长期趋势是：如果 AI Agent 生成的 HTML 数量超过人类手写的 HTML，W3C 等标准组织是否需要考虑"AI 友好"的标准演进？

可能的方向：

• 简化冗余语法：某些 HTML 属性的默认值可以更合理，减少 AI 需要显式声明的内容
• 语义化增强：增加更多语义标签，让 AI 更容易表达意图
• AI 输出标注：定义标准的 meta 标签来标注"此页面由 AI 生成"
• 交互回传标准：定义标准的方式让页面内的用户操作结果可以被外部程序（Agent）读取

6.2 “AI Output Profile”

类似于 HTML 曾经有 “XHTML Strict” 和 “HTML5” 等不同 profile，未来可能出现一个 “AI Output Profile”：

• 限定可使用的标签和属性子集
• 强制要求可访问性标注
• 内置安全约束（禁止外部资源加载、限制 JS 能力）
• 标准化的状态导出接口

这将为 Agent 生成 HTML 提供一个明确的"靶标"，也为沙箱渲染提供安全保障。

七、时间线预测与优先级判断

基于当前技术发展速度和产业需求，以下是各项变化可能的落地时间线：

短期（6-12 个月）

• 专门的 SFT 数据集：针对 HTML 生成任务的高质量标注数据集出现
• 评估基准：类似 HumanEval 但面向 HTML 生成质量的 benchmark 发布
• Tokenizer 微调：在现有 Tokenizer 基础上增加 HTML 高频模式

中期（1-2 年）

• AI Judge 工具链：自动化的 HTML 输出质量评估系统成熟
• 专用微调模型：在通用模型基础上针对 HTML 生成进行专门微调的版本
• 训练 pipeline 集成渲染器：主流训练框架支持在训练循环中调用浏览器渲染

长期（2-3 年）

• 原生 HTML 生成架构：从模型架构层面优化 HTML 生成效率
• 标准化进程：W3C 或类似组织开始讨论 AI 输出相关标准
• 多模态闭环训练：生成-渲染-评估的完整闭环成为标准训练范式

八、结语

从 Markdown 到 HTML 的输出格式转变，看似只是应用层的一个选择，实则牵动了大模型训练体系的多个核心环节。评估方式、数据质量标准、对齐方法、Tokenizer 设计乃至模型架构，都需要相应调整以适配这一新的输出范式。

这是一个典型的"应用层需求倒逼基础设施变革"的案例。历史上，移动互联网的兴起倒逼了响应式设计标准的建立，视频流媒体的普及倒逼了编解码器的革新。AI Agent 对 HTML 输出的需求，同样有可能推动从 Tokenizer 到 HTML 标准本身的一系列演进。

对于 AI 训练领域的从业者而言，现在是时候开始思考：当模型的输出不再只是文本，而是可渲染、可交互的完整界面时，训练的目标函数应该如何重新定义？

---

本文为"AI 输出范式转变"系列文章第四篇。
第一篇：《当大模型不再吐 Markdown：从 Claude 团队的 HTML 实践看 AI 输出范式转变》
第二篇：《一次性 UI 的时代：AI 生成的"用完即弃"界面会颠覆前端开发吗？》
第三篇：《AI Native 应用的 UI 层该怎么设计？从 AG-UI 到 Agent 直出 HTML 的思考》