# MiniMax-M2.7-highspeed 主力升级门 · 评测小结

> 日期：2026-06-10 ｜ 评测工程师独立跑批 + CSV/raw 独立复算对账
> 被测修法：解析侧剥 think 防御（`orchestrator/llm_client.py::normalize_llm_json_content`，本 harness 经 import 复用，未复制实现；本机单测 9/9 绿）
> 总预算消耗：**80/90**（smoke 1 + 结构层 52 + 探针 27），零超闸

---

## 一、门判定（结论先行）

| 门条件 | 实测 | 判定 |
|---|---|---|
| A. 结构层 ≥52/52 基线持平 | **52/52 = 100%**（四模板各 13/13，零重试） | **过** |
| B. 策划探针 P0/P1 与既有两候选（各 2/13）同量级 | P0 **0/13** 持平；P1 **4/13**（基线各 2/13 的 2 倍），其中 2 条为 highspeed 特有「裸 config 漏三键包裹」契约失败诱发；schemaOk **11/13** < 基线两候选各 13/13 | **不过（缺口）** |

**最终裁决：不过门（按「任何缺口 = 留任」铁律）。**
结构层硬线过、剥 think 修复完全有效；缺口在策划位输出契约纪律，非 think 病灶本身。

---

## 二、A 结构层明细（52 次，配方=struct_eval.py 逐字复用）

- **通过率**：52/52 = 100%，与 M2.7 基线（spike-eval.csv 52/52）持平；clicker/dodge/runner/match 各 13/13。
- **think 泄漏**：**27/52（51.9%）** content 以 `<think>` 开头（概率性病灶实锤，远高于 M3 路在 probe 腿的 6/13）；**剥除后 27/27 全部救回**（泄漏抢救成功率 100%，零条因泄漏失败）——若无该修复，结构层将跌至 25/52，比 M3 出局时的 22/52 略好但同样必死。
- **时延**（最终采纳调用，n=52）：**avg 9911ms / p50 9326ms / p95 15674ms**（min 5170 / max 19360）。
  - 对照 v4-pro（avg 7591 / p50 5671 / p95 17956）：**avg 慢 30.6%、p50 慢 64%，仅 p95 尾部更优**；
  - 对照 M3（avg 10383 / p50 8921）：avg 快 4.5%、p50 反慢——**「highspeed」卖点在短 prompt 结构层不成立**；
  - M2.7 本尊无逐次时延基线（既有缺口），无法证明相对主力不劣化。
- 调用消耗 52/56，零空 content、零 HTTP 错误；config 抽查 3 例真 JSON；自报与 CSV 独立复算零出入。

## 三、B 策划探针明细（13 创意 × 各一轮，统一 M2.7 + 对抗 v1.1.1 评审）

| 指标 | m27hs | 基线 m3 | 基线 v4p | 读法 |
|---|---|---|---|---|
| P0 检出 | **0/13** | 0/13 | 0/13 | 持平 |
| P1 检出 | **4/13** | 2/13 | 2/13 | **2 倍，不同量级** |
| schemaOk | **11/13** | 13/13 | 13/13 | **新失败模式** |
| think 泄漏 | 9/13 | （6/13，M3） | 0/13 | 全部被剥 think 救回 |
| intent 均长 | 42.8 | 42.8 | 42.3 | 持平 |
| 生成均时延 | **15240ms** | 24584ms | 22703ms | 长 prompt 下反而最快 |

- **P1 归因（关键）**：#07「海底捞珍珠」（kill 守卫 k-0cfbc296 同源锚点，两基线候选同位命中）与 #08「烧烤摊烤糊机制缺失」为真实内容质量 P1 —— **内容质量面 2/13 与基线同量级**；#01/#02 的 P1 由「模型只输出裸 GameConfig、漏 `{designIntent, expectedPlaySeconds, config}` 三键包裹」直接诱发（config=null/designIntent=null），**该契约失败模式两基线候选 0 发生**。
- think 文本里明明推理过 designIntent 却没包进输出（gen-01 raw 可证）——是输出纪律问题，非能力问题；但主力位以契约论。
- #05 曾出现 reasoning 吃光 4096 额度（finish=length、reasoning_tokens=4096、`</think>` 后零负载）：属通道公平性问题（m3/v4p 的 reasoning 走 reasoning_content 字段、content 真空会享提额重试，highspeed 混进 content 绕过判定），已修 harness 判定（think-only 等同空 content）并重测——重测一发过 schema、评审 0 findings。重测全程入台账（calls.jsonl），其余 12 条 raw 复用未动。

## 四、剥 think 修复结论（独立于门判定）

- **修复有效且必要**：本轮 36 处泄漏（结构层 27 + 探针 9）全部救回，**剥除成功率 36/36 = 100%**；评估矩阵前置的「解锁 M3 类模型」目标达成（M3 复测前置条件已满足）。
- 修复对纯净通道零扰动（归一化改写仅发生在泄漏条目，27/52 与泄漏数严格相等）。

## 五、若要转正的待补清单

1. **三键包裹契约失败（2/13）**：在策划 prompt 显式强化输出形状约束（或 run_batch schema 重出回炉实测回收率）后重测探针；
2. **时延**：补 M2.7 本尊同口径 52 次时延基线，才能判「不劣化」；highspeed 在结构层短 prompt 比 v4-pro 慢 30%，但长 prompt（策划位）比两候选快 33-38%——选型应按工位分别裁决；
3. reasoning 吃光额度为概率性（1/14 次生成调用），建议生产侧固化「think-only 等同空 content 提额重试」判定（本轮 harness 修法可平移 ExecutorLlmClient/llm_client）。

## 六、产物索引（均在本目录）

| 产物 | 说明 |
|---|---|
| `struct_eval_m27hs.py` | 结构层 harness（import struct_eval 基线配方 + import llm_client 剥 think） |
| `struct-m27hs.csv` / `struct-m27hs-run.log` / `raw-struct/`（52 文件） | 结构层 52 行明细 / 运行日志 / 原始响应全量 |
| `designer_probe_m27hs.py` | 探针 harness（含 think-only 公平性修法，差异注释在文件头） |
| `designer-probe-m27hs-results.json` / `-calls.jsonl` / `-run.log` / `-rerun05.log` / `raw-designer-probe/`（26 文件） | 探针结果 / 调用台账 / 首轮与 #05 重测日志 / 原始响应全量 |

caveats：① 探针样本仍仅 clicker 单模板 13 创意（与基线探针同限制）；② 两基线候选 P1 2/13 为同口径（对抗 v1.1.1 + M2.7 评审）可直比；③ #05 重测系通道公平性补测非质量重 roll，台账可审计；④ acceptable 列留空待创始人盲评（沿基线惯例）。