部署 llms.txt

1. 四级部署与投入上限

部署 llms.txt 可以分为四级。现有证据表明，发布这个文件几乎没有成本，但后续投入仍须设限。各级解决的问题不同，实施时也不必逐级推进。

之所以要限制投入，是因为目前缺少三样东西，而且都有公开资料可查。首先，没有任何主流 AI 厂商表示自家爬虫或推理流程会读取第三方的 llms.txt。OpenAI、Anthropic 和 Perplexity 的爬虫文档都把 robots.txt 列为站长可用的控制手段，却没有提到 llms.txt；Google 更明确表示：「Doing so will neither harm nor help your site’s visibility or rankings in Google Search, as Google Search ignores them.」（这样做既不会损害也不会提升你在 Google 搜索中的可见度或排名，因为 Google 搜索会忽略这些文件，Google Search Central，2026 年 7 月）。其次，没有官方校验工具。Chrome 的 Lighthouse 检查项只确认文件能否取得，遇到 404 就记为不适用；它检查的是文件是否存在，而不是格式是否正确。最后，也没有提交入口：Search Console、Bing Webmaster Tools 和各家模型厂商都未提供此类入口。

级别	要交付什么	工作量	什么情况下停在这一级
第 1 级：一份精选文件	手写一份 llms.txt，收录约 10 到 30 条链接，并在摘要引用块中写一句关于自己的事实陈述	约一小时，此后还要持续维护	站点规模不大，结构也很少变化
第 2 级：由唯一事实源生成	改为在构建阶段输出同一份文件，并通过一个明确字段保留人工筛选的结果	一次性投入半天	站点更新速度已经超过人工维护能力
第 3 级：链接指向的 markdown	为列出的页面提供干净的 .md 版本，并通过链接关系向外声明	每套模板一到两天	确实有 AI 智能体（agent）会请求你的页面；四级中只有这一级已经确认有人使用
第 4 级：全文文件	把干净正文拼接成一个文件，并明确规定词元（token）上限	数小时，之后还要长期检查体积	页面本身就是参考资料，智能体会从头读到尾

现有数据足以帮助判断应做到哪一级。Ahrefs 分析了 137,210 个域名在 2026 年 5 月的服务器日志，发现已经发布的 llms.txt 中有 97% 从未收到请求（Ahrefs，2026 年 6 月）。这一结果与此前两次测量一致：一项覆盖 30 万域名的研究没有发现引用量因此增加；另一项研究对 10 个站点进行了 90 天的前后对比，结论是*「像对待 sitemap 那样对待它：有用的基础设施，不是增长手段」*。

从现有使用情况看，实际采用情况并不随级别依次递进。目前已经有人使用的不是第 1 级索引文件，而是第 3 级的干净 markdown：Cloudflare、Mintlify、GitBook 已将其做成现成功能，OpenAI、Anthropic、Vercel 也为自家文档提供了这种版本。部署索引文件成本低；若标准将来获得采纳，站点也已经准备就绪。它所链接的 markdown 则确实已有系统读取。

还要留意规范近期的一次更新。规范于 2026 年 8 月 10 日修订为 v2，调整了文件的可放置位置，弱化了 Optional 一节的作用，并正式纳入「markdown 版本与页面同址」的做法。按 v1 编写的部署指引如今有三处需要修正，下文会逐一说明。

2. 开始部署前：四项决策

决策	选项	经验法则
要不要做	做／不做	只有当页面多到智能体不会逐页读取，而且确实需要区分先后顺序时，才值得部署。对于只有五页的营销站，这份文件只会重复现有导航
放什么进去	精选一部分／所有网址	这个文件的主要作用是筛选。若要提供完整清单，sitemap.xml 更合适，还能提供变更信号
链接指向哪里	现有的 HTML 网址／干净的 .md 版本	指向 HTML 虽然合规，也可以正常发布，却无法实现这套约定最主要的作用：降低读取成本（§5）
谁负责保持最新	构建流程／明确指定的人／没有人	如果答案是「没有人」，文件迟早会过时；§8 给出了具体处理规则

开始前应确认五项事项：整理好页面清单并处理规范网址；明确内容存放位置，内容究竟位于代码仓库中的 markdown 源文件还是 CMS 数据库，会直接影响第 3 级的实施成本；确认页面是否经过服务端渲染；列出所有主机与子域名，因为一份文件只能覆盖自身所在路径下的网址；确定并写明词元预算。

