第一步：把上下文窗口理解为本轮工作台
上下文窗口不是模型永久记住多少东西，而是一次请求能够容纳的信息范围。输入与输出通常共同占用窗口，部分模型的推理内容也会占用预算。因此，窗口很大，并不代表可以生成同样长度的答案；最大输出长度还要单独查看。([developers.openai.com](https://developers.openai.com/api/docs/guides/conversation-state?utm_source=openai))
窗口使用词元计量，而不是直接按字数或文件数量计算。中文、代码、标点的切分方式不同，不宜把一个汉字固定当作一个词元。准备项目资料时，应使用对应模型的计数工具核算。([help.openai.com](https://help.openai.com/en/articles/4936856-understanding-and-counting-tokens?utm_source=openai))
下面以代码修复和企业文档问答两类项目演示操作。所有容量数字都是预算示例，不代表某款模型的规格，也不是客户实测结果。
第二步：先列出代码修复任务的全部输入
假设你要修复电商项目中的重复扣款问题。不要立刻上传整个仓库，先列出完成判断所需的材料：支付入口、订单状态流转、重试逻辑、相关测试，以及能够复现问题的日志。
清单还必须包含系统指令、工具定义、历史对话与工具返回内容；上下文并不只有你刚刚粘贴的代码。工具不断追加结果时，可用空间也会随之变化。([anthropic.com](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents?utm_source=openai))
- 保留：支付调用链、幂等规则、失败请求与测试断言。
- 暂缓：无关页面、构建产物、重复日志与整份依赖目录。
- 补充：允许修改的范围，以及修复后必须通过的验收条件。
筛选标准是能否影响本次判断，而不是文件是否属于同一个项目。把材料清单写下来，也方便下一轮发现遗漏时定向补充。
第三步：用一张容量账单判断窗口是否够用
假设候选窗口为三万二千词元：固定指令与工具说明占三千，代码和日志占一万七千，计划为答案预留四千，则还剩八千。这八千可以作为追加测试结果和后续交互的余量，但不是所有任务都适用的固定比例。
如果把全仓库放入后超过预算，先沿支付调用链缩小范围。若相关模块确实无法拆开，再考虑更大的窗口。不要为了装下资料，直接取消答案预留，否则可能容得下问题，却留不出完整修复说明。
实际发送前，还应核对所选模型的窗口、最大输出及接口限制。容量账单用于规划，接口返回的实际用量用于校正。
第四步：让文档问答先找证据再组织答案
第二个场景是员工制度问答。用户询问异地出差报销，不必每次提交整个人事资料库。可以先检索差旅标准、审批要求与地区补充条款，再把相关段落连同文档名称、版本和生效日期交给模型。
这属于按需加载上下文：保留查找资料的线索，需要时再读取正文，而不是预先塞入全部内容。上下文工程的目标，是组织足够完成任务的高相关信息。([anthropic.com](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents?utm_source=openai))
但如果任务改成比较新版与旧版制度的全部变化，就不能只挑几个命中段落。此时应按章节配对比较，记录每章差异，再合并结果；确实需要全文互相参照时，才评估更大窗口。
第五步：用项目验收检验窗口是否真正有效
资料装得下，不等于模型能可靠利用每一处信息。随着上下文增加，信息提取可能受到影响，因此不能只根据标称容量判断任务表现。([anthropic.com](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents?_bhlid=1ba3bf95247bd689b5d1b76ed18f996f167a8d63&utm_source=openai))
代码修复项目可以检查：是否找到重复扣款路径、是否保留正常支付流程、是否补上幂等测试。制度问答可以检查：是否引用现行条款、是否区分地区例外、是否在缺少证据时明确说明。
建议固定问题与验收标准，分别尝试精简资料和完整相关资料，记录遗漏、错误引用与人工补充次数。如果扩大窗口没有改善关键结果，就回头调整材料组织，而不是继续堆文件。
第六步：把窗口选择变成可重复的调用流程
落地时，为每类任务保存材料清单、输入预算、输出预留和验收条件。每轮结束后，记录已确认事实、修改文件、未解决问题与证据位置；换一轮任务时，重新选择需要携带的内容。
需要比较不同模型时，可以通过 SwiftRelay 按实际词元用量付费，在同一套项目样本上核对结果与支出。接入渠道并不替代模型本身的容量限制，选择前仍要确认对应模型和工具配置。
注册 SwiftRelay，即可使用新账户赠送的小额额度，从一个范围明确的项目任务开始验证。
先算清需要什么，再决定窗口多大。对代码修复，围绕调用链收集证据；对文档问答，围绕问题与版本组织材料。让窗口服务于任务，而不是让任务迁就窗口。