@chongyan/autospec 1.0.1

package/knowledge/guides/support/ai-task-assessor.md

@@ -0,0 +1,418 @@
+---
+name: ai-task-assessor
+description: AI 评估任务复杂度，动态推荐流程策略
+type: support
+---
+
+## 定位
+
+替代脚本的复杂度计算，通过理解任务语义进行智能评估，动态推荐流程策略。
+
+## 输入
+
+- 必须输入：
+  - taskDescription: 任务描述
+  - config: 项目配置 (config.json)
+- 可选输入：
+  - historicalTasks: 历史相似任务
+  - projectContext: 项目上下文
+
+## 输出
+
+```json
+{
+  "complexity": "high|medium|low",
+  "factors": {
+    "scope": {
+      "level": "high",
+      "reason": "涉及 3 个子系统：后端、前端、AI 模型",
+      "score": 8
+    },
+    "techStack": {
+      "level": "medium",
+      "reason": "包含 AI 组件，需要效果评测",
+      "score": 6
+    },
+    "integration": {
+      "level": "high",
+      "reason": "需要对接外部 API 和数据库",
+      "score": 7
+    },
+    "uncertainty": {
+      "level": "medium",
+      "reason": "需求有部分模糊点需要澄清",
+      "score": 5
+    },
+    "scale": {
+      "level": "high",
+      "reason": "预估 3 人天，涉及 5+ 功能点",
+      "score": 8
+    }
+  },
+  "recommendations": {
+    "workflow": "waterfall",
+    "roles": ["backend", "frontend", "ai"],
+    "checkpoints": ["design-review", "ai-evaluation", "integration-test"],
+    "estimatedStages": 6
+  },
+  "taskDecomposition": {
+    "needsDecomposition": true,
+    "triggerReasons": [
+      "涉及多子系统",
+      "预估工作量 > 16 小时",
+      "有明确阶段依赖"
+    ],
+    "decompositionPlan": {
+      "strategy": "按系统边界 + 功能模块分层拆解",
+      "phases": [
+        {
+          "id": "P1",
+          "name": "AI 效果验证",
+          "subsystem": "ai",
+          "estimatedHours": 8,
+          "tasks": [
+            {"id": "T1.1", "name": "准备评测数据集", "hours": 2},
+            {"id": "T1.2", "name": "模型训练/调优", "hours": 4},
+            {"id": "T1.3", "name": "效果评测验证", "hours": 2}
+          ],
+          "dependencies": [],
+          "parallelizable": false
+        },
+        {
+          "id": "P2",
+          "name": "后端 API 开发",
+          "subsystem": "backend",
+          "estimatedHours": 12,
+          "tasks": [
+            {"id": "T2.1", "name": "数据模型设计", "hours": 2},
+            {"id": "T2.2", "name": "核心接口实现", "hours": 6},
+            {"id": "T2.3", "name": "单元测试", "hours": 2},
+            {"id": "T2.4", "name": "数据迁移脚本", "hours": 2, "parallel": true}
+          ],
+          "dependencies": ["P1"],
+          "parallelizable": false
+        },
+        {
+          "id": "P3",
+          "name": "前端页面开发",
+          "subsystem": "frontend",
+          "estimatedHours": 6,
+          "tasks": [
+            {"id": "T3.1", "name": "页面开发", "hours": 4},
+            {"id": "T3.2", "name": "接口联调", "hours": 2}
+          ],
+          "dependencies": ["P2"],
+          "parallelizable": true,
+          "parallelWith": ["P4"]
+        },
+        {
+          "id": "P4",
+          "name": "移动端适配",
+          "subsystem": "mobile",
+          "estimatedHours": 4,
+          "tasks": [
+            {"id": "T4.1", "name": "适配开发", "hours": 3},
+            {"id": "T4.2", "name": "真机测试", "hours": 1}
+          ],
+          "dependencies": ["P2"],
+          "parallelizable": true,
+          "parallelWith": ["P3"]
+        }
+      ],
+      "executionBatches": [
+        {"batch": 1, "phases": ["P1"], "reason": "阻塞后续"},
+        {"batch": 2, "phases": ["P2"], "reason": "依赖 P1"},
+        {"batch": 3, "phases": ["P3", "P4"], "reason": "依赖 P2，可并行"}
+      ],
+      "decouplingOpportunities": [
+        {
+          "dependency": "P2 →data→ P3",
+          "decouplable": true,
+          "method": "API契约定义后，后端实现与前端Mock开发并行",
+          "standardArtifact": "OpenAPI Schema",
+          "parallelPattern": "契约定义 → 后端实现 ∥ 前端Mock → 联调",
+          "integrationCost": "低（接口明确）"
+        },
+        {
+          "dependency": "P1 →data→ P2",
+          "decouplable": false,
+          "reason": "AI效果验证不达标则后续无意义，必须串行"
+        }
+      ]
+    }
+  },
+  "risks": [
+    {
+      "area": "AI 模型效果",
+      "risk": "模型效果可能不达标",
+      "mitigation": "建议先进行效果验证 POC"
+    }
+  ],
+  "confidence": 0.85
+}
+```
+
+## 任务拆解触发条件（三视角统一）
+
+任务拆解是一个统一的能力，以下任一条件触发：
+
+| 视角 | 触发条件 | 说明 |
+|------|----------|------|
+| **系统边界** | 涉及多子系统 | 需按系统拆分，明确系统间依赖 |
+| **任务规模** | 预估 > 16 小时 | 大任务必须拆为 2-4 小时的子任务 |
+| **阶段依赖** | 有明确阶段约束 | 如 AI 效果验证 → 后端开发 → 前端对接 |
+
+**拆解原则**：
+1. 按 ATOMIC 原则拆分（每个任务 2-4 小时）
+2. 先按系统边界拆 Phase，再在 Phase 内拆 Task
+3. 明确标注依赖类型和并行机会
+4. 输出执行批次，指导并行执行
+
+## 依赖解耦与并行策略
+
+### 依赖类型与解耦可能性
+
+| 依赖类型 | 标记 | 可解耦？ | 解耦方式 |
+|----------|------|----------|----------|
+| **数据依赖** | `→data` | ✅ 可解耦 | 定义接口协议/数据契约，双方面向标准并行开发 |
+| **逻辑依赖** | `→logic` | ⚠️ 部分可解耦 | 抽象中间层接口，但核心流程仍需串行 |
+| **资源依赖** | `→res` | ❌ 不可解耦 | 共享资源必须串行访问 |
+
+### 面向标准解耦并行
+
+**核心思想**：通过提前定义接口协议/数据契约，将"依赖"转化为"面向标准独立开发"。
+
+```
+传统串行：
+  [后端API实现] →data→ [前端开发]
+  后端完成后前端才能开始
+
+面向标准解耦并行：
+  [API契约定义] ─┬─→ [后端实现]
+                └─→ [前端Mock开发] → [联调验证]
+  契约定义后双方并行，最后联调
+```
+
+**可解耦场景**：
+| 场景 | 标准产出物 | 解耦后并行方式 |
+|------|------------|----------------|
+| 后端↔前端 | API契约（OpenAPI/GraphQL Schema） | 后端实现 ∥ 前端Mock开发 |
+| 后端↔移动端 | API契约 | 后端实现 ∥ 移动端Mock开发 |
+| 数据↔后端 | 数据模型/表结构定义 | 数据管道开发 ∥ 后端接口开发 |
+| AI↔后端 | 模型接口定义（输入输出格式） | 模型训练 ∥ 后端服务开发 |
+| 数据↔数据 | 数据交换格式/Schema | 上游产出定义 ∥ 下游消费开发 |
+
+**解耦标记**：
+- `→contract`：通过契约解耦，契约定义后可并行
+- `→mock`：使用Mock数据并行开发，待上游完成后联调
+
+**不可解耦场景**（必须串行）：
+- 数据库迁移（资源依赖）
+- 配置变更影响多方（资源依赖）
+- 核心业务流程顺序（逻辑依赖，如 创建订单→支付→发货）
+- AI模型效果验证（逻辑依赖，效果不达标则后续无意义）
+
+### 解耦并行判断流程
+
+```
+1. 识别依赖：A →data→ B
+
+2. 判断可解耦性：
+   - 是否有明确的标准产出物可定义？（API契约、数据Schema、接口定义）
+   - 下游是否可基于标准产出物独立验证？（Mock测试、Schema校验）
+   - 联调成本是否可控？（标准明确则联调成本低）
+
+3. 可解耦时：
+   - 先定义标准产出物（契约/Schema）
+   - 标记为 A →contract→ B
+   - 契约定义后 A实现 ∥ B实现 并行
+   - 最后联调验证
+
+4. 不可解耦时：
+   - 保持串行 A →data/logic/res→ B
+   - 不硬跳过依赖
+```
+
+## 复杂度评估维度
+
+### 1. 范围复杂度
+
+| 因素 | 分数范围 | 说明 |
+|-----|---------|------|
+| 单模块 | 1-3 | 只涉及单个模块 |
+| 多模块 | 4-6 | 涉及多个模块 |
+| 多子系统 | 7-10 | 涉及后端、前端、AI 等多个子系统 |
+
+### 2. 技术复杂度
+
+| 因素 | 分数范围 | 说明 |
+|-----|---------|------|
+| 常规技术 | 1-3 | 使用熟悉的框架和工具 |
+| 新技术引入 | 4-6 | 需要引入新技术或框架 |
+| AI/模型组件 | 7-10 | 包含 AI 模型，需要效果评测 |
+
+### 3. 集成复杂度
+
+| 因素 | 分数范围 | 说明 |
+|-----|---------|------|
+| 独立功能 | 1-3 | 不依赖外部系统 |
+| 内部集成 | 4-6 | 需要与内部系统集成 |
+| 外部集成 | 7-10 | 需要对接外部 API 或服务 |
+
+### 4. 不确定性
+
+| 因素 | 分数范围 | 说明 |
+|-----|---------|------|
+| 需求清晰 | 1-3 | 需求明确，无歧义 |
+| 部分模糊 | 4-6 | 有部分需要澄清的点 |
+| 高度不确定 | 7-10 | 需求模糊，需要探索 |
+
+### 5. 任务规模（新增）
+
+| 因素 | 分数范围 | 说明 |
+|-----|---------|------|
+| 小任务 | 1-3 | 预估 < 4 小时，单功能点 |
+| 中任务 | 4-6 | 预估 4-16 小时，多功能点 |
+| 大任务 | 7-10 | 预估 > 16 小时，需拆分为子任务 |
+
+**规模判断依据**：
+- 功能点数量：单一功能 vs 多功能组合
+- 代码量预估：单文件 vs 多文件/多模块
+- 依赖复杂度：独立实现 vs 多依赖协调
+- 实施周期：小时级 vs 天级 vs 周级
+
+## 流程策略推荐
+
+### 复杂度级别对应策略
+
+| 级别 | 总分范围 | 流程策略 | 人工介入点 |
+|-----|---------|---------|-----------|
+| **low** | 5-15 | 精简流程，可跳过可选阶段 | 仅异常情况 |
+| **medium** | 16-30 | 标准流程 | 阶段确认 |
+| **high** | 31-50 | 完整流程 + 额外审查 | 关键决策点 |
+
+### 工作流推荐
+
+| 复杂度 | 推荐工作流 |
+|-------|-----------|
+| low | agile（快速迭代） |
+| medium | waterfall（标准瀑布） |
+| high | waterfall + 额外检查点 |
+
+### 角色推荐
+
+基于任务描述自动识别需要的角色：
+
+- 提到 "API"、"后端"、"数据库" → backend
+- 提到 "界面"、"前端"、"页面" → frontend
+- 提到 "AI"、"模型"、"机器学习" → ai
+- 提到 "数据"、"报表"、"ETL"、"数据仓库"、"数据管道" → data
+
+## 执行步骤
+
+### Step 1: 分析任务描述
+
+```
+1. 提取关键实体和概念
+2. 识别涉及的技术栈
+3. 识别涉及的子系统
+4. 检测不确定性关键词
+```
+
+### Step 2: 评估各维度
+
+```
+1. 范围复杂度评估
+2. 技术复杂度评估
+3. 集成复杂度评估
+4. 不确定性评估
+```
+
+### Step 3: 计算综合复杂度
+
+```
+totalScore = scope + techStack + integration + uncertainty + scale
+complexity = totalScore > 30 ? 'high' : totalScore > 15 ? 'medium' : 'low'
+```
+
+### Step 4: 生成推荐策略
+
+```
+1. 推荐工作流
+2. 推荐角色
+3. 推荐检查点
+4. 识别风险
+```
+
+### Step 5: 评估任务拆解需求（三视角统一）
+
+```
+1. 判断是否需要拆解（三视角）：
+   ┌─────────────────────────────────────────────────────────┐
+   │ 视角1: 系统边界 → 涉及多子系统？→ 按系统拆 Phase        │
+   │ 视角2: 任务规模 → 预估 > 16 小时？→ 按功能拆 Task       │
+   │ 视角3: 阶段依赖 → 有明确阶段约束？→ 按阶段拆分          │
+   └─────────────────────────────────────────────────────────┘
+   任一满足 → 需要拆解
+
+2. 制定拆解策略：
+   - 多子系统 → 先按系统边界拆 Phase，明确系统间依赖
+   - 大任务 → 在 Phase 内按功能模块拆 Task（每任务 2-4h）
+   - 有阶段依赖 → 按 AI验证→后端→前端 顺序排列
+
+3. 识别依赖关系：
+   - 数据依赖（→data）：上游产出作为下游输入
+   - 逻辑依赖（→logic）：业务流程顺序约束
+   - 资源依赖（→res）：共享资源需串行访问
+
+4. 识别解耦并行机会：
+   - 数据依赖 → 检查是否可定义标准产出物（API契约、数据Schema）
+   - 可定义标准 → 标记为 →contract→，契约定义后并行
+   - 不可解耦 → 保持串行，不硬跳过
+
+5. 识别原生并行机会：
+   - 无共享写入资源 → 可并行
+   - 无执行顺序约束 → 可并行
+   - 失败互不影响 → 可并行
+
+6. 输出执行批次：
+   - 按依赖关系和解耦机会计算执行顺序
+   - 标记可并行执行的 Phase/Task
+```
+
+### Step 6: 输出结果
+
+```
+输出结构化 JSON，供后续流程使用
+```
+
+## 与启动门禁的集成
+
+在流程启动时自动调用，结果写入 state.json：
+
+```json
+{
+  "taskAssessment": {
+    "complexity": "medium",
+    "factors": {...},
+    "recommendations": {...}
+  }
+}
+```
+
+## 反模式清单 (DP7)
+
+1. **过度评估**：对简单任务也进行复杂分析
+   - 检测：任务描述 < 50 字符时使用快速评估
+
+2. **忽略历史**：不考虑历史相似任务
+   - 检测：必须检查历史任务库
+
+3. **推荐过于保守**：总是推荐完整流程
+   - 检测：low 复杂度任务必须推荐精简流程
+
+## 适用场景
+
+- 流程启动时自动触发
+- 手动执行 `/autospec:run --assess`
+- 任务变更时重新评估

