代码搜索与导航：LSP、ctags、GitHub 代码搜索与 AI 问答（纵轴 × 横轴综合报告·终稿） 未开始

题记与说明

报告性质：终稿。已按 8 条独立审读意见逐条修订（每条的处理方式见文末 4.6 节修订记录），不再是修订输入。
综合来源：output/reports/parts/ 下两份章节稿——纵轴稿《代码搜索与导航——纵轴发展史（1976–2026）》与横轴稿《代码搜索与导航——横轴对比报告》。
时间截面：2026-11-05。补充课题：大型陌生仓库上手流程的范式迁移。
来源与置信度说明：两份章节稿均基于当日实际运行的网络搜索与网页读取写成，关键事实均附来源 URL。本综合稿初版未新增任何外部检索，全部事实、数据与链接均取自两稿；终稿修订时为落实审读意见执行了少量核对性检索（新增来源见 4.2–4.4 节，核实结果与由此产生的事实更正见 4.5 节与 4.6 节）。各稿原有的置信度标注与诚实性说明全部保留（见文末）。

TL;DR（核心结论）

代码搜索与导航的主线，是对同一个问题——让不熟悉代码库的人和机器快速看懂代码——的四次范式回答：ctags 符号索引、IDE 编译器级解析、LSP 标准化与云端搜索、AI 问答与智能体检索。2026 年横截面"两极都赢"：服务端索引扩张，单机 agent 无索引检索成主流，个人本地 embedding 索引被掏空。LSP 经 JetBrains 开放 API 完成大一统，成为 AI 答案的确定性校准层；ctags 退位不退场；Sourcegraph 剥离 Amp，独立搜索公司只剩"上下文层"生态位。建议：AI 问答是加速器而非事实来源，按"站外预习→本地建图→精确定位→AI 问答（验证）→固化导航资产"五步上手陌生仓库，并执行两条纪律——工具顺序上先 grep 后 LSP，AI 答案必须用 LSP/rg 复核。

综合处理说明：两稿差异与重复的消解

两份章节稿在事实层面高度一致，综合时有四处口径问题需要显式统一：

1. "索引范式是否被 agent 替代"：纵轴稿第七阶段写"二十年前的 ctags 式'先建索引'，被'让 agent 即席搜索'替代"；横轴稿的判断是"索引与无索引的两极反而都赢了"。两者并不矛盾，但单独引用任何一句都会误导读者。本稿统一为"索引分化"框架：服务端跨用户索引继续扩张加码，单机代理场景转向无索引即席检索，被淘汰的只是"个人本地 embedding 索引"这一档（详见交叉洞察 3.1）。
2. ctags 的地位：横轴稿强调"在 AI 工具链中已被 tree-sitter 取代"（aider 案例），纵轴稿强调"Universal Ctags 仍在活跃维护"。本稿统一为"退位不退场"：AI 上下文压缩场景让位给 tree-sitter repo map，Vim/SSH/CI 等轻量场景仍是活跃维护的实用工具。
3. DeepWiki 发布时间：纵轴稿记"2025 年 4–5 月"，横轴稿记"2025-04 上线"。本稿统一为 2025 年 4 月上线（纵轴所记窗口为其发布推广期）。
4. 结构与重复：纵轴稿"四次范式迁移"的总览与正文七个叙事阶段存在表面不一致，本稿在 1.0 节显式建立两者对应关系；Sourcegraph/Amp 拆分、Blackbird 技术数据、Copilot 定价等两稿重复出现的事实，只在一处详述、其余各处以"见某节"方式引用，不再重复展开（本承诺已在终稿中逐条兑现，见 4.6 第 6 条）。

一、纵轴：发展脉络（1976–2026）

1.0 总览：一条主线，四次范式迁移，七个叙事阶段

四条线索——ctags（本地符号索引）、LSP（语言智能协议）、GitHub 代码搜索（云端代码检索）、AI 问答（代码库感知对话）——并不是四条平行线，而是同一个问题的四次回答：如何让一个不熟悉代码库的人（或机器）快速找到并看懂代码？

• 范式一（1976–1995）：用文本索引工具在终端里"跳"，代表是 ctags、cscope（对应叙事阶段 1.1）；
• 范式二（1996–2015）：IDE 把符号索引做进编辑器，Exuberant Ctags 与独立代码搜索引擎并存（对应阶段 1.2–1.3）；
• 范式三（2016–2022）：LSP 把"跳转到定义/查找引用"标准化，GitHub 把代码搜索与导航搬到网页端（对应阶段 1.4–1.5）；
• 范式四（2021–至今）：大模型把"检索"变成"问答"，再进一步把"问答"变成"智能体自己动手检索"（对应阶段 1.6–1.7）。

（范式四标注的起点 2021 与范式三的终点 2022 有约两年重叠——Copilot 技术预览（2021-06）与 LSP 生态扩张、Blackbird 重构（2021–2022）同期发生。这不是笔误，而是"检索消费者开始从人变成模型"的过渡期，详见交叉洞察 3.2。相邻叙事阶段之间允许少量事件交叠，阶段标题按主导事件划分。）

贯穿始终的驱动因素有三：代码规模持续膨胀（从贝尔实验室约 500 万行的 C/C++ 项目到 GitHub Blackbird 公测时约 155 亿文档规模的检索面，数据见 1.5 节）、编辑器碎片化（M×N 集成难题倒逼出 LSP 这类标准）、算力与索引成本曲线的下降（trigram 索引、Rust 重写的搜索引擎、增量解析，最终是"把整个代码库塞进模型上下文"）。

1.1 第一阶段（1976–1995）：Unix 索引工具时代——"跳"的起点

关键事件与版本节点

• 1976 年前后：ctags 随 BSD Unix 问世。据 Wikipedia 的 Ctags 词条（横轴稿检索会话中完整读取），原始 ctags 由 Ken Arnold 编写、随 BSD Unix 2.0 发布，其中 Fortran 支持来自 Jim Kleckner、Pascal 支持来自 Bill Joy；它生成 tags 文件（{tagname}\t{tagfile}\t{tagaddress} 三列、按 tagname 排序以便快速查找），让 vi 用户可以用一条命令从标识符直接跳到定义。1992 年它进入 Single Unix Specification / XPG4 初始版本。
• 1980 年前后：贝尔实验室的 Joe Steffen 开发 cscope。据 cscope 官方历史页，它最初服务于 PDP-11 时代的项目，后来支撑起约 500 万行 C/C++ 代码的贝尔实验室项目，提供了"找调用点、找被调用函数、找字符串"等远超跳转定义的交叉引用能力。
• Emacs 侧同期发展出 etags/TAGS 格式（与 ctags 同源实现，见上述 Wikipedia 词条）。

主要参与者：Ken Arnold、Bill Joy（BSD 圈）、Joe Steffen（贝尔实验室）。

驱动因素：代码从磁带/纸带走向文件系统后，"人肉 grep + 打印阅读"撑不住几万行以上的 C 项目；字符终端上最便宜的提速手段，就是预先生成一张排序好的符号索引表。

大型陌生仓库上手流程（当时形态）：先 grep -n 找入口（main 函数），再用 ctags 生成索引、vi -t 反复跳转，配合纸笔画调用图。这套"索引文件 + 编辑器跳转"的模式奠定了此后五十年代码导航的基本形状。

1.2 第二阶段（1996–2007）：Exuberant Ctags 与 IDE 智能化，M×N 问题显形

关键事件与版本节点

