@zeyue0329/xiaoma-cli 1.0.41 → 1.0.43

package/xiaoma-core/agents/workflow-executor.md

@@ -74,13 +74,18 @@ persona:
     - 自动切换智能体：根据工作流定义，自动使用 /analyst、/architect、/pm、/po、/sm、/dev、/qa 等命令切换到相应的智能体角色
     - 连续执行模式：完成一个步骤后，立即显示简短进度（1-2行）并**无需任何确认**直接进入下一个步骤，直到整个工作流完成或遇到真正的技术错误
     - "🚫 严禁中断询问：不要问'是否继续'、'请选择'、'您希望'等问题。用户启动工作流就是明确要求自动执行到底。唯一允许暂停的情况：文件不存在、执行报错、质量门控失败。"
-    - "✅ 正确的进度报告格式：简短报告 + 立即继续，例如：'✅ 步骤 3/6 完成: PM 创建 PRD → 立即开始步骤 4/6: PM 拆分史诗...'"
+    - "✅ 正确的进度报告格式：简短报告 + 立即继续，例如：'✅ 步骤 3/6 完成: PM 创建 PRD → 立即开始步骤 4/6: PM 拆分模块...'"
 
 # 所有命令在使用时都需要 * 前缀 (例如, *help, *run-requirements-analysis)
 commands:
   - help: 显示以下命令的编号列表以供选择
   - run-requirements-analysis: 🔥 自动化需求分析工作流（完全自动执行，不暂停）- 加载 automated-requirements-analysis.yaml 并连续执行所有 6 个步骤，从 req.txt 到最终的架构设计文档，全程自动化无需人工干预
   - run-story-development: 🔥 自动化用户故事开发工作流（完全自动执行，不暂停）- 加载 automated-story-development.yaml 并循环执行所有用户故事的 SM→PO→Dev→QA 完整开发周期，全程自动化无需人工干预
+  - run-requirements-development: >-
+      🔥🔥🔥 端到端全自动化工作流（完全自动执行，不暂停）-
+      加载 automated-requirements-development.yaml 并连续执行从需求分析到用户故事开发完成的完整流程
+      （阶段1: 需求分析 6步 + 阶段2: 用户故事开发循环），
+      实现从 req.txt 到所有代码完成的端到端自动化
   - status: 显示当前工作流执行状态和进度
   - validate-prerequisites: 验证工作流执行的前置条件
   - resume-workflow: 从上次中断的位置恢复工作流执行（同样会自动连续执行剩余步骤）
@@ -91,6 +96,7 @@ dependencies:
   workflows:
     - automated-requirements-analysis.yaml
     - automated-story-development.yaml
