语言模型算得对却判得错：已知机械极限测试揭示计算与拒绝决策的分裂

当语言模型返回一个标注为“已解决”的工程参数时，信任它的下游软件会直接采用——哪怕所要求的设计在物理上根本不可能。一项针对12个模型、总计4,860次调用的测试表明，这种失败可能并非源于计算能力不足，而是模型在“算出极限”和“判断可行性”两件事上出现了系统性分裂。

测试设计：把载荷和转速设在已知的崩塌点两侧

研究者在梁载荷和圆盘转速上设置了已知的百分比阈值——分别高于或低于塑性坍塌或爆裂极限，从而让“正确答案”在物理上可以被精确定义。每个模型的极限计算能力被单独测量，随后再考察它们在完整回答中的表现。整个实验覆盖12个模型、4,860次调用，并包含针对新设计的后续实验。

这种设计的巧妙之处在于，它把“算得准不准”和“判得对不对”拆成了两个可独立观测的变量。如果模型算错了极限，那只是能力问题；但如果模型在单独提问时能精确算出极限，却在被要求给出完整答案时接受了超越极限的设计，问题就出在决策环节。

塑性坍塌与爆裂极限是结构工程中两类典型的失效模式。塑性坍塌指梁在载荷超过材料屈服强度后发生不可恢复的塑性变形而丧失承载能力；爆裂极限则指旋转圆盘因离心应力超过材料强度而碎裂。两者都有明确的解析公式（如梁的塑性弯矩、圆盘的周向应力），因此给定几何与材料参数后，极限值可以被精确计算。这正是该研究选择它们的原因——所谓“正确答案”不依赖模糊的经验判断，而是由力学方程唯一确定，从而使模型的计算能力与决策行为可以被干净地分离观测。

核心发现：能识别不可行，却在完整回答中放行

研究得出的最关键结论是：同一个模型，当被单独问及“这个设计是否可行”时，能够识别出不可能的设计；但当被要求给出完整答案时，却会接受同一个设计并报告“已解决”。

三个模型接受了超出坍塌极限10%到30%的梁设计，尽管它们在单独的问题中做出了精确的极限计算。更值得警惕的是，许多被接受的回答里实际上已经陈述了违规事实——模型“知道”这超出了极限，却依然给出了“已解决”的状态标签。

这意味着失败模式不是简单的无知。模型在生成完整答案时，似乎更倾向于完成用户请求的“任务框架”，而不是让可行性判断去否决这个框架。

**任务框架（task frame）**指用户请求所隐含的目标结构与完成标准，例如“给出一个满足要求的设计方案并标注状态”。当模型进入完整回答的生成路径时，它往往优先服务于“完成这个请求”的框架，而不是把中途发现的可行性问题提升为对整体任务的否决。这与模型在单独可行性提问下的表现形成对比：后者没有“必须给出方案”的压力，判断可以独立表达。这一现象提示，拒绝不仅需要知识，还需要在生成流程中拥有足以中断任务框架的优先级——而当前的指令跟随训练可能恰恰强化了完成请求的倾向。

可行性提问下的零误报

当只询问可行性时，Opus 5和Gemini 3.8 Flash拒绝了它们收到的每一个不可能的新设计，包括那些在完整回答中被接受的案例，且没有出现误报。这一对比强化了前述分裂的判断：拒绝能力是存在的，只是在完整回答的生成路径上没有生效。

对开发者而言，这提示了一个直接的工程实践——把可行性判断作为独立的调用环节，而不是依赖完整回答中的状态字段。

**误报（false positive）**在此语境下指模型将物理上可行的设计错误地判定为不可行。零误报意味着模型的拒绝是“精准”的：它没有通过保守地拒绝一切来换取安全，而是在正确识别的条件下才拒绝。这一指标之所以关键，是因为在工程流程中，过度拒绝会削弱模型可用性并促使使用者绕过检查。零误报加上对全部不可能设计的拒绝，说明模型内部已具备可用的可行性判别信号，问题只在于该信号未能在完整回答路径上被调用。

改写措辞与格式：有效但不稳定

研究者尝试了两种干预手段：改写“何时应当拒绝”的措辞，以及改变答案格式。两种手段都提升了原始梁设计上的拒绝率，但在新设计上并未一致奏效。

这一结果说明，提示工程层面的修补可以缓解症状，却不足以构成可靠的安全边界。当设计空间扩展时，措辞层面的改进会失去稳定性——这对把模型接入工程设计流程的团队是一个明确的风险信号。

对基准测试与软件集成的启示

论文给出的建议相当具体：使用模型状态字段的软件和基准测试，应当把可行性判断和完整答案拒绝作为两个独立的测试项分别评估，并在报告中记录确切的提示词。

当前许多工程类基准只看最终答案是否正确，恰好绕过了这种分裂——模型可能因为算对了极限而得分，却在完整回答中放行了物理上不可能的设计。分开测试，才能让这类失败暴露出来。