• 1996 年：Darren Hiebert 发布 Exuberant Ctags。它最初随 Vim 发行，自 Vim 6 起独立为单独项目，支持 40 多种语言并允许用正则扩展新语言，把 ctags 从"vi 配件"升级为跨编辑器的基础设施（Vim/Emacs/NEdit/UltraEdit 等都支持其格式）。
• 1996–1997 年：微软在 Visual Basic 5.0 Control Creation Edition（1996）中首次 mainstream 推出 IntelliSense（语句补全/成员列表），1997 年初 VB 5.0 正式版铺开；此后 IntelliSense 覆盖 Visual Studio 全家桶。IDE 开始"边写边导航"。
• 2000 年：cscope 以 BSD 协议开源并迁入 SourceForge，进入 Vim/Emacs 用户的日常工具箱。
• 1997–2000 年代初：GNU Global（gtags）等交叉引用工具出现，与 ctags/cscope 并列为开源 C 项目三大件。
• 2001 年：Eclipse JDT 与 JetBrains IntelliJ IDEA 相继发布，"Find Usages / Call Hierarchy / Go to Declaration"成为 IDE 标配——编译器级别的符号解析首次大规模服务普通开发者。

主要参与者：Darren Hiebert（Exuberant Ctags）、微软（IntelliSense）、Eclipse 基金会、JetBrains。

驱动因素：语言越来越复杂（C++/Java），正则式的 ctags 无法解析重载、模板、继承；编译器前端性能提升使"精确解析"在 IDE 里变得可行，但代价是每个 IDE×每种语言都要单独写集成——M×N 问题在此阶段首次显形。

同时期（2004–2006）的云端萌芽：独立代码搜索引擎 Koders、Krugle（2006）与 Google Code Search（2006 年 10 月 5 日上线）出现。后者由 Russ Cox 花一个夏天构建，支持在全网开源代码上跑正则；其核心技术——trigram（三元组）索引——先用三元组过滤候选文件再跑正则引擎，成为此后近二十年代码搜索的标准架构（GitHub Blackbird、Zoekt 均是其精神后裔）。Google Code Search 于 2011–2012 年关闭，但 Russ Cox 开源了简化版 google/codesearch，并写下那篇著名的 "How Google Code Search Worked"。（Krugle 自身条目未在终稿修订会话中核实成功，故不再附链接，见 4.6 第 8 条。）

大型陌生仓库上手流程（当时形态）：Vim/Emacs 用户执行 ctags -R + cscope -Rbq 三件套；IDE 用户靠 Ctrl+点击/Ctrl+B。社区开始沉淀"先读 README 与 Makefile、从 main 下钻、用调用层次图看骨架"的方法论。

1.3 第三阶段（2008–2015）：代码托管平台与独立代码搜索

关键事件与版本节点

• 2008 年：GitHub 上线（业界公知时间，两稿检索会话均未逐字核对一手页面）；同年 Stack Overflow 创办——"问人类"的代码问答与"托管代码"的平台在同一年诞生，为后来的"问 AI"埋下对照。
• GitHub 早期代码搜索：据 GitHub 官方技术博客（2023-02-06），GitHub 在其历史的大部分时间里用 Solr/Lucene→Elasticsearch 的通用文本搜索引擎做代码搜索，体验差、索引慢、成本高：首个 Elasticsearch 部署为约 800 万仓库建索引耗时数月，而仓库总量后来增长到 2 亿+。
• 2013 年：Quinn Slack 与 Beyang Liu 创立 Sourcegraph，主打 "universal code search"——把多仓库、多版本的代码搜索与导航做成企业级服务，被称为 "Google for code"。
• 2014–2016 年：轻量级自建代码搜索工具出现：Etsy 开源的 Hound（约 2014–2015）、Han-Wen Nithuys 的 Zoekt（2016 年前后，后成为 Sourcegraph 的默认 trigram 索引器）。
• 2009–2015 年：Exuberant Ctags 停在 5.8 版后由 Hiebert 停止维护；社区补丁续命数年后，Universal Ctags 于 2015 年作为社区接棒的 fork 出现（版本横幅 "Copyright (C) 2015 Universal Ctags Team"，见 universal-ctags/ctags 与 Wikipedia）。
• 2015 年：VS Code 发布；TypeScript 独立于 LSP 但理念相似的 tsserver 同期成熟——"语言服务进程 + JSON 消息"的模式开始成形。

主要参与者：GitHub、Sourcegraph、Etsy、Universal Ctags 社区、微软（VS Code/TypeScript 团队）。

驱动因素：代码从公司 SVN/Perforce 迁到云端 Git 托管后，"搜索我仓库里的代码"变成"搜索组织/全网代码"；同时 Exuberant Ctags 的停滞暴露了"英雄式单维护者"项目的脆弱性，社区 fork 模式（Universal Ctags）成为续命标准解法。

大型陌生仓库上手流程（当时形态）：开源世界的标准动作变成"在 GitHub 上搜代码 + 在网页里点文件树"；公司内部则架 OpenGrok（Sun/Oracle 系 Java 跨引用引擎）或 Sourcegraph。新成员上手从"装本地工具链"转为"打开一个网页"。

1.4 第四阶段（2016–2020）：LSP 标准化与网页内代码导航

关键事件与版本节点

• 2016 年 6 月 27 日：VS Code 团队发表 A Common Protocol for Languages（纵轴稿检索会话中完整读取），在 DevNation 大会上宣布与 Red Hat、Codenvy 协作把 VS Code 内部的语言服务协议开放为 Language Server Protocol（JSON-RPC 上的 didOpen/didChange/textDocument/definition 等消息）。博文的原文一句话点破动机："a given language server to be implemented once and have different tools take advantage of it"——把 M×N 降为 M+N。规范此后持续演进，3.17.0 发布于 2022 年；此后主版本演进明显放缓，3.17.0 与 3.18.0 之间约四年没有主版本更新（3.18.0 于 2026-06-04 发布为当前版本，官方规范页与本稿修订时的核实见 2.2 节与 4.5 节）。
• 2018 年：Go 官方因 Go modules 冲击旧工具链，由 Rebecca Stambler 推出语言服务器 gopls（GopherCon 演讲 "Go, pls stop breaking my editor"），2021 年初在 VS Code Go 扩展中默认启用（见 vscode-go 文档）。clangd、rust-analyzer、Eclipse JDT LS、pyright 等语言服务器在 2016–2020 年间密集出现，LSP 成为事实标准。
• 2016 年：Andrew Gallant（BurntSushi）发布 ripgrep，2016 年 9 月的基准测试文让它成为"终端 grep 默认替代品"，2017 年发布 1.0——它同时验证了"在现代硬件上 brute-force 扫描可以快到什么程度"与"专用引擎为何仍然必要"（对照下文 Blackbird 的 0.01 QPS vs 640 QPS）。
• GitHub 代码导航：
  • 2018 年 10 月 31 日：Atom 采用 tree-sitter 解析系统。tree-sitter 是 Max Brunsfeld 在 GitHub 为 Atom 开发的增量解析器（2017 Universe 演讲、2018 FOSDEM 演讲），错误容忍、增量更新，后来也被 Neovim、Zed 采用（Wikipedia)）。
  • 2018 年 11 月：GitHub 以 tree-sitter + tags 服务上线代码导航开发者预览（起初仅 TypeScript/JavaScript）。
  • 2019 年 11 月 13 日：GitHub Universe 宣布代码导航正式可用——"jump to definition"与"find all references"铺向所有公开仓库。
  • GitHub 的导航分为两档：search-based（ctags/tree-sitter 启发式）与 precise（基于 Microsoft 提出的 LSIF 预计算索引），后者支持跨仓库跳转。
• 2014–2019 年：Google 开源 Kythe（语义图标准）、各大厂内部代码搜索（Google Codesearch UI、Meta 等）持续演进，为后来的 SCIP/索引交换格式铺路。

