Codex 子任务完整指南

bilibiliblilili

22人浏览 · 2026-08-24 13:06:28

bilibiliblilili · 2026-08-24 13:06:28 发布

Codex 子任务完整指南：如何拆分、并行、审计，以及为什么长期复杂项目更适合阶段化

本文是一篇面向新人的实战教程，也是一份带有案例证据和适用边界的技术分析。你可以先照着教程完成第一次子任务协作，再阅读后半部分理解它为什么有效、又为什么不能无限运行。

前言

很多人第一次看到 Codex 可以同时处理多个任务，会自然地想到一种组织方式：

人提出目标
→ 主任务理解项目并拆分
→ 多个子任务并行执行
→ 子任务回传结果
→ 主任务审计和返修
→ 主任务向人交付

这个想法没有错。对于边界清楚、时间有限、能够独立验收的工作，它非常有效。

问题在于，一旦把它当成长期项目的永久组织结构，主任务就会不断接收需求、结论、冲突、返修和跨模块关系。即使增加任务状态管理、计划文件或更多层级，也只能降低混乱和延缓增长，不能让这些信息凭空消失。

所以，本文不只回答“怎么创建子任务”，还要回答三个更重要的问题：

什么工作值得拆成子任务？
怎样拆分、派发、审计和收口才可靠？
为什么长期复杂项目应该阶段化，而不应该维持永久主线和永久子任务？

本文吸收了两篇 CSDN 实践文章中的控制台、多任务拆分、Worktree、任务合同和统一验收方法 [1][2]，并结合长期复杂项目中的主线交接经验，对这些方法的有效范围作进一步分析。

1. 先说结论

本文最重要的结论是：

Codex 子任务模式适合轻量到中等规模的有限工作单元；长期复杂项目可以使用“阶段化子任务”，但不应使用永久主线和永久子任务的连续运行模式。

这里有两个容易误解的地方。

第一，本文不是说“长期项目不能用子任务”。长期项目当然可以用，但每个子任务要有明确阶段、明确输入、明确验收和明确结束时间。

第二，本文所说的“长期复杂”，重点不是日历时间长，而是语义范围持续扩大：需求不断变化、跨模块关系越来越多、历史决策必须被持续记住、返修和交接不断发生。

1.1 30 秒判断表

如果你现在只想知道该怎么选，可以先看这张表。

任务类型	典型特征	推荐方式
轻量任务	目标清楚，1～2 个独立结果，几乎没有共享写入	直接使用一个或两个子任务
中等任务	多模块协作，接口可以先冻结，结果能够分别验证	主任务控制台 + 子任务 + 独立审计
长期复杂项目	需求持续变化，跨域依赖多，历史知识和返修不断累积	按阶段创建有限任务，阶段结束后封存并重建执行上下文
高耦合且无法拆分	多人必须同时理解同一片逻辑，文件和行为无法分开验收	单线实施为主，只并行做只读调查或审计

简单记法：

能独立说明、独立执行、独立验收的，才适合独立成一个子任务。

1.2 阅读路线

第一次使用 Codex 子任务：阅读第 2～11 节。
已经会用，但经常返工或冲突：重点阅读第 6、7、12、16 节。
正在管理长期项目：重点阅读第 13～18 节。
想检查本文论证是否成立：阅读第 21 节。

2. 先把术语分清楚

“子任务”在日常交流中经常被用来指代不同东西。如果不先分清，后面很容易把不同能力混在一起。

本文把“由主任务分派出去的有限工作”统称为子任务；但在产品和工程实现上，独立任务、Side conversation、Subagent、Fork 和 Worktree 并不是同一种东西。

不同版本的 Codex 界面名称可能变化，本文关注的是它们的工作语义，而不是某个按钮的固定位置。

2.1 主任务

主任务不是产品强制维护的“父节点”，而是你人为赋予的控制职责。

它通常负责：

理解本阶段目标；
确认影响范围和依赖；
拆分有限工作单元；
分配文件或模块所有权；
接收结果和证据；
处理跨任务冲突；
组织返修和统一验证；
最终向人报告。

因此，“主线”首先是一种职责关系，不代表它在物理上一定高于其他任务。很多 Codex 任务在界面和存储层面仍然是平级的。

2.2 独立任务

独立任务有自己的对话历史和生命周期，适合承接一段能够单独说明、单独等待、单独继续的工作。

例如：

调查某个框架版本的官方用法；
在独立 Worktree 中实现一个模块；
对固定代码快照做只读审计；
生成一份不依赖主任务实时指导的迁移清单。

独立任务的优点是隔离清楚，缺点是它不会自动拥有主任务脑中的全部背景。

2.3 Side conversation

Side conversation 可以理解为围绕当前工作临时展开的一条旁路讨论。它适合回答一个局部问题、比较两个方案或确认一段证据，而不必把主对话拉得更散。

它更像“从当前问题旁边开一个讨论窗口”，不应默认承担完整项目生命周期。

适合：

解释某段日志；
比较两个 API；
请另一个视角审查一个局部判断；
暂时讨论一个不确定方案。

不适合：

长期维护一个模块；
持续接收大量返修；
作为永久部门保存全部领域知识。

2.4 Subagent

Subagent 是当前主任务为了完成一个受限目标而调用的执行角色。它通常由主任务派发、回传结果，再由主任务综合。

它适合：

