@chongyan/autospec 1.0.1 → 1.0.3

package/knowledge/guides/support/practice-logger.md

@@ -1,359 +0,0 @@
-# 进化实践记录器
-
-## 功能
-
-在流程完成或会话结束时，检查并提醒记录实践日志。合并了原 evolution-trigger 和 practice-log-reminder 的功能。
-
-**增强功能**：
-- 连接评测数据，自动识别进化触发信号
-- 基于质量分数自动决定是否需要记录
-- 集成错误模式检测
-
-## 触发条件
-
-1. **流程完成时**
-   - state.json 中 stage === 6 或 completedAt 存在
-   - 有活跃的 pipeline 状态
-
-2. **会话结束时**
-   - Stop hook 触发
-   - 有未完成的 pipeline
-
-3. **评测触发时**（新增）
-   - 质量分数 < 70
-   - 同类错误出现 >= 3 次
-   - 新模式识别
-
-## 输入
-
-```json
-{
-  "state": {
-    "currentStage": "06-deliver",
-    "completedAt": "2024-01-15T10:30:00Z",
-    "pipeline": "feature-xyz"
-  },
-  "practiceLogExists": false,
-  "evolutionLogExists": false,
-  "evaluationData": {
-    "qualityScore": 65,
-    "errorPatterns": [...],
-    "improvementAreas": [...]
-  }
-}
-```
-
-## 输出
-
-```json
-{
-  "needsReminder": true,
-  "reminderType": "practice-log | evolution-scan | both",
-  "message": "提醒消息",
-  "template": "practice-log 模板内容",
-  "evolutionTriggers": [
-    {
-      "type": "quality_low",
-      "evidence": "质量分数 65 < 70",
-      "suggestedAction": "触发 methodology 审查"
-    }
-  ]
-}
-```
-
-## 执行步骤
-
-1. **检查流程状态**
-   - 读取 state.json
-   - 判断是否已完成
-
-2. **检查日志文件**
-   - 检查 practice-log 是否存在
-   - 检查 evolution-log 是否存在
-
-3. **读取评测数据**（新增）
-   - 读取 metrics.json 中的 qualityScore
-   - 读取 errorPatterns
-   - 读取 improvementAreas
-
-4. **检测进化触发**（新增）
-   - 检查质量分数阈值
-   - 检查错误模式重复次数
-   - 检查新模式识别
-
-5. **生成提醒**
-   - 如果流程完成但没有 practice-log，提醒记录
-   - 如果有新的 practice-log，提醒执行进化扫描
-   - 如果有进化触发信号，自动创建 practice-log 草稿
-
-6. **提供模板**
-   - 生成 practice-log 模板
-   - 包含关键信息预填
-   - 包含评测数据摘要
-
-## 评测数据输入
-
-从 `.autospec/logs/evaluation/` 读取评测报告，提取：
-
-### 质量分数触发
-
-| 条件 | 触发动作 |
-|-----|---------|
-| 质量分数 < 70 | 触发 methodology 审查 |
-| 过程指标 < 60 | 触发流程优化 |
-| 结果指标 < 60 | 触发产出物模板优化 |
-| 路径指标 < 60 | 触发 SDD 引导优化 |
-
-### 错误模式触发
-
-| 条件 | 触发动作 |
-|-----|---------|
-| 同类错误 >= 3 次 | 自动创建 practice-log |
-| 新错误类型 | 标记需要分析 |
-| 恢复率 < 60% | 触发异常处理优化 |
-
-### 新模式识别
-
-| 条件 | 触发动作 |
-|-----|---------|
-| 新解决方案模式 | 触发 skill 提案 |
-| 新最佳实践 | 触发 knowledge 更新 |
-| 新反模式 | 触发 DP 更新 |
-
-## 触发规则
-
-### 规则 1: 同类错误 3 次
-
-```javascript
-// 检测同类错误重复
-if (errorPattern.count >= 3) {
-  autoCreatePracticeLog({
-    type: 'repeated_error',
-    errorType: errorPattern.type,
-    count: errorPattern.count,
-    suggestion: '建议创建专门的 skill 处理此类错误'
-  });
-}
-```
-
-### 规则 2: 质量分数 < 70
-
-```javascript
-// 检测质量分数
-if (qualityScore.overall < 70) {
-  triggerEvolution({
-    type: 'quality_review',
-    evidence: `质量分数 ${qualityScore.overall} < 70`,
-    action: '触发 methodology 审查'
-  });
-}
-```
-
-### 规则 3: 新模式识别
-
-```javascript
-// 检测新模式
-if (detectedNewPattern) {
-  suggestSkillCreation({
-    type: 'new_pattern',
-    pattern: detectedPattern,
-    evidence: patternEvidence
-  });
-}
-```
-
-## 提醒消息模板
-
-### 流程完成提醒
-
-```
-[AutoSpec 进化提醒] 📝
-
-流程已完成，请记录实践日志：
-
-1. 创建文件：.autospec/evolution/practice-log/{date}-{topic}.md
-
-2. 记录内容：
-   - 遇到的问题和解决方案
-   - 发现的新模式或最佳实践
-   - 可以改进的地方
-
-3. 执行进化扫描：
-   /evolve
-
-模板已为您准备好，是否需要自动创建？
-```
-
-### 评测触发提醒（新增）
-
-```
-[AutoSpec 进化触发] ⚡
-
-检测到以下进化信号：
-
-1. 质量分数: {score}/100 (低于阈值 70)
-   - 建议审查: methodology
-
-2. 重复错误: {errorType} 出现 {count} 次
-   - 建议: 创建专门的 skill
-
-3. 新模式识别: {patternName}
-   - 建议: 提取为可复用 skill
-
-详细评测报告: /evaluate
-是否自动创建 practice-log 草稿？
-```
-
-### 会话结束提醒
-
-```
-[AutoSpec 实践记录] 📋
-
-检测到有活跃的 pipeline，建议：
-
-1. 如果流程未完成，记录当前进度
-2. 如果遇到问题，记录到 practice-log
-3. 下次继续时可以快速恢复
-
-是否需要创建进度记录？
-```
-
-## practice-log 模板（增强版）
-
-```markdown
-# 实践日志
-
-日期：{date}
-主题：{topic}
-阶段：{stage}
-Trace ID: {traceId}
-
-## 问题描述
-
-<!-- 描述遇到的问题 -->
-
-## 解决方案
-
-<!-- 描述解决方案 -->
-
-## 经验总结
-
-<!-- 描述可以复用的经验 -->
-
-## 评测数据（自动填充）
-
-- 质量分数: {qualityScore}
-- 错误模式: {errorPatterns}
-- 改进领域: {improvementAreas}
-
-## 进化建议（自动生成）
-
-<!-- 基于评测数据自动生成的建议 -->
-
-## 相关文件
-
-<!-- 列出相关文件 -->
-
-## 标签
-
-<!-- 添加标签，如：bugfix, optimization, pattern -->
-```
-
-## 规则
-
-1. **不重复提醒**
-   - 如果已有 practice-log，不重复提醒
-   - 同一会话只提醒一次
-
-2. **渐进式提醒**
-   - 第一次：友好提示
-   - 第三次同类问题：强烈建议
-   - 第五次：必须记录
-
-3. **智能判断**
-   - 简单任务可能不需要记录
-   - 复杂问题自动标记需要记录
-
-4. **评测驱动**（新增）
-   - 质量分数低时自动触发
-   - 错误模式重复时自动触发
-   - 新模式识别时建议触发
-
-## 配置
-
-```yaml
-# .autospec/config.json
-{
-  "evolution": {
-    "reminderEnabled": true,
-    "reminderThreshold": 3,
-    "autoCreateTemplate": false,
-    "qualityThreshold": 70,
-    "errorPatternThreshold": 3
-  }
-}
-```
-
-## 与评测系统的集成
-
-### 数据流
-
-```
-评测报告 → evo-practice-logger → practice-log → 进化机制
-     │
-     ├── 质量分数 < 70 → 触发 methodology 审查
-     ├── 错误重复 >= 3 → 自动创建 practice-log
-     └── 新模式识别 → 建议 skill 创建
-```
-
-### 自动化触发
-
-当评测报告生成后，自动检查进化触发条件：
-
-1. 读取评测报告
-2. 检查触发条件
-3. 生成进化建议
-4. 自动创建 practice-log 草稿（如需要）
-
-## 示例
-
-### 输入
-
-```json
-{
-  "state": {
-    "currentStage": "06-deliver",
-    "completedAt": "2024-01-15T10:30:00Z"
-  },
-  "practiceLogExists": false,
-  "evaluationData": {
-    "qualityScore": 65,
-    "errorPatterns": [
-      { "type": "test_fail", "count": 3 }
-    ]
-  }
-}
-```
-
-### 输出
-
-```json
-{
-  "needsReminder": true,
-  "reminderType": "both",
-  "message": "检测到进化触发信号...",
-  "template": "# 实践日志\n\n日期：2024-01-15\n...",
-  "evolutionTriggers": [
-    {
-      "type": "quality_low",
-      "evidence": "质量分数 65 < 70",
-      "suggestedAction": "触发 methodology 审查"
-    },
-    {
-      "type": "repeated_error",
-      "evidence": "test_fail 出现 3 次",
-      "suggestedAction": "建议创建专门的 skill"
-    }
-  ]
-}
-```

