@chongyan/autospec 1.0.2 → 1.0.4

package/knowledge/03-guides/34-assess-ai-task.md

@@ -1,418 +0,0 @@
----
-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/03-guides/35-evaluate-ai-pipeline.md

@@ -1,219 +0,0 @@
----
-name: ai-pipeline-evaluator
-description: 基于 Trace 日志生成流程评测报告
-type: review
----
-
-## 定位
-
-基于过程指标 + 结果指标 + 路径指标，自动生成流程评测报告，识别改进机会，触发进化机制。
-
-## 输入
-
-- 必须输入：
-  - traceId: 流程追踪 ID
-- 可选输入：
-  - logs/: 相关日志文件
-  - metrics: 质量指标数据
-
-## 评测维度
-
-### 1. 过程指标 (权重 30%)
-
-| 指标 | 权重 | 说明 |
-|-----|------|------|
-| Layer1 首次通过率 | 25% | 代码质量 |
-| Layer2 首次通过率 | 20% | 设计质量 |
-| 人工介入率 | 15% | 自主能力（反向） |
-| 回退率 | 15% | 流程顺畅度（反向） |
-| 错误率 | 10% | 稳定性（反向） |
-| 阶段成功率 | 15% | 完成度 |
-
-### 2. 结果指标 (权重 40%)
-
-| 指标 | 权重 | 说明 |
-|-----|------|------|
-| 产出物平均评分 | 40% | 产出质量 |
-| 一致性评分 | 30% | 产物一致性 |
-| 结构完整性 | 30% | 规范遵循 |
-
-### 3. 路径指标 (权重 30%)
-
-| 指标 | 权重 | 说明 |
-|-----|------|------|
-| 流程合规性 | 30% | 规范遵循 |
-| 执行效率 | 25% | 资源利用 |
-| 决策质量 | 25% | 自主决策能力 |
-| 异常处理 | 20% | 容错能力 |
-
-## 输出格式
-
-```markdown
-# AutoSpec 流程评测报告
-
-## 执行摘要
-
-| 指标 | 值 |
-|-----|-----|
-| Trace ID | {{traceId}} |
-| 执行时间 | {{duration}} |
-| 综合评分 | {{overallScore}}/100 ({{grade}}) |
-
-## 过程指标
-
-### Layer1/Layer2 验证
-- Layer1 首次通过率: {{layer1FirstPassRate}}%
-- Layer2 首次通过率: {{layer2FirstPassRate}}%
-
-### 流程效率
-- 阶段成功率: {{stageSuccessRate}}%
-- 回退次数: {{rollbackCount}}
-- 人工介入次数: {{humanInterventionCount}}
-
-### 错误分析
-- 总错误数: {{errorCount}}
-- 错误类型分布: {{errorTypeDistribution}}
-
-## 结果指标
-
-### 产出物质量
-| 产出物 | 评分 | 主要问题 |
-|-------|------|---------|
-{{#artifacts}}
-| {{name}} | {{score}} | {{mainIssue}} |
-{{/artifacts}}
-
-### 一致性检测
-- 一致性问题数: {{consistencyIssues}}
-- 主要不一致类型: {{mainInconsistency}}
-
-## 路径指标
-
-### 流程合规性
-- 阶段路径: {{stagePath}}
-- 违规项: {{violations}}
-
-### 执行效率
-- 重复操作: {{repeatedOps}} 次
-- 工具使用效率: {{toolEfficiency}}%
-
-### 决策质量
-- 人工介入率: {{humanRate}}%
-- 自动决策成功率: {{autoSuccessRate}}%
-
-## 改进建议
-
-### 高优先级
-{{#highPrioritySuggestions}}
-- {{.}}
-{{/highPrioritySuggestions}}
-
-### 中优先级
-{{#mediumPrioritySuggestions}}
-- {{.}}
-{{/mediumPrioritySuggestions}}
-
-## 进化触发建议
-
-{{#evolutionTriggers}}
-- **{{type}}**: {{reason}}
-  - 建议行动: {{action}}
-{{/evolutionTriggers}}
-```
-
-## 执行步骤
-
-### Step 1: 收集数据
-
-```
-1. 读取 metrics.json
-2. 读取 trace 日志
-3. 读取产出物评测结果
-```
-
-### Step 2: 计算各维度分数
-
-```
-1. 计算过程指标分数
-2. 计算结果指标分数
-3. 计算路径指标分数
-```
-
-### Step 3: 计算综合评分
-
-```
-overallScore = process * 0.3 + result * 0.4 + path * 0.3
-grade = getGrade(overallScore)
-```
-
-### Step 4: 分析改进点
-
-```
-1. 识别低分维度
-2. 分析问题根因
-3. 生成改进建议
-```
-
-### Step 5: 检测进化触发
-
-```
-1. 检测重复错误模式
-2. 检测低效阶段
-3. 检测质量下降信号
-```
-
-### Step 6: 生成报告
-
-```
-1. 生成 Markdown 格式报告
-2. 保存到 .autospec/logs/evaluation/
-3. 更新 metrics.json
-```
-
-## 进化触发规则
-
-| 条件 | 触发动作 |
-|-----|---------|
-| 同类错误 >= 3 次 | 创建 practice-log |
-| 质量分数 < 70 | 触发 methodology 审查 |
-| 新模式识别 | 触发 skill 提案 |
-| 阶段效率持续低 | 触发 skill 优化 |
-
-## 与 metrics.json 的集成
-
-评测结果写入 metrics.json：
-
-```json
-{
-  "qualityScore": {
-    "overall": 85,
-    "grade": "B",
-    "breakdown": {
-      "process": { "score": 80 },
-      "result": { "score": 88 },
-      "path": { "score": 86 }
-    }
-  },
-  "evaluationReport": {
-    "path": ".autospec/logs/evaluation/eval-2026-03-24.md",
-    "generatedAt": "2026-03-24T10:00:00Z"
-  }
-}
-```
-
-## 适用场景
-
-- 流程结束时自动触发（Stop Hook）
-- 手动执行 `/autospec:evaluate`
-- 定期质量审计
-
-## 反模式清单 (DP7)
-
-1. **忽略上下文**：不考虑任务复杂度
-   - 检测：结合任务评估调整评分标准
-
-2. **建议不可执行**：建议过于笼统
-   - 检测：每个建议必须指向具体改进点
-
-3. **过度惩罚**：对所有问题都扣分
-   - 检测：区分关键问题和次要问题