为什么有些人用 Codex 越用越慢、额度越用越快？

一、为什么我开始认真管理 AI 的上下文？

我很早就开始使用大语言模型解决各种问题，尤其是编程和软件开发相关的问题。

最初，我和很多人一样，习惯在同一个 Session（会话）中不断提出问题、补充资料、修改要求，希望 AI 能够记住之前讨论过的所有内容，然后在这些信息的基础上继续完成任务。

但随着对话越来越长，我逐渐发现了一些现象。

即使最新的问题已经不需要之前的信息，AI 有时仍然会受到历史讨论的影响。

有些回答看起来很完整，却没有真正深入解决问题；有些回答过于顺着我的想法，缺乏必要的质疑；还有一些任务，明明已经明确提出了要求，最终输出却逐渐偏离了我的真实目标。

后来，我在使用 RAG（检索增强生成）技术，为企业开发 AI 知识库系统时，也遇到了类似的问题。

当时，我担心大模型遗漏重要信息，所以经常尽可能多地提供知识库检索结果和历史对话。

我原本以为，信息越充分，AI 就越容易准确回答用户的问题。

实际效果却并不总是如此。

例如，用户查询某款电子元器件的具体型号和详细参数时，模型有时不能准确定位所需的信息，需要用户反复追问。

对于设备 BOM 表中的元器件价格计算，模型也可能给出错误结果。

后来，我尝试提高知识库检索的准确度，只向模型提供与当前问题直接相关的信息，并明确规定信息处理方式。

我发现，针对一些信息检索和理解类任务，这种方法反而能够得到更准确、更深入的回答。

当然，BOM 金额计算还涉及另一个问题：确定性计算不应该完全依赖大语言模型。

对于这类任务，更可靠的方法是使用程序完成数据检索与计算，再由模型解释结果。

这段经历让我逐渐意识到：

大模型能够处理大量上下文，不等于我们应该在每次执行任务时，都把尽可能多的信息提供给它。

从那以后，我开始有意识地管理输入给 AI 的信息，并将这套方法逐渐应用到 ChatGPT、Codex，以及后续的 AI 产品开发中。

二、我理解的 Context Engineering：不是尽可能少，而是尽可能准确

为了理解这些现象，我阅读过一些介绍 Transformer 和大语言模型工作机制的开源资料，包括：

• yeasy/llm_internals
• amitshekhariitbhu/transformers-explained

这些资料帮助我理解了大模型的注意力机制、上下文处理方式及相关的工程实现。

结合实际使用经验，我逐渐形成了自己的 Context 管理原则。

1. 上下文的信息量，不等于有效信息量

假设我们需要让 Codex 修改一个应用中的登录功能。

我们可以提供整个项目的历史需求、架构文档、全部代码、过去几十轮开发对话，以及其他模块的设计说明。

这样做的好处是：模型可能获得更多项目背景。

但同时也会产生一些问题。

首先，大量信息中可能包含已经失效的需求和历史方案。

其次，与当前任务无关的内容可能增加模型定位关键信息的难度。

此外，较长的上下文还可能增加输入处理成本，并使模型需要处理更多潜在的信息冲突。

但这并不意味着上下文越短越好。

如果为了追求简短，删除了完成任务所必需的业务规则、技术约束和接口信息，同样可能导致错误。

因此，我更重视的是：

在保证必要信息完整的前提下，尽可能提高上下文中有效信息的比例。

我将其简单理解为：管理 Context 的信噪比。

2. Context Window、KV Cache 和我们的 Markdown 文件不是同一回事

这里有必要区分三个概念。

Context Window 是模型能够处理的上下文容量。

KV Cache 是 Transformer 推理过程中，用于缓存已处理 Token 的 Key、Value 表示的一种机制。

而我在项目中维护的 Markdown 文件，则属于应用层的上下文管理。

我们可以通过筛选文件、压缩信息和拆分任务，减少不必要的输入，但这不等于直接管理了模型内部的 KV Cache。

同样，减少上下文长度，也不代表模型一定能够进行更深入的推理。

我真正希望实现的是：让模型在执行当前任务时，更容易获得完整、准确、相关且没有明显冲突的信息。

这才是我后续整套工作方法的出发点。

三、我最早的实践：把 AI 的工作结果整理成可复用的 Markdown 文件

在开始使用 Codex 之前，我主要使用 ChatGPT 一类的对话工具完成技术研究、项目分析和文档整理。

