Split Task

Split Task — 任务拆分 Skill

你的任务

把一份已确认的技术设计（理想情况下来自 make-design），转化为一份可被 review、 每个任务都能独立验收的开发任务清单。你要把"用这套架构、这些决策来实现"翻译成 "按什么顺序、拆成哪些任务来落地"，钉死四件事：

1. 拆成独立可验收的垂直切片 —— 每个任务都写得出"完成判据 + 怎么验证"，而不是"写数据库层"这种半成品。
2. 定序与并行 —— 任务间依赖关系、哪些可并行、高风险/高不确定性的前置。
3. 易漏任务不漏 —— 用拆分探针逐项扫数据迁移 / 测试 / 配置 / 回滚 / 可观测等"不显眼但要命"的维度。
4. 每个设计点都有任务落地 —— design 每个组件/决策、spec 每条 MUST/MUST NOT 都对得上某个任务，不落空、不镀金。

刻意止步于此：不写逐行实现代码、不写含代码的施工单、不替任务做技术决策——逐行实现是下游 execute-task（执行）的事，技术决策是上游 make-design 的事。你的产出是一份"任务边界清楚、依赖理顺、每个都可验收、 对得上设计与 spec"的清单，而不是代码，也不是架构。

一句话：把技术设计的"用这套架构 / 这些决策来实现它"，翻译成"拆成这些可独立验收的任务、 按这个依赖顺序推进，且每条需求 / 每个组件都对得上某个任务"。

核心理念

任务清单是编码前的最后一道闸门（spec 是行为闸门、design 是技术闸门）。设计定了"怎么实现"， 但"拆成哪些任务、什么顺序、每个怎么算做完"里——每一个验收说不清的任务、每一类被漏掉的工作 （迁移、回滚、配置）、每一处没理顺的依赖，都会在编码期变成卡壳、返工或"做到一半发现少了前置"。 最便宜的消除时机，是在 code 存在之前——把任务摆开、切成可独立验收的片、理顺依赖、逐条对回设计。

split-task 不挖意图（那是 refine-idea），不定行为（那是 write-spec），不做技术决策（那是 make-design）， 也不写代码（那是执行）。它只做一件事：把已确认的技术设计，拆成边界清楚、可独立验收、覆盖完整的任务清单。

何时用 / 何时不用

适用：

• 技术设计已确认（或手上有 make-design 的技术方案），准备进入编码前，需要把任务拆出来、理顺顺序。
• 要把一个功能 / 改动落地为"可被领取、可逐个验收、可勾选追踪"的开发任务。
• 协作中需要一份"执行期可对照、每个任务做没做完可逐条核对"的依据。

不适用（别硬套）：

• 技术方案还没定 / 没确认 → 先 make-design。任务必须站在确认过的技术设计上，否则是给没定的方案拆任务。
• 行为 / 需求还没钉死 → 先 write-spec；想法还模糊 → 先 refine-idea。
• 要的是逐行实现代码 / 含代码的施工单 → 那是下游 execute-task（执行）。
• 已在写代码、定位 bug、做评审。

⚠️ 加载约束：本 skill 的产出（任务清单）最终必须经一个能 review 的活人确认才放行进入编码。 与 make-design 一致——允许从 design + spec + 代码库推断常规拆分（显式标注假设），但有两条硬线：

• 会改变清单形状 / 需用户偏好的点（切片边界、任务粒度、关键依赖顺序、哪些延后到后续版本）停下来交用户拍板。
• 禁止在 CI / 定时任务 / 自治循环里把它当"自动产任务、无人 review 就开干"的工具——那种场景遇到 "没有任务清单"，正确做法是产出带假设标注的草案并标记为待 review 的 blocker，而不是自动定稿就开始编码。

招牌机制：垂直切片 + 拆分探针 ⭐

这是 split-task 区别于"随手列个 todo"的核心。一份任务清单不是把设计里的模块名抄成几行待办， 而是让每个任务都过两关、再受两道闸门收敛。与 make-design 的「决策探针 + 方案对比锁定」严格同构。

关一：每个任务独立可验收

每个任务必须写得出 「完成判据（验收标准）+ 怎么验证（验证方式）」。

• 写得出可验证的完成判据 → 它是一个任务。
• 写不出（只能说"把数据层写好""处理一下错误"）→ 它要么太大该拆，要么太空该并，别用"写好 X" 把没想清楚盖过去。

检验：把这个任务交给另一个人，他做完后能照着"验收标准"自己判断"做完了没有"吗？不能，就还没拆清。

关二：拆分探针强制覆盖

