周五下午，你给编程 agent 留下一段雄心勃勃的指令：把项目迁到最新版本，顺便让代码符合最佳实践。你合上笔记本回家。周一早上打开屏幕，它还在跑，日志几千行，改了四十多个文件。

然后你花掉整个上午读 diff，发现里面有一半是你根本不想要的东西，而且你还不太确定剩下那一半为什么这么写。

这不是 agent 的能力问题，而是我们把「跑得久」和「做得好」这两件事混为一谈了。开发者 Flavio Copes 在九月中旬更新了一份他日常使用 Codex 的完整记录，里面有段实验特别值得拿来讲：他让 Codex 在 Goal 模式下，用两套不同的技术栈把 PocketBase 各重造一遍。任务连续跑了超过 24 小时，两个原型都相当能看。但他最后给出的结论偏向反直觉：

我更愿意把这笔预算，花在十个能逐个审阅的小任务上。

这句话背后不是情绪，而是一套关于可观测性和返工成本的判断。

24 小时的产出，卡在哪一步#

先承认一件事：那 24 小时没白跑。两套技术栈、一个完整后端，从数据模型到接口都立起来了，这是几年前不可想象的产出密度。

问题出在他接下来要做的事上。原型「能看」和原型「能用」之间隔着一段很长的路，而那段路上的每一处修补，都要求你先理解它当初为什么那样写。模型跑得越久，它自己做的产品决策就越多，而这些决策没有留下任何可讨论的记录，只留下一堆代码。于是阅读成本全部压回到你身上。

更微妙的是时间尺度的错配。agent 用 24 小时产出了一整套系统，你用 4 个小时读它，其中 3 个小时在判断「这个设计到底是不是我想要的」。当审查成本接近甚至超过重写成本时，自动化带来的收益就被吃掉了。

还有一个更隐蔽的坑，来自他那个做多页漫画的小项目。第一版提示词写得很细，角色、故事、分镜、导出、本地存储全都列了。可第一轮生成的软件「确实很多，但不是他脑子里那个产品」。原因很朴素：提示词里的某些产品判断本身就是错的，而错误的判断只有在真正用起来之后才会暴露。你没用过它，就不知道哪条需求写漏了。

这三件事指向同一个结论：长跑任务最大的成本不在生成，而在理解。

他的替代方案：一次只给一个连贯的结果#

Copes 把自己稳定下来后的循环写成了十个步骤，核心是一句话：一次只交给 Codex 一个「连贯的结果」（one coherent outcome）。修认证就在同一个会话里把认证修到能测、能改、能收敛；顺手要更新一个无关的依赖，就另开一个会话。

具体的循环大致是：

  • 打开正确的项目，先让它读代码，不改任何东西
  • 任务跨多个文件或者决策不清楚时，走 Plan 模式拿一份计划
  • 认真读那份计划，把它当成代码来审
  • 让它实现一个连贯的结果
  • 让它自己跑测试和构建
  • 在浏览器或应用里亲自验证行为
  • 读完整个 diff
  • 再要一次收尾审查
  • 确认自己理解了结果，才提交和推送

这套流程没有一处依赖 Codex 的独有功能。真正起作用的是两条约束：范围要小到你能记住，结果要可验证到你能反驳。

Plan 模式和 Goal 模式，分工完全不同#

很多人把这两个模式当成「更谨慎」和「更激进」的档位，其实它们解决的是两个不相干的问题。

Plan 模式回答的是「这件事该怎么做」。Codex 只读项目、不改文件，然后给出一份方案，并问你要不要执行。Copes 的建议是要不要用 Plan，看四个信号：你不确定怎么实现、改动跨了好几个模块、顺序很重要、一个错误假设的代价很高。四个里中一个就值得先要计划。反过来，那些一眼就明白的小改动，走 Plan 模式纯属浪费。

他的一个习惯值得抄：读计划时的认真程度要和读代码一样。因为所有错误的架构决定，都还没来得及写进文件。

Goal 模式回答的是另一个问题：「让它一直朝这个结果跑下去」。你把目标、约束和验收方式写进去，它可以暂停、恢复、修改。听起来更强大，但它的适用条件苛刻得多：终点必须精确到 Codex 自己能判断什么时候算完成。 「迁移到最新版 Astro 并符合最佳实践」这种目标，终点是模糊的，模糊的终点意味着它会自己做无数个决定，而这些决定你事后要一个个拆开检查。

Copes 的选择很明确：一件一件做，然后审阅。只有终点足够精确的时候，才动用长跑。

让失败变得可见，比让代码变正确更优先#

他那个漫画项目里有一个细节，我认为比整份指南的技术配置都更有价值。

图像生成偶尔会静默失败。他没有先让 Codex 去改 API 调用，而是先加进度提示和错误消息，让失败在应用界面和日志里显形。等失败看得见了，再动手修接口。他的原话意思是，先让失败可见，然后才可能知道要修什么。