那时，我逐渐形成了一个习惯：

完成一个阶段的讨论后，不继续在原来的会话中无限追加任务，而是将已经确定的结果整理出来，保存到独立的 Markdown 文件中。

例如，讨论一个 Spring Boot 项目的技术方案时，我可能会与 AI 进行多轮交流。

我们会讨论不同技术方案的优缺点、适用范围、依赖关系以及最终选择。

当决定采用某个方案后，我只会保留最终的技术选择、必要的设计规则和注意事项。

中间讨论过、但最终没有采用的方案，一般不会继续保存在供后续任务使用的上下文文件中。

对于 AI 已经掌握的通用知识，我也不会重复编写大段解释。

例如，没有必要在每个任务中重新介绍 Spring Boot 的 Controller 层是什么。

真正需要保存的是当前项目采用了什么架构、依赖什么外部库、有哪些特殊要求，以及哪些行为必须遵守。

1. 我如何组织这些文件？

最初，我会按照项目、领域和文件用途，将信息分门别类地保存。

例如：

project/
│
├── background/
│   ├── project-overview.md
│   └── business-context.md
│
├── workflows/
│   ├── development-process.md
│   └── incident-review-process.md
│
├── statistics/
│   ├── calculation-rules.md
│   └── reporting-rules.md
│
├── results/
│   ├── analysis-result.md
│   └── report.md
│
└── prompts/
    └── common-instructions.md

这是一个简化示例，不同项目会采用不同的目录结构。

其中，我特别重视两个原则。

第一，按照信息所属的领域进行分类。

相互关联的信息尽量放在一起，不同领域的信息尽量分开。

第二，区分背景信息、工作规则和最终结果。

例如，一份项目分析报告可以作为后续任务的参考，但它不应该自动变成整个项目的长期工作规则。

通过这样的分类，我们就能在执行不同任务时，只提供真正需要的文件。

2. 为什么我使用 Git 管理这些文件？

因为这些文件并不是一次性写完就不再变化的。

随着项目推进，我们可能发现新的业务规则、需要修改之前的设计，或者发现某份文档中存在错误。

我会让 AI 协助修改这些文件，然后通过 Git 检查具体发生了哪些变化。

例如：

• 是否增加了新的规则？
• 是否覆盖了原来仍然有效的信息？
• 是否保留了已经废弃的方案？
• 是否出现了重复描述或相互冲突的要求？

确认以后，再将修改提交到 Git。

这样，这些文档就逐渐从普通的讨论记录，变成了一个可以持续维护、按需提供给 AI 的项目上下文体系。

后来开始使用 Codex 时，我依然保留了这个习惯。

只是 Codex 可以直接读取和修改这些文件，不再需要每次都手工复制全部内容。

四、真正改变我使用 Codex 的，是把 Context 管理提前到软件架构设计阶段

随着使用经验增加，我发现，仅仅在每次调用 AI 之前精简文档，还不够。

一个更值得思考的问题是：

能不能从软件架构设计阶段，就降低未来每次开发任务所需要处理的上下文复杂度？

如果一个系统的业务逻辑高度耦合，修改一个功能就需要同时理解大量无关代码，那么无论我们怎样编写 Prompt，AI 都很难只处理一个局部问题。

相反，如果系统具有清晰的架构、明确的领域职责和稳定的公共接口，我们就更容易为每个任务划定范围。

这也是为什么我认为，在 AI 编程时代，软件架构能力依然非常重要。

甚至在我的实际开发过程中，它的重要性比以前更加明显。

1. 我采用的架构组织方式

在开发 The Inward Pioneer（静行者）桌面应用时，我采用了分层架构与领域划分相结合的方式。

首先，通过分层架构明确不同层次的技术职责和依赖方向。

其次，在业务模型层，根据实际业务能力进行领域划分。

我将这些领域进一步分成两类：

功能类领域： 负责提供相对独立的业务能力，例如登录与 Token 管理、对话管理、技能管理、音乐管理等。

业务流程聚合领域： 负责协调多个功能类领域，完成一个完整的业务流程，并向界面层提供相应的能力。

这里的“业务流程聚合领域”是我在项目中使用的架构术语。

从传统分层架构的角度看，它的部分职责更接近应用服务层中的业务编排。

例如，一个完整的聊天流程可能需要：

先检查用户登录状态，再调用对话领域的相关能力，根据需要使用技能领域，最后将结果返回给界面。

