先泼一盆冷水如果你的网站在大模型眼里一直“存在感极低”可能不是内容不行而是你还没给它一份“读起来舒服”的资料。LLMs 处理网页时面对的往往是导航栏、广告位、动态脚本和一堆重复边栏真正有价值的信息被淹没在噪声里。我一直觉得大模型不是读不懂你的网站而是你从未按它习惯的方式组织内容。于是就有了 Llms.txt——一个放在网站根目录、用 Markdown 写成的纯文本文件告诉任何路过的 AI这个站点是什么、重点看哪些页面、每个页面的价值是什么。如果你正运营博客、文档站、产品官网或者在做 RAG、Agent、AI 搜索类应用这篇文章就是给你准备的手把手教你把它配好、验证好、用起来。1. 先搞清楚Llms.txt 到底解决什么问题1.1 大模型读网站时到底有多痛苦先说个我自己的例子。之前有个开源项目官网首页写得清清楚楚产品定位、三大功能模块、快速开始链接。结果让 ChatGPT 浏览网页摘要产品特点它给我提炼出的功能竟然是“支持在线聊天”——其实那只是首页一个悬浮客服组件。问题出在哪模型抓取整页 HTML 时信息密度太高、噪音太多它对“哪几句是真正的产品核心描述”判断错了。这几乎每个站长都遇到过。LLM 浏览网页时本质上会把整个页面渲染成文本再放入上下文。一个普通页面如果包含 5000 token 的导航、广告、脚本和推荐位那核心内容可能只有 800 token。上下文窗口再大也有极限模型只能在有限预算内判断哪些内容值得保留。它读得越多、越乱越容易理解偏。Llms.txt 就是来解决这个“信息预算”问题的。它不等同于网页本身而是一张高压缩比的内容地图。你可以把最关键的定位、入口、文档、FAQ 都写在里面让模型在接触完整页面前就已经知道“这事儿的重点是什么”。一句话它不是给搜索引擎爬虫用的是给 LLM 用的说明书。1.2 它和 robots.txt、sitemap.xml 是什么关系很多人一听“放根目录的 txt 文件”立刻想到 robots.txt。这俩完全是两码事。robots.txt 是给爬虫下达“允许还是禁止”的指令它解决的是访问权限。sitemap.xml 是告诉搜索引擎“你有哪些页面需要收录”它解决的是页面发现。而 llms.txt 的目标是让 AI 在抓到页面之后能立刻理解“这网站是干嘛的、哪些内容最重要”。一个比较形象的类比如果网站是家公司robots.txt 是前台保安决定谁可以进门sitemap.xml 是公司组织架构图告诉你有哪些部门llms.txt 则是前台放的接待手册写清楚公司最核心的业务和每个关键文档在哪。三者可以共存且各自负责不同环节。我用表格整理过它们的区别放在这方便你对比文件核心目的主要使用者格式放在哪robots.txt控制爬虫访问权限搜索引擎爬虫、AI 爬虫纯文本指令根目录sitemap.xml列出需要收录的 URL搜索引擎爬虫XML根目录或子路径llms.txt提供站点摘要和关键链接大语言模型、AI 应用Markdown 风格纯文本根目录所以千万别把 llms.txt 当成 robots.txt 的替代品。它只是多了一层“内容理解”帮你把网页里的高价值信息提炼出来让模型少走弯路。对任何希望被 AI 正确引用的站点来说这三者缺一不可。1.3 谁最该赶紧去配一份并不是所有网站都急着上 llms.txt但下面这几类站点的收益特别明显。第一类是文档和知识库。技术文档天然适合被模型读取但文档站通常有大量侧边栏、面包屑、版本切换脚本模型抓取时经常把“上一版本文档”误当成当前内容。一份 llms.txt 可以直接把最新版、最核心的文档链接拉出来并注明“这是当前推荐阅读的版本”效果立竿见影。第二类是产品官网和 SaaS 落地页。这类页面设计感强很多内容藏在图片、交互里模型根本读不到。llms.txt 可以写清楚产品定位、目标用户、核心功能和使用场景让 AI 在推荐商品或回答“有没有类似工具”时把你列进去而不是竞争对手。第三类是 RAG 和 Agent 应用开发者。我见过很多团队辛辛苦苦抓取网站做向量库结果因为源网页噪声太大检索出来的片段全是页面头部和底部导航。如果先读取 llms.txt作为种子文档再按需抓取它指向的高价值页面整个数据管线的质量会立刻提升一个档次。说到底它就是一份“AI 时代的内容摘要卡”。早配早受益而且成本极低剩下的时间和精力投入非常划算。2. 动手之前先把 Llms.txt 的语法和规范吃透2.1 文件格式极其简单但细节不能错Llms.txt 的规范故意设计得很轻。它本质上就是一个 UTF-8 编码的纯文本文件放在网站根目录命名为llms.txt。内容采用 Markdown 风格但不要求完整渲染关键是“人眼能读懂、模型容易解析”。最基础的结构可以只有三部分一级标题写站点名称引用块写站点定位然后用无序列表给出最重要的链接。我平时习惯先按官方推荐的骨架来写再根据站点情况加少量区块像这样# LogoLy LogoLy 是一个开源的轻量级日志采集与可视化工具适合中小团队快速搭建日志分析平台。 - [文档首页](https://logly.example.com/docs/): 包含安装、快速开始和全部 API 参考 - [GitHub 仓库](https://github.com/example/logly): 源码、Issue 和 Release 说明 - [使用指南](https://logly.example.com/guide/): 面向新手的操作教程 - [常见问题](https://logly.example.com/faq/): 部署和排障经验汇总注意一点这不是要你把页面标题复制一遍而是要求每个链接后面都用冒号加一句话说清楚这个页面里有什么、对模型有什么用。模型在看到链接文字之前先读到这句话就能判断是否值得进一步访问。这个“链接一句话描述”的组合是整个文件的灵魂。2.2 内容挑选的艺术别把整站都塞进去很多人第一次写 llms.txt容易走进“越多越好”的陷阱。我见过有人把 500 多个 URL 全列进去美其名曰完整索引。但实际上大模型读取 llms.txt 时同样受限于上下文长度和信息噪音。链接过多、描述模糊反而会稀释核心信息的权重。我的经验是llms.txt 里的链接要满足两个条件高价值、稳定。页面包含“关于我们”“产品介绍”“核心文档”“最新版发布说明”“FAQ”这类值得放。登录后的用户中心、临时活动页、带复杂参数的商品筛选页、纯广告引导页不要放。另外像“2024年暑期大促”这种会过期的内容也不该占名额。举个例子如果是电商站不需要列每一个商品详情页而是列“全部商品分类页”“热卖榜单”“退换货政策”这些入口。模型需要的不是你整站的目录而是它回答关于你品牌的问题时最该引用的那几个“锚点页面”。写描述时也要尽量客观不要写太多营销话术。比如一个工具站你可以写“支持十人以下团队免费使用”但不要写“功能最强大、秒杀一切同类”。模型有判断能力过度夸大的描述反而会降低可信度。2.3 多语言站点与多产品线怎么组织如果你的站点有中英文多个版本或者一个域名下同时有多个产品线直接在单个 llms.txt 里全塞进去会显得混乱。一个可行的做法是根目录的 llms.txt 做总纲指向各语言或各产品线的子说明文件并通过链接区分清楚。英文站可以这样English Site Summary : Overview of all English docs产品 A 文档 : ...产品 B 文档 : ...同样如果你的内容有多个层级可以在 llms.txt 里用二级标题分区块比如“## 产品文档”“## 公司信息”“## 支持资源”让模型可以快速定位到关心的部分。组织结构清晰一点解析脚本写起来也更简单后续维护也更省心。唯一要避免的是为了追求复杂而复杂。规范本身是灵活的你的网站内容形态决定了文件结构。3. 实操过程从零到一配置一份可用的 llms.txt3.1 第一步盘点站点内容画一张信息地图动手写文件之前我会先做一份“内容地图”避免遗漏重要信息。简单方法是准备一个表格把所有候选链接列出来分三列比较页面定位、目标用户、是否值得放进 llms.txt。比如一个刚上线的开源监控项目我可能这样梳理页面路径页面定位是否放 llms.txt/首页产品定位和核心卖点不直接放因为首页噪声高/docs/quickstart快速上手指南放最重要入口/docs/apiAPI 详细参考放/blog/团队博客可选建议精选高价值文章/operator-login运维后台登录页绝不放这个步骤花不了太久但能让你后续写出来的文件有主线、有取舍而不是随手拈来的 URL 大杂烩。3.2 第二步按模板写摘要与链接描述信息地图画完后就可以动手写正文了。我习惯先写一个“一句话定位”格式固定为“XXX 是什么 解决什么问题 适合谁”。这个定位会放在 llms.txt 的引用块里是模型理解你的第一步务必反复打磨。然后根据信息地图把每个核心页面写成一个链接条目。格式统一为页面标题 : 一句话说明这个页面包含什么。这里的说明不应该是页面的简单重复而要写出“模型看了这个页面能得到什么价值”。例如不要写“快速开始页面”而要写“从零开始安装并运行项目约十分钟可完成首个 Demo”。后者信息量更大模型会更愿意点进去。我还喜欢在文件的中间位置加入一小段“产品上下文”用自然语言补充分页面上可能没有的细节比如开源协议、技术栈、版本适配情况。这些信息对模型回答技术选型类问题非常重要而在首页上往往只是一行小字。3.3 第三步部署、校验与发布文件写好后把它放到服务器根目录/llms.txt并确保通过 HTTPS 可以被公开访问。这里有几个校验点非常容易被忽略。第一是文件编码必须是 UTF-8尤其注意中文内容不要用带 BOM 的格式否则解析时可能多出不可见字符。第二是响应头最好带上Content-Type: text/plain; charsetutf-8避免某些服务器用默认的 HTML 类型返回。第三是确认没有重定向比如从https://example.com/llms.txt301 跳转到别的路径会影响部分严格解析的客户端。上传后我一般会用 curl 快速验证一下curl -s https://example.com/llms.txt | head -50这条命令能确认文件能否正常访问、前 50 行内容是否完整。如果返回的是 HTML 错误页就需要检查服务器配置和文件位置了。3.4 让模型更容易发现它文件放在根目录不等于模型一定会读它。目前还没有统一的“提交 llms.txt”入口模型是否能发现它主要取决于爬虫是否抓取到了这个链接。所以我的建议是把 llms.txt 的链接光明正大地放进网站主页的页脚或“关于页面”里比如加一个AI 可读版本的文本链接。这样当 AI 爬虫访问首页时可以顺着链接发现这个文件。也可以在 robots.txt 里显式允许爬取该文件避免被某些禁止规则误伤。另外如果你的网站做了 sitemap可以把 llms.txt 的 URL 作为一个普通页面加进去。虽然它不是 HTML 页面但多一条曝光路径总没有坏处。记住一个核心逻辑你是想让 AI 优先读这份说明而不是整天在页面里猜重点。4. 进阶玩法让 LLM 读完还能“用起来”4.1 把 llms.txt 变成 RAG 管线的种子文档配置文件不只是给在线爬虫看的它非常适合作为 RAG 系统的前置索引。做一个简单的知识库问答应用时没必要把所有网页一次性全抓下来更好的流程是先读取 llms.txt解析出高价值链接列表再按需抓取这些链接指向的页面最后切块向量化。下面这段 Python 示例代码可以做最基础的解析工作import re import requests def fetch_llms_txt(base_url): txt_url base_url.rstrip(/) /llms.txt resp requests.get(txt_url, timeout10) resp.raise_for_status() return resp.text def parse_links_from_llms_txt(text): pattern r\[([^\]])\]\((https?://[^)])\):\s*(.*) items [] for line in text.splitlines(): m re.match(pattern, line.strip()) if m: title, url, desc m.groups() items.append({title: title, url: url, desc: desc}) return items text fetch_llms_txt(https://example.com) for item in parse_links_from_llms_txt(text): print(item[title], item[url], item[desc])其实这个脚本的本质是“把结构化地图解析出来”。拿到链接之后你可以只抓取其中质量最高的 20 个页面做向量化。相比整站递归抓取数据量和噪声都大幅下降检索准确率通常会好很多。4.2 用 llms.txt 持续优化模型回答的一致性如果你希望大模型对外展示的品牌信息保持统一llms.txt 还是一个绝佳的“标准答案源”。我做过一个测试让模型只浏览 llms.txt再进行规则提问比如“这个工具支持哪些平台”“开源协议是什么”“是否免费”。模型给出的回答一致性明显好于让它浏览完整网页。更进阶的做法是把 llms.txt 作为提示词的一部分注入系统消息或者作为评估基准。比如做一套自动化巡检脚本定期用 llms.txt 生成几道标准题再过一遍模型看它的回答是否和文件里的信息发生冲突。如果冲突说明模型的上下文里混入了错误信息可以及时调整抓取策略。这里要注意的是llms.txt 不是拿来操纵模型的而是提供更准确的信息入口。不要把它写成一篇自卖自夸的软文那反而会适得其反。客观、简洁、可验证才是这个文件真正有价值的点。4.3 内容侧标准与模型侧适配的关系大模型领域迭代很快像 time-llama 这类通过动态低秩适配让 LLM 做时序预测的工作也越来越多。很多人问既然模型都能通过微调、适配来理解数据了是不是就不需要 llms.txt 了我的看法是这两者解决的问题不在同一个维度。模型侧适配解决的是“能力”问题让模型更好地理解某种格式或领域llms.txt 解决的是“入口”问题让模型更快、更准确找到该理解的网站内容。哪怕未来模型能力再强它面对一个信息混乱的网页还是需要一份清晰索引来降低不确定度。内容侧的结构化永远不会过时。所以如果你在做 AI 搜索或 Agent除了关注模型选型、微调方法也别忘了把自己服务的数据源整理干净。llms.txt 就是一个低成本的切入点。5. 常见问题与排查技巧实录5.1 大模型还是读不到我的 llms.txt最让人头疼的情况是文件放好了curl 也能访问但模型回复里就是没有体现新内容。这时候先别急着怀疑文件没用按照下面顺序排查。首先要看你的 robots.txt 是否允许 AI 爬虫抓取根目录文件。有些站点为了减少资源消耗设置了Disallow: /这会把 llms.txt 一起挡住。如果不希望全站开放至少单独放行这个文件。其次是检查文件是否被 HTTP 缓存或 CDN 缓存过旧版本。如果你更新了 llms.txt要确认源站和 CDN 都刷新了否则模型读到的还是旧内容。别小看这个问题我踩过好几次坑改了文件没刷 CDN结果大半天里所有访问都是缓存版本。最后是耐心。AI 搜索引擎和模型提供方都有自己的抓取周期不是实时更新的。你今天刚部署的文件可能一周后才被某个模型内置。不要用“两小时后看不到效果”就判定失败可以持续观察再根据反馈优化。5.2 文件里放多少链接才算合适关于链接数量没有绝对标准但根据我的经验核心站点一般控制在 20 到 50 个高质量链接之间。内容特别庞大的文档站可以分区块但单个区块内的链接不宜过多否则解析容易失去重点。还有一个隐藏原则每条链接的描述不要写得像标签堆砌。你写“功能强大、稳定、高效、安全”这种词对模型没有信息增量。相反你写“支持 MySQL 和 PostgreSQL提供 Helm 部署方式适合 Kubernetes 环境”这种具体信息模型才能真的理解页面价值。如果站点内容实在太多可以在 llms.txt 里指出“完整文档入口”的大类链接而不是穷举每一个子页面。就像一本书目录只展示到章节级别而不是连每一节的页码都标出来。5.3 公开之后会不会被滥用任何公开文件都有被读取甚至被复制的可能llms.txt 也不例外。你要意识到它在将信息暴露给模型的同时也暴露给了所有能访问的人。所以不要把内网地址、未公开的接口、后台路径、内部人员信息写进去这些都不适合出现在根目录文件里。如果担心别人通过 llms.txt 快速抓取你的大量高价值内容可以为文件内容做合理精简。只要保证模型能正确理解你的定位和核心页面即可没必要把所有家底都摊开。有些站点会单独提供一份“面向模型”的精炼版本而把完整资料留在需要登录的文档站内部这个策略更稳妥。5.4 问题速查表现象可能原因解决方案curl 能访问模型不读缓存或抓取周期未到等待并刷新 CDN 缓存返回内容被 HTML 包裹Content-Type 错误强制改为 text/plain文件经常无法访问服务器路径或重定向问题去掉重定向直接返回文件模型回答了过期信息llms.txt 未及时更新建立版本更新机制同步刷新站点存在敏感信息泄露风险文件中包含了非公开 URL移除敏感链接这份表会根据每次实际部署慢慢扩充。我建议你把 llms.txt 纳入日常运营的“基础设施”清单和网站监控、日志告警放在一起它值得被持续维护。写这份文件最深远的意义在于你第一次主动向大模型介绍了自己而不是让它在噪声中盲猜。当我完成了第一个 llms.txt 后再去看那些被模型准确引用的结果心里还是挺踏实的。最后分享一个小技巧把站点更新最频繁、也最想让模型优先理解的三到五个页面放到文件最前面效果往往比你按栏目顺序排列要好得多。保持这份文件简洁、真实、稳定就是你给 LLM 最好的见面礼。
先泼一盆冷水如果你的网站在大模型眼里一直“存在感极低”可能不是内容不行而是你还没给它一份“读起来舒服”的资料。LLMs 处理网页时面对的往往是导航栏、广告位、动态脚本和一堆重复边栏真正有价值的信息被淹没在噪声里。我一直觉得大模型不是读不懂你的网站而是你从未按它习惯的方式组织内容。于是就有了 Llms.txt——一个放在网站根目录、用 Markdown 写成的纯文本文件告诉任何路过的 AI这个站点是什么、重点看哪些页面、每个页面的价值是什么。如果你正运营博客、文档站、产品官网或者在做 RAG、Agent、AI 搜索类应用这篇文章就是给你准备的手把手教你把它配好、验证好、用起来。1. 先搞清楚Llms.txt 到底解决什么问题1.1 大模型读网站时到底有多痛苦先说个我自己的例子。之前有个开源项目官网首页写得清清楚楚产品定位、三大功能模块、快速开始链接。结果让 ChatGPT 浏览网页摘要产品特点它给我提炼出的功能竟然是“支持在线聊天”——其实那只是首页一个悬浮客服组件。问题出在哪模型抓取整页 HTML 时信息密度太高、噪音太多它对“哪几句是真正的产品核心描述”判断错了。这几乎每个站长都遇到过。LLM 浏览网页时本质上会把整个页面渲染成文本再放入上下文。一个普通页面如果包含 5000 token 的导航、广告、脚本和推荐位那核心内容可能只有 800 token。上下文窗口再大也有极限模型只能在有限预算内判断哪些内容值得保留。它读得越多、越乱越容易理解偏。Llms.txt 就是来解决这个“信息预算”问题的。它不等同于网页本身而是一张高压缩比的内容地图。你可以把最关键的定位、入口、文档、FAQ 都写在里面让模型在接触完整页面前就已经知道“这事儿的重点是什么”。一句话它不是给搜索引擎爬虫用的是给 LLM 用的说明书。1.2 它和 robots.txt、sitemap.xml 是什么关系很多人一听“放根目录的 txt 文件”立刻想到 robots.txt。这俩完全是两码事。robots.txt 是给爬虫下达“允许还是禁止”的指令它解决的是访问权限。sitemap.xml 是告诉搜索引擎“你有哪些页面需要收录”它解决的是页面发现。而 llms.txt 的目标是让 AI 在抓到页面之后能立刻理解“这网站是干嘛的、哪些内容最重要”。一个比较形象的类比如果网站是家公司robots.txt 是前台保安决定谁可以进门sitemap.xml 是公司组织架构图告诉你有哪些部门llms.txt 则是前台放的接待手册写清楚公司最核心的业务和每个关键文档在哪。三者可以共存且各自负责不同环节。我用表格整理过它们的区别放在这方便你对比文件核心目的主要使用者格式放在哪robots.txt控制爬虫访问权限搜索引擎爬虫、AI 爬虫纯文本指令根目录sitemap.xml列出需要收录的 URL搜索引擎爬虫XML根目录或子路径llms.txt提供站点摘要和关键链接大语言模型、AI 应用Markdown 风格纯文本根目录所以千万别把 llms.txt 当成 robots.txt 的替代品。它只是多了一层“内容理解”帮你把网页里的高价值信息提炼出来让模型少走弯路。对任何希望被 AI 正确引用的站点来说这三者缺一不可。1.3 谁最该赶紧去配一份并不是所有网站都急着上 llms.txt但下面这几类站点的收益特别明显。第一类是文档和知识库。技术文档天然适合被模型读取但文档站通常有大量侧边栏、面包屑、版本切换脚本模型抓取时经常把“上一版本文档”误当成当前内容。一份 llms.txt 可以直接把最新版、最核心的文档链接拉出来并注明“这是当前推荐阅读的版本”效果立竿见影。第二类是产品官网和 SaaS 落地页。这类页面设计感强很多内容藏在图片、交互里模型根本读不到。llms.txt 可以写清楚产品定位、目标用户、核心功能和使用场景让 AI 在推荐商品或回答“有没有类似工具”时把你列进去而不是竞争对手。第三类是 RAG 和 Agent 应用开发者。我见过很多团队辛辛苦苦抓取网站做向量库结果因为源网页噪声太大检索出来的片段全是页面头部和底部导航。如果先读取 llms.txt作为种子文档再按需抓取它指向的高价值页面整个数据管线的质量会立刻提升一个档次。说到底它就是一份“AI 时代的内容摘要卡”。早配早受益而且成本极低剩下的时间和精力投入非常划算。2. 动手之前先把 Llms.txt 的语法和规范吃透2.1 文件格式极其简单但细节不能错Llms.txt 的规范故意设计得很轻。它本质上就是一个 UTF-8 编码的纯文本文件放在网站根目录命名为llms.txt。内容采用 Markdown 风格但不要求完整渲染关键是“人眼能读懂、模型容易解析”。最基础的结构可以只有三部分一级标题写站点名称引用块写站点定位然后用无序列表给出最重要的链接。我平时习惯先按官方推荐的骨架来写再根据站点情况加少量区块像这样# LogoLy LogoLy 是一个开源的轻量级日志采集与可视化工具适合中小团队快速搭建日志分析平台。 - [文档首页](https://logly.example.com/docs/): 包含安装、快速开始和全部 API 参考 - [GitHub 仓库](https://github.com/example/logly): 源码、Issue 和 Release 说明 - [使用指南](https://logly.example.com/guide/): 面向新手的操作教程 - [常见问题](https://logly.example.com/faq/): 部署和排障经验汇总注意一点这不是要你把页面标题复制一遍而是要求每个链接后面都用冒号加一句话说清楚这个页面里有什么、对模型有什么用。模型在看到链接文字之前先读到这句话就能判断是否值得进一步访问。这个“链接一句话描述”的组合是整个文件的灵魂。2.2 内容挑选的艺术别把整站都塞进去很多人第一次写 llms.txt容易走进“越多越好”的陷阱。我见过有人把 500 多个 URL 全列进去美其名曰完整索引。但实际上大模型读取 llms.txt 时同样受限于上下文长度和信息噪音。链接过多、描述模糊反而会稀释核心信息的权重。我的经验是llms.txt 里的链接要满足两个条件高价值、稳定。页面包含“关于我们”“产品介绍”“核心文档”“最新版发布说明”“FAQ”这类值得放。登录后的用户中心、临时活动页、带复杂参数的商品筛选页、纯广告引导页不要放。另外像“2024年暑期大促”这种会过期的内容也不该占名额。举个例子如果是电商站不需要列每一个商品详情页而是列“全部商品分类页”“热卖榜单”“退换货政策”这些入口。模型需要的不是你整站的目录而是它回答关于你品牌的问题时最该引用的那几个“锚点页面”。写描述时也要尽量客观不要写太多营销话术。比如一个工具站你可以写“支持十人以下团队免费使用”但不要写“功能最强大、秒杀一切同类”。模型有判断能力过度夸大的描述反而会降低可信度。2.3 多语言站点与多产品线怎么组织如果你的站点有中英文多个版本或者一个域名下同时有多个产品线直接在单个 llms.txt 里全塞进去会显得混乱。一个可行的做法是根目录的 llms.txt 做总纲指向各语言或各产品线的子说明文件并通过链接区分清楚。英文站可以这样English Site Summary : Overview of all English docs产品 A 文档 : ...产品 B 文档 : ...同样如果你的内容有多个层级可以在 llms.txt 里用二级标题分区块比如“## 产品文档”“## 公司信息”“## 支持资源”让模型可以快速定位到关心的部分。组织结构清晰一点解析脚本写起来也更简单后续维护也更省心。唯一要避免的是为了追求复杂而复杂。规范本身是灵活的你的网站内容形态决定了文件结构。3. 实操过程从零到一配置一份可用的 llms.txt3.1 第一步盘点站点内容画一张信息地图动手写文件之前我会先做一份“内容地图”避免遗漏重要信息。简单方法是准备一个表格把所有候选链接列出来分三列比较页面定位、目标用户、是否值得放进 llms.txt。比如一个刚上线的开源监控项目我可能这样梳理页面路径页面定位是否放 llms.txt/首页产品定位和核心卖点不直接放因为首页噪声高/docs/quickstart快速上手指南放最重要入口/docs/apiAPI 详细参考放/blog/团队博客可选建议精选高价值文章/operator-login运维后台登录页绝不放这个步骤花不了太久但能让你后续写出来的文件有主线、有取舍而不是随手拈来的 URL 大杂烩。3.2 第二步按模板写摘要与链接描述信息地图画完后就可以动手写正文了。我习惯先写一个“一句话定位”格式固定为“XXX 是什么 解决什么问题 适合谁”。这个定位会放在 llms.txt 的引用块里是模型理解你的第一步务必反复打磨。然后根据信息地图把每个核心页面写成一个链接条目。格式统一为页面标题 : 一句话说明这个页面包含什么。这里的说明不应该是页面的简单重复而要写出“模型看了这个页面能得到什么价值”。例如不要写“快速开始页面”而要写“从零开始安装并运行项目约十分钟可完成首个 Demo”。后者信息量更大模型会更愿意点进去。我还喜欢在文件的中间位置加入一小段“产品上下文”用自然语言补充分页面上可能没有的细节比如开源协议、技术栈、版本适配情况。这些信息对模型回答技术选型类问题非常重要而在首页上往往只是一行小字。3.3 第三步部署、校验与发布文件写好后把它放到服务器根目录/llms.txt并确保通过 HTTPS 可以被公开访问。这里有几个校验点非常容易被忽略。第一是文件编码必须是 UTF-8尤其注意中文内容不要用带 BOM 的格式否则解析时可能多出不可见字符。第二是响应头最好带上Content-Type: text/plain; charsetutf-8避免某些服务器用默认的 HTML 类型返回。第三是确认没有重定向比如从https://example.com/llms.txt301 跳转到别的路径会影响部分严格解析的客户端。上传后我一般会用 curl 快速验证一下curl -s https://example.com/llms.txt | head -50这条命令能确认文件能否正常访问、前 50 行内容是否完整。如果返回的是 HTML 错误页就需要检查服务器配置和文件位置了。3.4 让模型更容易发现它文件放在根目录不等于模型一定会读它。目前还没有统一的“提交 llms.txt”入口模型是否能发现它主要取决于爬虫是否抓取到了这个链接。所以我的建议是把 llms.txt 的链接光明正大地放进网站主页的页脚或“关于页面”里比如加一个AI 可读版本的文本链接。这样当 AI 爬虫访问首页时可以顺着链接发现这个文件。也可以在 robots.txt 里显式允许爬取该文件避免被某些禁止规则误伤。另外如果你的网站做了 sitemap可以把 llms.txt 的 URL 作为一个普通页面加进去。虽然它不是 HTML 页面但多一条曝光路径总没有坏处。记住一个核心逻辑你是想让 AI 优先读这份说明而不是整天在页面里猜重点。4. 进阶玩法让 LLM 读完还能“用起来”4.1 把 llms.txt 变成 RAG 管线的种子文档配置文件不只是给在线爬虫看的它非常适合作为 RAG 系统的前置索引。做一个简单的知识库问答应用时没必要把所有网页一次性全抓下来更好的流程是先读取 llms.txt解析出高价值链接列表再按需抓取这些链接指向的页面最后切块向量化。下面这段 Python 示例代码可以做最基础的解析工作import re import requests def fetch_llms_txt(base_url): txt_url base_url.rstrip(/) /llms.txt resp requests.get(txt_url, timeout10) resp.raise_for_status() return resp.text def parse_links_from_llms_txt(text): pattern r\[([^\]])\]\((https?://[^)])\):\s*(.*) items [] for line in text.splitlines(): m re.match(pattern, line.strip()) if m: title, url, desc m.groups() items.append({title: title, url: url, desc: desc}) return items text fetch_llms_txt(https://example.com) for item in parse_links_from_llms_txt(text): print(item[title], item[url], item[desc])其实这个脚本的本质是“把结构化地图解析出来”。拿到链接之后你可以只抓取其中质量最高的 20 个页面做向量化。相比整站递归抓取数据量和噪声都大幅下降检索准确率通常会好很多。4.2 用 llms.txt 持续优化模型回答的一致性如果你希望大模型对外展示的品牌信息保持统一llms.txt 还是一个绝佳的“标准答案源”。我做过一个测试让模型只浏览 llms.txt再进行规则提问比如“这个工具支持哪些平台”“开源协议是什么”“是否免费”。模型给出的回答一致性明显好于让它浏览完整网页。更进阶的做法是把 llms.txt 作为提示词的一部分注入系统消息或者作为评估基准。比如做一套自动化巡检脚本定期用 llms.txt 生成几道标准题再过一遍模型看它的回答是否和文件里的信息发生冲突。如果冲突说明模型的上下文里混入了错误信息可以及时调整抓取策略。这里要注意的是llms.txt 不是拿来操纵模型的而是提供更准确的信息入口。不要把它写成一篇自卖自夸的软文那反而会适得其反。客观、简洁、可验证才是这个文件真正有价值的点。4.3 内容侧标准与模型侧适配的关系大模型领域迭代很快像 time-llama 这类通过动态低秩适配让 LLM 做时序预测的工作也越来越多。很多人问既然模型都能通过微调、适配来理解数据了是不是就不需要 llms.txt 了我的看法是这两者解决的问题不在同一个维度。模型侧适配解决的是“能力”问题让模型更好地理解某种格式或领域llms.txt 解决的是“入口”问题让模型更快、更准确找到该理解的网站内容。哪怕未来模型能力再强它面对一个信息混乱的网页还是需要一份清晰索引来降低不确定度。内容侧的结构化永远不会过时。所以如果你在做 AI 搜索或 Agent除了关注模型选型、微调方法也别忘了把自己服务的数据源整理干净。llms.txt 就是一个低成本的切入点。5. 常见问题与排查技巧实录5.1 大模型还是读不到我的 llms.txt最让人头疼的情况是文件放好了curl 也能访问但模型回复里就是没有体现新内容。这时候先别急着怀疑文件没用按照下面顺序排查。首先要看你的 robots.txt 是否允许 AI 爬虫抓取根目录文件。有些站点为了减少资源消耗设置了Disallow: /这会把 llms.txt 一起挡住。如果不希望全站开放至少单独放行这个文件。其次是检查文件是否被 HTTP 缓存或 CDN 缓存过旧版本。如果你更新了 llms.txt要确认源站和 CDN 都刷新了否则模型读到的还是旧内容。别小看这个问题我踩过好几次坑改了文件没刷 CDN结果大半天里所有访问都是缓存版本。最后是耐心。AI 搜索引擎和模型提供方都有自己的抓取周期不是实时更新的。你今天刚部署的文件可能一周后才被某个模型内置。不要用“两小时后看不到效果”就判定失败可以持续观察再根据反馈优化。5.2 文件里放多少链接才算合适关于链接数量没有绝对标准但根据我的经验核心站点一般控制在 20 到 50 个高质量链接之间。内容特别庞大的文档站可以分区块但单个区块内的链接不宜过多否则解析容易失去重点。还有一个隐藏原则每条链接的描述不要写得像标签堆砌。你写“功能强大、稳定、高效、安全”这种词对模型没有信息增量。相反你写“支持 MySQL 和 PostgreSQL提供 Helm 部署方式适合 Kubernetes 环境”这种具体信息模型才能真的理解页面价值。如果站点内容实在太多可以在 llms.txt 里指出“完整文档入口”的大类链接而不是穷举每一个子页面。就像一本书目录只展示到章节级别而不是连每一节的页码都标出来。5.3 公开之后会不会被滥用任何公开文件都有被读取甚至被复制的可能llms.txt 也不例外。你要意识到它在将信息暴露给模型的同时也暴露给了所有能访问的人。所以不要把内网地址、未公开的接口、后台路径、内部人员信息写进去这些都不适合出现在根目录文件里。如果担心别人通过 llms.txt 快速抓取你的大量高价值内容可以为文件内容做合理精简。只要保证模型能正确理解你的定位和核心页面即可没必要把所有家底都摊开。有些站点会单独提供一份“面向模型”的精炼版本而把完整资料留在需要登录的文档站内部这个策略更稳妥。5.4 问题速查表现象可能原因解决方案curl 能访问模型不读缓存或抓取周期未到等待并刷新 CDN 缓存返回内容被 HTML 包裹Content-Type 错误强制改为 text/plain文件经常无法访问服务器路径或重定向问题去掉重定向直接返回文件模型回答了过期信息llms.txt 未及时更新建立版本更新机制同步刷新站点存在敏感信息泄露风险文件中包含了非公开 URL移除敏感链接这份表会根据每次实际部署慢慢扩充。我建议你把 llms.txt 纳入日常运营的“基础设施”清单和网站监控、日志告警放在一起它值得被持续维护。写这份文件最深远的意义在于你第一次主动向大模型介绍了自己而不是让它在噪声中盲猜。当我完成了第一个 llms.txt 后再去看那些被模型准确引用的结果心里还是挺踏实的。最后分享一个小技巧把站点更新最频繁、也最想让模型优先理解的三到五个页面放到文件最前面效果往往比你按栏目顺序排列要好得多。保持这份文件简洁、真实、稳定就是你给 LLM 最好的见面礼。
