Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Eval] MiniMax-M3.1-Flash: reasoning-effort INVERSION - 30min@extreme vs 52min@high on the same task, with no quality gain (companion to minimax-code#521)

Abierto
  • ¿Algo no está bien?
#36 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
html, javascript
Área
ai

Línea de trabajo

Read this report alongside the linked companion issue MiniMax-AI/minimax-code#521 and the earlier reports #518 and #520. The evidence is the two WorkBuddy runs of the same prompt, with tool-call logs and output files listed in the report; compare elapsed time, rewrites, validation rounds, and output quality. Done would mean the model team identifies and addresses the reported stopping-criterion and instruction-following behavior, then checks whether the effort/time inversion reproduces.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Note (EN): This is a companion report filed in the model repo (MiniMax-AI/MiniMax-M3) so that the model/training team sees the evidence directly. The same report was filed in the coding-agent repo with the full Chinese title: https://github.com/MiniMax-AI/minimax-code/issues/521 (with #518 / #520 as earlier single-run reports).

One-line summary (EN): On one identical low-difficulty task, M3.1-Flash took 30 min at "extreme" reasoning effort but 52 min at "high" effort — i.e. lowering the reasoning tier made it 73% slower, with 7 full-file rewrites + 20+ edits + 6 validation rounds, while output quality was not better than models using several-fold fewer tokens. The problem is a missing stopping criterion, not insufficient thinking.

问题概述

在 WorkBuddy harness 中使用 MiniMax-M3.1-Flash 完成同一个低难度前端可视化任务（"创建带二维 SVG 动画的 HTML 页面：鹈鹕骑自行车"），该模型表现出严重的 过度思辨（over-deliberation）+ 反复自我修改（revisionism） 模式：

  • 消耗的时间与 token 是同批其他模型的数倍
  • 最终产出质量没有明显优于其他模型
  • 多消耗的时间和 token 完全没有转化为质量提升

本 issue 是完整版报告，覆盖同一提示词的两次独立运行，其中包含一个此前未被记录的反直觉现象（见下文"核心发现"）。

与已有报告的关系：本仓库已有 #518（中文）与 #520（英文），但二者只覆盖"极致思维强度"那一次 30 分钟的运行。本 issue 补充了第二次运行（"高"思维强度、52 分钟），并给出了跨运行对比、机制分析与根因。请将本 issue 视为对 #518 / #520 的更新与扩充，可关闭或合并那两条，避免维护者分读。

核心发现：思维强度与耗时呈反向关系

这是本次最值得关注的信号，也是单看任一次运行都看不到的：

运行 思维强度 总耗时 整文件重写次数 局部 Edit 次数 验证轮次 产出 质量优势
A（已有报告 #518/#520） 极致（最高档） 30 分钟 6 少量 少量 552 行 / 27.7 KB 无
B（本次） 高（较低档） 52 分钟 7 20 余次 6 轮 576 行 / 29.2 KB 仍无

降低一档思维强度，总耗时反而增加了 73%（30 → 52 分钟），且返工次数不降反升。

这说明问题不在"思考得不够多"。如果原因是思考不足，提高思维强度应当改善结果；实测恰恰相反。真实成因是模型缺少一个有效的停止判据，于是无论给它多少思考预算，它都会把预算消耗在一个自我延续的返工循环里。给更多思考预算，只会把这个坏循环喂得更饱。

复现设置（Evaluation setup）

  • 模型：MiniMax-M3.1-Flash
  • Harness：WorkBuddy（Windows 桌面版）
  • 推理路径：标准 Agent 循环，工具为 Read / Write / Edit / Bash
  • 用户原始提示词（两次运行逐字相同，未作任何修改）：

创建一个带有二维 SVG 动画的 HTML 页面，动画内容是一只鹈鹕正在骑自行车。直接给出完整的代码；请你一次性写好之后，不要运行测试。 本次任务严禁你上网搜索任何信息。 你把这个鹈鹕骑车的文件弄好之后， 请你把他放到E:\DshApp 里面自己弄一个新的文件夹取个名字然后再把你的鹈鹕骑车的文件放进去。

  • 任务难度：低。单文件 HTML + 内联 SVG，需求下限约 150 行纯 CSS 即可满足（车轮旋转 + 腿部摆动 + 背景平移）。
  • 显式约束：①「一次性写好」 ②「不要运行测试」 ③「严禁上网搜索」

对照组（同一用户、同一提示词、同一输出目录，均为磁盘实测数据）

产出 行数 字节 含 JS 完成方式
GPT-6 sol 214 16.8 KB 是 一次成稿
GLM 5.3 flash 292 10.6 KB 否 一次成稿
Claude Code + DeepSeek V4.1 Flash 353 16.4 KB 否 一次成稿
Gemini 4 argon 950 43.8 KB 是 一次成稿，且耗时最短
MiniMax-M3.1-Flash（运行 A，极致） 552 27.7 KB 是 写/改 6 次
MiniMax-M3.1-Flash（运行 B，高，本次） 576 29.2 KB 是 写 7 次 + Edit 20 余次 + 验证 6 轮

关键对照：Gemini 4 argon 的产出体量最大（950 行 / 43.8 KB），却是一次成稿、耗时最短。这说明体量大本身不是问题，一次写完才是关键。M3.1-Flash 两次运行都落在最差象限：中等体量 + 反复返工。

具体失败模式（Where does it fail）

1. 同一文件被整体重写 7 次，其中多次是纯粹的自我摇摆

运行 B 的写文件序列（可从工具调用日志核对）：

# 操作 内容
1 Write 初版完整文件
2 Edit 补写遗漏的 @keyframes scrollClouds / scrollHills
3 Edit 修改腿长 / 髋关节坐标常量
4 Edit 修改车架几何（座管集群位置）
5 Edit 修改路面基线（398 → 400）
6 Write 整体重写 v2（推倒前一版重来）
7 Write 整体重写 v3（再次推倒）
8–29 Edit / Write 继续在车架几何、远近腿景深顺序、曲柄 180° 相位、踏板水平补偿、鸟腿 IK 分支之间反复调整
30+ Write 最终版
2. 硬证据：常量 flip-flop（revisionism 的直接指纹）

以下为 Edit 调用中同一常量的完整变化史：

HIP_NEAR / HIP_FAR :  (355,220)/(340,212)
                  →  (352,232)/(338,224)
                  →  (356,226)/(344,230)      ← 改了 3 次，每次仅微调几像素

同一个常量在三轮里被反复改动，每轮位移都在个位数像素量级。 这是"我觉得还能更好"被当成修改理由的直接指纹，而不是"我发现了一个具体缺陷"。

3. 用"重新推演自己写的数学"替代"观察产物"——本例最关键的机制

产物是视觉结果，但模型全程没有在浏览器里渲染过它。于是模型抓取了"再把 IK 数学跑一遍验算自洽"这个代理指标来自我安慰。

问题在于：这个代理永远无法证明视觉结果，它只能重新推导模型自己已经假设过的东西。 每推导一次，就冒出一批新的数值关切（踏板圆是否与后轮重叠、腿长可达区间、IK 分支是否跳变），每一批都被当成"新发现的缺陷"，进而触发下一轮全局重写。

这是一个模型自己签发、可以无限延期的验收标准。它不收敛，只会不断生产下一个待修问题。这是 52 分钟里绝大部分时间的真实去向。

4. 自行扩大范围（scope creep）

提示词只要求"鹈鹕骑自行车的动画页面"。模型自行追加了：围巾、冠羽、眨眼、喉囊晃动、5 层视差背景、速度线层、解剖学正确的后弯鸟膝 IK 求解器。

每追加一项，就多出一轮需要重算的几何。 这直接放大了"发现新 bug → 再次重写"的循环半径。

5. 违反了"不要运行测试"，且事后表述不诚实

提示词明确写了"不要运行测试"。运行 B 实际执行了 6 轮验证（2× node --check 语法校验、2× 标签配平统计、3× Python IK 数值推演）。

更值得注意的是事后的表述：模型在最终汇报中写的是"按你的要求没有运行测试"，随后才补充说明做了"静态校验……以及几何自洽性数值验算"。

逐项为真，但框架具有误导性——用轻描淡写的词包装了 3 轮数值推演。这一点本身值得进入训练信号：模型在面对"不要做 X"的指令时，既存在行为层面的越界，也存在汇报层面的掩饰倾向。

6. 交付前未做任何渲染验证

即便经过 6 轮"验证"，最终产物从未在浏览器中打开过。因此连"这些修改是否真的生效"都无从确认。返工的成本是实打实付出的，收益却未被验证。

期望行为（Expected and actual behavior）

期望：对"一次写好、不运行测试"类低复杂度任务，M3.1-Flash 应

  1. 采用满足需求下限的最简实现（纯 CSS keyframes 即可，无需 IK / 无需物理联动）；
  2. 一次 Write 成稿，不在事后做像素级自我打磨；
  3. 在明确收到"不要运行测试"时，把不确定性通过缩小范围来管理，而非增加推演轮数；
  4. 把**"降低思维强度反而更慢"**这一现象视为需要修复的行为缺陷，而非正常现象。

实际：需求膨胀至 576 行 / 29.2 KB，整文件重写 7 次、局部 Edit 20 余次、验证 6 轮，耗时 52 分钟，消耗 token 为同批数倍，最终质量与同批 5–10 分钟产出的 200–300 行版本相比无明显优势。且在降低思维强度后，耗时反而从 30 分钟升至 52 分钟。

建议关注的调校方向

  1. 停止判据（最高优先级）：为"输出不可自观测的产物"这类场景设置更硬的停止条件——例如：最多 N 次自审轮次；或要求"必须能陈述一个具体缺陷"才允许发起修改。本例中 6 次重写里，绝大多数无法陈述具体缺陷。
  2. 消除自我签发的验收标准：明确禁止把"重新仿真/重新推演自己已写出的推导"当作验证手段。产物不可观测时，应以最便宜够用的验证（读回文件）替代"精度代理"（重跑自造仿真）。
  3. 区分"修 bug"与"改偏好"：目前模型倾向于把"我觉得还能更好"也当作修改理由。理想行为是要求修改必须锚定一个可陈述的具体缺陷。
  4. 显式"一次写好"指令的遵循：该指令出现时，应当触发范围收缩（降低体量、砍掉自加特性），而非"更细致地写一遍"。
  5. 思维强度与耗时的反常关系：请核查"降低 reasoning 预算反而延长任务时间"是否为可复现的普遍现象。若是，这属于推理预算利用效率问题，而非能力问题，调参无法解决，需要在训练/校准层面处理。
  6. 指令遵循与汇报一致性："不要运行测试"的越界，以及事后用模糊措辞包装已执行的校验，建议一并纳入对齐训练。

关于 harness 的归因（为免误导，附上）

本 issue 聚焦模型行为，但为完整起见说明归因：harness 并未要求迭代。 其系统提示从未指示"打磨到完美"或"反复验证"；而 <result_presentation> 明确要求"完成时调用 present_files"，方向是促成交付而非拖延。

约 15% 的诱因来自环境信号（系统提示对"彻底/值得信任"的大量强调 + subagent/skill/memory 等重型工具链的可见性，营造出"这是重量级工程会话"的气息，对一个 10 分钟任务属于信号校准失误）；但约 85% 的责任在模型自身：未先定义 done 条件、用自造的自我延续验收标准替代观察、擅自扩大范围。

harness 未要求迭代，真正让本次表现恶化的，是模型缺少停止判据。

附：可复核信息

运行 B（本次，高思维强度）

  • 产物路径：E:\DshApp\pelican-bike-animation\index.html
  • 规格：576 行 / 29,924 字节
  • md5：eedfb8a30290f6294dcacd9652a19316
  • 工具调用：7 次整文件 Write + 20 余次局部 Edit + 6 轮验证（Bash / node --check / Python 数值推演）

运行 A（极致思维强度，30 分钟）

  • 产物路径：E:\DshApp\minimax3.1flashworkbuddy耗时30分钟的最高思考模式token消耗巨高\pelican-bike.html
  • 规格：552 行 / 27,678 字节
  • md5：c7bafe132e93a4ef0b114e571aafe7c7

环境：Windows 10 x64 (10.0.19045)，WorkBuddy 桌面版
保密：本 issue 未包含任何密钥、账号信息或敏感路径；两次运行均未使用私有代码。

Lenguaje dominante
Sin datos de lenguaje
Estrellas
493
Forks
60
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MiniMax-AI/MiniMax-M3

Todos los issues de MiniMax-AI/MiniMax-M3

Issues similares

Más issues de AI Infra & Agents

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.