先说结论：大型项目里，最浪费 Token 的往往不是“让 Codex 写了太多代码”，而是让它反复读取无关文件、重复理解项目架构、处理过长日志，以及一次承担过大的任务。省 Token 的核心是：固定长期规则，缩小每次上下文，按模块拆任务。

我自己在用 AI 辅助 Unity 和其他项目时，一个很明显的感受是：小项目里你可以直接说“帮我加个背包系统”，但项目一大，这种提示很容易把 Codex 变成“全仓考古”。它先找目录，再读几十个文件，再猜架构，最后真正需要修改的可能只有三四个脚本。

我们不讨论“某个模型固定能省多少百分比”，因为实际消耗会受到模型、任务复杂度、输入、缓存输入、输出、工具调用和 Fast 模式等因素影响。OpenAI 当前的 Codex 计费也已经更强调 token 类型，而不是简单按消息条数估算。本文只讲可以长期复用的工程方法。

图 1  大型项目中的上下文消耗来源（示意）

一、为什么大型项目特别容易“烧 Token”

Codex 并不是看到你的 Git 仓库就自动拥有完整的“项目理解”。每个任务仍然需要从指令、文件、检索结果、构建输出和历史上下文里重新组织信息。项目越大，如果边界越不清楚，越容易把大量无关内容送进上下文。

常见浪费点	表现	为什么费	更好的做法
每次重新介绍项目	提示词里反复贴架构说明	同一批规则反复进入上下文	固化到 AGENTS.md
直接让 AI 扫全仓	先遍历 Assets / src	检索结果和文件内容大量膨胀	明确目录、符号和依赖边界
任务跨度过大	“重构整个 UI 系统”	需要同时理解多个模块	按功能 / 调用链拆成小任务
日志全部粘贴	几千行构建日志直接输入	错误附近信息被噪音淹没	先过滤 error / warning / stack
同一会话无限续杯	一个线程做几十件事	历史上下文持续增长	一个目标一个线程，阶段完成后新开
重复试错	Codex 不知道验收标准	改完又返工，重复读取与生成	开工前写清“完成条件”

所以省 Token 的第一原则不是“提示词越短越好”，而是：该长期保存的信息不要重复说；该按需读取的信息不要提前全塞进去。

二、先把项目结构整理成“AI 能看懂的边界”

如果一个 Unity 项目把业务脚本、插件、素材、生成目录、测试代码全混在 Assets 下面，Codex 每次定位问题都要扩大搜索范围。反过来，目录本身就是最便宜的上下文：只看路径，AI 就能先判断“这个文件大概负责什么”。

我更推荐把自己的代码集中到一个清晰根目录，再按 Core / Features / Content 这样的职责拆分。第三方资源与项目代码分离，生成目录明确排除。

图 2  一个适合 AI 协作的 Unity 目录示例

Unity 项目可以这样约束 Codex

• 默认只修改 Assets/_Game 下的自有代码；ThirdParty、Plugins 除非任务明确要求，否则按只读处理。
• 不要扫描 Library、Temp、Logs、obj、Builds 等生成目录。它们文件多、噪音高，而且绝大多数时候不是问题源头。
• 每个 Feature 尽量自洽。例如背包相关脚本、配置和测试放在 Inventory 附近，不要散落在十几个目录。
• 公共能力放 Core，但不要让所有业务模块直接互相引用；依赖关系越清楚，Codex 需要追踪的调用链越短。

适用于其他技术栈：Python 可以按 package / domain 拆；Web 可以按 feature / page / component 拆；后端可以按 service / module 拆。核心不是目录名必须一样，而是让“当前任务的最小相关集合”容易被定位。

三、用 AGENTS.md 把重复提示词变成“项目配置”

OpenAI 官方把 AGENTS.md 定位为给 Codex 使用的项目说明文件。Codex 会在开始工作前读取它；可以有全局、仓库级和子目录级的指令，而且更靠近当前工作目录的规则可以覆盖上层规则。[1][2]

这正适合解决大型项目最典型的 Token 浪费：每次都要重新说“项目结构是什么、哪些目录不能动、怎么测试、改完要做什么”。

图 3  AGENTS.md 的分层思路

一个偏 Unity 的 AGENTS.md 模板

这里有两个细节很重要。第一，AGENTS.md 不要写成几十页的“公司制度”。官方也建议保持短、准、实用；文件太大时，把具体流程拆到其他 Markdown，再按需引用。[1] 第二，可以在某个 Feature 下再放局部 AGENTS.md，只描述这个模块特有的规则。这样背包任务不需要加载战斗系统的说明。

Codex CLI 还可以用 `/init` 生成一个起始版 AGENTS.md；复杂任务则可以先用 `/plan` 进入 Plan 模式，让它先收集上下文和形成方案，再真正改代码。[1]

四、任务越大，越要“先定位、再修改”

最费 Token 的提示通常长这样：“帮我把游戏的背包、装备、商店、存档都重构一下，顺便优化性能。” 这句话看起来省事，但对 Agent 来说意味着多个子系统、多个调用链、多个验收标准同时进入上下文。