+    - automated-requirements-development.yaml
 ```
 
 ---
@@ -155,7 +161,7 @@ workflow_stages:
     tasks:
       - 创建 Brownfield 项目迭代需求的 PRD 文档
       - 定义功能模块、数据变更、API 规范
-      - 制定验收标准和史诗拆分建议
+      - 制定验收标准和模块拆分建议
       - 自检 PRD 质量（16项检查）
     outputs:
       - docs/prd/brownfield-iteration-prd.md
@@ -163,15 +169,15 @@ workflow_stages:
   stage_4_pm_epics:
     agent: pm
     command: "*create-epic"
-    duration: "变动，取决于史诗数量"
+    duration: "变动，取决于模块数量"
     tasks:
-      - 从 PRD 提取史诗清单
-      - 循环创建每个史诗文档
+      - 从 PRD 提取模块清单
+      - 循环创建每个模块文档
       - 初步识别用户故事
       - 定义技术设计概要和数据库/API 变更
-      - 验证史诗质量
+      - 验证模块质量
     outputs:
-      - docs/epics/史诗-*.md (多个史诗文件)
+      - docs/epics/Epic-*.md (多个模块文件)
 
   stage_5_architect_design:
     agent: architect
@@ -180,7 +186,7 @@ workflow_stages:
     duration: "30-40分钟"
     inputs:
       - docs/prd/brownfield-iteration-prd.md
-      - docs/epics/史诗-*.md
+      - docs/epics/Epic-*.md
       - docs/architecture/current-architecture-analysis.md
     tasks:
       - 设计新增数据模型（Entity + DDL）
@@ -204,7 +210,77 @@ workflow_stages:
 
 ---
 
-### 2. 自动化用户故事开发工作流
+### 2. 🔥🔥🔥 端到端全自动化工作流 (新增)
+
+**命令**: `*run-requirements-development`
+
+**功能**: 执行从需求分析到用户故事开发完成的完整端到端自动化流程
+
+**工作流文件**: `xiaoma-core/workflows/automated-requirements-development.yaml`
+
+**核心价值**:
+- ✅ **一键启动**: 只需执行一个命令，完成从 req.txt 到所有代码的端到端开发
+- ✅ **无缝衔接**: 需求分析阶段自动衔接用户故事开发阶段，无需人工干预
+- ✅ **全程自动化**: 整合了两个子工作流的所有优势，实现完整的自动化流程
+- ✅ **质量保证**: 两个阶段的所有质量门控都会自动执行
+
+**执行流程**:
+
+```yaml
+端到端工作流结构:
+
+阶段 1: 需求分析阶段 (1.5-2.5小时)
+  ├─ 步骤 0/6: 前置环境验证
+  ├─ 步骤 1/6: Analyst 需求分析
+  ├─ 步骤 2/6: Architect 架构分析
+  ├─ 步骤 3/6: PM 创建 PRD
+  ├─ 步骤 4/6: PM 拆分模块
+  ├─ 步骤 5/6: Architect 架构设计
+  └─ 步骤 6/6: 生成需求分析报告
+      ↓
+  阶段间验证（无缝衔接）
+      ↓
+阶段 2: 用户故事开发阶段 (40-70分钟/故事)
+  循环执行（直到所有用户故事完成）:
+    ├─ 步骤 1: SM 创建用户故事
+    ├─ 步骤 1.5: 快速构建验证
+    ├─ 步骤 2: PO 验证故事
+    ├─ 步骤 2.5: 预开发构建检查
+    ├─ 步骤 3: Dev 开发故事
+    ├─ 步骤 4: QA 测试验证
+    └─ 步骤 5: 质量门控决策
+      ↓
+  生成端到端完成报告
+```
+
+**总耗时**:
+- 阶段 1（需求分析）: 约 1.5-2.5 小时
+- 阶段 2（用户故事开发）: 约 40-70 分钟 × 用户故事数量
+- **典型小型项目（5-10个故事）**: 4-8 小时
+- **典型中型项目（10-20个故事）**: 8-16 小时
+
+**成功标准**:
+
+阶段 1 成功标准:
+- ✅ 所有需求分析文档生成完成
+- ✅ PRD 和 Epic 文档创建完成
+- ✅ 架构设计和数据库脚本生成完成
+- ✅ 所有质量门控通过
+
+阶段 2 成功标准:
+- ✅ 所有用户故事状态为 Done
+- ✅ 所有测试通过（覆盖率 ≥80%）
+- ✅ 所有 QA 质量门控通过
+- ✅ 代码质量达标
+
+整体成功标准:
+- ✅ 两个阶段全部完成
+- ✅ 完整的文档和代码生成
+- ✅ 准备就绪进入集成测试和部署阶段
+
+---
+
+### 3. 自动化用户故事开发工作流
 
 **命令**: `*run-story-development`
 
@@ -390,6 +466,84 @@ quality_gates:
 
 ## 📊 使用示例
 
+### 🔥🔥🔥 执行端到端全自动化工作流（推荐）
+
+```bash
+# 1. 准备工作
+# 确保 docs/req.txt 文件存在且包含 PM 提供的需求
+
+# 2. 激活工作流执行器
+/workflow-executor
+
+# 3. 执行端到端全自动化工作流（完全自动化，一键到底）
+*run-requirements-development
+
+# ⚡ 核心优势：一个命令完成从需求分析到代码实现的全部工作！
+# ⚠️ 重要提示：工作流执行器会自动连续执行两个阶段的所有步骤，不会在中间暂停
+# 如果工作流在某个步骤停止，说明遇到了错误或质量门控失败，请查看错误信息
+
+# 工作流执行器将自动完成以下所有工作（典型小项目 4-8 小时）：
+#
+# 【阶段 1: 需求分析】（约 1.5-2.5 小时）
+# ✓ 步骤 0/6: 前置环境验证
+# ✓ 步骤 1/6: Analyst 需求分析 → 生成需求分析报告
+# ✓ 步骤 2/6: Architect 架构分析 → 生成架构分析报告
+# ✓ 步骤 3/6: PM 创建 PRD → 生成 Brownfield PRD
+# ✓ 步骤 4/6: PM 拆分模块 → 生成 Epic 文档
+# ✓ 步骤 5/6: Architect 架构设计 → 生成架构设计和数据库脚本
+# ✓ 步骤 6/6: 生成需求分析完成报告
+#      ↓
+# ✓ 阶段间无缝衔接验证
+#      ↓
+# 【阶段 2: 用户故事开发】（约 40-70 分钟 × 故事数量）
+# 对每个用户故事循环执行：
+#   ✓ SM 创建用户故事 → 快速构建验证
+#   ✓ PO 验证故事（10步验证）
+#   ✓ 预开发构建检查
+#   ✓ Dev 开发实现 + 自测
+#   ✓ QA 测试验证（真实数据测试）
+#   ✓ 质量门控决策 → Done
+# 直到所有用户故事完成
+#      ↓
+# ✓ 生成端到端完成报告
+
+# 4. 工作流完成后检查所有输出
+# 阶段 1 输出:
+# - docs/requirements/requirements-analysis.md
+# - docs/architecture/current-architecture-analysis.md
+# - docs/prd/brownfield-iteration-prd.md
+# - docs/epics/Epic-*.md
+# - docs/architecture/iteration-backend-design.md
+# - docs/architecture/db-migration-scripts.sql
+# - docs/architecture/*.md (7个模块文档)
+#
+# 阶段 2 输出:
+# - docs/stories/epic{X}-story{Y}.md (所有故事状态: Done)
+# - src/ 目录下的实现代码
+# - 测试报告
+# - QA gate 文件
+#
+# 完成报告:
+# - docs/end-to-end-completion-report.md
+```
+
+**🌟 端到端工作流的特殊优势**:
+
+- ✅ **一键到底**: 只需一个命令，无需在两个阶段间手动切换
+- ✅ **无缝衔接**: 阶段1完成后自动验证并进入阶段2，完全自动化
+- ✅ **全程监控**: 统一的进度追踪和质量控制
+- ✅ **完整报告**: 生成包含两个阶段的综合完成报告
+- ✅ **节省时间**: 避免手动操作和阶段间切换的开销
+- ⚠️ **执行时长**: 适合有充足时间的场景（典型小项目 4-8 小时）
+
+**🔥 适用场景**:
+- 从零开始的新需求迭代
+- 需要完整的需求分析和代码实现
+- 有充足的执行时间（半天到一天）
+- 希望最小化人工干预
+
+---
+
 ### 执行需求分析工作流
 
 ```bash
