⚡

测试厨房评委 judge

这是一个用于编程竞赛或代码评审的自动化评分框架，名为“测试厨房评委”。它通过一套结构化的5项标准（目标契合度、合理复杂度、可读性、健壮性与扩展性、可维护性）对不同的代码实现方案进行系统化评估和打分。该技能适用于“烹饪大赛”（相同设计的不同实现）和“Omakase挑战”（不同设计方法）两种场景，旨在客观、高效地评选出最佳代码实现。关键词：代码评审，编程竞赛，评分框架，软件质量，实现评估，自动化评分，代码规范，最佳实践。

测试 0 次安装 0 次浏览 更新于 2/28/2026

name: judge description: 测试厨房烹饪大赛和Omakase挑战的评分框架。在第四阶段调用，使用5项标准对实现方案进行评分。请勿直接调用 - 由cookoff/omakase-off调用。

测试厨房评委

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

术语说明： 本技能使用“impl”，但适用于以下两种情况：

  • 烹饪大赛：impl-1, impl-2, impl-3 (相同设计，不同实现)
  • Omakase挑战：variant-a, variant-b (不同方法/设计)

必填输出格式

您必须生成完全相同的结构。不要总结或缩写。

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

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

## 评分工作表

### impl-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)

### impl-2
[重复相同格式]

### impl-3 (如适用)
[重复相同格式]

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

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

## 优胜者选择
**优胜者：impl-X** (得分：__/25)

**选择理由：**
[2-3句话解释为什么这个实现获胜]

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

评分参考

分数含义

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

硬性门槛（自动）

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

目标契合度门槛解读

该门槛在两种情况下触发方式相同，但含义不同：

场景 目标契合度差值 Δ ≥ 2 的含义
烹饪大赛 某个实现偏离或误解了设计。所有实现的目标契合度应该相似，因为它们实现的是相同的规范。巨大的差距是一个危险信号。
Omakase挑战 某种方法确实能更好地解决问题。不同的方法在目标契合度上存在合理差异。巨大的差距意味着某种方法明显更优。

在两种情况下，目标契合度更高的实现获胜。解读只是解释了为什么存在差距。

可行性危险信号

评分前检查：

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

流程

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

关键： 仅使用整数分数 (1-5)。不要使用像4.5这样的半分。

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