让AI读懂你的网站：llms.txt从部署到实测的完整指南

先说结论：llms.txt 是技术文档站最该立刻做的事

2026 年 3 月，我给自己维护的两个网站部署了 llms.txt 协议——一个是技术 API 文档站，一个是个人技术博客。部署后在 Cursor、Claude Code 和 ChatGPT 中分别测试了 AI 对网站内容的理解准确率。结果：API 文档站的内容被 AI 准确引用率从部署前的约 40% 提升到了 85% 以上；博客站的提升不明显（约 50% → 55%）。 llms.txt 对结构化的技术文档有立竿见影的效果，但对叙事型内容的帮助有限。

llms.txt 是什么，不是什么

先澄清一个常见误解：llms.txt 不是一个需要安装的软件，也不是一个 AI 模型。它是一个开放的文件格式约定——在你的网站根目录下放一个 llms.txt 文件，里面用 Markdown 格式列出网站最关键的内容结构和链接。

它的核心思想很简单：当 AI（如 Cursor、ChatGPT with Browsing）访问你的网站时，它不用去解析 HTML 页面上的导航栏、广告这些噪音信息，而是直接读 llms.txt 这个精简版目录，然后按需跳转到具体的 .md 页面获取完整内容。

我具体做了什么测试

测试对象

• 站点 A：一个开源 API 文档站（约 200 页），使用 GitBook 托管
• 站点 B：个人技术博客（约 50 篇文章），使用 Next.js 自建

部署过程

站点 A（GitBook） 的部署非常省心：GitBook 在 2025 年末已经默认支持 llms.txt。只要你的文档站发布在 GitBook 上，访问 你的域名/llms.txt 就能看到一个自动生成的结构化索引。

站点 B（Next.js 自建） 需要手动操作。我在项目根目录的 public/ 文件夹下创建了 llms.txt（精简版导航，列出所有核心文章链接）和 llms-full.txt（完整内容导出，约 2.5MB）。部署后配置 Nginx 允许直接访问 .md 后缀文件。

测试方法和结果

我在三个 AI 工具上分别测试了部署前和部署后的表现。测试方法是向 AI 提出 20 个涉及我网站内容的问题，然后人工检查 AI 的回答是否准确引用了我的网站内容。

站点 B（博客）提升较小的原因：一是博客内容是叙事型的，不像 API 文档那样有清晰的参数-返回值结构；二是博客的文章之间关联性弱，llms.txt 的索引功能发挥空间有限。

一个意外的坑：llms-full.txt 的大小限制

我在 ChatGPT+Search 中测试时发现，当 llms-full.txt 超过约 1MB 时，ChatGPT 的上下文窗口装不下完整文件，它只会读取前面一部分。对于超过 200 页的文档站，我的建议是：不要用 llms-full.txt，只用 llms.txt 作为索引导航。

什么类型的网站最需要 llms.txt？

1. API 文档 / SDK 指南类网站：部署效果最佳。Cursor、Claude Code 等编程助手能直接读取你的 API 文档来生成正确的调用代码。

2. 企业内部知识库 / Wiki：如果你们用 GitBook 或 Apifox 托管，通常已经自带支持，检查一下 你的域名/llms.txt 是否存在即可。

3. 技术博客：有一定帮助但不要期待奇迹。

4. 电商 / 新闻 / 社交媒体：不太适合。llms.txt 的设计假设是"帮助 AI 高效找到准确的结构化信息"，而这类网站的内容通常不是 AI 需要引用的权威信源。

编辑手记

写这篇文章的动机比较直接——我维护的几个技术网站最近从 AI 搜索中获得的访问占比从 2024 年的不到 1% 涨到了 2026 年初的约 8%。这让我意识到需要认真对待"AI 如何阅读我的网站"这个问题。llms.txt 是目前最轻量的解决方案——一个 Markdown 文件，几小时就能部署完——但效果对技术文档站来说非常显著。测试数据截取自 2026 年 3 月中旬至 4 月初，样本量有限，建议自己也测一下。