229 lines
6.3 KiB
Markdown
229 lines
6.3 KiB
Markdown
**1: Align (对齐阶段)**目标: 模糊需求 → 精确规范
|
||
|
||
**执行步骤**
|
||
|
||
**1.项目上下文分析**
|
||
|
||
- 分析现有项目结构、技术栈、架构模式、依赖关系
|
||
- 分析现有代码模式、现有文档和约定
|
||
- 理解业务域和数据模型
|
||
|
||
**2.需求理解确认**
|
||
|
||
- 创建 docs/任务名/ALIGNMENT_[任务名].md
|
||
- 包含项目和任务特性规范
|
||
- 包含原始需求、边界确认(明确任务范围)、需求理解(对现有项目的理解)、疑问澄清(存在歧义的地方)
|
||
|
||
**3.智能决策策略**
|
||
|
||
- 自动识别歧义和不确定性
|
||
- 生成结构化问题清单（按优先级排序）
|
||
- 优先基于现有项目内容和查找类似工程和行业知识进行决策和在文档中回答
|
||
- 有人员倾向或不确定的问题主动中断并询问关键决策点
|
||
- 基于回答更新理解和规范
|
||
|
||
**4.中断并询问关键决策点**
|
||
|
||
主动中断询问，迭代执行智能决策策略
|
||
|
||
**5.最终共识**
|
||
|
||
生成 docs/任务名/CONSENSUS_[任务名].md 包含:
|
||
|
||
- 明确的需求描述和验收标准
|
||
- 技术实现方案和技术约束和集成方案
|
||
- 任务边界限制和验收标准
|
||
- 确认所有不确定性已解决
|
||
|
||
质量门控
|
||
|
||
- 需求边界清晰无歧义
|
||
- 技术方案与现有架构对齐
|
||
- 验收标准具体可测试
|
||
- 所有关键假设已确认
|
||
- 项目特性规范已对齐
|
||
|
||
**阶段2: Architect (架构阶段)目标**:
|
||
|
||
共识文档 → 系统架构 → 模块设计 → 接口规范
|
||
|
||
**执行步骤6.系统分层设计**
|
||
|
||
基于CONSENSUS、ALIGNMENT文档设计架构生成 docs/任务名/DESIGN_[任务名].md 包含:
|
||
|
||
- 整体架构图([mermaid](https://zhida.zhihu.com/search?content_id=261847862&content_type=Article&match_order=1&q=mermaid&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NTU5OTc1MDgsInEiOiJtZXJtYWlkIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjYxODQ3ODYyLCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.D3oqin5gWfqnolYmwRiFAsyk-_fwD8tHaBkHQeFwjZI&zhida_source=entity)绘制)
|
||
- 分层设计和核心组件
|
||
- 模块依赖关系图
|
||
- 接口契约定义
|
||
- 数据流向图
|
||
- 异常处理策略
|
||
|
||
**7.设计原则**
|
||
|
||
- 严格按照任务范围，避免过度设计
|
||
- 确保与现有系统架构一致
|
||
- 复用现有组件和模式
|
||
|
||
**质量门控**
|
||
|
||
- 架构图清晰准确
|
||
- 接口定义完整
|
||
- 与现有系统无冲突
|
||
- 设计可行性验证
|
||
|
||
**阶段3: Atomize (原子化阶段)**
|
||
|
||
**目标**: 架构设计 → 拆分任务 → 明确接口 → 依赖关系
|
||
|
||
**执行步骤**
|
||
|
||
**8.子任务拆分**
|
||
|
||
基于DESIGN文档生成 docs/任务名/TASK_[任务名].md每个原子任务包含:
|
||
|
||
- 输入契约(前置依赖、输入数据、环境依赖)
|
||
- 输出契约(输出数据、交付物、验收标准)
|
||
- 实现约束(技术栈、接口规范、质量要求)
|
||
- 依赖关系(后置任务、并行任务)
|
||
|
||
**9.拆分原则**
|
||
|
||
- 复杂度可控，便于AI高成功率交付
|
||
- 按功能模块分解，确保任务原子性和独立性
|
||
- 有明确的验收标准，尽量可以独立编译和测试
|
||
- 依赖关系清晰
|
||
|
||
**10.生成任务依赖图(使用mermaid)质量门控**
|
||
|
||
- 任务覆盖完整需求
|
||
- 依赖关系无循环
|
||
- 每个任务都可独立验证
|
||
- 复杂度评估合理
|
||
|
||
**阶段4: Approve (审批阶段)**
|
||
|
||
目标: 原子任务 → 人工审查 → 迭代修改 → 按文档执行
|
||
|
||
**执行步骤**
|
||
|
||
**11.执行检查清单**
|
||
|
||
- 完整性：任务计划覆盖所有需求
|
||
- 一致性：与前期文档保持一致
|
||
- 可行性：技术方案确实可行
|
||
- 可控性：风险在可接受范围，复杂度是否可控
|
||
- 可测性：验收标准明确可执行
|
||
|
||
**12.最终确认清单**
|
||
|
||
- 明确的实现需求(无歧义)
|
||
- 明确的子任务定义
|
||
- 明确的边界和限制
|
||
- 明确的验收标准
|
||
- 代码、测试、文档质量标准
|
||
|
||
**阶段5: Automate (自动化执行)**
|
||
|
||
**目标**: 按节点执行 → 编写测试 → 实现代码 → 文档同步
|
||
|
||
**执行步骤**
|
||
|
||
**13.逐步实施子任务**
|
||
|
||
创建 docs/任务名/ACCEPTANCE_[任务名].md 记录完成情况
|
||
|
||
**14.代码质量要求**
|
||
|
||
- 严格遵循项目现有代码规范
|
||
- 保持与现有代码风格一致
|
||
- 使用项目现有的工具和库
|
||
- 复用项目现有组件
|
||
- 代码尽量精简易读
|
||
- API KEY放到.env文件中并且不要提交git
|
||
|
||
**15.异常处理**
|
||
|
||
- 遇到不确定问题立刻中断执行
|
||
- 在TASK文档中记录问题详细信息和位置
|
||
- 寻求人工澄清后继续
|
||
|
||
**16.逐步实施流程 按任务依赖顺序执行，对每个子任务执行:**
|
||
|
||
- 执行前检查(验证输入契约、环境准备、依赖满足)
|
||
- 实现核心逻辑(按设计文档编写代码)
|
||
- 编写单元测试(边界条件、异常情况)
|
||
- 运行验证测试
|
||
- 更新相关文档
|
||
- 每完成一个任务立即验证
|
||
|
||
**阶段6: Assess (评估阶段)**
|
||
|
||
**目标**: 执行结果 → 质量评估 → 文档更新 → 交付确认
|
||
|
||
**执行步骤**
|
||
|
||
**17.验证执行结果**
|
||
|
||
更新 docs/任务名/ACCEPTANCE_[任务名].md整体验收检查:
|
||
|
||
- 所有需求已实现
|
||
- 验收标准全部满足
|
||
- 项目编译通过
|
||
- 所有测试通过
|
||
- 功能完整性验证
|
||
- 实现与设计文档一致
|
||
|
||
**18.质量评估指标**
|
||
|
||
- 代码质量(规范、可读性、复杂度)
|
||
- 测试质量(覆盖率、用例有效性)
|
||
- 文档质量(完整性、准确性、一致性)
|
||
- 现有系统集成良好
|
||
- 未引入技术债务
|
||
|
||
**19.最终交付物**
|
||
|
||
- 生成 docs/任务名/FINAL_[任务名].md(项目总结报告)
|
||
- 生成 docs/任务名/TODO_[任务名].md(精简明确哪些待办的事宜和哪些缺少的配置等，我方便直接寻找支持)
|
||
- **20.TODO询问**
|
||
- 询问用户TODO的解决方式，精简明确哪些待办的事宜和哪些缺少的配置等，同时提供有用的操作指引
|
||
|
||
技术执行规范
|
||
|
||
**安全规范**
|
||
|
||
API密钥等敏感信息使用.env文件管理
|
||
|
||
**文档同步**
|
||
|
||
代码变更同时更新相关文档
|
||
|
||
**测试策略测试优先**：
|
||
|
||
先写测试，后写实现
|
||
|
||
**边界覆盖**：
|
||
|
||
覆盖正常流程、边界条件、异常情况交互体验优化
|
||
|
||
**进度反馈**
|
||
|
||
- 显示当前执行阶段
|
||
- 提供详细的执行步骤
|
||
- 标示完成情况
|
||
- 突出需要关注的问题
|
||
|
||
**异常处理机制中断条件**
|
||
|
||
- 遇到无法自主决策的问题
|
||
- 觉得需要询问用户的问题
|
||
- 技术实现出现阻塞
|
||
- 文档不一致需要确认修正
|
||
|
||
**恢复策略**
|
||
|
||
- 保存当前执行状态
|
||
- 记录问题详细信息
|
||
- 询问并等待人工干预
|
||
- 从中断点任务继续执行
|