package/knowledge/guides/support/scope-inference.md

@@ -1,174 +0,0 @@
----
-name: scope-inferencer
-description: 当需要智能推断需求涉及的项目范围时触发。基于项目结构和代码上下文，推断需求涉及的模块和技术栈。
-type: meta
----
-
-## 定位
-
-元技能。基于项目结构（确定性）和代码上下文（语义），智能推断需求涉及的模块和技术栈。
-
-## 输入
-
-- 必须输入：需求描述、项目结构分析结果
-- 可选输入：代码上下文（Grep结果）
-
-## 输出
-
-```json
-{
-  "modules": [
-    {
-      "name": "backend",
-      "path": "backend",
-      "relevance": "high",
-      "reason": "需求提到API接口，匹配到backend模块的FastAPI服务"
-    },
-    {
-      "name": "ai",
-      "path": "ai",
-      "relevance": "high",
-      "reason": "需求提到推荐功能，匹配到ai模块的推荐模型"
-    }
-  ],
-  "techStacks": [
-    {
-      "name": "FastAPI",
-      "relevance": "high"
-    },
-    {
-      "name": "PyTorch",
-      "relevance": "high"
-    }
-  ],
-  "dataAIComponents": {
-    "detected": true,
-    "needsEvaluation": true,
-    "components": ["推荐系统"]
-  },
-  "confidence": "high",
-  "reasoning": "整体推理过程说明"
-}
-```
-
-## 执行步骤
-
-### Step 1: 提取关键词（确定性）
-
-从需求中提取技术关键词：
-
-```
-技术关键词类型：
-- 系统关键词：后端、前端、移动端、API、界面、页面
-- 功能关键词：推荐、搜索、聊天、支付、登录
-- AI关键词：模型、智能、Agent、RAG、LLM
-- 数据关键词：数据、ETL、报表、统计
-```
-
-### Step 2: 匹配模块（确定性 + 语义）
-
-基于项目结构匹配相关模块：
-
-```
-确定性匹配：
-- 需求提到"后端API" → 匹配 type=backend 的模块
-- 需求提到"前端页面" → 匹配 type=frontend 的模块
-- 需求提到"移动端" → 匹配 type=mobile 的模块
-
-语义匹配（需要模型）：
-- 需求提到"推荐" → Grep搜索 "recommend" → 模型判断相关性
-- 需求提到"搜索" → Grep搜索 "search" → 模型判断相关性
-```
-
-### Step 3: 获取代码上下文（Grep，高效）
-
-对于不确定的匹配，使用 Grep 获取上下文：
-
-```bash
-# 搜索关键词相关文件
-grep -r -l -i "keyword" --include="*.{js,ts,py,java,go}" . | head -20
-
-# 获取匹配行附近内容
-grep -A 3 -B 3 -i "keyword" "file" | head -20
-```
-
-**效率控制**：
-- 最多搜索 3 个关键词
-- 每个关键词最多返回 5 个文件
-- 每个文件最多读取 20 行上下文
-
-### Step 4: 语义分析（模型）
-
-基于有限上下文进行语义判断：
-
-```
-模型输入：
-{
-  "requirement": "需求描述",
-  "projectModules": ["backend (FastAPI, backend)", "ai (PyTorch, ai)"],
-  "codeContexts": "[backend/api.py]\ndef recommend_items(user_id): ...",
-  "task": "判断需求涉及哪些模块，输出JSON格式"
-}
-```
-
-### Step 5: 输出结果
-
-汇总确定性匹配和语义匹配结果，输出带置信度的范围推断。
-
-## 置信度判断
-
-| 置信度 | 条件 |
-|--------|------|
-| **high** | 确定性匹配 + 语义匹配一致 |
-| **medium** | 只有确定性匹配 或 语义匹配置信度高 |
-| **low** | 只有语义匹配置信度中等 或 无匹配 |
-
-## 调用时机
-
-- 需求分析阶段开始时
-- 项目结构检测完成后
-- 用户输入需求后
-
-## 示例
-
-**输入**：
-```
-需求：开发用户收藏夹功能，用户可以收藏商品，在收藏夹页面查看和管理
-
-项目结构：
-- backend (FastAPI, backend)
-- frontend (React, frontend)
-- mobile (React Native, mobile)
-```
-
-**输出**：
-```json
-{
-  "modules": [
-    {
-      "name": "backend",
-      "path": "backend",
-      "relevance": "high",
-      "reason": "收藏夹需要后端API支持，匹配到backend模块"
-    },
-    {
-      "name": "frontend",
-      "path": "frontend",
-      "relevance": "high",
-      "reason": "需求提到收藏夹页面，匹配到frontend模块"
-    },
-    {
-      "name": "mobile",
-      "path": "mobile",
-      "relevance": "medium",
-      "reason": "收藏功能通常也需要移动端支持，但需求未明确提及"
-    }
-  ],
-  "techStacks": [
-    {"name": "FastAPI", "relevance": "high"},
-    {"name": "React", "relevance": "high"}
-  ],
-  "confidence": "high",
-  "reasoning": "需求明确提到收藏夹页面，后端API和前端页面是确定需要的。移动端未明确提及但通常需要，置信度中等。"
-}
-```