适合部署的时机。 新站上线；信息架构或文档结构调整；CMS 或框架迁移；新增语言版本；GEO 审计发现文件缺失或已经过时；线上文件与站点不一致。

3. 第 1 级：挑选纳入的页面

3.1 挑选的标准

应当选出一批能够回答「你是谁、你做什么」等问题的页面。这些页面合在一起，应能说明你是什么、你做什么、产品怎么用、参考资料在哪里、政策条款在哪里。这份名单不是按页面流量排序的榜单。若用流量代替相关性，精选文件便失去了作用，而且通常无人察觉。

第一版草稿不必从零写起：免费的 llms.txt 生成器会抓取线上站点的站点地图与页面元数据并分节成稿，之后按下面的标准做删减即可。

分节	应该放什么	不该放什么
概览与产品	能说明你是什么、销售什么以及如何定价的页面	同一页面用于不同投放活动的变体
文档	快速上手指南、参考资料、API 接口	自动生成且没有正文的占位页
指南	值得推荐给读者的任务页	标签页、作者页、分页
政策	条款、隐私、安全说明、许可协议	上述内容的其他语言副本
Optional	更新日志、归档以及深入的背景资料	任何不应被跳过的内容

规范明确规定了两条结构规则。第一，内容被截断时，摘要引用块中的句子最有可能得到保留，因此这里应写一句关于你自己的事实陈述，而不是宣传语。第二，整个文件唯一不可缺少的元素是 H1 项目名。Optional 一节如今已经没有原先那么强的效力：v2 对它的说明是*「按约定用于次要信息：需要更短上下文时，智能体可以跳过的链接」*；规范附带的变更说明则指出，这一节原有的处理方式已连同上下文扩展工具一起从提案中移除。因此，它只能作为提示，不能保证读取系统如何处理内容。

文件应放在哪里。 v2 允许把文件放在*「网站根路径 /llms.txt，或任意子路径（例如 /docs/llms.txt）」*。每份文件覆盖自身所在路径下的网址；多份文件同时适用时，以路径层级最深的一份为准。因此，文档子目录可以单独放置一份文件，只覆盖该目录中的页面。规范明确反对将其放入 /.well-known/，因为 well-known 网址只能位于源站根目录，而很多作者只能控制其中一段路径。

多语言站点可以采用两种做法：在每个语言根目录各放一份，或在同一份文件中按语言分节，具体取决于站点的部署方式。无论采用哪种方式，只要某个分节已经标明特定语言，就不要混入其他语言的页面，除非另有明确说明。

3.2 一份填好的样例

# Northwind Analytics

> Northwind Analytics is a self-hosted product-analytics server. It ingests
> events over HTTP, stores them in ClickHouse, and exposes SQL and a query
> API. Self-hosted only; there is no managed cloud offering.

Northwind is distributed as a Docker image and a Helm chart. The docs below
are the reference an agent should read before answering questions about
setup, querying, or limits.

## Product

