6a

name: 6A description: 完整的软件项目开发工作流。适用于新需求、复杂、多步骤任务，涵盖需求对齐(Align)、架构设计(Architect)、任务拆分(Atomize)、人工审批(Approve)、自动化执行(Automate)、质量评估(Assess)六个阶段。确保高质量交付。

阶段1: Align (对齐阶段)

目标: 模糊需求 → 精确规范

执行步骤

1. 项目上下文分析
   • 分析现有项目结构、技术栈、架构模式、依赖关系
   • 分析现有代码模式、现有文档和约定
   • 理解业务域和数据模型
2. 需求理解确认
   • 创建 docs/任务名/ALIGNMENT.md
   • 包含项目和任务特性规范
   • 包含原始需求、边界确认（明确任务范围）、需求理解（对现有项目的理解）、疑问澄清（存在歧义的地方）
3. 智能决策策略
   • 自动识别歧义和不确定性
   • 生成结构化问题清单（按优先级排序）
   • 优先基于现有项目内容和查找类似工程和行业知识进行决策并在文档中回答
   • 有人员倾向或不确定的问题主动中断并询问关键决策点
   • 基于回答更新理解和规范
4. 中断并询问关键决策点
   • 主动中断询问,迭代执行智能决策策略
5. 最终共识
   • 生成 docs/任务名/CONSENSUS.md,包含:
     • 明确的需求描述和验收标准
     • 技术实现方案和技术约束和集成方案
     • 任务边界限制和验收标准
     • 确认所有不确定性已解决
   • 质量门控:
     • 需求边界清晰无歧义
     • 技术方案与现有架构对齐
     • 验收标准具体可测试
     • 所有关键假设已确认
     • 项目特性规范已对齐

阶段2: Architect (架构阶段)

目标: 共识文档 → 系统架构 → 模块设计 → 接口规范

执行步骤

1. 系统分层设计
   • 基于 CONSENSUS、ALIGNMENT 文档设计架构
   • 生成 docs/任务名/DESIGN.md,包含:
     • 整体架构图（使用 Mermaid或PlantUML 绘制）
     • 分层设计和核心组件
     • 模块依赖关系图
     • 接口契约定义
     • 数据流向图
     • 异常处理策略
2. 设计原则
   • 严格按照任务范围,避免过度设计
   • 确保与现有系统架构一致
   • 复用现有组件和模式
   • 质量门控:
     • 架构图清晰准确
     • 接口定义完整
     • 与现有系统无冲突
     • 设计可行性验证

阶段3: Atomize (原子化阶段)

目标: 架构设计 → 拆分任务 → 明确接口 → 依赖关系

执行步骤

1. 子任务拆分
   • 基于 DESIGN 文档生成 docs/任务名/TASK.md,否则用TodoWrite追踪
   • 每个原子任务包含:
     • 输入契约（前置依赖、输入数据、环境依赖）
     • 输出契约（输出数据、交付物、验收标准）
     • 实现约束（技术栈、接口规范、质量要求）
     • 依赖关系（后置任务、并行任务）
2. 拆分原则
   • 复杂度可控,便于 AI 高成功率交付
   • 按功能模块分解,确保任务原子性和独立性
   • 有明确的验收标准,尽量可以独立编译和测试
   • 依赖关系清晰
3. 生成任务依赖图
   • 使用 Mermaid 或 PlantUML 绘制任务依赖图
   • 质量门控:
     • 任务覆盖完整需求
     • 依赖关系无循环
     • 每个任务都可独立验证
     • 复杂度评估合理

阶段4: Approve (审批阶段)

目标: 原子任务 → 人工审查 → 迭代修改 → 按文档执行

执行步骤

1. 执行检查清单
   • 完整性:任务计划覆盖所有需求
   • 一致性:与前期文档保持一致
   • 可行性:技术方案确实可行
   • 可控性:风险在可接受范围,复杂度是否可控
   • 可测性:验收标准明确可执行
2. 最终确认清单
   • 明确的实现需求（无歧义）
   • 明确的子任务定义
   • 明确的边界和限制
   • 明确的验收标准
   • 代码、测试、文档质量标准

阶段5: Automate (自动化执行)

目标: 按节点执行 → 编写测试 → 实现代码 → 文档同步

执行步骤

1. 逐步实施子任务
   • 创建 docs/任务名/SUMMARY.md,记录完成情况
2. 代码质量要求:
   • 严格遵循项目现有代码规范
   • 保持与现有代码风格一致
   • 使用项目现有的工具和库
   • 复用项目现有组件
   • 代码尽量精简易读
3. 异常处理
   • 遇到不确定问题立刻中断执行
   • 在 docs/任务名/TASK.md 文档中记录问题详细信息和位置
   • 寻求人工澄清后继续
4. 逐步实施流程
   • 按任务依赖顺序执行,每个子任务执行:
     • 执行前检查（验证输入契约、环境准备、依赖满足）
     • 实现核心逻辑（按设计文档编写代码）
     • 编写单元测试（边界条件、异常情况）
     • 运行验证测试
     • 更新相关文档
     • 每完成一个任务立即验证

阶段6: Assess (评估阶段)

目标: 执行结果 → 质量评估 → 文档更新 → 交付确认

执行步骤

1. 验证执行结果
   • 更新 docs/任务名/SUMMARY.md
   • 整体验收检查:
     • 所有需求已实现
     • 验收标准全部满足
     • 项目编译通过
     • 所有测试通过
     • 功能完整性验证
     • 实现与设计文档一致
2. 质量评估指标
   • 代码质量（参考代码质量要求）
   • 测试质量（覆盖率、用例有效性）
   • 文档质量（完整性、准确性、一致性）
   • 现有系统集成良好
   • 未引入技术债务
3. 最终交付物
   • 更新 docs/任务名/SUMMARY.md（项目总结报告、精简明确哪些待办的事宜和哪些缺少的配置等,方便直接寻找支持）
4. 询问
   • 询问用户docs/任务名/SUMMARY.md的待办事项解决方式,同时提供有用的操作指引

技术执行规范

文档同步

• 代码变更同时更新相关文档

测试策略

• 测试优先:先写测试,后写实现
• 边界覆盖:覆盖正常流程、边界条件、异常情况

交互体验优化

• 进度反馈:
  • 显示当前执行阶段
  • 提供详细的执行步骤
  • 标示完成情况
  • 突出需要关注的问题

质量门控机制

检查时机

• 每个阶段完成后,进入下一阶段前

失败处理

1. 记录问题:在当前阶段文档末尾添加 ## 质量问题 章节
2. 中断执行:向用户报告具体问题和建议
3. 等待确认:用户选择"修复并继续"或"调整方案"
4. 回退修复:
   • Align失败 → 重新澄清需求
   • Architect失败 → 重新设计架构
   • Atomize失败 → 重新拆分任务
   • 后续阶段失败 → 回到Architect重新评估