更稳的方式是把一个大目标拆成可以独立验证的小阶段。OpenAI 官方也建议复杂、模糊或难描述的任务先 Plan，而不是直接进入实现。[1]

图 4  推荐的“定位—修改—验证”闭环

差的提示词 vs 更省上下文的提示词

不推荐	更推荐
把背包系统重构一下。	只处理 Assets/_Game/Features/Inventory。先定位 InventoryService、UI 刷新入口和存档接口，不要读取其他 Feature。先给出最多 5 个候选文件和改动计划。
修一下这个报错，我把完整日志贴给你。	先看下面 20 行核心错误和调用栈。优先定位首个项目代码栈帧；只有信息不足时再告诉我需要哪一段日志。
检查一下整个项目有没有性能问题。	先检查战斗场景中每帧 GC 分配。范围仅 Combat/ 与相关 UI。列出可复现证据后再决定是否扩大范围。
把 UI 框架优化到最好。	阶段 1 只梳理 UI 打开/关闭和生命周期；本轮不改视觉、不迁移 Prefab。先输出现状调用链与 3 个最高风险点。

这里真正起作用的不是“提示词更长”，而是它明确了范围、顺序和停止条件。Codex 不需要为了保险把整个项目都翻一遍。

我常用的“Token 友好型”任务模板

五、别把所有知识都塞进 Prompt：IDE 上下文和 Skills 要按需加载

如果你使用 Codex IDE 扩展，可以直接把当前打开文件、选中的代码或最近的对话加入 Composer。官方文档明确强调“使用已经打开的上下文”：这比你把整个文件复制到提示词里更自然，也更容易控制范围。[3]

另外，重复工作流不要一直复制长提示词。Codex Skills 可以把说明、脚本、参考资料封装成可复用能力，而且采用渐进式加载：初始只暴露技能名称和描述，真正命中后才读取完整 SKILL.md。OpenAI 文档还专门限制了初始 Skills 列表占用的上下文预算，以避免挤占主提示。[4]

信息类型	建议放哪里	原因
长期通用规则	~/.codex/AGENTS.md	所有项目复用，不必每次输入
项目架构 / 构建命令	仓库根 AGENTS.md	每个任务自动继承
某模块局部规则	模块目录 AGENTS.md	只在相关目录工作时加载
重复工作流	Skill	需要时再加载完整流程
当前具体代码	IDE 打开文件 / 选区	只提供当前任务上下文
一次性任务要求	当前 Prompt	只描述这一次的目标与验收标准

可以把它理解成“分级缓存”：长期知识放持久配置，模块知识靠目录分层，工作流放 Skill，只有当前问题才进入 Prompt。这样项目越大，收益越明显。

六、一套大型项目 Codex 使用习惯

1. 新项目先整理目录，不要一上来就让 Codex 写大量业务代码。目录边界本身就是上下文压缩。
2. 在仓库根目录维护一份短小的 AGENTS.md：项目地图、禁止目录、构建与测试命令、完成标准。
3. 复杂需求先 `/plan`。先让 Codex 说“准备读哪些文件、为什么”，再允许它实现。
4. 每次任务明确模块范围。能说“Inventory”就不要说“整个游戏系统”；能说具体符号就不要说整个目录。
5. 限制第一次检索规模。例如“先列最多 5 个最相关文件；不足再扩大”，而不是默认全仓扫描。
6. 日志先过滤。优先提供 error、stack trace、首个项目代码栈帧；完整日志保留在文件里，必要时再让 Codex查。
7. 改动和验证绑定。一次只做一个可测试目标，改完立即编译 / 测试 / review，不把十个需求堆到最后一起验。
8. 大阶段结束就形成 Git 检查点。下一阶段可以开新线程，用 Git diff / commit 代替超长历史对话。

开始任务前	执行过程中	结束任务时
□ 目标是否只有一个？	□ 首次只读最相关文件？	□ 是否跑了相关测试？
□ 范围目录是否明确？	□ 扩大搜索是否说明原因？	□ 是否检查了 diff？
□ 验收标准是否可验证？	□ 是否避免全量日志？	□ 是否记录剩余风险？
□ 是否应该先 Plan？	□ 是否出现无关重构？	□ 是否该开新线程进入下一阶段？

大型项目里，Codex 的效率很大程度上取决于你有没有把软件工程本身做清楚。模块边界清晰、规则可复用、任务可验证时，AI 不仅更省 Token，也更少出现“看了很多文件却改错地方”的情况。

所以我现在更倾向于把 Codex 当成一个会读仓库、会运行工具的工程师，而不是一个“输入一句话就自动完成整个项目”的代码生成器。你给它的不是越多越好，而应该是刚好足够完成当前任务的上下文。

参考资料（OpenAI 官方）

[1] Codex Best practices

[2] Custom instructions with AGENTS.md

[3] Codex IDE extension

[4] Build skills

[5] Codex rate card

说明：Codex 功能、模型和计费会继续更新，文中涉及当前产品行为的部分以 2026-08-12 官方文档为准。