### 极端挑战

动态评审团多维评分系统

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

核心理念

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

工作流程

Phase 1: 任务分析

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

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

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

Phase 2: 生成核心评审团

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

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

核心评审团生成规则：

任务类型	核心评审团	说明
网络服务	架构官、安全官、性能官、测试官	四方包围
数据处理

数据官、性能官、安全官、文档官 | 数据为中心 |
| UI/前端 | 美术官、体验官、性能官、兼容官 | 用户为中心 |
| 算法/AI | 算法官、性能官、测试官、伦理官 | 质量为先 |
| 安全工具 | 安全官、渗透官、合规官、审计官 | 安全至上 |
| 通用代码 | 美术官、性能官、安全官、测试官、文档官 | 五官齐全 |

Phase 3: 极端评审团挑战

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

极端评审官类型：

极端评审官	职责	挑战问题
🔥 纵火官	破坏性测试	如果故意传入恶意输入会怎样？
🧟 僵尸官

边界极端 | 如果内存只剩 1KB 怎么办？ |
| ⏰ 时间官 | 时间压力 | 如果要在 10ms 内完成怎么办？ |
| 💀 死神官 | 失败场景 | 如果这个函数崩溃了怎么办？ |
| 🎭 骗子官 | 欺骗输入 | 如果用户谎称输入类型怎么办？ |
| 🌀 混沌官 | 随机异常 | 如果网络突然断开怎么办？ |
| 📉 吝啬官 | 资源极限 | 如果 CPU 占用必须 < 1% 怎么办？ |
| 🌪️ 风暴官 | 高压负载 | 如果并发 100 万请求怎么办？ |

Phase 4: 用户选择

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

markdown

🎭 极端评审官提议

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

评审官	挑战维度	推荐理由
🔥 纵火官	破坏性测试	网络服务需要抵抗恶意输入
🌀 混沌官

异常处理 | 高并发场景网络不稳定 |
| 🌪️ 风暴官 | 极限负载 | 高并发需要压测验证 |

请选择要加入的极端评审官：

• - [ ] 全部加入
• [ ] 选择加入（指定）
• [ ] 不加入，使用核心评审团

Phase 5: 终极评审团

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

markdown

⚔️ 终极评审团阵容

核心阵势

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

极端挑战

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

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

Phase 6: 多轮迭代

python
for iteration in range(max_iterations):
# 1. 生成/改进代码
code = generateorimprove(task, previous_feedback)

# 2. 核心评审团评分
corescores = corejury.evaluate(code)

# 3. 极端评审官挑战
extremechallenges = extremejury.challenge(code)

# 4. 综合得分
total = weightedaverage(corescores, extreme_challenges)

# 5. 决策
if total >= threshold:
return ACCEPT, code
elif no_improvement:
return STAGNANT, best_code
else:
feedback = generatefeedback(corescores, extreme_challenges)
continue

评审官角色库

核心评审官

评审官	符号	维度	权重范围
🎨 美术官	🎨	代码美学	10-25%
⚡ 性能官

⚡ | 执行效率 | 10-25% | | 🔒 安全官 | 🔒 | 安全性 | 10-25% | | 🧪 测试官 | 🧪 | 测试质量 | 10-25% | | 📝 文档官 | 📝 | 文档完整 | 10-25% | | 🏗️ 架构官 | 🏗️ | 架构设计 | 10-20% | | 📊 数据官 | 📊 | 数据处理 | 10-20% | | 👁️ 体验官 | 👁️ | 用户体验 | 10-20% | | ⚖️ 合规官 | ⚖️ | 合规性 | 10-20% | | 🤖 算法官 | 🤖 | 算法质量 | 10-20% |

极端评审官

评审官	符号	挑战类型	适用场景
🔥 纵火官	🔥	破坏性测试	网络、安全、输入处理
🧟 僵尸官

🧟 | 资源极限 | 嵌入式、移动端 | | ⏰ 时间官 | ⏰ | 时间压力 | 实时系统、高频交易 | | 💀 死神官 | 💀 | 失败恢复 | 关键系统、金融 | | 🎭 骗子官 | 🎭 | 输入欺骗 | 用户输入、API | | 🌀 混沌官 | 🌀 | 随机异常 | 分布式、网络 | | 📉 吝啬官 | 📉 | 资源极限 | 性能敏感 | | 🌪️ 风暴官 | 🌪️ | 极限负载 | 高并发、游戏 |

配置参数

参数	默认值	说明
maxiterations	5	最大迭代次数
acceptthreshold

80 | 接受阈值 | | min_improvement | 5 | 最低改进分数 | | corejurysize | 4-5 | 核心评审团人数 | | extremejurymax | 3 | 极端评审官最大数 |

使用示例

示例 1: 高并发服务器

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

系统分析:

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

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

极端评审官提议:

• - 🔥 纵火官 (恶意请求)
• 🌪️ 风暴官 (极限并发)
• 🌀 混沌官 (网络异常)

用户选择: 全部加入

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

示例 2: 数据处理脚本

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

系统分析:

• - 类型: 数据处理
• 关键词: 数据、清洗、脚本

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

极端评审官提议:

• - 🎭 骗子官 (脏数据)
• 💀 死神官 (数据丢失)

用户选择: 加入骗子官

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

反馈输出格式

markdown

⚔️ 第 N 轮评审

###