开篇：为什么是 Codex，为什么是七天

你是不是也这样：收藏了一堆 AI 教程，真正打开跟着做完的没几篇？

问题不在你懒，而在大多数教程停在「功能罗列」——告诉你 Codex 能做什么，却不告诉你怎么才算真的做好了。

这一门课只做一件事：让你在 7 天里，把 Codex 从「装上了」用到「敢放手」。

title: "Day 1 · 跑起来：装上它，让它看见你的项目" description: "装好 CLI、登录账号，发出第一条指令，理解「会话」和「沙箱」。" course: codex order: 2 difficulty: 入门 duration: 15 分钟 lastUpdated: 2026-08-11 tags: ['安装', '登录', '沙箱']

当天目标：结束今天，你本地有一个 Codex 能跑、能读你项目约定、能用 Plan 模式规划并跑通一件小事的环境。

为什么先搭环境，而不是先调参

Agent 没有项目记忆。它每次开工，唯一能依赖的上下文就是你给它的文件 + 你下的指令。所以"让它听懂项目"的第一步，不是去点设置，是写一份项目说明书（桌面端的 Personalization 框，或仓库里的 AGENTS.md 文件），再建好一个不会被搅成一锅粥的目录结构。

桌面端的"工作区 / 文件夹"相当于左边的大抽屉，里面每一条 Thread 是一条任务线——这个两层结构决定你后面七天会不会乱，进哪个项目就 指定你的项目 再开 Codex，后面七天都顺着这个结构走。

两条入口路线，先定死一条

Codex 现在有两套入口：桌面端（ChatGPT 桌面应用里的 Codex）和 CLI（终端里的 codex 命令）。功能几乎一样，Personalization 框本质上就是 ~/.codex/AGENTS.md。选定一条走到底，别今天桌面端明天 CLI 来回切，配置会乱。两条路二选一：走桌面端得先装好 ChatGPT 桌面端；走 CLI 得本机有 Node 18 以上。

它还有几种"形态"值得知道：网页版 Cloud、GitHub 上自动审你代码的机器人、IDE 插件、用代码直接调的 SDK。关键差异：走 API key 直接调用拿不到 Cloud 网页和 GitHub 审代码这类托管能力——它们依赖 OpenAI 托管的运行环境。日常个人用，桌面端或 CLI 就够了。

提醒：独立的 Codex App 已在 2026-07-09 并入 ChatGPT 桌面端。

路线 A：桌面端（图形界面工作的人）

入口：打开 ChatGPT 桌面端，在左侧找到 Codex 入口。那个独立的 codex app 命令入口其实还在，但日常用桌面端界面就够了。
让 Codex 看见你的仓库：在 Codex 里"添加文件夹 / Open Folder"，选中你本地的项目目录（比如 dev/Projects/my-app）。这一步是关键——很多教程只说"建个目录"，没说怎么让 Codex 真的关联到你的代码。选完之后，你在这个工作区里开的每条 Thread 都基于这个仓库。
本地目录对照：桌面端的工作区和本地 dev/ 目录一一对应（Projects / sandbox / tools / notes 结构同上），顺着它走就不乱。
设置三件小事（路径在设置里）：
1. 开"保持电脑开机"——后台任务依赖电脑不睡眠，你睡了它断了，Day 6 的定时任务就失联。
2. 把 Follow-up 行为改成 steer——开发过程中你随时发消息调整方向，不用等它停。这是 Day 6"中途纠偏"的前提。
3. 建好 Threads 两层：第一层文件夹当"工作区"（按项目分），第二层在每个文件夹里建 Thread 当"任务线"（一个明确目标一条线）。别把所有事塞进一个 Thread。

路线 B：CLI（习惯终端、要写脚本/接 CI 的人）

bash

node -v                             # 先确认 Node 已装且在 18 以上；没装去 nodejs.org 下 LTS，装完重开终端
npm install -g @openai/codex        # 全局装 CLI（Node 18+）
codex --version                     # 打印版本号，确认装上了
codex login                         # 弹浏览器授权；回车后 codex status 显示已登录账号

codex login 引导你用 ChatGPT 账号授权（官方引导是跑 codex 后选 Sign in with ChatGPT）。授权完 codex status 会显示已登录账号。
登录卡住：先换网络重跑 codex login；还不行就 codex logout 后重新登录。
CLI 的好处是后面所有自动化（定时任务、CI、脚本调用）都基于它，偏技术的读者建议走这条。
让 Codex 看见仓库：cd 进你的项目目录再敲 codex 进入交互，它就读这个目录。没有现成项目就先 mkdir -p dev/Projects/demo && cd dev/Projects/demo 建个空目录练手。

怎么让 Codex"听懂"你的项目

桌面端的 Personalization 框（在「设置 → Personalization」，或点头像进「Customize」；它等价于全局 ~/.codex/AGENTS.md）。别照抄下面骨架，先用三问反推出你自己的：①项目跑不起来最常卡哪一步？②上次 review 最常被打回什么？③哪个目录碰了会炸？把答案填进去，再补下面几块：

markdown

# 项目协作约定（全局 AGENTS.md / Personalization）

## Operating principles
- 改动前先理解现有结构，不引入不必要的抽象。
- 优先改最小范围，不顺手重构无关代码。

## Build & run
- 启动：先 `npm install`，再 `npm run dev`，默认 3000 端口。
- 测试：`npm test`；提交前必须全绿。

## Output formatting
- 改动给 diff 而不是整文件重写。
- 注释用中文，面向人读。

## Conventions
- TypeScript strict 模式。
- 组件用函数式写法。
- 提交信息用 conventional commits（feat/fix/docs/...）。

## Constraints（红线）
- 不动 `migrations/` 目录。
- 测试必须过才能提 PR。
- 不往代码里写死密钥。

CLI 用户则在仓库根写 AGENTS.md，内容一样的几块。

第一性原理：工具的价值 = 决策质量 × 上下文质量。Codex 的决策质量由模型决定（你改不了），你能撬动的只有"上下文质量"——而 AGENTS.md / Personalization 就是上下文质量的乘数。今天写这一份，后面七天都吃利息。

第一个任务：先用 Plan 模式，别让它直接改

新手最常翻的车，就是一上来"帮我重构整个项目"——它改了上百个文件你拦不住。所以第一个任务要小、要能验证、要真有点用，而且先用 Plan 模式让它规划、你确认后再动手。

Plan 模式怎么进：

桌面端：对话框左侧找到"计划模式 / Plan"入口，或快捷键 Shift+Tab 切到 Plan。
CLI：会话里输入 /plan 你的需求描述，或按 Shift+Tab 在模式间切换（切到"只规划、不改动"那档再开工）。

Plan 模式下它只读文件、提澄清问题、生成计划，不写任何代码。你看了计划觉得对，再批准它执行。

第一个小任务示例：

在仓库里，给 utils/format.ts 加一个把日期格式化成 YYYY-MM-DD 的函数，附带一个单元测试，跑通测试。（仓库里没有 utils/format.ts 就先建一个空文件，或把路径换成你真有的文件——重点是让它能跑通一个小闭环。）

进 Plan 模式说这句话，看它列的计划（读哪些文件、怎么加、测试怎么写），确认没问题再放行。它读完 AGENTS.md 和你的指令，会改文件、写测试、跑测试。你看着它跑完，确认测试绿了，Day 1 就过关了。

