让 Codex 连干几天大项目不跑偏：OpenAI 工程师的 5 个协作习惯

AI 能连干几天了，难的是别跑偏

AI 现在能连着干好几个小时、甚至好几天了。难的其实不是让它「开始」，而是让它在干几天、不断发现新情况、来回验证的过程中——别跑偏。

OpenAI Codex 团队的工程师 Gabriel Chua，把自己摸索出的一套协作法则写成了文章《Collaborating with Codex on Long-Running Tasks》，89 万人看过。5 个习惯，把「放养一个 AI」变成「带一个 AI 团队」。这套方法不只对 Codex 适用——只要你在用能跑长任务、能开子 agent 的编码工具，逻辑都能搬。

全景：主线程协调，worker 干活

先说要解决的难题：Codex 能长时间干活，尤其是当 /goal 给了它一个持久目标之后。但麻烦在于——一开工，早期的假设往往就会变。所以理想的协作方式，要既守住目标，又给人和 Codex 都留出「根据新证据改计划」的空间。

全景结构：远程 SSH 环境里，主线程只做协调，把活委派给一群 worker；GOALS.md 存里程碑与证据；每个里程碑后过「质量关卡」（审计 + /review）；需要本机的检查交给本地线程；进度经 Slack 和仪表盘同步。

习惯一：让 Codex 自己规划，并维护路线图

他不用 /plan 模式开局，而是先聊。先描述想做什么、把粗糙的想法口述出来、给出约束，然后让 Codex 一直提问，直到它上下文够了、能提出初版计划为止。

项目成形后，让 Codex 设定当前的 Goal（目标）。Goal 模式给 Codex 一个持久目标，让它跨多轮朝同一个结果推进，直到目标完成、受阻、或被替换。更大的项目，把大路线图写进一个 GOALS.md（项目约定，不是内置功能），按里程碑组织而不是平铺的任务清单。每个里程碑记录：

想要的产出
当前范围内的工作
重要决策
已知的阻塞
进入下一步所需的证据

Codex 随项目推进不断维护它——新发现可能改变某个里程碑的范围、加出新里程碑、或改变「完成所需的证据」。同一时刻只有一个 Goal 活跃。

习惯二：主线程只管协调，别陷进实现细节

路线图有了之后，主线程只聚焦四件事：目标、约束、决策、当前项目状态。主线程负责决定下一步做什么、把有边界的任务委派出去、评估结果——它不需要背负每一个实现细节。

打个比方：一个 worker 可能花一小时读陌生代码、试好几种方案、修一个总失败的测试。但协调者只需要知道：这个 worker 学到了什么、改动了什么、支撑的证据、接下来该干什么。

Codex 既可以把活委派给 subagent，也可以另开独立 thread。他的取舍：如果之后可能想回头查看这块工作，就用独立 thread（有自己的历史，一直显示在 Codex app 里）——几块工作并行跑起来时尤其香，每处调查、实现、审查都单独可查。

习惯三：每个里程碑做完，先审路线图，再 review 代码

GOALS.md 反映的是 Codex 上一次更新时的认知。而一个里程碑干完，项目通常又冒出了新东西。所以在往下走之前，他会让另一个 thread 把路线图和现状对照着审一遍：

这个里程碑真的完成了吗？
下一个目标还是对的吗？
有没有漏掉的里程碑？
新证据是否改变了工作顺序？
「完成」的定义还成立吗？

他举了个例子：登录流程的实现在远程测试都做完了，路线图审计发现——根本没人在真正登录了的浏览器里测过这个流程；同时 /review 发现新代码把 token 存错了（尽管远程测试全过）。于是协调者更新 GOALS.md、委派人去修 token、补上缺失的浏览器验证，然后才激活下一个里程碑。

习惯四：需要本机的测试，交给「本地线程」

大部分 Codex session 跑在远程实例上，合上笔记本活儿也能继续。但有些检查绕不开本机：登录态的浏览器、本地凭据、Xcode、macOS 权限、iOS 模拟器。

远程协调者可以创建本地线程做这些检查：把远程的 diff 应用过来、checkout 到对应分支/commit，让本地线程测那份正确的代码。本地线程操作浏览器或应用，回传截图、日志和结论；一旦某项没过，就让远程 worker 去修，本地线程再测一遍。

典型循环：远程 worker 实现登录流 → 远程测试通过 → 本地线程用 Codex 的 Chrome 扩展跑 → 浏览器测出重定向 bug → 远程 worker 修掉 → 本地线程再测。项目默认在远程，电脑只在「必须它出场」的检查时才加入。

习惯五：用简报和仪表盘同步进度

每个 worker 线程通常只汇报一件事。回到项目时，需要的是全局视图。所以他让 Codex 在项目状态一有变化时，用三段极短的话汇报：

What’s done（已完成）
What’s next（下一步）
Any blockers（有无阻塞）

用他的话说，这几乎就是在和 Codex 开每日站会——只不过每小时一次。这份更新还能同步发到 Slack。跨多个里程碑或并行项目时，维护一个 progress-dashboard.html，显示当前活跃目标、已完成里程碑、证据、阻塞、决策、近期更新，还能部署成网站随时远程看。

什么时候值得这么干

这套结构不是每个小任务都要上：当一个项目很可能不断冒出新信息、涉及好几块独立工作、或需要来自多个环境的证据时，才值得这么拱。

整个工作流就是一个简单循环：Codex 把最初的对话变成路线图 → 激活一个里程碑 → 把活委派出去 → 验收结果，然后才往下走。核心只有一句：让「项目状态」始终足够新，好让下一个决策，反映的是 Codex 真正已经学到的东西。

上手：直接抄作业

第一种，把一段「长期项目协调」提示词粘进新的 Codex 会话（访谈 → GOALS.md → 里程碑 → 主线程协调 → worker 委派 → 里程碑审计 + /review → 本地线程 → 简报 → dashboard → 证据验收）。

第二种更省事：对着这篇文章截个图，让 Codex 「把这篇做成一个可复用的 skill，名叫 orchestrate-projects」，把这些习惯固化下来，以后一句话就能调起来。

说到底：你从「写代码的人」，变成「带 AI 团队的人」

这套东西表面是 Codex 使用技巧，本质是 AI 时代的项目管理。真正让 AI 干长活还不翻车的，不是某个更强的模型，而是三个很朴素的关键词：目标（Goal）、证据（Evidence）、状态（State）。

用一个持久的 Goal 和一份 GOALS.md，给 AI 一个不会随上下文漂走的「锚」
用「完成所需的证据」和里程碑后的审计 + review，给它设一道道验收关卡
用简报和仪表盘，把项目状态外置成随时可读的东西，而不是塞在某个线程的上下文里

你的角色正在从「那个写代码的人」，变成「带一个 AI 团队的 tech lead」——定目标、拆里程碑、派活、验收、管状态。

⚠️ 别照单全收：作者是 OpenAI 的人，写的是个人实践，不是官方定论；文中不少是 Codex 专有能力（/goal、/side、本地/远程线程、Codex app、部署成 Site），换成 Claude Code、Cursor 或国产工具得先找对应物——但「GOALS.md + 里程碑验收 + 远程/本地分工 + 状态外置」这套骨架是通用的。

原文：Gabriel Chua（OpenAI Codex DX Engineer）· Codex 开源仓库