一个越来越普遍的卡点

这两年工程团队的工作方式变了一个量级。以前一个大目标拆给三五个人，大家坐在一起，边界不清楚可以当面问，验收不严格可以靠默契兜底。现在不一样了：同一个目标可能同时有人类工程师、多个 AI 执行者、几条互相依赖的仓库线在推进。执行者的上下文是有限的，会话会断，接手的人未必参与过前期讨论，甚至未必是人。

于是一种新的卡点浮现出来，而且在越来越多的团队里重复上演：

• 任务拆了，但没人能单独开工。 子任务写着"完善 X 模块"，接手者打开后发现要先读完半个仓库才知道从哪下手。
• “完成"经不起追问。 PR 合了、CI 绿了、issue 关了，合到一起一跑，功能并不存在。问起来，每个人都能拿出自己那块的证据，但没有一份证据覆盖整体。
• 交接等于重做。 换一个执行者，或者 AI 会话一断，前面积累的判断、踩过的坑、剩下的缺口全部归零。
• 并行变成互相等待。 依赖写成"等 A 做完”，A 做完的定义又没人说清，结果一条线上的所有人都在等一个谁也说不清的时刻。

这些问题的共同点是：协作从"靠默契"变成了"靠书面"，但书面的那部分没有跟上。任务描述还是写给"随时能来问我"的同事看的，而真正执行它的人或模型，根本没有这个条件。

我们在几条并行推进的大型工程线上把这些坑挨个踩了一遍，然后把有效的做法沉淀成一套方法。它不新鲜，但每一条背后都有一次真实的返工。下面把精华和落地方式写出来，去掉了项目细节，文末附上可以直接复制的父任务和子任务模板。

核心判断：任务是否"拆好了"，只看三件事

一个任务拆分是否合格，不看条目多不多、分得匀不匀，只看三个问题：

1. 能不能认领：一个没参与过前期讨论的人，只读这条任务和它列出的材料，能否开工？
2. 能不能独立验证：做完之后，什么样的实现错误会让验收失败？如果答不上来，验收就是摆设。
3. 能不能交接：做到一半换人，接手者能否不丢信息地继续？

三个问题都能回答"是"，才算拆好了。下面的所有实操，都是围绕这三点展开。

一、先写最终结果，再划边界

很多拆分从一开始就错了：拿到一个大目标，直接按模块、按目录、按人头分。这样分出来的任务，每个人都在做"自己那块"，但没人对最终的整体负责。

正确的顺序是先让父任务回答四个问题：

• 完成之后，用户或调用方能做什么？
• 这个能力在哪些真实环境下成立？
• 哪些能力明确不在本次范围内？
• 什么证据齐备后，这个父任务才可以关闭？

写清这四条，再去核对当前代码、已有的 issue 和 PR，找出真实缺口。已经有人在做的就引用，不要再建一份平行清单。需求还不清楚的部分，老老实实标成"待决项"，不要把猜测写成已确定的方案。

二、一个子任务只交付一个可验证的结果

拆分的切口应该是行为、接口、事务或故障边界，而不是文件目录。标题用"动作 + 对象 + 结果"的格式，比如"取消等待后仍保持持久写入顺序"，而不是"完善存储模块"。前者能验，后者不能。

每个子任务要能说清自己的输入、产出、修改范围和验证方式。不要求每项都能独立发布：底层能力、适配层、完整链路可以分别交付，但父任务必须保留最终的集成验收，不能因为拆了就把整体要求拆没了。

遇到下面几种情况，要继续拆：

• 边界未知。不知道真实的调用链、恢复点在哪里，就先建一个只读调查任务，交付固定的代码版本、精确到行的位置、调用关系、已有测试和证据缺口。注意：调查完成不等于能力通过，这是两件事。
• 一个任务含多个独立结果。比如"空库启用"和"已有数据迁移"，要分开。
• 测试和实现合起来超预算。只有当测试接口、夹具和失败断言能被固定下来时，才按职责拆开：测试任务交付一个能编译、会真实失败的用例，实现任务依赖这个提交，两者联合验收后才算完成。失败的 stub 不能合进正式分支。

有一种假拆分要警惕：只为了减少文件数而搬代码、造抽象或换执行者。这不是拆分，是把复杂度挪了个地方。该做的是重新缩小真实的责任边界。

三、依赖写成"需要什么产出"，而不是"等谁做完"

“依赖 A 任务"这种写法几乎没有信息量。每条前置都要写明：需要什么能力、对应哪个任务、哪个提交已被接受、验收证据在哪。

一个反直觉但非常重要的规则：issue 关闭、PR 已开、单项 CI 通过，都不足以证明前置就绪。 还要确认那个提交已经进入了指定的集成分支。我们不止一次遇到"前置明明关了，拉下来代码里却没有"的情况。

