Claude Code 工程师：为什么使用HTML文件作为AI规范丨How I AI

Claude Code 工程师：为什么使用HTML文件作为AI规范丨How I AI Claude Code 工程师：为什么使用HTML文件作为AI规范丨How I AI Modified May 19 🔗 原文链接： https://mp.weixin.qq.com/s/gBPJcpza... 原创 Capihom Capihom 晚点再听LaterCast2026年5月18日 22:02 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "Markdown 计划太长了，我老实说已经不读了。" "你说 Claude 可以跑 8 小时，其实是在说 Claude 可以花掉 500 美元。" "HTML 更容易读，是你和 Claude 之间更丰富的沟通媒介。" Claude Code 团队工程师 Thariq Shihipar 最近几个月一直在试一种工作流：把 AI 计划、PRD、技术 spec、设计系统，尽量从 Markdown 文档变成 HTML 文件。听起来像格式偏好，聊到后面会发现它指向一个更大的变化：当 AI 可以连续跑几个小时、写出上万 token 的计划，人类如果还想留在回路里，就需要更容易看懂、能点、能改、能协作的中间界面。Thariq 不是在讨论“文档好不好看”，他在讨论人如何持续影响 agent 的方向。计划越长，越需要把信息压成可浏览的层级、组件和状态。他甚至把每周发给上级的 status update 也做成 HTML，让 Claude 读 Slack 后整理成一份更容易被经理读完的更新。 他的判断很直接：PRD 没有消失，spec 没有消失，消失的是人愿意逐行读长 Markdown 的耐心。 这会直接影响执行质量。别跳过这里。 Markdown 计划长到没人读 Thariq 开场说，Markdown 曾经是人和 agent 互动的主流格式，尤其在 Opus 4、Claude 3.5 这类模型刚开始认真做计划时，大家还能读完 50 行方案，顺手改几处。现在 agent 能写得太多，计划越来越长，他发现自己已经开始跳过这些输出。Claire 立刻抓住这一点：一旦人类只是看一眼然后说“应该没问题”，计划的质量就会往下掉。团队最怕的是人类默认计划可信，却没有认真参与选择。长 Markdown 把责任藏在段落里，HTML 可以把责任摊开成屏幕上的模块。谁做什么、哪里有风险、哪个 demo 可能失败、哪段还要确认，都可以被放到单独卡片里。你不需要读完整篇，也能先扫到红灯和取舍。 AI 写得越快，人越需要一个能把自己拉回来的界面。 HTML 的作用，是让人愿意重新参与。 "Markdown 成了和 agent 互动的流行方式，但计划太长了，我老实说已经不读了。" 这也是很多团队在 Claude Code、Cursor、Codex 里遇到的共同尴尬：模型愿意先计划，甚至计划得很认真，但人类没有一套同样认真的阅读机制。计划并没有变少，人的参与反而变少了。 8 小时运行等于 500 美元 Claire 问他，模型越来越强之后，PRD、计划、技术 spec 还重要吗？Thariq 的回答是“百分之百重要”。原因很现实：当你说 Claude 可以跑 8 小时，你实际是在批准一笔计算预算。假设一次长任务要花 500 美元，人就必须在开跑前弄清楚，哪些工作值得交给模型，哪些目标还没说清楚，哪些未知问题要先问出来。他把这一层工作叫做 compute allocator：你仍然在写文档，只是文档的对象从“说服同事”变成了“决定一台昂贵机器接下来怎么行动”。有时目标要靠和 Claude 对话慢慢拉出来，有时要先找到 unknown unknowns。Claude 会做很多事，但它不会替你承担资源分配的责任。 AI 时代的产品和工程负责人，会越来越像计算资源分配者。 计划不是仪式，它决定机器把昂贵 token 花在哪里，也决定你事后要不要花更多 token 返工。 "所有人都在变成 compute allocator，你要决定什么值得花计算资源。" Claire 顺着这个说法开了一个玩笑：以后别人问产品管理死了以后是什么，她会回答，新的工作就是 compute allocator。玩笑背后很实在，PM 和工程负责人都要更早判断任务边界。 HTML 把 spec 变成可读界面 Thariq 强调，HTML 的优势不在于 agent 只能读 HTML。模型很聪明，Markdown、代码、纯文本都能理解。真正变化发生在人这一侧。HTML 可以有卡片、表格、颜色、mockup、交互按钮和局部状态。一个 2000 字计划，如果放在 Markdown 里，很容易变成“看起来很多”的文本墙；放进 HTML，它可以变成一张可扫读的产品页面。比如 demo 方案可以放成 8 张卡片，每张有视觉草图、适合场景、风险提示；技术决策可以放成表格，每一行都能折叠、比较、标注。计划还可以嵌入小 mockup，让验证 agent 对照“我原本想做什么”和“最后产出了什么”。这种对照会让讨论更具体：按钮、表格、状态、空页面都能被点名。 当 spec 像一个网站，人更愿意停下来比较、选择、删改和追问。 人参与得越深，模型后面执行出的产品越接近真实意图。 "HTML 更容易读，它是你和 Claude 之间更丰富的沟通媒介。" 这点对产品和工程团队尤其重要。很多争论并非来自信息缺失，而是信息没有被放在可比较的位置。HTML 让计划从“顺序阅读”变成“空间浏览”，人可以先看结构，再看细节。会议讨论也会更快进入具体取舍，减少在抽象措辞里绕圈。 先让 Claude 用 HTML 头脑风暴 现场 demo 里，他打开 Claude Code，说自己通常从一段很普通的对话开始。他告诉 Claude：我要上 Claire 的播客，想做一个 demo，帮我在 HTML 文件里 brainstorm 一些想法。提示词没有复杂模板，也没有一长串角色设定。Claude 直接生成了 8 个视觉化 demo 方案，每个方案配有小 mockup、适合 Claire 的理由，以及可能翻车的风险。有一个方案从“白板草图到可工作的 UI”，还有一个方案围绕产品从模糊想法走到工作原型。Claire 看到后说，这比一份“你可以讲这些点”的 Markdown agenda 更容易选。更关键的是，HTML 让 Claude 主动选择了适合沟通的格式，而不是只列出条目。 头脑风暴一旦变成可视化选项，人就不再只是审核文字，而是在挑一个可以真正做出来的方向。 这也是 HTML 的微妙价值：它让 Claude 先把可能性摆出来，再让人做判断。 "我总是从头脑风暴开始；有一个伙伴时，头脑风暴容易得多。" 提示词少一点，留出空间 Claire 特意停下来复盘：Thariq 的 prompt 其实很简单，大意就是创建一个 HTML 计划，帮我可视化，必要时包含摘录、mockup、代码等。她做了几十期 How I AI，发现很多高手的提示词都没有神秘到哪里去，常常只是“把东西做出来，希望它不错”。Thariq 的原则是给 Claude 足够信息，让它知道你要什么；同时不要把它绑得太死。很多过度设计的 skill 和模板，会提前替模型决定表达方式。比如你可以要求它服务某个会议、某个 demo、某个产品决策，但没必要把每个卡片长什么样都写死。模型在选择信息架构时，常常能给出人没有预设到的表达。 更好的做法是说清楚目标、约束和受众，然后让 Claude 选择最适合这件事的呈现。 对团队来说，这比追求万能提示词更可复用。 "你要给足信息，确保拿到想要的东西，但不要过度限制 Claude。" PRD 和技术 spec 可以合成一页 两人接着聊到 PRD 和 tech spec 的未来。Claire 问，产品文档和技术文档还要分开吗？Thariq 的答案更像“看受众”。如果你是一个单线程 builder，做的是一个自包含的小项目，那一份 HTML 计划里可以同时放产品想法、12 分钟 demo 流程、代码片段、风格指南和实现步骤。团队协作时，也可以按不同受众拆成多个视图：管理者看目标和风险，工程师看实现路径，设计师看界面和状态，agent 看可执行步骤。Thariq 还提到，计划可以作为 artifact 被传给下一轮实现：清空上下文后，把这份计划交给 Claude，让它按计划实现；随后再用计划做 truth check。过去文档模板很重要，因为写、找、读都很贵；现在生成成本大幅下降，格式可以围绕消费场景重新设计。 AI 时代的文档不必先服从模板，它可以先服从读者要做的决定。 "计划重要，PRD 重要，spec 也重要。" 这和过去的“先写 PRD，再写技术方案，再开评审”不完全一样。HTML 计划更像一个工作台：同一份材料里可以同时承载产品意图、技术路径、演示脚本、风险列表和验收标准。 不满意某段计划，就造个临时 UI 最有启发的一段，是他展示如何修改 HTML 计划里的一个局部表格。计划里有一段关于 CSV 数据类型的渲染规则，他不喜欢。传统做法是在终端里对 Claude 说“这里不对”，来回改文字。Thariq 换了一个方式：让 Claude 为这个局部问题生成一个临时 UI，用更适合人操作的方式调整规则，再把结果写回原计划。Claire 形容这像“micro software on top of micro software”。这个小 UI 不必长期维护，也不需要产品化，它只为一次判断服务：我怎么更快地把脑子里的偏好表达清楚。界面可以做得像一个小工具，有按钮、有选择、有即时反馈，甚至带一点消费级产品的趣味。过去没人会为修改一个表格专门做软件，现在 Claude 可以几分钟做出来。 当软件生成成本下降，一个只服务五分钟的小界面也值得被创造。 它不一定要进产品，只要能让人更好地参与计划。 "基本上，就是为这个非常具体的问题建一个一次性 UI。" 这种做法会改变人对“工具”的理解。过去只有高频流程值得做工具，现在低频、临时、局部的问题也能有自己的界面。只要它能让你少解释三轮，成本就可能已经回来了。 设计系统也可以装进 HTML 最后，他展示了另一种用法：living design system。Claude 可以读取 GitHub repo，抽取颜色、字体、间距、圆角、核心组件，再生成一个 HTML 文件代表这个设计系统。下一个项目开始时，把 design system.html 放进仓库，Claude 就能带着这份可视化语境继续工作。Claire 还补充了自己的高级做法：把营销站和 app repo 都交给 Claude，让它提炼组件级风格指南，再生成可交互组件页面，营销同事可以下载透明 PNG 放进 deck 或视频。她还想到，可以像 Claude Design 那样，在计划页面里直接圈选、评论、提交修改，让评论反过来更新核心计划。这样一来，设计系统不只是让代码别跑偏，也能让市场、销售、产品在同一组真实组件上沟通。组件的真实样子、文案长度、边距和变体，都可以一起被保存。 设计系统不再只是写给工程师看的规则表，也可以变成跨产品、设计、市场共用的活文档。 "我会去一个新项目，然后说：design system.html，而不是 design.md。" Thariq 最后把流程收束成四步：让 Claude Code 用 HTML 头脑风暴，选一个方向，用 HTML 做计划，挑一处你不满意的部分，再生成一个微型 app 来编辑它。补充动作是把设计系统也做成 HTML，放在 repo 里随项目流动。这样 Claude 每次进新项目，都能先读到可视化上下文，而不是从零猜你的审美和组件规则。 写在最后 这期最值得带走的，不是“以后都写 HTML”。更实用的动作是：凡是你发现自己已经懒得读的 AI 输出，都该被改造成更适合人参与的界面。AI 写得越多，人越要设计自己介入工作的方式。下次让 Claude 写计划时，不妨先让它做成一张你真的愿意看的页面；能被认真阅读的计划，才有机会变成更好的产品。 内容来源："Why this Claude Code engineer uses HTML files as AI specs | Thariq Shihipar (Anthropic)"丨How I AI 原视频：https://www.youtube.com/watch?v=Qrpm7E80wQ0 Audio or video is not supported Please download the file and open it with the appropriate software. 6fef0035de76473cb1c660074a1c7a37.mp4 · 253.29MB 6fef0035de76473cb1c660074a1c7a37 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/gBPJcpza... 🔗 原文链接： https://mp.weixin.qq.com/s/gBPJcpza... https://mp.weixin.qq.com/s/gBPJcpza... 原创 Capihom Capihom 晚点再听LaterCast2026年5月18日 22:02 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "Markdown 计划太长了，我老实说已经不读了。" "你说 Claude 可以跑 8 小时，其实是在说 Claude 可以花掉 500 美元。" "HTML 更容易读，是你和 Claude 之间更丰富的沟通媒介。" Claude Code 团队工程师 Thariq Shihipar 最近几个月一直在试一种工作流：把 AI 计划、PRD、技术 spec、设计系统，尽量从 Markdown 文档变成 HTML 文件。听起来像格式偏好，聊到后面会发现它指向一个更大的变化：当 AI 可以连续跑几个小时、写出上万 token 的计划，人类如果还想留在回路里，就需要更容易看懂、能点、能改、能协作的中间界面。Thariq 不是在讨论“文档好不好看”，他在讨论人如何持续影响 agent 的方向。计划越长，越需要把信息压成可浏览的层级、组件和状态。他甚至把每周发给上级的 status update 也做成 HTML，让 Claude 读 Slack 后整理成一份更容易被经理读完的更新。 他的判断很直接：PRD 没有消失，spec 没有消失，消失的是人愿意逐行读长 Markdown 的耐心。 这会直接影响执行质量。别跳过这里。 Markdown 计划长到没人读 Thariq 开场说，Markdown 曾经是人和 agent 互动的主流格式，尤其在 Opus 4、Claude 3.5 这类模型刚开始认真做计划时，大家还能读完 50 行方案，顺手改几处。现在 agent 能写得太多，计划越来越长，他发现自己已经开始跳过这些输出。Claire 立刻抓住这一点：一旦人类只是看一眼然后说“应该没问题”，计划的质量就会往下掉。团队最怕的是人类默认计划可信，却没有认真参与选择。长 Markdown 把责任藏在段落里，HTML 可以把责任摊开成屏幕上的模块。谁做什么、哪里有风险、哪个 demo 可能失败、哪段还要确认，都可以被放到单独卡片里。你不需要读完整篇，也能先扫到红灯和取舍。 AI 写得越快，人越需要一个能把自己拉回来的界面。 HTML 的作用，是让人愿意重新参与。 "Markdown 成了和 agent 互动的流行方式，但计划太长了，我老实说已经不读了。" 这也是很多团队在 Claude Code、Cursor、Codex 里遇到的共同尴尬：模型愿意先计划，甚至计划得很认真，但人类没有一套同样认真的阅读机制。计划并没有变少，人的参与反而变少了。 8 小时运行等于 500 美元 Claire 问他，模型越来越强之后，PRD、计划、技术 spec 还重要吗？Thariq 的回答是“百分之百重要”。原因很现实：当你说 Claude 可以跑 8 小时，你实际是在批准一笔计算预算。假设一次长任务要花 500 美元，人就必须在开跑前弄清楚，哪些工作值得交给模型，哪些目标还没说清楚，哪些未知问题要先问出来。他把这一层工作叫做 compute allocator：你仍然在写文档，只是文档的对象从“说服同事”变成了“决定一台昂贵机器接下来怎么行动”。有时目标要靠和 Claude 对话慢慢拉出来，有时要先找到 unknown unknowns。Claude 会做很多事，但它不会替你承担资源分配的责任。 AI 时代的产品和工程负责人，会越来越像计算资源分配者。 计划不是仪式，它决定机器把昂贵 token 花在哪里，也决定你事后要不要花更多 token 返工。 "所有人都在变成 compute allocator，你要决定什么值得花计算资源。" Claire 顺着这个说法开了一个玩笑：以后别人问产品管理死了以后是什么，她会回答，新的工作就是 compute allocator。玩笑背后很实在，PM 和工程负责人都要更早判断任务边界。 HTML 把 spec 变成可读界面 Thariq 强调，HTML 的优势不在于 agent 只能读 HTML。模型很聪明，Markdown、代码、纯文本都能理解。真正变化发生在人这一侧。HTML 可以有卡片、表格、颜色、mockup、交互按钮和局部状态。一个 2000 字计划，如果放在 Markdown 里，很容易变成“看起来很多”的文本墙；放进 HTML，它可以变成一张可扫读的产品页面。比如 demo 方案可以放成 8 张卡片，每张有视觉草图、适合场景、风险提示；技术决策可以放成表格，每一行都能折叠、比较、标注。计划还可以嵌入小 mockup，让验证 agent 对照“我原本想做什么”和“最后产出了什么”。这种对照会让讨论更具体：按钮、表格、状态、空页面都能被点名。 当 spec 像一个网站，人更愿意停下来比较、选择、删改和追问。 人参与得越深，模型后面执行出的产品越接近真实意图。 "HTML 更容易读，它是你和 Claude 之间更丰富的沟通媒介。" 这点对产品和工程团队尤其重要。很多争论并非来自信息缺失，而是信息没有被放在可比较的位置。HTML 让计划从“顺序阅读”变成“空间浏览”，人可以先看结构，再看细节。会议讨论也会更快进入具体取舍，减少在抽象措辞里绕圈。 先让 Claude 用 HTML 头脑风暴 现场 demo 里，他打开 Claude Code，说自己通常从一段很普通的对话开始。他告诉 Claude：我要上 Claire 的播客，想做一个 demo，帮我在 HTML 文件里 brainstorm 一些想法。提示词没有复杂模板，也没有一长串角色设定。Claude 直接生成了 8 个视觉化 demo 方案，每个方案配有小 mockup、适合 Claire 的理由，以及可能翻车的风险。有一个方案从“白板草图到可工作的 UI”，还有一个方案围绕产品从模糊想法走到工作原型。Claire 看到后说，这比一份“你可以讲这些点”的 Markdown agenda 更容易选。更关键的是，HTML 让 Claude 主动选择了适合沟通的格式，而不是只列出条目。 头脑风暴一旦变成可视化选项，人就不再只是审核文字，而是在挑一个可以真正做出来的方向。 这也是 HTML 的微妙价值：它让 Claude 先把可能性摆出来，再让人做判断。 "我总是从头脑风暴开始；有一个伙伴时，头脑风暴容易得多。" 提示词少一点，留出空间 Claire 特意停下来复盘：Thariq 的 prompt 其实很简单，大意就是创建一个 HTML 计划，帮我可视化，必要时包含摘录、mockup、代码等。她做了几十期 How I AI，发现很多高手的提示词都没有神秘到哪里去，常常只是“把东西做出来，希望它不错”。Thariq 的原则是给 Claude 足够信息，让它知道你要什么；同时不要把它绑得太死。很多过度设计的 skill 和模板，会提前替模型决定表达方式。比如你可以要求它服务某个会议、某个 demo、某个产品决策，但没必要把每个卡片长什么样都写死。模型在选择信息架构时，常常能给出人没有预设到的表达。 更好的做法是说清楚目标、约束和受众，然后让 Claude 选择最适合这件事的呈现。 对团队来说，这比追求万能提示词更可复用。 "你要给足信息，确保拿到想要的东西，但不要过度限制 Claude。" PRD 和技术 spec 可以合成一页 两人接着聊到 PRD 和 tech spec 的未来。Claire 问，产品文档和技术文档还要分开吗？Thariq 的答案更像“看受众”。如果你是一个单线程 builder，做的是一个自包含的小项目，那一份 HTML 计划里可以同时放产品想法、12 分钟 demo 流程、代码片段、风格指南和实现步骤。团队协作时，也可以按不同受众拆成多个视图：管理者看目标和风险，工程师看实现路径，设计师看界面和状态，agent 看可执行步骤。Thariq 还提到，计划可以作为 artifact 被传给下一轮实现：清空上下文后，把这份计划交给 Claude，让它按计划实现；随后再用计划做 truth check。过去文档模板很重要，因为写、找、读都很贵；现在生成成本大幅下降，格式可以围绕消费场景重新设计。 AI 时代的文档不必先服从模板，它可以先服从读者要做的决定。 "计划重要，PRD 重要，spec 也重要。" 这和过去的“先写 PRD，再写技术方案，再开评审”不完全一样。HTML 计划更像一个工作台：同一份材料里可以同时承载产品意图、技术路径、演示脚本、风险列表和验收标准。 不满意某段计划，就造个临时 UI 最有启发的一段，是他展示如何修改 HTML 计划里的一个局部表格。计划里有一段关于 CSV 数据类型的渲染规则，他不喜欢。传统做法是在终端里对 Claude 说“这里不对”，来回改文字。Thariq 换了一个方式：让 Claude 为这个局部问题生成一个临时 UI，用更适合人操作的方式调整规则，再把结果写回原计划。Claire 形容这像“micro software on top of micro software”。这个小 UI 不必长期维护，也不需要产品化，它只为一次判断服务：我怎么更快地把脑子里的偏好表达清楚。界面可以做得像一个小工具，有按钮、有选择、有即时反馈，甚至带一点消费级产品的趣味。过去没人会为修改一个表格专门做软件，现在 Claude 可以几分钟做出来。 当软件生成成本下降，一个只服务五分钟的小界面也值得被创造。 它不一定要进产品，只要能让人更好地参与计划。 "基本上，就是为这个非常具体的问题建一个一次性 UI。" 这种做法会改变人对“工具”的理解。过去只有高频流程值得做工具，现在低频、临时、局部的问题也能有自己的界面。只要它能让你少解释三轮，成本就可能已经回来了。 设计系统也可以装进 HTML 最后，他展示了另一种用法：living design system。Claude 可以读取 GitHub repo，抽取颜色、字体、间距、圆角、核心组件，再生成一个 HTML 文件代表这个设计系统。下一个项目开始时，把 design system.html 放进仓库，Claude 就能带着这份可视化语境继续工作。Claire 还补充了自己的高级做法：把营销站和 app repo 都交给 Claude，让它提炼组件级风格指南，再生成可交互组件页面，营销同事可以下载透明 PNG 放进 deck 或视频。她还想到，可以像 Claude Design 那样，在计划页面里直接圈选、评论、提交修改，让评论反过来更新核心计划。这样一来，设计系统不只是让代码别跑偏，也能让市场、销售、产品在同一组真实组件上沟通。组件的真实样子、文案长度、边距和变体，都可以一起被保存。 设计系统不再只是写给工程师看的规则表，也可以变成跨产品、设计、市场共用的活文档。 "我会去一个新项目，然后说：design system.html，而不是 design.md。" Thariq 最后把流程收束成四步：让 Claude Code 用 HTML 头脑风暴，选一个方向，用 HTML 做计划，挑一处你不满意的部分，再生成一个微型 app 来编辑它。补充动作是把设计系统也做成 HTML，放在 repo 里随项目流动。这样 Claude 每次进新项目，都能先读到可视化上下文，而不是从零猜你的审美和组件规则。 写在最后 这期最值得带走的，不是“以后都写 HTML”。更实用的动作是：凡是你发现自己已经懒得读的 AI 输出，都该被改造成更适合人参与的界面。AI 写得越多，人越要设计自己介入工作的方式。下次让 Claude 写计划时，不妨先让它做成一张你真的愿意看的页面；能被认真阅读的计划，才有机会变成更好的产品。 内容来源："Why this Claude Code engineer uses HTML files as AI specs | Thariq Shihipar (Anthropic)"丨How I AI 原视频：https://www.youtube.com/watch?v=Qrpm7E80wQ0 Audio or video is not supported Please download the file and open it with the appropriate software. 6fef0035de76473cb1c660074a1c7a37.mp4 · 253.29MB 6fef0035de76473cb1c660074a1c7a37 00:00 Audio or video is not supported Please download the file and open it with the appropriate software. 6fef0035de76473cb1c660074a1c7a37.mp4 · 253.29MB 6fef0035de76473cb1c660074a1c7a37 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