主要参与者：微软（VS Code/LSP/LSIF）、Red Hat、Codenvy、GitHub（tree-sitter、代码导航）、Go/clangd/rust-analyzer 各语言社区、Sourcegraph。

驱动因素：编辑器之战空前碎片化（VS Code、Vim/Neovim、Emacs、Sublime、Atom），任何语言社区都无法负担为每种编辑器写插件；LSP 用一个协议换来全编辑器复用。同时"代码导航上网页"由 GitHub 的独家流量地位驱动——网页端没有你的 IDE，只能自建解析与索引。

大型陌生仓库上手流程（当时形态）：装好编辑器+语言服务器，任意符号上 goto-def / find-references / call hierarchy；GitHub 网页端则"悬停看引用、点击跳定义"。工具安装成本首次逼近于零，但"精确性 vs 可扩展性"的矛盾在网页端仍未完全解决（启发式导航常跳错）。

1.5 第五阶段（2021–2022）：检索基建大重构与 AI 编程起点

关键事件与版本节点

• GitHub 新代码搜索时间线：2021 年 12 月技术预览 → 2022 年 11 月 Universe 大会公测（官方讨论帖）→ 2023 年 5 月 8 日 GA（Changelog），旧系统于 2023 年 5 月 24 日完全退役。
• Blackbird 引擎（2023-02-06 官方工程博客，检索会话中完整读取）：搜索引擎 Blackbird 从零用 Rust 写成，专为代码域（标点敏感、无词干提取、支持正则）；公测时覆盖 约 4500 万仓库、115 TB 代码、155 亿文档，摄入管道每秒发布约 12 万文档，全量重建索引约 18 小时，分片查询 p99 约 100ms，单台 64 核主机上限约 640 QPS——对照组是 64 核×32 台机器的 ripgrep 集群只有约 0.01 QPS。
• 2021 年 12 月 9 日：GitHub 发布 stack graphs，基于 tree-sitter 生态的 Rust 库做大规模名字解析，Python 成为首个全量精确代码导航语言（研究论文 Creager et al. 2022）；2024 年精确导航扩展到 Pull Request 场景。
• 2022 年 6 月 8 日：Sourcegraph 发布 SCIP（检索会话中完整读取），以 Protobuf schema 取代 LSIF：gzip 后索引平均比 LSIF 小 4 倍（未压缩约 5 倍），Meta 报告"小 8 倍、处理快 3 倍"，解决了 LSIF 数字 ID 不可调试、增量索引难实现等问题。
• AI 起点：
  • 2021 年 6 月 29 日：GitHub 与 OpenAI 发布 Copilot 技术预览（Codex 模型）；2022 年 6 月正式商用 GA（10 美元/月，学生与热门开源维护者免费）（Wikipedia）。
  • 2022 年 11 月 30 日：OpenAI 发布 ChatGPT（业界公知日期，未逐字核对一手页面）——三个月内，"把代码贴进聊天框问"成为全球程序员的新默认动作。

主要参与者：GitHub（Blackbird、stack graphs）、Sourcegraph（SCIP、Zoekt）、OpenAI、GitHub+OpenAI（Copilot）。

驱动因素：云端代码规模逼死通用搜索引擎（旧系统"为 800 万仓库建索引要数月"）；预计算索引格式（LSIF→SCIP）解决了"精确导航"能否规模化的问题；而 GPT 类模型证明代码可以续写后，"检索"的地位被重估——它即将从"给人类看"变成"给模型喂上下文"。

大型陌生仓库上手流程（当时形态）：网页端 Blackbird 搜索 + 精确导航覆盖主流语言；本地端 Universal Ctags 与 LSP 并存。方法论仍以"人找答案"为主，但"先搜索、再读代码"的顺序已普遍。

1.6 第六阶段（2023–2024）：AI 问答与代码库感知（RAG for Code）

关键事件与版本节点

• 2023 年 3 月：Anysphere（2022 年由 MIT 学生创立）发布 Cursor)——AI 原生的 VS Code fork，核心卖点之一是代码库感知聊天：对整个仓库建索引，让 AI 的回答与修改有全库上下文。此后一年半 ARR 达约 3 亿美元，2025 年估值一度达 293 亿美元（Contrary Research）。
• 2023 年 4 月：Sourcegraph 发布 Cody（beta），打法正是"用自家代码搜索做 RAG"——先检索出相关代码片段再交给 LLM 回答；2023 年 12 月 14 日 Cody GA（Sourcegraph 博客）。
• 2023 年 12 月：GitHub Copilot Chat GA（官方公告），IDE 内自然语言问答铺开；2024 年 12 月，github.com 网页端 Copilot Chat GA，并推出 Copilot Free 免费档。
• 2023–2024 年：代码库问答基础设施成为品类：向量检索 + 符号检索（ctags/tree-sitter/LSP）+ grep 混合的"代码 RAG"成为通行架构；Greptile 等初创专门做 "codebase AI"。

主要参与者：Anysphere/Cursor、Sourcegraph、GitHub/Microsoft、OpenAI、Anthropic（Claude 系列模型自 2023 年起成为代码问答的主力底座之一）。

驱动因素：ChatGPT 证明了自然语言是新的查询界面；但通用 LLM 对私有代码一无所知，检索质量决定回答质量——拥有二十年代码搜索积累的公司（Sourcegraph、GitHub）与只做 RAG 的新玩家短暂同场竞技，最终证明"向量检索不如把检索、符号导航、grep 全部塞给一个能自己动手的模型"（下一阶段的伏笔）。

大型陌生仓库上手流程（当时形态）：新成员第一问从"README 在哪"变成"让 AI 总结这个仓库的架构"。@codebase / workspace 问答成为 2024 年度标配动作。

1.7 第七阶段（2025–2026）：智能体化上手——检索工具交给 AI

关键事件与版本节点

• 2025 年 2 月 24 日：Anthropic 以研究预览发布终端智能体 Claude Code（随 Claude 3.7 Sonnet）；2025 年 5 月 22 日随 Claude 4 GA（Anthropic 公告）。它不依赖预建索引，而是让模型在循环里自己调 grep/glob/读文件工具——从 ctags 式"先建索引给人看"，转向"让 agent 即席搜索"。OpenAI 随后推出 Codex 云端智能体；Cursor 也从编辑器转向 "agentic coding platform"。
• 2025 年 4 月：Cognition（Devin 团队）发布 DeepWiki：把 GitHub URL 里的 github.com 换成 deepwiki.com 即得自动生成的仓库 wiki（架构图 + 文档 + "Ask Devin" 问答），上线时已索引 3 万+ 仓库、40 亿行代码；社区随后出现开源复刻 DeepWiki-Open。"陌生仓库上手"被压缩成"打开一个网页问问题"。
• 2025 年 8 月：OpenAI（Codex）、Amp、Google（Jules）、Cursor、Factory 组成工作组，推出 AGENTS.md 开放标准——仓库根目录下给 AI 编码智能体看的"README"；2025 年 12 月 Linux Foundation 宣布的 Agentic AI Foundation（AAIF）将其纳入中立托管（见 Factory 公告）。仓库第一次有了面向机器读者的"门牌与地图"。
• 2025 年 12 月 2 日：Sourcegraph 与其智能体产品 Amp 拆分为独立公司，自身收缩为"代码库上下文层（The Context Layer）"——代码搜索元老正式把重心移出代理赛道，标志行业重心的迁移完成。
• 截至 2026 年 11 月：Universal Ctags 仍在活跃维护（6.0.0 发布于 2023-02-19，最新 6.2.1，2025 年 10 月），LSP 仍是编辑器语言智能的底座（当前主版本 3.18，见 2.2 节），Blackbird 支撑着 GitHub 每天的海量检索——旧范式没有死，而是变成新范式的工具层。

