上下文窗口从 3.2 万扩到 128 万、再到 100 万 token，真正解决的是“能放多少”，不是“该看哪里”；把整个代码仓库塞给模型，反而可能生成自信但错误的修改。

这是什么

上下文窗口是模型一次能够处理的文本容量。百万 token 听起来足以容纳大型项目，但容量扩大后，注意力分布、位置偏置和工具说明被忽略等问题仍然存在。文章采用的混合链路是：先用向量检索（按语义寻找相关内容的机制）把候选文件压缩到约十份，再将文件片段与调用链交给长窗口跨文件核对，最后把结论限制在 300 字以内。

更关键的调整发生在提示词上：系统指令从 1000 多字缩至不足 400 字，只保留任务边界、输出格式和禁止事项；示例移到最后一轮。核心并非提示词越长越好，而是关键要求要放在模型更容易注意到的首尾位置。

行业怎么看

长窗口正在从参数竞赛变成工程能力。Coze 与阿里云百炼的公开实践都把长上下文放在检索之后，用于二次精读，而不是取消检索。这说明百万级窗口更适合跨文件比较、复杂文档核对等需要整体阅读的任务。

风险也很明确：窗口越大，错误信息、过期资料和冲突指令被一并带入的概率越高；模型引用了错误方法时，甚至会掩盖原本的问题。因此团队需要先建立可观测性，区分“资料没有检索到”与“模型看到了却没有采用”，再决定是否扩大窗口。直接依赖长窗口，可能只是把一个可定位的问题变成更难排查的问题。

对普通人的影响

对企业 IT：采购模型时，窗口长度不应是唯一指标，检索质量、调用链完整度、指令遵循和过程日志更值得关注。企业也需警惕把敏感代码整库上传带来的合规风险。

对个人职场：使用代码助手或长文档分析工具时，清晰说明任务边界、禁止修改项和预期输出，比堆叠“仔细思考”式要求更有效。涉及采购或业务决策时，仍需核对原始资料。

对消费市场：能一次分析长文档、长对话和大型代码库，会提升智能助手在整理资料、比较方案上的实用性；但回答更流畅不等于更准确，检查关键结论仍是必要步骤。