你是否遇到过这种情况:让 Codex 帮你修改一个函数,结果它却把整个文件重写了一遍?或者让它理解你的项目结构,它却对着一堆无关文件"分析"了半天,最后给出一个完全不沾边的回答?
这些问题的根源,几乎都指向同一个元凶——上下文失控。
Codex 的工作机制决定了,它"看到"什么,就会"生成"什么。输入给 AI 的上下文越精准,生成的代码质量就越高;反过来,如果上下文里塞满了噪音,AI 就会在噪音的基础上"胡思乱想"。
本文从实战出发,深入讲解 Codex 的上下文管理机制,并介绍一整套 Token 优化的策略与技巧,帮助你让 Codex 在关键场景下"一击即中"。
Codex 在每次请求时,会将以下内容组装成上下文发送给模型:
┌─────────────────────────────────────────────┐ │ 1. 系统指令(AGENTS.md / CODE.md) │ │ 2. 项目目录结构概览 │ │ 3. 当前打开/关联文件的内容 │ │ 4. 对话历史记录 │ │ 5. 当前用户输入 │ └─────────────────────────────────────────────┘
每一个环节都会消耗 Token。以 GPT-4o 为例,它的上下文窗口是 128K Token——听起来很大,但在实际项目中,几个中等大小的源文件就能轻松吃掉数万 Token,再加上 AGENTS.md 的指令、项目文件树的索引和对话历史,窗口很快就捉襟见肘。
当上下文接近或超过模型窗口上限时,Codex 会启动上下文裁剪机制:较早的信息会被丢弃,AI 的行为开始变得不稳定——这被称为"上下文遗忘",具体表现为:
.codexignore 是 Codex 提供的第一道防线,用法和 .gitignore 几乎一模一样。放在项目根目录下,Codex 在构建项目视图时会自动排除匹配的文件和目录。
# 在项目根目录创建 .codexignore
常见的配置示例:
# 排除构建产物 dist/ build/ .next/ node_modules/ # 排除大型数据文件 *.csv *.jsonl *.parquet *.bin # 排除第三方依赖(通常只需索引而非阅读) vendor/ bower_components/ # 排除编译后的 JS *.min.js *.bundle.js # 排除自动生成的代码 *.pb.go *.graphql.ts generated/ # 排除二进制资源 *.png *.jpg *.svg *.mp4 *.zip
实战建议:不要一次性屏蔽所有第三方库。比如在调试某个依赖包的行为时,你可能需要保留 node_modules/ 中的特定包让 Codex 阅读。此时可以这样写:
# 屏蔽所有 node_modules node_modules/* # 但保留需要调试的特定包 !node_modules/@tanstack/react-query/
这样既控制了整体上下文大小,又在需要时保留了针对性访问。
AGENTS.md 是 Codex 最核心的项目级配置,它会被注入到每一次对话中。这意味着你在 AGENTS.md 里写的每一个字,都在持续消耗 Token 预算。
常见的 AGENTS.md 膨胀问题:
<!-- 反模式:过于冗长 --> # 项目说明 这是一个使用 React 18 构建的前端项目,我们使用了 TypeScript... (500 字项目背景介绍) # 编码规范 - 用 const 而不是 let - 优先使用箭头函数 - 组件命名用 PascalCase (300 字规范列表) # 依赖说明 本项目使用以下依赖... (400 字依赖清单,而 package.json 完全可以提供这些信息)
精简后的版本:
# 关键约定 - 所有组件用 TypeScript,严格模式 - 样式方案:Tailwind CSS + classnames - API 调用:统一用 src/api/client.ts 的 http 实例 - 状态管理:React Context + useReducer,禁止引入 Redux - 测试框架:Vitest + @testing-library/react # 快速参考 - API 基础路径:/api/v1 - 开发服务器:npm run dev(端口 3000)
精简原则:Codex 已经从 package.json、tsconfig.json 等文件中知道了项目的技术栈,你只需要告诉它例外情况和特殊约定。
随着对话轮次的增加,历史消息会占据越来越多的上下文空间。以下是一些实战技巧:
当你发现以下现象时,说明会话已经到了该重置的时候:
/clear 或开启新会话Codex 提供会话重置命令,执行后历史上下文被清空,AI 重新以 AGENTS.md 和当前文件为起点。
# 在 Codex 交互界面中 /clear
或者直接 Ctrl+C 退出,重新启动一个新的 Codex 会话。
不要把一整个大型任务塞进一次对话。将任务拆分为多个独立的短期会话:
会话 1:设计数据模型 → 完成 会话 2:实现 API 接口 → 完成 会话 3:编写前端组件 → 完成 会话 4:端到端联调 → 完成
每个会话只专注于一个明确的子目标,上下文利用率最高。
Codex 默认会根据你的当前工作目录和打开的文件自动收集上下文。掌握以下技巧可以显著提高命中率:
@ 文件引用在对话中显式引用文件,让 Codex 聚焦于你真正关心的代码:
# 只关注特定文件 @src/services/auth.ts 请帮我检查这个文件中的安全漏洞 # 引用多个关联文件 请参考 @src/types/user.ts 的类型定义,在 @src/api/user.ts 中实现 CRUD 接口
在 Codex 中 cd 到你关心的子目录,Codex 会自动将该目录作为上下文锚点:
cd src/modules/payment # 现在 Codex 的项目视图聚焦在支付模块,排除了其他无关模块
# 先让 Codex 帮你找到相关文件 rg "PaymentService" --files-with-matches # 然后用上面的结果引导 Codex 聚焦 请分析这些文件中 PaymentService 的调用链:@src/modules/payment/service.ts
对于重度用户,建议在 AGENTS.md 中加入 Token 预算相关的元指令:
# Token 管理 - 在执行大型任务前,先报告预计需要修改的文件数量和范围 - 如果发现上下文冗长,主动提示用户是否需要开启新会话 - 代码生成尽量简洁,避免不必要的解释性注释 - 输出 Token 超过 2000 时,考虑拆分输出
假设你有一个包含 200+ 组件的 React 项目,在某次重构中需要修改认证相关的 6 个文件:
优化前(上下文浪费严重):
优化后:
精简 AGENTS.md 到 300 字
在 .codexignore 中排除 node_modules/、dist/、*.snap
用 /clear 开启新会话
cd src/modules/auth 缩小上下文范围
使用 @ 显式指定需要修改的 6 个文件
# 实际操作序列 /clear cd src/modules/auth 请统一将以下文件中的 fetch 调用替换为 apiClient: @src/modules/auth/LoginForm.tsx @src/modules/auth/RegisterForm.tsx @src/modules/auth/AuthProvider.tsx @src/modules/auth/useAuth.ts @src/modules/auth/authService.ts @src/modules/auth/tokenManager.ts
结果:Codex 的回复准确率从约 70% 提升到接近 95%,且生成速度快了 2-3 倍。
上下文管理是使用 Codex 这类 AI 编程助手的核心能力,它不是锦上添花的优化,而是决定 AI 编码质量的关键变量。掌握以下五个策略,你就能从"碰运气式"的 AI 交互中解脱出来:
| 策略 | 核心动作 | 收益 |
|------|---------|------|
| .codexignore | 过滤噪音文件 | 减少无关上下文 40-60% |
| 精简 AGENTS.md | 只写必要指令 | 每次请求节省数百 Token |
| 会话管理 | 及时重置/分段任务 | 避免上下文遗忘 |
| 精准文件引用 | 使用 @ 和 cd | 命中率提升 20-35% |
| Token 监控 | 设置输出约束 | 控制交互成本与质量 |
工具再好,也需要正确的使用方法。把上下文管理融入你的日常开发习惯,Codex 才能真正成为你手中精准高效的手术刀,而不是一把到处乱砍的大斧头。