主要参与者：Anthropic、OpenAI、Cognition、Anysphere、Sourcegraph/Amp、GitHub、Linux Foundation（AAIF）。

驱动因素：模型能力跨过阈值后，"预建索引给人看"的性价比在单机场景被"agent 即席检索"反超；但上下文窗口与成本仍是约束，于是 ctags 式符号索引、trigram 搜索、LSP 精确导航以工具调用的形式被 agent 重新复用——历史以一种螺旋方式合流（详见交叉洞察 3.1 的"索引分化"框架）。

大型陌生仓库上手流程（当下形态）：读 AGENTS.md/README → 开 DeepWiki 生成全局认知 → 让 agent 做"代码考古"（谁写的、为什么这样改、牵连哪些模块）→ 在 LSP/精确导航里人工抽查验证 → 跑构建与测试闭环。人从"检索者"变成"提问者与验证者"。

1.8 大型陌生仓库上手流程的范式迁移（五十年一览表）

（表内各时间点均对应前文已引用来源；流程概括为综合自各阶段工具官方文档与两稿检索材料。行边界按事件归并入行——如"2016–2022"一行合并叙事阶段 1.4 与 1.5——故与 1.1–1.7 的阶段标题划分不完全对齐；其余行已与 1.1–1.7 的阶段边界对齐。）

1.9 驱动因素复盘：每一次范式迁移为什么发生

1. 规模压力永远先行：Bell Labs 500 万行催生 cscope，GitHub 2 亿仓库催生 Blackbird，40 亿行代码喂给 DeepWiki——先有"读不完的代码"，后有新工具。
2. 标准在碎片化中诞生：编辑器×语言的 M×N 困境在 2000 年代显形，2016 年由微软（恰是同时拥有语言工具与编辑器的中立方）牵头发起 LSP 解决；索引格式同理（LSIF→SCIP）。
3. 索引与即席检索的钟摆：ctags（预建索引）→ ripgrep（即席扫描）→ Blackbird/SCIP（云端预建索引）→ Claude Code（agent 即席检索）——每次摇摆都由"算力/存储成本曲线"决定，而非理念优劣。
4. 检索的消费者从人变成模型：2022 年后，代码搜索的最大新客户是 LLM 的上下文窗口；这解释了 Sourcegraph 的转型、GitHub 把搜索与 Copilot 合并、以及 ctags 意义上的"符号工具"在 agent 工具箱里的复归。
5. 上手流程的终点是"可提问"：从"给一张排序好的 tags 表"到"给一份机器可读的 AGENTS.md + 自动生成的 wiki"，五十年的方向始终一致：把理解代码所需的检索步骤进一步自动化。

二、横轴：横向对比（2026-11 截面）

2.1 四个梯队：竞争格局总览

"开发者如何在代码库里找到东西、看懂东西"这一层基础设施，在当下截面上可拆成四个梯队：

四个梯队不是简单替代关系：B 层是 AI 代理的手（Claude Code/Cursor 的检索工具就是 ripgrep 系），A 层是校准器（LSP 用来验证代理答案），C 层是规模化的分发渠道，D 层是新的交互入口。

2025 年以来两个结构性变化直接改写了竞争格局：

• "索引范式"向"代理检索范式"迁移：Cursor 弃用了自家的 embedding 代码库索引，改为 agentic search（Cursor 论坛讨论、HN 讨论、Cursor 官方文档 Search 工具页）；Claude Code 从一开始就不建索引、不 RAG，直接用 ripgrep 现场检索（HN 讨论、vadim.blog）。2026 年的综述文章干脆以《Is RAG dead? Why Cursor, Claude Code, and Devin use grep, not vectors》来概括这股潮流（MindStudio, 2026-03）。
• "搜索公司"与"代理公司"分家：Sourcegraph 已把 AI 编码代理 Amp 剥离为独立公司、自身收缩为"代码库上下文层（The Context Layer）"（事件详述与来源 URL 见纵轴 1.7 节与 4.4 节，不重复展开）。这等于官方承认：代码搜索与 AI 编码代理是两条不同的赛道。

2.2 符号级导航层：LSP vs ctags vs tree-sitter

三者其实处在同一问题——"符号从哪来"——的三条技术路线上：

• LSP 是编译器级语义：语言 server（gopls、pyright、clangd、rust-analyzer）真正做了类型解析，所以能回答"这个同名函数中这一个引用指向哪个重载"。当前主版本是 3.18（2026-06-04 发布，官方规范页与变更日志，本稿终版修订时完整读取；3.17.0 为上一版本，规范变更日志标注 2022-05-10），3.19 与基础协议 0.9 处于 Upcoming。3.17→3.18 之间约四年没有主版本更新——"核心演进放缓"有官方变更日志为证；这段时间里厂商普遍叠加私有扩展，LSP 方言化程度高（"方言化程度"为本稿判断，见 4.5 节待核实项）。
• ctags 是词法级索引：只回答"定义在哪一行"，没有引用关系和类型信息。Universal Ctags 保持活跃发版——2025 年发布 6.2.0（6 月 1 日）与 6.2.1（10 月 25 日，修复关键 bug）（GitHub Releases、docs.ctags.io），说明项目活着，但在 AI 工具链里已被 tree-sitter 显式取代——aider 官方博客《Building a better repository map with tree sitter》记录了从 ctags 方案切换到 tree-sitter 方案的决策（aider.chat, 2023-10-22）。
• tree-sitter 介于两者之间：真 AST（比 ctags 准），但不做完整类型解析（比 LSP 快且轻）。aider 用它抽取全部符号定义/引用，再做图排序，把"整仓骨架"压进 LLM 的 token 预算（repo map 文档）。

生态对比——2025 年的最大变量是 JetBrains 投降：JetBrains 长期以自有 PSI 引擎抵制 LSP，2023.2 周期才为 Quarkus 等受限场景引入 LSP API（JetBrains 博客, 2023-07）；2025 年 9 月 1 日起 LSP API 向全部 IntelliJ 用户与插件开发者开放（JetBrains 博客, 2025-09）。至此四大编辑器家族（VS Code、JetBrains、Neovim、Zed）全部接入 LSP，"协议化符号导航"取得对私有引擎的全面胜利。

结论：LSP 是精确导航的默认解，ctags 退守轻量/老环境场景，tree-sitter 吃下了 AI 上下文压缩的新增量。

2.3 文本检索层：ripgrep 与索引引擎不是替代关系

这是横轴里最反直觉的发现："不建索引"的 ripgrep 和"建索引"的引擎们不是替代关系，而是性能边界互补。

• ripgrep（不索引）：启动零成本、永远反映工作区当前状态、零维护、零隐私外流；代价是每次扫描都要付出磁盘+CPU，在超大单仓（数十万文件）上单次查询秒级。它是 Claude Code 与 Cursor 的内置检索底座：Anthropic 方面明确确认 Claude Code 不做索引、不做 RAG，用 ripgrep + glob + Explore 子代理现场检索（HN 讨论、vadim.blog 分析、amazingcto 分析）。
• 索引引擎（Zoekt/OpenGrok/Hound/livegrep）：首次建索引成本高，换来毫秒级查询与多仓库聚合。技术路线已收敛到 trigram 索引（Zoekt 系），OpenGrok 的 Lucene 路线偏老派但仍活跃发版（1.12.x，oracle/opengrok、Oracle 项目页）。
• 工程界实测的语义/文本边界：2025 年的学术研究《An Exploratory Study of Code Retrieval Techniques》给出的图景是——语义检索在"关键词零重叠"的任务上胜出，而 grep 在 import 追踪这类关键词直接相关的任务上更强（preprints.org）。