边界稳定的只读调查；
不重叠文件上的实现；
独立测试或反方审计；
能在一个工作轮次内完成的专家任务。

它不等同于独立任务。一般来说，Subagent 更偏当前任务内部的短期协作；独立任务更适合让用户直接看到、继续和管理。

2.5 Fork

Fork 是从已有上下文分叉出新的任务。新任务继承分叉点之前的背景，然后独立发展。

Fork 适合：

两个方案需要从同一背景出发分别验证；
当前任务已经积累了必要事实，新分支不想重新解释；
想保留原任务不动，在分支中尝试另一条路线。

Fork 不会让后续历史自动双向同步。分叉后发生的新决策，仍需要显式回传。

2.6 Worktree

Worktree 是 Git 的工作区隔离能力。它让不同任务在不同目录和分支上修改代码，从而减少同时写同一工作区造成的覆盖与混乱。

它解决的是文件和分支隔离，不是语义上下文隔离。

Worktree 可以防止两个任务直接踩同一份工作目录，却不能保证它们理解了相同需求，也不能自动解决合并后的行为冲突。

2.7 Plan

Plan 是持久化计划或任务状态记录。它可以保存目标、阶段、依赖、所有权、验证结果、阻塞项和下一步。

Plan 很有价值，但它保存的是显式状态，不等于保存了执行者的全部判断能力。为什么放弃某条路线、某个证据为何可信、某个边界为什么不能碰，这些隐含知识如果没有被写清楚，交接时仍会丢失。

2.8 一张表看懂

概念	最适合做什么	是否天然长期	主要风险
主任务	当前阶段的拆分、协调、审计和交付	不建议永久化	信息持续汇聚
独立任务	可单独继续和验收的工作	可跨多轮，但应有结束条件	与主任务语义漂移
Side conversation	临时旁路讨论	否	被误当成长期执行线
Subagent	当前任务内的有限执行或审计	否	输入不完整、回传过度摘要
Fork	从共同历史出发探索不同路线	分叉后独立	后续决策不会自动同步
Worktree	隔离代码目录和分支	可持续一段阶段	只隔离文件，不隔离语义
Plan	保存显式状态和恢复入口	可以长期保存	计划膨胀、陈旧、遗漏因果

3. 独立任务和 Subagent 到底有什么不同

这是新人最容易混淆的一组概念。

简单记法：

需要用户日后直接回来继续的，优先独立任务；只为当前主任务完成一个有限工作单元的，优先 Subagent。

对比项	独立任务	Subagent
谁直接管理	用户通常可以直接查看和继续	主任务负责调用和综合
上下文来源	创建时提供，或从 Fork 继承	由主任务在派发时提供
适合时长	多轮有限任务	单轮或少量轮次的受限任务
适合工作	独立开发、长期调查、单独交付	快速调查、局部实现、并行审计
结果回流	需要显式同步给主任务	通常直接回传主任务
主要风险	两条平级任务长期漂移	主任务给出的任务包不完整

选择流程如下。

图 1：任务类型选择。不要先问“哪个更强”，先问“谁管理、要运行多久、如何验收”。

4. 为什么要建立主任务控制台

只并行创建多个任务，并不会自动形成协作。没有控制台时，常见结果是：每个任务都完成了一部分，但没有人知道它们能否一起工作。

一个可靠的主任务控制台要同时管理三个面和三本账。

4.1 控制面、任务面、证据面

图 2：三面模型。控制面决定做什么和是否通过，任务面负责执行，证据面保存可以复查的事实。

控制面：目标、依赖、所有权、状态、冲突、验收和下一步。
任务面：调查、实现、测试、文档、审计等具体工作。
证据面：代码 diff、测试结果、日志、截图、接口样例、决策依据。

如果只有任务面，没有控制面，就会出现“各自完成、整体不可用”。如果只有控制面，没有证据面，就会出现“大家都说完成，但无法复核”。

4.2 决策账、任务账、产物账

三本账不是为了制造文档，而是为了让主任务在不重读全部对话的情况下恢复当前状态。

账本	至少记录什么	何时更新	解决什么问题
决策账	决定了什么、为什么、替代方案、影响范围、证据	关键取舍发生后	防止新任务重复争论或推翻冻结结论
任务账	任务 ID、负责人、状态、依赖、所有权、阻塞、下一步	派发、阻塞、回传、验收时	防止状态漂移和重复执行
产物账	文件、分支、测试、日志、截图、版本、验证状态	产物形成或验证后	防止“说完成了但找不到结果”

建议只记高价值字段。不要把每句聊天都复制进账本，否则账本本身也会变成新的超大上下文。

4.3 主任务不应该做什么

主任务不是所有工作的亲自执行者，也不应该变成摘要搬运工。

它不应该：

把每个子任务的完整对话再次复制进主线；
在没有证据的情况下替子任务宣布完成；
同时持有所有文件的写入权；
让多个任务长期等待自己的逐句指导；
因为怕遗漏而无限续写同一个主任务。

更合理的是：主任务保留当前阶段所需的控制信息，详细证据留在可定位的文件、测试和日志中。

5. 什么时候适合，什么时候不适合

5.1 适合子任务的场景

多个调查可以独立进行，例如文档核对、日志分析、代码入口定位。
多个模块的接口已经冻结，写入范围不重叠。
实现和审计可以由不同任务承担。
同一材料需要不同视角，例如支持方和反方评审。
每个结果都有单独的验收标准。

