llms.txt是提案还是标准，各家引擎支持到什么程度

llms.txt 现在是提案还是标准、各家引擎支持到什么程度？直接回答：它是提案，规范文本仍处在开放征求意见的阶段，没有任何机构宣布它成为正式标准。但提案不等于没人在用——审计工具已经把它列入检查项，模型厂商自己也给自己的文档站发布了这份文件。所以真正该讨论的不是「要不要等它定稿」，而是这份文件解决的是哪一层问题、该由谁来生成和维护。

它解决的是导览问题，不是权重问题

这份文件放在站点根目录，用 Markdown 写，目的是把站点的核心内容、结构入口和该看的页面讲清楚，让智能体不必从一堆链接里自己摸。

理解定位很重要：它不会因为你写了一份就把排名提上去，也不构成任何排序信号。它的作用更接近给访客的一张导览图，减少取用方在站点里绕路的成本。指望它改变可见度，会得出「做了没用」的结论；把它当作内容清单的补充，判断就清楚了。

提案身份意味着什么

三件事要提前知道。第一，格式还在动，社区意见仍在收，字段与写法的约定尚未定稿。第二，没有强制的兼容承诺，取用方按自己的解析习惯读，写法保守一些更稳。第三，判断依据只能来自实际观察，不能来自「标准已生效」这类表述。

因此合理的心态是：按当前提案描述的最简形式来写，先给站点定位说明，再列出核心页面入口，避免堆长清单；不要为了凑条目把归档页全部列进去。写法保守，将来格式若调整，改动面也小。

发布方与工具侧的采用说明哪一层价值

能核对到的采用情况有两类。一类是审计侧：浏览器性能与质量审计工具会把这份文件作为检查项之一，站点有没有它是一项可见结果。另一类是发布侧：几家模型方在自己的开发者文档站点上提供了这份文件，用来给读文档的智能体做导览。

这两类说明的是同一件事——把它当成一项交付质量检查，而不是一种优化技巧。有它，站点多了一个规整的对外说明入口；没有它，也不会因此失去什么排名。

站内该由谁来生成和维护

手工维护有两个必然失效点。第一是条目过期：清单里写着某个入口，实际页面已经改名或下线，取用方读到的是错的路标。第二是内容漂移：正文口径调整之后清单没跟着改，两边给的信息不一致，这种不一致比没有清单更糟。

所以结论是让它由系统随内容生成，而不是当一篇文章写。AnQiCMS 支持站点自动生成 llms.txt，同一套后台里还覆盖站点地图生成与 robots 规则配置等模块，这几份对外清单应当由同一个来源驱动，避免人工维护三份不同的地址表。

维护节奏上，把它和站点地图放在同一次检查里：新增重要栏目后核一次，改版后核一次，日常发布不必逐条改。每次改动后同时确认两件事：文件本身能直接访问；里面指向的地址都是当前生效的规范地址。

与抓取规则和站点地图的三处一致

第一处是可达性。抓取限制规则如果挡住了清单文件所在路径，这份文件写了也取不到；根目录下的限制要留出这一条。

第二处是地址口径。清单里的地址、站点地图里的地址、页面上实际规范化的地址三者必须一致。出现两套并行地址时，被引用到的往往是旧的那一套。

第三处是更新时机。内容推送与清单更新走同一节奏：新页面上线后再提交，而不是先提交再改地址。面向检索侧的链接推送与这份说明文件服务的是两个环节，前者解决发现时间，后者解决理解成本，两者都不能替代页面本身写得清楚。

常见问题

现在做会不会太早？提案状态本身就是做它的合理时机：写法简单、成本低，取用方已经在读。真正不该做的是把它当成排名手段来堆条目。

内容少要不要做？内容少时收益不明显，等站点有明确栏目结构与核心页面之后再补，条目才有意义。

要不要写多语言版本？多语言站点按语言各给一份说明更有效，不同语言读者关心的入口并不相同，混在一份里会让两边都不清晰。

和站点地图重复吗？不重复。站点地图是给检索侧的地址清单，这份文件是给智能体阅读的结构说明，前者重完整性，后者重可读性。