Codex 多线程管理教程：一个聊天窗口，指挥一整个修 Bug 小队

你有没有遇到过这种场景：

GitHub 上一堆 bug report 等着处理。

你开了 5 个聊天窗口。

一个在看报错日志，一个在改测试，一个在查历史提交，一个在跑命令，还有一个你已经忘了它在干嘛。

切来切去，脑子直接冒烟。😵

这就是很多 TUI 编程工具的问题：工具很强，界面很硬核，人很累。

Codex 最近加了一个很实用的能力：让一个聊天线程管理其他聊天线程。

听起来不花哨，但真的很香。

你可以只盯着一个主聊天，让它去创建子线程、分配任务、检查进度、置顶重点、归档完成项。像给自己配了一个会干活的项目助理。

这个功能到底解决了什么问题？

以前用 AI 写代码，经常是这种工作流：

• 开一个窗口修登录 bug
• 再开一个窗口查支付失败
• 又开一个窗口处理测试报错
• 中途忘了哪个窗口改了哪个分支
• 回头还要自己整理上下文

这不是编程，这是人肉调度系统。

Codex 的多线程管理，把调度这件事交给 AI。

主线程可以做这些事：

• 创建新的聊天线程
• 给不同线程分配不同任务
• 为每个任务创建独立 worktree
• 检查子线程当前进展
• 把重要线程 pin 到前面
• 把完成或暂缓的线程归档
• 需要时再打开某个线程继续追

重点来了：你不需要一直切窗口。

大部分时候，你只看主线程就够了。

为什么这比普通 Subagent 更值得用？

很多 AI 工具也有 Subagent。

问题是，不少 Subagent 更像一次性外包：

你派它出去，它跑一段，返回一个结果，然后就散了。

想回头 review？麻烦。

想继续追它刚才改了什么？麻烦。

想把它暂时放起来，下周再看？更麻烦。

Codex 这个模式更像“可管理的任务线程”。

每个线程都可以保留下来。

你可以归档，可以置顶，可以回看，可以继续推进。

这对真实项目很重要。

真实开发不是一锤子买卖。一个 bug 可能今天只能定位，明天补测试，后天等 CI 结果。线程能留下来，工作流才稳。

适合用它处理哪些任务？

别什么都丢给多线程。它最适合这几类场景：

1. GitHub bug 批量处理

比如你维护一个开源项目，Issue 堆了 30 个。

你可以让 Codex 扫一遍，挑出简单可修的 bug，分别开线程处理。

2. 多个小功能并行开发

比如：

• 给后台加导出按钮
• 给登录页补错误提示
• 给 API 加参数校验
• 给测试套件补缺口

这些任务互相影响不大，很适合拆成多个线程。

3. 大重构前的探索

你可以让不同线程尝试不同方案。

一个线程改 service 层。

一个线程抽公共函数。

一个线程专门补测试。

主线程负责看哪个方案最靠谱。

4. 代码审查和修复

让 Codex 针对 PR 评论创建子线程。

每条评论一个任务。

改完后主线程统一汇总。

快速上手：直接用这段 Prompt

在 Codex 任意一个聊天窗口里，输入下面这段：

扫描 GitHub 上的 bug 报告，然后针对看起来比较容易修复的 bug，在不同的 worktree 中创建新的线程去修复它们。对于最重要的任务，也把这些线程置顶。

接下来你会看到 Codex 开始做几件事：

• 查看 GitHub issue 或 bug report
• 判断哪些 bug 更容易修
• 给每个 bug 创建独立线程
• 为任务分配不同 worktree
• 把优先级高的线程置顶
• 在主线程里汇报分配情况

这就很像你对一个组长说：

“去把简单 bug 挑出来，每个人领一个，重要的放我桌上。”

你不用亲自把每个窗口点开安排。

推荐工作流：主线程当控制台，子线程干脏活

咱们可以把它拆成一个固定流程。

第一步：让主线程做任务筛选

你可以这样说：

请扫描当前仓库的 open issues，按修复难度和影响范围分组。优先挑选低风险、可在 1 小时内验证的 bug。不要直接修改代码，先给我任务清单。

这样可以避免 Codex 上来就乱改。

你先拿到一个清单，再决定哪些值得开线程。

第二步：让它创建子线程和 worktree

任务清单确认后，再发：

为清单中前 3 个低风险 bug 分别创建独立线程，每个线程使用单独 worktree。每个线程需要完成：复现问题、定位原因、修改代码、补充或更新测试、给出验证命令。

这里有个关键点：每个线程单独 worktree。

这样改动不会互相污染。

一个线程翻车了，不会把另一个线程也拖下水。

第三步：让主线程定期巡检

不要自己一个个点进去看。

直接问主线程：

检查所有子线程的当前进展。请按这几个字段汇总：任务名称、当前状态、已修改文件、是否有测试、风险点、下一步建议。

你要的是管理视角，不是流水账。

看一眼就知道该盯谁。

第四步：置顶高价值线程

当某个 bug 影响线上用户，别让它沉下去。