5.2 不适合直接并行的场景

需求本身还没有说清楚。
多个任务必须频繁修改同一批核心文件。
接口、数据结构或行为约定仍在变化。
子任务必须持续理解大量历史才能做出正确判断。
验收只能在所有修改合并后进行，局部结果没有意义。
主任务没有足够时间审查所有并行输出。

5.3 六维判断法

可以用六个问题快速评估：

维度	越适合拆分	越不适合拆分
目标稳定性	目标已确认	需求持续变化
边界清晰度	文件和模块范围明确	大量共享文件
接口稳定性	输入输出已冻结	接口仍在讨论
跨模块依赖	依赖少且单向	依赖多且双向
验收独立性	可以单独测试	只能整体试运行
历史知识依赖	读取少量当前资料即可	需要大量隐含背景

如果右侧特征占多数，不要为了“并行”强行拆分。先缩小目标、冻结接口或只并行做只读调查。

6. 从零搭建一套完整子任务流程

下面是一套适合第一次实践的八步流程。它综合了两篇参考文章中的任务控制、职责拆分、Worktree 和统一收口方法 [1][2]。

图 3：从零搭建子任务协作的八步流程。

6.1 第一步：定义总目标和完成标准

不要直接说“把这个项目优化一下”。先把目标写成可以检查的结果。

例如：

目标：为客户接口增加 customerLevel 字段。

完成标准：
1. 查询接口返回 customerLevel；
2. 新增和更新接口能够保存该字段；
3. 数据库迁移可执行；
4. 单元测试和接口测试通过；
5. 不改变原有字段语义。

目标不清楚时，子任务只会把模糊放大成多份不同理解。

6.2 第二步：只读确认影响范围

在任何写入之前，让一个任务先回答：

入口在哪里？
调用链经过哪些模块？
哪些文件必须一起修改？
是否有现成项目模式可以复用？
哪些行为只能运行时验证？
哪些结论仍然不确定？

这一步通常只读。它的目的不是提前写一篇长报告，而是形成可拆分的依赖图。

6.3 第三步：选择 Create、Fork 还是 Subagent

Create 指创建一个上下文较干净的新任务；Fork 指从当前历史分出新任务。

场景	Create	Fork	Subagent
工作与当前历史关系很弱	推荐	不需要	可用于很小的工作
必须继承大量已确认背景	需要重新写任务包	推荐	仅当工作有限
想比较两个独立方案	可分别创建	从同一点 Fork 更方便	适合短期方案比较
需要用户日后直接继续	推荐	推荐	不优先
只需回传一个有限结果	偏重	偏重	推荐

不要因为 Fork 方便就无限复制旧上下文。旧历史里如果包含大量已经失效的探索，它也会把噪声一起带过去。

6.4 第四步：选择 Local 还是 Worktree

Local 表示任务直接使用当前工作区。Worktree 表示给任务独立目录和分支。

选择	适合	不适合	关键规则
Local	只读调查、单一写入者、很小的连续修改	多个任务同时写同一仓库	同一时间只保留一个明确写入者
Worktree	多个独立模块并行开发、需要保留独立 diff	强耦合共享文件、接口仍在变化	先冻结接口，再分配分支和所有权

Worktree 不是越多越好。每增加一个 Worktree，就增加一次同步、合并和验证成本。

6.5 第五步：拆分任务并冻结接口

好的拆分不是“平均分工作量”，而是让每份工作可以独立验收。

拆分后要明确：

每个任务的输入和输出；
谁可以修改哪些文件；
哪些接口是冻结的；
依赖谁先完成；
通过什么检查才算完成；
失败后由谁返修。

错误示例：

任务 A：改后端。
任务 B：改前端。
任务 C：补测试。

这三个描述没有接口、文件边界和验收标准。

更合理的写法：

任务 A：冻结 customerLevel 的字段类型、枚举值和 API 契约，只读输出接口说明。
任务 B：在约定文件范围内实现数据库迁移、实体和持久层，运行持久层测试。
任务 C：在约定文件范围内实现 Service、Controller、DTO/VO，运行接口测试。
任务 D：基于冻结契约实现前端展示，不修改后端文件。
任务 E：待所有写入停止后，对固定快照做只读审计和集成验证。

6.6 第六步：派发完整任务合同

不要只发一句“帮我实现这个功能”。子任务看不到主任务脑中的隐含背景。

一个合格的任务合同至少包含：

任务名称：

目标：
用一句话说明完成后应该得到什么。

背景：
只提供与本任务直接相关的已确认事实和冻结决策。

输入：
允许读取的文件、链接、日志、接口或已有结论。

负责范围：
必须覆盖的模块、行为和场景。

不做：
明确禁止的重构、文件、功能和外部动作。

写入所有权：
只读，或明确允许修改的路径。

成功标准：
可以检查的完成条件。

验证要求：
需要运行的测试、静态检查或运行时验证。

输出格式：
状态、结论、证据、改动文件、验证、未验证、风险、下一步。

停止条件：
何时返回 BLOCKED，而不是自行扩大范围。

6.7 第七步：观察任务，不要频繁打断

观察任务的目的，是发现阻塞和方向偏差，不是逐句遥控。

合理做法：

