北京
一份号称“开源”的工具清单，把两个最受关注的项目挡在了门外。不是功能不行，也不是代码质量有问题——是许可证这一关没过。firecrawl/llmstxt-generator，534颗星，能一键生成llms.txt和llms-full.txt，但仓库里根本没有LICENSE文件。Canonry，99颗星，AEO监测平台，源代码完整可读，但用的是FSL-1.1-ALv2许可证。
生成式引擎优化这个词听起来有点拗口，但它解决的问题非常具体：你的内容现在不是给人看的，是给ChatGPT、Perplexity、Claude和谷歌AI概览这些系统看的。它们不点链接，只给答案。2024年KDD大会上那篇GEO原论文已经把路指得很清楚了——引用、统计数据、可引述的结构，这些才是关键，关键词密度基本没用了。
问题在于，市面上围绕GEO的工具几乎全是付费SaaS。已有的两份awesome清单质量不错，但工具部分读起来像融资新闻：Profound、Otterly、Goodie、Semrush。有预算当然好用，想读源码自己跑？门都没有。所以有人动手做了另一半：Awesome Open GEO，62个条目，一个标准从头筛到尾。
标准听起来很形式主义——每个条目必须免费可运行，并且发布在OSI批准的许可证下。但就是这个形式主义，直接决定了整份清单的含金量。firecrawl/llmstxt-generator因为没有LICENSE文件被排除。没有限制性许可证，不是一个，是没有。在默认版权法下，这意味着保留所有权利：无论仓库多么公开，无论作者意图多么明显，你没有获得使用、修改或再分发的授权。
Canonry是另一种情况。用的FSL-1.1-ALv2，即功能性源代码许可证，两年后转为Apache-2.0。从商业角度看，这个选择完全站得住脚。但它今天不是开源的，OSI对这类许可证的态度也很明确。这两项排除都不是对项目本身的批评——缺少许可证文件多半是疏忽，FSL则是经过深思熟虑的商业决策。但一份自称开源的清单，如果不去核查这一点，标签就没有任何意义。
反复出现的模式更值得注意：README里自称为“开源”的仓库，代码树里找不到许可证；号称“开放”的平台，许可证悄悄排除了竞争性使用。当你挑选一个要构建在上面的工具时，这个区别不是名词之争——是依赖项和潜在责任之间的分界线。
这份清单的筛选过程也下了笨功夫。先是GitHub API扫描，用大约15个主题和关键词查询——topic:generative-engine-optimization、topic:llms-txt、topic:answer-engine-optimization、topic:ai-visibility，外加关键词搜索，拿到603个独立仓库。然后按星数、许可证SPDX标识、最近推送时间和归档状态过滤。603个里大部分是误报，有用户代理解析器，有Telegram机器人，甚至有一份C#备忘单恰好提到了llms.txt。最后一步是读每个计划收录项目的README，因为仓库描述是营销，第三方博客摘要只会更差。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
