Jury Review

动态评审团多维评分与周期迭代工作流程。根据任务自动生成适合的评审团成员，支持极端评审官加入，形成包围式评审阵势。触发词：评审团、多维评分、迭代优化、代码评审、质量评估、周期迭代、动态评审。

动态评审团多维评分系统

基于 AutoResearch 思路的智能评审框架。

核心理念

text

任务分析 → 生成评审团 → 极端挑战 → 用户选择 → 终极评审团 → 迭代优化

工作流程

Phase 1: 任务分析

分析用户任务，识别关键维度：

python

task = "创建一个高并发的 C++ HTTP 服务器"

analysis = {
    "type": "网络服务",
    "keywords": ["高并发", "HTTP", "服务器", "C++"],
    "risk_areas": ["并发安全", "内存管理", "网络协议"],
    "quality_focus": ["性能", "安全", "稳定性"]
}

Phase 2: 生成核心评审团

根据任务类型，生成"上下左右"包围阵势的核心评审团：

text

                    【上】架构官
                       ↓
【左】安全官 ←─── 核心代码 ───→ 【右】性能官
                       ↑
                    【下】测试官

核心评审团生成规则：

任务类型	核心评审团	说明
网络服务	架构官、安全官、性能官、测试官	四方包围
数据处理	数据官、性能官、安全官、文档官	数据为中心
UI/前端	美术官、体验官、性能官、兼容官	用户为中心
算法/AI	算法官、性能官、测试官、伦理官	质量为先
安全工具	安全官、渗透官、合规官、审计官	安全至上
通用代码	美术官、性能官、安全官、测试官、文档官	五官齐全

Phase 3: 极端评审团挑战

生成"极端评审官"，质疑核心评审团的盲点：

极端评审官类型：

极端评审官	职责	挑战问题
🔥 纵火官	破坏性测试	"如果故意传入恶意输入会怎样？"
🧟 僵尸官	边界极端	"如果内存只剩 1KB 怎么办？"
⏰ 时间官	时间压力	"如果要在 10ms 内完成怎么办？"
💀 死神官	失败场景	"如果这个函数崩溃了怎么办？"
🎭 骗子官	欺骗输入	"如果用户谎称输入类型怎么办？"
🌀 混沌官	随机异常	"如果网络突然断开怎么办？"
📉 吝啬官	资源极限	"如果 CPU 占用必须 < 1% 怎么办？"
🌪️ 风暴官	高压负载	"如果并发 100 万请求怎么办？"

Phase 4: 用户选择

向用户展示极端评审团，选择加入：

markdown

## 🎭 极端评审官提议

根据您的任务特点，建议考虑以下极端评审官：

| 评审官 | 挑战维度 | 推荐理由 |
|--------|----------|----------|
| 🔥 纵火官 | 破坏性测试 | 网络服务需要抵抗恶意输入 |
| 🌀 混沌官 | 异常处理 | 高并发场景网络不稳定 |
| 🌪️ 风暴官 | 极限负载 | 高并发需要压测验证 |

**请选择要加入的极端评审官：**
- [ ] 全部加入
- [ ] 选择加入（指定）
- [ ] 不加入，使用核心评审团

Phase 5: 终极评审团

组合核心 + 极端，形成本次任务的终极评审团：

markdown

## ⚔️ 终极评审团阵容

### 核心阵势

text

    【架构官】赵构
        ↓

【安全官】盾山 ─── 代码 ─── 【性能官】闪电 ↑ 【测试官】试金石

text

### 极端挑战

🔥 纵火官·焚天 | 🌀 混沌官·乱舞 | 🌪️ 风暴官·狂啸

text

共 7 位评审官，综合权重自动分配。

Phase 6: 多轮迭代

python

for iteration in range(max_iterations):
    # 1. 生成/改进代码
    code = generate_or_improve(task, previous_feedback)
    
    # 2. 核心评审团评分
    core_scores = core_jury.evaluate(code)
    
    # 3. 极端评审官挑战
    extreme_challenges = extreme_jury.challenge(code)
    
    # 4. 综合得分
    total = weighted_average(core_scores, extreme_challenges)
    
    # 5. 决策
    if total >= threshold:
        return ACCEPT, code
    elif no_improvement:
        return STAGNANT, best_code
    else:
        feedback = generate_feedback(core_scores, extreme_challenges)
        continue