等到任务到达一个可汇报节点再读取状态；
补充新约束时说明它是否替代旧约束；
发现范围漂移时立即收紧合同；
多个任务依赖同一决策时，由主任务统一发布；
任务已完成或已阻塞时及时收口。

不合理做法：

每隔几分钟要求重复总结；
一边修改接口，一边让多个任务继续实现；
把新的大需求追加进原本很小的任务；
只看“正在运行”，不看是否有可验证产物。

6.8 第八步：用固定结果、独立审计和统一验证收口

子任务的最终回传至少应包含：

STATUS：COMPLETED / PARTIAL / BLOCKED

SUMMARY：最重要的结论或完成内容。

EVIDENCE：文件、行号、测试输出、截图或复现步骤。

CHANGED FILES：实际改动清单。

VERIFICATION：已运行的检查与真实结果。

UNVERIFIED：没有验证的部分以及原因。

RISKS：残余风险和可能影响。

NEXT ACTION：主任务下一步最小动作。

主任务必须检查代码、diff、测试和运行证据，不能因为子任务写了 COMPLETED 就直接放行。

图 4：执行、审计和返修闭环。审计前应暂停相关写入，确保所有人检查同一版结果。

7. 四种常见拆分方法

文章 2 把多任务拆分总结为技术层、业务域、阶段和角色。实际项目中可以组合使用，但要先理解每种方法的边界。

图 5：四种拆分方法。拆分方法不是组织口号，最终仍要落实到所有权、接口和验收。

7.1 按技术层拆分

例如前端、后端、数据库、测试。

适合：接口已经冻结，各层可以依据同一契约工作。

风险：如果字段类型、错误码和接口路径仍在变化，各层会同时返工。

7.2 按业务域拆分

例如客户、订单、支付、权限。

适合：业务模块边界清楚，每个域有相对独立的数据和行为。

风险：公共模型和共享服务可能成为冲突中心。不要只看目录不同，就误判为业务独立。

7.3 按阶段拆分

例如调查、设计、实现、测试、发布检查。

适合：前一阶段的结果必须先冻结，后一阶段才能安全开始。

风险：为了追求并行，把本来有前后依赖的阶段同时启动，导致执行建立在未确认结论上。

7.4 按角色拆分

例如实现者、测试者、审计者、文档作者。

适合：需要独立视角，尤其是实现和审计不应由同一上下文自我证明。

风险：角色不同不代表文件可以同时修改。审计者最好只读，返修再交回单一写入者。

7.5 怎样组合

一个中等功能可以这样组合：

阶段一：按角色拆分，只读调查 + 接口评审
阶段二：按技术层拆分，数据库 + 后端 + 前端
阶段三：按角色拆分，独立审计 + 集成验证

简单记法：先按依赖划阶段，再在阶段内部按技术层、业务域或角色并行。

8. 生命周期和状态怎么管理

任务状态应该反映真实生命周期，而不是聊天窗口是否还开着。

图 6：推荐任务状态机。任务关闭不等于删除历史，而是把稳定结果封存，让新工作进入新阶段。

状态	含义	主任务动作
Draft	目标或边界仍不完整	补合同，不派发
Ready	输入、依赖和所有权已确认	可以启动
Running	正在执行	低频观察，处理阻塞
Review	已回传结果，等待审查	固定快照并核验证据
Rework	审计发现明确问题	发有限返修合同
Blocked	缺少输入、权限、环境或决策	记录最小阻塞项
Accepted	成功标准已满足	更新三本账
Archived	阶段已封存	不再继续追加新目标

达到以下任一条件时，应停止向原任务继续追加：

当前目标已经验收；
需求变化使原合同失效；
文件所有权开始重叠；
多轮返修后需要重新定义问题；
任务无法从当前上下文可靠恢复；
下一步需要用户做关键决定。

9. 可以直接复制的提示词

模板的作用是减少遗漏，不是让所有任务机械地写同样的长文。使用时应删掉无关字段。

9.1 主任务初始化模板

你是本阶段的主任务控制台。

总目标：
[描述最终结果]

当前阶段：
[调查 / 设计 / 实现 / 验证]

已确认事实：
[只列与本阶段有关的事实]

冻结决策：
[接口、数据结构、范围和禁止事项]

成功标准：
[可检查的验收条件]

你的职责：
1. 先只读确认影响范围和依赖；
2. 把工作拆成有限、可独立验收的任务；
3. 分配文件所有权，避免重叠写入；
4. 要求结构化回执和验证证据；
5. 对固定快照做审计和统一验证；
6. 阶段结束后封存，不无限续派旧任务。

不要：
- 扩大目标；
- 假设任务之间自动同步；
- 用子任务的 COMPLETED 代替你的验收；
- 把全部聊天历史复制进计划。

9.2 子任务执行模板

你只负责以下有限工作单元。

目标：[一句话]
输入：[文件、接口、日志或结论]
负责范围：[模块和行为]
不做：[明确排除项]
写入所有权：[只读或具体路径]
成功标准：[可验证条件]
验证要求：[测试、检查或运行步骤]
停止条件：[何时返回 BLOCKED]

开始前复述边界；执行时不要顺手重构；结束时回传：
STATUS / SUMMARY / EVIDENCE / CHANGED FILES /
VERIFICATION / UNVERIFIED / RISKS / NEXT ACTION。

9.3 只读审计模板