结论：单仓本地开发，ripgrep 够用且最好用；多仓库组织、跨仓库定位，必须上索引引擎。

2.4 平台托管与"上下文层"：GitHub vs GitLab vs Sourcegraph

• GitHub 已成为托管搜索的默认解：自研 Rust 引擎 Blackbird（技术细节与关键数据见纵轴 1.5 节，此处不重复），新代码搜索 2023-05-08 GA；Copilot 语义代码搜索于 2025 年 3 月前后 GA（二手来源 Augment Code，置信度中等），自然语言 Copilot Search 亦已 GA（GitHub 社区公告）。厂商还宣称语义索引使 Copilot coding agent 启动提速约 50%（digitalapplied，厂商口径，待独立验证）。注意与 Cursor 相反：GitHub 在语义索引上加码而非撤除——因为它的索引是服务端、跨用户的，规模效应成立。
• GitLab 走"双引擎"路线：老 Advanced Search（Elasticsearch）负责模糊搜索，2025-06-25 官宣基于 Zoekt 的 Exact Code Search 负责精确/正则搜索，不可用时自动回退（GitLab 博客、官方文档）。这标志着 Zoekt 正式成为"精确代码搜索"的开源事实标准（被 Sourcegraph 与 GitLab 同时采用）。
• Sourcegraph 的转型最富戏剧性：曾经的 "universal code search" 开创者，如今（a）不再开源、免费层取消，Enterprise 约 $16K/年起、Enterprise Starter $19/人/月（≤50 人、≤100 仓库，2025-02 推出）（定价页）；（b）Amp 已剥离为独立公司、自身转向 "Context Layer" 定位（事件详述见纵轴 1.7 节，格局意义见 2.1 节）。这是横轴上最重要的信号：独立代码搜索的商业空间被两端挤压——上端被 GitHub/GitLab 托管搜索吞掉，下端被 agentic search 的"无索引检索"绕过，幸存的生态位是"给 AI 代理供上下文"的基础设施。

自建轻量组：Hound（易部署小规模）、livegrep（正则）、Sourcebot（2025 年后起的新一代开源替代），见 OpenGrok 替代品对比、Sourcegraph Alternatives 2026；规模与语言覆盖不及商业方案。

2.5 AI 问答层：四种产品形态与共同前提

四种形态共同成立一个前提：AI 答案是"假设"，不是"事实"。同名符号、框架魔法（装饰器注册、配置反射）都会让 LLM 自信地给出错误答案。这正是 AI 问答层无法取代 LSP/ctags 层的根本原因——后者是确定性的。

2.6 核心对比总表

表中"成本"为公开报价或开源许可现状；"成熟度"基于两稿检索到的发布记录与官方文档。

2.7 成本格局与成熟度风险

四条成本路线

• 零成本路线（个人/内网）：ripgrep + Universal Ctags + LSP + tree-sitter，全部免费开源，唯一成本是学习配置。
• 订阅路线（个人/小团队）：Copilot Free $0（50 次 premium 请求/月 + 2000 次补全）、Pro $10、Pro+ $39、Business $19/人/月、Enterprise $39/人/月；2025-06 起 premium 请求计费，超额约 $0.04/次（Copilot 计划页、GitHub Docs、Xebia 解读）。检索到提及更高档位（如 Max $100）的信息属 2026 年新变化，细节待核实。
• 企业路线：Sourcegraph ~$16K/年起；GitLab 需 Premium/Ultimate 才含 Zoekt 精确搜索；自建 Zoekt/OpenGrok 则是"人力换许可费"。
• 隐形成本：agentic search 的 token 消耗随仓库复杂度线性上涨，大量代理跑搜索时订阅制反而不透明——这是自建索引方案在 AI 时代的新论据（控制检索成本中可预期的部分）。

成熟度与风险

三、交叉洞察：两轴结合说明了什么

3.1 "索引 vs 无索引"的正确读法：不是替代，而是分化

纵轴的钟摆叙事（预建索引→即席扫描→云端索引→agent 即席检索）与横轴"两极都赢"的判断，合起来才得到完整图景：胜负手不是"要不要索引"，而是"索引服务谁、成本摊给谁"。

• 服务端跨用户索引赢了：GitHub 在语义索引上加码而非撤除（与 Cursor 方向相反），因为 Blackbird/Copilot 语义索引的成本被全体用户摊薄，规模效应成立；GitLab 把 Zoekt 纳入付费层是同一逻辑。
• 单机代理场景转向无索引：Cursor 弃用自家 embedding 索引是标志性事件——尽管 Cursor 自己的研究显示语义索引曾带来约 12.5% 的代理准确率增益（数据与出处见 2.5 节），2025–2026 年仍然弃用（Cursor 论坛）。模型能力跨过阈值、检索工具（ripgrep/Instant Grep）足够快之后，"维护一份随时会过期的个人索引"的收益不再覆盖其成本与复杂度。Claude Code 从第一天就选择不索引、不 RAG。
• 被两头掏空的中间层：恰恰是"个人/单机本地 embedding 索引"（2023–2024 年 Cursor、Cody 早期的主要卖点）成为最清晰的淘汰对象。2026-03 的综述《Is RAG dead?》（MindStudio）概括的正是这个中间层的退场，而不是索引整体的死亡。
• 钟摆的机制：每次摆向都由算力/存储成本曲线决定。1976 年内存与磁盘贵，所以要预建排序好的 tags 表；2026 年单机 CPU 快到即席扫描毫秒级、而 token 与索引维护成本相对变贵，所以 agent 选择即席检索。若未来上下文窗口成本骤降，钟摆完全可能再次摆回"预构建、预摘要"。

这也消解了纵轴稿第七阶段"ctags 式先建索引被 agent 即席搜索替代"与纵轴稿结尾"旧范式没有死，而是变成新范式的工具层"之间的表面张力：被替代的是"为单个开发者维护索引"这个动作，不是索引本身——索引只是换了一个雇主（从个人 IDE 搬到服务端与 agent 工具调用）。

3.2 检索的消费者从人变成模型

纵轴的范式四与横轴的 D 层指向同一件事：2022 年后，代码搜索的最大新客户是 LLM 的上下文窗口。三个证据链在两轴上互相印证：

1. 公司战略：Sourcegraph 剥离 Amp、收缩为 "Context Layer"（事件详述见纵轴 1.7 节），等于承认"给人搜代码"与"给代理供上下文"是两条赛道；
2. 产品形态：GitHub 把搜索与 Copilot 合并叙事，语义索引的直接受益者首先是 coding agent（厂商宣称启动提速约 50%，见 2.4 节）；
3. 技术复归：aider 用 tree-sitter 做 repo map（aider.chat）、GitHub 用 stack graphs 做大规模名字解析——ctags 意义上的"符号工具"以新实现回到 AI 工具链。仓库本身也开始为机器读者服务：AGENTS.md 于 2025 年 8 月成为开放标准、2025 年 12 月入 Linux Foundation AAIF 托管（Factory 公告）。

这兑现了纵轴第五阶段埋下的伏笔——"检索即将从'给人类看'变成'给模型喂上下文'"；横轴则展示了它完成后的商业版图与成本结构。

3.3 确定性层与概率层的分工：AI 负责假设，LSP/grep 负责裁决

两轴结合得到本报告最重要的方法论结论：AI 问答是理解加速器，不是事实来源。