如果它跑挂了——比如测试环境没装——这正是 Day 2 要讲的"断网伪成功"的苗头，今天先别深究，记住这个感觉：它"说完了"不等于"做对了"。

三个锦囊

Personalization / AGENTS.md 今天就必须写，哪怕只写 Build & run 一行。空着等于每天重复交代背景，纯浪费。
桌面端用户今天就把"保持电脑开机"和 Follow-up=steer 开了，不然 Day 6 的后台任务和纠偏玩不转。Windows 用户先确认桌面端有没有 Codex 入口，没有就走 CLI。
第一个任务要小，且先走 Plan 模式。大任务留到 Day 4 你学会验收之后再上。

自测标尺（用命令验证，不是口头打勾）

[ ] 你跑 codex --version 能看到版本号；codex status 显示已登录。
[ ] 你能说出自己走的是桌面端还是 CLI，且知道 Personalization 框 ≡ ~/.codex/AGENTS.md。
[ ] 你的 AGENTS.md / Personalization 里至少有 Build & run 一块写了真实内容（用三问反推填的，不是抄的）。
[ ] 你用 /plan 或 Plan 模式跑通了第一个小任务，且看到了测试变绿。
[ ] 验证约定真加载了：在会话里让它"复述你 AGENTS.md 里的 Build & run 要点"，它答得上来才算加载成功（CLI 也可用 /init 作为快速起点）。

效率日志（四列，今天起每天记）

任务	手动做要几分钟	Codex 做+你验收几分钟	打回几次
加日期格式化函数	___	___	___

title: "Day 2 · 管住它：给钥匙之前先看清边界" description: "读懂审批×沙箱两个正交维度，设出日常安全档，知道红区在哪。" course: codex order: 3 difficulty: 入门 duration: 18 分钟 lastUpdated: 2026-08-11 tags: ['权限', '审批', '安全']

当天目标：读懂"审批 × 沙箱"是两个正交维度，给自己设出日常安全档，清楚知道红区在哪、为什么不能碰。

为什么"管住它"排第二天，而不是最后

因为它是你敢不敢放手的前提。教程普遍把权限讲成"三档滑块"——只读 / 自动 / 全自动。这是错的，而且危险。

真实情况是两个互相垂直的维度：横轴是"审批"（它动之前要不要问你），纵轴是"沙箱"（它跑的时候是不是被关在隔离笼里）。把它们当成一维滑块，你会误以为"我选了只读就安全"，其实只读模式下它照样能读你全盘文件。

审批：它动手之前，要不要先问你

官方把审批分成三档：

untrusted：敏感操作（写文件、跑命令、联网）逐条问你确认。最稳，初探首选。
on-request：它自己判断哪些要问，低风险自己干，高风险问你。日常推荐档，省心但不如 untrusted 稳。
never：全自动，啥都不问。只配给"你信得过的成熟项目 + 已经锁死的沙箱"。新手碰都不能碰。

默认档因版本/客户端而异，常见是 workspace-write × on-request（Auto 预设）。初学用 untrusted 最稳，别迷信"默认就安全"。

CLI 写法：codex --ask-for-approval on-request，简写 -a on-request。会话内也能用 /permissions 临时切。

一个安全要点：项目级配置改不了某些全局安全项。比如你不能在仓库的 config.toml 里覆盖 model_provider 或 openai_base_url 去偷偷指向别处——Codex 故意不让项目级配置动这一组安全相关键。所以别信"改 base_url 接国产模型"的偏门，那条路在配置层就被堵了。

沙箱：它跑的时候，被关在哪儿

官方把沙箱分成三档：

read-only：能读你文件，改和跑被锁。最安全，初探用。
workspace-write：能在当前工作区里改和跑，但默认断网——它需要联网时会被拦，得显式放行。日常推荐档。
danger-full-access：裸机跑，读写联网全开。红区，别给。

CLI 写法：codex --sandbox workspace-write，简写 -s workspace-write。网络是独立于沙箱的开关——workspace-write 默认关网，你要它联网得单独开（[sandbox_workspace_write] network_access = true）。这点教程几乎没人提，但极关键：默认断网意味着它没法偷偷外传你文件，也意味着它"需要联网却没网"时会出错——这正是下一段要讲的翻车。

各平台沙箱实现不一样，别迷信"开了沙箱就绝对安全"：

macOS：用 Seatbelt 做系统级隔离。
Linux：用 seccomp 沙箱（部分内核/发行版回退到较弱隔离，会提示你）。
Windows：有原生沙箱（elevated / unelevated），推荐 elevated；实在不行用 WSL2 跑 Codex，隔离更干净。注意 elevated 在企业机上有时会直接失败并静默降级成较弱隔离——进会话看启动回显/日志有没有提示降级，降级后它其实没被关严，别以为开了就万事大吉。另外 WSL1 已不支持，用 WSL2。

把两个维度拼成矩阵

横轴是沙箱，纵轴是审批。九个格子，危险组合标红：

	沙箱 read-only（隔离读）	沙箱 workspace-write（工作区可写，默认断网）	沙箱 danger-full-access（裸机）
审批 untrusted（逐条问）	最安全，初探首选	日常档：能改能跑但隔离 + 断网	仍危险：全自动前的过渡，不推荐
审批 on-request（该问才问）	安全且省心	进阶日常档	危险
审批 never（全自动）	能读全盘，慎用	只信成熟项目时可用	红区：全自动 + 裸机，一夜改光

结论：日常用 on-request × workspace-write。红区 never × danger-full-access 谁都别给。

权限正交矩阵

嫌弹窗烦是真实痛点，正确出口不是开 danger-full-access，而是在 sandbox/（Day 1 建的试错目录）或容器里放宽——那里没有真代码；或用 --approve-for-me 代你批常规确认，但它仍受沙箱约束。

最阴的一种翻车：断网伪成功

这是最容易被忽略的坑，因为失败被伪装成了成功。

workspace-write 默认断网。当你的任务需要联网（比如 npm install 拉包、curl 调 API），而沙箱没开网，它会失败。正常的失败你会看到报错。但 Agent 有时候不报错——它"自己改道"，绕开联网那步，写出一份"能跑但逻辑是错的"代码。它以为绕过去了，其实埋了雷，你还以为任务完成了。

断网伪成功链路

对策：需要联网的任务，显式给沙箱开网（或临时放宽并放行网络）；跑完一定去看它实际执行了什么命令，别只看它说"完成"。怎么看——会话里有命令回显区，也可以开日志（codex -c log_dir=./.codex-log 后查 ./.codex-log/codex-tui.log，把 npm install 失败这类行抓出来）。

动手前先打 Git 检查点（防它改坏你能回滚）

打检查点前先确认你会基础 Git：装好 Git、懂 git init / status / commit；还不会先花 20 分钟补。Codex 要改你文件之前，先让仓库有个"出事能退回"的快照：

bash

git status                         # 确认当前是干净的工作区
git switch -c codex-<日期>-<任务>  # 开一条专门的分支给它折腾，主线不受污染
# 或者不想开分支：git stash 把当前改动暂存，事后 git stash pop 取回

它真改出问题，你 git checkout . 或删掉那条分支就能回到检查点，不至于手动一个个文件救。Day 4 讲 worktree 时还会用它做并行隔离。

把日常档写进配置（别每次手敲参数）

~/.codex/config.toml 不存在就自己建（Windows 上就是 C:\Users\你的用户名\.codex\config.toml，用记事本保存时文件名加英文引号，免得变 .txt）：