我不希望把这些逻辑重复写在每个界面组件中。

因此，会通过业务流程聚合领域，统一协调不同功能领域的能力。

同时，我会规定：

不同领域之间只能通过公开接口调用，不允许直接访问其他领域的内部实现，也不允许产生循环依赖。

这样，功能领域就可以像一个个相对独立的组件，被不同的业务流程组合使用。

2. 为什么这种架构有利于 Context 管理？

假设我们需要修改登录功能。

在架构清晰的情况下，我们通常能够快速判断：

当前任务属于哪个领域？

需要修改哪些模型和接口？

需要调用哪些底层能力？

是否会影响其他领域？

因此，我们可以将当前领域的架构规则、相关代码和具体需求提供给 Codex，而不必让它从整个项目中重新理解全部业务关系。

更重要的是，良好的模块化设计能够缩小很多日常改动的影响范围。

这不仅可以降低上下文组织的难度，也能够减少修改某个功能时意外影响无关功能的风险。

当然，复杂任务仍然可能需要跨领域修改。

但有了清晰的架构边界，我们至少能够明确这些修改应该发生在哪里，以及如何验证它们。

五、真实开发实践：我如何使用 ChatGPT 和 Codex 开发静行者

下面分享我在开发静行者 macOS 和 Windows 应用时使用的工作方法。

这不是一套要求所有项目照搬的固定流程，而是我根据实际项目特点逐渐形成的习惯。

第一步：先用 ChatGPT 解决通用技术问题

在开始编写项目代码之前，我会使用 ChatGPT 或其他大语言模型，讨论应用需要采用的技术栈、开发语言、框架、依赖库和相关技术问题。

这个阶段，我通常不会立即使用 Codex。

因为此时的主要目标是完成技术研究和方案选择，还没有进入实际代码开发。

当大部分问题已经讨论清楚以后，我会要求 AI 输出一份精简的技术方案总结。

只保留最终采用的技术、依赖、核心约束和必要的注意事项。

这份文件会成为后续开发使用的技术栈文档。

第二步：自己主导架构设计，明确 AI 必须遵守的边界

接下来，我会编写架构设计文档。

其中包括：

分层架构、各层职责、领域划分、领域间依赖关系、公共接口的设计原则，以及单元测试、集成测试和编译运行规范。

这个阶段，我会花比较多的精力。

因为我不希望后续每实现一个新功能，都需要重新讨论整个系统应该怎样设计。

同时，我不会事先规定所有实现细节。

架构文档只需要明确系统的整体结构、职责、边界和关键规则。

至于每个类具体如何实现、怎样组织内部方法，在满足约束的前提下，可以让 AI 根据实际代码和需求进行设计。

第三步：编写产品功能与概要业务流程

完成架构设计后，我会编写产品设计文档。

例如，静行者需要提供哪些功能，每个功能主要解决什么问题，以及核心业务流程是什么。

但在这个阶段，我不会把所有 UI 细节和具体操作过程都规定死。

因为在我的使用经验中，只要产品目标与架构边界足够清楚，AI 有时能够提出一些我之前没有想到的交互方式和界面设计。

我们可以先让 AI 在约束范围内生成方案，再根据实际体验修改。

第四步：让 Codex 搭建能够运行的项目框架

在准备好技术栈、架构和产品概要文档以后，我会使用高推理强度的 Codex 模型，完成项目初始化与整体框架搭建。

这个阶段，我要求 Codex：

按照已有文档创建项目结构、必要的类和接口、整套完整的 Demo 流程的实现、测试案例，以及编译和运行脚本。

对于尚未实现的业务，可以暂时使用 Stub（桩实现）返回测试数据。

但整个应用的基础界面和主要业务流程必须能够运行。

这样，我就能在真正开始详细开发之前，看到一个已经能够运行的应用框架，并验证重要的架构设计是否符合预期。

对于发现的小问题，我通常会使用较轻量的模型进行局部修正。

如果发现架构本身存在问题，则会先解决架构问题，而不是直接进入大量业务功能的开发。

第五步：让 AI 设计 UI，再逐步完善

项目框架能够正常运行以后，我会准备一份 UI 设计语言文档。

其中包括整体设计风格、视觉原则和需要遵守的约束。

随后开启一个新的 Session，让 Codex 根据已有界面、产品需求和设计语言进行 UI 设计。

这个阶段，我会根据实际效果进行多轮调整。