• 横轴证据：四种 AI 问答形态的共同前提是"答案是假设"；Cursor 语义索引曾带来约 12.5% 增益（见 2.5 节）说明语义检索有用但非决定性；preprints.org 的研究给出边界——语义检索赢在"关键词零重叠"的模糊定位，grep/LSP 赢在 import 追踪这类符号级事实。
• 纵轴证据：五十年的工具演化始终在提高"确定性"——ctags 的行号、LSP 的类型解析、LSIF/SCIP 的预计算索引都是确定性产物；AI 问答层是五十年里第一次出现的"概率性"导航层。
• 落点：因此验证纪律不可省略——AI 说的每个"定义在 A、被 B 调用"，用 LSP find-references 或精确 rg 复核。上手陌生仓库的最优流程，本质上是"概率层压缩阅读量、确定性层裁决事实"的双层严格执行（见 3.6 的五步流程与两条纪律）。

3.4 标准化的胜利与放缓：M+N 之后，演进转入厂商扩展

纵轴记录了 LSP 的诞生逻辑（M×N→M+N），横轴记录了它的完成与隐忧：

• 完成：JetBrains 已全面开放 LSP API（2025-09，事件与来源详见 2.2 节），四大编辑器家族（VS Code、JetBrains、Neovim、Zed）全部接入——2016 年埋的种子九年后收获。索引格式走同样的标准化路径（LSIF→SCIP，Sourcegraph 牵头、Meta 背书）。
• 放缓与方言化：LSP 主版本演进放缓有官方变更日志为证——3.17.0（变更日志标注 2022-05-10）到 3.18.0（变更日志标注 2026-06-04）之间约四年没有主版本更新（官方规范页，本稿修订时读取）。这段时间里演进动力转移到厂商私有扩展与 AI 适配层；值得注意的是，3.18 的头部新特性正是 inline completion（AI 行内补全）与"LLM 生成"代码动作标记（CodeActionTag.LLMGenerated）——核心规范的演进方向已明确指向 AI 适配。这与 ctags 的历史形成微妙对照——Exuberant Ctags 停更催生了社区 fork（Universal Ctags），LSP 的"放缓"则由厂商扩展消化。标准化组织降速后的真空，被实际利益方填补，这几乎是所有成功协议的共同宿命。
• 新一轮标准化已经开始：AGENTS.md 把仓库描述从"给人读的 README"分裂出"给机器读的版本"，其 Linux Foundation 中立托管路径与当年 LSP 的开放路径同构——可以预期它将成为 agent 时代的 "LSP 时刻"。

3.5 商业生态位收敛：从 "Google for code" 到 "Context Layer"

把纵轴的公司史和横轴的定价表放在一起，能看到独立代码搜索生态位的收敛过程：

• 2013–2022：Sourcegraph 以 "Google for code" 立身，与 GitHub 托管搜索错位竞争（多仓库、多版本、企业内网）；
• 2023–2024：RAG 热潮让"代码搜索公司"看起来像 AI 公司（Cody 发布、GA）；
• 2025–2026：双重挤压显形——上端被 GitHub/GitLab 捆绑销售吞掉预算（GitLab Exact Search 只对 Ultimate 层开放、Sourcegraph 免费层取消、不再开源），下端被 agentic search 绕过（不买搜索服务也能让 agent 现场检索）；幸存生态位是纵轴 1.7 节记录的 "Context Layer" 定位——给人和代理供上下文的基础设施。
• 对用户的意义：不要按"AI 公司 vs 工具公司"给这些厂商分类，而要按"确定性层（LSP/ctags/精确搜索）/概率层（AI 问答）/上下文层（供索引与上下文的基础设施）"的分工理解它们的去留与定价逻辑。

3.6 对用户的判断与建议

（1）工具选型：三套参考组合

（2）陌生仓库上手流程：五步两纪律

原则只有一条：每一层的工具干自己擅长的事。在这一条原则下立两条纪律，正文反复出现的正是它们：

• 纪律一 · 先 grep 后 LSP（工具顺序）：文本线索（日志、配置、字符串）用 ripgrep 找，符号级事实（定义、引用、重载）交给 LSP 裁决——grep 管广度、LSP 管精度（落实在第 2 步①）；
• 纪律二 · AI 答案必须复核（验证）：AI 说的每个"定义在 A、被 B 调用"，用 LSP find-references 或精确 rg 复核，不可省略（落实在第 3 步②，方法论依据见 3.3 节）。

• 第 0 步 · 站外预习（clone 前，约 10 分钟）：① DeepWiki 预习——把 github.com/<org>/<repo> 换成 deepwiki.com/<org>/<repo>，读架构图和模块摘要，直接提问"这个项目的核心数据流是什么"（只对公开仓库有效，Cognition 博客）；② GitHub Code Search 定锚点——用 path: symbol: 限定符搜入口（main、路由表、配置加载，Blackbird 技术博客）；③ 看仓库元数据——README、CODEOWNERS、最近三个月的 commit 热区、release 节奏，判断"哪些目录是活的，哪些是化石"。
• 第 1 步 · 本地建图（clone 后，约 10 分钟）：① 读构建系统——go.mod/pom.xml/Cargo.toml/package.json/CMakeLists，模块边界和依赖方向往往就在这里，比任何文档都可靠；② 生成符号地图——老派快速路 universal-ctags -R . 生成 tags、编辑器内 :tag <symbol> 秒跳；现代路 Neovim/Zed 的 tree-sitter 或 LSP 接管跳转；AI 路 aider 的 repo map（tree-sitter + 图排序）直接把"整仓骨架"喂给 LLM；③ 跑一遍构建/测试——能编译的仓库才能用 LSP。
• 第 2 步 · 精确定位（随读随查）：① 先 grep 后 LSP（纪律一）——ripgrep 搜字符串/日志/配置项（rg -n "xxx" --type py），找到符号后交给 LSP 做 go-to-definition / find-references 拿精确调用关系；② LSP 冷启动慢时用 ctags 的 tags 文件兜底（超大仓语言 server 索引要几分钟）；③ 跨仓库需求才上索引引擎——本地单仓 ripgrep 足够，"这个内部库被哪些项目用到"这类问题需要 Zoekt/Sourcegraph/平台搜索。
• 第 3 步 · AI 问答压缩理解成本（并验证）：① 用代理做定向理解——让 Claude Code/Cursor 解释"模块 X 和模块 Y 怎么通信"，它会用 ripgrep + Explore 子代理自动遍历（HN）；② AI 答案必须复核（纪律二，不可省略）——AI 说的每个"定义在 A、被 B 调用"，用 LSP 的 find-references 或精确 rg 复核；语义检索擅长"关键词零重叠"的模糊定位，但符号级事实必须以 LSP 为准（边界研究见 preprints.org）；③ 让 AI 生成导航资产——模块地图、调用链图、术语表，存进仓库笔记。
• 第 4 步 · 固化导航资产（形成复利）：tags 文件进 CI、.gitignore 之外维护个人笔记、把"这个仓库的坑"写进 CLAUDE.md/AGENTS.md 类代理说明文件——下次上手时间减半。

这条五步两纪律的流程本身就是五十年范式迁移（纵轴 1.8 节表格）的终点形态：纵轴的结论"上手流程的终点是可提问"，落到横轴就是"站外预习→本地建图→精确定位→AI 问答（验证）→固化导航资产"的可执行纪律。

（3）成本建议

• 个人/内网：走零成本路线（ripgrep + Universal Ctags + LSP + tree-sitter），唯一成本是学习配置；
• 个人/小团队订阅：Copilot 免费档已够轻量使用（50 次 premium 请求/月 + 2000 次补全），Pro $10 档性价比最高；注意 2025-06 起 premium 请求计费、超额约 $0.04/次（Xebia）；
• 企业：代码已在 GitHub/GitLab 就用平台捆绑方案（避免为搜索单独付费）；确有多仓库重构、合规审计需求再评估 Sourcegraph（~$16K/年起）或自建 Zoekt——"人力换许可费"；
• 盯住隐形成本：大量代理跑 agentic search 时，token 消耗随仓库复杂度线性上涨、订阅制反而难以核算——预算敏感的团队应测量 agent 检索的真实 token 开销，再决定是否为"可预期的检索成本"自建索引。