这条原则在任何 agent 工作流里都成立。agent 最危险的状态不是「写错」，而是「安静地没做成」：它说完成了，测试没跑，界面没渲染，接口返回 500 被吞掉，而你以为只是慢。所以在派活之前，先想清楚一件事：如果这次任务失败，我是从哪个信号知道的？如果你想不出这个信号，那这个任务还不该交给它跑。

这一点和我们之前聊过的另一个话题是同一件事的两面：有工程师在六百人规模里只关心「改动能不能被看懂、被审查」。可观测性是那套方法论的地基。看不见的改动即无法审查的改动。

磁盘只剩 1% 的时候，他选择自己敲命令#

整份记录里最有现场感的，是他处理一次生产事故的过程。

某个早上他醒来收到一封怒气冲冲的邮件：newsletter 的退订链接坏了，整个服务器宕机，磁盘占用 99%。这台机器离满盘只差一步。

他本可以给 Codex 开 SSH 权限。他没那么做。理由很直接：这是一台几乎没有剩余空间的生产服务器，每一条命令他都想亲眼看到。于是他变成了人和 agent 之间的中继：自己敲 df -h，把输出粘回去，Codex 建议下一条安全的排查动作，他执行，再粘回去。

顺着这个循环查下去，结论是 Sendy 的数据库只用了 528 MB，而 MySQL 的 binlog 吃掉了大约 41 GB。Codex 还给出了一条重要提醒：不要手工去 rm /var/lib/mysql 里的文件。它给了清理旧 binlog 的 SQL 命令，磁盘从 99% 回到 41%。

这段故事的价值不在「AI 救了服务器」，而在权限的粒度选择。他没有在「全权交给 agent」和「完全不交给 agent」之间二选一，而是把 agent 放在顾问的位置上，把所有破坏性动作留在自己手里。排障这类任务最适合让 agent 快速收敛假设，但最不适合让它直接执行。 你按一条命令的成本，远低于回滚一次误删的成本。

子 agent 的真正用途：隔离噪音，不是提速#

关于子 agent，Copes 给了一个和主流叙事不一样的定义。他说用它们的主要理由不是更快，而是很长的一段会话会被探索笔记、测试日志和堆栈跟踪填满，噪音越堆越多，模型在关键决策上的表现就越差。子 agent 把这些噪音关进各自的线程，只把摘要交回来。

这句话解释了很多人遇到的怪现象：同一个模型，会话前半段的判断很准，跑了几个小时后开始做傻事。换个说法，上下文窗口的容量不是问题，内容质量才是。

所以他的用法也很克制：子 agent 适合读密集型的工作，探索、测试、分类、审查；不适合几个 agent 同时写代码，因为它们会互相踩到对方的改动。而且每个子 agent 都独立消耗模型和工具的额度，整个任务的总 token 会比单 agent 更贵。

还有个容易踩的细节：子 agent 继承父会话的权限模式。所以要在派活之前把权限设好，而不是派出去之后再想办法收回来。

他自己不喜欢 Codex 的四处#

一份可信的评测必须包含反面意见。Copes 列了四条，我按重要性重排：

第一，Goal 模式的产出配不上它的诱惑力。24 小时换来两个仍需大量手工返工的原型，他认为同样的额度换成十个能做细的任务更划算。

第二，定时任务依赖你的电脑醒着。本地项目上的定时任务需要机器开着、应用在跑。设了早上七点的任务，笔记本合上就等于没设。真要保证跑，他还是用服务器上的 cron 或者 GitHub Actions。这一条对把「自动化」当卖点的人来说，是个很实际的限制。

第三，内置浏览器不认识你的登录态。它有自己的 profile，Google 登录的页面得在里面重登一次。要用真实登录态，就得装浏览器扩展去驱动你自己的 Chrome，代价是这个扩展能读改你访问的所有网站。

第四，命名混乱。应用叫 ChatGPT，Codex 是其中一个模式，文档里又常常把 ChatGPT Work 和 Codex 混着写，读的时候要花时间判断这句话到底适不适用于你。

值得带走的三点#

如果只留三句话，我会留这三句。

第一，把「一次一个连贯结果」当成默认，把长跑当成例外。 长跑不是更高级的用法，而是只在终点精确时才划算的一种赌注。

第二，先让失败可见，再让它正确。 派活之前问自己，失败时我从哪个信号知道。答不上来就别派。

第三，把 agent 放在它最擅长的那一半。 收敛假设、压缩噪音、批量执行，这些交出去；破坏性动作、权限边界、最终判断，留在自己手里。

Copes 在文末说，他从 Cursor、Claude Code 和 Codex 身上学到的东西其实是一样的：提示词的写法、审查的习惯、一次一件事的节奏，在哪里都通用。工具之间的差别只在于 agent 在哪里跑、能看到什么。

这句话我很认同。模型每几个月换一版，而真正决定产出质量的，是你给它划的那条边界。边界划得好，24 小时和十分钟都能派上用场；边界划不好，跑得越久，你需要读的东西就越多。

参考来源：Flavio Copes, The complete guide to Codex（2026 年 9 月 15 日更新），https://flaviocopes.com/codex/ 。文中实验、事故排查过程与作者观点均来自该文，分析部分为本文作者的解读。