进阶工作流：从"码农"变成"任务设计师"

很多人第一次用 Codex，都是这样开始的：打开一个项目，丢一句话进去——"帮我修这个 bug""帮我写个页面""帮我跑一下测试"。这当然没错，Codex 本来就是从写代码、改代码、跑命令这条路长出来的。

但如果你只把它当成一个"会写代码的聊天框"，就有点可惜了。以下内容来自 @ChrisWangwy 的 10 步工作流方法论（X，2026-05-28），@0xshimei 的 12 个进阶玩法（X，2026-05-16）补实战招式，@jxnlco 的英文原版长文（X，2026-05-21）补心智模型。三篇有重叠的概念只讲一次。

核心观点一句话：Codex 的重心仍是代码，但电脑工作大多已由代码中介——执行命令、浏览网页、调用 API、导出文档、响应事件、触发自动化。把这些能力组合起来，Codex 就从"窄义代码助手"变成"搞定计算机工作的系统"。

以下来自 @ChrisWangwy：别每任务都新开对话。长期项目 = 每天换新同事，每个新对话都要重新讲一遍背景。正确做法是建 3 个长期工位：①改代码/跑测试/看 diff ②README/教程/草稿 ③收件箱/待办/摘要。

@jxnlco 把这个概念叫 durable threads（耐久线程）：跨多次会话保存工作上下文的长期线程，而不是每轮重置。可以固定（pinned）高频工作流，比如 Chief of Staff 线程、发布线程、文档评审线程、外部监控线程。快捷键 Command-1 到 Command-9 直接跳转已保存的线程。

新手最小动作——今天就建一个，把这段发给 Codex（来自 @ChrisWangwy，可复制）：

复制这个线程作为长期使用。

每次开始任务前，请先复述：
1. 当前目标；
2. 你能改的范围；
3. 不能碰的文件或动作；
4. 你准备怎么验证。

每次完成任务后，请输出：
1. 改动摘要；
2. 验证命令和结果；
3. 风险点；
4. 需要我确认的下一步。

涉及密码、付款、删除、上传、外部消息发送、生产环境操作时，必须先停下来问我。

这段不复杂，但用上以后，Codex 不再只是"你说一句它答一句"，而是像一个有工位、有规矩、有验收标准的长期工作伙伴。

以下来自 @ChrisWangwy：让 Codex 动手前，先让它看现场。Appshots 交当前应用窗口（截图+可读文字）、浏览器工具看网页渲染、Computer Use 在 Mac 上点击输入滚动。新手先别让它操作，先让它复述——可复制提示词：

复制请先看当前窗口，不要点击、不要输入、不要修改任何内容。
请只做三件事：
1. 复述你看到了哪些主要区域；
2. 指出你认为最可能有问题的 3 个地方；
3. 告诉我下一步如果要检查，应该点哪里，但先不要点。

来自 @jxnlco 的补充：语音输入适合捕捉未经压缩的粗糙想法——难以打字表达的模糊起点（比如"我记得有人在 Slack 提过这事，细节忘了，你去查查"），或任务成型前 2–3 分钟的思维倾倒。原始会议记录、口述计划比精炼摘要更好，因为保留了不确定性、强调和未说完的话。

以下综合 @ChrisWangwy 与 @jxnlco（两人讲的是同一对概念，英文原版区分更精确）：

Steering（引导/方向盘）管"现在别跑偏"——在当前步骤完成前中断在跑的任务，给出新方向。比如网站评审时在侧边栏标注"make this smaller""this copy is wrong"。@0xshimei 的独家小细节：对话框输入新指令后按 Ctrl+Enter（普通 Enter 会进队列排队），AI 立刻停下当前思路按新方向走，省掉跑完再推翻的 10 分钟 + token 浪费。

Queuing（排队）管"下一步别忘"——不中断当前任务，把下一个任务加进队列（"做完后把预览链接发给 Slack 里的评审人"）。一句话区分：steer 改变现在做什么，queue 改变接下来做什么。

以下来自 @ChrisWangwy："帮我优化登录流程"是许愿，交活的写法是给完成标准。写 /goal 记住 4 词：目标 / 范围 / 验收 / 停止。示例：

复制/goal 让登录流程对新用户稳定可用。
范围：只检查登录、注册、找回密码；不重构用户系统；不改数据库结构。
完成标准：新增/修复必要测试；本地主流程通过；失败状态有明确提示；输出改动摘要和剩余风险。
暂停条件：需删数据/改生产配置/输入密码密钥付款信息。

来自 @jxnlco 的心智模型：目标 = 持续执行 + 验证器（verifier）。弱目标："按这个 Markdown 里的计划实现"。强目标：带可测量的成功标准，比如"单元测试全过"。有用的验证器包括：测试套件、基准（benchmark）、bug 复现、验证矩阵、必须持续通过的端到端流程。没有验证的野心只是愿望。

