Long Context Still Needs Code Retrieval
In a practitioner account, an author reports that placing an entire medium-sized frontend repository into a 1M-token context led the model to call a nonexistent store method and make incorrect fixes. The proposed hybrid workflow uses vector retrieval to reduce hundreds of candidate files to about ten, then adds relevant snippets and call chains to the long context for cross-file comparison. The author also recommends shorter system prompts, observability that distinguishes retrieval failures from ignored information, and placing critical tool instructions near the beginning or end of the prompt.
The account highlights that a larger context window helps with comparison across selected code but does not by itself solve retrieval, instruction placement, instruction following, or correctness. It presents retrieval and long-context review as complementary steps rather than substitutes.
装得下不等于用得好
百万 token 上下文铺开的第一周，我做了一件很蠢的事：把一个中型前端仓库整包塞进去，让它读完再改。结果它非常自信地调用了一个不存在的 store 方法，还顺手修复了几处上一轮我自己写错的地方——修复的方向也是错的。
窗口从 32k 涨到 128k 再到 1m，很多团队把它当成再也不用做检索的理由。但上下文长度解决的是能塞多少，没有解决该看哪一段。这两个问题的难度完全不在一个量级。
我的混合方案：先检索压缩，再让长窗口交叉比对
现在的链路是三段：
- 向量检索把候选文件从几百个压到十个左右，这一步保证召回的性价比；
- 把这十个片段连同调用链一起丢进长窗口，让模型在大约一千行的规模里做交叉比对，这是长上下文真正擅长的活儿，它能在同一次推理里同时看见 useEffect 和那个被遗漏的依赖；
- 最后要求它在三百字以内给出结论与改动点，防止它把检索到的原文重新复述一遍。