先画依赖图，再排批次（wave）。没有相互依赖、没有公共写入冲突的任务可以并行，不必把一条线上的前置重构排在另一条线全部收尾之后。但共享的接口、依赖锁文件、模块导出、集成分支，要指定唯一的整合者，并明确编译、数据库、端口这些资源是否需要串行。

父任务要并行委派时，先声明并发上限。我们用过的一个配置是"最多 3 个开发任务 + 1 个集成槽位”。wave 编号表示"最早可以开始的批次"，不是"这一批同时启动的数量"。也不要递归委派，一层就够了。

四、把预算写进任务里

这是整套方法里最有争议、也最有效的一条。

每个小任务默认有硬预算：读取与修改的来源并集不超过 8 个具体文件，累计上下文不超过 40k tokens。 适用的指令文件、测试、依赖声明、外部接口源码、被读取的契约文件全部计入。不允许用目录、通配符、生成的摘要或截断的输出来隐藏实际读取范围。

预算统计覆盖输入、输出、分析、编辑和消息的全部消耗。换会话或换执行者，不能让同一个未完成的职责归零重算。

接近上限时先交接。发现第九个必要来源，或者冒出一个新的接口边界，说明当初的拆分有问题，应该保留证据缺口、重新拆，而不是硬撑着做完。确实需要别的预算，由父任务明确记录，执行中不允许静默放宽。

这条规则的价值在于：它逼着拆分者在开工前真正想清楚边界。一个任务如果列不出 8 个以内的具体文件，大概率是边界还没想清楚，或者藏着一个该先做的调查。

五、验收要能回答"什么错误会让它失败"

“测试通过"不是验收条件。验收必须能回答：什么样的实现错误会让它失败？

具体写法：

• 固定候选提交、依赖版本、配置和运行环境。命令可以直接复制，预期写成退出码、实际发现的测试名、结果数量或明确的断言。不要把旧任务的测试数量硬套到新基线上。
• 行为变更要先拿到真实的失败，再实现、再转绿。编译失败、零测试、跳过、服务没启动、只打印了 PASS，这些都不算行为证据。文档、依赖注册这类非行为任务按仓库对应等级验证即可，不用制造无意义的红灯。
• 对安全、持久化、并发、迁移这类关键不变量，要写变异对照：故意破坏哪个生产行为、必须命中哪条断言。变异要能成功编译、执行到指定测试、在指定断言上失败。超时和环境故障不算命中。恢复之后要核对源码，并重新跑通受影响的测试。
• 需要真实数据库、容器、节点故障、旧版本二进制的验收，必须用对应的真实环境。模型、mock、内存实现只能证明各自的范围。一条路径上的证据不能直接推导到另一条路径上。
• 单项验收通过后，整合者要在最终组合提交上复跑受影响的门禁。既有的断言、故障场景和兼容要求不能因为拆了任务就消失。发布或切换还要满足父任务的端到端、升级回滚和性能要求。

六、认领与交接：Claim 和 Handoff

同一个子任务只保留一个活动的 Claim。每个任务用独立的分支或工作目录。接手前先看最新的认领和交接记录，不能只凭"看起来没人做"就接管。到期、释放、重新分配都要按父任务定的规则留痕。

Claim 要写清：执行者和机器、子任务和基准版本、分支标识、前置的接受证据、本次范围、占用的资源槽位、开始时间和预计交付。

Handoff 固定四段：

• Done：实际完成的结果，提交或 PR 链接，命令、退出码和候选版本。
• Not done：仍缺的验收、未证明的能力、明确的阻塞。
• Next command：下一条可以直接执行的命令，或者在等哪个前置产出。
• Gotcha：兼容和恢复风险、共享资源、来源和上下文累计用量、接手注意事项。

父任务用一组固定状态表达进度：待前置、可认领、执行中、待验收、已接受、阻塞。

两条容易混淆的边界：Handoff 结束的是认领，不自动代表任务完成；PR 合并和 issue 关闭也不自动代表能力已验收。验收者核对最终提交和全部交付条件后标记"已接受”，父任务满足整体关闭条件后才关闭。

发布任务前的五个自检

把任务发出去之前，最后过一遍：

1. 别人只读这条 issue 和列出的来源，能不能开工？
2. 前置是否具体到"需要什么产出、证据在哪"？
3. 验收能不能发现错误？
4. 所有原始需求是否仍有人负责？
5. 证据不足时，执行者是否知道该停在哪里？

五条里有一条答不上来，就还没到发布的时候。

写在最后

这套方法看起来繁琐，但每一条约束都对应一次真实的返工。它的本质是把"默契"变成"书面契约"：边界写明、依赖写明、预算写明、验收写明、交接写明。

它对人有用，对 AI 执行者更有用。当执行者的上下文有限、不能随时回头问人时，一条写清楚的任务就是全部。只读调查、硬预算、可失败的验收、四段式交接，这些不是官僚流程，是让协作在信息不完整的条件下依然能收敛的工程手段。

