@chongyan/autospec 1.0.1 → 1.0.2

package/plugins/skills/experiment-evaluator/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: experiment-evaluator
+description: "实验模式的效果评测阶段。执行评测数据集，产出评测报告，判定假设是否成立。"
+triggers:
+  - workflow: experiment
+  - stage: EVAL
+parameters:
+  maxIterations: 10
+  currentIteration: 1
+  complexityLevel: medium
+---
+
+# Experiment Evaluator - 实验评测
+
+## 概述
+
+实验模式的效果评测阶段是实验验证的关键环节。在原型实现完成后，自动触发效果评测，验证假设是否成立。
+
+## 输入
+
+- `specs/{feature}/evaluation-plan.md`: 评测方案
+- `specs/{feature}/assumptions.md`: 假设清单
+- `specs/{feature}/evaluation/dataset/`: 评测数据集
+- 原型代码
+
+## 执行流程
+
+### Step 1: 确定迭代次数上限
+
+根据实验复杂度确定最大迭代次数：
+
+| 复杂度 | 判断标准 | 最大迭代次数 |
+|--------|---------|-------------|
+| 简单 | 单模型单指标 | 3次 |
+| 中等 | 多模型或多指标 | 5次 |
+| 复杂 | 多模型多指标+数据管道 | 10次 |
+
+### Step 2: 加载评测方案
+
+读取 `specs/{feature}/evaluation-plan.md`：
+- 评测指标定义
+- 目标阈值
+- 评测方法
+- 数据集路径
+
+**评测方案格式**：
+```markdown
+# 评测方案
+
+## 评测指标
+
+| 指标名称 | 目标值 | 权重 |
+|---------|-------|------|
+| 准确率 | >= 85% | 0.4 |
+| 召回率 | >= 80% | 0.3 |
+| F1分数 | >= 82% | 0.3 |
+
+## 评测数据集
+
+- 训练集: `data/train.json`
+- 验证集: `data/valid.json`
+- 测试集: `data/test.json`
+
+## 评测方法
+
+1. 加载模型
+2. 执行推理
+3. 计算指标
+4. 生成报告
+```
+
+### Step 3: 执行评测
+
+调用评测脚本：
+
+```bash
+# 执行评测
+python evaluation/evaluator.py \
+  --model-path {model_path} \
+  --test-data {test_data} \
+  --output {output_path}
+```
+
+评测过程：
+1. 加载评测数据集
+2. 执行模型推理
+3. 计算评测指标
+4. 与目标阈值对比
+
+### Step 4: 产出评测报告
+
+写入 `specs/{feature}/evaluation-report.md`：
+
+```markdown
+# 评测报告
+
+## 评测结果
+
+| 指标名称 | 目标值 | 实际值 | 是否达标 |
+|---------|-------|-------|---------|
+| 准确率 | >= 85% | 87.2% | ✅ |
+| 召回率 | >= 80% | 78.5% | ❌ |
+| F1分数 | >= 82% | 82.8% | ✅ |
+
+## 综合评分
+
+- 达标指标: 2/3
+- 综合得分: 82.8%
+- 结论: 未完全达标
+
+## Badcase 分析
+
+### 失败案例1
+- 输入: ...
+- 预期输出: ...
+- 实际输出: ...
+- 分析: ...
+
+## 改进建议
+
+1. 增加训练数据
+2. 调整模型参数
+3. 优化特征工程
+```
+
+### Step 5: 假设判定
+
+```
+判定逻辑：
+
+if 所有指标达标:
+  return 'HYPOTHESIS_CONFIRMED'
+  → 假设成立，进入简化交付
+
+elif currentIteration < maxIterations:
+  # 分析未达标原因
+  analyze_failure_cases()
+
+  # 提出改进方向
+  suggest_improvements()
+
+  return 'HYPOTHESIS_NEEDS_ITERATION'
+  → 返回设计阶段迭代
+
+else:
+  return 'HYPOTHESIS_REJECTED'
+  → 输出失败报告，建议终止或调整方向
+```
+
+### Step 6: 迭代决策
+
+当需要迭代时：
+
+1. **分析失败原因**：
+   - 数据不足
+   - 模型选择不当
+   - 特征工程问题
+   - 超参数需要调整
+
+2. **提出改进方向**：
+   - 增加数据量
+   - 尝试其他模型
+   - 优化特征
+   - 调整超参数
+
+3. **更新假设置信度**：
+   - 降低置信度
+   - 记录迭代历史
+
+4. **返回设计阶段**：
+   - 更新设计文档
+   - 调整实现方案
+
+## 输出
+
+- `specs/{feature}/evaluation-report.md` - 评测报告
+- `specs/{feature}/assumptions.md` - 更新后的假设状态
+- 假设判定结论
+
+## 假设验证协议
+
+### 假设格式
+
+每个假设记录在 `assumptions.md`：
+
+```markdown
+## H-{id}: {假设描述}
+
+- **类型**: 技术可行性 / 用户价值 / 性能假设
+- **验证方式**: 效果评测 / A/B测试 / 用户访谈
+- **成功标准**: {可量化的指标}
+- **当前状态**: 待验证 / 验证中 / 已确认 / 已否定
+- **验证轮次**: {n}/{maxIterations}
+- **证据**: []
+```
+
+### 状态流转
+
+```
+待验证 → 验证中 → 已确认
+                  ↘ 已否定
+```
+
+### 验证循环
+
+```
+for iteration in 1..maxIterations:
+
+  # 执行评测
+  run_evaluation()
+
+  # 判定假设
+  result = judge_hypothesis()
+
+  match result:
+    case CONFIRMED:
+      假设成立，进入交付
+      break
+
+    case NEEDS_ITERATION:
+      分析失败原因
+      提出改进方案
+      更新假设置信度
+      continue
+
+    case REJECTED:
+      假设不成立
+      建议终止或调整方向
+      break
+```
+
+## 复杂度自适应机制
+
+### 复杂度评估
+
+```
+评估实验复杂度：
+
+简单：
+- 单一模型
+- 单一评测指标
+- 数据量 < 1000条
+
+中等：
+- 多个模型对比
+- 多个评测指标
+- 数据量 1000-10000条
+
+复杂：
+- 多模型多指标
+- 需要数据管道
+- 数据量 > 10000条
+- 涉及在线评测
+```
+
+### 迭代次数调整
+
+根据复杂度自动调整：
+- 简单：3次迭代上限
+- 中等：5次迭代上限
+- 复杂：10次迭代上限
+
+用户也可手动指定迭代次数上限。
+
+## 注意事项
+
+1. **评测数据集**：必须与训练数据分离，避免数据泄露
+2. **指标选择**：选择与业务目标相关的指标
+3. **阈值设定**：阈值应该有业务意义，而非随意设定
+4. **迭代成本**：每次迭代都有成本，避免无限迭代
+5. **失败处理**：实验失败是正常的，重要的是从中学习

