GitHub Spec Kit 实战（五）：/speckit.tasks 怎么拆------Spec Kit 五部曲收官
Spec Kit 五部曲------constitution / specify / plan / tasks / implement，前四步是"想清楚"，tasks 是"动手前最后一道关"。
这一步 AI 翻车的方式和前面三步不一样：
specify翻车：写了技术栈、堆了一堆功能constitution翻车：写得太多、写了软的、没带 Sync Impact Reportplan翻车：AI 偷偷选型、Constitution Check 自审、DDL 写进 data-modeltasks翻车：颗粒度失控、并行度瞎标、Story 之间互相依赖、tests 写成实现文档
tasks 阶段是把 plan 翻译成"AI 可以直接动手执行的清单"------颗粒度差一步，后面的 /speckit.implement 就会写出一堆不达标的代码。这篇文章拆 5 个最常见的坑。
tasks.md 的硬格式：4 个组件缺一不可
仓库的 tasks.md 命令源码里有明文规定：
Every task MUST strictly follow this format:
text- [ ] [TaskID] [P?] [Story?] Description with file path
4 个组件一个不能少：
| 组件 | 必有？ | 例子 |
|---|---|---|
Checkbox - [ ] |
必有 | - [ ] |
Task ID T001 |
必有 | T001、T002 顺序递增 |
[P] marker |
可选 | 只在可并行时加 |
[Story] label |
必有（除 Setup/Foundational/Polish） | [US1] / [US2] |
| Description + file path | 必有 | 描述要带具体文件路径 |
tasks.md 源码给的反例直接抄：
- ❌ WRONG:
- [ ] Create User model(missing ID and Story label)- ❌ WRONG:
T001 [US1] Create model(missing checkbox)- ❌ WRONG:
- [ ] [US1] Create User model(missing Task ID)- ❌ WRONG:
- [ ] T001 [US1] Create model(missing file path)
每条缺一个都视为不合法。
第一个关卡：颗粒度------不是 task 越细越好
AI 翻车点 1：颗粒度爆炸，一行代码一个 task
我见过一个 tasks.md 共 187 条，Phase 3（US1）就 42 条：
- T012 US1 Add import statement
import osin src/utils/file.py- T013 US1 Add import statement
import jsonin src/utils/file.py- T014 US1 Define function signature
def parse_exif(path: str)in src/utils/file.py- T015 US1 Add docstring to parse_exif
- T016 US1 Add type hint
: ExifDatato return type- T017 US1 Implement open file logic
- T018 US1 Implement read EXIF tags
- ...
这是反模式 。tasks.md 不是代码行级分解，是"一个 PR 单元"。
判断标准 ：一条 task 完成后，应该能独立 commit + push + review 。如果一条 task 只是给函数加 import 语句，它和"加 docstring"必须合并------它们属于同一个逻辑单元、同一文件、同一 PR。
正确颗粒度（US1 拆成 6-8 条）：
markdown
## Phase 3: User Story 1 - 按日期自动建相册 (Priority: P1) 🎯 MVP
### Tests for User Story 1 (OPTIONAL)
- [ ] T012 [P] [US1] Contract test for upload CLI in tests/contract/test_upload_cli.py
- [ ] T013 [P] [US1] Integration test for "upload triggers album creation" in tests/integration/test_upload_album.py
### Implementation for User Story 1
- [ ] T014 [P] [US1] Create Photo model in src/models/photo.py
- [ ] T015 [P] [US1] Create Album model in src/models/album.py
- [ ] T016 [US1] Implement ExifParser in src/services/exif_parser.py
- [ ] T017 [US1] Implement AlbumService.create_from_date() in src/services/album_service.py
- [ ] T018 [US1] Wire upload CLI to AlbumService in src/cli/upload.py
- [ ] T019 [US1] Add error handling + structured logging for US1 operations每条 task 都有明确边界：
- 一个文件 = 一条 task（除非跨文件 service）
- 一个逻辑单元 = 一条 task（不是"加 import"这种原子操作）
第二条判断标准 ：AI 拿到一条 task 后能不能不开问地完成 。如果 AI 还需要问"用什么库？文件放哪？"，说明 task 颗粒度太粗 。如果 AI 还需要问"加 import 还是 from？"------说明太细。
第二个关卡：依赖关系------一个 story 独立可测
tasks.md 命令源码里明文要求：
CRITICAL: Tasks MUST be organized by user story to enable independent implementation and testing.
AI 翻车点 2：Story 之间偷偷串依赖
我看过的 tasks.md：
markdown
## Phase 4: User Story 2 - 拖拽重分组 (Priority: P2)
- [ ] T020 [P] [US2] Create DragDropService in src/services/drag_drop.py
- [ ] T021 [US2] Refactor AlbumService to support re-grouping (depends on US1)
- [ ] T022 [US2] Implement drag drop endpoint in src/api/album.pyT021 标注"depends on US1"------US2 不能独立交付 。这违反了 specify 阶段就定下的硬规则："Each user story/journey must be INDEPENDENTLY TESTABLE"。
正确做法 ：US2 不去改 US1 的 AlbumService，扩展：
markdown
## Phase 4: User Story 2 - 拖拽重分组 (Priority: P2)
- [ ] T020 [P] [US2] Create DragDropRequest DTO in src/models/drag_drop.py
- [ ] T021 [P] [US2] Add `move_photo()` method to AlbumService in src/services/album_service.py
- [ ] T022 [US2] Implement drag drop endpoint in src/api/album.py新增方法 而不是重构 ------US1 的 AlbumService 行为不变，US2 增量添加 move_photo()。
判断标准 ：删除 T020-T022，US1 还能完整运行吗？能→US2 独立；不能→串依赖了。
第三个关卡：P 标记------不是"想并行就并行"
AI 翻车点 3：P 满天飞
我看过的 tasks.md 把所有 task 都标 P：
markdown
- [ ] T014 [P] [US1] Create Photo model in src/models/photo.py
- [ ] T015 [P] [US1] Create Album model in src/models/album.py
- [ ] T016 [P] [US1] Implement ExifParser in src/services/exif_parser.py # 实际依赖 T014
- [ ] T017 [P] [US1] Implement AlbumService in src/services/album_service.py # 实际依赖 T015、T016T016 和 T017 明明依赖前面的 model 和 parser，标 P 错。
tasks.md 命令源码的 P 规则：
P marker: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)
两个硬条件：
- 不同文件（不冲突）
- 不依赖未完成的 task
T014 / T015 满足------两个 model 不同文件 。
T016 / T017 不满足------依赖前面。
正确版：
markdown
- [ ] T014 [P] [US1] Create Photo model in src/models/photo.py
- [ ] T015 [P] [US1] Create Album model in src/models/album.py
- [ ] T016 [US1] Implement ExifParser in src/services/exif_parser.py (depends on T014)
- [ ] T017 [US1] Implement AlbumService in src/services/album_service.py (depends on T015, T016)
- [ ] T018 [US1] Wire upload CLI to AlbumService in src/cli/upload.py (depends on T017)注意 depends on T014, T015 这种显式标注 ------tasks.md 模板里给出了这种格式：
- T014 US1 Implement UserService in src/services/user_service.py (depends on T012, T013)
实际项目里依赖标注经常被 AI 漏掉 。读 tasks 阶段最快的"过稿"方法 1：扫所有非 P 的 task，有依赖没标 depends on 的直接打回。
第四个关卡：Tests 段------只在你真做 TDD 时才有
tasks.md 命令源码明文规定：
Tests are OPTIONAL: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.
AI 翻车点 4：默认生成一堆测试 task
我看过的 tasks.md 每个 user story 都有 4-5 条测试 task，但 spec 里从未提过 TDD 。这些测试 task 会让 AI 在 implement 阶段先写测试再写实现 ------而你的 spec 没要求 TDD，团队流程也不是 TDD-first，白白增加 30% 工作量。
正确做法：读 spec，看 FR（Functional Requirements）里有没有显式提到：
- "TDD" / "测试先行" / "test-driven" / "red-green-refactor"
- "测试覆盖率 ≥ X%"
- "所有 PR 必须有测试覆盖"
有 → 生成 Tests 段。
没有 → 跳过 Tests 段，只生成 Implementation。
反例（spec 没提 TDD，AI 还是生成了 Tests 段）：
markdown
### Tests for User Story 1 (OPTIONAL)
- [ ] T012 [P] [US1] Contract test for upload CLI in tests/contract/test_upload_cli.py
- [ ] T013 [P] [US1] Integration test for upload triggers album creation in tests/integration/test_upload_album.py正例（spec 提了 TDD）：
markdown
### Tests for User Story 1 ⚠️ REQUIRED (TDD per constitution Principle III)
> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
- [ ] T012 [P] [US1] Contract test for upload CLI in tests/contract/test_upload_cli.py
- [ ] T013 [P] [US1] Integration test for "upload triggers album creation" in tests/integration/test_upload_album.py第二种 才是合法------Tests 段必须标注"为何要写"，而不是 AI 默认加的。
读 tasks 阶段最快的"过稿"方法 2：扫 Tests 段，没注明 "per constitution Principle X" 或 "per spec FR-XXX" 的测试 task 直接打回。
第五个关卡：Final Phase 别搞成杂物间
AI 翻车点 5：Final Phase 啥都往里塞
tasks.md 模板里 Final Phase 是这样：
Phase N: Polish & Cross-Cutting Concerns
- Documentation updates in docs/
- Code cleanup and refactoring
- Performance optimization across all stories
- Additional unit tests (if requested) in tests/unit/
- Security hardening
- Run quickstart.md validation
这 6 条很泛------AI 容易往里塞一堆"看起来该做"的事。
我看过的 Final Phase：
markdown
- [ ] T045 [P] Add OpenTelemetry instrumentation
- [ ] T046 [P] Add Prometheus metrics endpoint
- [ ] T047 [P] Add Grafana dashboard
- [ ] T048 [P] Add alerting rules
- [ ] T049 [P] Write runbook
- [ ] T050 [P] Setup CI/CD pipeline
- [ ] T051 [P] Add Docker support
- [ ] T052 [P] Add Kubernetes manifests
- [ ] T053 [P] Setup database backups
- [ ] T054 [P] Add rate limiting
- [ ] T055 [P] Add API documentation
- ...Final Phase 从 6 条膨胀到 30 条 。每一项看起来都"该做"------但这些不是这一个 feature 的 scope 。这些是项目级基础设施，应该走单独的 spec。
判断标准 ：Final Phase 的每条 task，对其他 feature 也有用吗？
- 有用 → 走单独 spec，不放 Final Phase
- 只对当前 feature 有用 → 放 Final Phase 合理
正确 Final Phase（相册例子）：
markdown
## Phase 5: Polish & Cross-Cutting Concerns
- [ ] T045 [P] Update CLI --help text in src/cli/upload.py
- [ ] T046 [P] Add user-facing error messages in src/errors.py
- [ ] T047 Run quickstart.md validation scenarios 1-3 end-to-end
- [ ] T048 Code cleanup: remove unused imports across packages/
- [ ] T049 Update README.md with photo-album usage examples5 条。每条都直接服务于本 feature。
读 tasks 阶段最快的"过稿"方法 3：Final Phase 超过 10 条的，打回让 AI 拆出单独的 infrastructure spec。
三种交付策略：选对节奏比选对任务更关键
tasks.md 模板给的三种 Implementation Strategy：
MVP First (User Story 1 Only)
适合演示场景------给老板/客户看一个能跑的东西。
1. Phase 1: Setup
2. Phase 2: Foundational
3. Phase 3: User Story 1
4. STOP and VALIDATE
5. Deploy/demoIncremental Delivery (推荐)
适合生产迭代------每完成一个 story 部署一次。
1. Phase 1 + 2 → Foundation ready
2. Add US1 → Test → Deploy
3. Add US2 → Test → Deploy
4. Add US3 → Test → DeployParallel Team Strategy
适合多人团队------US 拆给不同人。
1. Team: Phase 1 + 2 一起做
2. Phase 2 完成后:
- Dev A: US1
- Dev B: US2
- Dev C: US3
3. 各自完成后集成多数项目选 Incremental------MVP First 只在 deadline 临近、必须有 demo 时用。
AI 翻车点 6：默认 Parallel Team Strategy，团队实际是 1 个人
我看过的 tasks.md 末尾 Implementation Strategy 段写着：
Parallel Team Strategy
With multiple developers:
- Team completes Setup + Foundational together
- Once Foundational is done:
- Developer A: User Story 1
- Developer B: User Story 2
- Developer C: User Story 3
但实际就 1 个工程师 。这种策略没有任何价值------1 个人没法并行。
正确做法 ：Implementation Strategy 必须和团队规模匹配。1-2 人 → MVP First 或 Incremental；3+ 人 → Parallel Team。
tasks 阶段过稿清单
拿到 tasks.md 后，按这个清单走一遍：
[ ] 格式合规
- [ ] 每条都有 `- [ ]` checkbox
- [ ] 每条都有 TXXX ID（顺序递增，无跳号）
- [ ] User Story 阶段的 task 都有 [US1]/[US2] 标签
- [ ] Setup/Foundational/Polish 阶段 task 没有 [Story] 标签
- [ ] 每条都有具体文件路径
[ ] 颗粒度
- [ ] 一个文件 = 一条 task（service 跨文件除外）
- [ ] 没有 "加 import" / "加 docstring" 这种原子 task
- [ ] AI 拿到 task 不需要再问问题
[ ] 依赖关系
- [ ] US 之间独立（删 US2 不影响 US1 跑通）
- [ ] 非 [P] task 显式标注 (depends on TXXX, TYYY)
- [ ] 没有"重构 US1 的代码"这种跨 story 依赖
[ ] [P] 标记
- [ ] 标记的 task 满足：不同文件 + 无未完成依赖
- [ ] 没标的 task 至少有 1 个依赖
[ ] Tests 段
- [ ] spec 没要求 TDD 时不出现 Tests 段
- [ ] 出现 Tests 段时必须注明来源（constitution / FR-XXX）
[ ] Final Phase
- [ ] 不超过 10 条
- [ ] 每条都只服务于本 feature
- [ ] 没有"加监控" / "加 CI" 这种项目级基础设施
[ ] Implementation Strategy
- [ ] 选 MVP First / Incremental / Parallel Team 之一
- [ ] 选的策略和团队规模匹配五部曲过稿清单（一图回顾）
走到 tasks，Spec Kit 五部曲的"想清楚"部分就结束了。最后一张总图：
| 阶段 | 产出一份什么 | 翻车点 | 人该把关什么 |
|---|---|---|---|
| constitution | 项目宪法（≤2 页、≤7 条原则） | 太多、太软、不带 Sync Impact Report | 改完看 plan-template 是否强制检查 |
| specify | spec.md（无技术栈的 WHAT/WHY） | 写技术栈、堆功能、SC 是程序员视角 | 检查 NEEDS CLARIFICATION ≤ 3、PM 能验 SC |
| plan | plan.md + research.md + data-model.md + contracts/ + quickstart.md | 偷偷选型、Constitution Check 自审、DDL 进 spec、3 个 Option 全留 | Mechanical Check、真实路径、Alternatives 写 rejected |
| tasks | tasks.md（按 user story 拆的 task 清单） | 颗粒度爆炸、Story 串依赖、P 满天飞、Tests 段不该有 | 格式合规、依赖显式、Tests 段有据、Final Phase 克制 |
| implement | 真实代码 | （这是另一篇文章） | （这是另一篇文章） |
Spec Kit 工作流的核心不是 AI 写代码，是 AI 写规格------人审规格------人改规格------AI 再写。
人最该花时间的两步：审 spec.md （不让 AI 替你猜业务）和审 plan.md （不让 AI 替你选型）。tasks 之后基本就是按清单执行，人手可以松一些。
写给还没用 Spec Kit 的人
如果你没试过 Spec Kit，看完这五篇可能还觉得"这么麻烦"。我用了 18 个月，回顾一下：
- 省下的时间 ：3 个月内 review 的 PR 数量是过去 12 个月的总和，所有"AI 写偏"的 PR 都被 spec 阶段卡住了------spec 阶段改一句话，比 implement 阶段改 50 行代码便宜 100 倍
- 多花的时间：每个 feature 多花 2-4 小时写 spec/plan/tasks
- ROI：5 个 feature 之后开始回本；20 个 feature 之后不可逆------团队再也不会回到"AI 直接写代码"的工作流
不要从大项目开始试 。先拿一个 1 周能做完的小 feature ，按 constitution → specify → plan → tasks → implement 走一遍。用一篇博客把它记录下来------你会被 spec 阶段卡的次数吓到，但也会被 implement 阶段一次通过率惊到。
下一篇会写 /speckit.implement------AI 怎么读 tasks.md 写代码、怎么 review、怎么发现 spec 阶段的遗漏。收官作。