一封来自 Claude Code 团队的备忘录
2026 年 5 月 8 日，Anthropic 的 Claude Code 团队成员 Thariq Shihipar 在自己的 X 账号上发出了一篇两千多字的长文，标题罕见地直白：《使用 Claude Code：HTML 不可思议的有效性》。
文章本身没有任何产品发布信息，没有路线图，也没有商业宣告。它讲的是一个看似琐碎的话题——AI 输出文件应该用什么格式。但这篇文章在 Claude Code 用户社群里被迅速传开，48 小时内的 X 浏览量冲到千万级，Karpathy 出手转发，国内的科技媒体也跟进做了二手解读。它确认了许多深度用户私下已经在做、却没人说破的一件事：他们正在抛弃 Markdown。
Thariq 在文中并不掩饰这是一个个人选择。他形容自己是”HTML 极端派”，几乎已经停止在工作中使用 Markdown。但他同时点明了一个集体趋势：在 Claude Code 团队内部，越来越多的成员把 HTML 作为 AI 输出的默认格式。他在文章末尾甚至留下一句半开玩笑的预防针——”我有点担心有人读完这篇会把它做成一个 /html 的 skill”——这句话本身就泄露了信息：这不是一个被产品化、被推广的特性，而是一群高频用户摸索出的内部惯例。
值得停下来追问的是，为什么是现在？Markdown 作为 AI 与人交流的格式，已经稳坐默认位置好几年。它简单、便携、人类好读好改，连 Claude 都被训练得善于用 ASCII 字符在 Markdown 里画出可用的示意图。它没有出问题，没有被弃用，没有被任何一次模型升级特别针对。但偏偏在 Opus 4.7 这一代，在团队内部就有人开始嫌它太窄。这是这篇文章真正值得讨论的地方——它不是关于 HTML 多么强大，而是关于 Markdown 在什么地方开始撑不住。
为什么过去是 Markdown 的天下
要看懂这场迁移，得先看懂 Markdown 当初凭什么赢。它的胜利不是偶然的，而是和大模型这一代技术栈在四个维度上严丝合缝地咬合在一起。
第一是训练数据的天然倾向。互联网上大量的技术博客、README、Stack Overflow 回答、GitHub Issues、Reddit 长帖、Notion 公开页都用 Markdown 写就。模型在预训练阶段反复见到”井号开头=标题”、”星号包围=强调”、”减号开头=列表”这类极轻量的视觉结构，逐渐把”用 Markdown 格式化”和”看起来更认真、更结构化、更专业”绑定在一起。这种关联一旦内化，模型在任何需要”显得靠谱”的场合都会下意识地用上 Markdown 标记。
第二是 token 经济学的偏向。Markdown 的结构信号是局部的、轻的——一个 # 就是一个标题，一对 ** 就是一次强调，模型不需要维护远距离的状态（比如某个标签是否闭合、某个嵌套是否完整）。相比之下，HTML、JSON、XML 这些格式都要求模型在生成时承担更重的”括号匹配”心智负担，每生成一个开标签就要在心里挂一个待闭合的栈。Markdown 把这层负担几乎压成零。
第三是 RLHF 阶段的强化。在人类反馈训练里，标注员对”结构清晰的答案”几乎本能地给高分。一个用 Markdown 排得整整齐齐、有标题有列表有代码块的回答，比起一段流水的纯文本，得分会系统性偏高。这种偏好在万次量级的标注上被模型完全吸收——它学到的不只是”什么时候用 Markdown”，而是”用 Markdown 这件事本身就更值钱”。
第四是零解析成本。Markdown 是纯文本，模型读它不需要任何前置解码——不像 PDF 要先把字符按坐标重排回阅读顺序，也不像 Word 要先把那堆 XML 标签和样式信息剥离掉，更不像 PPT 要在嵌套的 ZIP 包里找正文。Markdown 的字符序列就是它的语义序列。这一点让 Markdown 在”AI 之间投喂资料”这件事上几乎不可替代，也是为什么微软那个把 Office 文档统一转成 Markdown 的 markitdown 工具在 GitHub 上拿到 12 万星——它本质上是在做”喂给 AI 之前的最后一公里清理”。
把这四点叠起来就能看到：Markdown 不是因为人类好读才赢的，它是因为对 AI 也极其友好才赢的。模型擅长生成它，模型擅长消费它，工具链擅长围绕它做转换。在过去几年里，”AI 输出用 Markdown”几乎是一个不需要解释的默认。
Markdown 的隐性瓶颈
但今天的问题是：AI 这一边的产出速度和复杂度，已经悄悄越过了 Markdown 这种格式能承载的上限。Thariq 在文中提到一个非常具体的观察：他自己读不下去超过 100 行的 Markdown 文件，而且基本没办法让组织里的其他人去读这种文件。这不是 Markdown 排版能力的问题，是它作为”线性纯文本+少量结构”的本质决定的——它擅长承载一篇文章、一份说明，但当 AI 生成的不再是一篇文章，而是一份带有架构图、数据流、代码对比、多个备选方案并排的”工作产物”时，Markdown 只能把这些信息全部压扁成一长串文字流。
更尴尬的是，AI 在 Markdown 里挣扎的痕迹已经开始变得可笑。Thariq 在文章里贴了一张截图：Claude Code 试图在 Markdown 里表达颜色，但 Markdown 没有任何呈现颜色的能力，于是模型只能用一串 Unicode 字符去近似”红色”和”蓝色”的视觉效果。类似的还有用 ASCII 字符画的流程图——在没有更好选择的情况下，它能用，但它清楚地暴露了载体和内容之间的不匹配。AI 已经能想到”我想在这里展示一段交互”或者”我想让用户调一个参数看看效果”，但 Markdown 没有任何机制让这件事发生。
这种”撑不住”在别的产品身上也开始冒头。DeepSeek 的用户里有一个流传的小动作：跟模型说”给我做一个小游戏”，模型不会再老老实实写一份”游戏设计文档”丢给你，而是直接吐出一份可以双击打开就能玩的 HTML 文件。这件事发生在两个甚至不属于同一家公司的工具里，方向却是完全一致的——当模型能直接生成可运行的东西时，让它先退一步把成品写成 Markdown 描述，反而是一种倒退。
还有一个更隐蔽的转变：人们越来越少亲手编辑这些文件了。Markdown 一直以来最大的优势之一是”人类好改”，但当一份规格文档、一份头脑风暴笔记越来越多地由 AI 生成、再由人 prompt AI 去修改时，”人类好改”这个特性的价值就在下降。这个变化看似细微，却让 Markdown 的核心卖点之一失去了重量。换句话说，当生产端和消费端都被 AI 接管以后，中间格式应该优化的不再是”人类是否方便手敲”，而是”人类是否方便阅读、分享、互动”。
HTML 提供的五项升级
Thariq 把切换到 HTML 的好处归纳为五个方面，每一个都对应着 Markdown 的一个具体短板。第一是信息密度。HTML 不仅能做基本的标题和格式，还能用表格承载结构化数据，用 CSS 承载视觉设计，用 SVG 画真正的插图和流程图，用 script 标签嵌代码片段并直接运行，用绝对定位和 canvas 表达空间关系。他给出了一个相当大胆的判断：几乎不存在 Claude 能读取的信息，无法被 HTML 高效地再现。第二是可读性——HTML 文档可以靠分页、tab、配色、响应式布局把信息组织成真正能扫读的页面，而不是一坨从头滚到尾的文字。
第三和第四是分享与交互。Markdown 文件几乎没办法在浏览器里被原生体面地渲染，分享时常常要走”附件 + 请用 typora 打开”这种笨拙路径。HTML 只需要上传到一个静态空间——文章中举的例子是 S3——就能变成一条任何人都能点开的链接，”同事真正点开你那份规格文档”的概率会大幅提高。交互层更进一步：HTML 允许你在文档里嵌入 slider、按钮、可拖拽元素，让阅读者不只是看，而是动手玩，玩完之后还可以把调参结果一键复制成 prompt 粘回 Claude Code。
第五项是数据摄取力，这一点容易被忽略但实际上是 Claude Code 相对其他 AI 工具的核心优势之一。Claude Code 可以读你的整个代码目录，可以通过 MCP 访问 Slack、Linear，可以读 git 历史，可以通过 Claude in Chrome 抓你正在看的网页。Thariq 在文章里举的一个例子非常直观——他写这篇文章时，让 Claude Code 翻遍自己的代码文件夹，找出所有他生成过的 HTML 文件，分类归组，再生成一个总览页。这篇文章里出现的所有示意图都是这个过程的副产品。把这种数据摄取力和 HTML 的表达力结合起来，你得到的不是一个新格式，而是一个新工作流——AI 主动去聚合上下文，再以高密度的视觉形态把结果递还给你。
真正的新东西：一次性小工具
如果说前面几项升级还属于”格式优化”，那么 Thariq 在文章后半段提出的”Custom Editing Interfaces”——一次性自制工具——则是这次格式迁移真正的隐藏王牌。这个用例值得单独拎出来讲，因为它不是 HTML 比 Markdown 好一点的问题，而是它做了 Markdown 根本做不到的事。Thariq 描述的场景是这样的：有时候你要做的事情，光靠 prompt 在文本框里很难讲清楚，那就让 Claude 给你做一个一次性的小编辑器——不是产品，不是可复用工具，而是为此刻这一件事现造的一个 HTML 文件。
他给出了几个典型的例子，每一个都让人立刻意识到自己平时被”在文本框里描述”困住了多少次。第一个：要把 30 张 Linear 工单重新排优先级，让 Claude 做一个 HTML 文件，每张工单是一张可拖拽的卡片，分成 Now / Next / Later / Cut 四列，先按它的最佳猜测预排好，再加一个”copy as markdown”按钮，最后把结果连同每个分桶的简短理由一键导出。第二个：要调一个新结账按钮的播放动画——动画完成后变紫色——让 Claude 做一个 HTML 页面，把动画速度、缓动曲线、颜色参数都做成 slider，调到满意之后一键复制出最终参数。第三个：要调一个系统提示词，让它做一个左右分栏的页面，左边是带变量高亮的提示词，右边是三个样本输入实时渲染填充后的效果，配上字符和 token 计数。
这些例子的共同点是：它们不是”让 AI 帮我写一份东西”，而是”让 AI 帮我现造一个工具，我用这个工具完成一件事，工具用完即可丢弃”。在 Markdown 时代，这种工作流根本不存在——不是因为不能想到，是因为格式根本不支持。而在 HTML + AI 这一代，做出一个临时小工具的成本，已经低到比起花十分钟在文本框里描述清楚要求还要划算。这是这场迁移里最容易被低估的部分：人们以为只是换了一个文件后缀，实际上是新增了一类此前不存在的”工作产物”。
代价清单
把 HTML 当默认输出格式不是没有代价的，Thariq 在文章最后的 FAQ 里诚实地列出了几条。最直接的是生成速度——同样的内容，HTML 比 Markdown 慢两到四倍，这个差距在交互式使用中是能感受到的。其次是 token 成本，HTML 的标签开销不小，但作者认为在 Opus 4.7 的 1MM 上下文里，这一点几乎不构成实际压力，可以放下。第三是版本控制：HTML 的 diff 在 git 里又乱又长，几乎无法用常规的代码审阅方式去读，这是作者承认的最大短板。第四是审美问题——AI 生成的 HTML 默认有一股很强的”AI 味”，需要靠 frontend design 插件或者把公司自己的 design system 做成一个 HTML 参考文件喂给 Claude 才能拉回来。
值得注意的是，这些代价里没有一项是结构性致命的。慢两到四倍意味着每次生成多等几秒到几十秒，对于一份你打算反复阅读和分享的产物来说几乎可以忽略。token 成本随着上下文窗口扩大已经被稀释。版本控制的问题真实存在，但反过来想——如果一个 HTML 文件本来就是为一次性使用而生（比如那个 Linear 工单拖拽看板），它根本不需要进入版本控制系统。审美问题靠一个 design system 参考文件就能缓解。每一项代价都有对应的工程化路径。
这一点本身就说明问题。当一个新选项的所有缺点都是”可工程化解决”的，而它的优点是”打开了一个原本不存在的工作流”时，迁移就只是时间问题。Markdown 不会消失，它仍然是写给人看的文本的最佳格式，仍然适合那些线性的、需要被反复手编的文档。但作为”AI 工作产物的默认载体”这个位置，它确实正在被让出去。
协议与界面：AI 时代的产物分层
退一步看这件事，它真正昭示的不是 HTML 战胜了 Markdown，而是一个更长期的趋势：在 AI 把生产成本压到接近零的环境里，”工作产物”这件事正在按用途裂变。过去，一份规格文档、一份会议纪要、一份周报、一份代码评审，全部都可以塞进 Markdown 这个统一容器里——这是因为生产成本高，每一份产物都珍贵到值得人工抚平差异、塞进同一个模板。当生产成本变低之后，没有理由再用同一个模板去承载所有形态的产物。
真正在发生的，是产物层在分裂成至少三层。最底下一层是”协议层”，是 AI 内部彼此沟通用的工作语言——Claude 写给自己的笔记、agent 之间传递状态的中间文件、长任务里维护的上下文、CLAUDE.md 这类指令文件、被微软 markitdown 标准化处理后的资料库——这一层会继续是 Markdown 的领地，而且会越来越深地嵌进 AI 基础设施里。它的特点是被使用但很少被人直接读到，最终会变得像 HTTP 那样隐形：所有人都依赖它，没有人需要看见它。一种格式真正赢的方式，从来不是被歌颂，而是被遗忘。
中间一层是”界面层”，是 AI 给人看的最终产物——规格文档、研究报告、PR 解读、设计探索、需要在团队群里被点开转发的东西。这一层正在迁移到 HTML，原因前面已经讲透：信息密度更高、可读性更好、分享路径顺滑、能承载交互。这是 Thariq 文章里描述的主战场，也是 Claude Code 团队内部最早换上 HTML 的那一类输出。
最上面一层是”工具层”——也就是前面那一节讲的”一次性自制工具”。它的生命周期甚至比规格文档还短，可能只存在十几分钟，完成一次拖拽、一次调参、一次决策就被关掉。这是 AI + HTML 这一代独有的产物形态，过去根本没有对应物。它不进入版本控制，不需要审美打磨，不要求和团队其他文件保持一致，它的唯一标准是”此刻能不能帮我把这件事做完”。
把这三层叠起来看，就能解释为什么 Thariq 的文章在社群里被反复转发，也能解释为什么国内的科技媒体几乎是隔了几个小时就跟进做二手解读：它没有揭示新工具，它只是把一群人已经开始做、但说不清楚的事情说清楚了。Markdown 没有死，它退到了协议层，反而扎得更深。HTML 接过了界面层，但 HTML 也不是终点——往前看，界面层的载体未来还可能换成更精致的可交互格式、3D 空间、甚至更直接的视觉接口。真正稳定的，是这套”协议—界面—一次性工具”的分层逻辑本身。对于已经把 Claude Code 嵌入日常工作的开发者来说，这套分层不需要等待任何官方产品化——所有零件都已经在手里，缺的只是意识到自己可以这样用。对剩下还没意识到这件事的用户来说，看到这套用法的第一反应，恐怕都是同一句——”原来还可以这样用”。
示例： https://thariqs.github.io/html-effectiveness/
原文： https://x.com/trq212/status/2052809885763747935