当设计基本确定以后，再把已经形成的颜色规范、动画效果和其他需要长期遵守的规则，整理回 UI 设计文档中。

这份文档就会成为后续 UI 开发任务可以复用的上下文。

第六步：按照领域和任务边界，逐个完成具体功能

完成整体框架以后，我通常会为不同的开发任务创建独立的 Session。

简单 Bug 修复可能只需要一段任务指令和几个相关代码文件。

复杂功能则可能需要额外提供产品详细设计、技术详细设计及相关架构文档。

如果需要跨领域完成一个完整功能，我也可能在同一个 Session 中使用更高推理强度的模型完成。

关键并不是强制规定一个 Session 只能修改一个领域。

而是：

根据任务的真实边界，决定需要提供哪些信息、涉及哪些领域，以及是否需要更高能力的模型。

六、具体案例：使用 Codex 实现登录与 Token 管理功能

为了让读者更容易理解这套方法，下面以静行者的登录与 Token 管理功能为例。

这是根据我的实际开发方法整理的简化教学示例，文件路径和 Prompt 并非历史会话的逐字记录。

1. 首先，项目已经有明确的领域定义

在架构文档中，我会提前定义登录与 Token 管理领域。

例如：

同时，架构文档已经规定了功能类领域与业务流程聚合领域之间的协作方式。

因此，在实现登录功能时，Codex 不需要重新决定登录业务应该放在哪里，也不需要重新设计整个应用的层次结构。

2. 我们的项目文档是如何组织的？

在实际开发过程中，我会将项目的核心上下文统一保存到 docs 目录下。

例如：

project/
│
├── docs/
│   ├── technical-stack.md
│   ├── architecture.md
│   ├── product.md
│   ├── ui-design.md
│   ├── team-collaboration-rules.md
│   │
│   ├── product-detailed-design/
│   │   ├── login.md
│   │   └── chat.md
│   │
│   └── technical-detailed-design/
│       ├── login.md
│       └── chat.md
│
├── src/
│   ├── storage/
│   ├── network/
│   ├── utils/
│   ├── model/
│   │   ├── authentication/
│   │   └── demo/
│   └── view/
│
└── tests/

其中：

technical-stack.md：记录项目采用的技术栈、开发语言、依赖库和相关技术约束。

architecture.md：定义整体架构、各层职责、领域划分、依赖关系及开发规范。

product.md：记录产品的主要功能及概要业务流程。

ui-design.md：记录已经确定的界面设计原则和规范。

team-collaboration-rules.md：记录团队共同遵守的开发和协作规则。

product-detailed-design/：由产品人员维护具体功能的行为、约束、错误处理及界面期望。

technical-detailed-design/：由技术人员维护具体功能的 API 调用流程、关键接口、实现约束及技术注意事项。

对于已经存在的功能，技术详细设计文件还可以提供相关代码的位置，方便 Codex 快速定位实现。

这些文件并不要求一次性全部完成，也不要求每个项目使用完全相同的结构。

但我认为，它们不应该仅仅被当成传统意义上的项目文档。

这些文档承载着团队已经确定的设计、规则和决策，是人类成员与 AI 共同工作的长期上下文。

它们可以被不同成员阅读、修改、审查和复用。

当团队成员开启新的 AI 会话时，也不需要重新解释此前已经达成的全部共识。

3. 开发登录功能时，我会提供哪些 Context？

假设项目架构已经完成，现在需要实现登录功能。

我会根据当前任务，选择必要的上下文。

例如：

至于音乐、冥想等其他领域的文档，当前任务不需要，就不必提供。

历史开发对话同样不需要全部输入。

如果 Codex 执行过程中确实需要其他代码，可以让它继续读取。

我的原则是让 AI 从最相关的信息开始，而不是禁止它获取完成任务所必需的其他信息。

4. 一个可以直接参考的 Codex Prompt

在我的实际使用过程中，有时会直接粘贴相关文档，有时则会提供完整路径，让 Codex 自己读取。

对于较复杂的任务，我通常会在 Session 开始时，先让 Codex 阅读必要的规则和文档，确认它理解了相关背景，再开始执行。

下面是一份经过简化的教学示例。

第一条指令：阅读并理解当前任务的上下文。

任务：实现登录与 Token 管理功能。

一、阅读上下文

先阅读以下文件：

