@zeyue0329/xiaoma-cli 1.0.48 → 6.0.0-alpha.13

package/src/modules/xmc/workflows/auto-iteration/full-auto-workflow.md

@@ -0,0 +1,692 @@
+# 全自动迭代开发工作流
+
+> **工作流 ID**: auto-iterate
+> **触发命令**: `*auto-iterate`
+> **智能体**: Phoenix (全自动化迭代开发编排器)
+
+---
+
+## 知识库集成
+
+### 知识库配置
+
+```yaml
+knowledge_base:
+  # 当前模式: rag (前期) | mcp (后期)
+  mode: "rag"
+
+  # RAG 模式配置
+  rag:
+    file_path: "{project-root}/docs/rag/rag.md"
+
+  # MCP 模式配置 (未来)
+  mcp:
+    server: "knowledge-base-mcp"
+    endpoint: "mcp__kb__query"
+```
+
+### 知识库调用机制
+
+在执行过程中，遇到以下场景时会自动查询知识库：
+
+| 阶段 | 调用场景 | 查询类型 |
+|-----|---------|---------|
+| Phase 1 | 遇到业务术语 | 业务 |
+| Phase 1 | 识别功能需求时验证业务规则 | 业务 |
+| Phase 1 | 分析业务流程 | 业务 |
+| Phase 2 | 创建用户故事时查询角色定义 | 业务 |
+| Phase 2 | 定义验收标准时查询参考模板 | 业务+技术 |
+| Phase 2 | 定义NFR时查询标准 | 技术 |
+| Phase 3 | 技术选型时查询规范 | 技术 |
+| Phase 3 | 架构设计时查询模式 | 技术 |
+| Phase 3 | API设计时查询规范 | 技术 |
+| Phase 4 | 编写代码时查询编码规范 | 技术 |
+| Phase 4 | 实现业务逻辑时查询规则 | 业务 |
+| Phase 4 | 编写测试时查询测试规范 | 技术 |
+| Phase 5 | 验证覆盖率时查询要求 | 技术 |
+| Phase 5 | 质量门禁检查时查询标准 | 技术 |
+
+**详细调用点定义**: 参见 `knowledge-base/kb-call-points.md`
+
+---
+
+## 工作流概述
+
+本工作流实现从需求文档到代码实现的全自动化执行，融合7大智能体能力，通过知识库驱动所有决策，实现零人工干预的端到端开发。
+
+```
+┌─────────────────────────────────────────────────────────────────────────┐
+│                        全自动迭代开发流程                                  │
+├─────────────────────────────────────────────────────────────────────────┤
+│  输入                                                                    │
+│  ├─ 📄 迭代需求文档（产品经理提供）                                        │
+│  ├─ 📚 业务知识库（业务规则、领域知识）                                     │
+│  └─ 🔧 技术知识库（技术规范、代码规范、架构模式）                            │
+├─────────────────────────────────────────────────────────────────────────┤
+│  Phase 1: 需求分析 [Analyst 能力]                                        │
+│  ├─ 解析需求文档                                                         │
+│  ├─ 匹配业务知识库规则                                                    │
+│  ├─ 识别隐含需求和约束                                                    │
+│  └─ 输出: 结构化需求分析报告                                              │
+├─────────────────────────────────────────────────────────────────────────┤
+│  Phase 2: 需求规划 [PM + PO 能力]                                        │
+│  ├─ 创建 PRD 文档                                                        │
+│  ├─ 定义功能需求 (FRs)                                                   │
+│  ├─ 定义非功能需求 (NFRs)                                                │
+│  ├─ 创建史诗和用户故事                                                    │
+│  └─ 输出: PRD + Epic + Stories                                          │
+├─────────────────────────────────────────────────────────────────────────┤
+│  Phase 3: 架构设计 [Architect 能力]                                      │
+│  ├─ 分析现有代码架构                                                      │
+│  ├─ 设计技术方案                                                         │
+│  ├─ 匹配技术知识库规范                                                    │
+│  ├─ 创建数据模型设计                                                      │
+│  └─ 输出: 架构设计文档 + ADR                                             │
+├─────────────────────────────────────────────────────────────────────────┤
+│  Phase 4: 开发实现 [SM + DEV 能力]                                       │
+│  ├─ Sprint 规划                                                         │
+│  ├─ For Each Story:                                                     │
+│  │   ├─ 创建故事上下文                                                   │
+│  │   ├─ TDD 驱动实现                                                    │
+│  │   ├─ 代码审查                                                        │
+│  │   └─ 更新状态                                                        │
+│  └─ 输出: 实现的代码 + 测试                                              │
+├─────────────────────────────────────────────────────────────────────────┤
+│  Phase 5: 测试验证 [TEA 能力]                                            │
+│  ├─ 执行单元测试                                                         │
+│  ├─ 执行集成测试                                                         │
+│  ├─ 质量门禁检查                                                         │
+│  └─ 输出: 测试报告 + 质量报告                                             │
+├─────────────────────────────────────────────────────────────────────────┤
+│  输出                                                                    │
+│  ├─ ✅ 完整的代码实现                                                     │
+│  ├─ ✅ 完整的测试覆盖                                                     │
+│  ├─ ✅ 完整的文档产出                                                     │
+│  └─ ✅ 执行报告和追溯记录                                                  │
+└─────────────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 执行指令
+
+当用户输入 `*auto-iterate` 时，按以下流程自动执行：
+
+### Step 0: 初始化
+
+```markdown
+## 初始化检查清单
+
+1. **检查必要输入**
+   - [ ] 迭代需求文档路径或内容
+   - [ ] 目标项目路径
+
+2. **加载知识库 (RAG 模式)**
+   - 读取 `{project-root}/docs/rag/rag.md` 文件
+   - 解析知识库结构（业务知识 + 技术知识）
+   - 构建关键词索引
+
+3. **创建执行状态文件**
+   - 创建 `auto-iteration-status.yaml`
+   - 记录开始时间和初始状态
+   - 记录知识库加载状态
+```
+
+**执行动作**：
+
+```
+## 启动全自动迭代开发
+
+### 第一步：加载知识库
+
+正在读取知识库文件: {project-root}/docs/rag/rag.md
+
+**知识库加载结果**:
+- 业务术语: X 条
+- 业务规则: X 条
+- 业务流程: X 条
+- 技术规范: X 条
+- 编码规范: X 条
+- 架构模式: X 条
+
+✅ 知识库加载完成
+
+### 第二步：请提供迭代需求
+
+请粘贴产品经理提供的迭代需求文档内容：
+
+### 第三步：确认项目路径
+
+目标代码库路径: {project-root}
+确认后将开始全自动执行。
+```
+
+**知识库查询示例**：
+
+在执行过程中，当遇到需要查询知识库的场景时，将按以下格式执行：
+
+```yaml
+# 知识库查询
+call_point: "KBC-1.2"
+question: "请查询与用户偏好设置相关的业务规则"
+source: "{project-root}/docs/rag/rag.md"
+
+# 执行步骤
+1. 提取关键词: ["用户", "偏好", "设置", "业务规则"]
+2. 在 rag.md 中搜索匹配章节
+3. 返回匹配内容
+
+# 查询结果
+found: true
+content: |
+  ### 规则: BR-003 偏好设置规则
+  - 每个用户可设置最多100个偏好项
+  - 偏好键名长度不超过100字符
+  - ...
+source_section: "业务规则 > BR-003"
+confidence: "high"
+
+# 决策
+基于知识库 BR-003 规则，实现中必须：
+1. 限制偏好数量为100
+2. 验证键名长度
+3. ...
+```
+
+---
+
+### Step 1: 需求分析阶段 (Phase 1)
+
+**角色激活**: Analyst (需求分析师)
+
+**自动执行内容**:
+
+```yaml
+phase: 1
+name: 需求分析
+role: Analyst
+inputs:
+  - 迭代需求文档
+  - 业务知识库
+outputs:
+  - requirement-analysis.md
+
+tasks:
+  - name: 解析需求文档
+    action: |
+      1. 读取需求文档全文
+      2. 提取功能点列表
+      3. 提取业务规则
+      4. 提取约束条件
+
+  - name: 匹配业务知识库
+    action: |
+      1. 在知识库中检索相关业务规则
+      2. 验证需求与现有业务规则的一致性
+      3. 识别需要新增的业务规则
+      4. 标记潜在的业务冲突
+
+  - name: 识别隐含需求
+    action: |
+      1. 基于业务知识推断隐含需求
+      2. 基于技术约束推断非功能需求
+      3. 基于用户场景推断边界条件
+
+  - name: 生成分析报告
+    output: requirement-analysis.md
+    template: |
+      # 需求分析报告
+
+      ## 1. 需求概述
+      [从需求文档提取的核心需求描述]
+
+      ## 2. 功能点清单
+      | ID | 功能点 | 优先级 | 知识库匹配 |
+      |----|-------|-------|-----------|
+
+      ## 3. 业务规则匹配
+      ### 已匹配的业务规则
+      [从知识库匹配到的规则]
+
+      ### 新增业务规则
+      [需要新增的规则]
+
+      ## 4. 隐含需求
+      [推断出的隐含需求]
+
+      ## 5. 约束和风险
+      [识别的约束条件和潜在风险]
+
+      ## 6. 下一阶段输入
+      [为 Phase 2 准备的结构化输入]
+```
+
+**质量门禁**:
+- [ ] 所有功能点都已识别
+- [ ] 业务规则匹配率 > 80%
+- [ ] 无未解决的业务冲突
+
+**阻塞处理**:
+- 如果业务规则匹配率 < 80%，自动在知识库中扩大搜索范围
+- 如果存在业务冲突，记录冲突并标记为"需确认"，继续执行
+
+---
+
+### Step 2: 需求规划阶段 (Phase 2)
+
+**角色激活**: PM (产品经理) + PO (产品负责人)
+
+**自动执行内容**:
+
+```yaml
+phase: 2
+name: 需求规划
+role: PM + PO
+inputs:
+  - requirement-analysis.md
+  - 业务知识库
+outputs:
+  - prd.md
+  - epics/
+  - stories/
+
+tasks:
+  - name: 创建 PRD
+    action: |
+      1. 基于需求分析报告创建 PRD
+      2. 定义产品目标和成功指标
+      3. 详细描述每个功能需求 (FR)
+      4. 定义非功能需求 (NFR)
+    output: prd.md
+
+  - name: 创建史诗
+    action: |
+      1. 将功能需求按模块分组为史诗
+      2. 定义每个史诗的业务价值
+      3. 确定史诗间的依赖关系
+    output: epics/
+
+  - name: 分解用户故事
+    action: |
+      1. 将每个史诗分解为用户故事
+      2. 使用 INVEST 原则验证故事质量
+      3. 定义接受标准 (Given/When/Then)
+      4. 估算故事点
+    output: stories/
+
+  - name: PO 验收标准审核
+    action: |
+      1. 验证每个故事的业务价值
+      2. 确认接受标准完整性
+      3. 确认优先级排序
+```
+
+**PRD 模板**:
+
+```markdown
+# 产品需求文档 (PRD)
+
+## 1. 产品概述
+### 1.1 背景
+### 1.2 目标
+### 1.3 成功指标
+
+## 2. 功能需求 (FRs)
+### FR-001: [功能名称]
+- **描述**:
+- **用户故事**: As a [角色], I want [功能], So that [价值]
+- **接受标准**:
+  - Given [前置条件]
+  - When [操作]
+  - Then [预期结果]
+- **优先级**: P0/P1/P2
+- **知识库依据**: [引用的业务规则]
+
+## 3. 非功能需求 (NFRs)
+### NFR-001: 性能要求
+### NFR-002: 安全要求
+### NFR-003: 可用性要求
+
+## 4. 依赖和约束
+## 5. 风险和缓解措施
+```
+
+**质量门禁**:
+- [ ] PRD 覆盖所有已识别的功能点
+- [ ] 每个故事都有明确的接受标准
+- [ ] 故事点估算完成
+- [ ] 优先级排序完成
+
+---
+
+### Step 3: 架构设计阶段 (Phase 3)
+
+**角色激活**: Architect (架构师)
+
+**自动执行内容**:
+
+```yaml
+phase: 3
+name: 架构设计
+role: Architect
+inputs:
+  - prd.md
+  - epics/
+  - 技术知识库
+  - 现有代码库
+outputs:
+  - architecture.md
+  - adr/
+
+tasks:
+  - name: 分析现有架构
+    action: |
+      1. 扫描目标代码库结构
+      2. 识别现有技术栈
+      3. 识别现有架构模式
+      4. 识别可复用组件
+
+  - name: 设计技术方案
+    action: |
+      1. 基于 PRD 设计技术实现方案
+      2. 匹配技术知识库中的最佳实践
+      3. 设计新增组件和模块
+      4. 设计 API 接口
+
+  - name: 数据模型设计
+    action: |
+      1. 设计新增/变更的数据表
+      2. 创建 ER 图
+      3. 设计数据迁移策略
+
+  - name: 技术决策记录
+    action: |
+      1. 记录关键技术选型
+      2. 记录选型理由和权衡
+      3. 引用技术知识库依据
+    output: adr/
+```
+
+**架构文档模板**:
+
+```markdown
+# 架构设计文档
+
+## 1. 系统架构概览
+### 1.1 架构图
+[Mermaid 图]
+
+### 1.2 组件说明
+
+## 2. 技术决策
+### ADR-001: [决策标题]
+- **状态**: 已采纳
+- **上下文**: [为什么需要这个决策]
+- **决策**: [具体决策内容]
+- **理由**: [为什么这样决策]
+- **知识库依据**: [引用的技术规范]
+
+## 3. 数据模型
+### 3.1 ER 图
+### 3.2 表结构设计
+
+## 4. API 设计
+### 4.1 新增接口
+### 4.2 变更接口
+
+## 5. 文件变更清单
+| 文件路径 | 变更类型 | 说明 |
+|---------|---------|------|
+```
+
+**质量门禁**:
+- [ ] 架构设计覆盖所有功能需求
+- [ ] 技术决策都有知识库依据
+- [ ] 数据模型设计完整
+- [ ] API 设计符合现有规范
+
+---
+
+### Step 4: 开发实现阶段 (Phase 4)
+
+**角色激活**: SM (Scrum Master) + DEV (开发者)
+
+**自动执行内容**:
+
+```yaml
+phase: 4
+name: 开发实现
+role: SM + DEV
+inputs:
+  - architecture.md
+  - stories/
+  - 技术知识库
+outputs:
+  - 实现的代码
+  - 测试代码
+  - sprint-status.yaml
+
+tasks:
+  - name: Sprint 规划
+    role: SM
+    action: |
+      1. 基于故事优先级和依赖关系排序
+      2. 创建 sprint-status.yaml
+      3. 确定故事执行顺序
+
+  - name: 故事开发循环
+    role: DEV
+    repeat: for_each_story
+    action: |
+      1. 读取故事上下文
+      2. 分解为任务和子任务
+      3. TDD 驱动实现:
+         a. 编写失败的测试
+         b. 实现代码使测试通过
+         c. 重构优化
+      4. 代码审查
+      5. 更新故事状态
+```
+
+**TDD 执行流程**:
+
+```
+For Each Task in Story:
+  ┌──────────────────────────────────┐
+  │ 1. 编写测试 (Red)                 │
+  │    - 根据接受标准编写测试用例       │
+  │    - 运行测试，确认失败            │
+  ├──────────────────────────────────┤
+  │ 2. 实现代码 (Green)               │
+  │    - 编写最小代码使测试通过         │
+  │    - 运行测试，确认通过            │
+  ├──────────────────────────────────┤
+  │ 3. 重构 (Refactor)               │
+  │    - 优化代码结构                 │
+  │    - 确保测试仍然通过             │
+  ├──────────────────────────────────┤
+  │ 4. 代码审查                       │
+  │    - 检查代码质量                 │
+  │    - 检查规范合规性               │
+  │    - 检查安全性                   │
+  └──────────────────────────────────┘
+```
+
+**质量门禁**:
+- [ ] 所有测试通过
+- [ ] 代码审查通过
+- [ ] 无安全漏洞
+- [ ] 符合代码规范
+
+---
+
+### Step 5: 测试验证阶段 (Phase 5)
+
+**角色激活**: TEA (测试架构师)
+
+**自动执行内容**:
+
+```yaml
+phase: 5
+name: 测试验证
+role: TEA
+inputs:
+  - 实现的代码
+  - 测试代码
+  - prd.md
+outputs:
+  - test-report.md
+  - quality-report.md
+
+tasks:
+  - name: 执行测试套件
+    action: |
+      1. 运行单元测试
+      2. 运行集成测试
+      3. 收集测试覆盖率
+
+  - name: 质量门禁检查
+    action: |
+      1. 检查测试覆盖率 >= 80%
+      2. 检查无失败测试
+      3. 检查代码质量指标
+      4. 检查安全扫描结果
+
+  - name: 生成报告
+    action: |
+      1. 生成测试报告
+      2. 生成质量报告
+      3. 生成追溯矩阵
+```
+
+**质量门禁**:
+- [ ] 测试覆盖率 >= 80%
+- [ ] 所有测试通过
+- [ ] 无严重安全漏洞
+- [ ] 代码质量评分 >= B
+
+---
+
+## 阻塞处理机制
+
+当执行过程中遇到阻塞时，按以下优先级处理：
+
+```yaml
+blocking_resolution:
+  level_1_knowledge_base:
+    description: 首先在知识库中检索解决方案
+    actions:
+      - 扩大关键词搜索范围
+      - 检索相似问题的解决方案
+      - 查找相关技术文档
+
+  level_2_inference:
+    description: 基于知识库推断解决方案
+    actions:
+      - 基于相似案例推断
+      - 基于技术规范推断
+      - 基于最佳实践推断
+
+  level_3_default:
+    description: 使用默认策略继续执行
+    actions:
+      - 采用保守的默认实现
+      - 记录决策供后续审查
+      - 继续执行后续步骤
+
+  level_4_human:
+    description: 标记为需人工介入（最后手段）
+    actions:
+      - 记录详细的阻塞信息
+      - 暂停当前任务
+      - 继续执行其他无依赖任务
+```
+
+---
+
+## 状态追踪
+
+执行过程中自动更新 `auto-iteration-status.yaml`:
+
+```yaml
+# auto-iteration-status.yaml
+execution:
+  id: "iter-2024-001"
+  started_at: "2024-01-15T10:00:00Z"
+  status: "in_progress"  # pending | in_progress | completed | blocked
+
+phases:
+  phase_1_analyze:
+    status: "completed"
+    started_at: "2024-01-15T10:00:00Z"
+    completed_at: "2024-01-15T10:15:00Z"
+    outputs:
+      - requirement-analysis.md
+
+  phase_2_plan:
+    status: "completed"
+    outputs:
+      - prd.md
+      - epics/epic-001.md
+      - stories/story-001.md
+
+  phase_3_design:
+    status: "in_progress"
+    current_task: "数据模型设计"
+
+  phase_4_develop:
+    status: "pending"
+
+  phase_5_test:
+    status: "pending"
+
+blocking_issues: []
+
+knowledge_base_queries:
+  - query: "用户认证最佳实践"
+    result: "found"
+    source: "tech-kb/auth-patterns.md"
+```
+
+---
+
+## 执行完成
+
+当所有阶段完成后，输出最终报告：
+
+```markdown
+# 迭代开发执行报告
+
+## 执行摘要
+- **执行 ID**: iter-2024-001
+- **开始时间**: 2024-01-15 10:00:00
+- **完成时间**: 2024-01-15 14:30:00
+- **总耗时**: 4.5 小时
+- **状态**: ✅ 成功完成
+
+## 产出物清单
+### 文档
+- [ ] requirement-analysis.md
+- [ ] prd.md
+- [ ] architecture.md
+- [ ] test-report.md
+
+### 代码
+- [ ] 新增文件: 12 个
+- [ ] 修改文件: 8 个
+- [ ] 测试文件: 15 个
+
+### 测试结果
+- 单元测试: 45/45 通过
+- 集成测试: 12/12 通过
+- 覆盖率: 87%
+
+## 知识库使用统计
+- 业务规则匹配: 23 条
+- 技术规范引用: 15 条
+- 新增知识建议: 3 条
+
+## 后续建议
+1. [建议内容]
+2. [建议内容]
+```