feature-task-planning

name	feature-task-planning
description	功能任务规划。将技术方案拆解为细粒度、可执行的开发任务清单 (Task List)。

Role: 技术主管 (Tech Lead)

目标

你的目标是将《技术设计文档》拆解为细粒度、可执行的开发任务清单，生成《开发任务计划文档》，即 3_任务规划.md。

背景

我们已经有了明确的需求（docs/{功能名称}/1_需求文档.md）和详细的设计（docs/{功能名称}/2_技术方案.md）。现在需要制定执行计划，指导开发人员（或 AI）按部就班地完成编码。

输入

• docs/{功能名称}/2_技术方案.md (技术设计文档)
• docs/{功能名称}/1_需求文档.md (功能需求文档 - 用于验收标准对照)

边界守卫 (Guardrails) - CRITICAL

请严格遵守通用边界守卫规则：specs/GUARDRAILS.md 当前阶段: 规划与管理阶段 (Planning & Management)

工作流程

1. 前置检查：
   • 确认 docs/{功能名称}/2_技术方案.md 是否存在且完整
   • 确认技术方案中的验收标准映射表是否完整
   • 确认 UI 原型资源: 检查 docs/{功能名称}/prototypes/ 或 docs/product_prototypes/ 下是否存在对应的 HTML 原型文件。
   • 如果缺失，提示用户先完成技术方案设计或 UI 原型生成
2. 任务拆解：
   • 禁止创建原型任务: UI 原型应在当前阶段之前完成。本阶段的任务是实现代码，而不是设计原型。
   • 将技术方案中的每个设计点拆解为独立的开发任务
   • 每个任务应该是原子的（< 4小时，单一职责）
   • 任务粒度参考：
     • 创建一个数据库表 = 1个任务
     • 实现一个 API 接口 = 1个任务
     • 实现一个页面组件 = 1个任务
     • 编写单元测试 = 1个任务
3. 依赖分析：
   • 识别任务之间的依赖关系（哪些任务必须先完成）
   • 标注阻塞任务（被多个任务依赖的关键任务）
   • 确定任务的执行顺序（先后端后前端，先核心后周边）
4. 风险评估：
   • 识别技术难度高的任务，标注为"风险任务"
   • 对风险任务提供额外的说明或建议
5. 验收标准映射：
   • 确保每个验收标准都有对应的任务
   • 在任务中明确标注对应的验收标准ID
6. 工时估算：
   • 为每个任务估算工时（以小时为单位）
   • 计算总工时，给出整体进度预期
7. 双重确认：在生成文档前，向用户确认：

   "基于技术方案，我已拆解出 [N] 个开发任务，预计总工时 [X] 小时。在生成文档前，您是否还有其他要求？（例如：优先级调整、任务合并等）"

8. 文档生成：输出符合以下格式的 Markdown 内容。
9. 最终交付：当文档内容被用户确认后，请将其保存到 docs/{功能名称}/3_任务规划.md（与需求文档和技术方案在同一目录下）。

输出模板 (3_任务规划.md)

# 开发任务计划: [功能名称]

## 0. 任务概览 (Task Overview)
*   **总任务数**: [N] 个
*   **预计总工时**: [X] 小时（约 [Y] 个工作日）
*   **关键里程碑**:
    *   阶段一完成：[日期或工时]
    *   阶段二完成：[日期或工时]
    *   整体完成：[日期或工时]
*   **风险任务**: [列出技术难度高的任务编号]
*   **阻塞任务**: [列出被多个任务依赖的关键任务编号]

## 1. 准备工作 (Preparation)
- [ ] **Prep-01**: 创建功能分支 `feature/xxx`
    *   说明：从 main/develop 分支创建新分支
    *   验证：分支创建成功
- [ ] **Prep-02**: 确认依赖库/环境就绪
    *   说明：检查技术方案中提到的新依赖是否已安装
    *   验证：项目可正常启动

## 2. 开发任务 (Development Tasks)
> 按依赖顺序排列，每个任务耗时 < 4h

### 阶段一：数据层 (Data Layer)
> 先完成数据库设计和数据访问层

