夜雨聆风同一个项目里，Codex App 可以继续当前线程，可以开始新对话，可以派生到本地，也可以派生到新工作树，还能让 Subagents 并行查问题。
这几个入口都是「让 Codex 继续干活」，但实际的体感差别很大。
像我之前用 Codex 并不是很趁手，就是因为任务一多，先把自己搞乱了：一个线程在修 bug，一个线程在重构，一个线程又从头扫项目，另一个工作树里跑了一半测试，最后结果肯定是不如预期。
核心问题就一个：在当前项目里，什么时候留在当前线程，什么时候开始新对话，什么时候派生到本地，什么时候派生到新工作树，什么时候用 Subagent workflows。
- • 同一个问题还在推进 → 继续当前线程
- • 想试另一条路线，但还要继承前面的判断 → 用派生
- • 怕把当前项目改乱 → 用新工作树
- • 想让 Codex 忘掉前面的判断，重新看一遍 → 用新对话
- • 信息太多，需要分头查证 → 用 Subagents
这句话记住，Codex App 的线程就没那么乱了。
先判断任务有没有「换路」，不要急着点按钮
Codex App 里的很多混乱，来自一个很小的误判：问题还没变，却开了新对话；方向已经分叉，却还在主线程里盲目的继续。
比如一个项目 npm run build 报错。Codex 已经查过依赖版本、Node 版本、环境变量，最后怀疑是 tsconfig 和路径别名冲突。这个时候继续当前线程最合适，因为它已经知道哪些原因被排除，哪些文件已经看过，哪些方案试过但没有效果。
技术排障最怕丢掉中间过程。
一个新对话虽然也能看到同一个项目，但它不知道前面半小时发生了什么。它就像刚被拉进事故群的新同事——电脑是同一台，代码是同一份，但他不知道前面的人已经试过清缓存、重装依赖、切 Node 版本。
所以第一条规则很简单：目标没变，问题还在同一条线上，就留在当前线程。
可以这样提醒 Codex：
继续当前线程。先总结我们已经确认的事实、已经排除的原因、当前最可能的问题。然后给出下一步最小验证动作。不要扩大范围，不要重构。
这段提示词的作用，是让 Codex 先把工作现场重新摆整齐，再继续动手。
当前线程：适合同一个问题持续推进
线程不是普通聊天记录。放在 Codex App 里，它更像一次持续工作的任务现场。
它里面有对话，也有 Codex 已经做过的判断、执行过的命令、看过的文件、失败过的尝试。只要问题还没换，线程越连续，推理越不容易断。
比如登录页提交后按钮一直 loading。Codex 已经确认接口返回正常，也确认不是网络错误，问题更可能在前端状态管理。这个时候继续当前线程最合理。
提示词可以这样写：
继续当前问题，不要开新线程。
目标：修复登录页提交后按钮一直 loading 的问题。
上下文：刚才已经确认接口返回正常，问题更可能在前端状态管理。
限制：只改最小必要范围，不要重构登录模块。
完成标准：修复后跑相关测试，并总结改了哪些文件。
这里有四个关键词：目标、上下文、限制、完成标准。它们比「帮我修一下」管用得多。Codex 最怕的是目标模糊，一旦目标模糊，它就可能开始扩大范围，最后把一个小问题做成一场小型重构。
开始新对话：同一个项目，换一个干净视角
「开始新对话」很容易被误解成「继续干活」。其实更准确的理解是：同一个项目，换一个新脑子。
新对话能读当前项目里的文件，但不会继承刚才那条线程里的讨论、判断和失败记录。这有缺点，也有价值。
缺点是，它可能重复排查。刚才已经确认不是依赖问题，新对话不知道，可能又从依赖开始看。
价值是，它不会被前一条线带到沟里去。
比如 Codex 在主线程里一直认为搜索页卡顿来自前端重复请求，但你越看越怀疑后端查询也有问题。这个时候开一个新对话，让它从零审查代码，反而能拿到一个比较干净的第二意见。
可以这样写：
请从一个干净视角审查当前项目。
目标：找出搜索页变慢的主要原因。
先只读代码，不要改文件。不要参考任何历史结论。
输出：1. 你认为最可能的三个原因 2. 每个原因对应的文件证据 3. 哪个原因最值得优先验证 4. 下一步最小验证动作
新对话适合两种场景：第一种是全新任务（刚才在修登录，现在要写 README）；第二种是重新审查（主线程聊太久，判断越来越固定，换一个干净视角可能发现前面漏掉的东西）。
派生到本地：带着旧上下文，开一条旁路线
「派生到本地」和「开始新对话」最容易混。
两者都可能在当前项目里工作，也都可能直接改当前目录。真正的差别在于上下文。
派生到本地会继承当前线程的上下文。开始新对话不会。
举个例子。你让 Codex 修搜索页性能。主线程已经查到三个问题：前端没有防抖，搜索状态会触发重复请求，后端查询可能缺索引。现在你想试两个方案。
- • 方案 A 很保守：只加防抖和请求去重
- • 方案 B 更激进：重写搜索缓存层，顺便补测试
如果你希望方案 B 沿用前面的排查结论，就应该用派生。因为新线程知道问题是怎么查出来的，不需要重新从项目入口开始找。
如果只是开新对话，它可能又从「搜索页组件在哪里」开始扫。也能做，但会浪费上下文。
所以「派生到本地」适合这种任务：
- • 同一个问题出现另一条路线
- • 这条路线需要继承前面的判断
- • 改动不算大，可以接受它直接碰当前项目目录
但这里一定要小心：派生到本地有上下文隔离，但没有文件隔离。 它知道前面发生过什么，但它还是在当前本地目录里干活。如果这条路线会大改文件，优先考虑派生到新工作树。
派生到新工作树：让 Codex 去隔壁房间做实验
工作树可以理解成：同一个 Git 项目，额外开一份独立工作目录。
Codex 在这个目录里改代码、跑测试、试方案，不会直接搅乱你当前正在用的项目目录。
这对 Agent 很重要。因为 Agent 的优势是敢试，风险也是敢试。它可能一口气改十几个文件，做一个你没完全预料到的方案。如果这些改动都发生在当前目录，后面清理会很痛苦。
新工作树把问题变简单了：让它去隔壁房间折腾。方案好，就看 diff、跑测试、合回来。方案不行，就丢掉这条实验线。
适合用新工作树的场景很明确：
- • 重构一个模块
- • 替换一套技术方案
- • 尝试新的缓存策略
- • 让 Codex 并行修另一个问题
- • 主线程已经有保守方案，但你想让它试一个更彻底的版本
可以这样写：
这条线作为实验方案，放在新工作树里做。
基于当前上下文继续。
目标：验证完整性能优化方案是否值得合并。
范围：1. 前端防抖和请求去重 2. 后端查询优化 3. 必要时补索引方案 4. 增加性能相关测试
限制：1. 改动必须集中 2. 每一步说明原因 3. 最后给出是否建议合并的判断
这就是新工作树最舒服的用法：主线程保守推进，工作树大胆试错。两条线互不干扰。
Local 和 Worktree：一个负责快，一个负责稳
Local 就是当前项目目录。Codex 在这里读文件、改文件、跑命令，速度快，反馈直接，改完你马上能在 IDE 里看到。
Worktree 是独立工作目录。它也属于同一个 Git 仓库，但文件副本是分开的。
这两个入口没有高下之分，只有适不适合：
- • Local 适合明确的小任务：修一个按钮状态、补一个测试、改一段文案、调整一个组件样式、继续当前排查链路
- • Worktree 适合不确定的大任务：重构、实验、并行修复、多个方案对比、长时间后台工作
不过 Worktree 也有自己的坑。新工作树是新目录，不一定有你当前目录里的所有运行条件。node_modules 可能没有，本地 .env 可能没有，某些没提交的临时文件也可能没有。
更稳的做法，是在 Codex App 里给项目配置 Local environments。简单说，就是告诉 Codex：每次创建新工作树后，先跑哪些初始化命令。
比如前端项目可以配置：
npm install
npm run build这样 Codex 每次进入新工作树，不用重新猜项目怎么跑。
Handoff：把后台工作树里的活拿回当前目录
Worktree 还有一个很实用的动作，叫 Handoff。
它可以把线程在 Local 和 Worktree 之间移动。比如 Codex 在新工作树里做完一版实验，你想在自己平时用的 IDE 里仔细看，就可以把这条线程 hand off 回 Local。
这适合两种情况：
- • 你想用当前环境验证（比如本地开发服务器只适合跑一个实例）
- • 你想把后台实验带回主线（Worktree 里方案已经比较干净，接下来需要人工审 diff、跑测试、决定提交）
但要记住：Handoff 底层仍然要处理 Git 状态。被 .gitignore 忽略的文件，不会自动跟着移动。
Subagents：先让它们查证，别让它们抢方向盘
Subagent workflows 很强，但也很容易被用坏。
最常见的错误，是把 Subagents 当成「多个程序员同时写代码」。听起来效率高，实际很容易互相打架。一个 Agent 改搜索组件，另一个 Agent 改请求封装，第三个 Agent 改测试，最后主线程可能花更多时间处理冲突。
Subagents 更适合做读多写少的工作。
比如一个复杂问题里有很多不确定方向：前端可能重复请求，后端可能慢查询，缓存可能失效，测试也可能没覆盖。这个时候，不要让主线程一个人把所有文件翻完，可以让 Subagents 分头调查。
主 Agent 负责判断和取舍。Subagents 负责探索、测试、分诊、审查。
可以这样安排：
请启动 subagent workflow，所有子任务先只读不写。
主 Agent 负责最终汇总和决策。
请拆成 4 个 Subagents：
- 1. 前端请求流检查：查搜索页是否存在重复请求、状态循环、无效渲染
- 2. 后端查询检查：查搜索接口、数据库查询、分页逻辑
- 3. 缓存策略检查：查缓存命中、失效条件、重复计算
- 4. 测试覆盖检查：查现有测试是否能覆盖这个性能问题
每个 Subagent 输出：1. 结论 2. 证据文件 3. 风险等级 4. 建议下一步
等全部返回后，主 Agent 用一张表汇总，并给出唯一推荐行动。
这段提示词里最关键的是「只读不写」。先让它们查证，不要让它们抢方向盘。等结果回来，主 Agent 再决定怎么改。
AGENTS.md：给新对话和工作树留一张项目地图
新对话没有旧线程上下文。新工作树也可能缺少本地环境细节。这个时候，AGENTS.md 就很有用。
它可以理解成写给 Codex 的项目说明书。里面不用写得很漂亮，重点是把项目规则讲清楚：
- • 项目是什么
- • 目录怎么分
- • 常用命令是什么
- • 测试怎么跑
- • 哪些文件不能乱改
- • 哪些操作需要先确认
- • 任务完成后怎么验证
AGENTS.md 不需要一开始就写成百科全书。越长越容易失效。更好的方式是：先写最常用的规则，等 Codex 重复犯同一个错误，再把那条规则补进去。
这类规则来自真实摩擦，才有用。
一个完整实操案例：搜索页卡顿
假设当前项目是一个内容站。问题很具体：搜索页输入关键词后明显卡顿。用户每输入一个字，接口就请求一次，有时还会重复请求。
第一步：当前线程先只读排查
不要一上来就派生，也不要马上开 Subagents。先在当前项目里开一个 Local 线程，让 Codex 只读排查。
先不要改代码。
目标：查清搜索页输入关键词后变慢的原因。
上下文：用户输入时接口请求频繁，页面有卡顿。
限制：1. 先只读代码 2. 不要重构 3. 不要改数据库结构
完成标准：请输出最可能的 3 个原因、对应文件证据、下一步最小验证动作。
假设 Codex 查完以后，发现三个点：输入没有防抖、搜索状态会触发重复请求、后端查询可能缺索引。这时不要急着把三个问题全改掉。先选最小路径。
第二步：同一个问题继续当前线程，先做保守修复
如果问题集中在前端输入防抖和请求去重，那就留在当前线程里做最小修复。
继续当前线程。
采用最小修复方案：1. 前端加防抖 2. 避免重复请求 3. 不碰数据库结构
改完后运行相关测试，并给出 diff 总结。
这条线的目标是求稳。它不解决所有性能问题，只解决用户眼前能感受到的卡顿和重复请求。这样改动小，容易验证，也容易回滚。
第三步：派生到新工作树，试完整性能方案
如果还想验证更完整的方案，就从当前线程派生到新工作树。
这条线作为实验方案，放在新工作树里做。
基于当前上下文继续。
目标：验证完整性能优化方案是否值得合并。
范围：1. 前端防抖和请求去重 2. 后端查询优化 3. 必要时补索引方案 4. 增加性能相关测试
最后请给出：1. 改动文件列表 2. 测试结果 3. 是否建议合并 4. 如果不合并，哪些小改动值得带回主线
这样主线程有保守修复，工作树里有完整实验。两条线互不影响。
第四步：让 Subagents 审查实验方案
实验方案出来以后，不要立刻合并。让 Subagents 做一次审查。
请启动 subagent workflow，审查当前工作树的改动。
派 3 个 Subagents：1. 安全审查 2. 测试审查 3. 可维护性审查
要求：1. 只读不写 2. 每个结论给出文件证据 3. 主 Agent 等全部结果返回后，再给出最终合并建议
这一步像 PR review。它不是为了让 Subagents 接着改，而是让它们找问题。最终怎么合，仍然由主线程判断。
第五步：看 diff，再决定合并哪一部分
Codex App 的 diff 面板一定要看。不要只看 Codex 的总结。总结可能很顺，但 diff 里才能看到真实改动。
重点看五件事：改了哪些文件、有没有无关修改、有没有配置被误改、测试是不是真的跑了、风险点有没有解释清楚。
如果 worktree 方案干净，可以创建分支、提交、推送、开 PR。如果方案太大，就只把里面最有价值的小改动带回主线。如果方案跑偏，直接丢掉这个 worktree。
最容易翻车的 6 个判断
- 1. 同一个问题反复开新对话——每次都从头看项目，每次都重新问背景，每次都重复排查已经排除的原因。解决办法：同一个问题留在当前线程。
- 2. 大改还放在 Local 里做——Local 适合明确的小修。重构、实验、替换方案这类任务，放在当前目录里风险很高。解决办法：大改用 Worktree。
- 3. 把派生到本地当成安全实验区——派生到本地会继承上下文，但仍然可能直接改当前目录。它不是安全沙盒。解决办法：只要担心当前目录被改乱，就选新工作树。
- 4. 把 Subagents 当成多个程序员同时写代码——多个 Agent 同时写代码，容易互相冲突。解决办法：Subagents 先只读调查，主 Agent 汇总后再决定由谁执行修改。
- 5. Worktree 跑不起来，就怪 Codex——新工作树是新目录，依赖、本地环境变量、临时文件都可能缺。解决办法：配置 Local environments。
- 6. 没有完成标准——「帮我优化一下」很容易失控。解决办法：每个任务都写清楚目标、上下文、限制和完成标准。
最后真正要记住的，不是按钮，是分工
Codex App 桌面版的这些入口，本质上是在帮用户做任务分工：
- • 线程负责保留上下文
- • Local 负责快速执行
- • Worktree 负责隔离实验
- • 新对话负责干净视角
- • 派生负责继承上下文后的分叉
- • Subagents 负责并行调查
- • AGENTS.md 负责告诉 Codex 项目规矩
- • Local environments 负责让新工作树跑得起来
- • Handoff 负责把后台实验拿回前台验证
如果把它们都当成「再开一个聊天窗口」，Codex 很快就会变成一堆混乱线程。每条线程都在干活，但没人知道谁守主线，谁做实验，谁查证据，谁最后收口。
更好的用法，是在开始前先问一句：这件事是在继续推进、换路实验、重新审查，还是并行调查？
答案出来，按钮自然就好选。
原文：@thinkszyg[1] ｜ 作者：爆裂队长NEXT
引用链接
[1] @thinkszyg: https://x.com/thinkszyg/status/2061278800491729292