你只做只读审计，不修改任何文件。

审计对象：[固定提交、分支或快照]
成功标准：[逐条列出]
重点风险：[行为回归、遗漏场景、所有权冲突等]

请按严重程度输出：
1. 可复现问题；
2. 文件和行号证据；
3. 为什么违反成功标准；
4. 建议的最小修复方向；
5. 未能验证的部分。

没有问题时明确写“未发现问题”，同时列出残余验证缺口。

9.4 有限返修模板

本轮只修复以下审计问题，不扩大范围：

问题：[明确现象]
证据：[文件、行号、测试或复现步骤]
期望行为：[修复后应满足什么]
允许修改：[具体文件]
禁止修改：[范围外文件和重构]
回归检查：[必须重新运行的检查]

修复后回传真实 diff、验证结果和仍未解决的风险。

9.5 阶段收口模板

请对当前阶段收口，不继续实现新需求。

输出：
1. 阶段目标是否完成；
2. 已验收产物及位置；
3. 已运行验证及结果；
4. 未验证项和原因；
5. 决策账新增内容；
6. 任务账最终状态；
7. 产物账索引；
8. 下一阶段最小输入；
9. 哪些旧任务应归档。

9.6 新阶段交接模板

你将接管一个新阶段。不要假设旧任务的全部判断仍然有效。

项目目标：[长期目标]
本阶段目标：[有限目标]
已验收基线：[提交、测试和运行状态]
冻结决策：[结论及理由]
证据索引：[只给定位入口]
已知失败路线：[避免重复试错]
未解决风险：[按优先级]
允许范围：[文件、模块和外部动作]

开始时先做冷启动验收：
1. 复述目标和禁止事项；
2. 从证据索引定位两项关键事实；
3. 说明一个已知风险；
4. 给出本阶段第一步。
无法完成时返回交接缺口，不要直接开始修改。

10. 实战案例一：并行完成一篇深度文章

内容创作同样适合子任务，但不能把章节随意分给不同任务后直接拼接。文章需要统一观点、读者和术语。

10.1 错误拆法

任务 A 写前五章
任务 B 写后五章
任务 C 写总结

这种拆法容易出现重复、立场不一致、术语冲突和引用断裂。

10.2 更合理的拆法

图 7：深度文章协作。研究可以并行，核心叙事最好由一个主写任务统一完成。

10.3 为什么有效

资料核对、反例和案例收集相互独立；
主任务保留统一叙事和最终取舍；
审稿任务只读，不会与写作者同时改稿；
所有引用和结论可以统一检查。

11. 实战案例二：Spring Boot 增加 customerLevel 字段

下面用一个常见功能演示同仓库并行开发。需求是给客户模型增加 customerLevel，并贯通数据库、后端接口、前端展示和测试。

11.1 先冻结契约

主任务先确认：

字段名：customerLevel
类型：枚举字符串
允许值：NORMAL / VIP / ENTERPRISE
默认值：NORMAL
数据库列：customer_level
查询接口：返回该字段
新增/更新接口：接受并校验该字段
兼容要求：旧数据迁移后为 NORMAL

如果这些内容没有冻结，数据库、后端和前端同时开工只会制造返工。

11.2 拆分任务

任务	负责范围	写入所有权	验证
A 数据层	migration、Entity、Mapper/Repository	数据库和持久层文件	migration + repository test
B 业务与接口	Service、DTO、VO、Controller、校验	后端业务与接口文件	unit + API test
C 前端	类型定义、表单、列表展示	前端相关文件	type check + UI test
D 审计	契约一致性、兼容性、遗漏场景	只读	findings + evidence
M 主任务	冻结接口、处理冲突、集成验证	控制文件或无写入	full focused suite

11.3 执行顺序

图 8：customerLevel 案例的并行开发流程。并行发生在契约冻结之后，统一验收发生在合并之后。

11.4 主任务最终检查

旧数据是否得到默认值？
无效枚举是否返回明确错误？
DTO、VO、数据库和前端类型是否一致？
查询、新增、更新是否都覆盖？
序列化命名是否一致？
回滚 migration 是否可用？
前端未识别新值时是否有安全显示？

这个案例适合子任务，不是因为它涉及多个技术层，而是因为接口能够先冻结，各层结果也能单独测试。

12. 实战案例三：并行排查一个偶发 Bug

Bug 排查适合并行“调查假设”，不适合多个任务同时修改同一处核心逻辑。

假设现象是：用户偶尔保存成功，但页面刷新后字段又恢复旧值。

12.1 先建立可证伪假设

假设 A：前端没有发送新字段。
假设 B：后端 DTO 接收了字段，但映射时丢失。
假设 C：数据库事务回滚或更新条件未命中。
假设 D：保存成功后读取了旧缓存。

12.2 并行调查，单点修复

图 9：Bug 并行调查流程。多个任务可以读同一系统，但最终写入应收敛到一个修复者。

12.3 每个调查任务必须回传什么

假设：
检查路径：
观察到的事实：
支持证据：
反对证据：
结论：支持 / 不支持 / 证据不足
下一步最小实验：

不要让四个任务分别“顺手修一下”。否则根因没有收敛，代码却同时发生多处变化，最后很难知道哪项修改真正解决了问题。

13. Worktree 能解决什么，不能解决什么

很多人把 Worktree 当成并行开发的完整答案。实际上，它只解决其中一层。

