Typecho 圈在传「给博客装个 llms.txt 插件」：这扇给 AI 开的门，两侧都有风险

国庆这几天，博客圈在传一个小东西：给 Typecho 装个 llms.txt 插件。

零依赖、单个 PHP 文件、丢进 usr/plugins 目录就能激活，之后站点根目录下会自动多出 /llms.txt 和 /llms-full.txt。对写博客的人来说，这几乎是零成本的吸引力：不用改主题，不用动模板，装完就有。

但在动手之前，有一个”门的另一侧”值得先说清楚。

llms.txt 到底是什么

它是 2024 年 9 月由 Answer.AI 的 Jeremy Howard 提出的一套约定：用 Markdown 写一份站点说明书，告诉大模型”我的站里有什么、哪些内容值得读”。文件放在站点根目录，机器人和人都能看。

想法很合理——传统的 HTML 页面里，正文和导航条、广告、页脚混在一起，AI 抓完还得自己清洗；llms.txt 相当于你替它整理好了一份目录。

争议也一直没停。Google 的 John Mueller 直接把它类比成 1990 年代的关键词 meta 标签，说这东西注定会被滥用，Google 不认。采用率也确实低：SE Ranking 在一份 30 万个域名的扫描里，只找到大约 951 个域名有 llms.txt。所以它现在的状态，更接近”提前占位”——成本几乎为零，收益不确定。

真正该看的是另一侧：这是一份所有人都能写、AI 会照做的公开文件

8 月底，一份安全研究把这件事推到了另一个方向。

研究团队扫了 6214 个域名、8265 个 llms.txt 文件，结果发现：120 个文件指向了当时还没被注册的 npm / PyPI 包名和域名，227 个文件里写着”安装指令”。

更值得琢磨的是那个受控实验：研究员注册了其中一个”待抢注”的包名，然后等着。**一个小时内，就有来自财富 500 强企业网络的 AI Agent 回连了。**也就是说，Claude Code、Codex 这类会去读 llms.txt 的工具，读到”请安装这个依赖”时，会真的照着去装——而链路的另一端，可能是攻击者。

这不是理论推演。8 月 26 日，Ars Technica 报道过一个更具体的案例：Clerk.com 的 llms.txt 里被塞进了恶意的 npm 包名。一个被广泛使用的开发服务，一段谁都可能没细看的说明文件，加上一群会动手的 Agent。

对 Typecho 博客主来说，这件事有两层

**第一层是别人的 llms.txt。**你本地跑的 AI 编程助手，去读某个项目的 llms.txt、并按里面的指令装东西时，那条链路的信任是假定的。这不只是 Typecho 的问题，所有用 Agent 写代码的人都该知道。

**第二层是自己的插件。**插件生成的 llms.txt 本身是干净的——它只是把你的文章标题、链接、摘要列出来。但插件本身也是供应链的一环：一个单文件、来自个人博客的 PHP 插件，本质上就是典型的”非官方分发渠道”。你装进去的不是 GitHub 官方仓库里经过 review 的代码，而是一份贴在自己站点 usr/plugins 下的脚本。它有站点文件系统的写权限。

这不是说那个插件有问题——它可能就是老老实实读文章列表、生成 Markdown。我想说的是，判断标准应该是”我读过它”，而不是”它很流行”。

我的做法

如果你也在考虑装，我的建议是四条：

1. **装之前读一遍源码。**就一个文件，成本极低。看它写文件写到哪、读哪些表、有没有外部请求。
2. 别把整站内容 dump 出去。llms-full.txt 通常是全量正文，体积大、且等于把内容一次性摊开。只导出标题、链接、摘要就够用。
3. **别在 llms.txt 里写安装命令式的说明。**你自己的文件也要经得起别人照着执行。
4. **盯住 AI 抓取策略，而不是只靠 llms.txt。**要不要让 AI 爬，robots.txt 和爬虫策略才是有效的那个开关；llms.txt 更像一个”善待 AI 的门牌”。

我的判断

我赞成在博客上放一个 llms.txt。它的成本约等于零，而且能让 AI 拿到一个不出错的入口——在这个流量入口正在向 AI 迁移的年份，这算是便宜的保险。

但我更赞成的，是把它当成一个普通的、需要审计的公开文件来看待。它和 robots.txt 是同一类东西：所有人都能读，也所有人都能往里塞内容。区别只有一个——读 llms.txt 的，是会把读到的东西变成操作的 Agent。