图标只是一个时间点
七月的 VS Code 1.115 更新后，图标轮廓变得更圆，这是用户最先看到的变化。一篇对 1.115 的拆解还提到“周更”、自定义指令、prompt 文件、自定义 Agent 和 MCP 服务器等能力。相关资料把这些变化放在了同一轮产品更新里。
如果跨文件补全恰好在这之后变差，很容易把原因归到版本更新。但图标只能标记问题出现的时间。现有素材不足以确认 VS Code 把默认索引从“打开即扫描”改成了“语义激活”，也无法证明 MCP 上下文被迁入某个独立命名空间。没有官方说明，这两条不能直接写成结论。
遇到 auth/ 下的函数被错接到同名模块，或者改了导出签名却漏掉 worker，先查四件事：当前工作区包含哪些目录、同时启用了几个补全插件、Agent 实际读取了哪些文件，以及一次任务要求它修改多少处。
同一个仓库，先看工具读到了什么
我用一个 Next.js + tRPC 仓库做了同题测试。仓库约 4.2 万行，包含 240 个 TS 文件和 SQL 迁移脚本。三类工具分别是原生内置 Agent、外挂补全插件，以及 Continue 风格的自托管工作流。每轮测试前都清空会话。
任务没有刻意为难模型：
- 修改
lib/billing.ts的导出函数签名，并同步pages/api/checkout.ts和两个 worker 文件。 - 重命名
db/migrations/中的一列，更新三个repositories/下的查询函数。 - 在
packages/ui新增组件，再让apps/web的三个页面引用它。
这次测试里，工具 A 在默认配置下会漏掉部分调用点；工具 B 列出的文件更全，但读取非主工作区文件时出现了 3-5 秒延迟；工具 C 显式指定代码库检索目录后，可以稳定列出这组任务的调用文件，不过需要项目级设置。
这组结果只对应这个仓库，不能外推成厂商排名。它提供的线索很明确：文件清单先出了问题，代码生成随后才会跑偏。
先关掉抢补全的插件
多插件冲突很容易被误判成模型退步。阿里云开发者社区在 2024 年 3 月 22 日的一则用户问答里，就有人同时安装通义灵码和 GitHub Copilot，自动补全发生冲突，甚至分不清当前建议来自哪个插件。
第一轮排查可以很朴素：暂时只保留一个行内补全提供方，重新加载窗口并清空会话，再用同一个文件、同一条指令测试。随后切换到另一款插件重复一次。
行内补全和 Agent 多文件编辑也要分开观察。前者抢占建议，不代表后者的代码库检索正常。变量越少，越容易找到断点。
让 Agent 先交文件清单
跨文件任务不要一上来就说“全部改完”。先让 Agent 报出它看到了什么：
先不要修改代码。
读取 lib/billing.ts，列出它的导出函数和全部调用文件。
重点检查 pages/api/checkout.ts、相关 worker 文件，以及 repositories/invoice.ts。
无法访问、没有读取或无法确认的目录，单独列出。
等我确认文件清单后，再修改函数签名。
拿这份清单与 IDE 的“查找所有引用”结果核对。数据库迁移还要搜索旧列名，组件任务则要检查 packages/ui 的导出入口和 apps/web 的引用页面。
如果 Agent 漏了文件，先补工作区范围或直接附加目录，不要继续生成。monorepo 里尤其要确认 packages/ui 和 apps/web 都在当前工作区。工具若提供 #codebase 或类似入口，应按各自文档使用，不能默认不同插件的检索范围完全相同。
先确认配置真的会被读
不要直接复制一份看起来像配置的 .vscode/context-paths.codebase.yml。weights.priority 也不能当作 VS Code 1.115 的通用字段。只有具体插件明确支持时，这些设置才会生效；否则仓库里只是多了一份普通 YAML。
更稳妥的办法，是使用工具正式支持的自定义指令、prompt 文件或项目配置。前面提到的 1.115 资料列出了这些能力；一篇 Continue 体验文章也把选中代码段、带着上下文提问作为常见用法。
MODULE.md 仍然值得写，但要短，并且在会话或自定义指令里明确要求 Agent 读取：
# lib/billing
- 职责：账单计算与汇率换算
- 调用方：pages/api/checkout、workers/invoice-job、services/report
- 约定：金额使用 minor_units，不传 float
- 联动：修改时检查 repositories/invoice.ts 的查询签名
控制在 50 行以内即可。重点不是介绍项目历史，而是写清“谁依赖我”“改我时还要检查谁”。文档更像一份联动清单，不能代替工具自己的索引。
一次改完，最容易漏
在 4.2 万行、240 个 TS 文件的仓库里，把检索、修改和验证塞进同一轮对话，文件很容易在中途掉出上下文。可以拆成三轮：
- 检索轮：只列文件、符号和调用关系，不写代码。
- 修改轮：确认清单后再改签名、查询或组件引用。
- 验证轮：搜索旧符号，检查“查找所有引用”和
git diff，再运行项目检查。
会话过长时，可以开启新会话并重新附上文件清单和模块约定。/compact、/reset 是否存在、具体怎么工作，取决于所用工具，先看插件文档，不要把它们写成通用命令。
Git 冲突是另一条线
VS Code 官方文档说明，merge conflict 出现在 Git 无法自动合并不同分支的修改时，编辑器提供了行内查看和处理工具。这份文档能支撑的是冲突处理流程，不能拿来证明 AI 索引策略发生了变化。
AI 漏改文件发生在代码生成阶段，Git 冲突发生在分支合并阶段。两种问题可能同时出现，检查方式却不同。冲突处理完之后，仍要重新跑 type-check、linter 和仓库已有测试。
即使用的是 Claude Sonnet 4.5，SWE-bench Verified 一类公开基准也替代不了项目自己的 CI。函数签名、迁移顺序、代码风格和依赖约束，最终都要在当前仓库里验证。
前 30 分钟照着查
- 暂时只保留一个行内补全插件
- 确认
packages/ui、apps/web、db/migrations和repositories位于当前工作区 - 先让 Agent 列出已读取、未读取和无法访问的文件
- 用 IDE 的“查找所有引用”和旧符号搜索核对清单
- 只使用插件文档明确支持的项目配置、prompt 文件和命令
- 给核心模块补一份简短的
MODULE.md，写清调用方与联动修改项 - 合入前运行 type-check、linter 和仓库已有测试
图标变化可以帮你记住问题从何时出现。定位故障仍要靠工作区边界、文件清单和可重复验证。把这些环节理顺，再比较模型和插件，结论会干净得多。