- [What Northwind is](https://example.com/product.md): scope, and what it deliberately does not do
- [Pricing](https://example.com/pricing.md): per-seat and per-event tiers, with the free tier's limits

## Docs

- [Quickstart](https://example.com/docs/quickstart.md): Docker Compose to first event in ten minutes
- [Query API](https://example.com/docs/api.md): endpoints, auth, rate limits, pagination
- [Event schema](https://example.com/docs/schema.md): required and reserved properties
- [Self-hosting](https://example.com/docs/self-hosting.md): sizing, backups, upgrade path

## Policy

- [Terms](https://example.com/terms.md): licence terms for the self-hosted build
- [Security](https://example.com/security.md): disclosure process and supported versions

## Optional

- [Changelog](https://example.com/changelog.md): release history, safe to skip
- [Migration from v1](https://example.com/docs/v1-migration.md): only relevant to existing v1 operators

这个样例体现了三项设计选择。摘要引用块写明了一条否定性事实，即没有托管云版本，因为智能体最容易在这一点上出错。所有链接都以 .md 结尾，所以做到第 3 级时必须实际提供这些文件。更新日志放在 Optional 中，因为缺少这一页不会改变任何答案。

4. 第 2 级：从唯一事实源生成

文件是否有用，同时取决于页面筛选是否得当、内容是否及时更新。对于每周发版的站点，手工维护的文件上线后会逐渐过时，系统却不会提示它已与站点不一致。改为自动生成，大约半天即可解决这个问题。

所谓唯一事实源，是指渲染索引页和导航时实际使用的数据，例如内容集合、CMS 查询结果或清单文件。如果生成脚本与站点渲染读取的不是同一份名单，信息不一致的问题仍然存在，还会多出一个可能与站点脱节的数据源。

进入第 2 级后仍须保留第 1 级的筛选结果，因此必须遵守一条规则：直接从完整页面清单生成，会重现第 1 级已经解决的问题。 即使改为自动生成，也要保留人工筛选的结果；具体做法是增加一个逐页设置的明确字段，供生成脚本读取。

// src/pages/llms.txt.ts: Astro 会把它构建成站点根目录下的 /llms.txt。
// .ts 后缀会被去掉，所以文件名里要写上真正的扩展名。
import { getCollection } from 'astro:content';

const SECTIONS = ['Product', 'Docs', 'Policy', 'Optional'] as const;

export async function GET() {
  const docs = await getCollection('docs', ({ data }) =>
    // 自动化之后也要保住人工挑选的结果：逐页选择加入，绝不是「全都要」。
    data.inLlmsTxt && !data.draft && !data.noindex && !data.redirectFrom
  );

  const body = SECTIONS.map((section) => {
    const rows = docs
      .filter((d) => d.data.llmsSection === section)
      .sort((a, b) => (a.data.llmsOrder ?? 99) - (b.data.llmsOrder ?? 99))
      .map((d) => `- [${d.data.title}](https://example.com/${d.slug}.md): ${d.data.summary}`);
    return rows.length ? `## ${section}\n\n${rows.join('\n')}` : null;
  }).filter(Boolean).join('\n\n');

  return new Response(
    `# Northwind Analytics\n\n> ${SUMMARY}\n\n${body}\n`,
    { headers: { 'Content-Type': 'text/plain; charset=utf-8' } },
  );
}

Astro 会将 src/pages/ 下的任意 .ts 端点构建为静态文件，文件名就是去掉 .ts 后的名称。构建过程会调用导出的 GET，再把响应正文写入文件（见 Astro 端点文档）。在 Next.js 中，可以用 Route Handler 返回一个 Response，并明确设置 Content-Type 响应头（见 Next.js route.js）。

明确设定内容类型。 托管方通常会给静态 .txt 文件设置 text/plain，但代码生成的端点若未指定内容类型，就会沿用框架默认值。浏览器显示两者时看不出区别，因此这种错误通常没有任何提示。在静态托管环境中，可以通过响应头配置文件设定内容类型。例如，Cloudflare Pages 使用纯文本的 _headers 文件，按路径应用响应头规则。

生成时要排除什么	不排除会怎样
草稿和定时发布的内容	未发布的网址会暴露给所有读取该文件的系统
带 noindex 的页面	文件中的链接会与页面自身的指令相互矛盾
会发生跳转的源网址	每次读取都要多经过一次跳转，而部分系统不会跟随跳转
其他语言的重复页面	同一内容会被重复列出，既占用篇幅，也会排挤真正需要收录的页面
标签页、作者页、分页	人工筛选的结果会退化为普通索引

5. 第 3 级：提供链接所指的 markdown

5.1 同址的 markdown 版本

这套约定能否发挥作用，取决于列出的网址能否返回干净的正文。如果链接仍然指向普通 HTML 页面，读取系统取得的内容就会包含导航、页脚和组件外壳，而这个文件原本正是为了减少这些无关内容。

v2 已将这项做法写入规范：页面应当*「在与原页面相同的网址上提供该页的干净 markdown 版本，或在网址后追加 .md（page.html.md），或把扩展名替换为 .md（page.md）」*。它还说明了 v1 未明确的查找方法：用 rel="alternate" type="text/markdown" 指定该页的 markdown 版本，用 rel="describedby" 指定覆盖该页的 llms.txt。两种关系既可以写成 HTML 的 <link> 元素，也可以通过 HTTP 的 Link: 响应头发送。

做法	怎么实现	需要注意
在 <url>.md 上提供源 markdown	由端点读取渲染该页时使用的同一个文件	只有当内容原本就是 markdown 时，实施成本才低
构建期把 HTML 转成 markdown	在构建阶段为每个页面输出一个同名的 .md 文件	必须自行保证转换质量，并专门移除页面外壳
用 Accept 做内容协商	同一个网址收到相应请求时返回 markdown	实现更简洁，但支持范围较窄；Cloudflare 的付费套餐可在边缘提供这项能力

// src/pages/[...slug].md.ts: 为每个渲染页面输出一份同名的 /<slug>.md。
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const docs = await getCollection('docs', ({ data }) => !data.draft);
  return docs.map((d) => ({ params: { slug: d.slug }, props: { doc: d } }));
}

export function GET({ props }) {
  const { doc } = props;
  // 标题、日期行、正文。不要导航，不要页脚，不要相关文章模块。
  const md = `# ${doc.data.title}\n\n_Updated ${doc.data.lastUpdated}_\n\n${doc.body}`;
  return new Response(md, {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  });
}

还应在渲染后的页面中声明这两种链接关系。这样，即使读取系统从不查看 llms.txt，也能找到干净的 markdown 副本：

<link rel="alternate" type="text/markdown" href="/docs/quickstart.md">
<link rel="describedby" href="/docs/llms.txt">

实施成本取决于内容来源。 内容原本就是 markdown 时，实施成本才低。使用 CMS 渲染的站点需要增加转换步骤；只在前端渲染的站点则须先解决服务端渲染问题。如果 .md 端点根据同一个空壳生成，返回的同样只是空文件，详见 面向 AI 爬虫的服务端渲染。生成 markdown 时，应移除导航、页脚、Cookie 提示条、相关文章栏和内嵌组件，只保留标题、日期行、正文与链接。

5.2 全文文件：必须先定预算

文件名不能混用。应用最广泛的 llms-full.txt 是文档平台推广开来的一项通行做法，Mintlify 和 GitBook 都会自动生成，但 v2 规范并未收录这个名称。官方参考工具输出的扩展文件另有一套命名。应选择其中一种已有约定，并在文件中注明采用哪种方式，不要再创造第三套命名。

必须遵守的一项限制是文件体积：先设定词元上限，再在每次构建时检查文件，超出上限就让构建失败。Mintlify 对自动生成的 llms.txt 设置了 10 万字符上限，超出后会截断；全文文件没有类似限制，很容易持续膨胀。只有当页面本身就是参考资料，而且智能体会从头读到尾时，才应生成全文文件。

6. 各技术栈如何输出

不同技术栈的实现步骤各不相同，常见错误也随之变化。下面逐项列出实施方法和需要检查的问题。

技术栈	文件从哪里来	需要检查的问题
静态站点生成器（Astro、Hugo、Eleventy、Jekyll）	第 1 级可把文件放入直接发布的静态资源目录；第 2 级改用构建期端点	检查单页应用的兜底机制是否会为所有未知路径返回 index.html 和 200 状态码；Cloudflare Pages 在缺少顶层 404.html 时就会如此
React 系框架（Next.js 及类似）	把文件放入 public 目录，或在 /llms.txt 路径编写 Route Handler	检查 Route Handler 是否明确指定内容类型，否则会返回框架的默认类型
WordPress，Yoast	25.3 起免费提供，会在网站根目录写入实际文件	默认会筛选内容：每种内容类型取最近更新的五条，而且只取十二个月内发布的内容。网站根目录必须可写，并且不支持多站点
WordPress，Rank Math	1.0.250 起免费提供，通过重写规则生成虚拟文件	安装时会预先勾选所有可用的内容类型，每种列出 50 到 100 条链接。上线前应逐项核对勾选设置
WordPress，All in One SEO	Lite 版生成 llms.txt，全文文件由 Pro 版提供	默认纳入所有公开内容类型以及所有公开分类法，每种最多 1000 条链接；这是四款插件中收录范围最广的默认设置
WordPress，SEOPress	仅 Pro 版提供，生成一份*「通过 URL 重写生成」*的虚拟文件	内容取自手工编辑的文本框，没有内容类型选择项，因此发布者必须自行精选，也必须自行更新
文档平台（Mintlify、GitBook）	平台自动生成，文件通常已经上线	先确认文件经过筛选还是一次列出全部页面，并确认你能否修改。GitBook 的全文文件会收录隐藏页面
托管建站平台（Webflow、Wix、Squarespace）	目前都提供原生功能，但各有硬性限制	Webflow 允许上传一个 UTF-8 编码且小于 100 KB 的文件，只在自定义域名上提供，不会出现在预发布域名上。Wix 每天自动生成，但手动编辑后会停止自动更新。Squarespace 仅支持 7.1，默认关闭，并且完全依靠手工输入
CDN 与边缘层	文件可在边缘生成或改写，不受源站实现限制	检查边缘层实际向外返回的内容；线上可能早已不再提供仓库中的文件，而维护者并不知情

CDN 和边缘层也会遇到与 AI 爬虫访问审计检查 robots.txt 时相同的问题：仓库里的产物可能与线上实际返回的内容不同。只有发出一次真实请求，才能确认当前生效的版本。对于 WordPress，默认设置取决于所用插件：四款插件中有三款会默认勾选全部内容，输出未经筛选的完整清单；只有 Yoast 无需额外设置就会筛选内容。Rank Math 和 SEOPress 提供的是虚拟文件，其实现方式与 WordPress 核心提供 wp-sitemap.xml 相同，都通过 add_rewrite_rule 注册重写规则，磁盘上并没有对应文件。需要修改文件却无法在磁盘上找到它时，应先确认是否属于这种情况。

7. 验证：七项检查

目前没有官方校验工具，因此必须自行完成以下检查。前四项通常一分钟内即可完成。

检查项	能证明什么	不能证明什么
每个主机上的确切路径	确认文件确实位于预期位置	无法判断文件内容是否正确
响应正文不是 HTML	确认文件没有被兜底机制或单页应用替代	无法判断 markdown 格式是否符合规范
robots.txt 没有屏蔽这个路径	确认遵守 robots.txt 的系统能够取得文件	无法证明是否真的有系统读取文件
每条链接都能打开	确认清单中没有无法访问的链接	无法判断所选链接是否指向合适的页面
抽查的 .md 版本返回 markdown	确认第 3 级已经上线	无法判断转换结果是否只保留正文
体积符合写明的预算	确认文件没有超出可用的上下文窗口	无法判断内容是否有用
与线上导航一致	确认当前筛选结果仍与站点结构相符	无法证明是否真的有系统读取文件

URL="https://example.com/llms.txt"

# 内容类型，再加一项 HTML 检查：单页应用兜底路由的顶替就靠它抓出来。
curl -sSI "$URL" | grep -i '^content-type'
curl -sS "$URL" | head -c 32 | grep -qi '<!doctype\|<html' \
  && echo "FAIL: served HTML, not text" || echo "OK: not HTML"

# 逐条取出列出的链接，记下状态码。
curl -sS "$URL" \
  | grep -oE '\]\(https?://[^)]+\)' | tr -d '](' \
  | while read -r link; do
      printf '%-64s %s\n' "$link" "$(curl -sS -o /dev/null -w '%{http_code}' "$link")"
    done

人工比对虽然无法完全交给脚本，却能发现影响严重的问题：文件可以正常取得，每条链接也都返回 200，其中的内容却还在描述两个季度前的站点结构。

8. 内容新鲜度，以及何时应删除

文件一旦与站点不一致，就可能误导仍会读取它的系统。需要关注的不是时间戳是否最新，而是内容现在是否仍然成立。内容新鲜度对这两者作了区分；对于通篇介绍其他页面的文件，后者才是判断依据。

复查应由具体事件触发，而不能只依赖固定日程。这些事件包括信息架构调整、页面删除或跳转、产品或机构改名、文档结构重整、新增语言版本，以及会改变网址形式的迁移。此外，每季度还应抽查一次，以发现上述触发条件未覆盖的变化。

# 内容一旦走样就让构建失败，而不是两个季度之后才发现。
- name: Validate llms.txt
  run: |
    set -euo pipefail
    test -s dist/llms.txt
    head -c 32 dist/llms.txt | grep -qiv '<!doctype' || { echo "served HTML"; exit 1; }
    # 粗略按每个词元四个字符估算，按你自己的预算调整。
    chars=$(wc -c < dist/llms.txt)
    [ "$chars" -lt 100000 ] || { echo "over budget: ${chars} chars"; exit 1; }
    grep -oE '\]\(https?://[^)]+\)' dist/llms.txt | tr -d '](' \
      | xargs -I{} -P8 sh -c 'curl -sSfo /dev/null "$1" || { echo "dead: $1"; exit 1; }' _ {}

无法维护时就删除。 如果没有人负责这个文件，也无法自动生成，删除是合理的选择。没有 llms.txt 不会造成任何可测量的损失：没有厂商文档声称缺少它会受到惩罚；目前规模最大的日志研究还发现，已存在的文件中有 97% 从未收到请求。相比之下，内容错误的文件可能误导少数确实会读取它的系统。厂商文章通常只说明如何添加文件，但实际维护时也要保留删除这一选项。

9. 常见失误

做法	看上去没错	实际为什么不成立
把 sitemap 全量写入	「覆盖得全」	这样会使文件失去筛选作用；若要保证完整性，sitemap.xml 更合适，还会提供变更信号
从完整页面清单生成，没有挑选字段	「我们自动化了」	这样会把第 1 级筛掉的页面重新收进清单，而且每次构建都会重复收录这些页面
直接采用 SEO 插件的默认值而不核对	「插件会处理好」	四款主流 WordPress 插件中有三款默认勾选全部内容，其中一款会为每种内容类型列出最多 1000 条链接
列的是 HTML 网址，却当作已完成第 3 级	「链接都能打开」	这种做法虽然合规，却没有提供干净正文，实际上仍然只完成了第 1 级
全文文件塞满导航外壳，超出任何上下文窗口	「提供全部内容」	部署这套文件原本就是为了减少无关内容、降低读取成本
在每周发版的站点上手工维护	「它很少变」	内容迟早会与站点不一致，而且整个流程不会自动报错
在 robots.txt 里屏蔽这个路径，或把它放在需要登录或受 WAF 限制的位置	「这是给机器人看的文件」	任何遵守 robots.txt 的系统都会因此无法访问文件
在里面写「不要用这些内容训练」	「这是面向 AI 的文件」	这个文件既不能授予访问权限，也不能拒绝访问；相关策略应通过 robots.txt 设置
期待部署它能带来引用	「这是个 AI 文件」	没有厂商表示会读取第三方的 llms.txt，Google 的文档更明确写道会忽略它
为它排一个迭代周期的工作量	「要做就做完整」	这已经超过 §1 规定的投入上限；现有证据只支持投入约一天

10. 上线清单与复查触发条件

• 精选清单以约 30 条为上限，并按相关性而不是流量选择页面
• 摘要引用块包含一句关于你自己的事实陈述，并写明关键的否定性事实
• Optional 中只放可以跳过的链接，并明确它只是一项约定，不能保证读取系统如何处理
• 文件位于能够覆盖目标内容的路径下，并已部署到范围内的每个主机
• 文件根据站点渲染所用的同一份数据生成，人工筛选字段也确实生效
• 内容类型是 text/plain 或 text/markdown，并带上字符集
• 每条链接都能正常打开，而且清单中不含会发生跳转的源网址
• 抽查的 .md 版本返回 markdown，并且已移除页面外壳（第 3 级）
• 渲染后的页面已经声明 rel="alternate" 与 rel="describedby"（第 3 级）
• 全文文件（如有）没有超出明确规定的体积预算（第 4 级）
• robots.txt 没有屏蔽该路径，WAF 规则也不会阻止访问
• CI 检查已经通过，并且有明确的负责人

复查应按照 §8 的触发条件进行。如果某家厂商公开发布文档，表示会读取第三方的 llms.txt，就需要重新判断是否值得增加投入。截至 2026 年 8 月，尚无厂商作出这种说明；这也是唯一会改变 §1 投入上限的外部因素。规范再次修订同样会触发复查，而这份规范在本月已经更新过一次。

11. 相关条目

• llms.txt：介绍文件格式，以及站点是否发布、引擎是否读取的现状；这些信息也是确定投入上限的依据
• robots.txt：决定这个文件能否被访问，但用途不同于 llms.txt
• Sitemap 与 IndexNow：用于帮助系统发现页面并获得完整清单，这些并非 llms.txt 的功能
• AI 爬虫：列出可能访问这个文件的爬虫
• 面向 AI 爬虫的服务端渲染：解释 markdown 版本为何可能与原页面一样只返回空壳
• 内容新鲜度：说明维护时如何判断内容现在是否仍然成立
• AI 爬虫访问审计：用于确认外部系统能否取得这个文件
• GEO 审计：说明这项部署在整体审计流程中的位置