长上下文仍需配合代码检索
AI 总结
一位实践者在亲历报告中称，将整个中型前端仓库放入1M token上下文后，模型仍调用了不存在的store方法，并做出了错误的修改。作者提出的混合流程是：先用向量检索将数百个候选文件缩减至约十个，再将相关片段和调用链放入长上下文进行跨文件比对。他还建议缩短系统提示词、建立可观测性以区分检索失败和模型忽略信息，并把关键工具说明放在提示词首尾。
深度见解
这则实践表明，更大的上下文窗口有助于比对经过筛选的代码，但本身不能解决检索、指令位置、指令遵循和修改正确性问题。报告将检索与长上下文复核视为互补步骤，而非彼此替代。
装得下不等于用得好
百万 token 上下文铺开的第一周，我做了一件很蠢的事：把一个中型前端仓库整包塞进去，让它读完再改。结果它非常自信地调用了一个不存在的 store 方法，还顺手修复了几处上一轮我自己写错的地方——修复的方向也是错的。
窗口从 32k 涨到 128k 再到 1m，很多团队把它当成再也不用做检索的理由。但上下文长度解决的是能塞多少，没有解决该看哪一段。这两个问题的难度完全不在一个量级。
我的混合方案：先检索压缩，再让长窗口交叉比对
现在的链路是三段：
- 向量检索把候选文件从几百个压到十个左右，这一步保证召回的性价比；
- 把这十个片段连同调用链一起丢进长窗口，让模型在大约一千行的规模里做交叉比对，这是长上下文真正擅长的活儿，它能在同一次推理里同时看见 useEffect 和那个被遗漏的依赖；
- 最后要求它在三百字以内给出结论与改动点，防止它把检索到的原文重新复述一遍。