toml

# ~/.codex/config.toml
approval_policy = "on-request"        # 日常档：该问才问
sandbox_mode = "workspace-write"      # 工作区可写，默认断网

[sandbox_workspace_write]
network_access = false               # 显式关网；需联网的任务改成 true 或临时放宽

[windows]                            # Windows 用户加这条
sandbox = "elevated"

预期：之后每次进 Codex，默认就在这个档位，不用每次加 -a / -s。要临时更严，会话里 /permissions 切 untrusted；要临时放开网络，改 network_access = true 后重启会话。

三个锦囊

今天就把日常档设成 on-request × workspace-write，写进 ~/.codex/config.toml，别每次手动加参数。
红区 never × danger-full-access 写进脑子，任何教程让你"开 full 权限图省事"，一律当没看见。
需要联网的任务，跑完查它实际执行的命令，断网伪成功不会自己跳出来告诉你。

自测标尺（用命令验证）

[ ] 你打开 ~/.codex/config.toml，确认里面有 approval_policy 和 sandbox_mode 且值是日常档。
[ ] 会话里 /permissions 能切到 untrusted，且你知道网络是独立开关（network_access）。
[ ] 你能说出"断网伪成功"是什么、怎么防（去看实际执行命令）。

效率日志

任务	手动做要几分钟	Codex 做+你验收几分钟	打回几次
配安全档 + 试一次断网任务	___	___	___

title: "Day 3 · 教会它：把约定写成文本契约" description: "把约定写成文本契约，让 Codex 真的按你的规矩来。" course: codex order: 4 difficulty: 入门 duration: 20 分钟 lastUpdated: 2026-08-11 tags: ['AGENTS', '契约', '记忆']

当天目标：用 AGENTS.md + Skill + Memories 把项目约定固化成文本，让 Codex 越用越懂你，而不是每次重新教。

为什么"教会它"是个工程问题，不是聊天问题

Day 1 你写了 AGENTS.md 的骨架。今天把它做厚，再补两个大多数人忽略的机制：Skill（可复用的操作手册）和 Memories（它自己记的笔记）。

第一性原理还是那个：上下文质量 = 工具价值。你每多写一条约定，后面每次对话都少解释一遍，且不会因"你忘了说"而出错。

AGENTS.md：查找顺序与级联

Codex 读 AGENTS.md 是级联的：

全局 ~/.codex/AGENTS.md——对所有项目生效。
仓库根 你的项目/AGENTS.md——对这个项目生效，覆盖全局同名约定。
子目录 你的项目/src/AGENTS.md——只对 src 下生效，最优先。

越靠近代码，优先级越高。所以"通用的放全局，项目特有的放仓库根，某模块特有的放子目录"。还有个 AGENTS.override.md：你想临时推翻某些约定（比如这次就想让它随便改 migrations），写在这里——它和同目录的 AGENTS.md 只取一个（override 优先），但仍会被更靠近当前目录的下层文件覆盖，不是"压过一切"。用完删掉。

长度有默认上限 project_doc_max_bytes（约 32KiB，可调高但别无限堆——太长它反而抓不住重点）。所以 AGENTS.md 写"约定"，不写"教程"。

上下文文件优先级地图

Skill：把重复操作打包成可复用手册

Skill 是 Codex 的"操作手册"机制。四个作用域和对应的真实路径：

REPO：仓库内 .agents/skills/（从 cwd 向上扫到仓库根都能发现），团队共享，提交进 git 大家都能用。
USER：你个人的 $HOME/.agents/skills/，跨项目。
ADMIN：/etc/codex/skills/，机器/容器级，IT 管理用。
SYSTEM：Codex 内置（如 $skill-creator、$plan），不用管。

注意 USER 路径是 $HOME/.agents/skills，不是 ~/.codex/skills——这是最容易写错的地方。

建一个 Skill 有两条路：对话里输入 $skill-creator，它会分步问你——这个技能干嘛用、什么时机触发、要不要带脚本——然后自动生成目录和 SKILL.md；或手动建文件夹 + SKILL.md。桌面端在 Skills 面板里能看到已装技能、开关和来源，CLI 用 /skills 查看。SKILL.md 必须含 YAML frontmatter 的 name 和 description：

markdown

---
name: release-check
description: 检查版本号、变更记录、测试结果和 Git 状态，适用于准备发布或打标签前的核对。
---

# Release Check
按项目规范完成发布前检查：
1. 确认 package.json 版本号已 bump。
2. 确认 CHANGELOG 已更新。
3. 跑 `npm test`，必须全绿。
4. 跑 `git status`，确认没有遗漏的未提交改动。

显式调用：CLI/IDE 里输入 $ 后跟技能名（如 $release-check），或运行 /skills 看可用技能。
隐式调用：当你的任务描述和 description 匹配时，Codex 自动选它——所以 description 要写清"什么时候用、什么时候不用"，把关键触发词放前面。

坏例子：description: 处理发布相关的事 —— 太泛，Codex 分不清该不该触发，也容易和别的 Skill 撞。好例子：description: 发布前核对——检查版本号、CHANGELOG、测试结果和 Git 状态；仅在准备打 tag 或发版前使用 —— 触发词（发布前/打 tag）和禁用场景都写清，匹配才准。

同名 Skill 不合并，两个都会出现，靠 description 区分。

今天就真建一个并跑起来

光懂机制不够，现在动手做出第一个能复用的 Skill：

在仓库里建文件 .agents/skills/release-check/SKILL.md，把上面的 frontmatter 和正文粘进去（REPO 作用域，提交进 git 团队都能用）。
回到 Codex 会话，输入 $release-check。它会读 SKILL.md，按四步执行：检查 package.json 版本、看 CHANGELOG、跑 npm test、看 git status。
盯它实际做了什么——它应该真的跑过 npm test 并贴结果，而不是嘴上说"已检查"。如果它没跑测试就报"通过"，说明 Skill 写歪了，回去改 description 或步骤。
想让它自动触发，就把 description 写成"发布前核对——检查版本号、CHANGELOG、测试结果和 Git 状态；仅在准备打 tag 或发版前使用"。下次你说"准备发 v1.2"，它自己会挑这个 Skill，不用你手动 $。

这一个 Skill，每周发版帮你省一次人工核对。

渐进式披露（这是 Skills 的机制，不是 MCP 的）：Codex 启动时只加载每个 Skill 的 name + description 进初始清单，预算约上下文 2% 或 8000 字符。选中后才读完整 SKILL.md。所以 description 写最关键的可检索词，别把重点埋在文件末尾。

关键坑（自我蒸馏）：OpenAI 团队成员曾分享过一招——把一段提示词丢给 Codex，它回看历史会话，把重复工作流自动打包成 Skill / Subagent / Automation。这条路听起来香，但有两个坑：

它只看"重复"，不看"对不对"。Skill 没触发、机制没转的断点被忽略。
自动生成的 Skill，一半来自"输入还没稳定时就做过两次的事"——这种 Skill 维护比重写还贵。

所以自动蒸馏出的 Skill 必须人工把关：过一遍，删掉没稳定下来的，只留真能复用的。

Memories：让它自己记笔记

Memories 是 Codex 在协作中自己沉淀的笔记（你踩过的坑、项目的特殊约定），默认就是开启的（配置项 memories.generate_memories 默认为 true），下次会话会自动读进来。用 /memories 可以看它记了什么。