1. docs/architecture.md
2. docs/product-detailed-design/login.md
3. docs/technical-detailed-design/login.md
4. docs/ui-design.md
5. src/model/authentication/ 目录下的现有代码
6. src/model/demo/ 目录下的现有代码

阅读完成后，简要输出：

1. 本次任务涉及的架构层及领域，
   以及需要遵守的关键约束和规则。

2. 当前登录领域已经具备哪些能力。

3. Demo 领域采用的技术实现方式，
   以及它如何组合不同领域的能力完成业务流程。

4. 本次任务需要新增或修改哪些功能。

不需要重复解释整个项目架构，
只输出与当前任务直接相关的结论。

此阶段先不要修改代码。

确认 Codex 已经理解相关上下文后，再让它执行任务。

第二条指令：实现功能并完成验证。

二、任务目标

基于现有项目：

按照
docs/technical-detailed-design/login.md
中的技术设计，

实现
docs/product-detailed-design/login.md
规定的登录与 Token 管理功能。

三、架构约束

严格遵守 docs/architecture.md
中已经确定的架构规则和领域边界。

四、执行要求

优先复用现有代码、模型、
技术栈和基础设施。

需要引入新的依赖，
或者更新现有依赖版本之前，
必须先向我确认。

只修改完成当前任务必要的代码。

不要为了实现当前功能，
重新设计整个项目架构。

五、验证要求

按照项目现有测试规范，
补充必要的测试案例。

运行相关测试，
确认功能符合要求。

执行现有编译脚本，
确认没有引入编译错误。

检查本次修改范围，
确认没有修改无关领域。

最后简要输出：

1. 实现了哪些功能。
2. 修改了哪些文件。
3. 测试及编译结果。
4. 是否存在尚未解决的问题。
5. 是否需要同步修改相关文档。

如果需要修改文档，
先向我确认，再执行。

需要说明的是，这份 Prompt 并不是每次都要完整使用。

如果只是修复一个简单的 Bug，我可能只会提供相关代码文件的路径，再说明需要修改的问题。

也不一定每个任务都需要让 Codex 阅读架构文档。

上下文应该根据任务需要选择，而不是把全部规则设置成每次都必须加载的固定模板。

这也是为什么我通常不会把所有项目文档都写入 AGENTS.md，要求每个任务自动加载。

我更习惯在需要的时候，明确指定当前任务应该阅读哪些文件。

5. 执行完成后，我如何验证结果？

在项目架构初始化阶段，我就已经要求 Codex 建立必要的测试规范、编译脚本和运行脚本。

因此，每次完成任务以后，都可以使用现有工具验证。

对于登录功能，我会检查登录成功、登录失败、退出登录、登录状态以及 Token 管理等相关行为。

同时运行单元测试和必要的集成测试，执行编译脚本。

对于能够通过界面直接验证的功能，我也会启动 App，检查实际运行效果。

此外，我会通过 Git Diff 检查此次修改涉及的文件和代码，确认没有意外改变其他领域的实现。

这里需要强调：

编译通过不代表业务逻辑一定正确，测试通过也不能替代必要的人工检查。

自动化测试、实际运行与代码审查，应该相互补充。

6. 完成以后，如何更新 Context？

假设登录功能按照既定架构顺利实现，并没有产生新的公共接口或架构规则，那么通常不需要重新修改整个架构文档。

但如果开发过程中，确定了新的领域职责、公共接口或长期适用的约束，就需要更新相关文档。

产品行为或流程发生变化时，也需要同步修改相应的产品设计文档。

对于架构文档，我只希望保留最终确定的设计、职责、边界和约束。

不需要记录每一步代码实现细节，也不需要保留中间讨论过但最终放弃的方案。

这样，下次有新的任务需要使用登录领域时，Codex 就可以通过相应文档快速理解当前已经确定的设计。

七、Context 管理不是只能处理小任务：一次跨领域重构的经历

前面的登录案例主要展示了日常功能开发。

但实际软件开发中，总会遇到需要修改多个模块、甚至调整原有架构的复杂任务。

对于这类任务，我不会机械地要求每个领域必须在不同的 Session 中修改。

如果多个领域之间存在明确的依赖关系，而当前任务的目标就是完成一次完整的跨领域调整，我反而可能使用一个 Session，让较高能力的模型集中完成。

关键是提前明确本次调整的范围、步骤和约束。

1. 我们曾经遇到过的实际问题

静行者最初的产品设计中，包含多个不同的东方哲学人物。