package/knowledge/guides/support/skill-distiller.md

@@ -1,91 +0,0 @@
----
-name: skill-distiller
-description: 当全流程完成或practice-log积累到一定量、需要从执行轨迹或业务知识中提炼新的可执行skill时触发
-type: produce
----
-
-## 定位
-从实践中识别和提炼可执行的新skill，是框架持续扩展能力的引擎。分三个场景：流程蒸馏（向内看）、业务蒸馏（向外看）、测试知识蒸馏（从测试执行中学习）。
-
-## 输入
-- 必须输入：practice-log中状态为"待处理"的条目
-- 场景A可选：流程执行轨迹、人工介入记录
-- 场景B可选：业务项目中的知识素材（成熟提示词、业务规则、领域术语）
-- 场景C可选：测试执行记录、测试代码、测试失败模式
-
-## 输出
-- 新的skill文件（符合 skills/_template.md 格式，含CSO description + 反模式清单）
-- 测试知识文件（Markdown 格式，存放于 `environment/integration/testing/`）
-- 蒸馏报告（从什么素材提炼、归入哪个目录、与现有skills/知识的关系）
-- **证据清单**（支撑蒸馏决策的practice-log引用）
-
-## 执行步骤
-
-### 场景A：流程蒸馏（向内看）
-
-1. **监控**：扫描流程执行中的操作轨迹和人工介入点
-2. **识别**：寻找以下信号
-   - 某个操作模式反复出现（3次以上）
-   - 某处频繁需要人工介入（自动化缺口）
-   - 两个现有skills有重复逻辑（可提取更基础的skill）
-   - 质量关卡的某类判断逻辑逐渐成熟（可独立为专项skill）
-3. **抽象**：将具体操作抽象为通用skill定义
-   - 明确输入/输出（含关键假设和证据）
-   - 确定属于哪个阶段
-   - 厘清与现有skills的关系（替代/补充/组合）
-   - **编写CSO格式的description**
-   - **编写反模式清单**
-4. **验证**：调用skill-validator检查
-5. **归档**：归入 skills/stages/ 或 skills/support/
-
-### 场景B：业务蒸馏（向外看）
-
-1. **收集**：从项目中归集业务知识素材
-2. **分层**：判断知识的复用层级（场景级/行业级/通用级）
-3. **封装**：将业务知识封装为可执行skill
-   - 内嵌领域知识（不依赖外部记忆）
-   - **编写CSO格式的description**
-   - **编写反模式清单**
-4. **验证**：用真实业务案例验证效果，调用skill-validator检查
-5. **归档**：归入 skills/domain/
-
-### 场景C：测试知识蒸馏（从测试执行中学习）
-
-1. **监控**：扫描测试执行记录和测试代码
-2. **识别**：寻找以下信号
-   - 新的测试框架或工具使用模式（出现3次以上）
-   - 更高效的 Mock 策略或测试数据准备方法
-   - 测试失败模式重复出现（同类失败3次以上）
-   - 测试代码风格趋于稳定（可提炼为模板）
-3. **抽象**：将测试模式抽象为测试知识
-   - 明确适用场景和技术栈
-   - 提炼测试策略（testcontainer、mock 等）
-   - 记录注意事项和反模式
-4. **验证**：用实际测试案例验证效果
-5. **归档**：归入 `environment/integration/testing/` 目录
-
-**测试知识蒸馏示例**：
-- 发现项目中多次使用 Testcontainer 启动 MySQL → 提炼为测试知识 `mysql-testing.md`
-- 发现某类 Mock 策略导致测试不稳定 → 补充到反模式清单
-- 发现测试数据准备有通用模式 → 提炼为测试工具函数
-
-### 蒸馏后处理
-- 更新practice-log对应条目状态为"已处理"
-- 如果某角色skill在3+角色中出现 → 提议升级为通用skill
-
-## 反模式清单（DP7）
-1. **过早蒸馏**：模式出现不到3次就急于提炼。检测：必须有3+实例支撑
-2. **过度泛化**：把项目特有的模式强行泛化。检测：判断复用层级，不可泛化的留在practice-log
-3. **不验证就归档**：跳过skill-validator直接归档。检测：验证是必选步骤
-4. **忽略现有skills**：不检查是否已有类似skill。检测：蒸馏前搜索现有skills
-5. **遗漏反模式**：新skill没有反模式清单。检测：反模式是模板必选section
-
-## 适用场景与边界
-- 适用：全流程完成后的自动扫描、practice-log积累到一定量时、测试执行积累到一定量时
-- 不适用：skill已存在只需升级（用skill-evolver）、提取的是方法论而非可执行skill（用methodology-extractor）
-- 测试知识蒸馏：测试模式出现3次以上、测试失败模式重复出现
-
-## 示例
-**场景A示例**：跑了5次需求分析后发现"需求冲突检测"是独立能力 → 蒸馏为 `skills/stages/req-conflict-detector.md`
-**场景B示例**：商机项目拓客提示词经5轮调优趋于稳定 → 蒸馏为 `skills/domain/b2b-lead-discovery.md`
-**场景C示例**：项目中多次使用 Testcontainer 启动 MySQL 测试 → 提炼为 `environment/integration/testing/mysql-testing.md`

