上个月 Anthropic 那位工程 lead ( Thariq Shihipar )抛了个观点:在 agent 场景里,HTML 正在比 Markdown 更能留住人——它有可视化、有颜色、有交互,而 Markdown 输出永远是那一坨线性文本。这事在 HN 和 Reddit 吵得挺凶。我不完全站队,但它确实戳到我两个具体痛点。
痛点一:Markdown 的天花板很硬
我经常让模型写长篇技术文档。写到一定长度就会发现:结构图画不了( mermaid 不是哪儿都渲染,画出来还是那个味儿)、没有明暗主题、目录不联动、代码块想加个复制按钮都得看平台脸色。
而模型现在写单文件 HTML 的能力早就够用了。内联 SVG 、内联 CSS 、内联一个几十行的语法高亮器,一个文件全搞定,双击就能开。
痛点二:这些 HTML 往哪放,又怎么管版本
第二个问题比第一个更烦,而且很少有人提。
模型生成的单文件 HTML 动辄 100+ KB ,而且迭代极其频繁——"主题换成暗色"、"这节展开讲讲"、"这个图标签溢出了",每一轮都是一次全文重写。于是你会遇到:
- 本地存一堆
index-v2.html、index-final.html、index-final-真的最终版.html - 传到静态托管( CF Drop / Netlify drop / S3 / 自建),你永远只有"最新版",改坏了回不去
- 分享出去的链接是活的。你改完之后,别人看到的和当初讨论的已经不是一回事,而且没人知道变了什么
- 想对比"上一版到底动了哪",只能人肉 diff 两个 100KB 的文件
这就是我最后选 Gist 的原因:每个 gist 本身就是一个完整的 git 仓库。
git clone https://gist.github.com/<gist_id>.git
于是上面那堆问题一次性没了:每次编辑自动产生一个 revision ,网页上能翻历史,能 clone 回退,能取任意历史版本的 raw 。顺带白嫖的还有:免费不限量、不用备案不用配 CI 、可 fork (别人能拿你的 demo 接着改)、可评论、可 star 、多文件、raw URL 稳定。
我拿自己这几天的东西做了个实测。有一篇 126 KB 的教程,前后改了 4 版,gist 里的 git 记录是这样的:
+2069 -0 初版
+346 -18 加了一整章泛型
+189 -4 加了泛型方法一节
+40 -9 修 sidebar 的 sticky 和滚动条
一个"巨型单文件 HTML",在 git 眼里就是正常的增量 diff——每次改了什么、改了多少,一目了然。这跟"HTML 没法做版本管理"的直觉正好相反。
于是有了 gists.page
Gist 唯一的问题是:它只给你看源码,不给你看渲染结果。
所以我做了 https://gists.page —— 把 gist id 拼在域名后面,直接看渲染出来的页面:
https://gists.page/<gist_id>/
原理一句话:Service Worker 拦截请求,从 GitHub API / raw 取内容,按扩展名返回正确的 MIME 。纯静态、没有后端、不存任何内容,跑在 Cloudflare Pages 上。相对路径引用也能解析,多文件 demo 直接传上去就行。你已经有的 gist 也不用动,把 id 贴上去就能看。
光有个网站还不够
模型并不知道这东西存在,更不知道怎么用它。所以仓库里还带了一个 skill ( Anthropic 的 Agent Skills 格式,本质就是一个带 frontmatter 的 SKILL.md,Claude Code 和 Codex 都能加载):
https://github.com/zzir/gists.page/tree/main/skills/gists-page
里面写明白了这么几件事:
- 优先写单文件
index.html,能内联就别拆多文件 - 发布路径按可用性降级:
ghCLI → GitHub MCP → REST API + curl → 实在不行让用户手动去 gist.github.com - 更新走
gh gist edit --add,或者 clone 下来 commit + push - Gist 是扁平的,没有目录,多文件得先拍平;只有精确的
index.html会被当默认页 - 别 curl 预览链接去验证——内容是 SW 渲染的,curl 只能拿到壳页面,要验证得走 GitHub API
这些条目基本都是踩出来的。装上之后,在 Claude Code 里一句 /gists-page 写一篇 xx 教程,图文并茂,发布,它自己写 HTML 、自己建 gist 、自己回一条预览链接;下次说"再加一节",它就 gh gist edit 推上去,链接不变,历史留在 gist 里。
这其实正好接上开头那个 agentic loop 的说法:产出物本身就得是可直接分享、且能沉淀下来的成品,否则每一轮都要人手动导出、找地方托管、再贴回去,还没有历史。
四篇实例
这几天我就是这么让 Claude 写了 2 篇设计模式手册:
ZH:
- https://gists.page/0152d8bc733b68dad27a477d0b45b3cd/
- https://gists.page/8599e4e8ca705edd68521c3e538eca22/
EN:
- https://gists.page/ee5d5136cc25c9f0e835308d3422e6e1/
- https://gists.page/1f32d84cd2f9bf79c307d51dbe7b047f/
每篇 17–20 张内联 SVG 结构图、明暗双主题、目录联动、代码一键复制。如果当初让它输出 Markdown ,这些图就只能退化成"文字描述一下"。
一个容易混为一谈的点
最近还有个流传的数据,说给 LLM 喂 Markdown 比喂 HTML 省 60–80% token 。这跟上面那个观点不矛盾——模型读的东西用 Markdown 省钱,模型产出给人看的东西用 HTML 信息量大,两个方向的事。
老实说下限制
- 预览只认最新版。 GitHub API 支持
/gists/{id}/{sha}取历史 revision ,但 gists.page 现在的 URL 第二段是文件名,还没做版本预览。想看旧版得自己走 raw 或者 clone 。这条我打算改,欢迎提意见 - GitHub 网页对大文件的 diff 基本折叠不给看。 100+ KB 的单文件 HTML ,想认真看改动还是得 clone 下来
git diff - 必须有 Service Worker 。curl 和爬虫只能拿到壳页面,SEO 别指望
- Gist 扁平,没有目录
- 匿名 GitHub API 60 次/小时/IP ,超了会退到 raw 端点
- Gist 里的 JS 跑在 gists.page 这个域上,别往里放密钥
站点源码和那个 skill 都在这里:https://github.com/zzir/gists.page
欢迎拍砖,尤其是 SW 那部分的实现。也欢迎 Fork 和 Star 。