用法：跑完一段复杂任务，它通常会自己沉淀关键约定；你也可以明确让它"把这次的关键约定记进 Memories"。定期清理过时的 Memories，别让它记了一堆过期规则反过来误导你。存储路径因版本而异（可用 /memories 查看），别手改那个目录，让 Codex 自己管。

三个锦囊

AGENTS.md 今天补到"项目特有约定"层，仓库根那份写满 Build/run/Conventions/Constraints，别只留骨架。
第一个 Skill 今天就建：挑一个你每周都做的重复操作（发版、生成变更日志），用 $skill-creator 或手写一个 REPO/USER 作用域的 Skill。记得 name/description frontmatter。
自动蒸馏的 Skill 人工过一遍再留，别让"重复两次"就变成永久负担；Memories 定期清过期。

自测标尺（用命令/文件验证）

[ ] 你能说清 AGENTS.md 三级级联顺序和 AGENTS.override.md 的真实行为（同目录只取一个，不压过更靠近 cwd 的）。
[ ] 你建了至少一个真实 Skill，且 SKILL.md 有 name/description，你知道它属于哪个作用域、存在哪个路径（$HOME/.agents/skills/ 或 .agents/skills/）。
[ ] 你用过 $skill-name 或 /skills 触发过它；知道 description 决定隐式匹配。
[ ] 你理解"自我蒸馏"的两个坑，知道自动生成的 Skill 要人工把关；会用 /memories 看记忆。

效率日志

任务	手动做要几分钟	Codex 做+你验收几分钟	打回几次
建第一个 Skill + 写 AGENTS.md 项目层	___	___	___

title: "Day 4 · 放开它：让 Agent 自己证明做完了" description: "让 Agent 自己证明做完了，建立第一道验收意识。" course: codex order: 5 difficulty: 进阶 duration: 18 分钟 lastUpdated: 2026-08-11 tags: ['验收', '测试', '闭环']

当天目标：用"验收闭环"让 Codex 自己证明任务完成，而不是你盲信它说的"好了"。

为什么"放手"不等于"不管"

Day 2 你学会了收权限，Day 3 学会了教约定。但还有最后一个坎：你让它干完一件事，它说"做完了"，你信不信？

答案是：别信它说，让它证。这就是验收闭环——你下任务时就把"怎样算完成"写清楚，它做完必须对照那条标准自证。OpenAI 团队内部流传一句话："有雄心没有验证，不过是个愿望。"

一个你现在就能复现的实验（就知道为什么需要验收）

这一条别读，直接跑：给 Codex 下这个任务，然后别看它说"完成"，直接去看测试文件。

给 utils/ 加个 slugify 函数 + 测试，Done when：npm test 全绿、测试里有对 slugify 的 assert。

它大概率能跑通。但请故意做一件事：把 Done when 里的"有 assert"去掉，只说"加个测试"，再看它写出来的测试——常会是 print(slugify("你好 World")) 而没有 assert，或者 slugify 对中文直接返回空串。它在"完成"的定义里，把"文件存在"当成了"功能正确"。

验收闭环要做的，是逼它证明"测试真跑了、真绿了"，而不是"我写了测试"。

提示四要素：Goal / Context / Constraints / Done when

下任务时，把下面四块写全：

Goal：要达成什么。
Context：背景、相关文件、已知约束。
Constraints：红线（别动哪些、必须过什么）。
Done when：怎样算真完成——必须可验证。比如"测试全绿且 npm run build 通过"，而不是"功能实现"。

可复制的验收提示词骨架：

markdown

Goal：给 utils/ 加 slugify 函数，处理中英文。
Context：TS 项目，strict 模式，现有测试用 vitest。
Constraints：不引入新依赖；不动其他文件。
Done when：
- `npm test` 全绿，且测试里包含对 slugify 的 assert（不是 print）；
- 中文输入 "你好 World" 返回 "ni-hao-world"；
- `npm run build` 通过。

模糊的 Done when（"做好就行"）等于没验收——它说自己好，不等于真做好了。

长任务怎么不失控：compact / 新 Thread / worktree 三选一

上下文会满，满了对齐就崩。三个手段按场景选：

/compact：一段对话跑太久、开始胡说前，把已完成部分压成摘要腾空间——同一任务继续时用。
开新 Thread：任务之间毫无关联（比如一个在改前端、一个在写后端文档），别塞同一条线，新开一条避免上下文互相污染。判断标准：上一条任务的背景，下一条用不上，就开新的。
git worktree：一个大任务要拆多路并行（比如"重构三个模块"），每条开独立 worktree + 分支，各管各的，主线程只收结果，避免互相踩。

判断口诀：同一任务接着干用 compact，不相干任务开新 Thread，要并行才用 worktree。

把多 Thread 当产能，不只是防污染：① 每条线挂一个独立、可验收的目标，你从执行者变成调度者，轮流验收；② 只要动同一批文件，就必须配 worktree，否则两条线会互相踩。

验收闭环实操 + 代码评审

回到 Day 1 那个小任务，今天升级：下任务时写全四要素，特别是 Done when。它做完，你实际看它执行的命令和测试结果，对照 Done when 逐条勾。勾满了才算过，勾不满打回去重做。

进阶：让 Codex 自己审自己。用 /review 命令（或让它在计划阶段产出 PLANS.md、在改动后产出 code_review.md），把"它认为完成了"和"它自己复检的结论"都留痕，你再对照 Done when 收口。

它跑完改动后产出的 code_review.md 大致长这样（节选）：

## 改动概述
在 utils/ 新增 slugify，处理中英文；新增 slugify.test.ts。

## 自检验证
- [x] npm test 全绿
- [x] "你好 World" → "ni-hao-world"
- [x] npm run build 通过

## 风险点
- slugify 暂未处理 emoji，极端输入可能返回空串（已记入 Memories 待跟进）

拿这份对照 Done when 逐条勾，比听它说"完成"靠谱。空着的勾就是打回去的理由。

验收闭环

三个锦囊

每个任务都写 Done when，且必须可验证。"功能实现"不是验收标准，"测试绿 + build 过 + 含 assert"才是。
长任务中途 /compact，别等上下文爆了才救；大任务拆 worktree 并行。
它说"完成"先别信，看实际命令和测试结果，对照 Done when 逐条勾；用 /review 让它自己复检。

自测标尺（用动作验证）

[ ] 你给任意一个任务写出了可验证的 Done when（含具体 assert / 命令），不是"做好就行"。
[ ] 你实操过一次"对照 Done when 验收并打回"，而不是只看它说"完成"。
[ ] 你知道 /compact 干嘛用；跑过长任务中途 compact 过。
[ ] 你用过 /review（或产出 code_review.md）让它自己复检。

效率日志

任务	手动做要几分钟	Codex 做+你验收几分钟	打回几次
带四要素的任务 + 验收打回	___	___	___

title: "Day 5 · 用起来：接工具、吃重复活、算清成本" description: "接工具、吃重复活、算清成本，把 Codex 当生产力。" course: codex order: 6 difficulty: 进阶 duration: 22 分钟 lastUpdated: 2026-08-11 tags: ['MCP', '工具', '成本']

当天目标：给 Codex 接上 MCP 外部工具，在真实场景里吃掉一件重复活，并搞懂成本机制。

Codex 的稀缺价值在"造工具"和"吃重复活"，不在"代写内容"