如果你的团队也在多人、多线、多执行者的协作里反复返工，不妨从"验收能不能发现错误"和"8 个文件 40k 预算"这两条开始试。下面两份模板可以直接复制到你的 issue 系统里开干。

附录 A：父任务模板

父任务是唯一的汇总入口。详细证据放子任务，这里只维护目标、基线、约定、依赖表和关闭条件。拆分或替换子任务时保留旧到新的映射和原验收，不靠关闭旧任务消除缺口。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# [项目/主题] <最终要交付的结果>

## 目标与范围
- 完成后可观察的行为：
- 本次包含 / 明确不包含：
- 真实运行环境与兼容要求：

## 已核实基线
- 仓库、基准 commit、指定集成分支：
- 现有能力与证据链接：
- 缺口、待决项、已有相关 issue/PR：

## 交付与协作约定
- 提交方式、PR base、必需检查、合并/发布权限：
- 来源与上下文预算、并发上限、共享资源限制：
- 整合者、Claim 释放/接管规则：

## 任务与依赖
| ID / 子 issue | 可验证结果 | 前置产出 | 责任仓库 / 范围 | 最早 wave | 状态 / 当前负责者 | 已接受提交 / 证据 |
| --- | --- | --- | --- | --- | --- | --- |
| <ID / 链接> | <一句话> | <ID + 需要什么，或无> | <仓库 / 边界> | <编号> | <状态> | <链接> |

## 整体验收与关闭条件
- 需求 → 子任务 → 验收的对应关系：
- 最终组合提交与真实全链路验收：
- 适用的安全、故障、性能、旧数据与回滚门禁：
- 尚未证明的能力、解除阻塞所需证据：
- 发布/切换条件与失败后的恢复方式：

## 当前进度
维护上表作为唯一汇总入口；详细证据放子 issue。
拆分或替换任务时保留旧 → 新映射和原验收，不靠关闭旧 issue 消除缺口。

状态栏建议只用这六个词：待前置、可认领、执行中、待验收、已接受、阻塞。

附录 B：可执行子任务模板

一个子任务对应一个可验证结果。只读调查类任务的验收是问题清单和可定位证据，不要求产品提交或测试通过。路径和命令还没查明时不要填想象出来的内容，先建一个有边界的调查任务。小型改动可以合并栏目，但目标、边界、前置、验收和交付责任不能省略。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# [<主题>][<ID>] <动作 + 对象 + 可验证结果>

父任务：<链接>
类型：<只读调查 / 非行为准备 / 行为实现 / 集成验收>
仓库 / 基准 commit / 集成分支 / PR base：
前置：<issue + 所需能力 + 已接受提交 + 证据，或无>
后继：<谁消费本项产出>

## 目标
一句话说明完成后什么成立，以及产出的接口/契约。

## 范围与预算
- 读取与修改的具体文件并集：逐项列出，标注只读/修改/新增。
- 适用指令、测试、依赖和导出文件已经计入。
- 来源 / 累计上下文预算：
- 共享文件、构建槽位和外部环境限制：
- 不做什么、不能改变的语义：

## 实施步骤
1. <在哪个文件/真实入口完成什么>
2. <错误、取消、重试、恢复等适用边界>
3. <如何交付给后继；未知路径先转调查>

## 验收
- 候选 SHA、依赖和环境：
- <命令> → <发现哪些测试、退出码和具体预期>
- <具名场景> → <正确行为及禁止出现的结果>
- 既有回归与最终组合需要复跑的门禁：
- 行为失败对照：<实际入口、输入、指定失败断言；不适用时说明>
- 变异对照：<破坏位点/行为 → 指定断言 → 恢复验证；按风险填写>
- 风险、回滚方式、当前证据不能证明的范围：

## 交付与停止条件
- 交付物：<只读证据 / commit / PR / 集成验收记录> + Handoff。
- 验收者与接受条件：
- 前置缺失、必要来源超预算或目标改变时先交接并重拆；保留未完成项。
- 提交/推送/合并方式遵守父任务和目标仓库约定，不从其他项目继承权限。

附录 C：Claim 与 Handoff

认领和交接直接以评论形式贴在子任务下。同一任务只保留一个活动 Claim。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

### Claim
执行者 / 机器：
子任务、基准 SHA、分支 / worktree 标识：
前置接受证据：
本次范围、资源槽位、开始时间、预计交付：

### Handoff
Done：实际完成的结果；commit/PR/证据链接；命令、退出码及候选 SHA。
Not done：仍缺的验收、未证明的能力、明确阻塞。
Next command：下一条可执行命令，或等待哪个前置产出。
Gotcha：兼容/恢复风险、共享资源、来源和上下文累计、接手注意事项。
当前 Claim：结束；任务状态与下一负责人：