我发现很多人用 Codex App 时，都会走进同一个坑
打开项目，开一条线程，然后把所有需求都塞进去：改首页、修登录、补测试、写 README，最后再让它打包发布
刚开始没什么感觉
但聊到后面，任务边界会越来越模糊，改动范围越来越大，前面修好的地方也可能被后面的需求带乱
这时候别急着怪 Codex 不够聪明
一个项目本来就不该用一条聊天线程从头扛到尾
Codex App 管的是任务，不是聊天记录普通聊天的习惯是问一句、答一句
但软件项目不是一连串孤立问题，它通常同时包含功能开发、Bug 修复、文档整理、测试验证和重构分析
如果这些事情都挤在一个线程里，Codex 就要同时背着一大堆上下文往前走
更稳的做法，是把项目拆成多个独立任务，再给每个任务开一条线程
我会把 Codex App 理解成一个项目工作台
人的工作是拆清楚，Codex 的工作是分别推进，最后再由人检查 diff、决定合并顺序
多线程的关键，是每条线只负责一件事“多线程”不等于多开几个窗口，然后让它们随便改
如果几条线程同时碰同一个主页面、同一套全局状态，冲突只是早晚的事
比如下面这种拆法，风险就很高：
纯文本
线程 A：重构整个项目线程 B：优化所有页面
线程 C：修复所有 Bug
线程 D：调整整体架构
这不是并行推进，更像是几组人同时在一块地基上施工
可以换成这种边界更窄的拆法：
纯文本
线程 A：只修改登录页按钮交互线程 B：只补充用户设置页的空状态提示
线程 C：只检查列表加载失败的问题
线程 D：只整理 README 文档
真正适合并行的任务，一般有三个特点：目标清楚、修改范围有限、和其他任务耦合较低
Worktree：给每条线程单独留一块施工区Codex App 里的worktree，是多线程工作流里很关键的一环
如果你还不熟悉 Git，可以先把它想成同一个项目的多个临时工作间
主项目是办公室，每条 Codex 线程进入自己的工作间施工
纯文本
主项目 main├─ worktree-ui → 只做界面调整
├─ worktree-bugfix → 只修一个 Bug
├─ worktree-docs → 只写文档
└─ worktree-test → 只补测试
这样一来，不同线程的修改不会直接搅在一起
每条线程都有自己的 diff，你可以单独审查结果，不满意就放弃这一条，满意后再合并回主项目
所以，worktree 的价值不只是“让任务同时跑起来”
它还把每次修改变成了可以检查、比较和回滚的独立结果
一个项目，应该这样拆线程我建议先按任务类型拆，不要按“我要完成整个项目”拆
功能线程：只交付一个新能力
适合新增用户头像上传、搜索筛选、订单导出、暗色模式切换这类目标明确的功能
这条线程只解决一个功能，别顺手把项目结构也重写一遍
纯文本
本线程只负责实现【搜索筛选功能】要求：
1. 只修改与搜索筛选相关的文件
2. 不重构项目整体结构
3. 不修改无关页面样式
4. 修改前先说明准备检查哪些文件
5. 修改后列出改动摘要和验证方式
Bug 线程：定位原因，再做最小修复
登录按钮无响应、列表刷新后数据重复、表单提交没有提示，都适合单独开线
纯文本
本线程只负责修复【登录按钮点击无响应】的问题限制：
1. 优先定位原因，不要直接大范围重构
2. 只做最小必要修改
3. 不改动页面视觉样式，除非问题必须涉及样式
4. 修复后说明问题原因、修改文件和验证步骤
文档线程和测试线程：让它们别碰业务代码
README、运行说明、更新日志，可以交给文档线程单独处理
构建检查、边界测试、潜在 Bug 排查，则适合放进测试线程
这两类任务和业务开发分开后，通常更容易审查，也更不容易把改动范围带偏
重构线程：先分析，后决定改不改
重构最容易失控
我的建议是先让一条线程只分析项目结构，列出重复代码、命名混乱、模块耦合和潜在风险，再决定是否另开线程执行其中一项
别一上来就说“帮我优化整个项目”
边界提示词，比“帮我优化一下”有用得多给 Codex 的任务越开放，它越容易顺手扩大修改范围
一个完整的线程提示词，至少要说清楚四件事：做什么、能改什么、不能改什么、怎样算完成
纯文本
当前项目正在使用 Codex App 多线程并行开发【本线程目标】
只处理：设置页保存按钮点击后没有反馈
【允许修改范围】
- 设置页相关组件
- 设置保存相关逻辑
- 必要的提示组件调用
【禁止修改范围】
- 登录模块
- 路由结构
- 全局样式
- 项目构建配置
【完成标准】
1. 点击保存后有明确的成功或失败反馈
2. 原有保存逻辑不被破坏
3. 修改范围尽量小
4. 最后列出改动文件、原因和验证方式
这类提示词的作用，不是让 Codex 变得更听话
它是在提前划定审查范围，让一项开放任务变成一个可以回滚、可以合并的小任务
不是所有任务都适合并行拆线程之前，我会先看任务之间的耦合程度
可以记住一个判断：
能并行的是边界清楚的任务，不能并行的是高度耦合的核心改动
合并结果，也要有自己的节奏多线程的目的，不是让所有线程同时改完，然后一次性全部合并
更稳的流程是这样：
纯文本
确认项目处于 Git 管理下↓
列出今天要推进的任务
↓
判断哪些任务可以并行
↓
一个任务开一条线程
↓
逐条审查 diff，再决定是否合并
Git 至少能帮你查看 diff、回滚改动、比较不同线程、合并结果和处理冲突
如果项目还没有 Git，可以先让 Codex 检查是否适合初始化，但不要马上让它做大范围修改
比如今天有四件事：
纯文本
1. 修复登录按钮无响应2. 增加搜索筛选
3. 整理 README
4. 检查构建报错
我可能会先并行处理登录问题、README 和构建检查
搜索筛选涉及数据结构、页面状态和接口调用，最好等基础问题稳定后再推进
Codex 做完以后，也别看到“完成”就直接接受
我会检查它有没有改到任务范围之外，有没有删除已有功能，有没有引入新的依赖，以及它是否说明了验证方式
文档、小 Bug、测试补充和样式微调，可以优先合并
架构重构、依赖升级、状态管理调整、接口变化，则要多看一眼
人的角色，从写提示词变成排任务过去用 AI 编程，常见流程是：我提需求，AI 给代码，我复制粘贴，报错后继续问
Codex App 更像项目协作
纯文本
我拆任务我开线程
Codex 分头处理
我看 diff
我评论修改
我决定合并
我控制节奏
这并不意味着人可以少做判断
相反，你要负责决定哪些事能并行，哪些改动值得合并，什么时候暂停、回滚或重做
对于普通项目，同时开 2～4 个线程通常已经够用
我更推荐分轮推进：先开 2 个低风险线程，审查并合并稳定结果，再开下一轮任务
最后留一条判断标准
Codex App 的变化，不是让一个 AI 把所有事情一口气做完
它把复杂项目拆成多个可以独立推进的任务，再让你逐个检查和选择
所以我现在更关注的，不是一次开了多少条线程
而是每条线程有没有清楚的目标、有限的修改范围、独立的 diff，以及安全的合并条件
AI 负责执行，人负责判断
当你能把项目拆成几条互不打架的工作线，Codex App 才真正开始发挥作用