---

name: judge description: 测试厨房烹饪大赛和主厨精选赛的评分框架。在第4阶段调用，使用5项标准对实现方案进行评分。不要直接调用 - 由烹饪大赛/主厨精选赛调用。

测试厨房评委

使用5项标准框架对实现方案进行评分。严格按照所示格式填写所有部分。

术语说明： 本技能使用“实现方案”一词，但适用于两种情况：

• 烹饪大赛：实现方案-1、实现方案-2、实现方案-3（相同设计，不同实现）
• 主厨精选赛：变体-A、变体-B（不同方法/设计）

必需输出格式

您必须生成此确切结构。不要总结或缩写。

## 门禁检查
| 实现方案 | 测试通过 | 设计遵循 |
|------|------------|------------------|
| 实现方案-1 | X/X ✓ 或 ✗ | 是/否 |
| 实现方案-2 | X/X ✓ 或 ✗ | 是/否 |

## 可行性检查
| 实现方案 | 状态 | 备注 |
|------|--------|-------|
| 实现方案-1 | ✓ 通过 / ⚠️ 标记 | 详情 |
| 实现方案-2 | ✓ 通过 / ⚠️ 标记 | 详情 |

## 评分工作表

### 实现方案-1
**目标契合度**（是否解决了实际问题？）

*功能需求：*
- [ ] 主要用例端到端工作？
- [ ] 所有明确声明的需求都已实现？
- [ ] 处理现实场景，而不仅仅是理想路径？

*用户需求（超出字面要求）：*
- [ ] 用户会实际使用它，还是仅用于演示？
- [ ] 它解决了真正的问题，而不仅仅是字面请求？
- [ ] 部署/分发是否符合声明的需求？

*未来考虑（如相关）：*
- [ ] 如果提到增长/扩展，架构是否支持？
- [ ] 如果提到团队/协作，其他人是否易于维护？

检查项：_/8 是 → **得分：_/5** (7-8=5, 5-6=4, 4=3, 2-3=2, 0-1=1)
*注意：并非所有项目都适用于每个项目。根据相关项目评分。*

**合理复杂度**（每一行代码都物有所值？）
- 不必要的抽象：___
- 死代码：___
- 膨胀估计：___%

*代码行数比较（如有多个实现方案）：*
- 本实现方案：___ 行
- 最小实现方案：___ 行
- 额外代码行的理由：___

→ **得分：_/5** (5=最小化, 4=轻微膨胀<10%, 3=10-25%膨胀, 2=25-50%, 1=>50%)

**可读性**（5分钟内理解核心流程？）
违规项：
- [ ] 单字母变量（非循环索引）：+1 每个 = __
- [ ] 函数>50行：+1 每个 = __
- [ ] 嵌套>3层：+1 每个 = __
- [ ] 魔数：+1 每个 = __
- [ ] 不良函数名：+1 每个 = __
总违规数：__ → **得分：_/5** (0=5, 1-2=4, 3-4=3, 5-7=2, 8+=1)

**健壮性与扩展性**（处理意外情况+增长？）
- [ ] 输入验证？
- [ ] 外部调用错误处理？
- [ ] 有用的错误消息？
- [ ] 空值/空处理？
- [ ] 异步超时？
- [ ] 无无限循环？
- [ ] O(n log n) 或更好？
- [ ] 内存有界？
- [ ] 查询分页？
- [ ] 关键路径中无阻塞I/O？
- [ ] 退避/重试逻辑？
- [ ] 处理10倍负载？
检查项：_/12 是 + 可行性标记 → **得分：_/5**
(11-12 + 无标记=5, 9-10 或 轻微标记=4, 7-8=3, 5-6 或 主要标记=2, <5 或 关键标记=1)

**可维护性**（下一次变更的痛苦程度？）
- [ ] 函数单一职责？
- [ ] 显式依赖（无全局变量）？
- [ ] 业务逻辑与基础设施分离？
- [ ] 新功能 = ≤3个文件更改？
- [ ] 配置外部化？
- [ ] 测试能捕获回归？
检查项：_/6 是 → **得分：_/5** (6=5, 5=4, 4=3, 2-3=2, 0-1=1)

### 实现方案-2
[重复相同格式]

### 实现方案-3（如适用）
[重复相同格式]

## 评委记分卡
| 标准 | 实现方案-1 | 实现方案-2 | 实现方案-3 | 最佳 |
|-----------|--------|--------|--------|------|
| 目标契合度 | | | | |
| 合理复杂度 | | | | |
| 可读性 | | | | |
| 健壮性与扩展性 | | | | |
| 可维护性 | | | | |
| **总计** | /25 | /25 | /25 | |

## 硬性门禁
| 门禁 | 结果 |
|------|--------|
| 目标契合度门禁 (Δ ≥ 2) | 触发/未触发 |
| 关键缺陷 (任何=1) | 触发/未触发 |

## 优胜者选择
**优胜者：实现方案-X** (得分：__/25)

**选择理由：**
[2-3句话解释为何此实现方案获胜]

**已确认的权衡：**
[其他实现方案做得更好的方面]

评分参考

分数含义

分数	含义
5	优秀 - 超出预期
4	良好 - 完全满足要求
3	合格 - 核心工作，存在一些差距
2	较差 - 存在显著问题
1	关键缺陷 - 取消资格

硬性门禁（自动）

1. 目标契合度门禁： 如果实现方案间目标契合度 Δ ≥ 2 → 目标契合度更高的立即获胜
2. 关键缺陷门禁： 如果任何标准 = 1 → 该实现方案被淘汰

目标契合度门禁解释

目标契合度门禁在两种上下文中触发方式相同，但含义不同：

上下文	目标契合度 Δ ≥ 2 的含义
烹饪大赛	一个实现方案偏离或误解了设计。所有实现方案的目标契合度应相似，因为它们实现的是相同的规范。巨大差距是一个危险信号。
主厨精选赛	一种方法确实更好地解决了问题。不同的方法可能合理地具有不同的目标契合度。巨大差距意味着一种方法明显更优。

在两种情况下，目标契合度更高的获胜。解释只是说明了差距存在的原因。

可行性红色标记

评分前检查：

• 无界数据上的 O(n²) 或更差
• 无界内存增长
• 自DDoS模式（轮询、无退避）
• 缺少分页
• 关键路径中的阻塞I/O
• 无错误恢复

流程

1. 阅读 所有实现方案代码（应已在上下文中）
2. 填写 每个实现方案的工作表 - 不要跳过任何部分
3. 检查 硬性门禁
4. 宣布 优胜者并给出理由

关键： 仅使用整数分数 (1-5)。不要使用半分，如 4.5。

关键： 填写每个复选框。不要总结或缩写工作表。