把影响用户登录、支付、数据丢失相关的线程置顶。其他低优先级任务保持普通状态。

主线程会帮你整理优先级。

你每天打开 Codex，先看置顶线程就行。

第五步：完成后归档

做完的线程别堆在列表里。

归档已经完成并通过测试的线程。归档前请汇总每个线程的修改内容、测试结果和相关分支名称。

归档不是丢掉。

它更像把文件放进柜子。

哪天要复盘，还能拿出来看。

一个真实场景：维护开源项目时怎么用

假设你有一个 Node.js 项目，GitHub 上有这些 issue：

• 登录失败时没有错误提示
• Windows 下路径解析报错
• 导出 CSV 时中文乱码
• 测试在 Node 20 下偶发失败
• README 安装命令过期

你可以直接给 Codex 这段指令：

扫描当前仓库的 GitHub issues。请挑出 3 个适合快速修复的问题，为每个问题创建独立线程和 worktree。优先选择：复现路径清晰、影响范围小、测试容易补的任务。完成后在主线程汇总每个子线程的任务目标和预期改动。

它可能会这样分配：

| 子线程 | 任务 | 优先级 | worktree | |---|---|---|---| | thread-login-error | 登录失败提示 | 高 | wt-login-error | | thread-csv-encoding | CSV 中文乱码 | 中 | wt-csv-encoding | | thread-readme-install | README 命令更新 | 低 | wt-readme-install |

然后你继续指挥：

优先推进登录失败提示这个线程。其他线程保持等待。请检查登录线程是否已经补充测试，并告诉我是否可以提交 PR。

你看，整个过程里，你都在主线程里说话。

Codex 去调度。

你做判断。

这才像人用工具，而不是人被工具牵着跑。

Prompt 模板：直接收藏

批量扫 bug

扫描当前仓库的 GitHub bug 报告，按修复难度、影响范围、测试成本分组。请列出适合快速修复的候选任务，不要立刻修改代码。

创建子线程

为候选任务中的前 N 个创建独立线程，每个线程使用单独 worktree。每个线程需要复现问题、定位原因、修改代码、补测试、给出验证命令。

检查进度

检查所有子线程状态。请用表格汇总：任务、状态、改动文件、测试情况、阻塞点、建议动作。

置顶重点任务

把高风险或高价值任务置顶，判断标准是：影响线上用户、涉及安全、涉及支付、涉及数据正确性。

归档完成线程

归档已完成且通过测试的线程。归档前请汇总：问题描述、修改内容、测试命令、测试结果、分支或 worktree 名称。

暂停低优先级任务

暂停低优先级线程，并说明暂停原因。保留上下文，后续可能继续处理。

避坑清单：别让 Codex 带着你狂奔

坑 1：一上来就让它改代码

别急。

先让它扫 issue，做分类，给候选任务。

你确认后再开线程。

否则它可能挑了一个“看起来简单，实际牵一发动全身”的坑。

坑 2：没有要求独立 worktree

多线程最怕互相污染。

一定要明确：每个任务独立 worktree。

这句话别省。

坑 3：不要求测试

AI 修 bug 最容易出现一种情况：代码看着对，测试没跑。

Prompt 里要写死：

• 需要复现
• 需要测试
• 需要验证命令
• 需要说明测试结果

坑 4：线程开太多

别贪。

一次开 3 个到 5 个就够了。

开 20 个线程，主线程也会变成菜市场。

坑 5：不做归档

完成的线程一定归档。

不然几天后你打开 Codex，满屏都是历史任务，心态当场爆炸。

坑 6：把判断权全交出去

Codex 适合做执行和整理。

优先级、风险判断、是否合并，还是你拍板。

AI 可以帮你跑腿，别让它替你签字。

TUI 模式为什么会被这种工作流压一头？

TUI 工具不差。

很多开发者喜欢它，因为快、纯粹、键盘友好。

问题在于，大量任务并行时，TUI 很容易把心智成本甩给你。

你要记住：

• 哪个面板在修哪个 bug
• 哪个分支跑过测试
• 哪个窗口还没提交
• 哪个任务被卡住
• 哪个改动可以合并

人脑不是任务队列。

当工具能替你管理线程、状态、优先级和归档时，纯靠人肉切换窗口的方式就显得累了。

Codex 这套多线程管理，把 AI 编程从“单次问答”往“项目调度”推了一步。

这才是它真正有意思的地方。

你可以今天就试的最小动作

别等大项目。

找一个你手上的仓库，挑 5 个 issue。

然后在 Codex 里输入：

扫描这个仓库的 open issues，挑出 3 个低风险、容易验证的 bug。请先给我候选清单，不要修改代码。

确认清单后，再输入：

为这 3 个 bug 分别创建独立线程和 worktree。每个线程完成复现、修复、测试和验证命令汇总。重要任务请置顶。

跑一轮你就能感受到差别。

以前是你盯着 5 个窗口找状态。

现在是一个主线程把状态送到你面前。

少切几个窗口，少丢几次上下文。

一天结束时，真的可能早下班一小时。