llms.txt 这两年被讨论得很多，而且讨论两极分化。一边说这是 AI 时代的 robots.txt，不做就落后；另一边说根本没有模型读它，纯属自我安慰。

两种说法都比官方文档说得更满。

llms.txt 是什么，是谁提出的

llms.txt 是 Jeremy Howard 在 2024 年 9 月提出的一个提案，发布在 llmstxt.org。提案的原意是在网站上放一个 /llms.txt 文件，帮助智能体和大模型使用这个网站。

它的格式用 Markdown 写，结构很简单：

  1. 一个一级标题，写项目或机构的名称，这是唯一必需的部分
  2. 一段引用块，用几句话概括这个站点，写清理解后文需要的关键信息
  3. 若干个二级标题分组，每组下面是链接列表，指向可以进一步阅读的页面
  4. 按约定，一个名为 Optional 的分组，放在上下文不够时可以跳过的次要链接

提案还建议，重要页面同时提供一个干净的 Markdown 版本，地址是原网址后加 .md。

需要说清楚的一点：提案自己的措辞是推动标准化的提议，它不是 W3C 或 IETF 那种正式标准。作为对照，robots.txt 在 2022 年已经成为 IETF 的 RFC 9309。

llms.txt 有没有用：官方文档的三种表态

判断有没有用，最可靠的依据是读取方自己怎么说。目前能找到的官方表态，方向并不一致。

来源官方表态对企业官网的含义
Google 搜索中心出现在 AI 功能里不需要新建机器可读文件、AI 文本文件或特殊标记不是进入 Google AI 摘要的条件
Chrome Lighthouse列为智能体浏览检查项；文件缺失时判为不适用，取回出错时才会被标出提供与否目前是可选的
大模型厂商的开发者文档提案页列出 OpenAI、Anthropic、Gemini 为自家开发者文档发布了 llms.txt说明它们自己在用，不等于它们的搜索会读
国内六家 AI 平台截至本文写作，我们没有找到任何一家公开说明读取 llms.txt没有证据支持，也没有证据否定

同一家公司的两个产品给出了两种信号。Google 搜索中心在 2025 年 12 月更新的页面里写明，出现在 AI 功能中不需要任何新的机器可读文件，也没有需要额外添加的特殊结构化数据。而 Chrome 的 Lighthouse 在 2026 年 5 月更新的文档里，把 llms.txt 放进了智能体浏览的检查项，同时说明文件缺失时审计结果为不适用，因为目前提供这份文件是可选的。

这两者并不矛盾。前者说的是搜索排名和 AI 摘要，后者说的是智能体在浏览网站时怎么理解站点结构。llms.txt 的用途更接近后者。

2024年9月llms.txt 提案发布llmstxt.org
2022年9月robots.txt 规则成为 RFC 9309IETF

国内 AI 平台读不读 llms.txt

这是国内企业最关心的问题，也是最没有答案的问题。

DeepSeek、豆包、文心一言、通义千问、腾讯元宝、Kimi，截至本文写作，我们没有在它们的公开文档里找到任何关于 llms.txt 的说明。这既不能证明它们不读，也不能证明它们读。

在这种情况下，把 llms.txt 当成提升国内 AI 可见度的手段去宣传，是说过头了。反过来，因为没有官方确认就断定它毫无价值，同样说过头了。更准确的定位是：一份成本很低、没有已知坏处、收益尚未被证实的站点说明。

llms.txt 怎么写：写给一个不认识这家公司的读者

大部分 llms.txt 写得没用，不是因为格式错，而是因为内容像一份网站导航的复制品。

一份有用的 llms.txt，读起来应该像给一位完全不认识这家公司的研究员写的简介。几件事要写清楚：这家机构是做什么的，服务哪些客户，最重要的页面是哪几个，以及不做什么。最后这一项最常被漏掉，却最能防止模型把业务范围说大。

最后一条值得多说一句。一份和官网正文相互矛盾的 llms.txt，比没有更糟。如果真有模型读它，读到的是两套说法；如果没有模型读它，它也在提醒团队官网本身的事实还没统一。

一份企业官网的 llms.txt 大致分几块

对一家普通企业来说，不需要复杂的结构。下面这种分法足够覆盖大多数情况。

部分写什么最常见的问题
一级标题品牌名称，必要时附公司全称只写简称，和工商登记名对不上
引用块主营业务、服务对象、服务地域写成广告语，没有一句可核对
主体信息法人主体、地址、联系方式、备案号和官网页脚、地图资料不一致
核心页面服务、价格说明、常见问题，各附一句说明把导航菜单原样搬进来
不做的事明确不提供的业务与不作的承诺整段缺失
Optional博客、新闻等次要内容放得比核心页面还多

还有一个实际问题是维护。很多站点的 llms.txt 是一次性手写的，半年后服务调整了、页面改版了，文件还停在上线那天，里面的链接一半是死链。比较稳妥的做法是让它从站点数据自动生成，页面增删时跟着变。本站的那一份就是在构建时从页面数据生成的，不需要单独维护。

至于提案建议的 Markdown 版本页面，对企业官网来说优先级更低。它的成本是每个页面多维护一个版本，收益取决于有没有读取方真的去取。更实际的替代是确保原页面本身在不执行脚本时就能读出完整正文，这样无论读取方取的是哪个版本，看到的都是同样的内容。

比 llms.txt 更该先做的事

站在优先级的角度，llms.txt 应该排在后面。

排在它前面的，是那些已经有明确机制的事情。AI 爬虫能不能访问站点，由 robots.txt 规则、CDN 和防火墙共同决定；RFC 9309 自己也说明，这些规则不是访问授权，而是请求爬虫遵守。页面在不执行 JavaScript 的情况下有没有内容，决定了不执行脚本的抓取程序能不能读到正文。结构化数据是否只标注了页面上真实可见的内容，决定了它会不会被当成可信信息。

这些检查我们放在 官网 AI 可读性体检 里一起做，llms.txt 是交付物之一，但不是重点。本站根目录的那一份，末尾专门有一节写我们不做的事。词条层面的定义见 llms.txt 词条。

所以回到标题的问题。llms.txt 有没有用，目前的诚实回答是：对智能体理解站点结构有一个官方工具在检查它，对 Google 的 AI 摘要官方明确说不需要，对国内平台没有公开信息。它值得花半小时写好，不值得花一个项目去做。

参考来源