SDD 任务计划模板

规格已经准备好后，用这份模板把实现拆成小块。它让人工工程师和 AI 编码代理都绑定到同一组验收标准。

tasks.md

# Implementation Tasks

Spec:
Design:
Owner:

## Task Rules
- 每个任务都必须可评审。
- 不实现规格外行为。
- 完成前必须附证据。

## Tasks
- [ ] Task 1:
  - Acceptance link:
  - Allowed files:
  - Test command:
  - Evidence:

- [ ] Task 2:
  - Acceptance link:
  - Allowed files:
  - Test command:
  - Evidence:

## Dependency Order
1.
2.
3.

什么时候使用这份模板

功能可以进入实现，但跨多个模块。
多个人或多个代理需要明确文件归属。
一次性生成大 diff 太难评审。
QA 想看到任务如何映射验收标准。

填好后应该是什么样

模板只有在写入真实决策、负责人和证据后才有价值。下面是一个可评审的片段。

- [ ] 添加退款幂等存储
  - Acceptance link: AC-2 重放返回已有 refund_id
  - Allowed files: services/refunds/*, tests/refunds/*
  - Test command: npm run test -- refunds
  - Evidence: refund_timeout_replay 通过

实现前先检查这些点

每个任务都指向一条验收标准或设计章节。
允许修改文件足够窄，避免无关改动。
测试命令在实现前就写好。
依赖顺序能避免危险并行。

弱写法 vs 强写法

弱写法

实现后端、更新前端、添加测试。

强写法

先做幂等存储，再做渠道超时状态，再做客服 UI 阻断。每个任务都写明对应验收标准、允许文件和测试命令。

FAQ

为什么不只放在任务系统里？

可以放，但 tasks.md 能把意图、设计、任务和证据串成一条可追溯链路。

任务应该拆多小？

小到评审者能理解 diff、运行验证命令，并判断它是否满足规格的一部分。

AI 代理可以执行这些任务吗？

可以，前提是每个任务都有允许文件、非目标和证据要求。

编辑说明

这份模板面向 spec-driven development 工作流，示例用于展示结构，不代表特定公司的内部流程。

作者: Daniel Marsh
编辑政策: 我们如何审阅和更新内容

建议把它放在仓库的 /docs/specs/ 或 /.specs/ 下，并在实现过程中持续更新。最后更新：2026 年 5 月 11 日。