13.1 它能解决

不同任务拥有独立工作目录；
未提交修改不会直接混在一起；
每个任务可以保留独立分支和 diff；
失败尝试更容易丢弃或单独审查。

13.2 它不能解决

两个分支对同一接口做出不同假设；
两个任务修改不同文件却改变同一行为；
合并顺序带来的运行时回归；
一个任务没有收到最新冻结决策；
主任务无法审查过多并行结果。

13.3 推荐合并流程

冻结接口
→ 分配 Worktree 和文件所有权
→ 各任务提交独立结果
→ 主任务检查每个 diff
→ 按依赖顺序合并
→ 在统一快照上运行集成验证
→ 独立审计
→ 收口

简单记法：

Worktree 解决“在哪里改”，任务合同解决“应该改什么”，统一验收解决“改完能不能一起工作”。

14. 为什么语义持续扩张的永久主线会遇到上下文问题

这一节是全文的核心分析。

14.1 1 对多会形成持续的信息汇聚

主任务要接收每个子任务的结果、风险、冲突和返修。如果项目持续增长，主任务面对的不是一次性输入，而是持续扇入。

图 10：永久主线的信息扇入。增加并发可以缩短局部执行时间，但会增加主任务的接收、比较和验收工作。

14.2 项目熟悉度不能被无限压缩

要正确实现需求，执行者通常需要知道：

当前架构和调用链；
已冻结的行为约定；
历史上试过但失败的路线；
跨模块影响；
原始需求和后续变更；
哪些证据可靠，哪些只是推测。

如果把这些全部删除，新任务不再熟悉项目；如果全部保留，上下文又会越来越大。这是长期代理工作的基本张力。

14.3 多加几级“主管”只能重新分配信息流

企业类比很直观：人是客户，主线是 CEO，分区主线是主管，子任务是执行者。

增加主管可以减少 CEO 直接面对的任务数量，但不能消除：

部门之间的接口冲突；
必须上升的关键决策；
主管摘要中的信息损失；
跨部门验收；
最终责任人需要理解的全局影响。

所以，层级可以降低直接扇出，却不会降低项目的总语义量。

14.4 交接摘要存在结构性信息损失风险

摘要擅长保存“发生了什么”，却容易丢失：

为什么没有选择另一个方案；
哪些看似合理的路径已经失败；
某条证据的可信度为什么较低；
一个局部约束与哪些历史问题有关；
原执行者在多次对比后形成的判断权重。

摘要越短，遗漏越多；摘要越长，新主线的读取和判断成本越接近重新加载旧上下文。

因此，“交接文件已被读取”不等于“新主线已经具备原主线的工作能力”。

14.5 状态管理器、Plan 和知识库的真实价值

这些工具当然有用。它们能够：

保存任务状态；
标记所有权和依赖；
记录已验收产物；
降低中断后的恢复成本；
减少重复调查；
让遗漏更容易被发现。

但它们不能自动保存全部因果知识和隐含判断，也不能保证文档永远新鲜。

方法	能解决	不能根治
多级主线	降低单点直接扇出	总信息量和跨域决策
状态管理器	任务状态、依赖和所有权	完整项目理解
持久化 Plan	恢复入口和显式约束	隐含判断、陈旧风险
更大上下文窗口	延后容量临界点	持续增长和注意力竞争
更长交接文档	保存更多事实	阅读成本和信息权重丢失
Worktree	文件和分支隔离	语义同步和整体正确性

结论不是“这些方法没用”，而是要正确定位：它们降低风险、延缓退化，却不是无限上下文的根治方案。

15. 长期复杂项目如何使用阶段化子任务

阶段化的目标不是让代理忘掉项目，而是限制当前必须同时保持活跃的工作集。

因此，本文给出的工程建议仍然是：

Codex 子任务模式适合轻量到中等规模的有限工作单元；长期复杂项目可以使用“阶段化子任务”，但不应使用永久主线和永久子任务的连续运行模式。

15.1 阶段模型

图 11：阶段化子任务。长期保留的是目标、事实、决策和已验收基线，而不是永久保持同一组对话身份。

15.2 区分四种身份

taskId：长期逻辑目标
phaseId：当前自然阶段
attemptId：本轮实施或返修
threadId：本轮对话载体

长期逻辑目标可以稳定，当前阶段和本轮尝试必须能够结束，对话载体则可以替换。

15.3 稳定保留什么

项目事实和版本基线；
已确认决策及理由；
对外接口和不变量；
证据索引；
阶段验收结果；
未解决风险；
下一阶段输入。

15.4 不要求永久保留什么

同一个主任务身份；
同一个子任务身份；
全部聊天历史始终处于活跃上下文；
已结束阶段的所有中间尝试；
已经失效的计划细节。

15.5 阶段结束条件

一个阶段应该在以下条件满足时结束：

阶段目标有明确验收结论；
代码、测试和文档处于固定基线；
决策账、任务账和产物账已更新；
未解决风险被明确保留；
下一阶段可以从有限输入启动；
原阶段任务被归档，不再追加新目标。

15.6 冷启动交接验收

不要只检查新主线“是否读过交接文档”。应检查它能否实际工作：

能否复述本阶段目标和禁止事项？
能否从证据索引找到关键事实？
能否说明一个历史失败路线及原因？
能否识别当前最高风险？
能否给出符合依赖顺序的第一步？

