AI 原生写作：为什么我放弃 Markdown，改用 HTML

TL;DR

Claude Code 团队成员 Thariq 的长文观察到一个正在发生的转变：

Markdown 是 AI 早期时代的格式 — 设计给人类写、人类改的，现在是 AI 写、人看

HTML 是 AI 时代的更好媒介 — 更丰富的信息密度、视觉清晰度、双向交互

信息密度决定参与度 — 超过 100 行的 Markdown 人就不读了，HTML 可以做得更可读

格式即交互设计 — 你选择的输出格式决定了后续的交互可能性

📋 本文结构

Markdown 的局限 — 它为什么会成为 AI 时代的瓶颈
HTML 的优势 — 来自 Claude Code 团队的实践
双向交互：不仅仅是展示 — 从”看”到”操作”
使用场景 — Specs、代码审查、设计原型、报告
权衡与局限 — HTML 的代价
结论：格式即思想

Markdown 的局限

💡 Key Insight

Markdown 是人类写给人类的格式。当 AI 成为主要写作者，人变成阅读者时，这个格式就开始成为瓶颈。

Thariq 在 Anthropic 做 Claude Code。他观察到一个现象：Markdown 已经成为 AI 和人类沟通的主导格式——简单、可移植、有一定富文本能力、人容易编辑。但随着 AI 越来越强大，他越来越觉得 Markdown 是一种限制性格式。

核心问题：超过 100 行的 Markdown 文件，人实际上不会读。 你可以让 Claude 写一份详细的 spec 或计划，但现实中他不会真的去读超过 100 行的 Markdown 文件，更不用说让团队里的其他人去读。

当信息密度超出一定阈值，Markdown 的线性文本结构就成了障碍。没有视觉层次，没有tabs，没有图表，没有交互——只有不断滚动的文字。

维度	Markdown	HTML
信息密度	线性文本	表格、SVG、CSS、代码片段
视觉清晰度	有限	可视化结构、tabs、响应式
分享方式	附件/粘贴	链接
交互性	单向（读）	双向（可操作）
超过 100 行	人不读	更易读
适用场景	人类写给人类	AI 写给人读

HTML 的优势

💡 Key Insight

几乎没有任何信息是 Claude 能读取而你不能高效地用 HTML 表示的。HTML 是模型向人传达深度信息的最高效方式。

Thariq 总结了他转向 HTML 的四个核心理由：

1. 信息密度

HTML 可以表达更丰富的信息：

用 table 表示表格数据
用 CSS 表示设计数据
用 SVG 做图表
用 script 标签嵌入代码片段
用 HTML + JavaScript + CSS 实现交互
用 SVG + HTML 做工作流图
用绝对定位和 canvas 表示空间数据
用 image 标签嵌入图片

当不能做这些时，Claude 就会用更低效的方式——比如用 Unicode 字符估算颜色（在终端里用方块和符号画”彩色”图表）。

2. 视觉清晰度

Claude 能做越来越复杂的工作，写越来越大、越来越长的 spec 和计划。但 HTML 文档更容易阅读——Claude 可以用 tabs 组织结构，用图表说明，用链接导航，甚至可以做到移动端响应式（不同设备不同阅读方式）。

3. 易于分享

Markdown 文件很难分享——大多数浏览器不能原生渲染它。你经常需要把它作为附件发送。HTML 只需要上传到 S3（或任何静态托管），然后分享链接。任何人可以在任何地方打开。

4. 双向交互

这是最有趣的一点。HTML 可以让你与文档交互。比如你可能想要 sliders 或 knobs 来调整设计，或者调整算法参数看效果。你甚至可以要求添加一个”复制这些改动为 prompt”的按钮，把你在 UI 上调整的参数直接贴回 Claude Code。

双向交互：不仅仅是展示

💡 Key Insight

最强大的用法不是”让 AI 给我一个 HTML 页面”，而是”让 AI 给我一个针对这个特定任务的一次性编辑器”。

Thariq 描述了一个具体场景：