光照着设计里的模块拆，会漏掉一半真正要做的工作——漏在数据迁移、测试、配置、回滚、可观测、 依赖安装这些"设计文档不显眼、但不做就上不了线"的维度上。拆分探针逐项扫一组易漏任务维度， 每个维度强制表态：需任务 / 不适用 / 延后。

• 维度示例：数据迁移 / 测试 / 配置与环境变量 / 文档 / 回滚 / 可观测（日志·指标）/ 集成点 / 依赖安装 / 构建·CI / 接口契约落地 / 种子数据。
• 关键：每个维度都要有结论（拆了任务 / 明确不适用 / 显式延后），"忘了想"和"想过判定不适用"是两回事。

（维度全清单与每个维度具体问什么，见 references/split-probes.md。）

闸门一：任务分级（防笨重 + 防过碎）

不是每个动作都单列一个任务，也不是一个任务塞下整个功能。两头收敛：

• 任务大小以 S / M 为宜（约 1~5 个文件、一个工作单元内能完成）。
• XL 必拆 —— 跨多个关注点、说不清单一验收的，继续拆到可独立验收。
• 过碎则合并 —— "改一行配置"这种别单列，并入相关任务。
• 垂直切片优先，但允许必要的地基任务 —— 优先让任务穿透各层、可独立验收（反对"先做全部 DB 再做全部 API"）； 但建表 / 脚手架 / 公共依赖这类天然的地基，可作为前置任务单列。

闸门二：设计 & spec 覆盖核对（防落空与镀金）

design 每个组件 / Decision、spec 每条 Requirement / MUST NOT → 由哪个任务覆盖。这是 split-task 独有的闸门， 确保不落空（每个设计点都有任务落地）、也不镀金（不冒出 design / spec 之外的任务）。

（切片怎么切、分级判据、依赖与并行怎么排、覆盖核对怎么做，见 references/slicing-method.md。）

漏斗顺序：先用垂直切片圈出有哪些任务（覆盖面）→ 用拆分探针补漏（易漏维度）→ 用分级收敛（大小 / 合并 / 前置，防笨重）→ 最后做覆盖核对（对齐 design + spec）。

工作流程（阶段 0 + 四个工作阶段）

阶段 0 · 定位与上下文

