他们每天怎么用 Codex#

每天到办公室的流程挺有意思的：

1. 打开 4 个 Codex 实例：1 个 VSCode 插件 + 1 个 Desktop 客户端 + 2 个终端
2. Desktop 里跟 Codex 对齐需求、拆任务、充分讨论
3. 终端 A 开 plan 模式执行
4. 终端 B /review + VSCode 插件用定制 prompt review
5. 审查通过 → push → PR

4 个实例分工明确，各管一摊。Desktop 讨论，终端执行，插件追踪。

两个让我印象深刻的点#

① “plan 模式几乎直接执行”

他们在 Desktop 里把需求讨论透了，生成一套 prompt 丢给终端 A。终端 A 的 plan 展开后几乎直接执行，有时候甚至不看就放行。

这意味着什么？规划的质量直接决定了执行的质量。不是 Codex 不需要监督，而是监督前置了——在 Desktop 讨论阶段就已经完成了 review。

② 双视角 review

终端 B 的 /review 偏语法和逻辑，机械但稳定。VSCode 插件用定制 prompt review，偏架构和一致性。两个都跑一遍交叉验证。

单一的 review 视角肯定有盲区。一个查语法，一个查架构，互补。

“所有问题都问 Codex”这个原则#

分享里提到一个原则：不自己搜，不自己猜，所有问题直接问 Codex。

编译报错 → 贴给 Codex，秒解。业务疑问 → 贴给 Codex，结合上下文分析。技术选型不确定 → 让 Codex 列优缺点，自己做决策。

这背后的前提是：你得能判断 Codex 给的答案靠不靠谱。它不是替代判断力，是放大判断力。越会用的人，越能判断。

核心启发#

这套工作流的本质是 把人的角色从”写代码”转变为”审代码”。规划阶段花时间充分思考，执行阶段交给 AI 高速推进，最后用多维度 review 兜底。

代码从不手写，但大脑从不放假。