评审官角色库

核心评审官

评审官	符号	维度	权重范围
🎨 美术官	🎨	代码美学	10-25%
⚡ 性能官	⚡	执行效率	10-25%
🔒 安全官	🔒	安全性	10-25%
🧪 测试官	🧪	测试质量	10-25%
📝 文档官	📝	文档完整	10-25%
🏗️ 架构官	🏗️	架构设计	10-20%
📊 数据官	📊	数据处理	10-20%
👁️ 体验官	👁️	用户体验	10-20%
⚖️ 合规官	⚖️	合规性	10-20%
🤖 算法官	🤖	算法质量	10-20%

极端评审官

评审官	符号	挑战类型	适用场景
🔥 纵火官	🔥	破坏性测试	网络、安全、输入处理
🧟 僵尸官	🧟	资源极限	嵌入式、移动端
⏰ 时间官	⏰	时间压力	实时系统、高频交易
💀 死神官	💀	失败恢复	关键系统、金融
🎭 骗子官	🎭	输入欺骗	用户输入、API
🌀 混沌官	🌀	随机异常	分布式、网络
📉 吝啬官	📉	资源极限	性能敏感
🌪️ 风暴官	🌪️	极限负载	高并发、游戏

配置参数

参数	默认值	说明
max_iterations	5	最大迭代次数
accept_threshold	80	接受阈值
min_improvement	5	最低改进分数
core_jury_size	4-5	核心评审团人数
extreme_jury_max	3	极端评审官最大数

使用示例

示例 1: 高并发服务器

text

用户: 创建一个高并发 C++ HTTP 服务器

系统分析:
- 类型: 网络服务
- 关键词: 高并发、HTTP、服务器
- 风险点: 并发安全、内存泄漏、连接管理

生成核心评审团:
        【架构官】
            ↓
【安全官】─── 代码 ───【性能官】
            ↑
        【测试官】

极端评审官提议:
- 🔥 纵火官 (恶意请求)
- 🌪️ 风暴官 (极限并发)
- 🌀 混沌官 (网络异常)

用户选择: 全部加入

终极评审团: 7 位评审官
开始多轮迭代...

示例 2: 数据处理脚本

text

用户: 写一个 Python 数据清洗脚本

系统分析:
- 类型: 数据处理
- 关键词: 数据、清洗、脚本

生成核心评审团:
        【数据官】
            ↓
【安全官】─── 代码 ───【性能官】
            ↓
        【文档官】

极端评审官提议:
- 🎭 骗子官 (脏数据)
- 💀 死神官 (数据丢失)

用户选择: 加入骗子官

终极评审团: 5 位评审官
开始多轮迭代...

反馈输出格式

markdown

## ⚔️ 第 N 轮评审

### 核心评分
| 评审官 | 分数 | 状态 | 主要问题 |
|--------|------|------|----------|
| 🏗️ 架构官 | 82 | ✅ | 模块划分清晰 |
| ⚡ 性能官 | 75 | ⚠️ | 可优化连接池 |
| 🔒 安全官 | 68 | ⚠️ | 缺少输入验证 |
| 🧪 测试官 | 60 | ⚠️ | 测试覆盖不足 |

### 极端挑战
| 评审官 | 通过 | 挑战结果 |
|--------|------|----------|
| 🔥 纵火官 | ❌ | 恶意请求导致崩溃 |
| 🌪️ 风暴官 | ⚠️ | 10K 并发延迟增加 |

**综合得分: 71.2 分**
**状态: 继续迭代**

### 改进建议
1. [安全] 添加请求头验证
2. [测试] 添加并发测试用例
3. [极限] 增加请求速率限制

注意事项

• 极端评审官数量适中，避免过度惩罚
• 每轮迭代要有明确改进目标
• 迭代停滞时及时终止
• 记录评审历史用于分析优化