package/plugins/skills/experiment-iteration/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: experiment-iteration
+description: "实验模式下的假设验证循环。提出假设→设计实验→收集数据→验证结论的迭代过程。"
+triggers:
+  - workflow: experiment
+parameters:
+  hypothesis: ""
+  experiments: []
+  currentPhase: design
+---
+
+# Iteration Experiment - 实验迭代执行
+
+## 概述
+
+实验模式的核心是**假设驱动**的验证循环。与瀑布模式的完整流程和敏捷模式的故事驱动不同，实验模式通过提出假设→设计实验→收集数据→验证结论的迭代过程来探索最佳解决方案。
+
+## 输入
+
+- `hypothesis`: 待验证的假设
+- `experiments`: 实验列表
+- `currentPhase`: 当前实验阶段
+
+## 执行流程
+
+### Step 1: 假设定义
+
+```
+1. 明确问题：
+   - 背景描述
+   - 当前痛点
+   - 期望效果
+
+2. 提出假设：
+   - 假设内容（可验证）
+   - 假设前提
+   - 预期结果
+
+3. 定义成功标准：
+   - 量化指标
+   - 阈值定义
+   - 验证方法
+```
+
+### Step 2: 实验设计
+
+```
+1. 设计实验方案：
+   - 实验组 vs 对照组
+   - 变量控制
+   - 数据采集方法
+
+2. 确定实验规模：
+   - 样本数量
+   - 实验时长
+   - 资源需求
+
+3. 准备实验环境：
+   - 隔离环境
+   - 数据准备
+   - 监控配置
+```
+
+### Step 3: 实验执行
+
+```
+1. 运行实验：
+   - 记录实验过程
+   - 采集实验数据
+   - 监控关键指标
+
+2. 数据收集：
+   - 定量数据
+   - 定性反馈
+   - 异常记录
+
+3. 数据清洗：
+   - 去除异常值
+   - 数据标准化
+   - 初步分析
+```
+
+### Step 4: 结果验证
+
+```
+1. 统计分析：
+   - 显著性检验
+   - 置信区间
+   - 效果量计算
+
+2. 结论判断：
+   - 假设成立 → 沉淀为最佳实践
+   - 假设不成立 → 记录经验教训
+   - 需更多数据 → 设计新实验
+
+3. 产出实验报告：
+   - 实验过程
+   - 数据分析
+   - 结论建议
+```
+
+### Step 5: 迭代优化
+
+```
+基于实验结论：
+1. 假设优化：
+   - 调整假设前提
+   - 缩小验证范围
+
+2. 实验迭代：
+   - 设计新实验
+   - 继续验证
+
+3. 知识沉淀：
+   - 记录实验结论
+   - 更新最佳实践
+   - 分享经验
+```
+
+## 实验类型
+
+| 类型 | 说明 | 适用场景 |
+|------|------|---------|
+| A/B测试 | 对比两个版本的效果 | 功能优化、UI改进 |
+| 灰度发布 | 渐进式发布验证 | 新功能上线 |
+| 特性开关 | 动态控制功能开关 | 功能灰度 |
+| 埋点验证 | 通过数据分析验证假设 | 用户行为分析 |
+| 性能基准 | 性能指标对比 | 性能优化 |
+
+## 验证标准
+
+| 指标 | 说明 | 判断标准 |
+|------|------|---------|
+| 统计显著性 | p值 < 0.05 | 假设可信 |
+| 效果量 | 变化幅度 | 业务意义 |
+| 样本量 | 足够的数据量 | 结论可靠 |
+| 可重复性 | 多次实验结果一致 | 结论稳定 |
+
+## 与其他迭代模式的区别
+
+| 模式 | 驱动方式 | 适用场景 |
+|------|---------|---------|
+| waterfall-iteration | 阶段驱动 | 需求稳定、项目明确 |
+| agile-iteration | 故事驱动 | 需求变化、增量交付 |
+| hotfix-iteration | 问题驱动 | 紧急修复、快速响应 |
+| experiment-iteration | 假设驱动 | 探索性验证、A/B测试 |
+
+## 注意事项
+
+1. **假设可验证**：假设必须是可量化、可验证的
+2. **控制变量**：实验组和对照组需要控制变量
+3. **数据质量**：确保数据采集的准确性和完整性
+4. **统计严谨**：使用正确的统计方法，避免误导性结论
+5. **快速迭代**：小步快跑，快速验证假设

