怎么创建一个真正能干活的 Skills？

编辑 | 林芯

“我已经完全不再使用 Markdown 了”

刚刚，在X上Claude Code工程师Thariq的一篇分享——他几乎停止使用 Markdown，转而使用 Claude Code 生成 HTML 文件。在短短几个小时里，这篇帖子的浏览量就突破了 200 万。

评论区有网友对“使用 Claude Code 生成 HTML”的方式非常支持：

要知道，Markdown 凭借着简洁、纯文本、版本控制友好、几乎随处可编辑的特点，从技术文档到 GitHub ，从笔记软件到博客平台，它几乎成了轻量级标记语言的代名词。

但如今，Claude Code 团队里有许多人都更倾向于使用 HTML 作为输出格式。难道 Markdown 一下子过时了吗？

我们一起来看一下！

 为什么大批开发者，开始放弃 Markdown？

“我也不亲自编辑这些文件了，而是将其用作设计规范、参考文件、头脑风暴的成果等等。当我确实需要修改时，通常会提示 Claude 来进行修改，但这却削弱了 Markdown 最大的优点之一。”

Markdown简单、便携、富文本能力适中，还容易手动编辑。Claude 甚至能用ASCII 在 Markdown 里画图！

但是随着 Agent 的能力越来越强，一系列问题就出现了：

• 长文件阅读困难：超过100行的文件自己都难阅读下去；

• 信息密度低：难以高效表达表格、颜色、复杂图表等；

• 分享也不方便：浏览器的原生支持差，通常需要通过附件才能分享。

碾压 Markdown！HTML 到底强在哪？

HTML 还是有“两把刷子”的——Markdown 做不到的地方也就成为了HTML的优势。

优势1：超丰富的信息表达形式

HTML 除了能够完成简单的文档结构功能，还能呈现 8 种类型的信息，包括表格、插图等等。

“我甚至可以说，只要是对 Claude 能读懂的信息，几乎都可以通过 HTML 进行相当高效地呈现。”

优势2：视觉清晰、阅读友好

相对于Markdown，HTML 文档更容易阅读：Claude 可以从“界面”的角度去组织内容结构，通过标签、插图、链接等导航，它甚至还可以是移动响应式的！

优势3：更容易分享

在分享 Markdown 文件时，通常需要作为附件添加到电子邮件或消息中。

如果使用的是 HTML ，只要上传文件，就能轻松分享链接。

“如果你的报告或者公关稿件是 HTML 格式的，别人真正愿意打开并读完它的概率会高得多。”

优势4：支持双向交互

更重要的是，HTML 不只是“更好看的文档”，它甚至可以变成一个可交互的界面。比如加入滑块、旋钮、按钮等交互组件，用来实时调整设计参数，或者修改算法中的不同选项，能够直接观察到结果。

甚至还可以让 Claude 自动把这些调整后的参数整理成 prompt，一键复制回 Claude Code 。

选择用 Claude Code 而不是 Claude Design 

可能会有人疑问：为什么选择用 Claude Code 来生成 HTML，而不是直接使用 Claude AI 或 Claude Design？

Thariq 的回答是：Claude Code 能够调用的“上下文”远远更多。它不仅能读取当前文件，还能直接通过代  MCP（如 Slack、线性线性等）、浏览器（在 Chrome 中使用 Claude）、git 历史记录等来查找上下文。

并且 Thariq 在写这篇文章时，他直接让 Claude Code 扫描自己的代码文件夹，找到过去生成的所有 HTML 文件，对它们进行分类、归组，再自动生成一个包含不同类型图表的 HTML 页面。而文章里展示的那些图表，就是 Claude Code 基于这些上下文生成的结果。

真实落地：工程师私藏的 5 大 HTML 使用场景

前面有关 HTML 的优势说了那么多，实际落地会用到哪里呢？

Thariq 给出了 5 个可参考的使用场景！

场景1：发散性思考探索

如果说 markdown 是一个单线程的计划，那么 HTML 就是多线程发散式的。

当他用 Markdown 时，流程是线性的：想法 → 计划 → 实现，

但切换到 HTML 时，流程变成了一个“发散式网络”：先让 Claude 头脑风暴探索，把每个方向扩展成独立 HTML 页面；再选择一个满意方向深入撰写成实施方案；最后汇总成实现计划，再开启新的对话去执行。