“有时候很难在文本框里描述你想要什么。在这种情况下，我会让 Claude 给我做一个一次性的编辑器来专门处理我正在做的这个事。不是产品，不是可复用的工具，只是一个单次使用的 HTML 文件。诀窍是最后要有一个’导出’——一个’复制为 JSON’或’复制为 prompt’的按钮，把我在 UI 上做的任何操作转译成可以粘贴回 Claude Code 的东西。”

具体例子：

重新排序 30 个 Linear tickets → 把每个 ticket 做成长卡片在 Now/Next/Later/Cut 列之间拖拽，最后有”复制为 markdown”的按钮导出最终排序
调整系统 prompt → 做左右对比编辑器，左边是可编辑的 prompt（变量槽高亮），右边是三个样本输入，实时渲染填充后的模板
编辑 feature flag 配置 → 做表单编辑器，按 area 分组，显示依赖关系，开启某个 flag 时检查前置条件是否满足

这是格式作为交互设计的核心含义：你选择的格式不仅决定了如何展示信息，还决定了如何操作信息。

使用场景

Thariq 列举了他用 HTML 替代 Markdown 的具体场景：

1. Specs、规划和探索

当 Thariq 开始处理一个问题时，他期望的是一组 HTML 文件而不是一个简单的 markdown plan：

先让 Claude Code 做头脑风暴，创建一些不同选项的探索
然后扩展其中一个方向，做 mockups 或代码片段
最后写实现计划
验证时让验证 agent 也读这些文件，获得更广泛的上下文

2. 代码审查和理解

代码在 Markdown 文件里很难读。HTML 可以渲染 diffs、注解、流程图、模块关系图。这比 GitHub 默认的 diff 视图效果更好。他现在每次 PR 都附上 HTML 代码说明器。

3. 设计和原型

Claude Design 基于 HTML 是有原因的——HTML 对设计的表达力极强，即使最终输出不是 HTML。用 HTML 做设计 mockup，创建 sliders 和 knobs 来调整参数，prototype 动画和交互，然后复制参数到实际代码里。

4. 报告、研究和学习

Claude Code 非常擅长跨多个数据源综合信息并转换为可读报告。可以用 HTML 创建：

深度研究文件（读 git 历史后对 prompt caching 变化的详细说明）
周报
事件报告
用 SVG 图表说明概念

权衡与局限

HTML 不是银弹。Thariq 也坦诚地提到了代价：

权衡	说明
Token 效率	HTML 确实用更多 token，但 1M 上下文窗口里不明显
生成时间	HTML 比 Markdown 慢 2-4 倍，但他认为值得
版本控制	最大缺点——HTML diffs 噪音大，比 Markdown 难 review
匹配品味	需要 design system 文件或前端 design plugin 帮助

关于版本控制这一条值得展开：Markdown 的优势之一是它本质上是纯文本，diff 友好。但当信息的丰富度需求超过一定阈值，这个优势就不值一提了。Thariq 选择的是：在需要时才用 HTML。

结论：格式即思想

💡 Key Insight

Thariq 说了一句话让我印象很深：”我已经开始害怕因为我不再深入阅读计划，AI 就会替我做选择。但我高兴地说，使用 HTML 后我反而比以往任何时候都更有参与感。”

这句话揭示了一个被忽视的真相：格式决定了你的参与方式。

当你用 Markdown 时，你面对的是一个静态文档——你读或者不读，没有中间地带。当你用 HTML 时，你面对的是一个活的界面——你可以探索、调整、导出、反馈。这不仅仅是”好看”的问题，而是你作为人类的判断力如何介入 AI 工作流的问题。

上周我写了《执行已死，判断力永生》，说人类的价值在于定义方向、设定边界、验证结果。这篇文章从工具层面补充了这一点：判断力介入的方式也取决于你选择的媒介。

Markdown 是对话的终结——AI 输出，你接受或拒绝。HTML 是对话的延续——AI 输出，你探索、操作、迭代，然后继续。

格式即思想。你选择的表达格式，决定了你思维的方式。