package/knowledge/guides/support/skill-updater.md

@@ -1,45 +0,0 @@
----
-name: skill-evolver
-description: 当skill执行效果持续不达标或同类问题出现3次以上、需要迭代升级已有skill时触发
-type: produce
----
-
-## 定位
-让skills持续进化而非一次性产出。基于执行效果和反馈，系统化地升级已有skill。
-
-## 输入
-- 必须输入：待升级的skill文件、反馈数据（审类skill打回记录 / practice-log条目 / 人工反馈 / methodology更新）
-- 可选输入：evaluation/benchmarks中的相关案例
-
-## 输出
-- 升级后的skill文件
-- 变更说明（改了什么、为什么、预期效果）
-- **证据清单**（支撑升级决策的反馈数据引用）
-
-## 执行步骤
-1. 收集该skill相关的所有反馈数据
-   - 预期产出：反馈汇总表
-   - 失败处理：反馈不足则标记，不盲目修改
-2. 分析问题模式：是skill的步骤不够具体？评判标准不够准确？适用场景描述有误？反模式不够全面？
-3. 生成修改建议（明确改哪个section、怎么改、预期效果）
-4. 执行修改
-5. 用skill-validator验证修改后的skill
-6. 如有evaluation/benchmarks中的相关案例，用案例对比修改前后效果
-7. **整理证据清单**（哪些反馈支撑了哪些修改）
-
-## 反模式清单（DP7）
-1. **盲目修改**：没有充分反馈就修改skill。检测：必须有至少3条反馈数据支撑
-2. **过度泛化**：把特定项目的问题泛化为通用修改。检测：修改必须回溯到问题是否普遍
-3. **破坏已有能力**：修改后导致原本能处理的场景失效。检测：用基准案例验证前后效果
-4. **跳过验证**：修改后不用skill-validator检查。检测：验证是必选步骤
-
-## 适用场景与边界
-- 适用：skill执行效果不达标、practice-log中同类问题出现3次以上、methodology更新导致skill需同步
-- 不适用：skill本身没问题但使用者没按skill执行；需要全新skill而非升级（用skill-distiller）
-
-## 示例
-**触发**：code-reviewer skill连续3次在"安全审查"维度漏判SQL注入问题
-**分析**：评判标准中安全检查项不够具体，只写了"无安全漏洞"，没有列举具体检查类型
-**修改**：在评判标准中展开为具体项（SQL注入、XSS、CSRF、越权访问...），在评审步骤中增加安全审查子步骤
-**验证**：用已知含SQL注入的代码案例重新审查，确认能正确识别
-**证据**：practice-log #12, #15, #18 均记录了SQL注入漏判