为何大型代码库迁移工具正在让工程师失效
在大型软件项目的迁移项目中，瓶颈往往不在于工程师的能力或项目计划的制定，而在于工具无法看清整个代码库。当迁移进行六个月仍未完成、估算持续超支、工程师被迫花费大量时间在调查而非实施上时，问题通常出在工具的视野局限上。
被忽视的搜索问题
大多数工程团队认为代码搜索是一个已解决的问题：拥有 IDE、grep 和 GitHub 搜索栏似乎就足够了。然而，一旦代码库达到一定规模，关键词搜索的局限性便暴露无遗。
- 缺乏语义理解：关键词搜索只能找到字符串，无法理解代码的功能、组件间的关联或变更带来的潜在影响。
- 隐形的时间成本：工程师在开始编写代码前，需要花费大量时间阅读代码、追踪调用链、跨仓库梳理导入关系，以在脑海中构建一个过于庞大而难以持有的模型。
- 不可预见的破坏：基于局部理解的变更，往往会引发工程师未曾检查的其他仓库中的故障。
多仓库环境的挑战
大多数迁移工具是为单仓库环境设计的，假设代码仅存在于一个地方。然而，现代工程组织通常更为复杂：
- 分布式代码库：收购带来的不同公司代码、平台团队拆分的服务、遗留系统（如 Perforce）与现代化 Git 系统的并存。
- 工具视野盲区：当搜索仅在一个版本控制系统中有效，或静态分析工具无法跨越仓库边界时，依赖图谱将是不完整的。
- AI 代理的局限：AI 编码助手若仅加载本地文件作为上下文，可能会给出看似自信但实际破坏其他模块的建议。
MathWorks 的工程团队便曾面临此困境，其代码库跨越四十余年，分布在 Perforce、GitHub 和 GitLab 中。其原生搜索工具仅在 Perforce 内有效，导致工程师在其他系统中工作时常处于“半盲”状态。
AI 代理放大而非解决问题
随着 AI 编码代理的普及，它们本应加速迁移工作，生成样板代码并执行重复性转换。然而，代理面临与人类工程师相同的可见性问题，甚至更甚。
- 缺乏隐性知识：人类工程师经过数年的工作，已内化了代码库的上下文，知道哪些模块脆弱、哪些依赖是隐性的。而从头开始的 AI 代理只有其上下文窗口能容纳的内容。
- 实验数据佐证：Sourcegraph 的 CodeScaleBench 在 40 多个仓库、370 个真实企业任务中评估了代理性能。在无代码智能工具的情况下，代理在 Kubernetes 规模系统上运行超时需 2 小时；接入 Sourcegraph 的 MCP (Model Context Protocol) 工具后，同一任务仅需 89 秒。
- 检索精度飞跃：在检索任务中，无代码智能的代理正确检索文件的比例仅为 12.7%，而接入 MCP 后提升至 27.7%。在处理跨仓库的组织级查询时，前 5 名的精确率从 0.7% 飙升至 47.1%。
当代理无法找到相关代码时，它们要么放弃，要么胡编乱造，这两种结果都代价高昂。
规模化后的成本累积
这些问题不会停留在小范围内。迁移时间翻倍不仅意味着工程成本的倍增，还会延迟依赖项目，延长团队同时维护新旧系统的周期，并增加迁移永远无法完全完成的风险，导致遗留分裂架构。
解决方案：跨仓库代码智能
迁移问题的本质不是人员或流程问题，而是可见性问题。当工程师和代理能够看清他们正在工作的内容时，他们就能做出更好的决策。
具备跨仓库、跨版本控制系统和跨语言能力的代码智能，为团队提供了准确规划、自信执行并确认迁移完成的基础。这正是区分“成功交付的迁移”与“永远停留在待办列表中的项目”的关键。
Sourcegraph 为管理大型复杂代码库的团队提供跨仓库代码智能，帮助工程团队通过更好的代码视野，更快地完成迁移。
"The difference is not model capability. The difference is what the model can see."
—— Sourcegraph 团队