答不出来，说明交接还没有形成工作能力。

16. 常见失败方式

下面不按抽象理论分类，而按你在项目里会直接看到的症状来写。

16.1 症状一：子任务很多，结果却不能合并

原因：按“工作量”拆分，没有冻结接口、所有权和验收标准。

处理：回到依赖图，先冻结共享契约，再按可独立验收的单元拆分。

16.2 症状二：多个任务都改了同一批文件

原因：把不同角色误认为不同写入范围，或者没有指定单一写入者。

处理：暂停写入，固定快照，选择一个任务整合；其他任务只读审计。

16.3 症状三：主任务说完成，运行时却没通过

原因：把“代码已写”“静态检查通过”“真实环境验收通过”混为一谈。

处理：分别记录实现状态、自动验证状态和运行验收状态；未验证项必须显式保留。

16.4 症状四：任务之间不断出现旧结论

原因：假设它们会自动同步，或者冻结决策没有进入决策账。

处理：由主任务发布一次权威更新，注明替代哪条旧结论，并要求受影响任务复述。

16.5 症状五：任务越来越长，只能不断总结

原因：旧任务被永久续派，目标和阶段已经变化，但身份没有结束。

处理：完成当前最小验收，封存事实和风险，创建新阶段任务。

16.6 症状六：主任务整天处理汇报，没有时间验收

原因：并发量超过验收带宽，主任务成为摘要搬运工。

处理：减少在途任务；合并低价值调查；只保留能改变决策的回报；按完成顺序验收。

16.7 症状七：任务粒度过小

表现：创建、同步、等待和收口比实际工作更费时间。

处理：把能够由同一上下文、同一所有权、同一验证一起完成的步骤合并。

16.8 症状八：任务粒度过大

表现：任务需要反复向主线询问背景，改动范围膨胀，无法独立验收。

处理：按自然阶段拆分，先调查和冻结，再实现和审计。

17. 注意力、用量和验收带宽

并行任务不是免费的速度倍增器。它会同时消耗模型用量、人的注意力和主任务的验收能力。

17.1 真正的瓶颈通常会转移

执行任务较少时：瓶颈在实现
执行任务增加后：瓶颈转到结果阅读
结果继续增加后：瓶颈转到冲突处理和统一验收

所以，并发上限不应由“最多能开多少任务”决定，而应由“主任务能可靠验收多少结果”决定。

17.2 用量控制原则

先并行只读调查，再决定哪些实现值得启动；
不让多个任务重复读取同一批大文件；
任务包只提供相关事实，不复制全部历史；
状态更新只报告新变化，不重复完整背景；
失败的假设及时停止，不为了“已经花了用量”继续运行；
大范围任务先做一个小样本，确认拆分方式有效；
定期查看当前客户端提供的用量或配额信息，具体入口以产品版本为准。

17.3 设定在途任务上限

主任务当前状态	建议在途任务
需求和接口仍不稳定	0～2 个只读调查
接口冻结、边界清楚	少量并行实现
正在合并和审计	暂停新增写入任务
已出现多轮返修	降低并发，重新定义阶段

不要追求一个适用于所有项目的固定数字。任务复杂度、验证成本和人的参与程度都会改变上限。

18. 团队如何落地

团队落地不应一开始就把整个项目改成多任务模式。更稳妥的做法是从一个边界清楚的功能试点。

18.1 最小角色分工

角色	主要责任	不应承担
需求负责人	确认目标、优先级和外部取舍	逐条遥控实现
主任务负责人	拆分、所有权、决策账、统一验收	替每个任务亲自实现
执行任务	完成有限工作并提供证据	自行扩大范围
审计任务	固定快照只读检查	一边审计一边大改
仓库维护者	分支、Worktree、合并和 CI 规则	用合并成功代替行为验收

18.2 四步试点

选择一个中等规模、接口可冻结的功能。
只使用一主、两到三个执行任务和一个审计任务。
记录返修轮次、冲突数量、验收时间和未验证项。
复盘后再决定是否扩大，而不是只看“并行任务完成得很快”。

18.3 团队应统一的规则

任务合同的最小字段；
文件所有权和冲突处理；
决策账的权威位置；
COMPLETED、PARTIAL、BLOCKED 的含义；
哪些验证可以由任务自动运行；
哪些外部动作必须由人确认；
阶段结束和任务归档条件；
谁拥有最终验收权。

18.4 建议观察的指标

首次验收通过率；
每个任务平均返修轮次；
共享文件冲突次数；
未验证项在交付前的关闭率；
主任务用于验收而非摘要整理的时间比例；
新阶段冷启动时发现的交接缺口。

这些指标比“开了多少子任务”更能说明模式是否有效。

19. 三种模式的最小配置

前文已经说明三种规模如何判断。这里不再重复流程，只列真正开始使用时的最小配置。

模式	任务组合	必要记录	Worktree	验收方式	结束方式
轻量模式	一主一支或一主两支	一份任务合同即可	通常不需要	主任务直接检查	完成后关闭
中等模式	分析、实现、审计	决策账、任务账、产物账	按写入范围选择	固定快照审计 + 集成验证	功能验收后归档
长期复杂模式	多个有限阶段任务组	长期事实、阶段基线、风险和证据索引	只在阶段内使用	每阶段独立验收	封存阶段并创建新任务

