https://codexer.com/tags/plan-%E6%A8%A1%E5%BC%8F/Recent content in Plan 模式 on CodexerHugozh-cnMon, 21 Sep 2026 08:06:00 +0800https://codexer.com/posts/2026-09-21-codex-goal-mode-24-hour-lesson/Mon, 21 Sep 2026 08:06:00 +0800https://codexer.com/posts/2026-09-21-codex-goal-mode-24-hour-lesson/<p>周五下午，你给编程 agent 留下一段雄心勃勃的指令：把项目迁到最新版本，顺便让代码符合最佳实践。你合上笔记本回家。周一早上打开屏幕，它还在跑，日志几千行，改了四十多个文件。</p> <p>然后你花掉整个上午读 diff，发现里面有一半是你根本不想要的东西，而且你还不太确定剩下那一半为什么这么写。</p> <p>这不是 agent 的能力问题，而是我们把「跑得久」和「做得好」这两件事混为一谈了。开发者 Flavio Copes 在九月中旬更新了一份他日常使用 Codex 的完整记录，里面有段实验特别值得拿来讲：他让 Codex 在 Goal 模式下，用两套不同的技术栈把 PocketBase 各重造一遍。任务连续跑了超过 24 小时，两个原型都相当能看。但他最后给出的结论偏向反直觉：</p> <blockquote> <p>我更愿意把这笔预算，花在十个能逐个审阅的小任务上。</p> </blockquote> <p>这句话背后不是情绪，而是一套关于可观测性和返工成本的判断。</p> <h2 id="24-小时的产出卡在哪一步">24 小时的产出，卡在哪一步</h2> <p>先承认一件事：那 24 小时没白跑。两套技术栈、一个完整后端，从数据模型到接口都立起来了，这是几年前不可想象的产出密度。</p> <p>问题出在他接下来要做的事上。原型「能看」和原型「能用」之间隔着一段很长的路，而那段路上的每一处修补，都要求你先理解它当初为什么那样写。模型跑得越久，它自己做的产品决策就越多，而这些决策没有留下任何可讨论的记录，只留下一堆代码。于是阅读成本全部压回到你身上。</p> <p>更微妙的是时间尺度的错配。agent 用 24 小时产出了一整套系统，你用 4 个小时读它，其中 3 个小时在判断「这个设计到底是不是我想要的」。当审查成本接近甚至超过重写成本时，自动化带来的收益就被吃掉了。</p> <p>还有一个更隐蔽的坑，来自他那个做多页漫画的小项目。第一版提示词写得很细，角色、故事、分镜、导出、本地存储全都列了。可第一轮生成的软件「确实很多，但不是他脑子里那个产品」。原因很朴素：提示词里的某些产品判断本身就是错的，而错误的判断只有在真正用起来之后才会暴露。你没用过它，就不知道哪条需求写漏了。</p> <p>这三件事指向同一个结论：<strong>长跑任务最大的成本不在生成，而在理解。</strong></p> <h2 id="他的替代方案一次只给一个连贯的结果">他的替代方案：一次只给一个连贯的结果</h2> <p>Copes 把自己稳定下来后的循环写成了十个步骤，核心是一句话：一次只交给 Codex 一个「连贯的结果」（one coherent outcome）。修认证就在同一个会话里把认证修到能测、能改、能收敛；顺手要更新一个无关的依赖，就另开一个会话。</p> <p>具体的循环大致是：</p> <ul> <li>打开正确的项目，先让它读代码，不改任何东西</li> <li>任务跨多个文件或者决策不清楚时，走 Plan 模式拿一份计划</li> <li>认真读那份计划，把它当成代码来审</li> <li>让它实现一个连贯的结果</li> <li>让它自己跑测试和构建</li> <li>在浏览器或应用里亲自验证行为</li> <li>读完整个 diff</li> <li>再要一次收尾审查</li> <li>确认自己理解了结果，才提交和推送</li> </ul> <p>这套流程没有一处依赖 Codex 的独有功能。真正起作用的是两条约束：范围要小到你能记住，结果要可验证到你能反驳。</p> <h2 id="plan-模式和-goal-模式分工完全不同">Plan 模式和 Goal 模式，分工完全不同</h2> <p>很多人把这两个模式当成「更谨慎」和「更激进」的档位，其实它们解决的是两个不相干的问题。</p> <p>Plan 模式回答的是「这件事该怎么做」。Codex 只读项目、不改文件，然后给出一份方案，并问你要不要执行。Copes 的建议是要不要用 Plan，看四个信号：你不确定怎么实现、改动跨了好几个模块、顺序很重要、一个错误假设的代价很高。四个里中一个就值得先要计划。反过来，那些一眼就明白的小改动，走 Plan 模式纯属浪费。</p>