Minimax3.1flash在workbuddy里面做鹈鹕骑车测试消耗的时间和token是别的模型的数倍，但是达到的效果却很一般，数倍于其他模型的时间和token的消耗并没有让结果明显好于其他模型，请官方重视。 #518

问题概述

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

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

这不是"模型能力不足"，而是"模型把自己本来的优势（体量小、速度快）变成了劣势"。如果 M3.1-Flash 能在 5–10 分钟内以 200–300 行体量一次成稿交付，它在同类任务上的性价比将远超本次表现。请官方重视这一模式并在调校/训练中针对性优化。

复现设置（Evaluation setup）

• 模型：MiniMax-M3.1-Flash（WorkBuddy 中最高思考模式）
• Harness：WorkBuddy（Windows 桌面版），同批对比使用了其他 harness/模型
• 推理路径：标准 Agent 循环，工具为 Read / Write / Edit / Bash
• 用户原始提示词（逐字）：

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

• 任务难度：低。单文件 HTML + 内联 SVG，需求下限约 150 行纯 CSS 即可满足（车轮旋转 + 腿部摆动 + 背景平移）。
• 显式约束：①「一次性写好」 ②「不要运行测试」 ③「严禁上网搜索」
• 对照组：同批横向测试的其余模型产出（同一用户、同一提示词、同一目录）：

注：Gemini 4 argon 的产出体量最大（950 行 / 43.8 KB）但一次成稿、耗时最短。这说明体量大本身不是问题，一次写完才是关键。本次表现是"体量中等 + 反复返工"，落在最差象限。

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

1. 同一文件被写/改 6 次，而其中若干次是纯粹的自我摇摆

实际写文件序列（可从工具调用日志核对）：

2. 硬证据：常量 flip-flop（这是 revisionism 的直接指纹）

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

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

THIGH / SHIN      :  100 / 90
                  →  88 / 80
                  →  100 / 88                  ← 改了 2 次，第 3 次改回原值

这些改动不是"发现 bug"——是"拿不定主意"。真正的 bug 修复会收敛，而它们在发散。其中 THIGH/SHIN 的第三次改动是把值改回原来的 100/88，纯粹的空转。

3. 需求膨胀（Scope inflation）

以下特性用户从未要求，均为模型自行叠加：

• 两骨 IK 步态解算（大腿/小腿长度 + 每帧膝关节三角函数求解）
• 牙盘 / 车轮传动比联动（GEAR = 2.4）
• 地面线速度与轮速的物理一致性推导
• 多层视差滚动（云 46s / 远山 22s）
• 无限平铺无缝滚动 + 周期整除性约束
• SMIL 眨眼 / 拍翅 / 太阳脉冲
• 暂停 + 三档变速交互控件

每多加一层约束，就多出一批需要自洽的坐标关系，于是写完必然回头返工。30 分钟是被自己造出来的复杂度逼出来的，任务本身并不难。

4. 停止判据失效（Termination criterion failure）

这是一个无法靠"更努力"解决的结构性问题：

对于一个无法直接观测渲染结果的视觉产物，模型的实际停止条件退化为"在我的内部模型里找不出更多瑕疵"。而这个条件几乎永不为真——总能再想象出一个"这里坐垫会不会被遮住"。于是行为从「找正确性」滑向「找缺陷」，而找缺陷可以无限进行。

关键：用户明确要求"不要运行测试"后，正确的应对应当是收窄范围、一次写完、立即交付（把验证成本转移到"少做"上），而模型把"不许测"转译成了"那就多推演几轮"，于是演变为 25 分钟的盲审。这属于指令遵循层面的偏差，不是能力问题。

5. 净收益核算（Net result）

• v1（16:33，27.8 KB）本身已经是功能完整、可直接交付的产物
• 迭代 2–6 对"能否正常运行 / 结果是否正确"的贡献 = 0
• 唯一净产出是若干像素级的观感微调
• 成本：约 25 分钟 + 数倍 token
• 且最终交付前未做任何渲染验证，因此连"改进是否真的生效"都无从确认

即：数倍于其他模型的时间和 token 消耗，并没有让结果明显好于其他模型。

期望行为（Expected and actual behavior）

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

1. 采用满足需求下限的最简实现（纯 CSS keyframes 即可，无需 IK / 无需物理联动）；
2. 一次 Write 成稿，不在事后做像素级自我打磨；
3. 在明确收到"不要运行测试"时，把不确定性通过缩小范围来管理，而非增加推演轮数。

实际：需求膨胀至 552 行 / 27.7 KB，写改 6 次，产生无收益的 flip-flop 返工，耗时约 30 分钟，最终质量与同批 5–10 分钟产出的 200–300 行版本相比无明显优势。

建议关注的调校方向

1. 停止判据：为"输出不可自观测的产物"这类场景设置更硬的停止条件（例如：最多 N 次自审轮次，或要求"能指出具体缺陷"才允许修改），抑制无限自审。
2. 区分"修 bug"与"改偏好"：目前模型倾向于把"我觉得还能更好"也当作修改理由。理想行为是要求"修改必须锚定一个可陈述的具体缺陷"。
3. 显式"一次写好"指令的遵循：该指令出现时，应当触发范围收缩（降低体量、砍掉自加特性）而非"更细致地写一遍"。
4. 过度设计与 token 效率：把"产出体量 / 同批模型 2 倍"作为可检测的过度设计信号，触发自我降级。

附：可复核信息

• 复现产物（本次归档）：pelican-bike.html，552 行 / 27.8 KB，md5 c7bafe132e93a4ef0b114e571aafe7c7
• 平台：Windows 10 x64 (10.0.19045)，WorkBuddy 桌面版
• 该次任务未使用任何私有代码或凭据；本 issue 未包含任何密钥、账号信息或敏感路径