Codex 最值钱的活是：把你要手动做的、重复的工程动作自动化掉——批量改文件名、生成 CRUD 代码、跑测试、提 PR、整理 Issue。所以第 5 天就一件事：用 Codex 把你每周 X 小时的重复活吃掉。

接 MCP：让 Codex 能碰外部系统

MCP（Model Context Protocol）是让 Codex 调用外部工具（数据库、API、飞书、Playwright 浏览器等）的标准协议。配在 ~/.codex/config.toml 或项目级。

STDIO 型（本地命令启动，最常见）：

toml

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]   # 需本机有 Node；没装 playwright 先 npm i -g playwright，或换成你已装好的 MCP

# 工具级审批：四档 auto / prompt / writes / approve
# writes = 只读工具免审批，写/创建/删除类触发审批（推荐默认）
[mcp_servers.playwright]
default_tools_approval_mode = "writes"

# 单个工具覆盖：这个工具每次问你
[mcp_servers.playwright.tools.browser_navigate]
approval_mode = "prompt"

Streamable HTTP 型（远程服务）：

toml

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
default_tools_approval_mode = "prompt"

要点：

四档审批：auto（静默全批）、prompt（每次问你）、writes（只读免审、写操作弹审批，v0.144.0 起推荐默认）、approve（除非预批准否则拦截）。破坏性操作在所有档都需审批。
工具级 + 服务级：先用 default_tools_approval_mode 定全局，再用 [mcp_servers.x.tools.t] approval_mode 单个覆盖。
OAuth：远程 MCP 的认证在 v0.144.0 起 GA，跑 codex mcp login 启动登录；mcp_oauth_callback_port 可固定回调端口。别把 token 明文写进 config。
其他旋钮：startup_timeout_sec（默认 10）、tool_timeout_sec（默认 60）、enabled_tools/disabled_tools、required（启不来就启动失败）。
查当前接了哪些：桌面端用 /mcp；CLI 用 codex status 看概况。

MCP 工具审批四档

一个常见误解：有人以为 MCP 配置也像 Skill 那样"前 512 字符当索引"——那是 Skill 渐进披露（2% / 8000 字符）的预算，MCP server 的 instructions 前 512 字符要自成一体。两回事，别混。

场景组：挑一个今天就能吃掉的重复活

下面每个场景都给完整提示词骨架（Goal / Context / Constraints / Done when），你照着填自己的项目：

场景 A · 批量重构

Goal：把 src/ 下所有 var 改成 const，未重新赋值的。 Context：src/ 是 TS 项目，strict 模式。 Constraints：不动 *.test.ts；每文件单独提交。 Done when：tsc --noEmit 通过，且 git diff --stat 只含预期文件，CI 绿。

场景 B · 生成 CRUD + 测试

Goal：给 User 实体生成 RESTful 接口 + 单元测试。 Context：用仓库现有 services/ 模式（见 AGENTS.md）。 Constraints：不引入新依赖；沿用现有错误处理。 Done when：npm test 全绿，且新增接口在 /docs 里有记录。

场景 C · 整理 Issue / 周报

Goal：读本周 GitHub Issues，生成一份按优先级排序的周报。 Context：仓库地址、本周时间范围。 Constraints：只列 open 状态；不改动任何 Issue。 Done when：产出 markdown 周报，且未对任何 Issue 执行写操作（用 Read-only 沙箱跑）。

场景 D · 端到端（从空目录到可验收的产物）

Goal：从空仓库做出一个能跑、能测、能提交的最小 Node 小程序。 Context：空目录 dev/Projects/hello-codex，已 git init。 Constraints：只用一个文件；不引第三方依赖。 Done when：node index.js 输出 "hello from codex"；node test.js 断言通过；git log 有一条提交。

场景 E · 浏览器自动化（Playwright MCP）

这一条把 Codex 从"改你本地文件"升级到"真去开浏览器、真去点按钮"——价值大，危险也大。前面 Day 5 开头那段 Playwright MCP 配置就是为它准备的：接好后 Codex 能打开网页、登录、点击、截图、读页面结构。

Goal：用 Playwright 打开后台登录页，用测试账号登录，进"订单列表"，把前 20 条订单逐个点"导出"，确认都下载成功。 Context：Playwright MCP 已按本天配置接好，导航类工具（如 browser_navigate）设为 prompt 审批（见上方四档表）。环境是 staging，不是生产。 Constraints：只在 staging 跑；不写任何生产数据；登录凭据从环境变量读，不写进提示词。 Done when：20 次导出都生成了文件、文件名含订单号；产出一份 export-result.md 记录每条结果；全程没有走到生产域名。

为什么单独拎出来讲：浏览器一旦被打开，Codex 就等于能下单、能发帖、能转账。它"跑通了"不代表"做对了"——点错一个选择器，可能把测试单下到生产。所以相关工具必须走 prompt 而不是 auto，沙箱别放开到能碰你别的账号。

场景 F · 接飞书（把产出自动发到群 / 写进表格）

Codex 的价值不只在你电脑里。把它接到你的协作工具，就能把"生成的东西"自动送到该去的地方——前提是发之前拦一道。

Goal：每天早 9 点，把昨天合入的 GitHub PR 标题和链接汇总，发到"发布同步"飞书群，同时写进团队的发布记录多维表格。 Context：你已装好飞书 CLI（lark-cli）并登录，或接了飞书 MCP；GitHub token 放在环境变量。 Constraints：只发"已合入"的 PR；不改动任何仓库文件；群名和表格 ID 写进 AGENTS.md，不写进提示词。 Done when：群里收到一条含日期和 PR 列表的消息、表格新增一行；命令退出码为 0；没有把草稿 PR 误发进去。

这条最常见的坑：Codex 跑通"发消息"不代表"发对了"。它可能在凌晨把一条还没 review 的 PR 当成已合入发出去，或者发错群。所以"往外发"的动作审批要拦一道（writes 或 approve，别 auto）；更稳的做法是让它先把拟发内容写到本地文件、你过一眼再发（定时怎么配见 Day 6）。

挑一个离你最近的，今天就用四要素下给它，跑通。

成本机制：钱到底烧在哪

这是被教程集体跳过、但你最该懂的一块。

消耗的是"额度/credits"，不是"次数"。一次任务烧多少，取决于它读了多少上下文、跑了多少轮工具调用、模型档位多高。
套餐决定上限：ChatGPT Plus / Pro / 团队版各挡额度不同（具体数字以你当天套餐页为准，别人晒的截图会过期，别当真）；用 API key 是按 token 实时结算。
推理档位（reasoning effort）直接挂钩成本：档越高单次越贵但质量越高；具体档名和配置写法以你当天 codex --help / 官方文档为准，别把档位焊死。
推理档位怎么选（档名以当天 codex --help 为准，别焊死）：日常改字符串、格式化用低档；常规改动用中档；跨文件重构、调试升到高档；长程 agentic 任务才上 Extra High。原则就一句——用刚好够的最低档，档越高越贵但越稳。
算不清成本就谈不上"省"：你授权它消耗的每次 token、每分额度，都是你买回来的时间。用 codex status 看用量，定期回看"我花了多少、省了多少小时"。

第一性原理回扣：工具价值 = 决策质量 × 上下文质量。成本机制提醒你——上下文越厚（AGENTS.md 写得好）、指令越准（Done when 写得清），单次消耗的轮数越少，单位时间成本越低。写清楚约定，本身就是省钱。

