@chongyan/autospec 1.0.2 → 1.0.3

package/plugins/commands/project-evolve.md

@@ -1,920 +0,0 @@
----
-description: "AI Native 项目自我进化：智能感知、自动评测、自适应修复，支持单系统/多系统，评测即记忆，记忆即进化"
----
-
-# AutoSpec Project-Evolve — 项目自我进化
-
-## 定位
-
-**AI Native 智能进化系统** —— 不是静态规则检查，而是活的、自我学习的、团队共享的智能进化体。
-
-```
-评测即记忆，记忆即进化
-```
-
-## 三层进化体系
-
-| 层级 | 命令 | 目标 | 范围 |
-|------|------|------|------|
-| **Self-Evolve** | `/self-evolve` | 框架自我进化 | AutoSpec 框架自身 |
-| **Field-Evolve** | `/autospec:field-evolve` | 领域进化 | 框架从实战中学习 |
-| **Project-Evolve** | `/autospec:project-evolve` | 项目自我进化 | 实战项目自我优化 |
-
-## 用户输入
-
-```
-/autospec:project-evolve
-```
-
----
-
-## 前置处理
-
-【前置】读取流程协议：
-> **【重要】执行本 command 前必须先读取流程协议**
-> 1. 读取 `knowledge/03-guides/00-pipeline-protocol.md` 中的「流程能力」章节
-> 2. 执行以下步骤：
->    - 解析命令与参数
->    - 加载必要文件
-> 3. 完成后继续执行本命令的具体逻辑
->
-> **【注意】日志追踪已启用**
-> - 执行日志会自动记录到 `.autospec/logs/execution-{date}.json`
-> - 关键步骤（skill 加载、agent 调用、产物生成、阶段完成）都会被追踪
-
----
-
-## 执行指令
-
-**【技能组合】** 项目进化由以下技能协作完成：
-- `project-evolve-scanner` - 扫描项目特征
-- `project-evolve-analyzer` - 分析改进机会
-- `project-evolve-fixer` - 执行自动修复
-- `project-evolve-verifier` - 验证修复效果
-- `project-evolve-reviewer` - 审查改进方案
-- `project-evolve-learner` - 学习团队偏好
-- `project-evolve-generator` - 生成 benchmark
-
-### Step 1: 交互式选择模式
-
-**运行时让用户选择执行模式：**
-
-```
-请选择执行模式：
-
-  1. quick    - 快速扫描：代码规范检查 + 简单修复
-  2. deep     - 深度进化：全维度分析 + 自动修复
-  3. full     - 完整循环：deep + 持续优化 + 效果验证
-  4. report   - 仅报告：分析并生成建议报告
-  5. review   - 效果回顾：回顾进化效果，持续改进
-  6. generate - 生成 Benchmark：基于项目自动生成
-  7. learn    - 学习模式：观察人工操作，学习团队偏好
-
-请输入选项编号（1-7）：
-```
-
-**模式说明**：
-- **quick**: 快速扫描 - 代码规范检查 + 简单修复（融合 init-memory + cruise）
-- **deep**: 深度进化 - 全维度分析 + 自动修复（融合 focus）
-- **full**: 完整循环 - deep + 持续优化 + 效果验证
-- **report**: 仅报告 - 分析并生成建议报告（融合 advise）
-- **review**: 效果回顾 - 回顾进化效果，持续改进
-- **generate**: 生成 Benchmark - 基于项目自动生成
-- **learn**: 学习模式 - 观察人工操作，学习团队偏好（融合 chat）
-
----
-
-### Mode: quick（快速扫描）
-
-**目标**: 零配置启动，自动发现项目特征和评测点
-
-#### Step 1: 项目扫描
-
-```
-1. 检测技术栈
-   - package.json → Node.js/React/Vue
-   - pom.xml/build.gradle → Java/Spring
-   - go.mod → Go
-   - requirements.txt/pyproject.toml → Python
-
-2. 检测项目结构
-   - 单系统 vs 多系统
-   - 源码目录结构
-   - 测试框架
-   - 构建工具
-
-3. 检测现有配置
-   - lint 配置
-   - 测试配置
-   - CI/CD 配置
-```
-
-#### Step 2: 智能发现评测点
-
-```
-基于项目特征，自动生成评测规则：
-
-示例 - React项目：
-- 组件必须有 displayName
-- Props 必须有类型定义
-- Hooks 必须有依赖数组
-- 不能有 console.log
-
-示例 - Java项目：
-- 类必须有包声明
-- 公共方法必须有文档注释
-- 异常必须正确处理
-- 资源必须正确关闭
-
-示例 - 多系统项目：
-- 接口契约一致性
-- 共享组件抽离机会
-- 子系统依赖循环
-- 构建顺序优化
-```
-
-#### Step 3: 创建记忆结构
-
-```
-创建 .autospec/autospec:memory/ 目录结构：
-├── index.yaml                    # 记忆索引
-├── discovered/                   # 自动发现的评测
-│   ├── code-patterns.yaml
-│   ├── quality-gates.yaml
-│   └── multi-system-checks.yaml
-├── patterns/                     # 验证后的模式
-├── preferences/                  # 团队偏好
-└── evolution/                    # 进化日志
-
-生成初始记忆文件，标记状态为 "learning"
-```
-
-#### Step 4: 输出初始化报告
-
-```markdown
-## Project-Evolve 初始化报告
-
-### 项目特征
-- 技术栈: React + TypeScript + Jest
-- 项目类型: 单系统
-- 代码规模: 约 150 个文件
-- 测试框架: Jest + React Testing Library
-
-### 自动发现评测点 (12个)
-
-🔴 代码质量 (5个)
-- React组件规范
-- TypeScript类型完整性
-- 未使用变量检测
-- 复杂函数检测
-- 重复代码检测
-
-🟠 测试体系 (4个)
-- 组件测试覆盖率
-- 边界条件测试
-- 异步测试规范
-- Mock数据管理
-
-🟡 工程配置 (3个)
-- 构建配置优化
-- 依赖版本管理
-- CI/CD流水线
-
-### 下一步建议
-运行 `/autospec:project-evolve --cruise` 开始智能巡航
-```
-
----
-
-### Mode: --cruise（智能巡航）
-
-**目标**: 全自动持续进化，适合 CI 集成
-
-#### Step 1: 加载记忆
-
-```
-1. 读取 .autospec/autospec:memory/index.yaml
-2. 加载所有 validated 状态的评测规则
-3. 加载团队偏好
-```
-
-#### Step 2: 执行评测
-
-```
-1. 代码扫描
-   - 复杂度分析
-   - 重复代码检测
-   - 死代码识别
-   - 测试缺口分析
-
-2. 多系统检测（如适用）
-   - 接口契约检查
-   - 共享逻辑识别
-   - 依赖循环检测
-
-3. 运行时信号（如有）
-   - 错误日志分析
-   - 性能指标检查
-```
-
-#### Step 3: 智能决策
-
-```
-1. 关联分析
-   - 将检测到的问题关联到历史模式
-   - 分析影响范围和紧急程度
-
-2. 优先级排序
-   - 高影响 + 低成本 → 立即处理
-   - 高影响 + 高成本 → 建议确认
-   - 低影响 → 观察
-
-3. 方案生成
-   - 自动生成修复方案
-   - 预测修复效果
-```
-
-#### Step 4: 自动执行
-
-```
-L1 自动修复（无需确认）：
-- 代码格式化
-- 未使用导入清理
-- 简单命名规范化
-- 依赖安全升级
-
-L2+ 建议（需确认）：
-- 生成改进建议报告
-- 等待人工确认或定时自动执行
-```
-
-#### Step 5: 效果记录
-
-```
-1. 记录执行结果到 episodes/
-2. 更新记忆统计信息
-3. 生成巡航报告
-```
-
----
-
-### Mode: --deep（深度进化）
-
-**目标**: 全维度深度分析和改进
-
-#### Step 1: 全维度扫描
-
-```
-六层全面扫描：
-
-🔴 代码质量层
-- 代码规范检查
-- 类型安全分析
-- 重复代码检测
-- 死代码识别
-- 复杂度分析
-
-🟠 测试体系层
-- 覆盖率分析
-- 测试缺口识别
-- 边界测试检查
-- Flaky test 检测
-- 契约测试验证（多系统）
-
-🟡 配置工程层
-- 构建配置优化
-- 依赖健康检查
-- CI/CD 优化
-- 环境一致性
-
-🟢 文档知识层
-- README 完整性
-- API 文档检查
-- CHANGELOG 规范
-- 开发规范
-
-🔵 架构设计层
-- 接口契约对齐
-- 共享逻辑识别
-- 依赖循环检测
-- 模块边界检查
-
-⚪ 质量门禁层
-- 提交规范
-- Review 清单
-- 自动化规则
-- 准入标准
-```
-
-#### Step 2: 关联推理
-
-```
-示例关联分析：
-
-发现: "模块A测试覆盖率低（60%）"
-关联:
-  - 模块A变更频率高（每周5次）
-  - 近期Bug多（本月8个）
-  - 依赖模块B不稳定
-  - 新成员常修改此文件
-
-推理:
-  不是简单"补测试"
-  而是"重构A与B边界 + 补契约测试 + 补充单元测试 + 添加注释"
-
-预测效果:
-  - Bug率降低: 50%
-  - 维护成本降低: 40%
-  - 新人上手时间减少: 30%
-```
-
-#### Step 3: 生成改进方案
-
-```yaml
-improvements:
-  - id: IMP-001
-    priority: P0
-    category: architecture
-    title: "重构订单模块与支付模块边界"
-
-    problem:
-      description: "两个模块循环依赖，导致发布耦合"
-      evidence:
-        - "过去3个月必须同时发布5次"
-        - "循环依赖分析报告"
-
-    solution:
-      approach: "提取共享接口层"
-      steps:
-        - "创建 order-payment-contract 模块"
-        - "移动共享接口到契约模块"
-        - "更新依赖关系"
-      estimated_time: "2小时"
-
-    impact:
-      bug_rate_reduction: "60%"
-      release_risk_reduction: "50%"
-
-    validation:
-      - "编译通过"
-      - "所有测试通过"
-      - "无循环依赖"
-
-    auto_fixable: false  # 需要人工确认
-```
-
-#### Step 4: 执行修复（如 --auto-fix）
-
-```
-L1 自动修复:
-- 直接执行，无需确认
-- 每项修复单独提交
-- 失败自动回滚
-
-L2/L3 建议+确认:
-- 生成详细方案
-- 等待人工确认
-- 支持一键执行
-```
-
-#### Step 5: A/B 验证
-
-```
-修复前:
-  - 记录基线指标
-  - 代码复杂度
-  - 测试通过率
-  - 构建时间
-
-修复后:
-  - 对比指标变化
-  - 退化 → 自动回滚
-  - 提升 → 记录成功模式
-```
-
----
-
-### Mode: --focus（专项进化）
-
-**目标**: 针对特定维度深度优化
-
-#### --focus=code（代码质量专项）
-
-```
-重点检查:
-- 代码规范（lint规则）
-- 类型安全（TypeScript类型完整性）
-- 代码注释（公共API文档）
-- 重复代码（提取公共函数）
-- 死代码清理
-- 复杂度优化
-
-自动修复:
-- 格式化
-- 未使用导入清理
-- 简单重构
-```
-
-#### --focus=test（测试体系专项）
-
-```
-重点检查:
-- 测试覆盖率缺口
-- 边界条件测试
-- 异常分支测试
-- Mock数据管理
-- Flaky test 检测
-- 契约测试（多系统）
-
-自动修复:
-- 生成缺失测试模板
-- 补充边界测试
-- 优化Mock数据
-```
-
-#### --focus=performance（性能专项）
-
-```
-重点检查:
-- 大文件/大函数
-- 重复计算
-- 内存泄漏风险
-- 异步优化机会
-- 资源加载优化
-
-建议:
-- 性能优化方案
-- 基准测试建议
-```
-
-#### --focus=security（安全专项）
-
-```
-重点检查:
-- 依赖安全漏洞
-- 敏感信息泄露
-- 输入验证
-- 权限检查
-- 安全头部
-
-自动修复:
-- 升级安全依赖
-- 添加基础防护
-```
-
-#### --focus=docs（文档专项）
-
-```
-重点检查:
-- README 完整性
-- API 文档
-- CHANGELOG
-- 代码注释
-- 开发规范
-
-自动修复:
-- 生成API文档
-- 更新CHANGELOG
-- 补充基础注释
-```
-
-#### --focus=arch（架构专项）
-
-```
-重点检查:
-- 模块边界
-- 依赖关系
-- 接口契约
-- 设计模式
-
-建议:
-- 重构方案
-- 解耦策略
-```
-
-#### --focus=multi（多系统专项）
-
-```
-重点检查:
-- 子系统接口契约一致性
-- 共享逻辑抽离机会
-- 依赖循环
-- 构建顺序优化
-- 数据模型对齐
-
-自动修复:
-- 同步接口定义
-- 建议共享库
-- 优化构建配置
-```
-
----
-
-### Mode: --advise（智能建议）
-
-**目标**: 只分析不执行，生成详细建议报告
-
-```
-执行流程同 --deep，但：
-- 不执行任何修复
-- 生成详细分析报告
-- 提供多种方案对比
-- 预测每种方案效果
-```
-
----
-
-### Mode: --chat（对话式交互）
-
-**目标**: 交互式进化，逐步确认
-
-```
-AI: 发现3个可优化点，最紧急的是订单模块复杂度超标，要看看吗？
-User: 看看
-AI: [展示详情] 建议拆分为3个子模块，预计减少40%维护成本。要自动执行吗？
-User: 先执行第一个子模块
-AI: 好的，执行后我会记录效果，如果好就推荐应用到其他模块。
-```
-
----
-
-### Mode: --learn-from（学习模式）
-
-**目标**: 观察人工操作，学习团队偏好
-
-```
-1. 读取人工修改记录
-2. 对比 AI 建议与人工决策
-3. 分析差异原因
-4. 更新团队偏好
-5. 调整未来建议
-
-示例学习:
-- 团队更喜欢某种代码风格 → 更新风格偏好
-- 人工经常跳过某类建议 → 降低优先级或移除
-- 人工经常手动做某事 → 添加自动检测
-```
-
----
-
-### Mode: --generate（生成 Benchmark）
-
-**目标**: 基于项目自动生成测试基准，用于评估项目开发能力
-
-#### Step 1: 项目扫描
-
-```
-1. 检测技术栈
-   - package.json → Node.js/React/Vue
-   - pom.xml/build.gradle → Java/Spring
-   - go.mod → Go
-   - requirements.txt/pyproject.toml → Python
-
-2. 检测项目结构
-   - 源码目录
-   - 测试框架
-   - 构建工具
-
-3. 检测现有配置
-   - lint 配置
-   - 测试配置
-   - CI/CD 配置
-```
-
-#### Step 2: LLM 分析项目特征
-
-**【核心】使用 LLM 智能分析项目：**
-
-```
-1. 准备项目上下文：
-   - 项目结构概览
-   - 主要依赖和框架
-   - 测试框架和配置
-   - 入口文件和核心模块
-
-2. 调用 LLM 分析：
-   请分析以下项目特征，生成针对性的 benchmark 配置：
-
-   - 项目复杂度评估（简单/中等/复杂）
-   - 关键功能模块识别
-   - 测试需求分析
-   - 性能关注点识别
-   - 安全关注点识别
-
-3. LLM 输出 benchmark 配置建议
-```
-
-#### Step 3: 生成 Benchmark
-
-根据 LLM 建议生成 benchmark：
-
-```yaml
-# .autospec/benchmarks/project-{name}.yaml
-pipeline: {detected-pipeline-type}
-description: "基于项目特征自动生成的 benchmark"
-
-scenario:
-  name: "{project-name} 开发能力测试"
-  input: "{LLM-generated-scenario}"
-  complexity: {detected-complexity}
-  expectedStages:
-    - requirement
-    - design
-    - implement
-    - test
-    - deliver
-
-stageCriteria:
-  requirement:
-    expectedArtifacts:
-      - specs/{project}/requirement.md
-    successCriteria:
-      - 需求描述清晰
-      - 验收标准完整
-    qualityMetrics:
-      - 需求完整率: ">= 90%"
-
-  design:
-    expectedArtifacts:
-      - specs/{project}/design.md
-    successCriteria:
-      - 架构设计合理
-      - API 定义完整
-    qualityMetrics:
-      - 设计完整率: ">= 90%"
-
-  implement:
-    expectedArtifacts:
-      - src/ 源代码
-      - tests/ 测试代码
-    successCriteria:
-      - 代码编译通过
-      - 单元测试通过
-    qualityMetrics:
-      - 测试覆盖率: ">= 70%"
-
-  test:
-    expectedArtifacts:
-      - tests/ 测试报告
-    successCriteria:
-      - 测试用例完整
-      - 测试通过
-    qualityMetrics:
-      - 测试通过率: ">= 90%"
-
-  deliver:
-    expectedArtifacts:
-      - release-notes.md
-    successCriteria:
-      - 发布说明完整
-    qualityMetrics:
-      - 文档完整率: ">= 90%"
-```
-
-#### Step 4: 保存 Benchmark
-
-- 保存到 `.autospec/benchmarks/project-{name}.yaml`
-- 该 benchmark 用于项目自我评测，可通过 project-evolve 自我评估
-
----
-
-### Mode: --review（效果回顾）
-
-**目标**: 回顾进化效果，持续改进
-
-```
-1. 读取历史执行记录
-2. 统计指标变化
-   - 代码质量趋势
-   - Bug率变化
-   - 维护成本变化
-3. 分析哪些改进有效
-4. 识别新的优化机会
-5. 生成回顾报告
-```
-
----
-
-### Mode: 记忆管理
-
-#### --memory-status
-
-```
-显示记忆系统状态：
-- 总记忆数
-- 各状态分布（learning/validated/deprecated）
-- 最近更新
-- 记忆健康度
-```
-
-#### --tune-rules
-
-```
-交互式调整评测规则：
-- 查看当前规则
-- 启用/禁用规则
-- 调整规则参数
-- 添加自定义规则
-```
-
-#### --export-memory
-
-```
-导出团队记忆包：
-- 打包 validated 记忆
-- 包含团队偏好
-- 生成可复用包
-```
-
-#### --import-memory
-
-```
-导入他人记忆包：
-- 自动适配当前项目
-- 合并团队偏好
-- 标记为 learning 状态
-```
-
-#### --sync-memory
-
-```
-同步最新能力：
-- 从 Field-Evolve 获取新能力
-- 更新评测规则
-- 保持与框架同步
-```
-
----
-
-## 六层可进化维度
-
-### 🔴 第一层：代码质量
-
-| 进化点 | 自动检测 | 自动修复 | 说明 |
-|--------|---------|---------|------|
-| 代码规范 | ✅ | ✅ | lint规则优化、format统一 |
-| 类型安全 | ✅ | ⚠️ | TypeScript类型补全 |
-| 代码注释 | ✅ | ⚠️ | 公共API文档注释 |
-| 重复代码 | ✅ | ⚠️ | 检测重复、提取公共函数 |
-| 死代码 | ✅ | ✅ | 未使用变量/函数清理 |
-| 复杂度 | ✅ | ⚠️ | 复杂函数拆分建议 |
-
-### 🟠 第二层：测试体系
-
-| 进化点 | 自动检测 | 自动修复 | 说明 |
-|--------|---------|---------|------|
-| 测试补全 | ✅ | ⚠️ | 基于覆盖率补缺失测试 |
-| 测试数据 | ✅ | ⚠️ | 生成Mock数据 |
-| 边界测试 | ✅ | ⚠️ | 边界条件、异常分支 |
-| 契约测试 | ✅ | ⚠️ | 子系统间API契约（多系统） |
-| 测试稳定性 | ✅ | ⚠️ | 修复flaky test |
-
-### 🟡 第三层：配置与工程
-
-| 进化点 | 自动检测 | 自动修复 | 说明 |
-|--------|---------|---------|------|
-| 构建优化 | ✅ | ⚠️ | 配置调优、缓存策略 |
-| 依赖管理 | ✅ | ✅ | 过期依赖升级、安全修复 |
-| CI/CD优化 | ✅ | ⚠️ | 流水线精简、并行化 |
-| 环境一致性 | ✅ | ⚠️ | 配置同步 |
-| 多系统构建 | ✅ | ⚠️ | 构建顺序优化 |
-
-### 🟢 第四层：文档与知识
-
-| 进化点 | 自动检测 | 自动修复 | 说明 |
-|--------|---------|---------|------|
-| README | ✅ | ⚠️ | 安装、使用指南补全 |
-| API文档 | ✅ | ⚠️ | 自动生成/更新 |
-| CHANGELOG | ✅ | ✅ | 基于提交生成 |
-| 架构文档 | ✅ | ⚠️ | 多系统关系图 |
-| 开发规范 | ✅ | ⚠️ | 团队规范文档 |
-
-### 🔵 第五层：架构与设计
-
-| 进化点 | 自动检测 | 自动修复 | 说明 |
-|--------|---------|---------|------|
-| 接口契约 | ✅ | ⚠️ | 契约对齐（多系统） |
-| 共享逻辑 | ✅ | ⚠️ | 抽离建议（多系统） |
-| 子系统解耦 | ✅ | ⚠️ | 循环依赖检测 |
-| 数据模型 | ✅ | ⚠️ | 跨系统对齐 |
-| 错误处理 | ✅ | ⚠️ | 统一规范 |
-
-### ⚪ 第六层：质量门禁
-
-| 进化点 | 自动检测 | 自动修复 | 说明 |
-|--------|---------|---------|------|
-| 提交规范 | ✅ | ⚠️ | commit message检查 |
-| Review清单 | ✅ | ⚠️ | 基于历史问题更新 |
-| 自动化规则 | ✅ | ⚠️ | lint规则更新 |
-| 准入标准 | ✅ | ⚠️ | 覆盖率阈值配置 |
-
----
-
-## 智能触发时机
-
-```
-# 定时巡航（CI集成）
-- 每次提交后
-- 每日定时
-- 发布前
-
-# 事件触发
-- 代码合并后
-- 测试失败后
-- 生产故障后
-
-# 趋势预警
-- 代码复杂度连续增长
-- 测试覆盖率下降
-- Bug率上升
-```
-
----
-
-## 安全机制
-
-### 进化分区保护
-
-```
-冻结区（绝不自动修改）:
-- constitution.md
-- evolution.md
-- 核心设计原则
-- 安全敏感配置
-
-受控区（需确认）:
-- 架构调整
-- 接口变更
-- 配置修改
-
-自由区（自动修复）:
-- 代码格式化
-- 未使用导入清理
-- 简单命名规范化
-```
-
-### 回滚机制
-
-```
-每项自动修复：
-1. 修复前保存快照
-2. 修复后验证
-3. 失败 → 自动回滚
-4. 记录失败模式
-```
-
----
-
-## 产出物
-
-```
-.autospec/
-├── memory/                       # 评测记忆
-│   ├── index.yaml
-│   ├── discovered/
-│   ├── patterns/
-│   ├── preferences/
-│   └── evolution/
-├── logs/
-│   └── project-evolve/
-│       ├── cruise-{date}.md      # 巡航报告
-│       ├── deep-{date}.md          # 深度报告
-│       ├── advise-{date}.md        # 建议报告
-│       └── review-{date}.md        # 回顾报告
-└── runtime/
-    └── project-evolve-state.json   # 执行状态
-```
-
----
-
-## 使用示例
-
-```bash
-# 执行 project-evolve（运行时选择模式）
-/autospec:project-evolve
-
-# 选择模式：
-# 1. quick    - 快速扫描（代码规范检查 + 简单修复）
-# 2. deep     - 深度进化（全维度分析 + 自动修复）
-# 3. full     - 完整循环（深度 + 持续优化 + 效果验证）
-# 4. report   - 仅报告（分析并生成建议报告）
-# 5. review   - 效果回顾
-# 6. generate - 生成 Benchmark
-# 7. learn    - 学习模式
-```
-
----
-
-## 预期效果
-
-### 量化指标
-- 代码规范自动修复率: 90%+
-- 测试覆盖率提升: +30%
-- 代码Review效率: +50%
-- 新人上手时间: -40%
-- Bug率（生产环境）: -30%
-
-### 质化效果
-- **团队**: 减少重复劳动，聚焦业务价值
-- **项目**: 自我维护、自我改进的活的系统
-- **组织**: 经验沉淀、能力复用、持续进化