本文讲 GEO（Generative Engine Optimization，生成式引擎可见性） ：它和 SEO 差在哪、为什么开源仓库也会「被 AI 说歪」、以及你可以用哪些可验证手段改善。文末流程图串起整条链路。
GitHub 是 GitHub, Inc. 的商标；下文讨论的仓库诊断思路适用于在 GitHub 等平台托管的公开项目，与平台无隶属关系。
1. 先把词说清楚
SEO 主要优化的是：关键词、收录、排序、点击率------目标往往是「用户在搜索框里点进你的页面」。
GEO 关心的是另一件事：当用户不再打开十条蓝色链接，而是在对话框里问「这个库能用在生产吗」「和 A 比强在哪」时，系统能读到的公开文字 是否足够一致、完整、可被压缩成一段靠谱的摘要。你优化的是被生成式系统正确读取与转述的概率，不是传统意义上的排名位次。
两者有重叠（都需要清晰标题、可读正文），但验收标准不同：
| 维度 | SEO 常见关注点 | GEO 更在意的点 |
|---|---|---|
| 读者 | 人类扫一眼 SERP | 人类读答案 + 机器做抽取与归纳 |
| 信息形态 | 关键词与落地页匹配 | 事实是否分散、是否自相矛盾 |
| 成功样子 | 点击、停留、转化 | 回答少幻觉、少张冠李戴、版本与定位别串台 |
| 失败样子 | 没曝光 | 有曝光但答错------更隐蔽 |
2. 一条说得通的因果链
可以把「模型为什么会答错你的项目」拆成几步（简化模型，够用就行）：
- 用户问题里带了项目名或场景，系统需要从可触达的公开语料里找依据。
- 依据往往来自：仓库页、README、生态描述文件（如
package.json）、文档站、发行说明等------谁写得乱，谁就更容易被拼错。 - 生成阶段会做摘要与推理；输入里缺字段、多版本叙事并存时，填空的成本就转到模型身上，表现为含糊、过时信息、或与竞品混淆。
所以 GEO 在工程上常常落地成两件事：补全机器好解析的结构化信号 ，以及消灭多源叙事冲突。这和「写一篇漂亮软文」不是同一件事。
3. 案例 A：README 首屏没有「三句话」
某 CLI 工具仓库，Star 不少，但 README 一上来是安装命令和参数表，没有独立段落说明：
- 解决什么问题
- 给谁用
- 和同类工具差在哪
在对话场景里，用户问「这个工具干嘛的」，模型只能从大段命令和 flag 里猜。结果常见两种：要么回答过泛（「一个命令行工具」），要么把某个子命令说成主能力。
改法（示意，按你项目语气写即可）：
markdown
## 是什么
面向 **在 CI 里跑集成测试** 的团队，用一条命令拉起依赖服务并回收容器。
不适合需要 GUI 配置或单机桌面安装的场景。
## 和 X 的差别
X 偏重本地开发机；本仓库聚焦 **可重复、可缓存** 的流水线镜像。要点不是文采，而是把边界写死：适合谁、不适合谁、差异句可检索。
4. 案例 B：package.json 与 GitHub About 各说各话
另一个典型坑：GitHub 仓库 About 里的描述写「轻量日志库」，而 package.json 的 description 仍是 npm 初始化时的占位句；homepage 指向旧域名，README 里文档链接又是新域名。
对人类维护者来说「心里知道是一个项目」，对自动化抓取却是三条独立字符串。摘要阶段很容易只采到其中一条，或把旧站内容当成现行事实。
改法 ：选一处为「主叙事」（通常 README 首段 + About），其余字段做字符串级对齐 ：description、repository、homepage、README 顶部互相引用同一套表述。改完不用猜模型采哪段------采哪段都不打架。
5. 代码示意：用「规则」把 GEO 拆成可执行项
产品里可以把「是否利于生成式系统阅读」落成可测试规则，而不是玄学清单。下面是一段示意 TypeScript：判断 README 是否过短（真实项目里阈值、路径、国际化都要再细化）。
typescript
const MIN_README_INTRO_CHARS = 200;
function readmeIntroTooShort(readmePlainText: string): boolean {
const firstSection = readmePlainText.split(/\n##\s+/)[0]?.trim() ?? "";
return firstSection.length < MIN_README_INTRO_CHARS;
}再配合「生态文件与 About 是否一致」一类检查，报告里就能出现可定位的 diff，而不是一句「建议优化 README」。
YAML 配置层也可以把「提示题」和「规则项」分开：规则跑静态数据，提示跑固定规模的对话模拟------两者互补，而不是互相替代。
yaml
# 示意：轻量诊断里常见的「面向对话的问题类型」
prompts_lite:
- id: elevator_pitch
intent: 一句话说明解决什么问题、目标用户是谁
- id: prod_risks
intent: 上生产前要确认的前提与风险
- id: vs_alternatives
intent: 与常见替代相比的核心差异6. 流程图：从提问到答案，信息从哪来
用户自然语言提问
检索 / 工具调用 / 抓取公开页
候选文本片段
摘要与生成
对话中的答案
仓库 README / About
package.json 等生态文件
文档站 / Release 说明
维护者能直接动刀的，主要是左侧三块：让 R、P、D 同源、同版本、同边界。GEO 工作就是减少 S 里的噪声和冲突。
7. 和「买排名」划清界限
GEO 能做的是：降低 因信息缺失或矛盾导致的误述概率。任何「改完模型一定引用你」「保证排进答案前三」的说法都站不住脚------推理链、产品策略、时效性都不在你单仓可控范围内。务实目标写进文档里就两句：可读、一致、可复扫。
8. 小结
- GEO = 针对生成式问答场景，优化公开信息的完整性与一致性，减少被错误摘要的风险。
- 与 SEO 共享一部分页面功夫，但验收标准是「答对」而不只是「被点到」。
- 开源仓库上，README 首屏、About、生态描述文件、文档出口是最常出问题的四面墙；先对齐它们，再谈文风。
- 工程上可以规则化 + 固定提示集复扫，把「感觉 AI 不懂我」变成「这一条上周修了没有」。