@@ -410,7 +564,7 @@ quality_gates:
 # ✓ 步骤 1/6: 切换到 Analyst 进行需求分析（15-25分钟）
 # ✓ 步骤 2/6: 切换到 Architect 分析现有架构（10-20分钟）
 # ✓ 步骤 3/6: 切换到 PM 创建 Brownfield PRD（20-30分钟）
-# ✓ 步骤 4/6: 切换到 PM 拆分史诗（取决于史诗数量）
+# ✓ 步骤 4/6: 切换到 PM 拆分模块（取决于模块数量）
 # ✓ 步骤 5/6: 切换到 Architect 设计增量架构（30-40分钟）
 # ✓ 步骤 6/6: 生成完成报告
 
@@ -418,7 +572,7 @@ quality_gates:
 # - docs/requirements/requirements-analysis.md
 # - docs/architecture/current-architecture-analysis.md
 # - docs/prd/brownfield-iteration-prd.md
-# - docs/epics/史诗-*.md
+# - docs/epics/Epic-*.md
 # - docs/architecture/iteration-backend-design.md
 # - docs/architecture/db-migration-scripts.sql
 ```
@@ -468,7 +622,7 @@ quality_gates:
 
 # 输出示例：
 # 当前工作流: automated-requirements-analysis
-# 当前阶段: stage_4_pm_epics (PM 拆分史诗)
+# 当前阶段: stage_4_pm_epics (PM 拆分模块)
 # 进度: 60% (3/5 步骤完成)
 # 当前智能体: pm
 # 已完成步骤:
@@ -477,7 +631,7 @@ quality_gates:
 #   ✓ stage_2_architect - 架构分析
 #   ✓ stage_3_pm_prd - PRD 创建
 # 进行中步骤:
-#   ⏳ stage_4_pm_epics - 史诗拆分 (2/4 史诗已创建)
+#   ⏳ stage_4_pm_epics - 模块拆分 (2/4 模块已创建)
 # 待执行步骤:
 #   ⏸ stage_5_architect_design - 架构设计
 ```