我们采用 Plugin 机制组织不同人物的功能。

当时，我们认为不同人物的技能可能影响聊天行为，因此在各个 Plugin 中分别放置了一些共用业务逻辑，包括聊天处理、语音发送与接收等。

后来，在实际开发过程中，我们发现这些共用逻辑的维护成本较高。

当聊天流程需要修改时，往往需要在多个 Plugin 中进行类似的调整。

这时，我们决定重新划分领域职责。

将各 Plugin 中重复的通用聊天和语音处理逻辑，逐步调整到共用的聊天领域中。

Plugin 则继续保留自身需要承担的特定职责。

2. 我如何让 Codex 完成这次重构？

这类任务与简单 Bug 修复不同。

我会提前编写一份相对详细的 Markdown 文档，说明这次重构的目标和约束。

例如：

哪些共用逻辑需要从 Plugin 中移出？

这些逻辑应该归入哪个领域？

哪些公开接口需要保持稳定？

不同领域之间应该如何调用？

哪些无关领域不允许修改？

对于具体的内部实现，我不一定会逐行规定。

因为 Codex 可以通过阅读现有代码，理解当前实现方式。

我更重视的是把重构目标、领域职责变化、依赖关系以及不能破坏的边界描述清楚。

随后，让 Codex 根据这份文档和相关代码完成重构，并通过现有测试验证结果。

当代码符合预期后，再同步更新架构文档。

3. 这个案例带给我的启发

Context Engineering 并不意味着每个任务都必须非常小，也不是所有任务都要使用轻量级模型。

对于真正需要跨领域修改的任务，应该提供足够完整的相关上下文。

但是，这仍然不意味着必须输入整个项目的全部资料。

我们真正需要提供的，是：

当前重构涉及的领域、相关代码、现有依赖关系、目标架构、修改边界以及验证要求。

这样的上下文既能够支持复杂任务，也能避免无关信息干扰当前工作。

八、如果 Codex 连续修复失败，我会重新整理问题，而不是无限延长对话

即使准备了比较完善的上下文，AI 仍然可能出现错误。

例如，Codex 修改代码后，编译失败，或者实际运行结果与预期不符。

对于第一次出现的问题，我通常会直接在当前 Session 中要求它修复。

但如果连续几次修改都没有解决问题，或者当前会话已经发生了上下文压缩，我就会考虑重新开始。

这时，我不会简单地把旧会话全部复制到新的会话中。

而是创建一份新的 Markdown 文件，整理当前问题。

文件一般包含：

# 当前问题

## 1. 错误现象

描述实际发生了什么。

## 2. 预期结果

说明正确行为应该是什么。

## 3. 复现步骤

列出可以稳定复现问题的操作。

## 4. 最近一次错误信息

保留实际报错、日志或测试失败信息。

## 5. 已尝试但无效的方案

简要列出之前尝试过的修改。

## 6. 可能的原因

记录当前怀疑的方向，并明确这些只是待验证的假设。

## 7. 相关文件

列出当前问题涉及的代码文件或目录。

随后开启新的 Session，让 Codex 基于这些信息重新分析问题。

对于复杂问题，我可能会选择更高推理强度的模型。

对于能够安全撤销的错误修改，也可以先通过 Git 回到已确认的稳定状态，再重新处理。

需要注意，已经尝试过但无效的方案并不是完全没有价值。

它们可以帮助 AI 排除部分重复尝试。

但我只会保留必要的失败记录，而不是把此前所有分析、猜测和修改过程原样输入新会话。

我的目标是保留已经确认的事实，同时避免旧会话中未经验证的推测继续主导新的分析。

九、这套方法能够减少 Codex 的额度消耗吗？

在我的实际开发过程中，我确实观察到了一些变化。

当架构、领域职责和上下文文档比较清晰时，很多日常功能开发和 Bug 修复任务，不需要每次都使用最高推理强度的模型。

我可以根据任务复杂度选择不同的模型。

简单任务使用较轻量的模型；涉及整体架构、大范围重构或复杂问题分析时，再使用更高能力的模型。

同时，由于每次开发任务都有明确的范围，也不需要反复要求 AI 重新理解整个项目。

在开发静行者的过程中，我发现，大部分日常任务都能够使用这种方式完成，Codex 的使用额度通常也足够支持我的开发工作。

但这里有一个重要前提：

这只是我的实际使用经验，而不是经过严格对照实验得出的普遍结论。

