llms.txt是提案还在被采用，站内该由谁来生成和维护

给大模型看的说明文件还只是提案吗？准确说法是：定位上仍是提案，采用上已经有人在用。llms.txt 的规范描述本身写明这是一个用于帮助智能体使用网站信息的标准化提案，规范仍处于开放社区征求意见的阶段；同一页面也提到，Chrome 的 Lighthouse 会检查站点有没有这份文件，OpenAI、Anthropic、Gemini 这些模型方也为自己的开发者文档发布了 llms.txt。所以真正该讨论的不是「要不要等它定型」，而是站里这份文件该由谁来生成、怎么长期维护。

它现在是什么定位

提案状态带来两个实际影响。一是格式没有硬约束，各家读取时的容错不同，写得太复杂反而降低被利用的概率；二是它不在搜索引擎的排名信号清单里，不能按 SEO 老办法去推算收益。

它解决的问题却很具体：模型读取网页时拿到的是渲染后的正文，站点结构、哪些页面值得引用、更新到什么时候，这些信息由一份纯文本集中说明，比让模型逐页猜要省事。对内容量大的站点，这份文件的价值主要在被摘要、被引用时能带对地址和名称。

谁在用这份文件

从***息看，使用它的一方包括工具侧和模型侧。工具侧是站点审计与抓取类工具，会把「有没有这份文件、路径能不能访问」当作检查项；模型侧是几家大模型厂商，在自己的开发者文档目录下提供 llms.txt，方便程序读取文档结构。

这两类用法共同指向一个结论：写这份文件的成本极低，收益取决于站点内容本身是否值得被引用。没有内容质量的站点，加不加这份文件都不会改变被引用的概率。

手工维护的两个失效点

第一个失效是条目过期。说明里列出的栏目、示例页、时间信息一旦跟不上实际调整，读取方拿到的是旧结构，效果比没有更差——它会主动误导引用。

第二个失效是内容漂移。正文地址改了、标题改了、栏目合并了，而说明文件还按旧结构列。这类漂移往往发生在批量调整之后：改站点的人专注于站点地图和跳转，忘了这份文件也在描述同一批地址。

两个失效的根源都是手工。站点内容每天都在变，一份手工维护的清单等于每月给自己增加一次全量核对。

该由谁来生成和维护

合理分工是让系统生成，而不是让人抄写。在 AnQiCMS 里，这份文件由站点自动生成，用来帮助大语言模型理解和索引网站内容；后台与抓取、收录相关的能力合计有 14 个模块，llms.txt 是其中一项，和站点地图生成、抓取授权文件配置处在同一组配置面里。

同源的必要性就在这里：站点地图已经掌握了当前有效地址集合，llms.txt 如果由同一个生成链路产出，条目就不会和实际内容脱钩。两处分别维护时，一定会出现两份地址清单不一致的情况，而这种不一致很难被发现，因为两边看起来都是「正常生成过」。

与站点地图、抓取授权的分工

三者面向的对象和粒度不同。站点地图面向搜索引擎，逐条列地址并带上更新时间；抓取授权文件 robots.txt 面向抓取行为，规定哪些路径允许访问、哪些不允许；llms.txt 面向模型读取，重点是站点说明与关键页面入口，不是全量地址列表。

配置顺序建议按依赖关系来：先确认 robots.txt 没有把说明文件的路径挡掉，再确认站点地图能正常访问，最后核对说明文件里的条目是否指向实际存在的页面。前两步不通，文件写得太规范也没人读得到。

常见问题

文件路径与可达性为什么是第一步检查项？因为这是最常见的失效方式。路径写法不符合约定、被授权文件挡掉、或者生成后返回异常，任何一种都会让后续内容完全不起作用，而这三点在浏览器里点一次就能确认。

提案没定型，现在做会不会白做？格式可能微调，但内容来源是站点自身，重新生成的成本几乎为零。相比之下，手工维护才是要避免的沉没成本。

要不要在这份文件里写推广语？不要。它的读取方是模型，条目应聚焦站点说明、栏目与关键页面入口，宣传性描述会降低被摘取的概率。

一个判断口径

llms.txt 值不值得做，取决于站点有没有值得被引用的内容；能不能持续有用，取决于它是不是随内容一起生成。提案身份不是理由，手工维护才是风险。