@chongyan/autospec 1.0.1 → 1.0.3

package/knowledge/principles/evolution.md

@@ -1,553 +0,0 @@
-# 自进化机制
-
-> 核心思想：**让框架从每次执行中学习，但进化本身必须受约束、可回滚、可审计。**
->
-> **版本**: v2.0
-> **最后更新**: 2026-03-26
-> **基于**: FinSDD 自进化体系、Claude Marketplace 插件进化机制
-
-## 三层自进化体系
-
-AutoSpec 的自进化在三个层面分层发生，形成从项目实践到框架升级的完整闭环：
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│  L1: Self-Evolve (框架级)                                        │
-│  /self-evolve                                                    │
-│  目标: AutoSpec 框架自身的迭代升级                                  │
-│  位置: .claude/skills/self-evolve/                               │
-│  产出: 框架技能、方法论、设计原则                                  │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓ 提炼
-┌─────────────────────────────────────────────────────────────────┐
-│  L2: Field-Evolve (领域级)                                        │
-│  /autospec:field-evolve                                          │
-│  目标: 框架从实战项目中学习和提炼能力                               │
-│  位置: plugins/commands/autospec:field-evolve.md                            │
-│  产出: 领域技能、最佳实践、benchmarks                              │
-└─────────────────────────────────────────────────────────────────┘
-                              ↓ 应用
-┌─────────────────────────────────────────────────────────────────┐
-│  L3: Project-Evolve (项目级)                                      │
-│  /autospec:project-evolve                                        │
-│  目标: 实战项目自身的代码、配置、文档优化                          │
-│  位置: plugins/commands/autospec:project-evolve.md                        │
-│  产出: 代码质量提升、测试补全、文档完善                            │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### L1: Self-Evolve（框架自我进化）
-
-迭代 AutoSpec **自身**时，框架用自己的流程来完善自己（dogfooding）：
-
-```
-AutoSpec 自身改进需求 → 走 AutoSpec 流程 → practice-log → 框架进化
-                                              ↓
-                          同一次迭代既是产出，又是进化信号
-```
-
-- AutoSpec 的开发本身遵循启动门禁和双层验证
-- 对框架文件的修改要用框架自身的审查流程验证
-- 通过 benchmark 评估进化效果，退化自动回滚
-- 框架越用越好，形成飞轮效应
-
-### L2: Field-Evolve（领域进化）
-
-用 AutoSpec 驱动**其他项目**研发时，实践经验自动回流到框架：
-
-```
-项目A研发 → practice-log → distiller提炼新skill → 框架变强
-项目B研发 → practice-log → extractor提炼methodology → 框架变强
-项目C研发 → 新领域技能沉淀 → skills/domain/ 扩充
-        ↓
-每个项目的经验都让下一个项目更顺畅
-```
-
-- 分析实战项目中的 benchmarks 评测数据，提炼有效模式
-- 从 practice-log 中蒸馏通用技能和最佳实践
-- 每个项目的经验通过 field-evolve 提炼后应用于所有项目
-- 领域特有的技能留在企业叠加层（不上游）
-- 通用的改进（pipeline优化、skill改进）贡献回核心框架
-
-### L3: Project-Evolve（项目自我进化）
-
-实战项目**自身**的代码、配置、文档优化：
-
-```
-代码扫描 → 问题检测 → 自动修复/A/B验证 → 质量提升
-    ↑                                    ↓
-    └──────────── 持续巡航 ←─────────────┘
-```
-
-- **智能感知**：自动发现代码质量问题、测试缺口、文档缺失
-- **自动修复**：格式化、重构、补全测试、完善文档
-- **评测驱动**：基于 benchmarks 评测指导优化方向
-- **记忆沉淀**：项目级经验沉淀为团队共享知识
-
-### 三层进化的关系
-
-```
-L3 Project-Evolve（项目级优化，量大，持续）
-    ↓ 实践信号汇聚
-L2 Field-Evolve（领域级提炼，周期性）
-    ↓ 提炼通用能力
-L1 Self-Evolve（框架级升级，战略性）
-    ↓ 框架升级
-L3 Project-Evolve（升级后的框架用于新项目）
-```
-
-**数据流向**：
-- 向下流动：L1 → L2 → L3 是能力下发（框架升级 → 领域技能 → 项目应用）
-- 向上流动：L3 → L2 → L1 是经验回流（项目实践 → 领域提炼 → 框架升级）
-
-## 第一原则
-
-进化系统最危险的失败模式是**修改自己的评判标准**。因此：
-
-1. **评判器不可变** — 宪法、验证harness、进化规则本身，不可被自动修改
-2. **约束进化空间** — 明确哪些可以自动进化，哪些需要人工批准
-3. **可量化适应度** — 进化必须有可测量的改进信号，不凭感觉
-4. **可回滚** — 每次进化变更可追溯、可撤销
-5. **简洁压力** — 等效结果下，优先选择更简单的方案
-
-## 进化分区与三层体系的对应
-
-将框架内容分为四个区域，对应三层自进化体系的不同层级：
-
-| 进化分区 | 对应层级 | 进化命令 | 主要内容 |
-|---------|---------|---------|---------|
-| 🔴 冻结区 | L1 Self-Evolve 核心 | `/self-evolve` | 宪法、进化规则、核心原则 |
-| 🟡 受控区 | L1/L2 交界 | `/self-evolve` + 人工审批 | pipeline、通用skills、角色画像 |
-| 🟢 自由区 | L2 Field-Evolve | `/autospec:field-evolve` | domain skills、benchmarks、决策树 |
-| 🔵 环境知识区 | L3 Project-Evolve | `/autospec:project-evolve` | 环境配置、组件库、最佳实践 |
-
-### 🔴 冻结区（Frozen Zone）
-
-**绝不可自动修改。变更必须由人工发起并审批。**
-
-| 内容                                                 | 原因            |
-| -------------------------------------------------- | ------------- |
-| `constitution.md`                                  | 安全红线，是整个系统的底座 |
-| `evolution.md`（本文件）                                | 进化规则本身，防止自我篡改 |
-| `pipeline/overview.md` 的启动门禁和双层验证定义                | 流程骨架，牵一发动全身   |
-| `methodology/design-philosophy.md` 的第一性原则（DP1-DP3） | 根基原则          |
-| 评判标准的判定逻辑（审类skill的"必须满足"条款）                        | 防止降低标准来通过验证   |
-
-**冻结区变更协议**：
-
-1. 人工提出变更提案（说明理由、影响范围、回滚方案）
-2. 至少经过一个完整项目周期的试运行
-3. 变更作为独立commit，message标记 `[FROZEN-ZONE]`
-
-### 🟡 受控区（Controlled Zone）
-
-**可以自动提议变更，但必须人工批准后才能生效。**
-
-| 内容                                                    | 进化方式                   |
-| ----------------------------------------------------- | ---------------------- |
-| `pipeline/01-requirement.md` \~ `06-delivery.md` 阶段定义 | 基于practice-log分析提出优化建议 |
-| `skills/stages/` 通用技能                                 | 基于执行效果提出改进             |
-| `roles/{role-name}.md` 角色画像                           | 基于实际项目反馈调整关注点          |
-| `methodology/principles.md`                           | 基于实践验证新增/修订原则          |
-| `methodology/checklists/`                             | 基于审查结果补充检查项            |
-
-**受控区变更协议**：
-
-1. 自动生成变更提案（含：当前问题 + 建议修改 + 支撑证据 + 预期效果）
-2. 提案存放于 `.autospec/evolution/proposals/` 待审批
-3. 人工审批通过后合入
-4. 合入后跑一次基准案例对比（如有）
-5. 对比退化 → 自动回滚
-
-### 🟢 自由区（Free Zone）
-
-**可以自动进化，但必须通过skill-validator验证。**
-
-| 内容                            | 进化方式              |
-| ----------------------------- | ----------------- |
-| `skills/domain/` 业务技能         | 从practice-log自动蒸馏 |
-| `roles/*/skills/` 角色特有技能      | 从角色实践中自动提炼        |
-| `evaluation/benchmarks/` 基准案例 | 从成功/失败案例自动归档      |
-| `methodology/decision-trees/` | 从重复决策模式中自动生成      |
-
-**自由区变更约束**：
-
-1. 必须通过 skill-validator 验证
-2. 不可与冻结区内容冲突
-3. 每次变更记录到进化日志
-4. 同一skill在一个进化周期内最多修改一次（防止震荡）
-
-### 🔵 环境知识区（Environment Knowledge Zone）
-
-**环境衔接层知识，按类型分属不同进化分区。**
-
-详见 `knowledge/environment/overview.md`。
-
-| 内容 | 进化分区 | 进化方式 |
-|------|---------|---------|
-| `environment/env-knowledge/middleware/` 中间件知识 | 🟡 受控区 | 人工定义 + 自动验证，自动提议需人工批准 |
-| `environment/env-knowledge/infrastructure/` 基础设施知识 | 🟡 受控区 | 人工定义 + 自动验证 |
-| `environment/component-lib/components/` 组织组件库 | 🟢 自由区 | 自动进化 + validator验证 |
-| `environment/component-lib/best-practices/` 最佳实践 | 🟢 自由区 | 从practice-log自动蒸馏 |
-| `environment/integration/ci-cd/` CI/CD配置 | 🟡 受控区 | 人工定义 + 自动执行 |
-| `environment/integration/testing/` 测试知识 | 🟡 受控区 | 从测试执行自动学习，人工审批后生效 |
-| `environment/integration/deployment/` 部署配置 | 🟡 受控区 | 人工定义 + 自动执行 |
-
-**环境知识进化协议**：
-
-1. **中间件知识进化**：
-   - 从代码中检测到新的中间件使用模式 → 自动生成配置模板提案
-   - 提案存放于 `.autospec/evolution/proposals/` 待审批
-   - 人工审批后写入 `environment/env-knowledge/middleware/`
-
-2. **组件知识进化**：
-   - 同类使用模式出现3次 → 自动生成组件知识提案
-   - 通过 environment-manager hook 验证后自动合入
-   - 更新注册表 `environment/registry.json`
-
-3. **集成知识进化**：
-   - 新增CI/CD、测试、部署配置需人工定义
-   - 配置变更需经过验证流程
-
-4. **测试知识进化**：
-   - 触发时机：每次交付完成后，skill-distiller 扫描测试执行记录
-   - 学习信号：
-     - 新的测试框架或工具使用模式（出现3次以上）
-     - 更高效的 Mock 策略或测试数据准备方法
-     - 测试失败模式重复出现（同类失败3次以上）
-     - 测试代码风格趋于稳定（可提炼为模板）
-   - 进化流程：
-     - skill-distiller 识别测试模式 → 自动生成测试知识提案
-     - 提案存放于 `.autospec/evolution/proposals/` 待审批
-     - 人工审批后写入 `environment/integration/testing/`
-   - 知识格式：推荐使用自由的 Markdown 格式，而非结构化 YAML
-   - 验证：用实际测试案例验证效果
-
-**环境知识验证**：
-
-- Schema验证：YAML格式正确
-- 环境变量验证：必需变量存在
-- 安全检查：无危险命令、无硬编码敏感信息
-- 语义验证：与项目技术栈兼容
-
-## 进化循环
-
-```
-执行流水线 → 收集信号 → 分析模式 → 生成提案 → 验证提案 → 接受/拒绝 → 下一轮
-    │              │            │            │            │           │
-    │              │            │            │            │           └─ 拒绝 = 回滚
-    │              │            │            │            └─ skill-validator + 基准对比
-    │              │            │            └─ 区分冻结/受控/自由区
-    │              │            └─ skill-distiller + methodology-extractor
-    │              └─ practice-log + 执行指标
-    └─ pipeline-runner 驱动
-```
-
-### 基于评测驱动的自进化
-
-AutoSpec 通过 **Benchmarks 评测** 驱动进化，形成"评测 → 分析 → 改进 → 验证"的闭环：
-
-```
-实战流程执行
-    ↓
-自动生成 Benchmarks（基于项目特点）
-    ↓
-执行 Benchmarks 评测（Layer 1 + Layer 2 + Layer 3）
-    ↓
-生成评测报告（评分、改进建议）
-    ↓
-Field-Evolve 分析（哪些 benchmarks 有效）
-    ↓
-提炼通用 Benchmarks 模板
-    ↓
-更新框架 Benchmarks 能力
-    ↓
-应用于所有项目
-```
-
-**评测驱动的价值**：
-1. **客观量化**：用数据而非主观判断评估进化效果
-2. **及时反馈**：每次执行后立即获得改进信号
-3. **可追溯**：评测历史记录进化轨迹
-4. **可对比**：基准案例对比验证进化有效性
-
-### 信号收集
-
-每次流水线执行后，自动收集：
-
-| 信号            | 来源         | 含义        |
-| ------------- | ---------- | --------- |
-| Layer 1 通过率   | 验证日志       | 代码质量基线    |
-| Layer 2 首次通过率 | 审查结果       | skill产出质量 |
-| **Layer 3 评测分数** | **benchmarks结果** | **综合质量评分** |
-| **Benchmarks 通过率** | **评测报告** | **阶段准出指标** |
-| 回退次数          | state.json | 流程顺畅度     |
-| 人工介入次数        | 执行日志       | 自主能力指标    |
-| 阶段耗时          | 执行日志       | 效率指标      |
-| 假设漂移次数        | 假设追踪表      | 阶段间一致性    |
-
-### 适应度函数
-
-```
-进化有效 = 以下至少一项改善，且无一项退化：
-  1. Layer 1+2 首次通过率 ↑
-  2. Layer 3 Benchmarks 综合评分 ↑
-  3. Benchmarks 通过率 ↑
-  4. 回退次数 ↓
-  5. 人工介入次数 ↓（在同等执行模式下）
-  6. 交付成功率 ↑
-
-进化无效 = 任何安全指标退化（即使其他指标改善）
-```
-
-**Benchmarks 驱动的进化指标**：
-- 各阶段 benchmarks 平均分数趋势
-- P0 benchmarks 首次通过率
-- 评测建议的采纳率和效果
-
-### 进化周期
-
-| 频率                  | 动作                          | 对应层级    |
-| ------------------- | --------------------------- | --------- |
-| **每次执行后**           | 记录practice-log，收集信号         | L3 Project  |
-| **阶段完成后**           | 执行 Benchmarks 评测                | L3 Project  |
-| **每5条practice-log** | 触发 distiller + extractor 扫描 | L2 Field    |
-| **每周/每迭代**          | 审查受控区变更提案 + Benchmarks分析    | L2 Field    |
-| **每季度**             | 冻结区变更评估 + 自主边界扩展            | L1 Self     |
-| **每年/大版本**          | 框架架构升级 + 进化体系迭代            | L1 Self     |
-
-## 企业适配
-
-AutoSpec 通过**领域叠加层**适配不同企业环境，而非分叉框架。
-
-### 适配架构
-
-```
-┌─────────────────────────────────┐
-│         企业叠加层               │  ← 企业特有（不上游合并）
-│  org-constitution.md            │     企业级红线追加
-│  org-skills/                    │     企业特有技能
-│  org-checklists/                │     企业特有检查项
-│  domain-knowledge/              │     领域知识注入
-├─────────────────────────────────┤
-│         AutoSpec 核心框架        │  ← npm install 获得（可升级）
-│  constitution.md                │
-│  pipeline/ skills/ roles/ ...   │
-└─────────────────────────────────┘
-```
-
-### 领域注入
-
-```bash
-autospec init --domain <domain>
-```
-
-通过 `--domain` 指定业务领域，自动加载领域特有的：
-
-| 领域           | 注入内容示例                     |
-| ------------ | -------------------------- |
-| `finance`    | 合规检查项、金额必须用Money类、审计日志要求 |
-| `healthcare` | 数据隐私红线、医疗合规检查、医疗数据校验    |
-| `ecommerce`  | 高并发检查、支付安全、库存一致性           |
-| `generic`    | 仅核心框架，无领域叠加（默认）            |
-
-领域配置存放于 `.autospec/domain/`，格式：
-
-```json
-// .autospec/domain/config.json
-{
-  "domain": "finance",
-  "version": "1.0",
-
-  // 追加到宪法（不替换核心宪法）
-  "constitution_addons": [
-    "敏感数据处理必须有审计日志",
-    "金额计算禁止使用浮点数"
-  ],
-
-  // 追加到检查清单
-  "checklist_addons": {
-    "code": [
-      "所有金额字段使用 BigDecimal/Money 类型",
-      "交易操作必须有幂等性保证"
-    ],
-    "design": [
-      "支付链路必须有对账机制"
-    ]
-  },
-
-  // 领域特有技能（指向文件）
-  "skills": [
-    "domain/finance-compliance-checker.md",
-    "domain/finance-audit-reviewer.md"
-  ]
-}
-```
-
-### 流水线扩展钩子
-
-企业可在每个流水线阶段注入自定义逻辑，无需修改核心框架：
-
-```
-before_require  → [需求分析] → after_require
-before_design   → [方案设计] → after_design
-before_implement → [编码实现] → after_implement
-before_review   → [代码审查] → after_review
-before_test     → [QA测试]   → after_test
-before_deliver  → [交付部署] → after_deliver
-```
-
-**扩展钩子配置**（`.autospec/domain/hooks.json`）：
-
-```json
-{
-  "hooks": {
-    "before_implement": [
-      {
-        "name": "compliance-scan",
-        "command": "node .autospec/domain/scripts/compliance-check.js",
-        "required": true
-      }
-    ],
-    "after_review": [
-      {
-        "name": "jira-sync",
-        "command": "node .autospec/domain/scripts/sync-to-jira.js",
-        "required": false
-      }
-    ]
-  }
-}
-```
-
-**设计原则**：
-
-- 钩子缺失或失败时，核心流程不受影响（`required: false` 时优雅降级）
-- `required: true` 的钩子失败 → 等同 Layer 1 失败，阻止进入下一阶段
-- 钩子是确定性脚本，不是AI判断
-
-### 企业私有进化
-
-企业环境中的进化产出分为两类：
-
-1. **可上游贡献**：改进通用pipeline/skills → 提PR回AutoSpec主仓
-2. **企业私有**：企业特有技能/检查项/知识 → 留在企业叠加层，不上游
-
-分离标准：**是否依赖企业内部上下文**。依赖 → 私有。不依赖 → 可贡献。
-
-## Claude Code 集成
-
-AutoSpec 通过 Claude Code 原生机制实现流程控制，不额外发明抽象：
-
-### 集成架构
-
-```
-Claude Code 原生机制          AutoSpec 用途
-─────────────────────────    ──────────────────────────────
-.claude/commands/            斜杠命令 → 显式触发流程/阶段
-.claude/skills/              技能 → 自动感知开发任务，注入流程意识
-.claude/agents/              子Agent → 做审分离（独立审查实例）
-.claude/settings.json        Hooks → 确定性安全检查（冻结区守卫、Layer 1 信号）
-```
-
-### Hooks（确定性守卫 + 质量监控）
-
-通过 Claude Code hooks 实现安全检查和质量监控，不依赖 AI 判断：
-
-| Hook                       | 事件                      | 作用                                  |
-| -------------------------- | ----------------------- | ----------------------------------- |
-| `frozen-zone-guard`        | PreToolUse (Write/Edit) | 阻止对冻结区文件的自动修改                       |
-| `scope-sentinel`           | PreToolUse (Write/Edit) | 编码阶段偏航检测（三级递增提醒）                    |
-| `layer1-validator`         | PreToolUse/PostToolUse  | Layer 1 强制检查 + 结果捕获 + 质量追踪           |
-| `execution-tracker`        | PostToolUse (全部)        | 追踪执行日志（skill 加载、agent 调用、产物生成）       |
-| `environment-manager`      | Stop                    | 环境知识验证 + 未注册中间件检测                   |
-
-Hooks 是**确定性的**（shell脚本，非AI判断），对应 DP1 第一层验证理念。
-企业可在此基础上追加自定义 hooks（合规检查、审计日志等）。
-
-### Skills（流程意识注入）
-
-| Skill                | 触发条件                              | 作用                                                       |
-| -------------------- | --------------------------------- | -------------------------------------------------------- |
-| `startup-guard`      | Claude 检测到开发类任务但未使用 / 命令 | 自动注入启动门禁意识，推荐合适的工作流命令                                    |
-| `layer1-validation`  | 代码变更后                             | 提醒运行 Layer 1 验证                                          |
-| `requirement-stage`   | 需求分析场景                            | 加载需求分析流程（含CEO探索对齐）+ skill + 方法论原则                        |
-| `design-stage`    | 方案设计场景                            | 加载设计流程 + skill + 方法论原则 + 检查清单                            |
-| `implementation-stage` | 编码实现场景                            | 加载实现流程 + skill + Brownfield适配 + 角色关注点                    |
-| `testing-stage`      | 测试场景                              | 加载测试流程 + skill + 角色特有测试关注点                               |
-| `delivery-stage`   | 交付部署场景                            | 加载交付流程 + 安全检查 + 自动触发practice-log和进化信号                    |
-| `evolution-process`    | 框架进化/流程完成后                        | 加载进化流程（强制执行 distiller + extractor + evolver + validator） |
-| `pending-dashboard`   | 新会话启动时                            | 扫描待处理提案/practice-log/中断流程，主动提醒用户                         |
-
-Skills 是**被动激活的**——Claude 根据 description 自动判断是否加载。
-与 commands（主动调用）互补：skill 保底防跳过，command 显式驱动。
-
-### Agents（做审分离 + CEO探索 + 自主决策）
-
-| Agent                         | 用途                  | 隔离方式                     |
-| ----------------------------- | ------------------- | ------------------------ |
-| `independent-reviewer`           | 需求/设计/代码 Layer 2 审查 | 独立上下文 + 只读权限 + 仅获得产出物和标准 |
-| `test-coverage-reviewer`      | 测试充分性审查             | 独立上下文 + 只读权限 + 建立覆盖映射表   |
-| `consistency-checker`        | 跨产物一致性检查（DP18）      | 独立上下文 + 只读权限 + 六维检测      |
-| `ceo`       | CEO/战略视角需求探索        | 独立上下文 + 只读权限 + 聚焦商业价值    |
-| `product-owner` | 产品落地挑战（与CEO博弈）      | 独立上下文 + 只读权限 + 聚焦可行性     |
-| `stage-gate-evaluator`         | 自主阶段产出审批（无人值守）      | 独立上下文 + 只读权限 + 客观评估质量    |
-| `safety-auditor`     | 不可逆操作安全审计           | 独立上下文 + 只读权限 + 安全风险评估    |
-| `failure-diagnostician`           | 自主故障诊断（回退Level 3替代） | 独立上下文 + 只读权限 + 根因分析      |
-
-通过 Claude Code 的 Agent 机制实现 DP2 做审分离和多Agent博弈，审查/探索 Agent 天然信息隔离。
-自主决策类 Agent（stage-gate/safety-auditor/diagnose）实现无人值守流水线。
-
-### 扩展点
-
-企业可通过以下方式扩展 Claude Code 集成：
-
-```
-.claude/
-├── commands/autospec/       # 追加企业自定义命令
-├── skills/                  # 追加企业特有 skills
-├── agents/                  # 追加企业特有 agents（如安全审计Agent）
-└── settings.json            # 追加企业 hooks（如合规检查）
-```
-
-所有扩展遵循 Claude Code 原生格式，无额外学习成本。
-
-## 安全护栏
-
-### 进化不可触碰的底线
-
-1. **不可降低验证标准** — 进化可以改进skill产出，不可放宽审查标准
-2. **不可跳过Layer 1** — 即使skill进化了，确定性验证仍然必须真实执行
-3. **不可自动修改冻结区** — 包括本文件
-4. **不可在无实践支撑时进化** — 每条进化变更必须引用至少1条practice-log
-5. **不可无限自进化** — 同一组件在一个周期内最多进化一次
-
-### 进化回滚
-
-当进化变更导致以下任一情况时，**自动回滚**：
-
-- 基准案例通过率下降
-- Layer 1 通过率下降 ≥ 10%
-- 出现新的宪法违规
-- 人工标记"进化退化"
-
-回滚粒度：单个变更（不是整个进化周期）。通过git commit history实现。
-
-### 进化审计
-
-所有进化变更记录到 `.autospec/evolution/evolution-log.json`：
-
-```json
-{
-  "zone": "free",
-  "target": "skills/domain/api-design.md",
-  "action": "create",
-  "trigger": "practice-log/003",
-  "evidence": ["practice-log/003", "practice-log/005"],
-  "metrics_before": { "layer2_pass_rate": 0.75 },
-  "metrics_after": { "layer2_pass_rate": 0.85 },
-  "status": "accepted",
-  "rollback_commit": "abc1234"
-}
-```
-