@@ -579,7 +733,7 @@ escalation_protocol:
 *validate-prerequisites
 
 # 检查项目：
-# ✓ Epic 文档存在 (docs/epics/史诗-*.md)
+# ✓ Epic 文档存在 (docs/epics/Epic-*.md)
 # ✓ 数据库设计文档存在 (docs/architecture/iteration-backend-design.md)
 # ✓ 架构分析文档存在 (docs/architecture/current-architecture-analysis.md)
 # ✓ 代码生成器配置完成 (如使用 MyBatis-Plus Generator)
@@ -607,7 +761,7 @@ escalation_protocol:
 # 示例输出：
 # 检测到未完成的工作流: automated-requirements-analysis
 # 最后完成的步骤: stage_3_pm_prd (PRD 创建)
-# 准备从步骤 stage_4_pm_epics (史诗拆分) 恢复执行
+# 准备从步骤 stage_4_pm_epics (模块拆分) 恢复执行
 #
 # 验证前序输出:
 # ✓ docs/requirements/requirements-analysis.md
@@ -787,7 +941,7 @@ completion_report:
 # ✅ 步骤 1/6: Analyst 需求分析 → 立即开始步骤 2/6...
 # ✅ 步骤 2/6: Architect 架构分析 → 立即开始步骤 3/6...
 # ✅ 步骤 3/6: PM 创建 PRD → 立即开始步骤 4/6...
-# ✅ 步骤 4/6: PM 拆分史诗 → 立即开始步骤 5/6...
+# ✅ 步骤 4/6: PM 拆分模块 → 立即开始步骤 5/6...
 # ✅ 步骤 5/6: Architect 架构设计 → 立即开始步骤 6/6...
 # ✅ 步骤 6/6: 生成完成报告 → 🎉 工作流完成！
 
@@ -823,9 +977,9 @@ completion_report:
 [20-30分钟后]
 ✅ 步骤 3/6 完成: 已生成 docs/prd/brownfield-iteration-prd.md
 
-正在执行步骤 4/6: PM 拆分史诗...
-[根据史诗数量]
-✅ 步骤 4/6 完成: 已生成 4 个史诗文档
+正在执行步骤 4/6: PM 拆分模块...
+[根据模块数量]
+✅ 步骤 4/6 完成: 已生成 4 个模块文档
 
 正在执行步骤 5/6: Architect 设计增量架构...
 [30-40分钟后]
@@ -841,7 +995,7 @@ completion_report:
 - docs/requirements/requirements-analysis.md
 - docs/architecture/current-architecture-analysis.md
 - docs/prd/brownfield-iteration-prd.md
-- docs/epics/史诗-*.md (4个)
+- docs/epics/Epic-*.md (4个)
 - docs/architecture/iteration-backend-design.md
 - docs/architecture/db-migration-scripts.sql
 

package/xiaoma-core/tasks/batch-story-generation.md

@@ -58,7 +58,7 @@ story_identification:
 
   story_sizing_guidelines:
     - small_story_preference: 优先小故事(1-3天)
-    - epic_breakdown: 大史诗分解策略
+    - epic_breakdown: 大模块分解策略
     - dependency_minimization: 依赖最小化
 ```
 

package/xiaoma-core/tasks/requirements-coverage-audit.md

@@ -11,7 +11,7 @@
 ### 📋 需求转化检查
 
 - PRD文档需求是否完全转化为用户故事
-- 史诗级需求的用户故事覆盖度分析
+- 模块级需求的用户故事覆盖度分析
 - 需求优先级和实施状态匹配度验证
 
 ### ✅ 用户故事完整性检查
@@ -36,10 +36,10 @@
 *requirements-coverage-audit
 ```
 
-### 专注特定史诗的审计
+### 专注特定模块的审计
 
 ```bash
-*coverage-audit --epic=史诗-1基础设施与核心文档展示
+*coverage-audit --epic=模块-1基础设施与核心文档展示
 ```
 
 ### 验证用户故事状态准确性
@@ -54,12 +54,12 @@
 
 1. **加载PRD文档**
    - 读取主PRD文档
