GPT-6 时代 Codex 的 4 个关键技巧：上下文、模型、提示词与 Agent 模式

开发工具2026-10-0514 நிமிட வாசிப்புGPT-6Codex上下文缓存AGENTS.mdSkillsAgent

YouTube 视频《4 个必须学习的 GPT-6 核心技巧：让你把 Codex 发挥到极致》由杰森的效率工坊发布，公开日期为 2026 年 10 月 3 日，时长约 20 分钟。视频把 GPT-6 时代的 Codex 使用变化归纳为四组：上下文与缓存、模型选择与资源分配、提示词和指令文档、以及 Agent 工作模式。

本文按字幕和视频章节整理作者的观点与示例。模型名称、价格、额度、实验性配置、第三方仓库星标和功能状态都可能随时间变化；涉及 OpenAI 功能时，应以当前官方文档和账户界面为准。文中命令和配置只作为概念说明，修改本地 Codex 配置前应先备份并确认当前版本支持。

一、上下文管理：窗口很大，不等于任务一直清晰

视频首先区分了两件事：模型能从超长上下文中找到信息，不代表它在很长的连续编程任务中始终保持同样清晰的工程判断。作者引用的经验是，GPT-6 类前沿模型在前约 15 万 token 处于更舒适的工作区；超过某个长上下文计价阈值后，缓存命中成本也可能变化。

这里的实用结论不是死记一个 token 数字，而是关注任务生命周期：上下文何时仍服务于当前目标，何时已经混入大量分支、旧决策和无关日志。视频建议根据任务关系选择不同操作：

场景	视频建议	目的
当前任务仍在主线上	继续使用当前会话	保留工作连续性
上下文过长但目标不变	`/compact`	压缩历史，继续主任务
临时讨论一个分支问题	`/side`	不污染主任务
基于当前状态探索新目标	`/fork`	复制历史，创建新任务分支
原任务已完成，新任务需要项目状态	`handoff.md` 或 handoff Skill	用结构化交接代替重新解释

交接文件应保存当前目标、已完成内容、未决问题、验证结果、相关文件和下一步，而不是复制整段聊天。视频特别强调，已有的 plan 或 issue 文档应直接引用，避免在 handoff 中制造第二份容易过期的事实。

二、跨上下文笔记：先了解状态，再决定是否启用

视频介绍了面向 Codex 和 GPT-6 Astra 的跨上下文结构化笔记功能：把重要决策和关键信息保存为可搜索的 note，让后续上下文窗口能够继续使用。作者提到该能力在视频制作期间处于实验和临时关闭状态，并给出过在 config.toml 中启用实验模式的示例。

这部分不能照抄成当前稳定操作。实验性开关可能改名、下线或只对特定账户开放；在没有核对当前官方文档和本地版本前，不要把 experimental_mode = true 写入生产配置。更稳妥的迁移方式是：先用项目已有的 AGENTS.md、plan、issue 和 handoff 文档保存关键状态，再把实验性 note 当作可选增强。

三、思考强度、缓存与模型切换

视频区分了“在同一个模型中调整思考强度”和“中途切换模型”：作者的结论是 GPT-6 中可以根据任务难度调整思考强度，而在同一个会话中途切换模型，可能造成缓存丢失和性能下降。

因此可以遵循三个操作原则：

任务开始前先选定主模型，避免把模型切换当成普通的调参动作。
在同一模型内，根据简单、一般和高难度阶段调整思考强度，并观察实际成本和质量。
如果不同任务需要不同模型，用独立会话或子代理分工，不要在主会话中途反复切换。

这里的价格和缓存行为属于版本、模型和计费策略相关的运行时事实。以视频发布时的体验作为排查线索即可，最终以当前 API 或 Codex 账户的用量和账单记录为准。

四、模型分工：Luna、Sol、Astra 的任务路由

视频给出一种按任务确定性和难度分配模型的方式：

模型角色	视频中的定位	典型任务
Luna	低成本、确定性强、频率高	翻译润色、文档处理、网页信息整理、运行测试脚本
Sol	日常主力，承担常规判断与推理	一般开发、代码修改、常规分析
Astra	高难度、多步骤、高价值任务	架构判断、复杂调试、需要更强推理的工作

这个表是路由起点，不是性能排名。实际模型名称、可用性、额度和计费应通过当前模型列表与账户页面确认。简单任务交给低成本子代理可以省资源，但要给出明确输入、输出和验收标准，避免把低成本变成重复返工。

