用 Accept Headers 向 AI Agents 提供 Markdown
Serve Markdown to AI Agents with Accept Headers
你的网站内容其实已经存在，只需通过 Accept Headers 提供 Markdown 版本，就能让 AI Agents 直接读取核心内容，跳过导航、脚本和布局等冗余代码。这不仅大幅减少了 Token 消耗，让模型将上下文集中在你的正文上，还能提升 RAG 管道的信噪比，避免广告和弹窗干扰。更关键的是，更小的数据量意味着更快的首字延迟，让 AI 能更快开始思考。通过检查 URL 是否支持 text/markdown 响应，你可以快速评估网站的 AI 就绪程度，并参考 Nginx、Cloudflare Workers 等平台的配置指南进行优化。
你的网站已经拥有内容，提供 Markdown 变体能让 AI 客户端跳过导航、脚本和布局标记，直接读取内容。
HN 评论区
69- k1m
我同意 Roy Fielding 的观点：
> 在每次请求中发送一堆头部字段，仅仅为了告诉服务器用户持有的所有可能的偏好变化，这是一种糟糕的设计权衡，尤其是当这些维度中的任何一个适用于目标资源的可能性微乎其微时。自从 1993-94 年那段极短的时期（当时人们不知道哪种图像格式能在所有用户代理上可用，且没有 CSS 或 JavaScript 来实现客户端自适应）以来，这一直是一种糟糕的设计权衡。
> ...主动协商对缓存的影响远比反应式协商每站点多一次往返要糟糕得多，而且即使在支持客户端自适应的格式中，那一次往返也是不必要的。
关于缓存影响，Simon Willison 写道：
> ...你无法将使用 Accept 头部进行内容协商的应用部署在 Cloudflare CDN 之后——例如，根据传入的 Accept 头部为同一 URL 提供 JSON 或 HTML。如果你这样做，Cloudflare 可能会将缓存的 JSON 提供给 HTML 客户端，反之亦然。
注：我在另一条评论中发布了这两段引文及其链接，当时无法轻松复制，稍后会补充。
- MiroslavPokorny
为什么任何网站愿意额外花精力以 Markdown 形式“提供”他们的内容给 AI，却得不到任何回报？
- joshum97
我觉得自己快要疯了。谁脑子正常会把原始 HTML 直接喂给 LLM 啊？
HTML 是一种标记语言。用户代理以适合用户的方式呈现它——无论是视觉上还是通过辅助技术。引入 LLM“用户”不应该改变这一点——它们的用户代理（即 harness）应该以它们原生理解的方式呈现 HTML，也就是将其转换为 Markdown。
我们不会仅仅因为 harness 开发者太懒或太蠢，懒得从 npm 上拉一个 HTML 转 Markdown 的包，就重写整个互联网。如果有些网站确实想这么做，那很好，在很多情况下，我也很乐意跳过 CSS/JS，直接阅读 Markdown（或者更好，格式美观的 Markdown）。但别怪网站作者，是你们自己的 harness 浪费了你们的 token。
- lekevicius
除非前四大 AI 聊天机器人中的任何一个表示它们将开始使用这个头部发起请求，否则我不会这么做。在此之前，这只是一个很酷但无人采用的想法。
我也认为，前四大聊天机器人中任何一个选择以这种方式加载网站的可能性极低。即使多年后采用率也只有 0.01%，风险也太大了。
- collimarco
那干净、语义化的 HTML 呢？
它本来就是为机器人和搜索引擎（它们也是机器人）优化的，而且已经使用了数十年。为什么现在需要以 Markdown 形式提供？
此外，HTML 的许多部分（如导航栏）对机器人和 AI 很有用，但在 Markdown 版本中可能会被移除。