-   - 扫描docs/prd/目录下的史诗文件
+   - 扫描docs/prd/目录下的模块文件
    - 提取所有需求和用户故事定义
    - 构建需求层次结构
 
 2. **提取需求矩阵**
-   - 识别所有史诗和用户故事
+   - 识别所有模块和用户故事
    - 提取验收标准和功能点
    - 分析需求优先级
    - 构建需求依赖关系

package/xiaoma-core/templates/fullstack-architecture-tmpl.yaml

@@ -340,7 +340,7 @@ sections:
       1. 如果是 REST API, 创建一个 OpenAPI 3.0 规范
       2. 如果是 GraphQL, 提供 GraphQL 模式
       3. 如果是 tRPC, 展示路由定义
-      4. 包括来自史诗/故事的所有端点
+      4. 包括来自模块/故事的所有端点
       5. 基于数据模型定义请求/响应模式
       6. 记录认证要求
       7. 包括请求/响应示例

package/xiaoma-core/templates/prd-tmpl.yaml

@@ -73,7 +73,7 @@ sections:
         title: 关键交互范式
       - id: core-screens
         title: 核心屏幕与视图
-        instruction: 从产品角度看，为实现 PRD 的价值和目标，最关键的屏幕或视图是什么？这旨在提供概念性的高层概览，以驱动粗略的史诗或用户故事。
+        instruction: 从产品角度看，为实现 PRD 的价值和目标，最关键的屏幕或视图是什么？这旨在提供概念性的高层概览，以驱动粗略的模块或用户故事。
         examples:
           - "登录屏幕"
           - "主仪表盘"
@@ -123,38 +123,38 @@ sections:
         instruction: 在起草本文档的整个过程中，如果提出或发现任何其他适合架构师的技术假设，请在此处作为额外的项目符号添加。
 
   - id: epic-list
-    title: 史诗列表
+    title: 模块列表
     instruction: |
-      向用户呈现一份高层次的史诗列表以供批准。每个史诗应有一个标题和一个简短的（1句话）目标陈述。这使用户能在深入细节之前审阅整体结构。
+      向用户呈现一份高层次的模块列表以供批准。每个模块应有一个标题和一个简短的（1句话）目标陈述。这使用户能在深入细节之前审阅整体结构。
 
-      关键：史诗必须遵循敏捷最佳实践，保持逻辑上的顺序：
+      关键：模块必须遵循敏捷最佳实践，保持逻辑上的顺序：
 
-      - 每个史诗都应交付一个重要的、端到端的、完全可部署且可测试的功能增量。
-      - 史诗 1 必须建立基础项目设施（应用设置、Git、CI/CD、核心服务），除非我们是向现有应用添加新功能。同时，它还应交付一个初始功能，即使只是一个健康检查路由或一个简单的金丝雀页面显示——在为第一个史诗编写用户故事时要记住这一点！
-      - 每个后续的史诗都在之前史诗功能的基础上构建，交付主要的功能模块，这些模块在部署时能为用户或业务提供切实的价值。
-      - 并非每个项目都需要多个史诗，一个史诗需要交付价值。例如，一个已完成的 API 即使 UI 尚未完成并计划在另一个史诗中实现，也可以交付价值。
-      - 倾向于设置较少的史诗，但要告知用户你的理由，并提供拆分选项，如果某些史诗看起来太大或关注点分散的话。
-      - 横切关注点应该贯穿于史诗和用户故事中，而不是作为最后的用户故事。例如，在一个史诗的最后一个故事中添加日志框架，或者在项目结束时作为最后一个史诗或故事来做，这将非常糟糕，因为我们从一开始就没有日志记录。
+      - 每个模块都应交付一个重要的、端到端的、完全可部署且可测试的功能增量。
+      - 模块 1 必须建立基础项目设施（应用设置、Git、CI/CD、核心服务），除非我们是向现有应用添加新功能。同时，它还应交付一个初始功能，即使只是一个健康检查路由或一个简单的金丝雀页面显示——在为第一个模块编写用户故事时要记住这一点！
+      - 每个后续的模块都在之前模块功能的基础上构建，交付主要的功能模块，这些模块在部署时能为用户或业务提供切实的价值。
+      - 并非每个项目都需要多个模块，一个模块需要交付价值。例如，一个已完成的 API 即使 UI 尚未完成并计划在另一个模块中实现，也可以交付价值。
+      - 倾向于设置较少的模块，但要告知用户你的理由，并提供拆分选项，如果某些模块看起来太大或关注点分散的话。
+      - 横切关注点应该贯穿于模块和用户故事中，而不是作为最后的用户故事。例如，在一个模块的最后一个故事中添加日志框架，或者在项目结束时作为最后一个模块或故事来做，这将非常糟糕，因为我们从一开始就没有日志记录。
     elicit: true
     examples:
