给大模型的站点说明文件是给人读的还是给智能体用的，提案改过说法

给大模型的站点说明文件是给人读的还是给智能体用的？它既不是只给人读，也不是只给模型读。按提案现行措辞，它要解决的是帮智能体使用网站；早期版本的说法更窄，讲的是帮语言模型理解并索引网页内容。两份说法的差异不在文件格式，而在被假设的读者：从「读内容的模型」扩展到「会用网站的智能体」。

提案最初要解决什么问题

网页对人类友好，对机器并不友好。导航、弹层、无限滚动、脚本渲染出来的正文，人眼会自动跳过噪声，程序却要把它们逐段处理。提案作者 Jeremy Howard 在 2024 年 9 月给出这份文件，出发点就是把站点的核心信息集中成一份可以直接交给模型处理的纯文本清单，省掉从整站页面里猜结构的过程。这份规范在 2026 年 8 月留下了修订记录，措辞也从模型一词语义扩展到智能体。

从「读懂内容」到「使用网站」的差别

服务对象一变，文件里该写什么跟着变。如果读者只是模型，写出站点是做什么的、有哪些重点页面就够了。如果读者是会执行动作的智能体，它还需要知道边界在哪里：哪些页面是说明、哪些是接口入口、哪些操作需要人工确认。措辞改掉之后，内容的重心从介绍转成了引导，站点说明文件更接近一份给外部程序看的站点导览，而不是一篇宣传稿。

为什么必须是纯文本清单

规范要求的是一份 Markdown 文本，不是接口，也不是配置描述。理由很直接：任何一端都能读，不需要为它准备解析器，也不需要鉴权约定。清单形式还带来一个附带好处——它是可核对的。写错了、漏了栏目、链接指到失效页面，人都能直接看出来，不必依赖工具链。

必填段与可选段怎么分

按规范对合法文件的要求，只有一项是必填：写明项目或站点名称的一级标题。其余部分都是可选组合，可以有一到多段，也可以完全不写：

• 紧跟在标题后的引用块，用来放一段简短摘要，写好理解整份文件需要的关键信息；
• 若干普通 Markdown 段落，放更细的说明，但这一类里不再出现标题层级；
• 若干按二级标题分组的文件清单，把可以进一步查看的地址归类列出。

结构上的取舍是：必填项少到不可能出错，可选部分决定这份文件究竟有用还是形同虚设。真正需要斟酌的是引用块里那几十个字，以及文件清单里列哪些地址、不列哪些。

站内该由哪一层来生成

AnQiCMS 支持站点 llms.txt 的自动生成，让大语言模型更容易理解和索引网站内容。这一层由系统按现有栏目与文章产出，站方不需要手工维护每一行。它和站点地图的分工要分清：站点地图面向抓取器，逐条列出地址与最后修改时间；面向模型的站点说明文件面向理解，用文字把站点是什么、有哪些内容讲清楚。两者在后台各管一处，谁也不能替掉谁。

维护节奏跟着什么走

这份文件的变动应该跟着内容结构走，而不是跟着页面文案走。新增一个栏目、调整一类内容模型、上线一批接口说明，都值得再检查一次文件清单是否有对应条目；改一句标语则不必动。它属于一份仍在修订的开放提案，社区意见仍在收集，所以更稳妥的做法是保持简短、保持可核对，等结构真变了再动。

常见问题

问：只写一级标题行不行？ 答：按规范这是合法文件，必填段就是这一行；但这样的内容对读者几乎没有附加价值。

问：能不能把全站文章地址都列进文件清单？ 答：不建议。清单的价值在筛选，把全量地址倒进去等于把整理工作推回给读取方，也更容易漏掉过期条目。

问：它和 GEO 里其他动作是什么关系？ 答：属于其中一环。抓取控制、站点地图、正文可抽取性各管一段，单独把这份文件写完并不等于生成式可见度到位。