简单记法：轻量任务减少管理，中等任务加强控制，长期复杂项目主动结束上下文。

20. 启动、运行和收口清单

20.1 启动前

总目标能否用一句话说明？
成功标准是否可以检查？
是否先做了只读影响分析？
接口和不变量是否已经冻结？
每个任务是否能够独立验收？
写入所有权是否不重叠？
Create、Fork、Subagent 是否选择正确？
Local 或 Worktree 是否有明确理由？
并发量是否低于验收带宽？

20.2 运行中

子任务是否仍在合同范围内？
新决策是否统一同步并替代旧结论？
是否出现共享文件或接口冲突？
状态更新是否只报告新变化？
阻塞项是否足够具体？
是否有人把局部完成误写成整体完成？
是否需要暂停新写入，先处理验收积压？

20.3 收口时

子任务是否提供了真实 diff 和证据？
已验证和未验证是否分开？
是否对固定快照做了独立审计？
是否运行了统一集成验证？
决策账、任务账、产物账是否更新？
残余风险是否明确交给人？
当前任务是否应该归档？
下一阶段是否能从有限输入冷启动？

21. 研究问题、案例证据与论证边界

前面的内容主要是教程。这一节把论点、证据和局限集中列出，说明最终结论是怎样得到的。

21.1 研究问题

RQ1：Codex 子任务模式实际解决了哪些工程问题？
RQ2：哪些任务特征决定它能否提高效率？
RQ3：为什么分层主线、状态管理和交接摘要仍不能根治长期上下文问题？
RQ4：长期复杂项目怎样保留子任务收益，同时控制上下文风险？

21.2 参考实践的贡献与共同前提

文章 1 的主要贡献是：区分任务形态，建立主对话控制面，强调控制面、任务面、证据面和三本账，并给出 Create、Fork、Worktree、任务包、观察、纠偏和收口方法 [1]。

文章 2 的主要贡献是：以工程职责和模块边界拆分多任务，强调接口冻结、写入范围、统一验证，并通过功能开发和 Bug 排查展示标准流程 [2]。

另外三篇 CSDN 教程强调了编号步骤、短段落、直接判断、Local/Worktree 选择和冲突边界 [3][4][5]。本文借鉴的是它们面向新人的表达方式，而不是把实践文章当成学术证明。

两篇文章虽然写法不同，却共享一个前提：

子任务需要被拆成边界清晰、依赖有限、结果能够独立验收的有限工作单元。

本文进一步讨论的是：当这个前提在长期复杂项目中逐渐失效时，会发生什么。

21.3 六个命题

命题	机制解释	工程含义
P1 边界越清楚，子任务收益越高	沟通、冲突和返修成本更低	先拆边界，再谈并行
P2 持续审计和跨域协调会让主线上下文呈累积趋势	结果、异常和新决策不断向上汇聚	主任务不应永久运行
P3 增加层级不能消除总语义量	摘要、冲突和关键决策仍需向上流动	分层只能延缓压力
P4 正确实现需要项目熟悉度	结构、历史决策和负面知识不能无限压缩	交接不能只传状态
P5 计划和状态管理降低恢复成本，但不保存全部判断	显式字段难以包含完整因果和证据权重	把工具定位为风险控制
P6 阶段化可以限制活跃工作集	已验收事实长期保存，执行上下文按阶段重建	长期项目使用有限阶段

21.4 匿名长期案例的演进

本文使用一个长期、高耦合项目作为纵向案例。为避免暴露私人项目和任务信息，只保留机制层面的观察。

初始主线负责拆分和审计
→ 引入状态管理、所有权和结构化回执
→ 子任务执行变得更规范
→ 主线持续吸收多模块结果和返修
→ 更换新主线并编写交接材料
→ 新主线能读取状态，却遗漏部分冻结理由和失败路径
→ 尝试增加分区主线和更长摘要
→ 直接扇出下降，但跨域决策和总语义量仍然汇聚
→ 最终转向阶段化任务

21.5 案例记录、替代解释与判断

观察现象	案例记录	可替代解释	本文判断
新主线接管后遗漏关键约束	状态和计划已交接，但部分冻结理由没有转化为工作判断	交接文档不够完整	文档质量很重要，但完整性与工作能力仍不是同一件事
状态管理后仍出现理解偏差	任务状态正确，执行方向却使用了旧前提	状态更新延迟	状态字段不能保存全部语义和因果
增加层级后主线仍膨胀	分区结果、冲突和跨域决策继续向上汇总	汇报格式过长	缩短汇报能减负，但不能消除必须处理的信息
阶段封存后可从有限基线重新启动	新阶段从已验收基线和有限风险启动	新阶段恰好更简单	阶段化缩小了恢复范围，但不能据此证明对所有项目都更优

21.6 完整论证链

正确实现需要项目熟悉度
→ 熟悉度包含结构、历史决策、失败路线和跨模块知识
→ 子任务结果必须回流主任务，以便审计和协调
→ 工作量与返修轮次增加，使信息持续汇聚
→ 摘要会压缩决策理由、负面知识和证据权重
→ 新主线读取摘要后，不一定恢复原主线的判断能力
→ 层级、计划、状态机和更大窗口只能延缓这一过程
→ 永久主线与永久子任务不具备稳定的长期可持续性
→ 子任务应限定为有限工作单元，长期项目应阶段化使用