Codex 教程的保质期越来越短：2026 年真正值得记的是“能力地图”，不是按钮
2026 年写 Codex 教程，有一个越来越尴尬的问题：一篇文章发布时可能是对的，三个月后就已经有一半细节变了。 这次源素材列了 12 个“进阶玩法”，大方向里有很多值得保留：沙箱、并行 worktree、Steer、计划、Skills、Automations、远程协作、MCP。但如果按 2026-08-14 的官方资料重新核对，部分“绝对结论”已经明显过时。 与其再做一篇“12 个隐藏
Codex 教程的保质期越来越短：2026 年真正值得记的是“能力地图”，不是按钮
2026 年写 Codex 教程，有一个越来越尴尬的问题：一篇文章发布时可能是对的，三个月后就已经有一半细节变了。
这次源素材列了 12 个“进阶玩法”，大方向里有很多值得保留：沙箱、并行 worktree、Steer、计划、Skills、Automations、远程协作、MCP。但如果按 2026-08-14 的官方资料重新核对，部分“绝对结论”已经明显过时。
与其再做一篇“12 个隐藏技巧”，更有价值的是教会读者怎么判断一个 Codex 能力当前在哪个 Surface、哪个 OS、什么权限、谁是 Host、什么时候需要 Human Gate。
先纠正四个传播性很强、但现在不够准确的说法
1. “VSCode 是 Codex 唯一能直连的编辑器”——不成立
OpenAI 官方明确把 Codex 描述为可以通过 CLI、IDE extension 和 desktop app 在开发者机器上工作。Codex App 本身就能处理多文件、终端、diff 和 Git 工作流。
所以 VSCode 是常见开发面，不是“唯一入口”。
2. “Mac 独享 Computer Use”——已经过时
Codex App 在 2026-03-04 正式上线 Windows。OpenAI 5 月底的 release notes 进一步确认 Windows Codex 支持 Computer Use，符合条件的用户可以让 Codex 查看、点击和输入 Windows 应用；还可以从 ChatGPT iOS/Android 或 Codex on Mac 继续 Windows 工作流。
发布时仍存在地区、工作区和资格差异，因此正确写法不是“Windows 全都有”，而是：
功能存在 + availability 需要按当前计划/地区/工作区核对。
3. “沙箱不能改外部文件、沙箱内绝对不能联网”——过度简化
OpenAI 对 Windows sandbox 的工程说明更精确：默认模式允许广泛读取，但写操作被限制在 workspace；网络默认不开放，除非用户明确请求/授权。
这和“什么都不能碰”的二元描述差别很大。
真正应该教四个维度：
Read Scope / Write Scope / Network Scope / Approval Scope
4. “权限完全放开更好用”——个人习惯，不是最佳实践
源帖回复里作者提到自己会把权限完全放开。这最多属于 SOURCE_OPINION。
Codex 能执行 shell、编辑文件、联网、使用插件/Computer Use。权限越大，blast radius 越大。尤其涉及生产数据库、Secret、支付、发布、账号操作时，Full Access 不应被包装成默认设置。
Worktree 真正解决的不是“开两个 AI”，而是状态隔离
Codex App 的并行能力很容易被写成“同一个项目开几个 Agent 同时跑”。真正关键的是 worktree 给不同任务提供隔离的 repo 状态。
适合并行：两个边界清楚、文件冲突小、验收条件独立的任务。
不适合并行：共同修改核心 schema、共享迁移、强顺序依赖的任务。
所以并行不是越多越快。真正要看的是：
Task Independence × Merge Cost × Review Capacity
如果最后人工 review 合并不了，再多 Agent 只是把拥堵从“写代码”移动到“审代码”。
Steer 的价值：不是省几分钟，而是降低错误路径的沉没成本
长任务里最贵的错误不是模型不会做，而是它在一个错误假设上持续推进。
Steer 的好处是在人发现方向偏差时提前改变局部约束，而不是等所有产物生成完再推倒。
它应该和一个明确习惯配套：
- 任务开始前写 Acceptance Criteria；
- 关键中间节点暴露结果；
- 发现方向错误立即 steer；
- 不把所有修正都堆到最后一轮。
- Feature；
- Surface（App/CLI/IDE/Web/Mobile）；
- OS；
- Plan/Workspace/Region；
- Read Scope；
- Write Scope；
- Network Scope；
- Host；
- Human Gate；
- Verified Date。
- 哪条是官方事实；
- 哪条只是作者偏好；
- 哪条和当前产品状态冲突；
- 哪条受 OS/计划/地区影响；
- 哪条涉及高权限风险；
- 最后核验日期是什么。
Plan 模式也不能被神化成“复杂任务必开”
计划的价值是暴露假设、依赖和风险。如果任务本身边界很小，过度计划反而增加交互成本。
更好的 Gate：
跨多文件 / 架构决策 / 数据迁移 / 高风险副作用 / 多种合理方案 → 先 Plan。
单点 typo / 明确测试修复 / 低风险机械改动 → 可以直接执行。
Skills：不要把长提示词误认为“稳定能力”
官方 Codex 已把 Skills 作为可复用工作流的一部分。但 alphahole 前 200 条已经沉淀出一个更严格的原则：
Skill 是可测试协议，不是一段很长的 instruction。
一个能长期用的 Skill 至少要有：
Trigger / Anti-trigger / Inputs / Workflow / Permissions / Human Gate / Output / Acceptance / Failure / Examples / Evals / Version。
如果没有 eval，一次成功只证明“这次碰巧成功”。
Remote / Mobile：分清 Host 和 Control Surface
OpenAI 2026-05-14 的官方说明非常关键：手机可以加载远端机器上的 live state，查看线程、审批、修改方向、开始新工作；但本地文件、凭据、权限和项目环境仍保留在运行 Codex 的 host。
因此，远程工作的正确心智模型不是“手机变成电脑”，而是：
Host 负责环境与执行；Mobile 负责 Intervention。
这会直接影响安全和可靠性。远程时最有价值的是缩短 Human Blocking Time——及时批准、回答、转向，而不是在手机上承担所有复杂 review。
Automations：能后台跑，不等于应该无人审查
重复、低风险、结果可 review 的任务很适合 Automation，例如定期 lint、报告、整理、测试、数据检查。
涉及写生产、支付、删除、大范围外发、Secret、账号权限变化，就应该保留 Human Gate。
自动化判断可以用：
Reversibility × Impact × Permission × Verification Cost
越不可逆、影响越大、权限越高，自动执行越应该保守。
2026 Codex 教程应该统一变成 Capability Contract
以后每一个功能都记录 10 个字段：
这套 Contract 能解决一个比“技巧大全”更重要的问题：Capability Drift。
一个旧教程不是只有“对/错”两种状态，而应该被标记：
CURRENT / REVERIFY / OBSOLETE / ACCOUNT-SPECIFIC / REGION-SPECIFIC。
对 alphahole 的产品化价值
这条内容不应该再造一个 Codex 技巧站。更应该增强已有 Remote-Agent Capability Drift Gate + Experience-to-Skill Compiler。
新模块可以让用户贴入一段 AI 工具教程，系统逐条输出：
免费层做单篇教程审计；会员层做收藏教程的动态 REVERIFY；团队版可以做内部 AI SOP freshness monitoring。
这比不断生产“最新版 20 个技巧”更有长期价值。
> 本文只依据截至 2026-08-14 的 OpenAI 官方资料进行能力核对。Codex 更新频繁，实际界面与资格请以当前账户和官方说明为准。