五、把 ChatGPT 网页端放到前期分析位置

视频提出一个资源分配思路：把项目早期的讨论、搜索、方案比较和规划放到 ChatGPT 网页端，再把经过整理的结果交给 Codex 执行，以减少 Codex 额度消耗。它按风险从低到高介绍三种集成层级：

在 Codex 中使用 @ 引用 ChatGPT 网页端已有对话。这是最简单、最适合新手的方式。
使用只读的 codex-with-chatgpt 类方案，让内置浏览器通过 MCP 读取本地项目，由 ChatGPT 提供分析建议，最终仍由 Codex 修改文件。
使用带 full harness 的 codex-chatgpt-web 类方案，让 ChatGPT 直接获得文件系统和工具权限。视频将其称为更激进、风险更高的方式，并提醒注意个人版条款和仓库 issue 中的风险案例。

本文不把第三方仓库列为推荐，也不复述安装脚本。引入任何 MCP、浏览器连接器或 harness 前，应检查代码、权限范围、数据外发路径、维护状态和许可证。只读分析与能够写文件、运行脚本、访问密钥是完全不同的风险级别。

六、GPT-6 时代的提示词：目标、上下文、约束、完成条件

视频认为，旧模型时代堆积的“先扫描目录、再制定计划、每一步等待批准、最后运行全部测试”等程序性提示词，可能限制更强模型。作者推荐用四段结构替代：

目标：要实现、修复或交付什么？
上下文：需求、日志、相关文件和已有决策在哪里？
约束：哪些接口、行为、权限或文件不能改变？
完成条件：用什么结果、测试或证据判断任务完成？

这不是让提示词变得更短而已，而是把决策权交给模型，同时把不可越过的边界写清楚。比如“修复上传错误；日志在 X；不要改 API 契约；完成后运行上传模块测试并报告结果”，比要求模型机械执行十几个步骤更容易维护。

七、精简 AGENTS.md 与 Skills

视频建议把 AGENTS.md 当作路由和工作契约，而不是项目百科全书。文件可以说明：遇到什么任务去读哪个文档、指令优先级是什么、哪些操作需要审批、验证范围如何匹配风险。项目的全部背景应该留在合适的文档中，避免每次任务都注入一大段历史。

Skill 的 name 和 description 会暴露给模型用于匹配。装太多同类 Skill，或让描述覆盖过宽，可能降低触发准确度。一个好的描述应明确：

什么时候必须触发；
处理什么输入；
产出什么结果；
哪些相似任务不属于它。

对于网络搜索、数据库或部署等高风险能力，尤其要避免多个 Skill 隐式竞争。视频提到可将重型或高影响 Skill 改为显式调用；具体属性名称和配置格式需要按当前 Codex Skill 文档核对，不要盲目复制旧配置。

八、Agent 工作模式：给可逆动作自主权，给高风险动作留审批

视频观察到 GPT-6 Astra 在有多个合理选择时更倾向于询问，并支持一边执行一边提出澄清问题。它建议对可逆、非破坏性动作给出足够自主权，对大量删除、付款、密钥和不可逆外部操作保留审批。

可以按风险分层：

操作	默认边界
读取文件、搜索、格式化、运行局部测试	可在项目范围内自主执行
修改可回滚的本地代码	明确目录范围并要求 diff 与验证
删除大量文件、迁移数据、发布外部资源	需要明确确认和回滚方案
付款、提交密钥、生产写入	始终保留人工审批

明确要求并行使用子代理

视频认为 Astra 可能不会自动积极拆分子代理，因此适合并行的任务要在提示词中明确：并行哪些工作、每个子代理的模型和输出、如何汇总、何时停止。文档翻译、润色和独立测试等确定性任务可以交给较低成本模型；架构决策和最终复核仍由主 Agent 负责。

限定测试范围

“每次修改后运行全部测试”会让 Agent 扩大无关验证范围。更好的做法是按变更面选择测试：改 UI 就先做 UI 测试，改 API 就跑相关契约和集成测试，跨模块变更再扩大范围。无论模型多强，都要报告实际执行了哪些测试，而不是只写“已验证”。

九、GPT-6 迁移清单

视频最后给出一份迁移方向，可以整理成下面的项目检查表：

视频章节

来源：杰森的效率工坊，《4 个必须学习的 GPT-6 核心技巧：让你把 Codex 发挥到极致》，2026 年 10 月 3 日，YouTube 原视频。