package/plugins/skills/exploration-phase/SKILL.md

@@ -11,6 +11,35 @@ parameters:
 
 你正在执行探索阶段，负责与创业团队对齐并完成需求澄清。
 
+## ⚠️ 执行约束（强制）
+
+**【阻塞检查】** 在开始执行前，必须确认以下条件：
+
+```
+□ 已读取复杂度评估指南（24-assess-complexity.md）
+□ 已确定参与角色列表（根据复杂度）
+□ 已准备启动多 Agent 对抗分析
+□ 已准备使用 AskUserQuestion 进行澄清
+```
+
+**【跳过检测】** 以下行为将被检测并阻止：
+
+| 行为 | 检测方式 | 处理 |
+|------|----------|------|
+| 直接生成 requirement.md | 检查 clarifications.md 是否存在 | 阻止，返回执行 Step 3-4 |
+| 使用单个 Agent 模拟对抗 | 检查 Agent 调用记录 | 阻止，要求并行启动多 Agent |
+| 不使用 AskUserQuestion 澄清 | 检查问答记录 | 阻止，要求执行 Step 4 |
+| 跳过复杂度评估 | 检查评估记录 | 阻止，要求执行 Step 1 |
+
+**【强制流程】** 必须按顺序完成以下步骤，不可跳过：
+
+```
+Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → Step 6 → Step 7
+         ↓
+    【强制】Step 3 和 Step 4 必须完成
+    【禁止】直接跳到 Step 5 生成需求文档
+```
+
 ## 前置参数
 
 - **maxRounds**: 最大探索轮次（默认6，由复杂度决定）