成本机制

三个锦囊

MCP 工具级审批今天就必须配，别全开。writes 是稳妥默认，高危工具单独 prompt/approve。
今天挑一个场景跑通，用完整四要素。别"看懂了"就过，动手才有体感。
成本只看机制 + 用 codex status 看自己用量，别人晒的数字会过期，不采信。

自测标尺（用动作验证）

[ ] 你给自己配了一个 MCP server，且 default_tools_approval_mode 设的是 writes（不是全开）。
[ ] 你用四要素跑通了至少一个真实场景，且对照 Done when 验收过。
[ ] 你能讲清成本机制（额度非次数、档位挂钩、套餐定上限）。
[ ] 你跑过 codex status 看过自己的用量。

效率日志

任务	手动做要几分钟	Codex 做+你验收几分钟	打回几次
场景（如批量重构）	___	___	___

title: "Day 6 · 串成工作流：定时、无人值守、高效用法" description: "定时、无人值守、把 Codex 串进你的工作流。" course: codex order: 7 difficulty: 进阶 duration: 25 分钟 lastUpdated: 2026-08-11 tags: ['工作流', '定时', '自动化']

当天目标：把 Codex 变成"不在电脑前也能干活"的后台劳动力，并吸收一套成熟的高效用法。

工作流的本质区别：人在不在场

前面五天你都在场兜底。人不在场时，唯一的兜底是你事先收紧的边界——所以无人值守的权限必须比白天更紧，这跟 Day 2 一脉相承。

定时任务：RRULE 与外部触发

Codex 的定时能力主要在**桌面端 / Web（ChatGPT 托管界面）**里配置 scheduled 任务（Web 版有局限，比如没有本地文件夹，纯云端任务才顺）；CLI 没有内置定时 UI，要靠外部 cron（macOS/Linux）或 CI 触发 codex exec "<提示词>"，Windows 用任务计划程序或 WSL2 跑这条。别被"在 Codex 里建个 scheduled"这种含糊说法骗了——你走哪条路线，定时就走哪条路。

RRULE 是日历重复规则标准写法，填进定时配置时用。例：每周一早 9 点扫一遍 Issue 生成周报：

FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0

CLI 等价做法（外部 cron 触发）：

bash

# macOS/Linux：crontab -e 里加一行，每周一 9:00 跑
0 9 * * 1 codex exec "读本周 GitHub Issues，生成按优先级排序的周报，写到 weekly-report.md" --sandbox workspace-write -a on-request
# Windows：用任务计划程序或 WSL2 触发等价命令，不要在 cmd 里直接跑 cron（没有）

无人值守权限必须收紧：审批用 on-request 甚至 untrusted，沙箱 workspace-write 且默认断网，绝对不拿白天 never × danger-full-access 的配置直接丢给定时任务。CLI 0.147.0 起新增 --approve-for-me（代你批常规确认，但仍受沙箱约束）——不是放行一切。

心跳：让它定期主动向你汇报

下面这套用法，核心只有一句：别打断人和 Agent 的协作循环。我按实战拆成七条来讲，核心四条：

持久对话串：把相关任务挂同一条长对话，它带上下文连续干，不用每次重启交代背景。
Steering（中途纠偏）：用 Follow-up=steer（Day 1 开的）随时发消息调方向，它会在当前循环里就地改。提示词写法："在不动当前 X 的前提下，把 Y 也加上"。
Queuing（排队不打断）：把新指令排进队列，它干完手上这段再接新方向，不中途打断正在跑的循环。适合"先跑完这批，再开始那批"。
结构化记忆：把项目关键约定、踩过的坑写进 AGENTS.md / Memories，或者像很多开发者那样用 Obsidian 这类本地笔记软件建个知识库、让 AGENTS.md 当索引——代码库存代码，记忆库存滚动上下文，跨会话带着长期记忆干。

其余几招是上面四招的变体，挑有用的记：

工具触达：用 MCP 接浏览器、电脑、邮件、日历这类外部工具——比如让 Agent 直接开浏览器查资料，或把你的邮件、日历变成它干活的起点；语音口述任务——打字会把需求压成一句干巴巴的话，口述才带得出约束、背景和"上次那个坑"，而这些正是 Done when 写准的原料，配合双 Command 键截图喂上下文，适合边走边想。
Goals + 验证器 / 侧边栏：任务里写清 Goal 和 Done when（就是前面验收闭环那套）；长任务丢侧边栏，主线程干别的。
定期清坏规则：工作流跑久了会积过期 Skill、不再适用的约定。定期清一遍，比攒一堆更省心。

心跳 RRULE 示例：每 30 分钟扫一次 Slack/Issue，起草但不发送（防它擅自发出去）：

FREQ=MINUTELY;INTERVAL=30

任务提示词里明确"只起草，不发送"——这是无人值守的安全底线。

一个能直接抄的无人值守例子

把上面拼起来，这就是一个可落地的后台任务：

bash

# 每周一 9:00，让 Codex 扫 Issue 起草周报（不发送）
# crontab -e（macOS/Linux）或任务计划程序（Windows）
0 9 * * 1 codex exec \
  "读本周 open 状态的 GitHub Issues，按优先级生成周报草稿，写到 weekly-report.md。只起草，绝不主动发送或改任何 Issue。" \
  --sandbox workspace-write -a on-request --approve-for-me

要点：提示词明文"只起草不发送"兜底——这是无人值守的安全底线（沙箱、审批、--approve-for-me 的收紧见上方，别放松）。它真出格，最坏的结局也只是写了个本地草稿，不会外发、不会删库。

变体：每天 9:00 只读巡检。把周报例子换成"只读检查磁盘 / 日志 / 证书到期，写 report.md，经飞书或企微 MCP 推送到你眼前"——结果推到你面前，定时任务才用得下去。安全约束照写：read-only 沙箱 + 提示词"只报告不修复"。

三个锦囊

无人值守权限比人在时更紧，绝不用白天 full 档丢给定时任务；CLI 走 cron + codex exec。
心跳任务"只起草不发送"，防它擅自对外发。
这七条里"持久串 / Steering / Queuing / 结构化记忆"是常驻核心习惯——其余几招按场景取用。

自测标尺（用动作验证）

[ ] 你写过一个 RRULE（如 FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0），且知道无人值守权限要收紧。
[ ] 你知道 --approve-for-me（0.147.0 新增）是干嘛的、受什么约束；CLI 定时靠系统自带的定时任务 cron 或 CI 触发，没有内置定时界面。
[ ] 你实操过"持久对话串"或"中途纠偏"其中一种。
[ ] 你理解"定期清坏规则"为什么必要。

效率日志

任务	手动做要几分钟	Codex 做+你验收几分钟	打回几次
排一个定时/心跳任务	___	___	___

title: "Day 7 · 复盘与排雷：盯住会变的，做次体检" description: "盯住会变的，做次体检，把经验沉淀成可复用资产。" course: codex order: 8 difficulty: 进阶 duration: 20 分钟 lastUpdated: 2026-08-11 tags: ['复盘', '排雷', '体检']

当天目标：盯住"模型退役"和"协议墙"两颗时效炸弹，给自己的配置做一次体检，知道哪些会悄悄失效。

第一性原理：你的配置建在"会变的东西"上