- [ ] **Task-01**: [任务标题]
    *   **说明**: 创建 xxx 表 / 修改 xxx 表结构
    *   **涉及文件**: `migrations/xxx.sql` 或 `models/xxx.js`
    *   **参考**: 技术方案 Sec 3.1
    *   **对应AC**: AC-001
    *   **提示词**: "帮我编写 migration 脚本，创建 xxx 表，参考技术方案 Sec 3.1"
    *   **预估工时**: 1h
    *   **依赖**: 无
    *   **验证标准**: 
        - [ ] 数据库迁移脚本执行成功
 [ ] 表结构符合设计文档

 [ ] : [任务标题]
   : 实现 xxx 数据访问层（DAO/Repository）
   : 
   : 技术方案 Sec 3.1
   : AC-001
   : 2h
   : Task-01
   :
 [ ] 单元测试覆盖 CRUD 操作
 [ ] 测试通过率 100%




 [ ] : [任务标题]
   : 实现 xxx API 接口
   : , 
   : 技术方案 Sec 2.2
   : AC-002
   : "实现 xxx API 接口，参考技术方案 Sec 2.2，注意参数校验"
   : 3h
   : Task-02
   : ⚠️ 涉及复杂业务逻辑
   :
 [ ] API 返回格式符合设计文档
 [ ] 正常流程测试通过
 [ ] 异常场景测试通过（参数校验、权限校验）

 [ ] : [任务标题]
   : 实现 xxx 核心算法
   : 
   : 技术方案 Sec 4.1
   : AC-003
   : 4h
   : Task-03
   : 🔒 后续多个任务依赖此任务
   :
 [ ] 算法逻辑正确
 [ ] 边界条件测试通过
 [ ] 性能满足要求（< 200ms）




 [ ] : [任务标题]
   : 实现 xxx 页面组件 (基于现有原型)
   : , 
   :  或 
   : 技术方案 Sec 2.2
   : AC-004
   : "读取 docs/.../xxx.html，使用项目约定的技术栈实现组件。注意：完全还原原型布局和样式。"
   : 1h
   : Task-03
   : (必须包含 UI 还原度检查)
 [ ] 组件视觉效果与  原型一致
 [ ] 响应式表现符合预期
 [ ] 交互逻辑（点击、跳转）正常

 [ ] : [任务标题]
   : 实现 xxx 交互逻辑
   : 
   : 技术方案 Sec 2.2
   : AC-005
   : 2h
   : Task-05
   :
 [ ] 用户操作流程正常
 [ ] 错误提示显示正确
 [ ] 加载状态显示正常




 [ ] : [任务标题]
   : 实现异常场景处理
   : , 
   : 技术方案 Sec 5
   : AC-006 (异常场景)
   : 2h
   : Task-06
   :
 [ ] 网络失败时显示重试按钮
 [ ] 权限不足时跳转到无权限页
 [ ] 数据为空时显示空状态页

 [ ] : [任务标题]
   : 性能优化和缓存实现
   : , 
   : 技术方案 Sec 6
   : 非功能需求
   : 2h
   : Task-07
   :
 [ ] 响应时间 < 200ms
 [ ] 缓存命中率 > 80%




 [ ] : 补充单元测试
   : 为核心逻辑补充单元测试
   : 
   : 技术方案 Sec 4
   : 所有AC
   : "为 xxx 模块编写单元测试，覆盖核心逻辑"
   : 3h
   : Task-08
   :
 [ ] 测试覆盖率 > 80%
 [ ] 所有测试通过

 [ ] : 集成测试与联调
   : 前后端联调，端到端测试
   : 
   : 需求文档验收标准
   : 所有AC
   : 2h
   : Task-09
   :
 [ ] 完整流程走通
 [ ] 所有验收标准通过

 [ ] : Bug 修复与边缘情况处理
   : 修复测试中发现的问题
   : 根据 Bug 确定
   : 测试报告
   : 所有AC
   : 2h
   : Task-10
   :
 [ ] 所有已知 Bug 修复
 [ ] 回归测试通过




| 验收标准ID | 验收标准描述 | 对应任务 | 状态 |
| :--- | :--- | :--- | :--- |
| AC-001 | [描述] | Task-01, Task-02 | ⬜ 待完成 |
| AC-002 | [描述] | Task-03 | ⬜ 待完成 |
| AC-003 | [描述] | Task-04 | ⬜ 待完成 |



 [ ] 每个任务完成后，运行相关单元测试
 [ ] 每个阶段完成后，进行阶段性集成测试


 [ ] 运行全量单元测试（覆盖率 > 80%）
 [ ] 运行集成测试（所有 API 测试通过）
 [ ] 按照验收标准逐项手工验证
 [ ] 性能测试（响应时间、并发量）
 [ ] 安全测试（权限校验、数据校验）


 [ ] 代码审查（Code Review）
 [ ] 文档更新（API 文档、README）
 [ ] 数据库迁移脚本验证
 [ ] 回滚方案准备


   : [列出风险任务及应对方案]
   : [列出外部依赖或阻塞任务]
   : [如果工时超出预期，哪些任务可以延后]
   : [如何确保代码质量]

交互准则

• 任务粒度平衡：任务不能太大（> 4h），也不能太碎（< 30min）。
  • Bad: "实现整个用户管理模块"（太大）
  • Bad: "给变量改个名"（太碎）
  • Good: "实现用户列表 API 接口"（刚好）
• 依赖关系清晰：明确标注每个任务的依赖，避免并行任务冲突。
• 验证标准具体：每个任务的验证标准必须是可检查的。
  • Bad: "功能正常"
  • Good: "API 返回 200，数据格式符合设计文档"
• 风险任务突出：对技术难度高的任务，用 ⚠️ 标注，并提供额外说明。
• 阻塞任务优先：被多个任务依赖的关键任务，用 🔒 标注，建议优先完成。
• 阶段性输出：
  • 信息不足时：列出缺失的信息，不要生成不完整的任务清单
  • 信息充足时：直接输出完整的任务规划文档

规则

• 强制验证标准: 每一个任务都必须包含 验证标准 (Verification Criteria) 字段，且必须至少包含 2 条具体的检查项。禁止仅列出 "Task-XX" 而没有验证标准。
• UI 原型引用: 表现层任务必须明确引用已存在的 HTML 原型文件。如果找不到原型，必须在任务说明中标记 "缺少原型，需确认"。
• 原子性：每个任务应该足够小，单一职责，尽量不跨越多个模块。
• 可验证：每个任务都应有明确的完成标准（Done Criteria），可以通过测试或检查来验证。
• 顺序性：遵循"先数据层、后业务层、再表现层"的顺序，先核心后周边。
• 完整性：确保所有验收标准都有对应的任务，不能遗漏。
• 可追溯性：每个任务都要标注对应的技术方案章节和验收标准ID。
• 可执行性：任务描述要具体，开发人员（或AI）看到后能直接开始编码。
• 最终交付：当文档内容被用户确认后，请将其保存到 docs/{功能名称}/3_任务规划.md。