突如其来的唱衰
这周，突然一篇来自 Claude Code 内部人员 Thariq 的文章，在圈内大火。 引起了非常热烈的讨论。
这篇名为《Using Claude Code: The Unreasonable Effectiveness of HTML》的文章，大意是说，应该用 HTML 作为 人与AI交流的基本格式； 而不是目前广泛采用的 Markdown 格式。 原作者列出了一堆理由，也列举出了利弊。
但是在我看来，这篇唱衰 Markdown 的文章，并不是那么简单，复合了不少的误解。下面我会附原文的翻译摘要和我的观点一起进行讲解。
原文很长，但是翻来覆去就是几句话，大致核心是：AI 能力的提升，传统的 Markdown 格式已经成为限制，AI 代理（如 Claude Code）和人的交互应该全面转向 HTML，以获得更高的信息密度、更好的视觉体验和交互能力。。
原文摘要及我的的观点
1. 关于“信息密度与表现力”
原文观点引用：
“HTML 能传达比 Markdown 丰富得多的信息。它不仅能处理文本，还能通过 CSS 呈现设计、用 SVG 绘制插图。这完美替代了 Markdown 中低效且难看的 ASCII 字符画。”
火箭君的观点：复杂不等于高效，内容与表现应该分离。
Markdown 的核心哲学正是「内容与表现分离」，它强迫 AI 和 用户专注于逻辑和文本本身。
让 AI 生成包含大量 HTML 标签、内联 CSS 和 SVG 路径的代码，会引入海量的无意义样板代码。此外，现代 Markdown 除了可以 完美的HTML 渲染以外，还可以通过集成 Mermaid 或 PlantUML 完美实现流程图和架构图。这种声明式的图表语法比臃肿的 HTML/SVG 源码更干净、更易于人类修改。
2. 关于“视觉清晰与易读性”
原文观点引用：
“超过 100 行的 Markdown 几乎没人愿意仔细看。而 HTML 可以通过标签页、折叠面板、响应式排版等视觉结构，将庞杂的系统设计或代码逻辑整理得井井有条。”
火箭君的观点：源码的可读性才是更重要的可读性。
HTML 只有被渲染后才易读，其纯文本源码（Raw Source）是完全反人类阅读的。而 Markdown 无论是否经过渲染，其纯文本本身就具备极强的结构化和可读性，这对于习惯在终端或代码编辑器中工作的知识工作者至关重要。无论是写文章还是写代码都是一样的，这是参与思考的过程。
当然，现在有种观点，人类未来不需要阅读源码，无论是写作，报告，还是 vibe coding， 源码都交给 AI 就好了。那我只能说，放弃读源码，实际是在外包自己的思考过程，等到大家都不再思考源码时，大家也就没有了自己的思考能力，只能看着 AI 生成的华丽输出傻笑了（目前已经明显有这个趋势了）。
3. 关于“分享体验”
原文观点引用：
“Markdown 在浏览器中缺乏原生渲染支持，往往需要作为附件发送。而 HTML 文件只需上传（如 S3）即可生成链接，同事们可以在任何设备上直接点开阅读，大大提高了分享效率。”
火箭君的观点：增加了基础设施依赖与安全风险。
实际上，HTML 的分享门槛远高于 Markdown。分享稍微复杂一点的 HTML 需要专门的托管服务（如 AWS S3、Vercel 等），这不仅增加了基础设施成本，还带来了权限控制和数据泄露的安全风险。
相反，Markdown 是现代协作工具的“通用语言”。你可以直接将 Markdown 粘贴到 GitHub、GitLab、Notion 或 Slack 中，它们都会提供完美的原生渲染。不需要任何“上传文件并生成链接”的繁琐步骤。
我个人也介绍了很多 Markdown 编辑器（含渲染），Windows Notepad 也开始支持 MD 了， 这已经是一种默认的新文本文件格式了。 很难想象，2026年，一个严肃的知识工作者居然会打不开 Markdown 文件。
4. 关于“双向交互与自定义编辑器”
原文观点引用：
“HTML 支持双向交互。当文本框难以描述需求时，你可以让 AI 为你写一个‘一次性编辑器’（如拖拽式的工单看板、特性开关表单），调整满意后再将数据导出回 AI。”
火箭君的观点：过度工程化且充满安全隐患。
让 AI 编写带有 JavaScript 的“一次性交互界面”实在是过度工程化了。
首先，运行 AI 生成的未经审查的 JavaScript 代码可能导致 XSS 攻击或本地数据泄露。 原本只要好好的看文本，现在变成了还要运行代码。
其次，AI 生成的交互逻辑往往存在 瑕疵 Bug，难道还要为调试这些“一次性工具”，去花费的时间？直接用文本解决原问题，不是更好吗？我一直主张，关注内容，关注问题本身，而不是花哨的形式。 纯纯的 shi 上雕花。
5. 关于“生成速度与 Token 成本”
原文观点引用：
“虽然生成 HTML 通常比 Markdown 慢 2-4 倍，且消耗更多 Token，但在当前百万级上下文窗口下，这点消耗微乎其微，结果绝对物有所值。”
火箭君的观点：稀释 用户 和 AI 两方的注意力。
姑且我们相信仅仅慢了2-4 倍。 抛开这些问题，因为AI算力，我假设以后一直会增长，一年后或许的确不是大问题了。
但在交互式 AI 体验中是灾难性的。哪怕慢2-4倍，等待几分钟只为了看一个排版花哨的报告，会严重打断用户的心流。
更重要的是，即使上下文窗口足够大，生成大量冗余的 HTML 标签也会严重稀释 AI 的注意力（Attention 机制），导致模型在长文本中迷失核心逻辑，增加产生幻觉的概率。同时，输出 Token 的成倍增加直接等同于 API 成本的激增。
而这一切，原本都是没有必要的。（哦，对了，你们是按 token 用量卖套餐的，这就解释得通了）
6. 关于审查和版本控制
原文观点引用：
“这是最大的缺点。HTML 的 Diff 噪音很大，确实不如 Markdown 容易审查。”
火箭君的观点：无法进行审查，注定只能是玩具。
原文作者轻描淡写地承认了这一点。但是审查和版本管理，尤其是审查是不可避免的，如果我们讨论的是严肃的生产力的话。
审查意味着有人参与的阅读理解，或者工具辅助的比较（比如 diff，但是多数情况下，非代码类的可能用不到 diff，但肉眼审查还是需要的）
不能被审查，意味着不能进入合规的企业用途，也很难成为效率生产的一部分（后续会带来混乱），只能在很浅的应用里打转，接近于轻娱乐和自嗨这类，我一直喜欢说的，这就是另一个“AI玩具”，闪闪发光，好玩，有新鲜感，然并卵，热度褪去后，什么也不是。
Claude Code 原本是一个真正的生产力工具，最后却要和一众 AI 玩具争夺市场？
最后
《HTML 超乎想象的有效性》一文确实展示了 AI 在前端生成方面的强大能力，HTML 也确实能做出好看的“演示工具” 或者 “AI玩具”，这是事实。
但是，Markdown 才是知识工作实践的基石。用 HTML 替代 Markdown 交互，本质上是为了追求视觉上的“华丽”，而牺牲了源码可读性、安全性、生态兼容性和审查控制能力。
在生产力的领域里，这不是专业的做法，也无疑是本末倒置的做法。无论 AI 以什么方式介入我们的工作，保持简单、专注内容，才是高效工作或协作的真正解法，这也是我这么多年的经验之谈。
顺便一说，Claude Code 借内部人士之口，鼓励大家用更耗 token 的方式使用 AI， 属于利益相反（COI），本身就有商业伦理上的可疑之处，值得我们注意。 （他原本完全可以说，给你们提供一个输出方式的选择 HTML，而不是说替代 Markdown ）
效率火箭，火箭君的新博客 