@@ -21,7 +50,7 @@ parameters:
 
 ### Step 1: 复杂度评估
 
-**【强制】** 读取 `${KNOWLEDGE}/guides/support/complexity-assessor.md`，执行复杂度评估：
+**【强制】** 读取 `${KNOWLEDGE}/03-guides/24-assess-complexity.md`，执行复杂度评估：
 
 - 简单任务（score <= 5）：2-3轮
 - 中等任务（score 6-8）：3-4轮
@@ -37,22 +66,52 @@ parameters:
 - 只有当 clarifications.md 中有完整的「对抗分析结果」+「多轮问答记录」时，才算完成
 - 如不存在或不完整 → **必须**继续执行 Step 3 和 Step 4
 
-### Step 3: 多Agent对抗分析
+### Step 3: 团队智能体对抗分析
+
+**【强制】【不可跳过】** 必须根据复杂度评估结果，启动团队智能体并行对抗分析：
+
+**【禁止】** 以下行为将被阻止：
+- 使用单个 Agent 模拟团队对抗
+- 自己模拟分析而不调用 Agent 工具
+- 跳过对抗分析直接进入需求分析
+
+#### 复杂度评估（继承 Step 1 结果）
 
-**【强制】【不可跳过】** 必须启动 2-3 个独立 Agent 并行分析，即使需求文档很详细：
+- **简单任务（score <= 5）**：CEO + 产品负责人
+- **中等任务（score 6-8）**：CEO + 产品负责人 + 技术负责人
+- **复杂任务（score >= 9）**：CEO + 产品负责人 + 技术负责人 + 相关工程师（如触发条件）
 
-1. **Agent A - 乐观视角**：支持这个需求的理由、预期价值
-2. **Agent B - 质疑视角**：潜在问题、风险、伪需求可能性
-3. **Agent C（可选）- 技术视角**：技术可行性、实现难点
+#### 团队对抗执行
 
-**【强制】** 使用 Agent 工具启动独立 Agent，不要自己模拟分析。
+**【强制】** 读取 `${KNOWLEDGE}/03-guides/01-team-orchestrator.md`，并行启动团队智能体：
 
-汇总对抗结果，形成「待确认问题清单」，记录到 clarifications.md
+1. **CEO Agent**：战略一致性、商业价值、风险把控
+2. **产品负责人 Agent**：用户价值、产品方向、MVP范围
+3. **技术负责人 Agent**：技术可行性、技术风险（如中等及以上）
+4. **相关工程师 Agent**：实现可行性（如复杂任务且有特定子系统）
+
+**【强制】** 使用 Agent 工具启动独立 Agent（信息隔离，做审分离），不要自己模拟分析。
+
+**【执行验证】** 完成后必须记录：
+```
+对抗分析记录：
+- 参与角色：[CEO, 产品负责人, 技术负责人, ...]
+- 各角色意见汇总：...
+- 分歧点：...
+- 待确认问题清单：...
+```
+
+汇总团队对抗结果，形成「待确认问题清单」，记录到 clarifications.md
 
 ### Step 4: 多轮澄清（动态轮次）
 
 **【强制交互】【不可跳过】** 必须使用 AskUserQuestion 工具与用户进行交互澄清。
 
+**【禁止】** 以下行为将被阻止：
+- 不使用 AskUserQuestion 工具进行澄清
+- 直接假设用户意图而不提问
+- 跳过澄清环节直接生成需求文档
+
 **【重要】** 即使需求文档很详细，也必须执行至少一轮澄清！
 
 根据 Step 1 确定的轮次上限，执行以下循环：
@@ -95,9 +154,33 @@ parameters:
 - 第5轮：风险识别（如需要）
 - 第6轮：验收标准（如需要）
 
