误区：把整个仓库直接丢进去
上下文窗口变大了，但「全量粘贴」通常不是最优解：无关文件会稀释重点，回答容易泛泛而谈，且成本更高。更稳妥的是先筛选，再分块，最后提问。
第一步：筛选（决定放什么）
优先放入：
- 入口文件与路由定义
- 你正在改动的模块及其直接依赖
- 相关的数据结构 / 类型定义
- 报错堆栈涉及的文件
明确排除：
- 构建产物、锁文件、依赖目录
- 与当前问题无关的页面与测试
- 大段静态资源或数据文件
第二步：分块（决定怎么放）
按「模块」而不是「文件大小」切分，每块保持语义完整：
以下为 A 模块代码，包含 xxx 与 yyy 两个文件。
[代码]
关键：给每块加一句说明，告诉模型这是什么、做什么用。有标注的上下文，回答准确率明显高于裸代码。
第三步：提问（决定问什么）
避免宽泛提问，改成带约束的任务式提问：
- ❌「这段代码有什么问题？」
- ✅「这个模块在并发调用时是否可能出现状态覆盖？如果有，指出具体行号和修改建议。」
推荐提问模板：
背景：[项目类型与目的]
目标：[我想达成什么]
约束：[不能改动的部分 / 性能要求 / 兼容性]
问题：[具体疑问]
让回答更可靠的三个习惯
- 要求给出依据：让它说明结论来自哪段代码，便于你核对
- 要求列出不确定项：明确问「哪些地方你没有把握」，比事后返工划算
- 小步验证：让它一次只改一个文件，验证通过再进行下一个
注意事项
- 涉及密钥、用户数据等敏感内容，粘贴前必须脱敏
- 模型给出的重构建议需要完整跑测试再合入
- 对性能相关的结论，用真实基准验证，不要只看推理
小结
长上下文的价值不在「能塞多少」，而在「是否能精准提供相关上下文」。筛得准、标得清、问得具体，回答质量会有明显差别。