1. 接上游：读 design（docs/design/* 或用户指明的位置）作为主输入，读 spec（docs/specs/*）取验收口径。 无 design → 视为前置缺失：任务必须站在确认过的技术设计上；没有就建议先 make-design， 不要自己去补技术决策（补决策是 make-design 的职责，越界了）。
2. 扫代码库（轻量）：技术栈、现有结构、测试怎么跑、构建怎么跑——这决定任务的"涉及文件" 与"验证方式"能落成什么形式。注意：这是为了让任务落地，不是重做架构调研（现状认知信任 design）。
3. 判 greenfield / brownfield：
   • 全新系统 / 独立新模块 → 拆全量任务清单。
   • 改既有系统 → 用 delta：聚焦"改动相关的任务 + 迁移 / 兼容 / 回滚任务"，不重列与本次无关的既有工作。
4. 判规模：若这其实是多个独立子系统，先提示拆分，逐个出任务清单，别把一份清单撑成全系统施工总表。

阶段 1 · 切片与定序

1. 垂直切片：按"独立可验收的窄而完整的路径"切任务，而非按技术层横切。必要的地基任务（建表 / 脚手架）单列为前置。
2. 跑拆分探针补漏：逐项扫易漏维度，判定 需任务 / 不适用 / 延后，把漏的任务逼出来。
3. 定序与并行：建依赖关系（A 依赖 B）、标注可并行的任务（互不冲突文件）、把高风险 / 高不确定性的任务前置 （先验证不确定的部分，避免后面返工）；每 2~3 个任务设一个 checkpoint（验证测试 / 构建 / 核心流程）。
4. 分级收敛：任务大小 S/M，XL 拆、过碎并。
5. 推断优先，关键点停下确认：能从 design + spec 推断的拆分直接推断（标注假设）； 切片边界 / 粒度 / 关键依赖顺序 / 哪些延后这类会改变清单形状、或需用户偏好的，停下来给推荐并问。

检验：「这个切法 / 这个顺序定错了，好不好改？」——会让一批任务推倒重排、且难改 → 必须停下确认，不许靠推断蒙混。

阶段 2 · 起草任务清单

按 references/task-template.md 写。每个任务含：

• 目标：这个任务要交付什么（一句话，落到可验收的结果）。
• 切片：它属于哪条垂直切片 / 是不是地基任务。
• 涉及文件：创建 / 修改 / 测试哪些文件（先定文件结构，借 superpowers）。
• 依赖：依赖哪些前置任务（无依赖则标 none）；可并行 / 高风险标注。
• 验收标准：完成判据，可被另一个人独立判断（关一）。
• 验证方式：怎么验证（最好对应"测试怎么跑 / 构建怎么跑"，如 pytest tests/test_x.py）。
• 覆盖：这个任务落地了 design / spec 的哪些条目（关联闸门二）。
• checkbox：- [ ] 便于执行阶段勾选追踪。

清单整体还要含：依赖与并行视图（顺序 / 哪些可并行 / checkpoint 在哪）+ 覆盖核对表（design&spec → 任务）。

下游可解析约束：迁移、兼容、回滚只要判定为“需任务”，就必须写成完整的 ### Task N: ...，包含与其他任务相同的字段和 checkbox。可以另设索引汇总这些任务， 但不能只在“迁移 / 回滚”章节留一条游离 bullet；否则 execute-task 无法机械抽取和追踪。

阶段 3 · 自检（双重，落盘前过一遍）

① 任务卫生（借 superpowers）：

• 占位符 / TODO / "待补充"的任务？补全或删除。
• 自相矛盾？（两个任务职责重叠、依赖关系打架）
• 范围过大？需要拆成多份清单？
• 歧义？（某个任务的验收能有两种解读 → 写死一种）

② 覆盖自检（招牌机制回扫）：

• 每个拆分探针维度都表态了吗（需任务 / 不适用 / 延后）？
• 每个任务都有可独立判断的验收标准 + 验证方式吗（关一）？
• design 每个组件 / Decision、spec 每条 Requirement / MUST NOT 都有任务落点吗（不落空）？有没有 design/spec 之外的镀金任务？
• 依赖关系无环、顺序可执行吗？高风险任务前置了吗？
• 任务大小合适吗（没有 XL 没拆、没有过碎该并）？
• 推断出来的拆分，假设都显式标注了吗？

就地修复，不必重复 review。

阶段 4 · 用户 review 门禁（硬门）

1. 落盘：把任务清单写入仓库。位置见下文「产物与落盘」。
2. 请用户 review，并明确这条规矩：

   未通过 review 的任务清单，不进入编码。

3. 用户要改 → 回阶段 1 / 2 / 3 修订并重过自检；用户显式确认 → 过门。
4. 过门后：可以一句话提示"需要的话，可据此进入 execute-task（逐个任务执行）"， 但不自动开始编码、不自动跑任务。本 skill 到"任务清单确认"为止。

哪些回答不算 "yes"（同 refine-idea / write-spec / make-design 的门禁纪律）：

• "你看着办 / 都行" = 委托，不是决策。
• "听起来不错" = 模糊回应。
• 沉默后一句"那就开始吧" = 放弃，不是确认。

产物与落盘

• 默认单份任务清单文档，内容是任务（目标 / 切片 / 文件 / 依赖 / 验收 / 验证 / 覆盖 + checkbox）+ 依赖与并行视图 + 覆盖核对表。
• 位置：跟随仓库既有约定——若已有 OpenSpec 式 openspec/changes/<change>/tasks.md 或 docs/tasks/ 布局，就跟随； 否则默认 docs/tasks/<YYYY-MM-DD>-<主题>-tasks.md（目录不存在先跟用户确认）。
• brownfield 用 delta，聚焦改动相关任务 + 迁移 / 兼容 / 回滚，不重列全量；其中判定为“需任务”的 迁移 / 兼容 / 回滚必须使用完整 Task N 结构。
• 规模极大 / 多子系统时，可提议拆成多份，但这是 scale-up，不是默认——别给小改动套重型结构。

核心原则（不要违反）

1. 每个任务可独立验收，不是半成品 —— 都要写得出"完成判据 + 怎么验证"，否则该拆或该并。
2. 先站在 design 与 spec 上，再拆任务 —— 脱离技术设计（怎么实现）或 spec（验收口径）的任务清单是空拆。
3. 拆分探针是强制项 —— 数据迁移 / 测试 / 配置 / 回滚 / 可观测是漏任务的重灾区，逐项扫，别省。
4. 垂直切片优先，分级收敛 —— 任务穿透各层可独立验收；S/M 为宜，XL 拆、过碎并，别横切成"半层任务"。
5. 每个设计点都要对得上号 —— design 组件 / Decision、spec 的 MUST / MUST NOT 都有任务落点，且不拆 spec 之外的任务。
6. 依赖理顺、高风险前置 —— 依赖无环、顺序可执行；不确定性最高的先验证。
7. 推断可以，关键必停、最终必 review —— 常规拆分可推断 + 标注假设；切片边界 / 粒度 / 顺序停下问；定稿经活人确认才进编码。
8. 止步于任务清单，不下沉代码 —— 逐行实现 / 含代码施工单留给下游 execute-task，不自动往下、不写代码。

终止条件（可检验）

• 达标即停：当每个任务都有验收 + 验证、每个拆分探针维度都表态、design 每个组件 / spec 每条都有任务落点、 依赖无环可执行——任务清单就够了，进入 review 门禁，别为"更细的任务"无限拆下去。
• 兜底①：拆到一半发现 design 本身有没定的技术决策（你要拆的任务依赖一段缺失的设计）→ 停下退回 make-design， 别用任务清单去替设计补决策。
• 兜底②：某个切片边界 / 依赖顺序反复定不下来、且缺用户私有信息（偏好、优先级、外部约束）→ 停下把判断告诉用户、 交他拍板，别在原地空转或硬猜。

自检清单（落盘前过一遍）

• 每个任务都有可独立判断的验收标准 + 验证方式（关一）？
• 每个拆分探针维度都表态了（需任务 / 不适用 / 延后）？
• design 每个组件 / Decision、spec 每条 Requirement / MUST NOT 都有任务落点（覆盖核对），没落空？
• 通篇没有 design / spec 之外的镀金任务？
• 任务大小合适（没有 XL 没拆、没有过碎该并）、垂直切片优先？
• 依赖关系无环、顺序可执行，高风险前置、设了 checkpoint？
• 推断出来的拆分，假设都显式标注了？
• brownfield 用了 delta（只列改动相关 + 迁移/回滚），没重列全量？
• 所有“需任务”的迁移 / 兼容 / 回滚都写成了完整 Task N，没有游离 bullet？
• 会改变清单形状的点（切片边界 / 粒度 / 顺序 / 延后）都停下问过用户，不是自己拍板的？
• 动笔前读过 design 与 spec、轻量扫过代码库（结构 / 测试怎么跑 / 构建怎么跑）？
• 拿到的是显式 review 确认，不是"你看着办 / 听起来不错"？
• 全程止步于任务清单，没下沉到逐行实现、没写代码？

一次完整示范（照着这个节奏走）

接 make-design 那份"实验清单"技术设计，看它怎么被拆成可执行任务清单。三件套用同一案例贯穿。

输入（来自 make-design 技术设计，节选）

brownfield：既有 Flask + SQLite + pytest 应用里新增"实验清单"只读功能。 架构：models.py 的 list_experiments() 纯函数（取数 + 状态校验 + 稳定排序）；routes.py 的 GET /experiments 调它渲染 experiments.html；无写路由。数据模型：experiments(id, name, status CHECK in draft/running/done, owner NULL, created_at)。测试策略：pytest 测 list_experiments() （正常 / 空 / 非法状态 / owner 空 / 稳定排序）+ 一条路由 smoke test。

阶段 0 · 定位与上下文

design 齐全，直接接住。扫项目：Flask + SQLite，测试 pytest，无构建步骤。这是在既有应用里加新功能 → brownfield delta：只列实验清单相关任务，不动既有部分。现状认知信任 design（make-design 已调研过）。

阶段 1 · 切片 + 探针 + 定序

按垂直切片切（数据 → 展示），地基任务前置；跑拆分探针补漏；多数维度不适用（只读小功能），正好演示克制：

拆分探针维度	判定	处理
数据迁移	需任务	T1 建 experiments 表 + CHECK 约束
测试	需任务（嵌入式）	验收用 pytest，融入 T2 / T3 的验证方式，不另列纯测试任务
接口契约落地	需任务	T3 GET /experiments
种子数据	需任务（小）	并入 T1（插几条演示数据）
配置 / 依赖安装 / 构建 CI	不适用	无新配置 / 无新依赖 / 沿用现有 pytest
回滚 / 可观测	不适用	新增只读功能、无破坏性迁移、只读静态无需埋点
文档	延后	内部小工具，本版不写文档（进延后）

切出 4 个任务，依赖链 T1 → T2 → T3 → T4，规模小基本线性、无特别高风险：

• T1（地基/schema） 建 experiments 表 + CHECK 约束 + 几条种子数据
• T2（数据层切片） list_experiments() 纯函数：取数 + 状态校验 + 稳定排序
• T3（展示层切片） GET /experiments 路由 + experiments.html：倒序展示、空态、owner 空兜底
• T4（MUST NOT 收口） 核对无写路由 / 无表单 / 无图表 / 无外部同步入口

切片边界（数据层 / 展示层分开）会影响清单形状，停下确认：

「我打算按'数据层（T2）/ 展示层（T3）'切两片，建表（T1）作前置地基，最后用 T4 收口三条 MUST NOT。 你认可这个切法和 T1→T2→T3→T4 的顺序吗？」

用户：认可。

阶段 2 · 起草（节选）

Task 2: 实验查询与校验 list_experiments()

• 切片：数据查询层（DB → 纯函数，可独立测）
• 涉及文件：models.py(改)、tests/test_models.py(新)
• 依赖：T1（建 experiments 表）；可并行：否；高风险：否
• 验收标准：非法 status 标记数据异常（不静默显示）；空集合返回 [] 不报错； created_at 相同按 id 稳定排序；owner 为空不抛错
• 验证方式：pytest tests/test_models.py（覆盖正常 / 空 / 非法状态 / owner 空 / 稳定排序）
• 覆盖：design list_experiments()；spec Req「状态约束」「稳定排序」
• 完成

〔T1 / T3 / T4 同构略〕

依赖与并行视图

• 顺序：T1 → T2 → T3 → T4（线性）
• 可并行：无（小项目，强依赖链）
• checkpoint：T2 后跑一次 pytest（数据层绿）；T3 后开页面 + 路由 smoke

覆盖核对表

design / spec 条目	任务落点
design experiments 表 / 数据模型	T1
design list_experiments()	T2
design GET /experiments + 模板	T3
spec Req 只读展示（含空态 / owner 空 / 倒序）	T3
spec Req 状态约束	T1（CHECK）+ T2（查询层校验）
spec Req 稳定排序	T2
spec MUST NOT 编辑 / 同步 / 图表	T4
design 测试策略	T2 + T3 的验证方式

阶段 3 · 自检

每个任务都有验收 + 验证 ✓；拆分探针每维表态（含"不适用 / 延后"）✓； design 组件与 spec 每条 MUST / MUST NOT 在覆盖核对表都有落点、无镀金 ✓； 依赖 T1→T2→T3→T4 无环可执行 ✓；任务大小 S/M ✓；文档"延后"已标注 ✓。

阶段 4 · review 门禁

任务清单已写入 docs/tasks/2026-06-22-experiment-list-tasks.md。请 review；未过 review 不进入编码。

〔用户显式确认后过门，提示"可据此进入 execute-task 执行"，不自动往下。〕

反例（不要这样做）

❌ 把 design 里的模块名抄成几行 todo 当任务 —— 没有验收标准、没法判断做没做完。 ❌ 按技术层横切（"任务1：全部数据库""任务2：全部 API""任务3：全部 UI"）—— 每个都不可独立验收，违背垂直切片。 ❌ 一个任务塞下整个功能（XL 不拆），或给"改一行配置"单列一个任务（过碎不并）。 ❌ 只照设计里写到的模块拆，漏掉数据迁移 / 测试 / 配置 / 回滚 / 可观测 —— 拆分探针没逐项扫。 ❌ 任务清单不对照 design / spec，漏了某个组件或某条 MUST 没人做，或冒出一堆 spec 之外的"顺手加的"任务（镀金）。 ❌ 依赖有环 / 顺序排错（后置任务被前置任务依赖），或把高不确定性的任务放到最后才做。 ❌ design 还没确认就开始拆任务 —— 给没定的方案拆活，该先 make-design。 ❌ 把逐行实现代码、含代码的施工单写进任务里 —— 越界到下游 execute-task（那是执行 / 编码的事）。 ❌ 自己替任务做技术决策（"这里改用 Redis"）—— 越界回 make-design。 ❌ 切片边界 / 粒度 / 关键顺序自己拍板、不问也不留 review。 ❌ brownfield 把与本次无关的既有工作也列进来 —— 该用 delta。 ❌ 接 issue tracker / 外部平台发任务 —— 本链是本地文档驱动，不做外部集成。 ❌ 没落盘、没让用户 review 就说"任务拆好了，开始写代码"。 ❌ 在 CI / 自治循环里自动产任务清单、无人 review 就开干。

相关参考

• references/task-template.md —— 任务清单落盘模板 （任务条目 + 依赖与并行视图 + 覆盖核对表；含 brownfield delta）。
• references/split-probes.md —— 拆分探针清单： 逐项易漏任务维度 + 每个维度具体问什么、怎么判"需任务 / 不适用 / 延后"。
• references/slicing-method.md —— 切片与定序方法： 垂直切片怎么切、任务大小分级、依赖与 wave 并行怎么排、高风险前置 / checkpoint、覆盖核对怎么做。