窗口不是越多越好 · 用法决定效果
窗口变大了，问题也变了
如何在 1M+ 里高效 coding
把整个代码库扔进去往往适得其反。学会选择性加载、缓存断点、结构化索引，才能把大窗口变成真正优势。
大窗口的真实代价与收益
更大上下文带来更高成本和更低信噪比。有效利用率往往只有 10-30%。关键不是塞更多，而是让模型每次只看到它真正需要的精确信息。
分段与子任务策略
将长任务拆分为小步骤，每一步只提供必要上下文。比一次性塞满整个代码库更精确、更可靠。
实践示例
重构时先缓存架构概览，再添加要修改的文件。显式排除无关文件，避免噪声干扰模型。
高效缓存前缀设计
把系统提示、核心架构描述、常用工具定义做成稳定前缀。长会话中这些部分命中缓存可节省 70-90% 输入成本。
选择性上下文加载
优先使用 repo map + 相关文件子集 + 显式缓存前缀。干净上下文中模型推理效果更好。
成本对比与实测
对比全上下文、选择性、加缓存三种方式的 token 量和费用。在 QCode dashboard 观察实际消耗并快速调整策略。
何时用检索代替塞满窗口
不要把一切都塞进窗口。考虑用搜索或 MCP 工具获取所需信息，还能缓解上下文中间召回退化问题。
QCode 上的长上下文实践
通过同一个 Key 访问支持大窗口的模型，在 dashboard 观察实际 token 消耗，快速迭代你的 context 策略。
长上下文 FAQ
要把整个 repo 都放进去吗？
不要。优先用 repo map + 相关文件子集 + 显式缓存前缀。模型更擅长在干净上下文中推理。
缓存前缀怎么设计最有效？
把系统提示、核心架构描述、常用工具定义做成稳定前缀。长会话中这些部分命中缓存可省 70-90% 输入成本。
中途切换模型会丢上下文吗？
客户端负责维护消息历史。切换模型时历史会保留，但新模型对之前 token 的「理解」可能不同，必要时做摘要压缩。
QCode 有什么特别的帮助？
统一 Key 下可同时使用不同窗口大小的模型，dashboard 按模型拆分用量，便于对比策略效果。