（4）风险提示与待核实项

• AI 幻觉：同名符号与框架魔法（装饰器注册、配置反射）会诱导 LLM 给出自信的错误答案，验证纪律（纪律二）不可省略；
• 厂商自述待独立验证：Cursor Instant Grep "快于 ripgrep"、Copilot 语义索引"使 coding agent 提速约 50%"均为厂商口径；
• 置信度中等的信息：Copilot 语义搜索 GA 时间（2025-03）来自二手来源（Augment Code 对比文）；
• 业界公知但未逐字核对的日期：GitHub 2008 年上线、Stack Overflow 2008 年创办、ChatGPT 2022-11-30 发布；LSP 规范版本演进已在本稿修订时经官方规范页核实（见 4.5 与 4.6 第 3 条）；
• 硬约束仍在：模型成本与上下文窗口仍是智能体化上手的约束，agent 检索的答案需要人兜底；DeepWiki 生成内容同样需要抽查。

四、参考来源

4.1 两稿检索会话中完整读取的四个核心一手页面

• LSP 官方公告（2016-06-27）：https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol
• GitHub Blackbird 技术博客（2023-02-06）：https://github.blog/engineering/architecture-optimization/the-technology-behind-githubs-new-code-search/
• SCIP 发布公告（2022-06-08）：https://sourcegraph.com/blog/announcing-scip
• Ctags 词条（含 BSD 2.0/Ken Arnold/Exuberant/Universal 史）：https://en.wikipedia.org/wiki/Ctags

（终稿修订时新增完整读取：LSP 官方规范页与变更日志，见 4.2。）

4.2 历史与基础工具

• cscope 历史：https://cscope.sourceforge.net/history.html ；https://en.wikipedia.org/wiki/Cscope
• Google Code Search 与 trigram 索引：https://en.wikipedia.org/wiki/Google_Code_Search ；https://swtch.com/~rsc/regexp/regexp4.html ；https://github.com/google/codesearch
• Universal Ctags：https://github.com/universal-ctags/ctags ；https://github.com/universal-ctags/ctags/releases （终稿修订时抓取：可见 6.0.0、6.1.0、6.2.0、6.2.1 的 releases 页面）；https://docs.ctags.io/en/stable/news/HEAD.html
• LSP 官网与规范（含 3.17、LSIF）：https://microsoft.github.io/language-server-protocol ；https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification ；https://microsoft.github.io/language-server-protocol/specifications/lsif/0.6.0/lsif/
• LSP 官方规范页与变更日志（终稿修订时完整读取，核实 3.18.0 发布日期与 3.17→3.18 间隔）：https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/
• gopls 与 Go 工具史：https://go.dev/blog/11years ；https://github.com/golang/vscode-go
• tree-sitter：https://en.wikipedia.org/wiki/Tree-sitter_(parser_generator) ；https://github.blog/news-insights/product-news/atoms-new-parsing-system ；https://archive.fosdem.org/2018/schedule/event/code_tree_sitter
• GitHub 代码导航与 stack graphs：https://github.blog/news-insights/product-news/universe-day-one ；https://github.blog/open-source/introducing-stack-graphs ；https://arxiv.org/pdf/2211.01224
• GitHub 代码搜索 GA 与公测：https://github.blog/2023-05-08-github-code-search-is-generally-available/ ；https://github.blog/changelog/2023-05-08-the-new-code-search-and-code-view-is-now-generally-available ；https://github.com/orgs/community/discussions/38692
• ripgrep：https://blog.burntsushi.net/ripgrep/
• OpenGrok：https://github.com/oracle/opengrok ；https://oracle.github.io/opengrok ；Hound：https://github.com/etsy/hound ；Zoekt：https://github.com/sourcegraph/zoekt
• Sourcegraph 公司史：https://en.wikipedia.org/wiki/Sourcegraph
• IntelliSense 起点：https://en.wikipedia.org/wiki/Code_completion

4.3 生态与平台对比

• JetBrains LSP API 开放（2025-09）：https://blog.jetbrains.com/platform/2025/09/the-lsp-api-is-now-available-to-all-intellij-idea-users-and-plugin-developers
• JetBrains LSP 起点（2023-07）：https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-developers
• aider repo map（弃 ctags 转 tree-sitter）：https://aider.chat/2023/10/22/repomap.html ；https://aider.chat/docs/repomap.html
• GitLab Exact Code Search：https://about.gitlab.com/blog/exact-code-search-find-code-faster-across-repositories ；https://docs.gitlab.com/user/search/exact_code_search
• GitLab 代码智能对照事件（终稿修订检索发现，2019-11-12 宣布与 Sourcegraph 集成；初稿所记 2019-06-11 事件未能核实，该括注已删除）：https://about.gitlab.com/blog/sourcegraph-code-intelligence-integration-for-gitlab
• 自建搜索方案对比：https://faun.dev/toolbox/alternatives/opengrok-alternatives ；https://repowise.dev/blog/comparisons/sourcegraph-alternatives-2026
• Sourcegraph 定价：https://sourcegraph.com/pricing
• Copilot 计划与计费：https://github.com/features/copilot/plans ；https://docs.github.com/en/copilot/get-started/plans ；https://xebia.com/blog/github-copilot-premium-requests
• Copilot Search GA：https://github.com/orgs/community/discussions/164214
• Copilot 语义搜索对比（二手来源）：https://www.augmentcode.com/guides/github-copilot-vs-amazon-q-enterprise-comparison

4.4 AI 问答与编码代理

• Sourcegraph/Amp 分家（2025-12-02）：https://sourcegraph.com/blog/why-sourcegraph-and-amp-are-becoming-independent-companies ；https://tessl.io/blog/sourcegraph-spins-out-ai-coding-agent-amp-as-a-standalone-company
• Cursor 弃用索引 / Instant Grep：https://forum.cursor.com/t/what-do-you-think-about-cursor-removing-the-codebase-indexing-settings/165899 ；https://news.ycombinator.com/item?id=49487825 ；https://cursor.com/docs/agent/tools/search
• Cursor 语义索引原理与增益：https://cursor.com/blog/secure-codebase-indexing ；https://www.digitalapplied.com/blog/cursor-semantic-search-coding-ai-guide ；https://www.digitalapplied.com/blog/github-copilot-coding-agent-50-percent-faster-semantic-search
• Claude Code 无索引检索：https://news.ycombinator.com/item?id=43164253 ；https://vadim.blog/claude-code-no-indexing ；https://www.amazingcto.com/grep-or-lsp-in-claude-code
• RAG→grep 趋势综述（2026-03）：https://www.mindstudio.ai/blog/is-rag-dead-what-ai-agents-use-instead
• 检索技术边界研究（2025）：https://www.preprints.org/manuscript/202510.0924
• DeepWiki：https://cognition.com/blog/deepwiki ；https://docs.devin.ai/work-with-devin/deepwiki ；https://deepwiki.com ；官方仓库：https://github.com/CognitionAI/deepwiki ；社区开源复刻 DeepWiki-Open（AsyncFuncAI，MIT 许可）：https://github.com/AsyncFuncAI/deepwiki-open （终稿修订时核实，替换原稿错链）
• Windsurf（终稿修订时新增，用于 2.5 表定位）：https://techcrunch.com/2025/07/14/cognition-maker-of-the-ai-coding-agent-devin-acquires-windsurf ；https://cognition.com/blog/windsurf
• AGENTS.md：https://www.infoq.com/news/2025/08/agents-md ；https://factory.com/news/agents-md
• Copilot 时间线与 Chat GA：https://en.wikipedia.org/wiki/GitHub_Copilot ；https://github.blog/news-insights/product-news/github-copilot-chat-now-generally-available-for-organizations-and-individuals
• Cody 发布与 GA：https://sourcegraph.com/blog/cody-is-generally-available
• Cursor：https://en.wikipedia.org/wiki/Cursor_(company) ；https://research.contrary.com/company/cursor
• Claude Code GA：https://www.anthropic.com/news/claude-4