Goal 的完整机制（三重防护、Ralph Loop、源码拆解）是下一课《Goal 模式》的主题，这里先掌握写法即可。

以下来自 @ChrisWangwy：如果你有一段提示词已经复制过 3 次，就该做成 Skill。很多人以为 Skill 是插件，其实更像一张"标准作业卡"——让 Agent 每次按同一套流程干活，少一点随机发挥。

比如你经常让 Codex 做文章审查，每次都要说"请检查这篇文章是不是太空，标题有没有痛点……不要只夸优点，要指出可改的地方，最后给我一个改稿清单"。这段每次复制迟早会漏。可以让 Codex 帮你写一个最小版（可复制）：

复制请把我刚才这套文章审查流程整理成一个 Skill。

要求：
1. 触发场景写清楚；
2. 执行步骤写成编号；
3. 禁止事项写明；
4. 输出格式固定成：问题 / 原因 / 修改建议 / 可复制示例。

来自 @0xshimei 的补充——Skill 三种来源：A. 官方（插件市场装，比如 Remotion 让 AI 用代码画 3D 动画视频）；B. 第三方（GitHub 下载 zip → 项目根目录建 .codex/skills/ → 解压进去 → Codex 里用 / 调用）；C. 自己创建（调用内置 skill-creator，描述你的重复工作，自动生成 Skill 文档）。作者自用案例：视频+字幕→Markdown 笔记，配图处打 [SCREENSHOT] 标记，ffmpeg 自动截图替换，5 分钟出图文教程。

以下来自 @ChrisWangwy：哪些文件不能动？测试命令是什么？提交前必须跑什么？这些不要每次靠嘴说，写进项目规则 AGENTS.md。一个最小模板长这样（可复制）：

复制# 项目规则

## 常用命令
- 安装依赖：npm install
- 本地启动：npm run dev
- 最小测试：npm test -- --runInBand

## 修改边界
- 不要改数据库 schema；
- 不要删除用户数据；
- 不要修改.env 和密钥文件；
- 大改动前先输出计划。

## 完成要求
- 每次改完先看 git diff；
- 能跑测试就跑最小相关测试；
- 输出改动摘要、验证结果、风险点。

## 必须暂停
- 需要付款；
- 需要登录新账号；
- 需要发送外部消息；
- 需要删除文件或数据。

这不是给 AI 写作文，这是给它贴一张办公室规章制度。

来自 @0xshimei 的双层记忆：项目级 Agent.md + 全局 Agent.md（设置→个性化→自定义指令）。必写的安全约束示例：禁止用脚本批量删除文件，只能逐个删除，批量删除必须停下让用户手动确认——作者曾被一条删除命令清空整个项目目录，痛失三天工作量。

来自 @jxnlco 的共享记忆（shared memory）模式：把长期上下文放在对话之外、显式可审查的地方。推荐把持久线程锚定在一个 Obsidian vault（纯文本文件夹，易检查、易编辑、易迁移），可放云存储/Git/Dropbox 同步。示例结构 vault/ 下分 TODO.md、people/、projects/、agent/、notes/，顶层 AGENTS.md 规定 Codex 如何更新工作区。另有官方记忆功能：设置 → 个性化 → Memories，以及 Chronicle（从近期屏幕上下文帮 Codex 建记忆）。

以下来自 @ChrisWangwy：Automations 适合三特点的任务——固定时间出现、输入来源稳定、结果需要你审一眼。更稳的做法是输出"待审结果"而非替你拍板。示例：每天上午 9 点检查 issue 和失败测试，只整理归类不改代码，输出最紧急 3 件事 + 证据链接 + 建议下一步 + 需确认处。

来自 @jxnlco 的升级版：thread automation（线程自动化）是心跳式周期唤醒，回到同一线程、带着运行上下文继续。实战：Chief of Staff 线程每 30 分钟检查 Slack 和 Gmail 的未答复消息，帮你排优先级、深挖答案、起草回复但不发送（人来决定发什么）。@0xshimei 的版本更进一步：AI 每次执行的经验自动写入 memory.md，下次复用，相当于自我进化的定时机器人。

质量门要前置（@ChrisWangwy）：Agent 的总结不是证据，真正的证据是 diff、测试、截图、日志。以后每次让 Codex 改东西，最后加这一段（可复制）：

复制完成后请先过 5 道质量门：

1. 列出 git diff 中真正改动的文件；
2. 说明每个改动为什么必要；
3. 跑最小相关测试，并贴出命令和结果；
4. 检查是否改了依赖、密钥、权限、删除逻辑；
5. 给出剩余风险和需要人工确认的地方。

不要只写"已完成"。

人的角色变了：从"遥控器"（做这一步、再做下一步、这里错了）变成"小项目负责人"——目标是什么、边界在哪里、看到什么现场、允许用哪些工具、成功怎么验收、什么时候必须停。