package/knowledge/guides/support/ai-test-diagnostics.md

@@ -0,0 +1,133 @@
+---
+name: ai-test-diagnostics
+description: 当测试执行失败或需要评估测试质量时，进行深度分析诊断和质量评估，提供修复建议和改进方向。
+type: ai
+---
+
+## 定位
+
+AI 专用技能。接收测试输出，进行深度分析诊断和质量评估，输出结构化的诊断报告和改进建议。
+
+## 输入
+
+- 必须输入：测试执行输出（stdout/stderr）
+- 可选输入：
+  - 测试命令
+  - 测试覆盖率报告
+  - 相关代码文件
+  - 项目技术栈信息
+  - 代码变更列表
+
+## 输出
+
+```json
+{
+  "diagnosis": {
+    "summary": "测试失败分析摘要",
+    "errorCount": 5,
+    "errors": [
+      {
+        "type": "import",
+        "severity": "high",
+        "message": "Cannot find module './utils'",
+        "file": "src/index.js",
+        "line": 3,
+        "suggestion": "检查模块路径是否正确，或运行 npm install"
+      }
+    ],
+    "rootCause": {
+      "type": "import",
+      "confidence": 0.9,
+      "description": "主要问题是模块导入路径错误"
+    },
+    "fixSuggestions": [
+      {
+        "priority": "high",
+        "action": "fix_import",
+        "description": "修复导入路径",
+        "files": ["src/index.js"]
+      }
+    ]
+  },
+  "quality": {
+    "score": 75,
+    "grade": "B",
+    "metrics": {
+      "passRate": { "score": 80, "value": "80%" },
+      "testCoverage": { "score": 70, "value": "65%" },
+      "codeQuality": { "score": 75 },
+      "stability": { "score": 80 }
+    }
+  },
+  "improvements": [
+    {
+      "area": "test_coverage",
+      "priority": "high",
+      "description": "增加对 utils 模块的测试覆盖",
+      "suggestedTests": ["utils/format.test.js"]
+    }
+  ],
+  "testFramework": "vitest",
+  "language": "javascript"
+}
+```
+
+## 执行步骤
+
+### Step 1: 解析测试输出
+
+1. 识别测试框架（vitest/jest/pytest/mocha 等）
+2. 提取错误信息、文件位置、行号
+3. 识别错误类型（语法/导入/类型/逻辑/运行时）
+4. 统计通过/失败数量
+
+### Step 2: 深度诊断
+
+1. **错误分类**：使用 AI 判断错误属于哪类
+2. **影响评估**：评估错误影响的范围（单文件/多文件/整个模块）
+3. **根因分析**：分析最可能的根本原因
+4. **修复优先级**：按影响范围和严重程度排序
+
+### Step 3: 质量评估
+
+1. **通过率分析**：计算测试通过率
+2. **覆盖率分析**：评估测试覆盖是否充分（如有报告）
+3. **代码质量**：基于错误模式评估代码质量
+4. **稳定性**：基于历史数据分析稳定性趋势
+
+### Step 4: 生成建议
+
+1. 针对每个错误给出具体修复建议
+2. 识别测试覆盖缺口
+3. 提出具体改进方向
+4. 优先级排序
+
+### Step 5: 输出综合报告
+
+输出 JSON 格式，包含：
+- 诊断部分：错误统计、根因分析、修复建议
+- 质量部分：质量分数、各维度指标、改进建议
+
+## 规则
+
+- 必须输出结构化 JSON 格式
+- 每个错误必须包含：类型、严重程度、文件位置、修复建议
+- 质量分数范围 0-100
+- 等级：A(90+), B(80+), C(70+), D(60+), F(<60)
+- 优先输出可执行的修复命令
+- 识别哪些问题可以自动修复，哪些需要人工介入
+
+## 反模式清单
+
+1. **只报告错误不分析根因**：必须提供根因分析
+2. **修复建议过于笼统**：必须给出具体可执行的建议
+3. **忽略测试框架差异**：必须识别并适配不同框架的输出格式
+4. **质量评估脱离实际**：必须基于实际数据而非猜测
+5. **改进建议无优先级**：必须按影响和紧急程度排序
+
+## 适用场景
+
+- 测试执行失败，需要诊断原因
+- 需要评估测试质量和覆盖率
+- 需要识别代码质量问题和改进方向
+- 持续集成失败，需要快速定位问题