Markdown 长到没人读了，换成 HTML 才能把人拉回 Claude 的决策回路
HTML 的信息密度比 Markdown 高，Claude 能读到的信息几乎都能用 HTML 高效表达出来。
HTML 自带多种表达通道：表格、CSS、SVG、script、可交互元素、绝对定位或 canvas、图片。Markdown 只有标题和格式，模型只能退回 ASCII 图、用 unicode 字符凑颜色色块这种低效办法（见 ¶16）。表达通道多了，同样的信息需要绕的弯就少，人审阅起来也更快。
“almost no set of information that Claude can read” ¶15
文章没讲怎么验证 HTML 本身是否正确：交互脚本可能不执行，或只在部分环境下能用。
真正的瓶颈是人读不下去：作者自己基本不读超过 100 行的 Markdown，更别说让同事去读。HTML 能用标签页、插图、链接把结构摆清楚，还能适配手机。
把注意力成本转到版式上：长 spec 先按导航结构拆开（作者举例是 Overview/API/Rollout 三个标签页加图表），读者按需跳读，不用从头滚到尾。分享时 HTML 浏览器直接能打开、发个链接就行，Markdown 往往只能当附件（见 ¶19-¶21）。
“I tend to not actually read more than a 100-line Markdown file” ¶17
「100 行以上就不读」「HTML 被阅读的概率高得多」都是作者个人感受，没有数据。¶76 用 Opus 4.7 的 1MM 上下文说明 token 增量「不明显」，这是上下文占用的口径，不是计费口径，也没算输出变长带来的延迟。
一次性编辑界面：不是产品，也不是可复用工具，只是为这一份数据专门写的单个 HTML 文件，最后必须带一个导出按钮。
有些东西很难用文本框说清楚，比如颜色、缓动曲线、拖拽排序、带依赖的配置，在 UI 里直接操作更准。导出按钮把 UI 里的操作变回能粘贴进 Claude Code 或提交进仓库的文本，人还在回路里，但每一轮来回短得多。
“The trick is always to end with an export” ¶63
一次性编辑器加导出按钮的套路很容易复现，代价也低，可以拿真实的待决事项马上试。
用 Claude Code 而不是 Claude.ai 或 Claude Design 来生成 HTML，主要好处是它能读到的上下文多。
Claude Code 能读文件系统、MCP（Slack、Linear 等）、浏览器（Claude in Chrome）和 git 历史，生成的 HTML 有真实数据撑着，不是凭空排版。作者本文的配图，就是让 Claude Code 扫了他自己生成过的 HTML 文件、归类之后画出来的。
“all of the context Claude Code can ingest” ¶24
作者是 Anthropic 技术人员，文末声明是个人观点（¶81），但全文都在推 Claude Code、Claude Design、Claude in Chrome 和 MCP 生态，HTML 的好处和用更多厂商工具绑在了一起。
规划不再是一份单一的计划文档，而是一组 HTML 文件：探索、mockup、实现计划。之后整组交给新会话去实现，也交给验证 agent 去核对。
每个阶段的产物单独成一个文件，留作参考。实现会话和验证会话拿到的不只是结论，还有当初探索过的备选方案和取舍，因此「对需求的理解更全面」（见 ¶29、¶78）。说白了就是把会话之间的上下文交接，从压缩后的摘要换成了完整的工件。
“create a new session and pass in all of these files” ¶28
¶28-¶29 说把一组 HTML 交给实现或验证会话能带来更全面的上下文，但没有和「交 Markdown 计划」做过对照；HTML 里的样式和脚本对下游模型来说可能是噪声。
作者自己说，换成 HTML 的真正原因是保持在回路里：Claude 接手的活越多，他越不细读计划，HTML 让他重新参与到 Claude 的选择里。
他把监督衰减当作一个人因问题来处理：计划不是错了，而是没人读，所以要降低读的成本。在这个框架里，HTML 是让人继续参与审阅的手段，不是为了好看。
“it helps me feel much more in the loop with Claude” ¶79
这一点暂无对应的审视。
作者没有直接谈到这一点。
文章没谈分享和托管的安全与合规：HTML 可以带脚本，上传链接相当于对外发布，可能被缓存或索引。
编辑器本身用完就扔，关键是最后的导出：把人在界面里的判断变回能交给 Claude 的文本
HTML 的信息密度比 Markdown 高，Claude 能读到的信息几乎都能用 HTML 高效表达出来。
HTML 自带多种表达通道：表格、CSS、SVG、script、可交互元素、绝对定位或 canvas、图片。Markdown 只有标题和格式，模型只能退回 ASCII 图、用 unicode 字符凑颜色色块这种低效办法（见 ¶16）。表达通道多了，同样的信息需要绕的弯就少，人审阅起来也更快。
almost no set of information that Claude can read
¶15 ↗
真正的瓶颈是人读不下去：作者自己基本不读超过 100 行的 Markdown，更别说让同事去读。HTML 能用标签页、插图、链接把结构摆清楚，还能适配手机。
把注意力成本转到版式上：长 spec 先按导航结构拆开（作者举例是 Overview/API/Rollout 三个标签页加图表），读者按需跳读，不用从头滚到尾。分享时 HTML 浏览器直接能打开、发个链接就行，Markdown 往往只能当附件（见 ¶19-¶21）。
I tend to not actually read more than a 100-line Markdown file
¶17 ↗
一次性编辑界面：不是产品，也不是可复用工具，只是为这一份数据专门写的单个 HTML 文件，最后必须带一个导出按钮。
有些东西很难用文本框说清楚，比如颜色、缓动曲线、拖拽排序、带依赖的配置，在 UI 里直接操作更准。导出按钮把 UI 里的操作变回能粘贴进 Claude Code 或提交进仓库的文本，人还在回路里，但每一轮来回短得多。
The trick is always to end with an export
¶63 ↗
用 Claude Code 而不是 Claude.ai 或 Claude Design 来生成 HTML，主要好处是它能读到的上下文多。
Claude Code 能读文件系统、MCP（Slack、Linear 等）、浏览器（Claude in Chrome）和 git 历史，生成的 HTML 有真实数据撑着，不是凭空排版。作者本文的配图，就是让 Claude Code 扫了他自己生成过的 HTML 文件、归类之后画出来的。
all of the context Claude Code can ingest
¶24 ↗
规划不再是一份单一的计划文档，而是一组 HTML 文件：探索、mockup、实现计划。之后整组交给新会话去实现，也交给验证 agent 去核对。
每个阶段的产物单独成一个文件，留作参考。实现会话和验证会话拿到的不只是结论，还有当初探索过的备选方案和取舍，因此「对需求的理解更全面」（见 ¶29、¶78）。说白了就是把会话之间的上下文交接，从压缩后的摘要换成了完整的工件。
create a new session and pass in all of these files
¶28 ↗
作者自己说，换成 HTML 的真正原因是保持在回路里：Claude 接手的活越多，他越不细读计划，HTML 让他重新参与到 Claude 的选择里。
他把监督衰减当作一个人因问题来处理：计划不是错了，而是没人读，所以要降低读的成本。在这个框架里，HTML 是让人继续参与审阅的手段，不是为了好看。
it helps me feel much more in the loop with Claude
¶79 ↗
作者是 Anthropic 技术人员，文末声明是个人观点（¶81），但全文都在推 Claude Code、Claude Design、Claude in Chrome 和 MCP 生态，HTML 的好处和用更多厂商工具绑在了一起。
「100 行以上就不读」「HTML 被阅读的概率高得多」都是作者个人感受，没有数据。¶76 用 Opus 4.7 的 1MM 上下文说明 token 增量「不明显」，这是上下文占用的口径，不是计费口径，也没算输出变长带来的延迟。
一次性编辑器加导出按钮的套路很容易复现，代价也低，可以拿真实的待决事项马上试。
文章没讲怎么验证 HTML 本身是否正确：交互脚本可能不执行，或只在部分环境下能用。
文章没谈分享和托管的安全与合规：HTML 可以带脚本，上传链接相当于对外发布，可能被缓存或索引。
¶28-¶29 说把一组 HTML 交给实现或验证会话能带来更全面的上下文，但没有和「交 Markdown 计划」做过对照；HTML 里的样式和脚本对下游模型来说可能是噪声。