HTML 和 Markdown 不可能是替代关系

原文：https://www.chatprd.ai/how-i-ai/claude-code-anthropic-thariq-shihipar-on-replacing-markdown-with-html

HTML 可能是 AI 编程时代的新 Markdown

大家好，我是唐斩，今天看到 ChatPRD 采访 Anthropic Claude Code 团队工程师 Thariq Shihipar 的一篇文章。

里面有一句话很有意思：

HTML is the new markdown。

这句话我觉得值得展开讲讲。

过去我们和 AI 协作，最常用的中间产物是 Markdown。

需求文档是 Markdown，技术方案是 Markdown，任务列表是 Markdown，AI 生成计划也是 Markdown。

Markdown 的优点是简单、结构化、模型和人都容易读。

但问题也很明显。

当一个计划变成几千行 Markdown 时，人其实就不读了。

你会让 AI 总结，让 AI 修改，让 AI 继续补，但自己对计划的参与度会越来越低。

这时候协作质量就下降了。

所以 Thariq 的核心观点不是“模型读不了 Markdown”，而是：

人读不动大段 Markdown。HTML 能把人重新拉回协作过程。

1、HTML 计划，比 Markdown 计划更容易参与

HTML Plan 让人重新参与计划

他第一个 workflow 是让 Claude Code 直接生成 HTML 计划。

不是说：

给我列几个 demo idea。

而是说：

帮我用 HTML 做一个 demo idea 页面。

这样出来的就不是一堆 bullet list，而是一个可滚动、可视化、有小 mockup、有风险评估的网页。

后面选定一个方向，比如 CSV 转交互式 dashboard，再让 Claude 继续生成完整 HTML implementation plan。

这个 plan 里可以有：

• 产品说明
• 文件结构
• UI mockup
• 代码片段
• mood board
• 风险和约束

这就很像一个单文件网站。

我觉得这个点非常关键。

AI 编程的 plan 阶段，本质不是为了“有一份文档”，而是为了让人和 AI 对齐。

Markdown 能对齐逻辑。

HTML 能对齐视觉、结构和交互。

复杂任务里，后者明显更强。

2、临时 micro-app，是 AI 编程的新用法

Micro-app 临时软件化

第二个 workflow 更有意思。

HTML 不像 Markdown 那么容易手改，怎么办？

Thariq 的办法是：让 Claude 再做一个临时编辑器。

比如他在计划里有一套 CSV 字段转图表的决策规则，觉得 AI 生成得不够好。

普通做法是继续聊天：

这里改一下，那里改一下。

但他直接让 Claude 生成一个 custom UI，用来编辑这套规则。

这个 UI 里可以有输入框、下拉框、增加删除按钮，最后还能把配置复制回 Markdown 或主流程里。

这就不是传统意义上的软件了。

而是为了当前任务临时生成的 micro-app。

我觉得这代表一个很重要的变化：

以前我们只有值得长期维护的东西才做成软件。现在很多一次性的编辑、整理、配置、决策，也可以临时做成软件。

因为成本太低了。

这就是 AI 编程带来的“软件丰裕”。

以后我们不只是写产品代码，也会给自己的工作流随手生成一堆临时工具。

用完就扔，也没问题。

3、design_system.html 是很好的上下文资产

design_system.html 是上下文资产

第三个 workflow 是 living design system。

让 Claude 从项目代码、CSS、组件里提取设计语言，然后生成一个 design_system.html。

这个文件不是普通说明文档，而是一个能看的设计系统页面。

里面可以展示：

• 色板
• 字体层级
• spacing 规则
• button / input / card 等组件
• 不同状态下的组件示例
• 可调参数的 playground

以后做新页面或新功能，把这个 HTML 文件给 Claude，它就能参考已有风格。

这个思路我很喜欢。

因为它解决的是 AI 做 UI 时一个非常常见的问题：

AI 不是不会写页面，而是经常写得不像你的产品。

如果只有文字描述，比如“保持现有风格”，太抽象。

如果有一个可视化的 design system HTML，模型和人都能看到具体样子，效果就会稳定很多。

这其实也是上下文工程。

只是上下文不再只是文本，而是一个可视化、可交互、可复用的网页资产。

4、真正的变化是人机协作介质升级

总结一下，我觉得这篇文章的重点不是 HTML 这个技术本身。

HTML 很老了。

真正的变化是：AI 让 HTML 成为一种低成本的人机协作介质。

Markdown 适合表达结构化文本。

HTML 适合表达可视化结构、交互界面和工作状态。

以前做 HTML 页面需要前端开发成本，所以不会为一个临时计划、一个临时规则编辑器、一个临时设计系统专门做页面。

现在 Claude Code 可以直接生成。

成本一降，使用场景就变了。

所以后续我觉得可以这样用：

1. 复杂方案，不要只让 AI 写 Markdown，让它生成 HTML plan。
2. 复杂配置，不要反复聊天改，让它生成临时编辑器。
3. UI 项目，不要只写风格要求，让它生成 design_system.html。
4. 给别人 Review，不要只发文字方案，发一个可读可看的网页。
5. 重复使用的 HTML artifact，可以沉淀成项目上下文资产。

这和我之前说的 Agent 工作流是同一个方向。

AI 编程不是只生成最终代码。

大量 token 会消耗在计划、沟通、对齐、编辑、验证、设计系统这些“中间脚手架”上。

这些中间产物不一定进生产代码，但它们会显著提高最后那部分生产代码的质量。

所以，下一次用 Claude Code 或 Codex 时，可以试试不要说：

帮我写一个计划。

而是说：

帮我生成一个 HTML 页面，让我能看懂、能编辑、能和你一起推进这个计划。

这可能就是 AI 编程从“文本协作”进入“界面协作”的开始。

在我看来，他俩不是替代关系，HTML面向人，易读易修改。Markdown面向Agent，格式紧凑，易读易理解。

你是否有这样的场景：

1、你有一个巨长的重要的 markdown 文件。 比如一个精心打磨的skill

2、你对这个markdown有阅读的需求。比如你想看一下刚才Agent给你改的skill的结果

3、你还对markdown有修改的需求。比如刚才的skill你想直接改动一部分

那如果有一个工具能输入markdown实时渲染HTML，这个HTML是可修改的，修改后能实时反馈回到 markdown 上。你会需要这样的工具吗？

我是唐斩，AI编程专家