kiro 整个提示词太庞大了, 一整套软件工程的书全部扔里面的感觉, 就重点看看它的工作分解部分吧,讲道理官方里讲的 EARS（Easy Approach to Requirements Syntax)[简易需求语法方法] 专门用于产品文档,决然语言需求中常见的歧义、不一致、难以验证等问题. 这套东西,我干了这么多年开发,听都没听过, 感觉自己好low
来源: https://github.com/jasonkneen/kiro
任务阶段文档
📍 您在这里：主指南→流程指南→任务阶段
快速导航
•🎯 开始：任务模板- 即用型模板
•📖 查看示例：简单功能任务- 完整的任务示例
•⚡ 执行任务：实施指南- 如何完成任务
•🔄 回到起点：需求阶段- 完整的工作流上下文
阶段导航
•上一阶段：设计阶段- 必须先完成
•当前阶段：任务阶段- 将设计分解为可操作的步骤
•下一阶段：实施- 执行任务
•上下文：流程概述- 三阶段工作流
* *
概述
任务阶段是规范驱动开发流程的最后阶段，将批准的设计转化为一个由离散、可操作的编码任务组成的结构化实施计划。该阶段是规划与执行之间的桥梁，将复杂的系统设计分解为可由开发团队或 AI 编码代理增量执行的可管理步骤。
作为“需求 → 设计 → 任务”工作流的第三个阶段，任务阶段确保所有精心的规划和设计工作都能转化为系统化、可跟踪的实施进度。
目的和目标
任务阶段旨在：
• 将设计组件转化为具体的编码活动
• 为实现最佳开发流程和早期验证对任务进行排序
• 为实施创建清晰、可操作的提示
• 建立任务之间的依赖关系和构建顺序
• 通过可测试的里程碑实现增量进展
• 为系统化的功能开发提供路线图
分步流程
步骤 1：设计分析和任务识别
目标：将设计分解为可实施的组件
流程：
1.审查设计组件：识别所有需要构建的系统组件
2.映射到代码产物：确定需要创建哪些文件、类和函数
3.识别依赖关系：了解哪些组件需要在其他组件之前构建
4.考虑测试要求：在实施的同时规划测试创建
5.为早期验证排序：对任务进行排序以快速验证核心功能
任务识别指南：
• 专注于具体的编码活动（编写、修改、测试代码）
• 每个任务都应产生可工作的、可测试的代码
• 任务应在先前工作的基础上增量构建
• 避免无法由编码代理完成的任务
步骤 2：任务结构化和层次结构
任务组织原则：
1.最多两级：仅使用顶级任务和子任务（避免深度嵌套）
2.逻辑分组：将相关任务归入有意义的类别
3.顺序依赖：对任务进行排序，使每个任务都建立在先前工作的基础上
4.可测试的增量：每个任务都应产生可测试的功能
任务层次结构模式：
[ ] 1. [史诗/主要组件]- [ ] 1.1 [具体的实施任务] – [任务详情和需求参考]- [ ] 1.2 [下一个具体任务] – [任务详情和需求参考]- [ ] 2. [下一个史诗/主要组件]- [ ] 2.1 [具体的实施任务] – [任务详情和需求参考]
步骤 3：任务定义和规范
任务规范要素：
1.明确的目标：需要编写或修改哪些具体代码
2.实施细节：要创建的具体文件、组件或函数
3.需求可追溯性：引用正在实施的具体需求
4.验收标准：如何知道任务已完成
5.测试期望：应编写或更新哪些测试
任务描述模板：
[ ] X.Y [任务标题] – [具体的实施目标] – [要创建/修改的文件或组件] – [要实施的关键功能] – 需求：[需求参考]
步骤 4：依赖管理和排序
依赖注意事项：
1.基础先行：核心接口和数据模型先于依赖组件
2.自下而上：低级实用工具先于高级功能
3.测试驱动顺序：测试与实施并行或先于实施
4.集成点：规划在构建组件时连接它们
排序策略：
•核心优先：在可选功能之前构建基本功能
•风险优先：尽早处理不确定或复杂的任务
•价值优先：实施可以快速测试的高价值功能
•依赖驱动：尊重组件之间的技术依赖关系
步骤 5：任务验证和完善
任务质量标准：
1.可操作：可由编码代理执行，无需额外澄清
2.具体：清楚说明要创建哪些文件、函数或组件
3.可测试：产生可测试和验证的代码
4.增量：在先前任务的基础上构建，没有大的复杂性跳跃
5.完整：涵盖需要实施的设计的所有方面
验证问题：
• 开发人员可以立即根据此任务描述开始编码吗？
• 此任务是否产生可工作的、可测试的代码？
• 正在实施的需求是否已明确识别？
• 此任务是否在逻辑上建立在先前任务的基础上？
• 范围是否合适（不太大，也不太小）？
任务类别和模式
基础任务
目的：建立核心结构和接口
示例：
• 设置项目结构和依赖项
• 创建核心数据模型接口
• 实施基类和实用工具
• 设置测试框架和配置
模式：
[ ] 1. 设置项目基础- [ ] 1.1 创建项目结构和核心接口 – 为模型、服务和实用工具设置目录结构 – 为核心数据类型定义 TypeScript 接口 – 创建基本配置文件 – 需求：1.1, 2.1
数据层任务
目的：实施数据模型和持久化
示例：
• 创建带验证的数据模型类
• 实施用于数据访问的存储库模式
• 设置数据库连接和迁移
• 编写数据访问层测试
模式：
[ ] 2. 实施数据层- [ ] 2.1 创建带验证的核心数据模型 – 实施用户、文档和设置模型类 – 添加用于数据完整性的验证方法 – 为模型验证编写单元测试 – 需求：2.1, 3.3
业务逻辑任务
目的：实施核心功能
示例：
• 为业务操作创建服务类
• 实施工作流和流程逻辑
• 添加业务规则验证
• 为业务逻辑编写集成测试
模式：
[ ] 3. 实施业务逻辑- [ ] 3.1 创建身份验证服务 – 实施用户注册和登录逻辑 – 添加密码哈希和验证 – 创建会话管理功能 – 为身份验证流程编写测试 – 需求：1.2, 4.1
API/接口任务
目的：创建外部接口和端点
示例：
• 实施 REST API 端点
• 创建请求/响应处理
• 添加输入验证和错误处理
• 编写 API 集成测试
模式：
[ ] 4. 实施 API 层- [ ] 4.1 创建用户管理端点 – 实施用于注册的 POST /users – 实施用于身份验证的 POST /auth/login – 添加请求验证和错误响应 – 编写 API 端点测试 – 需求：1.2, 2.3
集成任务
目的：连接组件和外部系统
示例：
• 连接依赖注入
• 实施外部 API 集成
• 将前端连接到后端服务
• 添加端到端集成测试
模式：
[ ] 5. 集成和连接- [ ] 5.1 将身份验证连接到用户管理 – 将身份验证服务连接到用户端点 – 为受保护的路由实施中间件 – 为完整的身份验证流程添加集成测试 – 需求：1.2, 4.1
任务排序策略
策略 1：基础优先方法
最适用于：新项目、具有许多相互依赖关系的复杂系统
顺序：
项目设置和核心接口2. 数据模型和验证3. 数据访问层4. 业务逻辑服务5. API 端点6. 集成和连接
优点：
• 在构建功能之前建立坚实的基础
• 减少因架构变更引起的返工
• 清晰的依赖链
缺点：
• 可见功能出现的时间较长
• 基础过度设计的风险
策略 2：功能切片方法
最适用于：MVP 开发、面向用户的应用程序、敏捷开发
顺序：
核心用户注册（端到端）2. 用户身份验证（端到端）3. 用户个人资料管理（端到端）4. 高级功能和优化
优点：
• 早期交付用户价值
• 更快的反馈周期
• 降低集成风险
缺点：
• 随着功能扩展可能需要重构
• 潜在的技术债务
策略 3：风险优先方法
最适用于：具有高技术不确定性的项目、概念验证
顺序：
最不确定/最复杂的组件2. 外部集成和依赖项3. 核心业务逻辑4. 用户界面和体验5. 完善和优化
优点：
• 早期验证技术可行性
• 降低项目风险
• 为架构决策提供信息
缺点：
• 可能不会尽早交付用户价值
• 需要强大的技术专长
策略 4：混合方法
最适用于：大多数实际项目
顺序：
最小化基础（核心接口、基本设置）2. 高风险/高价值的功能切片3. 根据需要扩展基础4. 其他功能切片5. 集成和完善
优点：
• 平衡风险管理与早期价值
• 灵活且适应性强
• 务实的方法
高级依赖管理策略
依赖类型和管理
技术依赖
定义：必须在其他代码组件构建之前存在的代码组件
示例：
• 使用数据库模型的服务之前的数据库模型
• 受保护端点之前的身份验证中间件
• 功能实施之前的配置设置
管理策略：
[ ] 1. 核心基础设施设置- [ ] 1.1 创建数据库连接和配置- [ ] 1.2 设置身份验证中间件框架- [ ] 1.3 创建基本错误处理实用工具- [ ] 2. 基础模型（依赖于 1.1）- [ ] 2.1 创建与数据库集成的用户模型- [ ] 2.2 创建与数据库集成的会话模型- [ ] 3. 身份验证服务（依赖于 1.2, 2.1, 2.2）- [ ] 3.1 使用用户和会话模型实施登录服务
逻辑依赖
定义：在概念上建立在其他功能之上的功能
示例：
• 用户个人资料编辑需要用户注册
• 密码重置需要用户身份验证
• 高级搜索需要基本搜索
管理策略：
[ ] 1. 基本用户管理- [ ] 1.1 用户注册功能- [ ] 1.2 用户登录功能- [ ] 2. 扩展用户功能（依赖于 1.1, 1.2）- [ ] 2.1 用户个人资料编辑（需要现有用户）- [ ] 2.2 密码重置（需要身份验证系统）
数据依赖
定义：需要特定数据或状态存在的任务
示例：
• 用户仪表板需要用户数据
• 报告功能需要交易数据
• 管理功能需要用户角色
管理策略：
[ ] 1. 数据基础- [ ] 1.1 创建用户注册和示例数据- [ ] 1.2 创建交易记录系统- [ ] 2. 数据依赖功能（依赖于 1.1, 1.2）- [ ] 2.1 用户仪表板（需要来自 1.1 的用户数据）- [ ] 2.2 交易报告（需要来自 1.2 的交易数据）
依赖可视化技术
简单依赖链
任务 A → 任务 B → 任务 C → 任务 D
并行依赖
任务 A → 任务 C任务 B → 任务 C
复杂依赖图
任务 A → 任务 C → 任务 E任务 B → 任务 D → 任务 E任务 A → 任务 D
处理循环依赖
问题：当任务似乎相互依赖时
用户服务需要身份验证服务身份验证服务需要用户服务
解决方案：
1.接口提取：
[ ] 1.1 创建 IUserService 和 IAuthService 接口- [ ] 1.2 使用 IAuthService 接口实施 UserService- [ ] 1.3 使用 IUserService 接口实施 AuthService- [ ] 1.4 连接依赖注入
2.分层方法：
[ ] 1.1 创建用户数据模型和基本 CRUD- [ ] 1.2 使用用户 CRUD 创建身份验证服务- [ ] 1.3 通过身份验证集成增强用户服务
3.事件驱动解耦：
[ ] 1.1 为用户/身份验证通信创建事件系统- [ ] 1.2 实施带事件发布的用户服务- [ ] 1.3 实施带事件监听的身份验证服务
结构良好的实施计划示例
示例 1：用户身份验证系统
实施计划- [ ] 1. 设置身份验证基础- [ ] 1.1 创建项目结构和核心接口 – 为身份验证、模型和 API 组件设置目录结构 – 为用户、会话和 AuthRequest 类型定义 TypeScript 接口 – 为环境变量创建基本配置 – 需求：1.1- [ ] 1.2 设置测试框架和数据库 – 为单元和集成测试配置 Jest – 使用 Docker 配置设置测试数据库 – 为用户表创建数据库迁移脚本 – 需求：1.1, 2.1- [ ] 2. 实施核心数据模型- [ ] 2.1 创建带验证的用户模型 – 实施包含电子邮件、密码和个人资料字段的用户类 – 添加用于电子邮件格式和密码强度的验证方法 – 为用户模型验证编写单元测试 – 需求：1.2, 2.1- [ ] 2.2 实施会话模型和管理 – 创建用于跟踪用户会话的会话类 – 实施会话创建、验证和过期逻辑 – 为会话管理编写单元测试 – 需求：1.2, 4.1- [ ] 3. 创建身份验证服务- [ ] 3.1 实施用户注册服务 – 创建带注册方法的 UserService – 使用 bcrypt 添加密码哈希 – 实施重复电子邮件检查 – 为注册逻辑编写单元测试 – 需求：1.2- [ ] 3.2 实施登录和会话服务 – 添加带密码验证的登录方法 – 实施 JWT 令牌生成和验证 – 使用刷新令牌创建会话管理 – 为登录和会话逻辑编写单元测试 – 需求：1.2, 4.1- [ ] 4. 创建 API 端点- [ ] 4.1 实施注册端点 – 创建 POST /auth/register 端点 – 添加请求验证和错误处理 – 实施正确的 HTTP 状态码和响应 – 为注册 API 编写集成测试 – 需求：1.2, 2.3- [ ] 4.2 实施登录端点 – 创建 POST /auth/login 端点 – 为受保护的路由添加身份验证中间件 – 实施注销功能 – 为登录/注销 API 编写集成测试 – 需求：1.2, 4.1- [ ] 5. 集成和安全加固- [ ] 5.1 添加安全中间件和速率限制 – 为身份验证端点实施速率限制 – 添加 CORS 配置和安全标头 – 为 JWT 令牌验证创建中间件 – 编写以安全为重点的集成测试 – 需求：4.1, 2.3- [ ] 5.2 端到端集成测试 – 创建完整的用户注册和登录流程测试 – 测试错误场景和边缘情况 – 验证安全措施和令牌处理 – 需求：1.2, 4.1
示例 2：数据处理管道
实施计划- [ ] 1. 设置数据处理基础- [ ] 1.1 创建核心数据处理接口 – 为 DataProcessor、Validator 和 Transformer 定义接口 – 为数据源和目标设置配置 – 创建错误处理和日志记录实用工具 – 需求：1.1, 3.1- [ ] 2. 实施数据验证层- [ ] 2.1 创建数据验证引擎 – 实施可配置的验证规则引擎 – 添加对必填字段、数据类型和自定义规则的支持 – 创建包含详细错误消息的验证结果报告 – 为验证引擎编写单元测试 – 需求：2.1, 3.2- [ ] 3. 构建数据转换管道- [ ] 3.1 实施数据转换服务 – 创建具有可配置步骤的转换管道 – 添加对数据映射、筛选和丰富的支持 – 实施错误处理和部分故障恢复 – 为转换逻辑编写单元测试 – 需求：2.2, 3.1- [ ] 4. 创建数据处理协调器- [ ] 4.1 实施处理工作流引擎 – 创建协调验证和转换的协调器 – 添加对批处理和流处理模式的支持 – 实施进度跟踪和状态报告 – 为完整的处理工作流编写集成测试 – 需求：1.1, 2.1, 2.2
示例 3：电子商务产品管理系统
此示例演示了复杂的依赖管理和多种排序策略：
实施计划- [ ] 1. 基础和核心基础设施- [ ] 1.1 设置项目结构和核心接口 – 为模型、服务、存储库和 API 层创建目录结构 – 为产品、类别、库存和订单类型定义 TypeScript 接口 – 为数据库、缓存和外部服务设置配置管理 – 配置具有单元、集成和 e2e 测试支持的测试框架 – 需求：1.1, 1.2- [ ] 1.2 创建数据库架构和迁移 – 设计和实施产品、类别和库存的数据库架构 – 为初始表创建创建迁移脚本 – 设置数据库连接池和事务管理 – 为常见操作编写数据库实用函数 – 需求：2.1, 2.2- [ ] 2. 核心数据模型和验证（依赖于 1.1, 1.2）- [ ] 2.1 实施具有全面验证的产品模型 – 创建具有名称、描述、价格、SKU 和元数据字段的产品类 – 添加对必填字段、价格范围和 SKU 唯一性的验证 – 实施产品分类和标记功能 – 为所有验证场景编写全面的单元测试 – 需求：2.1, 2.3, 3.1- [ ] 2.2 实施具有层次结构的类别模型 – 创建支持父子关系的类别类 – 添加对类别层次结构深度和循环引用的验证 – 实施类别路径生成和面包屑功能 – 为层次结构操作和边缘情况编写单元测试 – 需求：2.1, 3.2- [ ] 2.3 创建具有库存跟踪的库存模型 – 实施具有库存水平、预留和阈值的库存类 – 添加对库存操作和负库存预防的验证 – 创建库存调整日志记录和审计跟踪功能 – 为库存操作和并发访问场景编写单元测试 – 需求：2.2, 4.1- [ ] 3. 用于数据访问的存储库层（依赖于 2.1, 2.2, 2.3）- [ ] 3.1 实施具有高级查询的产品存储库 – 创建具有 CRUD 操作和复杂查询的 ProductRepository – 添加按类别、价格范围和可用性筛选的支持 – 实施产品名称和描述的全文搜索功能 – 为所有存储库操作编写集成测试 – 需求：3.1, 3.3- [ ] 3.2 实施具有层次结构操作的类别存储库 – 创建具有树遍历和操作方法的 CategoryRepository – 添加查找所有后代、祖先和兄弟姐妹的支持 – 实施类别重新排序和层次结构重组 – 为层次结构操作编写集成测试 – 需求：3.2- [ ] 3.3 创建具有并发处理的库存存储库 – 实施具有原子库存操作的 InventoryRepository – 添加对批量库存更新和预留的支持 – 创建库存历史跟踪和报告查询 – 编写包括并发访问场景的集成测试 – 需求：4.1, 4.2- [ ] 4. 业务逻辑服务（依赖于 3.1, 3.2, 3.3）- [ ] 4.1 实施产品管理服务 – 创建具有产品生命周期业务逻辑的 ProductService – 添加对产品创建、更新和软删除的支持 – 实施产品批准工作流和状态管理 – 为所有业务逻辑场景编写单元测试 – 需求：2.1, 2.3, 5.1- [ ] 4.2 实施库存管理服务 – 实施具有库存分配和预留逻辑的 InventoryService – 添加对自动重新订购点通知的支持 – 创建具有批准流程的库存调整工作流 – 为库存业务规则编写单元测试 – 需求：4.1, 4.2, 5.2- [ ] 4.3 实施类别管理服务 – 创建具有类别层次结构管理的 CategoryService – 添加对类别合并、拆分和重组的支持 – 实施基于类别的产品分配和批量操作 – 为类别管理工作流编写单元测试 – 需求：3.2, 5.1- [ ] 5. API 层和外部接口（依赖于 4.1, 4.2, 4.3）- [ ] 5.1 创建产品 API 端点 – 实施用于产品 CRUD 操作的 REST 端点 – 添加对产品搜索、筛选和分页的支持 – 创建产品图片上传和管理端点 – 编写 API 集成测试和文档 – 需求：6.1, 6.2- [ ] 5.2 实施库存 API 端点 – 创建用于库存查询和更新的 REST 端点 – 添加对库存预留和释放操作的支持 – 实施库存报告和分析端点 – 编写具有正确错误处理的 API 集成测试 – 需求：6.1, 4.2- [ ] 5.3 创建类别 API 端点 – 实施用于类别管理的 REST 端点 – 添加对类别树检索和操作的支持 – 创建基于类别的产品列表端点 – 为层次结构操作编写 API 集成测试 – 需求：6.1, 3.2- [ ] 6. 高级功能和集成（依赖于 5.1, 5.2, 5.3）- [ ] 6.1 实施产品搜索和推荐引擎 – 创建与 Elasticsearch 集成的搜索服务 – 添加对分面搜索、自动完成和拼写错误容忍的支持 – 基于类别和受欢迎程度实施基本推荐算法 – 为搜索功能编写集成测试 – 需求：3.3, 7.1- [ ] 6.2 创建与外部系统的库存同步 – 实施用于与仓库管理系统同步库存的服务 – 添加通过 webhooks 进行实时库存更新的支持 – 为库存差异创建冲突解决 – 使用模拟外部系统编写集成测试 – 需求：4.3, 7.2- [ ] 6.3 实施用于性能优化的缓存层 – 为频繁访问的产品和类别数据添加 Redis 缓存 – 为数据一致性实施缓存失效策略 – 为热门产品创建缓存预热流程 – 编写性能测试以验证缓存有效性 – 需求：8.1, 8.2- [ ] 7. 端到端集成和测试（依赖于 6.1, 6.2, 6.3）- [ ] 7.1 创建全面的端到端测试场景 – 为完整的产品生命周期工作流编写 e2e 测试 – 测试包括边缘情况的库存管理场景 – 验证类别管理和产品分配流程 – 为高负载场景创建性能测试 – 需求：5.1, 5.2, 6.1, 6.2- [ ] 7.2 实施监控和可观察性 – 添加应用程序指标和健康检查端点 – 为所有业务操作实施结构化日志记录 – 为关键库存和系统事件创建警报 – 为监控和警报功能编写测试 – 需求：8.3, 8.4
此示例的主要特点：
1.清晰的依赖链：每个主要部分都建立在先前工作的基础上
2.并行开发机会：在 1.x 完成后，可以同时进行任务 2.1、2.2、2.3
3.风险管理：核心功能（模型、存储库）先于高级功能
4.增量价值：每个完成的部分都提供可工作的、可测试的功能
5.全面测试：贯穿始终的单元、集成和 e2e 测试
6.真实世界的复杂性：处理并发、外部集成和性能问题
任务编写最佳实践
编写有效的任务描述
好的任务示例：
[ ] 2.1 创建带验证的用户模型 – 实施具有电子邮件、密码、姓名和 createdAt 字段的用户类 – 添加用于电子邮件格式 (RFC 5322) 和密码强度（8+ 个字符、混合大小写、数字）的验证方法 – 创建涵盖有效/无效电子邮件格式和密码要求的单元测试 – 需求：1.2, 2.1
差的任务示例：
[ ] 2.1 构建用户的东西 – 让用户的东西工作 – 添加一些验证 – 需求：1.2
任务范围指南
适当的任务范围：
• 可以在 1-4 小时的专注工作中完成
• 产生可工作的、可测试的代码
• 有明确的完成标准
• 在先前任务的基础上增量构建
太大：
[ ] 1.1 实施完整的用户管理系统
太小：
[ ] 1.1 在第 42 行添加分号
正好：
[ ] 1.1 创建具有验证方法的用户模型
需求可追溯性
始终包括：
• 引用正在实施的具体需求
• 任务与用户价值之间的明确联系
• 用于测试和验证的可追溯性
示例：
[ ] 3.2 实施密码重置功能 – 创建密码重置请求端点 – 为重置令牌添加电子邮件发送 – 实施安全令牌验证 – 需求：1.3, 4.2
常见的任务规划陷阱
陷阱 1：任务过于抽象
问题：“实施用户管理”
解决方案：“创建具有电子邮件验证和密码哈希的用户模型”
陷阱 2：缺少依赖项
问题：由于未构建先决条件而无法完成的任务
解决方案：对任务进行排序，使每个任务都建立在已完成工作的基础上
陷阱 3：非编码任务
问题：“部署到生产环境”、“获取用户反馈”
解决方案：只关注编码、测试和实施活动
陷阱 4：单体任务
问题：试图一次性实施整个功能的任务
解决方案：分解为更小的增量步骤
陷阱 5：缺少测试任务
问题：只有实施任务而没有相应的测试
解决方案：将测试创建作为每个实施任务的一部分
质量清单
在最终确定任务列表之前，请验证：
完整性：
• 所有设计组件都由实施任务涵盖
• 所有需求都由一个或多个任务解决
• 所有主要功能都包含测试任务
• 集成任务连接所有组件
清晰度：
• 每个任务都有一个清晰、具体的目标
• 任务描述指定要创建哪些文件/组件
• 每个任务都包含需求参考
• 完成标准是隐式或显式的
排序：
• 任务按尊重依赖关系的顺序排列
• 早期任务为后续工作奠定基础
• 核心功能在可选功能之前实施
• 集成任务在组件实施之后进行
可行性：
• 每个任务的范围都适合实施
• 任务可由编码代理完成
• 没有任务需要外部依赖项或手动流程
• 任务复杂性逐渐增加
任务规划问题故障排除
问题：任务过于模糊
症状：开发人员无法根据任务描述开始编码
解决方案：添加更具体的实施细节和文件/组件名称
问题：任务依赖关系不明确
症状：由于缺少先决条件而无法完成任务
解决方案：审查任务顺序并添加缺失的基础任务
问题：任务与需求不对应
症状：难以将任务追溯到用户价值
解决方案：添加需求参考并验证覆盖范围
问题：任务列表过于庞大
症状：任务太多，优先级不明确
解决方案：将相关任务分组并首先关注核心功能
任务执行指南
准备实施
在开始执行任务之前，请确保您已具备：
上下文准备：
• 需求文档可访问且已理解
• 设计文档已审查并内化
• 开发环境已设置并测试
• 测试框架已配置并准备就绪
• 版本控制系统已初始化
任务选择策略：
1.从基础任务开始：始终从设置和核心接口任务开始
2.遵循依赖关系：不要跳到依赖于未完成工作的任务
3.一次一个任务：在转到下一个任务之前完全专注于单个任务
4.在继续之前进行验证：确保每个任务都已完全完成并测试
分步任务执行流程
阶段 1：任务分析
在开始任何任务之前：
1.仔细阅读任务详情：确切了解需要实施的内容
2.审查需求参考：了解正在交付的用户价值
3.检查依赖关系：确保所有先决条件任务都已完成
4.规划实施方法：决定具体的技术方法
5.确定成功标准：了解如何验证完成情况
阶段 2：实施
在任务执行期间：
1.更新任务状态：在开始前将任务标记为“进行中”
2.首先创建测试（如果适用）：编写定义成功的失败测试
3.增量实施：逐步构建功能
4.持续测试：在构建时验证每个部分
5.边做边记录：内联添加注释和文档
阶段 3：验证和完成
在将任务标记为完成之前：
1.运行所有测试：确保新的和现有的测试都通过
2.对照需求进行审查：验证任务是否交付了所需的功能
3.检查集成：确保新代码与现有组件一起工作
4.代码质量审查：检查可维护性和最佳实践
5.更新任务状态：仅在完全验证后标记为完成
任务执行最佳实践
与 AI 编码代理合作
有效的任务执行提示：
我需要实施规范中的任务 [X.Y]。以下是上下文：需求：[引用具体需求]设计上下文：[影响此任务的关键设计决策]任务详情：[复制任务描述和详情]依赖关系：[此任务建立在哪些先前任务的基础上]请按照指定的方法实施此任务，并包括适当的测试。
迭代开发方法：
1.从简单开始：首先实施基本功能
2.逐步增加复杂性：增量构建功能
3.测试每个增量：在继续之前验证每个更改
4.需要时重构：边做边提高代码质量
管理任务依赖关系
依赖验证清单：
• 所有先决条件任务都已标记为完成
• 所需的接口和类型可用
• 必要的配置已到位
• 测试基础设施已准备就绪
处理被阻止的任务：
1.识别缺失的依赖项：具体是什么阻止了进度？
2.检查任务顺序：任务是否正确排序？
3.创建缺失的基础：如果需要，实施最小的先决条件
4.更新任务计划：如果错过了依赖项，则调整顺序
执行期间的质量保证
每个任务的测试策略
单元测试：
• 为单个函数和方法编写测试
• 测试正常路径和错误条件
• 旨在对新功能实现高代码覆盖率
• 使用描述行为的描述性测试名称
集成测试：
• 测试新组件如何与现有代码一起工作
• 验证组件之间的数据流
• 测试跨组件边界的错误处理
• 验证配置和设置是否正常工作
验证测试：
• 对照原始需求进行测试
• 验证面向用户的功能是否按预期工作
• 测试边缘情况和边界条件
• 验证性能是否符合预期
代码质量标准
在实施期间：
• 遵循一致的编码风格和约定
• 为复杂逻辑添加有意义的注释
• 使用描述性的变量和函数名称
• 保持函数专注和单一用途
• 适当地处理错误
在任务完成之前：
• 删除调试代码和控制台日志
• 确保已实施正确的错误处理
• 验证没有引入安全漏洞
• 检查性能影响
• 验证是否满足可访问性要求
常见执行问题故障排除
问题：任务要求不明确
症状：无法确定要实施的具体内容
解决方案：
• 查看原始需求文档以获取上下文
• 查看设计文档以获取实施指南
• 查看相关任务以了解模式和一致性
• 将任务分解为更小、更清晰的子步骤
问题：缺少依赖项
症状：由于缺少先决条件而无法完成任务
解决方案：
• 审查先前的任务以确保它们真正完成
• 确定解除阻塞所需的最小实施
• 考虑是否需要调整任务顺序
• 如有必要，实施临时存根
问题：测试失败
症状：在实施过程中新的或现有的测试中断
解决方案：
• 在修复之前了解测试失败的原因
• 确保新功能不会破坏现有行为
• 如果需求确实发生了变化，则更新测试
• 添加新测试以涵盖发现的边缘情况
问题：任务范围蔓延
症状：实施变得比预期大得多
解决方案：
• 审查原始任务范围并坚持下去
• 确定可以推迟到以后任务的内容
• 将大任务分解为更小、可管理的部分
• 首先关注最小可行实施
进度跟踪和沟通
任务状态管理
状态定义：
•未开始：任务尚未开始
•进行中：正在积极进行实施
•已阻止：由于依赖项或问题而无法继续
•审查中：实施完成，等待验证
•已完成：完全实施、测试和验证
状态更新指南：
• 在开始处理任务时更新状态
• 在任务被阻止或延迟时添加注释
• 仅在满足所有验收标准时标记为完成
• 包括有关实施决策的简要说明
执行期间的文档
实施说明：
• 记录实施期间做出的关键技术决策
• 记录与原始任务计划的任何偏差
• 记录遇到的任何问题以及如何解决这些问题
• 如果实施揭示了差距，则更新设计文档
知识转移：
• 编写清晰的提交消息以解释更改
• 为复杂逻辑添加内联文档
• 使用新的设置或使用说明更新 README 文件
• 为新功能创建示例或演示
调整流程
为不同项目类型定制
小型项目：
• 为提高效率合并相关任务
• 首先关注基本功能
• 使用更简单的测试策略
• 优先考虑可工作的软件而不是详尽的文档
大型项目：
• 保持严格的任务边界
• 在每个步骤实施全面的测试
• 关注可维护性和可扩展性
• 彻底记录架构决策
团队项目：
• 协调任务分配以避免冲突
• 建立代码审查流程
• 在整个团队中使用一致的编码标准
• 定期沟通进度和障碍
处理实施挑战
当任务花费的时间比预期长时：
1. 评估范围是否已超出原始意图
2. 确定是否需要其他子任务
3. 考虑是否应将任务拆分为更小的部分
4. 根据学习情况更新剩余任务的估算
当实施期间需求发生变化时：
1. 停止当前工作并评估影响
2. 首先更新需求和设计文档
3. 在实施计划中修改受影响的任务
4. 向利益相关者沟通变更
5. 使用更新的上下文恢复实施
当出现技术障碍时：
1. 记录具体的技术挑战
2. 研究潜在的解决方案和替代方案
3. 考虑是否需要调整设计
4. 实施最小可行解决方案以保持进度
5. 如果需要，计划在以后的任务中进行优化
与规范驱动开发工作流的集成
与先前阶段的联系
从需求阶段：
• 每个任务都应追溯到具体的需求
• 每个实施任务的用户价值都应清晰
• 验收标准为任务完成验证提供信息
从设计阶段：
• 任务结构遵循架构决策
• 实施方法与设计模式保持一致
• 组件边界尊重设计接口
对早期阶段的反馈
当实施揭示问题时：
• 如果需要调整架构，则更新设计文档
• 如果用户需求被误解，则澄清需求
• 如果错过了依赖项，则修改任务计划
持续改进：
• 记录实施期间吸取到的教训
• 根据执行经验更新任务规划流程
• 为未来项目完善估算准确性
后续步骤
任务完成并批准后：
1.开始实施：使用上述指南按顺序执行任务
2.跟踪进度：在工作完成时更新任务状态
3.保持质量：始终遵循测试和验证实践
4.保持灵活性：如果实施揭示问题，则调整任务
5.对照需求进行验证：确保完成的任务满足原始需求
6.记录学习：为未来的规范驱动开发捕获见解
任务阶段为系统化实施提供了路线图，将复杂的设计分解为可管理、可操作的步骤，从而成功交付功能。通过适当的执行指导，团队可以在整个实施过程中保持质量和势头。
