yanxulong/AIEC_Skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

20260109

Browse Source
This commit is contained in:
闫旭隆
2026-01-09 11:22:42 +08:00
parent f4314c3ede
commit 202d1cb5ba
1066 changed files with 179639 additions and 7618 deletions
Download Patch File Download Diff File Expand all files Collapse all files

202
.claude/skills/requirement-generator-v1/开发文档.md
View File

@ -6,7 +6,7 @@
1. **动态适应用户能力**: 业务语言优先，通过观察用户回答动态评估其技术深度，切换语言风格
2. **允许用户中途介入**：允许用户中途完全介入，及时修正
3. **多专家博弈评审**：4位专家独立评审 + 两轮交叉博弈，通过观点碰撞提升评审质量
3. **多专家独立评审**：4位专家从不同视角独立评审，确保需求覆盖全面
4. **用户需求基准原则**：以用户原始需求为最高准则，专家建议不可违背用户核心需求
5. **最终校验确保质量**：确保最终的需求文档以客观、陈述性输出，前后逻辑闭环，无明显矛盾
@ -37,21 +37,7 @@ flowchart TB
H --> I4[领域专家]
end
subgraph Debate1["博弈-评价阶段"]
I2 & I3 & I4 --> J1[开发专家评价]
I1 & I3 & I4 --> J2[产品经理评价]
I1 & I2 & I4 --> J3[AI专家评价]
I1 & I2 & I3 --> J4[领域专家评价]
end
subgraph Debate2["博弈-回应阶段"]
J2 & J3 & J4 --> K1[开发专家回应]
J1 & J3 & J4 --> K2[产品经理回应]
J1 & J2 & J4 --> K3[AI专家回应]
J1 & J2 & J3 --> K4[领域专家回应]
end
K1 & K2 & K3 & K4 --> L{决策模式}
I1 & I2 & I3 & I4 --> L{决策模式}
L -->|用户确认| M1[req_consolidator]
L -->|自动应用| M2[req_auto_consolidator]
M1 & M2 --> N[requirement_final.md]
@ -92,78 +78,28 @@ flowchart TB
| AI专家 | `temp/review_ai.json` | 智能化需求合理性、AI能力边界 |
| 领域专家 | `temp/review_domain.json` | 领域合规性、行业规范、特殊要求 |
#### 6.3 博弈-评价阶段：交叉评价（并行）
每位专家阅读其他3位专家的评审结果，对有冲突、不合理或需要补充的观点进行评价：
| 专家 | 读取文件 | 输出文件 |
|------|----------|----------|
| 开发专家 | review_pm/ai/domain.json | `temp/evaluate_dev.json` |
| 产品经理 | review_dev/ai/domain.json | `temp/evaluate_pm.json` |
| AI专家 | review_dev/pm/domain.json | `temp/evaluate_ai.json` |
| 领域专家 | review_dev/pm/ai.json | `temp/evaluate_domain.json` |
**评价输出格式**（必须包含目标定位）：
```json
{
"responses": [
{
"target_expert": "产品经理",
"target_file": "temp/review_pm.json",
"target_location": "issues[2]",
"target_content": "对方观点摘要",
"my_comment": "我的评价",
"reasoning": "专业理由"
}
]
}
```
#### 6.4 博弈-回应阶段：交叉回应（并行）
每位专家只读取针对自己的评价，决定是否修正原始观点，确定最终立场：
| 专家 | 读取内容 | 输出文件 |
|------|----------|----------|
| 开发专家 | evaluate_*.json 中 target_expert="开发专家" | `temp/response_dev.json` |
| 产品经理 | evaluate_*.json 中 target_expert="产品经理" | `temp/response_pm.json` |
| AI专家 | evaluate_*.json 中 target_expert="AI专家" | `temp/response_ai.json` |
| 领域专家 | evaluate_*.json 中 target_expert="领域专家" | `temp/response_domain.json` |
**回应输出包含**：
- `final_issues`: 最终问题列表（含 consensus_level: unanimous/majority/contested）
- `withdrawn_issues`: 被说服后撤回的问题
- `new_issues_from_debate`: 博弈中新发现的问题
#### 6.5 决策模式选择
#### 6.3 决策模式选择
询问用户选择处理方式：
- **用户确认模式**: 调用 `req_consolidator`，逐项与用户确认
- **自动应用模式**: 调用 `req_auto_consolidator`，自动评估并应用
#### 6.6 汇总整合
#### 6.4 汇总整合
汇总Agent读取 **14个文件**：
汇总Agent读取文件：
| 类别 | 文件 | 数量 |
|------|------|------|
| 用户需求基准 | `temp/interview_result.json` | 1 |
| 原始需求文档 | `requirement.md` | 1 |
| 初始评审 | `temp/review_*.json` | 4 |
| 交叉评价 | `temp/evaluate_*.json` | 4 |
| 交叉回应 | `temp/response_*.json` | 4 |
| 评审结果 | `temp/review_*.json` | 4 |
**合并决策规则**：
1. **可以采纳**: 优化补充用户需求、细化实现细节的建议
2. **谨慎采纳**: 与用户需求有出入但专家一致认同的建议
3. **禁止采纳**: 完全背离用户原始需求的建议（即使专家全员同意）
**共识度处理**：
- `unanimous`（全员一致）: 自动采纳
- `majority`（多数同意）: 自动采纳
- `contested`（存在争议）: 按裁决规则处理或询问用户
#### 6.7 质量审查
#### 6.5 质量审查
调用 `review_report` 检查最终文档：
- 文档结构是否符合模板（不能有多余章节）
@ -172,58 +108,6 @@ flowchart TB
- 闭环性（功能描述完整）
- 业务完整性（无"待确认"的业务问题）
## 专家博弈流程图
```mermaid
sequenceDiagram
participant Main as 主窗口
participant Dev as 开发专家
participant PM as 产品经理
participant AI as AI专家
participant Domain as 领域专家
participant Consolidator as 汇总Agent
Note over Main: 阶段6.2 独立评审
par 并行评审
Main->>Dev: mode: review
Main->>PM: mode: review
Main->>AI: mode: review
Main->>Domain: mode: review
end
Dev-->>Main: review_dev.json
PM-->>Main: review_pm.json
AI-->>Main: review_ai.json
Domain-->>Main: review_domain.json
Note over Main: 阶段6.3 博弈-评价阶段
par 并行评价
Main->>Dev: mode: evaluate
Main->>PM: mode: evaluate
Main->>AI: mode: evaluate
Main->>Domain: mode: evaluate
end
Dev-->>Main: evaluate_dev.json
PM-->>Main: evaluate_pm.json
AI-->>Main: evaluate_ai.json
Domain-->>Main: evaluate_domain.json
Note over Main: 阶段6.4 博弈-回应阶段
par 并行回应
Main->>Dev: mode: respond
Main->>PM: mode: respond
Main->>AI: mode: respond
Main->>Domain: mode: respond
end
Dev-->>Main: response_dev.json
PM-->>Main: response_pm.json
AI-->>Main: response_ai.json
Domain-->>Main: response_domain.json
Note over Main: 阶段6.6 汇总整合
Main->>Consolidator: 整合14个文件
Consolidator-->>Main: requirement_final.md
```
## Agent 协作架构
### 需求生成 Agents (阶段1-4)
@ -236,15 +120,15 @@ sequenceDiagram
### 评审 Agents (阶段6)
| Agent | 视角 | 重点 | 工作模式 |
|-------|------|------|----------|
| **dev_expert_reviewer** | 技术 | 可行性、架构、性能、风险 | review/evaluate/respond |
| **pm_reviewer** | 业务 | 目标、价值、场景、验收标准 | review/evaluate/respond |
| **ai_expert_reviewer** | 智能化 | AI能力边界、智能化合理性 | review/evaluate/respond |
| **domain_expert_reviewer** | 领域 | 合规性、行业规范、特殊要求 | review/evaluate/respond |
| **req_consolidator** | 整合 | 用户确认模式，多轮交互 | - |
| **req_auto_consolidator** | 整合 | 自动评估模式，无用户交互 | - |
| **review_report** | 质量 | 客观性、逻辑严谨性、业务完整性 | - |
| Agent | 视角 | 重点 |
|-------|------|------|
| **dev_expert_reviewer** | 技术 | 可行性、架构、性能、风险 |
| **pm_reviewer** | 业务 | 目标、价值、场景、验收标准 |
| **ai_expert_reviewer** | 智能化 | AI能力边界、智能化合理性 |
| **domain_expert_reviewer** | 领域 | 合规性、行业规范、特殊要求 |
| **req_consolidator** | 整合 | 用户确认模式，多轮交互 |
| **req_auto_consolidator** | 整合 | 自动评估模式，无用户交互 |
| **review_report** | 质量 | 客观性、逻辑严谨性、业务完整性 |
## 目录结构
@ -279,18 +163,10 @@ requirement-generator-v1/
temp/ (运行时生成)
├── interview_result.json # 访谈结果
├── domain_role.md # 领域专家角色定义
├── review_dev.json # 开发专家初始评审
├── review_pm.json # 产品经理初始评审
├── review_ai.json # AI专家初始评审
├── review_domain.json # 领域专家初始评审
├── evaluate_dev.json # 开发专家交叉评价
├── evaluate_pm.json # 产品经理交叉评价
├── evaluate_ai.json # AI专家交叉评价
├── evaluate_domain.json # 领域专家交叉评价
├── response_dev.json # 开发专家交叉回应
├── response_pm.json # 产品经理交叉回应
├── response_ai.json # AI专家交叉回应
├── response_domain.json # 领域专家交叉回应
├── review_dev.json # 开发专家评审
├── review_pm.json # 产品经理评审
├── review_ai.json # AI专家评审
├── review_domain.json # 领域专家评审
└── consolidation_report.json # 汇总应用记录（自动模式）
```
@ -300,26 +176,24 @@ temp/ (运行时生成)
| 传递方向 | 策略 | 说明 |
|----------|------|------|
| 主窗口 → Agent | 标识符/模式 | 仅传递 `mode: review/evaluate/respond` |
| 主窗口 → Agent | 简洁指令 | 仅传递任务描述 |
| Agent → temp/ | JSON文件 | 结构化数据存储，便于其他Agent读取 |
| Agent → 主窗口 | 概要文字 | 简洁提示，详细数据在文件中 |
| Agent → Agent | 文件路径 | 通过 `temp/*.json` 传递，主窗口不加载 |
## 关键设计决策
### 1. 专家博弈机制
### 1. 多专家独立评审
采用博弈机制提升评审质量，每轮博弈包含两个阶段：
- **评价阶段**: 专家指出其他专家观点中的问题
- **回应阶段**: 专家根据评价决定是否修正
采用4位专家（开发专家、产品经理、AI专家、领域专家）从不同视角独立评审需求文档。
**设计理由**: 单轮评审可能存在盲点，博弈过程可发现更多问题，共识度标注帮助汇总决策。
**设计理由**: 不同角色关注点不同，多视角评审可发现单一视角的盲点，确保需求覆盖全面。
### 2. 原始评审不可变
### 2. 评审结果持久化
`review_*.json` 在生成后保持不变，所有修正记录在 `response_*.json` 中。
各专家评审结果保存到 `review_*.json`，便于后续汇总和追溯。
**设计理由**: 保留完整的观点演变历史，便于追溯和审计。
**设计理由**: 结构化存储便于自动化处理，同时保留评审历史供审计。
### 3. 用户需求基准原则
@ -354,10 +228,9 @@ temp/ (运行时生成)
### 添加新评审专家
1. 在 `agents/` 目录创建新专家定义文件
2. 实现三种工作模式：review/evaluate/respond
3. 定义专家视角和评审重点
4. 更新 SKILL.md 和 phase6_review_guide.md 中的调用列表
5. 更新汇总 Agent 的文件读取列表
2. 定义专家视角和评审重点
3. 更新 SKILL.md 和 phase6_review_guide.md 中的调用列表
4. 更新汇总 Agent 的文件读取列表
## 常见场景处理
@ -374,18 +247,11 @@ temp/ (运行时生成)
2. Agent 自主决定文档结构
3. req_writer 根据 custom_sections 构建文档（不使用预定义模板）
### 专家意见严重冲突
### 专家意见存在冲突
当 `contested` 级别问题较多时：
- **用户确认模式**: 向用户展示争议双方观点，由用户决定
- **自动应用模式**: 按裁决规则处理（合规性优先 > 技术可行性优先 > 用户价值优先）
### 博弈后仍有分歧
即使博弈后仍有 `contested` 问题：
1. 汇总 Agent 根据裁决规则自动处理
2. 在 `consolidation_report.json` 中记录裁决过程
3. 用户可事后查看裁决依据
当多位专家意见不一致时：
- **用户确认模式**: 向用户展示不同观点，由用户决定
- **自动应用模式**: 按裁决规则处理（合规性优先 > 技术可行性优先 > 用户价值优先），在 `consolidation_report.json` 中记录裁决过程
---