8.2 Greptile 与 Copilot 即时索引
8.2 Greptile 与 Copilot 即时索引
本节摘要：第二组样本，押注点截然不同。Greptile：两个下注——①符号感知的 chunk（tree-sitter 切分保住函数/类边界，第 3 章"切分决定上限"论点的产品印证）；②面向 agentic coding 的 API 化（代码检索、批量审查、跨仓库问答以 API 交付给 Agent 集成——第 6.3 节"检索作为工具"的产品印证）。消费者定位是 Agent/平台团队，而非 IDE 里的个人。Copilot 即时索引：押注新鲜度——2025-03 GitHub 官方博客宣布代码搜索的即时语义索引 GA，新仓库的索引时间从分钟级压到秒级（官方自报）：clone 即索引、改完即生效，把"索引滞后于代码"这个语义检索最大的体验硬伤从产品里抠掉。其工程思路与 4.3 节的优先级队列、分片并行、增量细粒度化一脉相承，只是跑在平台级基建上。对照表的读法：同为"预建索引"阵营，Greptile赢在喂给模型的料与 Agent 接口，Copilot 赢在新鲜度与 IDE 分发；数字均标注属性，功能细节以官方文档为准。
学习目标
阅读完本节，你应当能够：
- 说出 Greptile 的两个押注及其与第 3/6 章论点的对应；
- 复述 Copilot 即时索引的关键数字与来源属性（2025-03 GA，分钟级→秒级，官方自报）；
- 用押注点对照表比较两家（以及与 Sourcegraph）的差异化路线；
- 把两家的思路映射回自建管线的对应改进点。
一、Greptile：把宝押在"料"和"接口"
Greptile 的公开材料强调两点差异化（以官方文档为准）：
- 符号感知 chunk：用 tree-sitter 按语法边界切分（函数/类完整入 chunk），再叠语义嵌入。这正是第 3 章的立场——产品的差异化常常不在模型，而在喂给模型的料：同样一个嵌入模型，吃到拦腰截断的函数和吃到完整函数，检索质量是两个档次（3.3 的症状一与症状二）。对代码检索这个场景，chunk 策略是少数"自己可控、见效直接"的杠杆；
- 面向 agentic coding 的 API：把仓库检索能力（自然语言查代码、批量 PR 审查、按规则扫描）以 API 形态交付，集成进 CI 与 Agent 工作流。消费者不是在搜索框打字的人，而是第 6.3 节设计的那种工具调用方——返回格式紧凑、可程序化消费、支持跨仓库。
API 化的典型消费场景（公开材料口径）：
- PR 批量审查：对 diff 问"这段改动可能影响哪些调用方"；
- 规则扫描：把团队规范写成自然语言查询，全仓巡检；
- 跨仓问答：接手遗留系统时的"这个概念在哪些服务里出现过"。
三个场景的共同点：消费者是程序（CI 任务、Agent 工作流），不是坐在 IDE 里的人——这决定了接口形态（可编程、可限流、返回紧凑）优先于交互形态。
映射回自建管线：①对应 3.2 的 chunker.py（你已经有了符号感知切分）；②对应 6.3 的 tools.py（你也已经有了工具化接口）。Greptile 的存在侧面验证了本书的部件选择——自建路线与商业路线在"料"与"接口"两层的最佳实践是重合的。
二、Copilot 即时索引：把宝押在"新鲜"
2025-03，GitHub 官方博客宣布 Copilot 代码搜索的即时语义索引 GA：新仓库索引时间从约 5 分钟级压缩到秒级（官方自报数字，撰写时点口径）。这个数字的分量要放在 4.3 节的框架里读：
| 4.3 的思想 | 即时索引的产品化形态 |
|---|---|
| 优先级队列（热文件先索引） | 打开仓库/活跃分支优先调度 |
| 分片并行 | 索引作业按仓库与文件分片，平台级并行 |
| 增量细粒度化 | 编辑后只更新受影响 chunk 的向量 |
| 冷热分层 | 不活跃仓库的索引降级/回收，重新访问再建 |
新鲜度为什么值得下重注：语义检索的传统体验硬伤是"刚 clone 的仓库搜不了/搜旧代码"——用户对"搜不到"的容忍远低于"搜得慢"。秒级索引把语义检索的可用时间窗从"开后等几分钟"缩到"无感"，这是把 4.2/4.3 的工程命题推到平台级后的红利。Copilot 的分发优势（IDE 内置、@workspace 入口）则让这套基建被默认消费。
读这组数字的三条注意：
- "分钟级→秒级"是索引时间不是查询时间——查询延迟本来就是毫秒级；
- 官方自报数字通常测自理想条件（新 clone 的仓库）；私有大仓、冷启动、权限复杂时体感打折；
- GA 时点（2025-03）之后功能仍在迭代，引用时注明时点（本书口径 2026-09）。
三、押注点对照表
| 维度 | Greptile | Copilot 即时索引 | 本书对应 |
|---|---|---|---|
| chunk 策略 | 符号感知（tree-sitter），明确公开 | 未公开细节（以官方为准） | 3.2 chunker |
| 索引时机 | 预建（接入仓库时） | 即时（秒级，2025-03 GA 官方自报） | 4.2/4.3 |
| 字面一路 | 支持（符号/路径过滤） | 支持（GitHub 代码搜索本就词法强） | 5.1 |
| 权限过滤 | 按仓库/组织 | 企业版能力（以官方为准） | 4.1 生态轴 |
| 主要消费者 | Agent / 平台团队（API） | IDE 里的开发者 | 6.3 |
| 典型任务 | 批量审查、跨仓问答、规则扫描 | @workspace 问答、就地检索 | 第 7 章 |
| 分发形态 | API/集成 | IDE 内置 | — |
读表的方法：不要问"谁更好"，问"谁的成本模型适合谁的场景"。Greptile 把成本花在料的质量与 Agent 接口上，赌的是 agentic coding 时代检索的消费者是程序；Copilot 把成本花在新鲜度与分发上，赌的是检索体验的默认入口仍在 IDE。Sourcegraph（8.1）则把成本花在"意图+保真"的两层组合与企业权限上，赌的是大组织的代码资产需要基础设施级伺候。
💡 横评的正确姿势：repowise 2026-05 这类第三方横评（公开评测）适合做初筛与视角校准，但选型决策要拿自己的评测集（第 9.2 节）去跑候选工具——查询分布不同，横评名次与你的体感可以完全相反。这是"数字标注属性"的最终目的：知道哪个数字能代表你。
四、映射回自建管线
两家的押注翻译成自建改进项清单：
- chunk 质量：3.2 已做到符号感知，可再加身份前缀与类骨架（3.3）；
- 新鲜度：7.2 的增量更新已有两级判定，可加 watch 模式（4.2 的 watchdog 思路）把更新从"跑命令"变"常驻"；
- 接口：6.3 的工具化已按 Agent 消费设计，返回紧凑、可程序化；
- 新鲜度的高级形态：按需惰性（6.2 的 Claude Code 路线）与预建（本节路线）混合，4.3 与 6.2 都论证过终态。
自建的短板通常在基建规模（分片调度、多租户、权限）——那正是 8.3 决策表要算的账。
⚠️ 产品事实的时效：本节对 Greptile 与 Copilot 的描述基于撰写时点（2026-09）的公开材料与官方博客；两家的功能边界（尤其 Copilot 的索引范围与 Greptile 的 API 能力）迭代都快，引用前先对官方文档。
本节要点回顾
- Greptile 两个押注：符号感知 chunk（料）与 agentic API（接口）——分别印证第 3、6 章的选择；
- Copilot 即时索引押注新鲜度：2025-03 GA、分钟级→秒级（官方自报），4.3 思想的平台级兑现；
- 对照表的正确读法：比成本模型与场景适配，不比抽象好坏；
- 两家押注均可映射为自建改进项；自建短板在基建规模——引出 8.3 的决策账本。
看完两极与两条路线，该算自己的账了。下一节把前面所有的观察收进一张决策表：自建、拼装还是采购，四轴定夺。