4.5 综合稿诚实性说明（继承两稿，并补充终稿修订记录）

• 本综合稿初版未新增任何外部检索：全部事实、日期、数据与 URL 均继承自两份章节稿在 2026-11-05 检索会话中的记录；初版撰写过程中执行的操作仅为读取两份章节稿文件、核对其内容并撰写综合稿，故各链接的可达性与内容以两稿检索时点为准。
• 终稿修订时（2026-11-05）为落实审读意见执行了少量核对性检索，新增/更正的事实与来源均已标注在正文与 4.2–4.4 节：
  1. LSP 官方规范页与变更日志（完整读取）：当前主版本为 3.18（变更日志标注 3.18.0 发布于 2026-06-04），3.19 与基础协议 0.9 为 Upcoming，3.17.0 为上一版本（变更日志标注 2022-05-10）。据此，初稿四处"停在 3.17/更新基本停滞"的事实性表述已更正为"3.17→3.18 间隔约四年、演进放缓"（详见 4.6 第 3 条）。
  2. DeepWiki-Open 社区仓库：核实为 https://github.com/AsyncFuncAI/deepwiki-open （README 自述为 DeepWiki 的开源实现，MIT 许可）；初稿错链指向的 https://github.com/CognitionAI/deepwiki 实为 Cognition 官方仓库，已在 4.4 节改标"官方仓库"。
  3. Windsurf 定位：核实其前身 Codeium、2025-07-14 被 Cognition 收购（TechCrunch、Cognition 博客），用于 2.5 表一句话定位。
  4. Universal Ctags releases 页：可见 6.0.0、6.1.0、6.2.0（2025-06-01）、6.2.1（2025-10-25）等 6.x 版本，未见 5.x；初稿"5.9→6.x 大版本跨越"缺少 5.9 依据，已改为与文内证据一致的"2025 年发布 6.2.x"。
  5. GitLab 2019-06-11 事件：检索未能确认当日 GitLab 宣布了什么（可核实的对照事件是 2019-11-12 GitLab 宣布与 Sourcegraph 集成代码智能，https://about.gitlab.com/blog/sourcegraph-code-intelligence-integration-for-gitlab ），故初稿该裸日期括注已删除。
  6. Krugle 条目：本修订会话多次抓取 Wikipedia 失败（网络超时），无法核实 Krugle 自身词条页，故初稿的错链（指向 Google Code Search 词条）已移除、保留纯文本，不猜测新链接。
• 两稿检索会话中完整读取的四个核心一手页面：LSP 官方公告、GitHub Blackbird 技术博客、SCIP 发布公告、Wikipedia 的 Ctags 词条；终稿修订时另完整读取 LSP 3.18 官方规范页。
• 业界公知日期但未逐字核对一手页面：GitHub 2008 年上线、Stack Overflow 2008 年创办、ChatGPT 2022-11-30 发布。
• 置信度中等（二手来源）：Copilot 语义搜索 GA 时间（2025-03，来自 Augment Code 对比文）。
• 厂商口径待独立验证：Cursor Instant Grep 性能、Copilot 语义索引使 coding agent 提速约 50%、GitHub Copilot 更高档位（如 Max $100）的细节待核实。
• 本稿判断（待核实项）：LSP 3.17→3.18 空窗期内"厂商普遍叠加私有扩展、方言化程度高"——规范版本演进事实有官方变更日志为证，但各方言的扩展密度未逐一统计，此判断保留为待核实项；agentic search 的 token 隐形成本测算（3.6 节）亦属经验判断。
• 两稿口径差异的统一处理：DeepWiki 发布时间统一为 2025 年 4 月上线（纵轴记 4–5 月窗口）；"索引被 agent 替代"与"两极都赢"统一为"索引分化"框架（3.1 节）；ctags 地位统一为"退位不退场"。

4.6 终稿修订记录（审读意见逐条处理，2026-11-05）

1. 数据自相矛盾（45 亿 vs 155 亿）：1.0 节驱动因素改为"Blackbird 公测时约 155 亿文档规模"（口径与来源统一到 1.5 节已带来源的 Blackbird 工程博客数据）；"45 亿"全文无出处，未找到其为另一时点数据的证据，故删除。
2. "五步双纪律"标题与内容不符：3.6（2）改为"五步两纪律"，并显式定义两条纪律（纪律一：先 grep 后 LSP 的工具顺序；纪律二：AI 答案必须用 LSP/rg 复核），在正文（第 2 步①、第 3 步②、3.3 节、风险提示）点明；TL;DR 的五步命名统一为与 3.6 步骤名一致的"站外预习→本地建图→精确定位→AI 问答（验证）→固化导航资产"。
3. LSP"停滞"断言无来源：修订时完整读取官方规范页后发现该断言已过时（3.18.0 已于 2026-06-04 发布），故按事实改写：1.4、2.2、2.6 表、2.7 表、3.4 节统一为"3.17（2022-05-10）→3.18（2026-06-04）间隔约四年、演进放缓"，附官方规范页来源；"方言化程度"降级为本稿判断并列于 4.5 待核实项；3.4 节标题"停滞"改"放缓"，并补入 3.18 的 inline completion 与 LLM-generated 标记这两个有据可查的新事实。
4. Universal Ctags"5.9→6.x"无出处：2.2 节与 2.6 表改为与文内证据一致的"2025 年发布 6.2.x"（6.2.0 于 2025-06-01、6.2.1 于 2025-10-25），并以修订时抓取的 releases 页佐证（未见 5.x 版本）。
5. GitLab 2019-06-11 裸日期：无法核实当日事件，按审读意见允许的方案删除该括注；可核实的 GitLab 对照事件（2019-11-12 与 Sourcegraph 集成代码智能）补入 4.3 节来源清单。
6. 去重承诺未兑现：Sourcegraph/Amp 拆分保留纵轴 1.7 节一处详述，2.1、2.4、2.6 表、3.5 节改为"见 1.7 节"式引用；JetBrains 2025-09 开放 LSP API 保留 2.2 节一处详述（含两个 URL），2.6 表、2.7 表、3.4 节改为引用；Cursor 12.5% 增益保留 2.5 表一处详述（含 URL），3.1、3.3 节改为引用。所有被移除的 URL 均保留在 4.4 节来源清单中。
7. 时间分段三套口径：1.2 节标题由"1996–2009"改为"1996–2007"（该节内容最晚事件为 2004–2006 年的云端萌芽，与 1.3 节"2008–2015"及 1.8 表"1996–2007/2008–2015"行完全对齐）；1.8 表注补一句说明"2016–2022"行系合并叙事阶段 1.4 与 1.5、按事件归并入行；1.0 节补一句"相邻叙事阶段之间允许少量事件交叠"。
8. 链接与指称不符、实体凭空出现：Krugle 错链（指向 Google Code Search 词条）移除并保留纯文本（其自身词条未能核实）；DeepWiki-Open 链接更正为 https://github.com/AsyncFuncAI/deepwiki-open ；Windsurf 在 2.5 表补一句话定位（前身 Codeium，2025-07-14 被 Cognition 收购，附 TechCrunch 来源）。