前面六天你写下的所有配置——模型名、协议、Skill——都建在 OpenAI 会迭代的东西上。不写死 + 会查 + 会盯退役，是配置长期可用的前提。

炸弹一：模型退役红线

回开篇那件事：GPT-5.4 与 5.4-mini 于 2026-08-31 从 Codex 退役（仅 ChatGPT 登录场景受影响，走 API key 的不受影响）。影响面：

config.toml 里写死这两个模型的 → 到点静默变差。
CI 脚本 codex exec --model gpt-5.4-* → 不报错，行为变差。
custom agent 里焊死模型名的 → 同理。
官方给的替换建议：gpt-5.4 → gpt-5.6-terra，gpt-5.4-mini → gpt-5.6-luna（以官方当期替换建议为准，别焊死）。退役前把工作区默认、已存模型设置、托管配置、custom agent、定时任务里用到这两个模型的都改掉。

查当前模型的方法：会话内看模型选择器，或 codex --help 看 --model 说明，或查官方文档可用模型清单。对策：需要指定模型时用变量/环境变量，不在配置里焊死。

配套：CLI 0.147.0 移除 codex exec --full-auto（改用 --sandbox workspace-write 等组合）。老流水线里写死 --full-auto 的命令会直接报错失败（不是静默），检查并改掉。

炸弹二：协议墙（别搞反了）

很多教程说"Chat Completions 要 deprecated 了，接国产模型趁早"——这是错的。

OpenAI 官方弃用页面写得很清楚：截至本文撰写，Chat Completions API 不在官方弃用清单中；真正被宣布下线的是 Assistants API，计划 2026-08-26 下线，官方建议迁移到 Responses API（及 Conversations API）。所以"改 base_url 接国产模型"这条偏门，踩的是被堵的安全项（项目级配置动不了 openai_base_url），不是趁 Chat Completions 倒计时——那个倒计时不存在。

炸弹三：Chronicle 隐私雷

Codex 有屏幕截取类功能（比如 macOS 上的 Chronicle，能回看你屏幕做过什么），已知风险有三：本地存储可能未加密、烧 rate limit、被恶意内容诱导去做你没让做的事的风险更高。是否开启、开哪些，按你自己的安全边界定，功能不是开得越多越好，尤其屏幕抓取和凭证类。

配置体检清单（今天做一遍，给真实命令）

bash

# 把下面的 <repo> 换成你自己的项目路径再跑（Windows 用 Git Bash 或 WSL 执行，cmd 里没有 grep）
# 1. 查所有 config / CI / custom agent 里有没有写死 gpt-5.4*
grep -rn "gpt-5.4" ~/.codex/ <repo>/.codex/ <repo>/ci/  2>/dev/null
#    有 → 改成变量

# 2. 查有没有 --full-auto（0.147.0 已移除）
grep -rn "full-auto" <repo>/ <repo>/ci/  2>/dev/null
#    有 → 改成 --sandbox workspace-write 组合

# 3. 看登录与用量
codex status

# 4. 看日志（排障用）：先指定日志目录再查
codex -c log_dir=./.codex-log        # 之后查 ./.codex-log/codex-tui.log

Memories / Skills 清一遍过期的（用 /memories 看，手删过期 Skill 目录）。

附：排雷自查（照这七条过一遍自己的配置）

[ ] 没有把任何模型名焊死在 config.toml / CI / custom agent 里
[ ] 没有写死 --full-auto（已移除，改用 --sandbox 组合）
[ ] 日常档是 on-request × workspace-write，红区 never × danger-full-access 没开
[ ] 改文件前打了 Git 检查点（分支 / stash）
[ ] 验收靠"看实际命令 + 测试结果"，不是信它说"完成"
[ ] 定时/无人值守权限比人在时更紧，且提示词里有"只起草不发送"兜底
[ ] Memories / Skills 清过过期项

三个锦囊

模型名用变量，不焊死；会查当前模型的方法记牢（模型选择器 / codex --help / 官方清单）。
协议墙搞清：Assistants 2026-08-26 下线，Chat Completions 没 deprecated，别信错情报。
功能不是开越多越好，尤其屏幕抓取和凭证类，按自己边界定。

自测标尺（用命令验证）

[ ] 你跑过 grep -rn "gpt-5.4" 和 grep -rn "full-auto" 检查自己配置，确认没有写死。
[ ] 你能说出两颗时效炸弹（模型退役日期、Assistants 下线日期）且知道查当前模型的方法。
[ ] 你知道 Chronicle 类功能的隐私雷，且明白"功能不是开越多越好"。
[ ] 你跑过一次配置体检（codex status + 上面两条 grep）。

效率日志（七天总账）

天	任务	手动分钟	Codex+验收分钟	打回次数
D1	小函数	___	___	___
D2	安全档	___	___	___
D3	Skill	___	___	___
D4	验收任务	___	___	___
D5	场景	___	___	___
D6	定时	___	___	___
合计		___	___	___

把每天"手动分钟 − Codex分钟"加总，这就是你七天拿到的最硬成果——实打实省下的小时数。

写在最后

七天走完，你落下的是一套能长期用的协作纪律：管住它（审批×沙箱）、教会它（AGENTS.md+Skill+Memories）、放开它（验收闭环）、用起来（MCP+场景）、串成流（定时+无人值守）、常排雷（盯退役+协议墙）。

七天之后往哪走：先把本手册七天的"安全档 + AGENTS.md + 验收闭环"固化成你的日常习惯；再去看 OpenAI 官方 Best Practices / AGENTS.md 指南 / Skills 文档（developers.openai.com/codex），以及 awesome-codex-cli 社区合集，挑和你项目最贴的进阶玩法。

开篇：为什么是 Codex，为什么是七天 ​

title: "Day 1 · 跑起来：装上它，让它看见你的项目" description: "装好 CLI、登录账号，发出第一条指令，理解「会话」和「沙箱」。" course: codex order: 2 difficulty: 入门 duration: 15 分钟 lastUpdated: 2026-08-11 tags: ['安装', '登录', '沙箱'] ​

为什么先搭环境，而不是先调参 ​

两条入口路线，先定死一条 ​

路线 A：桌面端（图形界面工作的人） ​

路线 B：CLI（习惯终端、要写脚本/接 CI 的人） ​

怎么让 Codex"听懂"你的项目 ​

第一个任务：先用 Plan 模式，别让它直接改 ​

三个锦囊 ​

自测标尺（用命令验证，不是口头打勾） ​

效率日志（四列，今天起每天记） ​

title: "Day 2 · 管住它：给钥匙之前先看清边界" description: "读懂审批×沙箱两个正交维度，设出日常安全档，知道红区在哪。" course: codex order: 3 difficulty: 入门 duration: 18 分钟 lastUpdated: 2026-08-11 tags: ['权限', '审批', '安全'] ​

为什么"管住它"排第二天，而不是最后 ​

审批：它动手之前，要不要先问你 ​

沙箱：它跑的时候，被关在哪儿 ​

把两个维度拼成矩阵 ​

最阴的一种翻车：断网伪成功 ​

动手前先打 Git 检查点（防它改坏你能回滚） ​

把日常档写进配置（别每次手敲参数） ​

三个锦囊 ​

自测标尺（用命令验证） ​

效率日志 ​

title: "Day 3 · 教会它：把约定写成文本契约" description: "把约定写成文本契约，让 Codex 真的按你的规矩来。" course: codex order: 4 difficulty: 入门 duration: 20 分钟 lastUpdated: 2026-08-11 tags: ['AGENTS', '契约', '记忆'] ​

