Thariq 文章深度解读 · 论点拆解 × 边界分析 × 工作流落地
Thariq 发现了一个真问题（Markdown 表达力不够），给了一个对的方向（HTML），但把个人最佳实践包装成了普适结论。HTML 的真正价值是交互性和可分享性，不是"更好的 Markdown"。对你来说，值得在特定场景采纳，但不值得全面切换。
Thariq 说：HTML 能表达表格、CSS 设计、SVG 插图、JS 交互、空间布局、图片——"几乎没有什么信息是 HTML 不能高效表达的"。
他举了一个例子：Claude Code 试图在 Markdown 里用 Unicode 字符来"显示颜色"。这确实很荒谬，也说明 Markdown 在视觉表达上的局限是真实的。
我的判断：表达力上他说的完全对。但"能表达"和"应该用 HTML 表达"是两回事。一个内部技术笔记写成 HTML 就像用 InDesign 排购物清单——能做，但何必？
Thariq 说："超过 100 行的 Markdown 我就不看了"，HTML 的视觉组织（标签页、插图、链接导航）让长文档变得可读。
我的判断：这里有个归因错误。他把"Markdown 长文不好读"归因于格式，但真正的问题往往是内容组织。一个结构混乱的 HTML 文档照样没人读。
不过他有一个隐含的好观点：HTML 能做非线性导航（标签页、锚点跳转、折叠区域），这是 Markdown 做不到的。对于超过 500 行的参考文档，这确实有价值。
Thariq 说：Markdown 浏览器不直接渲染，只能当附件发；HTML 上传 S3 就能分享链接，别人打开就能看。
我的判断：这是他最无可辩驳的论点。"别人愿不愿意点开"是文档价值的决定性因素。一个链接 vs 一个附件，点击率差 5-10 倍不夸张。
而且他说的"让别人真的读你的 spec"这个痛点非常真实——在团队协作中，文档写了没人看是最大的浪费。HTML 的低摩擦分享确实能改善这个问题。
Thariq 说：HTML 可以加滑块、旋钮让你调参，然后把调好的参数通过"copy as prompt"按钮喂回给 Claude Code。
我的判断：这才是 HTML 相对于 Markdown 真正的维度跃迁，不是量变是质变。
Markdown 是单向的：AI → 人。HTML 可以是双向的：AI → 人 → 调整 → AI。这把文档从"输出物"变成了"中间件"。
Thariq 说：Claude Code 能读文件系统、MCP、浏览器、Git 历史等，所以用 Claude Code 生成 HTML 比用 Claude.ai 更好。
我的判断：这个论点成立，但跟"HTML vs Markdown"没关系。Claude Code 的数据接入能力生成 Markdown 也一样强。他在这里偷偷把"Claude Code 的优势"包装成了"HTML 的优势"。
Thariq 说："Making HTML documents with Claude is just more fun"，这本身就够了。
我的判断：说实话这不是论据，是感受。但他敢这么写也说明他的目标读者是 Claude Code 的高频用户——这群人确实会因为"看到漂亮的输出"而感到愉悦。
不过反过来想，如果你需要快速记录、快速迭代、快速搜索，Markdown 的"素颜"反而让你更专注。愉悦感是双向的。
他自己承认"HTML diffs are noisy and hard to review"，然后一句话带过。但对任何需要迭代的文档（spec、设计方案），diff 可读性直接决定了协作效率。Markdown 的 diff 是人类可读的，HTML 的 diff 基本是噪音。
严重程度：高 · 他的回应：承认但无解
他说"results are worth it"，但这是建立在他用最新 Opus、1M 上下文窗口、公司付费的前提下。对于 token 敏感的用户，每次输出多花 2-4 倍 token 不是小数目。而且生成时间长意味着迭代次数减少。
严重程度：中 · 他的回应：轻描淡写
他说"I'm also increasingly not editing these files myself"来合理化这个问题。但这恰恰暴露了一个假设：你永远有 AI 帮你编辑。如果你需要在高铁上快速改几行 spec，Markdown 用任何文本编辑器都行，HTML 呢？
严重程度：中 · 他的回应：合理化
作为 Claude Code 团队成员，他是世界上最早、最深度使用这个工具的人之一。他的工作流（高频 Agent 交互、复杂技术探索、团队 spec 分享）恰好是 HTML 的最佳场景。但他的文章标题用的是"Unreasonable Effectiveness"——暗示普适性，实际上是幸存者偏差。
严重程度：中 · 他的回应：未意识到
与其争论"HTML 好还是 Markdown 好"，不如问对问题：这个输出需要什么？
→ Markdown
→ HTML（简单型）
→ HTML（工具型）
→ HTML（全功能型）⭐
右上角是 HTML 的甜区——既要交互又要分享。左上角是 Markdown 的地盘。中间两个象限按需选择。
| 用例 | HTML 提升倍数 | 是否有替代方案 | Andy 场景适配 |
|---|---|---|---|
| Spec / 方案规划 | 3-5x | 飞书文档（部分替代） | ✅ 高价值 — 技术方案、架构设计 |
| 代码审查 | 5-10x | GitHub PR（部分替代） | ✅ 高价值 — 尤其跨仓库审查 |
| 设计 / 原型 | 10x+ | Figma / Claude Design | ⚠️ 中等 — 你不常做 UI 设计 |
| 报告 / 调研 | 3-5x | 飞书文档 + 知识库 | ✅ 高价值 — 调研报告可视化 |
| 自定义编辑器 | ∞（不可替代） | 无 | ✅ 高价值 — Prompt 调试、配置编辑 |
| 探索 / 头脑风暴 | 2-3x | 白板工具 / Markdown | ⚠️ 低 — 快速探索时 Markdown 更快 |
Thariq 写了一篇鼓吹 HTML 的文章，但文章本身是用纯文本（推文格式）发布的。他的示例页面 thariqs.github.io/html-effectiveness 才是 HTML。这说明什么？
在"快速表达想法、让尽可能多的人看到"这件事上，低摩擦的文本格式仍然是最优解。HTML 适合"精加工的输出物"，不适合"快速传播的想法"。
把 HTML 换成别的词——比如"可交互文档"或"富媒体输出"——这篇文章的核心论点依然成立。他真正发现的不是"HTML 好"，而是：
基于以上分析，你刚搭建的 HTML Artifacts 平台应该优先服务这些场景（按 ROI 排序）：
不建议用 HTML 的场景：