甚至在验证阶段：另一个 Agent 会重新“读整个 HTML 网络”，而不是只看一段总结

Thariq还给了提示词案例：“我不确定如何设计引导界面。生成 6 种截然不同的方法——变化布局、语气和密度——并将它们以网格形式放在一个 HTML 文件中，以便我可以并排比较它们。”

场景2：代码审查与理解

在 Markdown 文件中，代码可能难以阅读。但使用 HTML，我们可以渲染差异、注释、流程图、模块等。利用这个方法，可以更好地理解 Agent 编写的代码，进行代码审查。

“我发现这通常比默认的 Github 差异视图效果更好，现在我会在每个 PR 中附加一个 HTML 代码解释器。”

场景3：设计与原型交互

HTML 在设计表达上具有极强的表现力。

即使你最终的产品界面完全不是 HTML，也完全没问题：Claude 可以先用 HTML 快速勾勒出高保真设计图，呈现出布局、交互和视觉效果，然后再用你指定的语言（React、Swift、Kotlin 等）将其真正实现出来。

除此之外，还可以直接进行原型化交互：Claude 直接构建一些可操作的组件，比如动画效果、按钮交互，甚至是滑块、旋钮等参数控制器。

场景4：输出清晰易读的报告

Claude Code 非常擅长整合多个数据源信息并转化为报告。

通过提示 Claude 搜索 Slack、代码库、git 历史记录、互联网等，能够利用它生成非常易于阅读的报告；并且还可以将其组装成 HTML 文档、交互式解释器，甚至是一个演示文稿。

场景5：自定义编辑界面

有时候很难只用文本描述出想实现的效果。

在这种情况下，Thariq 会让 Claude 构建一个一次性编辑器，用于正在处理的具体事情。

“不是产品，也不是可重用的工具，而是一个专门为这一份数据构建的单一 HTML 文件。”

灵魂三问：

更耗 Token、生成慢、版本控制差怎么办？

在 Thariq 从 Markdown 切换到 HTML 之后，总会被问到一些问题：

这不会更消耗 token 吗？

“虽然 Markdown 通常使用更少的 token，但 HTML 的表达能力更强，而且我更有可能阅读它，这意味着可以得到更好的整体输出。在 Opus 4.7 的 1百万字上下文窗口中，token 使用量的增加在上下文窗口中并不明显。”

这会不会比 Markdown 生成得更慢？

“确实要花更长的时间！HTML 生成的时间可能比 Markdown 多 2-4 倍，但我发现结果值得。”

版本控制怎么样？

“这是 HTML 最大的缺点之一，HTML 在版本对比时会显得非常“嘈杂”，结构变化、标签层级、样式调整都会被放大成大量无关噪音，使得代码审查变得不够清晰、也不够高效。”

网友：超赞！工作效率提高了！

对于用 HTML 来替代 Markdown 的这种操作，网友的态度大多是肯定的：“让 AI 用 HTML 帮你做软件原型，你实际上可以在其中构建交互来测试空状态等。保真度更高，可以检查可用性。”

“我之前不知道该怎么编辑 HTML 代码。Claude 直接给了我带内联注释的可编辑 HTML 代码。问题解决了，我的工作效率也提高了！"

除此之外，还有一些对操作细节的询问：“对于我们这些在终端中使用 Claude Code 的人来说，你建议我们如何利用 HTML？刚刚让它生成文件并在浏览器中打开？”

写在最后

Thariq 之所以选择使用 HTML，除了上面提到的原因之外，更核心的是“它让我在与 Claude 的协作中始终保持“参与感”。

“我曾开始担心，因为我不再深入阅读它生成的计划，我可能最终不得不完全放手，让 Claude 自己做出所有决策，而我只负责接受结果。”

在这篇帖子的评论区，有网友发出疑问：“这是否意味着其他允许手动编辑的工具，比如 Excalidraw，也会被淘汰？"

在小编看来，答案是否定的。

每一种工具都有它的“生态位”。Markdown 的极简、纯文本、版本控制友好。Excalidraw 的手绘风格和白板体验，在头脑风暴和快速草稿上仍有一席之地。