为什么"教会它"是个工程问题，不是聊天问题 ​

AGENTS.md：查找顺序与级联 ​

Skill：把重复操作打包成可复用手册 ​

今天就真建一个并跑起来 ​

Memories：让它自己记笔记 ​

三个锦囊 ​

自测标尺（用命令/文件验证） ​

效率日志 ​

title: "Day 4 · 放开它：让 Agent 自己证明做完了" description: "让 Agent 自己证明做完了，建立第一道验收意识。" course: codex order: 5 difficulty: 进阶 duration: 18 分钟 lastUpdated: 2026-08-11 tags: ['验收', '测试', '闭环'] ​

为什么"放手"不等于"不管" ​

一个你现在就能复现的实验（就知道为什么需要验收） ​

提示四要素：Goal / Context / Constraints / Done when ​

长任务怎么不失控：compact / 新 Thread / worktree 三选一 ​

验收闭环实操 + 代码评审 ​

三个锦囊 ​

自测标尺（用动作验证） ​

效率日志 ​

title: "Day 5 · 用起来：接工具、吃重复活、算清成本" description: "接工具、吃重复活、算清成本，把 Codex 当生产力。" course: codex order: 6 difficulty: 进阶 duration: 22 分钟 lastUpdated: 2026-08-11 tags: ['MCP', '工具', '成本'] ​

Codex 的稀缺价值在"造工具"和"吃重复活"，不在"代写内容" ​

接 MCP：让 Codex 能碰外部系统 ​

场景组：挑一个今天就能吃掉的重复活 ​

成本机制：钱到底烧在哪 ​

三个锦囊 ​

自测标尺（用动作验证） ​

效率日志 ​

title: "Day 6 · 串成工作流：定时、无人值守、高效用法" description: "定时、无人值守、把 Codex 串进你的工作流。" course: codex order: 7 difficulty: 进阶 duration: 25 分钟 lastUpdated: 2026-08-11 tags: ['工作流', '定时', '自动化'] ​

工作流的本质区别：人在不在场 ​

定时任务：RRULE 与外部触发 ​

心跳：让它定期主动向你汇报 ​

一个能直接抄的无人值守例子 ​

三个锦囊 ​

自测标尺（用动作验证） ​

效率日志 ​

title: "Day 7 · 复盘与排雷：盯住会变的，做次体检" description: "盯住会变的，做次体检，把经验沉淀成可复用资产。" course: codex order: 8 difficulty: 进阶 duration: 20 分钟 lastUpdated: 2026-08-11 tags: ['复盘', '排雷', '体检'] ​

第一性原理：你的配置建在"会变的东西"上 ​

炸弹一：模型退役红线 ​

炸弹二：协议墙（别搞反了） ​

炸弹三：Chronicle 隐私雷 ​

配置体检清单（今天做一遍，给真实命令） ​

三个锦囊 ​

自测标尺（用命令验证） ​

效率日志（七天总账） ​

写在最后 ​

开篇：为什么是 Codex，为什么是七天

title: "Day 1 · 跑起来：装上它，让它看见你的项目" description: "装好 CLI、登录账号，发出第一条指令，理解「会话」和「沙箱」。" course: codex order: 2 difficulty: 入门 duration: 15 分钟 lastUpdated: 2026-08-11 tags: ['安装', '登录', '沙箱']

为什么先搭环境，而不是先调参

两条入口路线，先定死一条

路线 A：桌面端（图形界面工作的人）

路线 B：CLI（习惯终端、要写脚本/接 CI 的人）

怎么让 Codex"听懂"你的项目

第一个任务：先用 Plan 模式，别让它直接改

三个锦囊

自测标尺（用命令验证，不是口头打勾）

效率日志（四列，今天起每天记）

title: "Day 2 · 管住它：给钥匙之前先看清边界" description: "读懂审批×沙箱两个正交维度，设出日常安全档，知道红区在哪。" course: codex order: 3 difficulty: 入门 duration: 18 分钟 lastUpdated: 2026-08-11 tags: ['权限', '审批', '安全']

为什么"管住它"排第二天，而不是最后

审批：它动手之前，要不要先问你

沙箱：它跑的时候，被关在哪儿

把两个维度拼成矩阵

最阴的一种翻车：断网伪成功

动手前先打 Git 检查点（防它改坏你能回滚）

把日常档写进配置（别每次手敲参数）

三个锦囊

自测标尺（用命令验证）

效率日志

title: "Day 3 · 教会它：把约定写成文本契约" description: "把约定写成文本契约，让 Codex 真的按你的规矩来。" course: codex order: 4 difficulty: 入门 duration: 20 分钟 lastUpdated: 2026-08-11 tags: ['AGENTS', '契约', '记忆']

为什么"教会它"是个工程问题，不是聊天问题

AGENTS.md：查找顺序与级联

Skill：把重复操作打包成可复用手册

今天就真建一个并跑起来

Memories：让它自己记笔记

三个锦囊

自测标尺（用命令/文件验证）

效率日志

title: "Day 4 · 放开它：让 Agent 自己证明做完了" description: "让 Agent 自己证明做完了，建立第一道验收意识。" course: codex order: 5 difficulty: 进阶 duration: 18 分钟 lastUpdated: 2026-08-11 tags: ['验收', '测试', '闭环']

为什么"放手"不等于"不管"

一个你现在就能复现的实验（就知道为什么需要验收）

提示四要素：Goal / Context / Constraints / Done when

长任务怎么不失控：compact / 新 Thread / worktree 三选一

验收闭环实操 + 代码评审

三个锦囊

自测标尺（用动作验证）

效率日志

title: "Day 5 · 用起来：接工具、吃重复活、算清成本" description: "接工具、吃重复活、算清成本，把 Codex 当生产力。" course: codex order: 6 difficulty: 进阶 duration: 22 分钟 lastUpdated: 2026-08-11 tags: ['MCP', '工具', '成本']

Codex 的稀缺价值在"造工具"和"吃重复活"，不在"代写内容"

接 MCP：让 Codex 能碰外部系统

场景组：挑一个今天就能吃掉的重复活

成本机制：钱到底烧在哪

三个锦囊

自测标尺（用动作验证）

效率日志

title: "Day 6 · 串成工作流：定时、无人值守、高效用法" description: "定时、无人值守、把 Codex 串进你的工作流。" course: codex order: 7 difficulty: 进阶 duration: 25 分钟 lastUpdated: 2026-08-11 tags: ['工作流', '定时', '自动化']

工作流的本质区别：人在不在场

定时任务：RRULE 与外部触发

心跳：让它定期主动向你汇报

一个能直接抄的无人值守例子

三个锦囊

自测标尺（用动作验证）

效率日志

title: "Day 7 · 复盘与排雷：盯住会变的，做次体检" description: "盯住会变的，做次体检，把经验沉淀成可复用资产。" course: codex order: 8 difficulty: 进阶 duration: 20 分钟 lastUpdated: 2026-08-11 tags: ['复盘', '排雷', '体检']

第一性原理：你的配置建在"会变的东西"上

炸弹一：模型退役红线

炸弹二：协议墙（别搞反了）

炸弹三：Chronicle 隐私雷

配置体检清单（今天做一遍，给真实命令）

三个锦囊

自测标尺（用命令验证）

效率日志（七天总账）

写在最后