开源项目与开发者工具做 GEO：程序员问 AI「用什么库」时怎么被推荐

开发者是最早把 AI 当搜索引擎的人群

写代码时遇到问题，越来越多人的第一反应是问 AI 而不是搜 Stack Overflow。这意味着开源项目和开发者工具的「第一印象」正在被模型重塑。而模型的推荐，高度依赖它能读到的文档质量。

模型读得懂的 README 长什么样

• 第一屏就说清「它解决什么问题」。不要用「下一代」「重新定义」这类词，用一句可判定的描述：「一个把 CSV 转成带类型 JSON 的 Python 库，支持流式处理 10GB 以上文件」。
• 有可直接复制的安装与最小示例。模型在回答「怎么用 X」时，会把 README 里的示例代码整段搬过去。示例越完整，被引用的概率越高。
• 写清与其他方案的差异。「和 pandas 的区别」这类章节，正是模型回答「X 和 Y 选哪个」时的素材来源。
• 版本与兼容性表格。明确的版本矩阵会显著提升「技术事实」类问题的引用率。

文档站的三个加分项

1）每个概念一个独立 URL，不要把所有 API 塞在一页；2）页面里保留可被检索的纯文本，而不是只有交互式示例；3）提供 llms.txt 或清晰的站点地图——它不一定被所有平台读取，但成本极低。

社区信号仍然重要

模型推荐库时，会交叉参考 GitHub star、issue 活跃度、发布频率、是否有知名项目依赖。这些不是你能「优化」的，但可以主动补充：在 README 里列出使用你的知名项目，维护一份 CHANGELOG，保证最近半年有提交记录。

一个容易被忽略的战场

错误信息的修正。如果模型的训练数据里你的库还停留在两年前（比如已经不推荐的 API），用户会被引导到过时用法。对策是：在文档里显式标注「已废弃」，并保留迁移指南——模型读到废弃说明后，回答里通常会带上提醒。

开源项目做 GEO 几乎不需要额外预算，需要的是把文档当成产品的一部分来写。