Codex 的额度消耗还与模型选择、任务复杂度、执行过程和工具调用等因素有关。

精简上下文不一定能保证每次任务都消耗更少额度。

例如，新 Session 可能需要重新读取代码和建立上下文。

而如果某个任务本身需要复杂推理或大量修改，仅仅缩短 Prompt 也不一定能够降低执行成本。

因此，我不会把自己的方法总结为“上下文越少，额度消耗越低”。

我更愿意将其理解为：

通过合理的架构设计和上下文组织，让更多任务能够在明确的边界内完成，并根据实际任务需要选择合适的模型。

十、这套方法同样适用于非开发人员

前面用了大量软件开发案例，但这套方法并不局限于编程。

例如，一个团队使用 ChatGPT 完成产品策划、市场分析和运营工作，也可以采用类似的组织方式。

将信息分为：

项目背景、产品规则、业务流程、数据统计口径、原始数据、历史分析结果和常用指令等不同类别。

其中，数据统计口径应该由团队统一维护，避免不同成员在不同 AI 会话中使用不一致的计算规则。

产品需求发生变化后，及时更新产品文档，而不是让每位成员继续引用过去的讨论记录。

在分析某项运营数据时，只提供当前分析需要的数据、统计规则和相关背景。

不需要把全部产品历史、无关业务数据和所有过去的分析报告一起输入。

这样，我们就能把软件架构中的分层、模块化、高内聚和低耦合等思想，应用到日常知识工作中。

这里的“领域”不一定是软件模块，也可以是一个独立的业务流程、工作职责或知识主题。

核心并不是使用某种固定的目录结构，而是让不同信息拥有清晰的职责和边界，使它们能够被独立维护，并在需要的时候重新组合。

对于已有的大型旧项目，也不一定需要推倒重来。

可以从当前最常使用的业务领域开始，与 AI 一起整理相关背景、工作规则和历史决策，逐步建立可复用的上下文体系。

十一、写在最后：AI 编程时代，人更应该重视架构和判断能力

回顾我使用 ChatGPT 和 Codex 的经历，我认为最值得分享的并不是某条特别有效的 Prompt。

而是一套逐渐形成的工作习惯。

首先，尽量把项目划分为职责清晰的层次和领域，使相关信息能够聚合在一起，不同领域之间能够通过明确的接口协作。

其次，把已经确定的背景、规则、设计和结果整理成简洁、准确、可以长期维护的文档。

执行任务时，根据实际需要选择上下文，而不是把所有资料一次性提供给 AI。

最后，在正式进行大量开发之前，认真完成必要的架构设计和规则制定，并通过测试、代码审查和实际运行验证结果。

在实际工作中，我越来越觉得：

AI 可以帮助我们更快地编写代码，但一个项目应该怎样划分、哪些信息值得长期保存、什么样的结果真正符合需求，仍然需要人来判断。

Context Engineering 也不只是一套减少 Token 消耗的技巧。

它实际上涉及信息组织、知识管理、架构设计、任务规划和结果验证。

随着 AI 工具逐渐具备更强的长上下文处理、自动压缩和自主执行能力，这些机制能够帮助我们完成更多复杂任务。

但对我来说，主动管理项目中的关键知识和决策，依然有着独立的价值。

因为这些信息不仅服务于当前使用的某个模型，也服务于整个团队，以及未来可能使用的其他 AI 工具。

我希望建立的，不是一个必须依赖某个漫长 AI 会话才能继续工作的项目，而是一个即使关闭当前会话，换一个人、换一个模型，也能够根据现有文档和代码继续推进的项目。

这也是我在 AI Pioneer 开发静行者等产品的过程中，一直尝试实践的工作方式。

关于 AI Pioneer 与 The Inward Pioneer

AI Pioneer（智驱者科技）是一家致力于将 AI 与东方智慧结合的科技公司。

我们开发的 The Inward Pioneer（静行者），是一款以道家哲学为思想内核的 AI 桌面陪伴应用，支持 macOS 和 Windows。

它并不试图成为一个回答所有问题的通用 AI 助手，而是希望在用户面对工作、关系和日常生活中的困惑时，通过对话提供不同的观察视角，帮助用户重新看清自己的处境，形成属于自己的判断。

这篇文章中介绍的 Context 管理与 AI 编程方法，来自我们开发实际产品过程中的技术实践。

产品官网： https://www.smartpioneer.com.cn/