-      - "史诗 1：基础与核心设施：建立项目设置、认证和基本用户管理"
-      - "史诗 2：核心业务实体：创建和管理主要领域对象的 CRUD 操作"
-      - "史诗 3：用户工作流与交互：实现关键用户旅程和业务流程"
-      - "史诗 4：报告与分析：为用户提供洞察和数据可视化"
+      - "模块 1：基础与核心设施：建立项目设置、认证和基本用户管理"
+      - "模块 2：核心业务实体：创建和管理主要领域对象的 CRUD 操作"
+      - "模块 3：用户工作流与交互：实现关键用户旅程和业务流程"
+      - "模块 4：报告与分析：为用户提供洞察和数据可视化"
 
   - id: epic-details
-    title: 史诗 {{epic_number}} {{epic_title}}
+    title: 模块 {{epic_number}} {{epic_title}}
     repeatable: true
     instruction: |
-      在史诗列表被批准后，将每个史诗及其所有的用户故事和验收标准作为一个完整的审查单元呈现。
+      在模块列表被批准后，将每个模块及其所有的用户故事和验收标准作为一个完整的审查单元呈现。
 
-      为每个史诗提供扩展的目标（2-3 句话描述所有故事将实现的目标和价值）。
+      为每个模块提供扩展的目标（2-3 句话描述所有故事将实现的目标和价值）。
 
       关键的用户故事排序要求：
 
-      - 每个史诗中的用户故事必须在逻辑上是顺序的。
+      - 每个模块中的用户故事必须在逻辑上是顺序的。
       - 每个故事都应该是一个“垂直切片”，交付完整的功能，除了项目基础的早期使能型故事。
-      - 任何故事都不应依赖于后续故事或史诗的工作。
+      - 任何故事都不应依赖于后续故事或模块的工作。
       - 识别并注明任何直接的前置故事。
       - 关注“做什么”和“为什么”，而不是“怎么做”（将技术实现留给架构师），但要足够精确以支持故事之间逻辑上顺序的操作。
       - 确保每个故事都交付明确的用户或业务价值，尽量避免使能型故事，而是将它们构建到交付价值的故事中。

package/xiaoma-core/templates/requirements-coverage-audit.yaml

@@ -25,7 +25,7 @@ description: |
 
   📋 **需求转化检查**:
   - PRD文档需求是否完全转化为用户故事
-  - 史诗级需求的用户故事覆盖度
+  - 模块级需求的用户故事覆盖度
   - 需求优先级和实施状态匹配度
 
   ✅ **用户故事完整性检查**:
@@ -51,7 +51,7 @@ execution:
         description: "加载PRD文档"
         actions:
           - "读取主PRD文档"
-          - "扫描docs/prd/目录下的史诗文件"
+          - "扫描docs/prd/目录下的模块文件"
           - "提取所有需求和用户故事定义"
           - "构建需求层次结构"
         output: "requirements_inventory.json"
@@ -59,7 +59,7 @@ execution:
       - step: "extract_requirements_matrix"
         description: "提取需求矩阵"
         actions:
-          - "识别所有史诗和用户故事"
+          - "识别所有模块和用户故事"
           - "提取验收标准和功能点"
           - "分析需求优先级"
           - "构建需求依赖关系"
@@ -204,7 +204,7 @@ report_structure:
     sections:
       - requirements_coverage_matrix:
           title: "需求覆盖度矩阵"
-          content: "史诗-用户故事映射表"
+          content: "模块-用户故事映射表"
       - story_completeness_analysis:
           title: "用户故事完整性分析"
           content: "每个故事的完整性评分"
@@ -322,8 +322,8 @@ usage_examples:
     *requirements-coverage-audit
 
   focused_audit: |
-    # 专注于特定史诗的审计
-    *coverage-audit --epic=史诗-1基础设施与核心文档展示
+    # 专注于特定模块的审计
+    *coverage-audit --epic=模块-1基础设施与核心文档展示
 
   status_verification: |
     # 验证用户故事状态准确性