+### Step 4.5: 阶段完成验证（阻塞检查）
+
+**【强制】【不可跳过】** 在生成 requirement.md 之前，必须验证以下条件：
+
+```
+验证清单：
+□ clarifications.md 文件存在
+□ clarifications.md 包含「对抗分析结果」章节
+□ clarifications.md 包含「多轮问答记录」章节
+□ 至少执行了一轮 AskUserQuestion 澄清
+□ 复杂度评估结果已记录
+```
+
+**验证失败处理**：
+
+| 缺失项 | 处理方式 |
+|--------|----------|
+| clarifications.md 不存在 | 返回 Step 3 执行对抗分析 |
+| 缺少对抗分析结果 | 返回 Step 3 补充对抗分析 |
+| 缺少问答记录 | 返回 Step 4 执行澄清 |
+| 未执行澄清 | 返回 Step 4 执行澄清 |
+
+**【禁止】** 验证未通过时，禁止进入 Step 5 生成需求文档。
+
 ### Step 5: 需求分析
 
-**【强制】** 读取 `${KNOWLEDGE}/guides/stages/requirement-analyzer.md`，生成结构化需求文档：
+**【强制】** 读取 `${KNOWLEDGE}/03-guides/02-analyze-requirement.md`，生成结构化需求文档：
 
 1. 将3轮澄清结果融入需求文档
 2. 每个决策标注来源：用户确认/自动决策/待审阅
@@ -115,7 +198,7 @@ parameters:
 
 ```
 prompt: 请审查以下需求文档。
-  1. 先读取审查标准: ${KNOWLEDGE}/guides/stages/requirement-reviewer.md
+  1. 先读取审查标准：${KNOWLEDGE}/03-guides/09-review-requirement.md
   2. 被审查文档: .autospec/specs/{feature}/requirement.md
   注意：你是独立审查者，只看产出物和标准
 ```

package/plugins/skills/field-evolve-analyzer/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: field-evolve-analyzer
+description: "分析实战项目问题，识别根因和模式"
+type: analyzer
+---
+
+# Field-Evolve Analyzer
+
+## 定位
+
+分析实战项目问题，识别根因和共性模式，为技能蒸馏提供输入。
+
+## 输入
+
+- 扫描结果（来自 scanner）
+- 项目上下文
+
+## 输出
+
+- 问题分析报告
+- 根因分析
+- 模式识别
+
+## 执行步骤
+
+### Step 1: 问题分析
+
+```
+分析问题：
+1. 分类问题类型
+2. 评估影响范围
+3. 确定严重程度
+```
+
+### Step 2: 根因分析
+
+```
+分析根因：
+1. 定位问题位置
+2. 分析问题原因
+3. 评估影响范围
+```
+
+### Step 3: 模式识别
+
+```
+识别模式：
+1. 从多个项目中识别共性问题
+2. 提取可复用的解决方案
+3. 生成模式报告
+```
+
+## 使用示例
+
+```
+# 执行分析
+读取 plugins/skills/field-evolve-analyzer/SKILL.md 并执行
+```
+
+## 与其他技能的区别
+
+| 技能 | 侧重点 |
+|------|--------|
+| project-evolve-analyzer | 单个项目问题分析 |
+| **field-evolve-analyzer** | 多项目模式分析，提炼共性 |

package/plugins/skills/field-evolve-distiller/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: field-evolve-distiller
+description: "从实战项目中提炼技能，更新框架能力"
+type: distiller
+---
+
+# Field-Evolve Distiller
+
+## 定位
+
+从实战项目中提炼技能，将项目级经验提升为框架级能力。
+
+## 输入
+
+- 项目执行记录
+- 问题分析结果
+- 修复方案
+
+## 输出
+
+- 新技能定义
+- 更新的技能模板
+- 框架改进建议
+
+## 执行步骤
+
+### Step 1: 经验提取
+
+```
+提取经验：
+1. 分析项目执行过程
+2. 识别可复用的解决方案
+3. 提取通用模式
+```
+
+### Step 2: 技能提炼
+
+```
+提炼技能：
+1. 将解决方案封装为技能
+2. 定义技能输入输出
+3. 编写技能文档
+```
+
+### Step 3: 框架更新
+
+```
+更新框架：
+1. 生成技能定义
+2. 更新技能模板
+3. 提出框架改进建议
+```
+
+## 使用示例
+
+```
+# 执行蒸馏
+读取 plugins/skills/field-evolve-distiller/SKILL.md 并执行
+```
+
+## 与其他技能的区别
+
+| 技能 | 侧重点 |
+|------|--------|
+| self-evolve-generalizer | 框架级经验泛化 |
+| **field-evolve-distiller** | 项目级经验提炼为框架级技能 |