4 个必须学习的 GPT-6 核心技巧：让你把 Codex 发挥到极致
整理 GPT-6 与 Codex 的四个核心技巧：上下文管理与缓存、模型选择与推理强度、Prompt 与 AGENTS.md 和 Skills 指令收敛，以及 Agent 工作模式，帮助你更高效地使用 Codex。
GPT-6 的技术变化
由于 GPT-6 的底层架构、推理引擎以及机制发生了重大变化，许多在 GPT-5.6 之前的惯用方法、Prompt 技巧与工程配置，在 GPT-6 时代可能已失效甚至沦为错误。
| Short context | Long context | |||||||
|---|---|---|---|---|---|---|---|---|
| Model | Input | Cached input | Cache writes | Output | Input | Cached input | Cache writes | Output |
| gpt-6-astra | $10.00 | $1.00 | $12.50 | $50.00 | $20.00 | $2.00 | $25.00 | $75.00 |
| gpt-6.1-sol | $2.00 | $0.10 | $2.50 | $10.00 | $4.00 | $0.20 | $5.00 | $15.00 |
| gpt-6-luna | $0.10 | $0.01 | $0.125 | $0.50 | $0.20 | $0.02 | $0.25 | $0.75 |
上下文管理与缓存
Codex Chat 的最佳生命周期：handoff, compact, side, fork
上下文窗口与舒适区
GPT 已经有 1M 上下文，同时 GPT-6 Astra 官方长上下文测试（OpenAI 自研测试：在超长文本里，区分并精准找回 8 段高度相似的目标信息）里：256K–512K 的 MRCR v2 8-needle：100%； 512K–1M：96.3%。
但是：“能从 800K context 里准确找到 8 个信息” 和 “经过 800K token 的 Coding Agent 轨迹以后，仍然保持和最开始一样清晰的工程判断” 不是同一件事情。
1M Context Window 是容量上限，不应该被理解成推荐工作集大小。 GPT-6 API 请求超过 272K 输入 Token 后，会进入 Long Context 计费：整笔请求的输入与缓存相关价格按 2 倍计，输出按 1.5 倍计。
Matt Pocock（mattpocock/skills 作者，大名鼎鼎的 grill-me skill）的观点：
- 模型能力越强，一个错误的决策造成的破坏速度也越快。 GPT-6 既能把正确决策放大，也能把错误决策放大。
- 给 Agent 的 context 越多，Agent 的表现通常会越来越差。
- 当前 Frontier Model 的 Smart Zone，他估计大约是最开始的 150K token。(主持人这个时候有追问：Of a 1 million token window? Matt回答：Yes)
Codex Chat 的最佳生命周期, compact, side, fork
OpenAI 给出的实际顺序非常明确：check status → 目标相同则 compact → 目标分叉则 fork。 https://developers.openai.com/blog/mastering-codex-remote-for-engineering
还是同一个核心工作目标？
│
├─ 是，Context 健康 → 继续当前 Chat
├─ 是，但 Context 已经很长 → /compact
├─ 只是旁支问题，不想污染主任务 → /side
├─ 要探索另一条主要路线 → /fork
└─ 已经是新的独立工作单元 → /new / 新 Chat - 同时考虑做HandOffhandoff
最可靠的方案是：当前执行状态单独写一个短的 HANDOFF.md；新会话先读取 handoff，再对照 Git/实际文件进行校验。
| 方式 | 是否继承旧聊天历史 | 是否得到真正干净的新上下文 | 适合场景 |
|---|---|---|---|
| Resume / Continue | 是 | 否 | 临时退出后继续同一个会话 |
| Fork / Branch | 是 | 否 | 从旧会话分叉尝试另一条路线 |
| Compact | 压缩后的历史 | 否 | 同一任务继续做，但上下文快满了 |
| Handoff → New Session | 否，只带交接状态 | 是 | 长项目、阶段切换、模型切换、上下文变脏 |
推荐使用 Matt 的 HandOff Skill。
他的 handoff Skill 定义其实只有十几行，理念非常干净：
把当前 conversation 压缩成 handoff document，让另一个 fresh agent 接手。
而且特别强调：
已经存在于 spec、plan、ADR、issue、commit、diff 里的内容不要重复复制，直接引用它们的位置。
模型和思考等级切换，缓存命中
- GPT-5.6 sol，中途修改思考强度，会导致缓存未命中。(https://github.com/openai/codex/issues/35416)
- GPT-6.1 sol，中途修改思考强度，会保留缓存，不会丢失。（Change reasoning mid-conversation while preserving cache）
- 无论 5.6 还是 6.1，中途切换模型必定导致性能下降和缓存丢失。 https://openai.com/zh-Hans-CN/index/unrolling-the-codex-agent-loop/ https://developers.openai.com/api/docs/guides/prompt-caching/diagnostics https://github.com/openai/codex/blob/main/codex-rs/core/src/session/mod.rs
所以，绝不是：
同一个 Codex 对话
Astra → 写架构
↓
切 Luna → 写文档
↓
切 Astra → Debug
↓
切 Luna → 改 README而是主 Agent 保持不变，使用 SubAgent 做任务路由。
Main Agent 模型保持不变
│
┌──────────┴──────────┐
│ │
Astra subagent Luna subagent
复杂代码/架构 文档/扫描/整理跨上下文窗口的结构化笔记保存：experimental context management
开启实验性上下文管理。它不会只是反复把上下文压缩成一个 summary，而是利用 notes 和可搜索的历史记录来保留累积的信息。
当前状态：
- 面向 Codex；
- 最初主要针对 GPT-6 Astra；
- 需要使用 ChatGPT Plus / Pro 登录 Codex，而不是 API Key；
- Astra 可以在不同 context window 之间保留 notes；
- 可以搜索同一个 task 中更早的 messages 和 tool results；
- 默认关闭；
- 修改配置以后需要 start a new task 才生效。
在 config.toml 中添加参数：
[features.context_management]
experimental_mode = true但：当前此功能临时关闭（https://github.com/openai/codex/issues/44873），属于还在实验阶段的功能。
模型选择、推理强度与资源分配
Astra、Sol、Luna 的选择
Luna 负责大量明确任务，Sol 负责日常主力工作，Astra 留给真正困难或高价值任务。 推理强度：日常任务从 Light/Medium 起步，复杂任务通常 High 即可满足，避免起手设置 Extra High 或 Max。
| 模型 | 适合场景 | Standard 输入 / 输出 |
|---|---|---|
| GPT-6 Luna | 清晰、重复、高频、成本敏感任务 | $0.10 / $0.50 |
| GPT-6.1 Sol | 日常 Coding、Research、需要判断力的 Agent Workflow | $2 / $10 |
| GPT-6 Astra | 最高难度、多步骤、跨工具、高歧义、高价值任务 | $10 / $50 每百万 Token |
ChatGPT 集成到 Codex
三个层级：
1. 使用 @ 引入 ChatGPT Web 聊天内容
自己去 ChatGPT Web 进行讨论，制定项目的分析和规划，然后回到 Codex 的 AI 对话框中，使用 @ 符号引入 GPT Web 的聊天记录，让 Codex 读取其中的内容，并执行任务。 这种方式最安全稳定，是官方提供的功能。
2. GPT 做项目分析，Codex 做实施
GitHub 项目：XiaoDuoYa/codex-with-chatgpt，目前约 6.8k Star。 核心理念：
- ChatGPT thinks. Codex works.
- ChatGPT Web 可以读取本地项目，但不能直接修改本地项目。
- 本质是操作 Codex 内置浏览器，通过 MCP 的方式让 ChatGPT Web 读取本地项目文件。
flowchart LR
U[用户] --> C[Codex]
C -->|调用 Skill| S[codex-with-chatgpt Skill]
S -->|控制内置浏览器| B[Codex 内置浏览器]
B <--> |网页对话| G[ChatGPT Web]
G <--> |MCP<br/>读取代码 / Diff / 测试结果| M[C2C Bridge<br/>本地 MCP Server]
M <--> |只读| W[本地项目]
C <--> |修改文件 / Shell / Git / 测试| W3. ChatGPT Web 直接操作本地文件，极度激进
GitHub 项目：miuuyy/codex-chatgpt-web，目前约 11.6k Star。
ChatGPT Web 获得了调用当前 Codex Harness 工具的能力。
flowchart LR
U[用户] --> C[Codex]
C -->|选择 GPT Web 模型| R[本地 Launcher / Bridge]
R -->|浏览器自动化| B[项目自带浏览器]
B <--> |直接操作网页| G[ChatGPT Web]
G -->|需要调用工具时| M[MCP Connector]
M --> T[本地 MCP Server]
T <--> |文件 / Terminal / Codex 工具| C风险
OpenAI 当前个人版 Terms of Use（2026-01-01 生效）明确写着，不允许：Automatically or programmatically extract data or Output. 并且禁止：circumvent any rate limits or restrictions.
所以：官方 Codex 能控制 Browser ≠ OpenAI 官方认可“使用 Browser 自动调用 ChatGPT Web 作为模型 API”。
（codex-chatgpt-web 仓库中已经有 issue，出现风险案例。）
同类项目：webcodex
所以：推荐大多数普通用户使用第一种方式。
指令收敛：Prompts, AGENTS.md, Skills
GPT-6 Astra 的一个直接结果是：过去为了较弱模型积累的大量框架、引导和防御性指令，可能不再有帮助，甚至会限制模型。OpenAI 在专门针对 Astra 的官方文章中，明确要求重新审视任务 Prompt、AGENTS.md 和 Skills。（参考 OpenAI 开发者博客：Rethinking skills and prompts for GPT-6 Astra）
GPT-6 时代的统一原则是：
减少程序式指导，增加任务契约。
提示词：Goal、Context、Constraints、Done when
OpenAI 当前给 Codex 的推荐 Prompt 结构可以概括为：Goal → Context → Constraints → Done when。（https://learn.chatgpt.com/guides/best-practices）
过去常见写法是：先扫描目录、再读全部文档、先制定计划、每一步等待批准、修改后运行全部测试。这类 Prompt 本质上是在替 Agent 规定执行算法。GPT-6 更适合明确最终任务契约，例如：
目标：
修复 Safari 下结账页面重复提交的问题。
上下文：
主要相关代码在 checkout/，已知错误日志见 logs/safari-submit.md。
约束：
不要修改支付 API 契约；不要改变其他浏览器行为。
完成条件：
Safari 复现用例消失；相关 Checkout 测试通过；确认没有引入新的重复请求。不再需要像以前那样手动给模型编排每一步怎么思考怎么做，而是制定任务契约、Context Engineering、权限边界、完成标准和验证标准。
AGENTS.md 指令文档
AGENTS.md 负责说明什么情况下去哪里找知识，授予执行特定工作流程的权限，定义决策边界。
### 任务路由：
- 服务边界相关变更，在 architecture.md 文档记录；
- 数据库表结构或迁移相关工作，在 database.md 文档记录；
- 准备部署操作时，使用 deployment.md 文档。
### 工作契约与自主权规范
- 在本地隔离环境/分支中的读取、代码编辑和单元测试属于预授权操作，切勿中途暂停询问。
- 对于 routine、可逆的决策，做出合理假设并直接推进；仅在缺少关键信息且严重影响正确性或权限边界时提问。
### 指令优先级：
- 用户的显式指令 > 系统安全规则 > 本地 AGENTS.md > 外部 Skills 指引。
- 若外部 Skill 指引导致无谓的暂停或偏离，直接忽略该 Skill 的约束并继续完成授权工作。
### 风险匹配验证
- 验证强度必须与改动风险相匹配。针对小修小补仅执行定向局部检查，严禁触发全量无关测试循环。Skills
Codex 会先把 Skill 的 name + description 暴露给模型，让模型判断是否需要加载 Skill。Skill 太多、Description 太长时，Codex 可能缩短 Description，反而降低选择准确度；多个描述范围重叠时，还可能误触发 Skill。
Description 应尽量短，但触发边界要明确。比如“数据库相关工作都使用这个 Skill”范围过宽；“新增、修改或审核 Postgres migration 时使用”更精确。
Agent 工作模式
权限与安全边界
GPT-6 Astra 比 GPT-5.6 sol 更谨慎。 (GPT-6 Astra is generally better than GPT-5.6 Sol and earlier models at staying coherent during long tasks. It is also more likely to ask for clarification where earlier models would make assumptions.)
OpenAI 明确表示 Astra 更可能在“用户答案会实质改变结果”的时候提出澄清问题，而以前的模型可能直接猜。
你会遇到一种很有意思的现象：
- GPT-5.6 Sol：我大概知道你的意思，直接干。
- Astra：这里有两个合理选择，你希望哪个？(也就是说：它经常会停下来问问题)
所以，一个合理的风险边界是： 本地文件读取、可逆代码编辑、临时 Worktree、定向测试 → 默认授权。 删除大量文件、修改生产数据、发布生产环境、付款、向外发送消息、权限与密钥操作 → 继续审批。
同时：在 Prompt 或 AGENTS.md 中加入标准自主权指令（“对于非破坏性、可逆的决策，请直接按合理假设推进并完成校验，不要停下来提问”）即可彻底消除频繁暂停。
异步澄清与并发解耦执行：Codex Async Clarification & Execution
在 Codex 中，当任务存在非关键歧义时，GPT-6 Astra 不会直接阻塞暂停，而是会自动将任务拆分：一边在后台向用户提出澄清问题，同时继续完成那些不依赖用户答案的工作。
你不需要在 Codex 中做任何特殊的参数设置，这个是自带的功能。你只需要注意：发送指令后，不要彻底放手不管，因为 Codex 有可能中途异步向你问问题。
Subagent
GPT-6 Astra 真正的新问题是：
Astra 有能力拆分 Subagent，但它可能没有你预期得那么积极。
所以 OpenAI Prompting Guide 专门建议：如果任务适合并行，可以明确告诉它什么时候以及多大程度使用 Subagent。（Subagent delegation: The model may delegate less often than desired for your workflow. Specify when and how much it should use subagents for parallel work.）
如果任务天然可以分解，并且你希望最大化并发，明确授权 Subagent 是一种有效 Prompt 技巧。否则 Astra 大概率串行执行
测试与验证策略变化
OpenAI 明确指出 Astra 已经非常倾向测试和检查，因此过去 Always run the full test suite after every change 这类泛化规则可能导致简单修改也运行大量无关测试。（参见：Previous models needed encouragement to run tests and check their work. GPT-6 Astra does that on its own, so the same instructions can lead to unnecessary testing.）
也就是说：如果赋予过度的测试指令，它会为了极小的改动陷入无休止的测试重写循环
正确的做法：限定测试范围与风险相匹配（例如：针对 UI 样式修改仅运行局部视觉检查；针对核心鉴权逻辑才执行深度自检）
从旧项目迁移 GPT-6 的检查清单
- Prompt：删掉没有必要的 Step-by-Step 微操作，保留 Goal、Context、Constraints、Done when。
- AGENTS.md：删除所有任务都强制加载的架构文档，把它改成按场景读取的路由表。
- Skills：压缩 Description，缩小 Trigger 范围；大型 Skill 使用 Progressive Disclosure。
- Approval：删除低风险操作的逐步审批；保留不可逆、生产、财务、权限、外部通信操作的审批。
- Testing：从“永远跑全部测试”变为 Risk-Matched Verification。
- Model：重新 Eval Astra / Sol / Luna，不要简单把旧模型名字替换成 Astra。
- Reasoning：Sol 从 Medium、Luna 从适合任务的低中档开始；Astra 明确任务可以从 Low 开始，真正困难任务再提高。不要默认 Max。
- Context：不要因为有 1M Window 就扩大默认预加载范围。
- Codex：检查实验功能
experimental_mode = true是否值得开启。