长文本代码库 RAG 优化：如何通过精简上下文窗口减少模型幻觉

把整个项目源码全塞进上下文窗口（Context Window）绝对是很多人的误区，尤其是用 Claude 3.5 Sonnet 这种长文本模型时，Token 越多，模型越容易在代码细节上产生“幻觉”，甚至开始胡编一些不存在的 API。

我最近在处理一个 5 万行以上的 TypeScript 项目，发现直接用 @Codebase 索引经常导致 AI 给出看似正确但实际运行报错的建议。解决这个问题的核心不在于增加窗口，而在于通过 .cursorrules 或自定义提示词，强制模型执行「精简上下文」策略。

最有效的操作是建立一套上下文过滤机制。不要让 AI 漫无目的地搜索，而是在 Prompt 中明确要求它先检索接口定义，再查看实现逻辑。

我在 .cursorrules 里加入了一段约束，强制它在分析复杂逻辑前先执行以下步骤：

# Context Precision Strategy
1. Identify core types/interfaces related to the query first.
2. Only read implementation files (.ts/.tsx) after locating the exact method signature.
3. If a function is imported from another module, explicitly state the import path before proposing changes.
4. Discard any boilerplate code (like CSS-in-JS or redundant types) from the current reasoning chain.

另一个踩过的坑是：AI 经常在 RAG 检索到多个相似函数时产生混淆。比如项目里有 UserStore.ts 和 UserProvider.ts，它可能会把 A 文件的逻辑写到 B 文件里。

为了解决这个问题，我习惯在对话开始前，先手动用 CMD+K 喂给它一个关键路径清单，而不是依赖自动索引。

具体的实战操作流程：
第一步：通过 grep 或全局搜索找到所有相关的 Type 定义，直接把这些定义复制给 AI，告诉它：「这是当前业务的唯一真理来源」。
第二步：使用命令限定范围，比如在 Cursor 中使用 @Files 精确指定 2-3 个核心文件，而不是用 @Codebase。
第三步：要求 AI 在输出代码前，先用一段简短的伪代码描述它对当前逻辑流的理解。

如果发现 AI 开始胡言乱语，立刻输入：

Stop. You are hallucinating the method `xxx`. Please re-scan the provided files and verify if this method exists in the current scope.

通过这种「先定边界 → 再读实现 → 最后输出」的链路，代码采纳率从之前的 60% 提升到了 90% 以上，且极大地减少了因为上下文过载导致的低级 Bug。