package/knowledge/process/01-requirement.md

@@ -1,113 +0,0 @@
-# 需求分析
-
-## 目标
-将原始需求转化为结构化、无歧义、可实现的需求文档。
-
-## 输入
-原始需求（口头描述、文字记录、issue、用户反馈等）。
-
-## 核心动作
-1. 理解原始需求的背景和目的（为什么要做）
-2. 拆解为具体的功能点和非功能需求
-3. 识别模糊点，生成澄清问题
-4. 确认需求边界（做什么、不做什么）
-5. 评估可行性和依赖关系
-6. 排定优先级
-
-## 输出
-结构化需求文档，包含：
-- 需求背景与目的
-- 功能需求列表（含优先级）
-- 非功能需求（性能、安全、兼容性等）
-- 验收标准（每条功能需求对应至少一条）
-- 依赖和约束
-- 不做的事项（明确排除）
-- **关键假设清单**（已确认 / 待确认）
-- **证据清单**（支撑需求合理性的依据）
-
-## 团队对抗审查
-
-### 触发机制
-需求分析开始前，先执行复杂度评估（参考 `skills/support/complexity-assessor.md`）：
-
-| 复杂度级别 | 参与角色 | 说明 |
-|------------|----------|------|
-| 简单（≤5分） | CEO、产品负责人 | 快速通道 |
-| 中等（6-8分） | CEO、产品负责人、技术负责人 | 引入技术视角 |
-| 复杂（≥9分） | CEO、产品负责人、技术负责人、相关工程师 | 完整团队 |
-
-### 强制触发规则
-以下场景强制引入特定角色（不受复杂度影响）：
-- 涉及用户数据 → 安全工程师
-- 涉及支付/资金交易 → 安全工程师
-- 跨系统变更 → 技术负责人、运维工程师
-
-### 对抗审查流程
-1. **并行启动角色Agent**：每个角色独立审查（信息隔离）
-2. **各角色关注点**：
-   - CEO：战略一致性、商业价值、风险把控
-   - 产品负责人：用户价值、MVP范围、验收标准
-   - 技术负责人：技术可行性、技术风险
-   - 安全工程师：数据安全、合规要求（如触发）
-3. **汇总意见**：生成团队对抗审查报告
-4. **处理分歧**：
-   - 一致通过 → 进入需求文档生成
-   - 有分歧 → 标记NEEDS CLARIFICATION，交互模式等待用户决策
-   - 有重大问题 → 返回修正
-
-### 与现有流程的关系
-- 团队对抗审查在 Layer 2 之前执行
-- 团队对抗审查不通过 → 不进入 Layer 2
-- 简单任务可跳过团队对抗审查，直接使用 requirement-reviewer
-
-## 质量关卡
-
-### Layer 1: 确定性验证
-- [ ] 需求文档符合规定的schema格式（可自动校验）
-- [ ] 每条功能需求有对应的验收标准（结构完整性检查）
-- [ ] 无空字段或占位符
-
-### Layer 2: AI审查（requirement-reviewer执行）
-必须满足：
-- [ ] 每条功能需求都有明确的验收标准（参考 methodology/checklists/requirement.md）
-- [ ] 无歧义：不同人读到的理解一致
-- [ ] 可实现：技术上可行，资源上可承受
-- [ ] 边界清晰：明确列出不做的事项
-- [ ] 需求间无矛盾
-
-建议满足：
-- [ ] 有用户场景/用户故事描述
-- [ ] 标注了与现有功能的关联和影响
-- [ ] 考虑了向后兼容性
-
-输出格式：通过/不通过 + 逐项判定 + 证据 + 修复建议
-
-## 关键假设
-本阶段典型假设：
-- 用户群体和使用场景的假设
-- 技术可行性的假设
-- 与现有系统兼容性的假设
-
-规则：待确认假设超过3个 → 升级人工确认。
-
-## AI自主决策边界
-| 决策类型 | 处理方式 |
-|---------|---------|
-| 需求方向和范围 | **必须人工确认** |
-| 优先级排序（涉及业务判断） | **必须人工确认** |
-| 需求拆解的粒度 | AI自主 |
-| 验收标准的措辞 | AI自主 |
-| 格式和结构组织 | AI自主 |
-| 不确定的功能点 | AI做合理默认+标记NEEDS CLARIFICATION（最多3个） |
-
-## 反模式清单
-1. **需求镀金**：加入不必要的功能。检测：每条功能回溯到原始诉求，无法回溯的删除
-2. **隐含需求遗漏**：用户没说但理应包含的。检测：用checklist逐项检查非功能需求
-3. **边界模糊**：什么算做完没说清。检测：强制填写验收标准和排除项
-4. **假设隐藏**：假设了某些条件但未显式记录。检测：强制填写关键假设清单
-5. **过度澄清**：无限追问延迟推进。检测：最多3个NEEDS CLARIFICATION，其余做合理默认
-
-## 常见问题
-- **需求镀金**：加入不必要的功能。应对：严格对照原始需求，每条功能都要回溯到原始诉求
-- **隐含需求遗漏**：用户没说但理应包含的。应对：用checklist逐项检查非功能需求
-- **边界模糊**：什么算做完没说清。应对：强制填写验收标准和排除项