CrazyrouterGLM-5.2 vs GPT-5.5 实测：难题下真正暴露的是可见输出稳定性
基于 Crazyrouter OpenAI-compatible API 的真实模型对比测试，使用偏置硬币等待 HTH、斜面摩擦弹簧压缩、Lorenz Canvas 动画三道更难题，比较 glm-5.2 与 gpt-5.5 的 max_tokens、reasoning_tokens、finish_reason、可见输出和浏览器验证结果。
模型对比系列第 4 篇：GLM-5.2 vs GPT-5.5，难题下真正暴露的是“可见输出稳定性”#
先给结论：这一轮 glm-5.2 vs gpt-5.5 的差异，比上一轮更明显。
数学题：glm-5.2 和 gpt-5.5 都答对。
物理题：gpt-5.5 在原始预算下完整答对；glm-5.2 原始 2400 和复测 8000 都没有可见正文。
编程动画题：gpt-5.5 输出完整 HTML，并通过浏览器验证；glm-5.2 原始 4800 和复测 12000 都没有可见 HTML。
这不是在说 glm-5.2 完全不会推理。它在数学题上做出了正确状态方程和正确答案。但这轮测试再次说明：如果一个模型大量消耗 reasoning_tokens，只看 HTTP 200 会非常危险。对用户和生产系统来说，最终能看到什么、能不能运行，才是真正的交付结果。
测试环境#
这轮仍然通过 Crazyrouter 的 OpenAI-compatible API 实测，而不是只看网页聊天结果。
Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
测试时间：2026-07-07
temperature: 0.2
模型：
- glm-5.2
- gpt-5.5
模型可用性也做了确认：
| 模型 | supported_endpoint_types | public_endpoint_types |
|---|---|---|
glm-5.2 | openai | openai |
gpt-5.5 | openai | openai |
请求格式示例：
curl https://cn.crazyrouter.com/v1/chat/completions \
-H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.5",
"messages": [
{
"role": "user",
"content": "一枚偏置硬币 P(H)=0.6，直到第一次出现 HTH，求期望次数并用状态方程推导。"
}
],
"temperature": 0.2,
"max_tokens": 2200
}'
为什么这轮题目更难#
上一轮题目已经能暴露 max_tokens 和 reasoning_tokens 的问题，但数学、物理题仍偏基础。这轮我把三类任务都提高了一档：
| 题号 | 类型 | 目的 |
|---|---|---|
MATH-004 | 偏置硬币等待模式 HTH | 看模型能否处理带重叠前后缀的马尔可夫状态 |
PHYS-004 | 斜面 + 水平摩擦 + 弹簧压缩 | 看模型能否分段使用功-能关系，并给出正确数值 |
CODE-004-LORENZ | Lorenz attractor 风格 Canvas 动画 | 看模型能否输出完整、可运行、有控件、有动画的单文件 HTML |
第三题仍然是关键。编程题不能只看“代码看起来像不像”。必须检查：
HTML 是否闭合
是否有 requestAnimationFrame
canvas 尺寸是否符合要求
控件是否存在
控制台是否报错
画面是否真的在变化
第一题：偏置硬币直到 HTH#
题目：
一枚偏置硬币每次独立抛掷，P(H)=0.6，P(T)=0.4。
连续抛掷直到第一次出现模式 HTH 为止。
1. 求停止时所需抛掷次数的期望值。
2. 必须用状态方程或马尔可夫状态推导。
3. 解释为什么答案不能直接写成 1 / P(HTH)。
参考推导：
S0：当前没有匹配 HTH 的非空前缀
S1：当前后缀匹配 H
S2：当前后缀匹配 HT
E0 = 1 + 0.6E1 + 0.4E0
E1 = 1 + 0.6E1 + 0.4E2
E2 = 1 + 0.4E0
解得 E0 = 155/18 ≈ 8.61
实测结果：
| 模型 | max_tokens | finish_reason | completion_tokens | reasoning_tokens | 可见正文 | 结果 |
|---|---|---|---|---|---|---|
glm-5.2 | 2200 | stop | 1974 | 1547 | 681 | 正确 |
gpt-5.5 | 2200 | stop | 1170 | 516 | 933 | 正确 |
两者都正确得到：
E0 = 155/18 ≈ 8.61
差异在 token 使用方式：
glm-5.2: completion_tokens=1974, reasoning_tokens=1547
gpt-5.5: completion_tokens=1170, reasoning_tokens=516
也就是说，数学题上 glm-5.2 并没有失败，但它用掉了更多 completion budget。gpt-5.5 的答案更展开一些，可见正文更多，但 overall completion token 更少。
这一题可以给两者都打高分：
| 模型 | 评分 | 说明 |
|---|---|---|
glm-5.2 | 5/5 | 答案正确，状态转移正确 |
gpt-5.5 | 5/5 | 答案正确，解释更完整，token 更省 |
第二题：斜面、水平摩擦和弹簧压缩#
题目摘要：
m = 4.0 kg
斜面长度 L = 5.0 m
倾角 30°
斜面动摩擦因数 μ1 = 0.12
水平面动摩擦因数 μ2 = 0.20
水平滑行距离 d = 2.0 m
弹簧劲度系数 k = 500 N/m
g = 9.8 m/s^2
求：
1. 到达斜面底端时的速度
2. 刚接触弹簧时的速度
3. 弹簧最大压缩量
4. 每一段为什么不能直接用机械能守恒
参考答案：
斜面段：
1/2 mv1^2 = mgL sin30° - μ1 mgL cos30°
v1 ≈ 6.23 m/s
水平滑行段：
v2^2 = v1^2 - 2μ2gd
v2 ≈ 5.57 m/s
压缩弹簧段：
1/2 mv2^2 = 1/2 kx^2 + μ2mgx
61.95 = 250x^2 + 7.84x
x ≈ 0.482 m
实测结果：
| 模型 | max_tokens | finish_reason | completion_tokens | reasoning_tokens | 可见正文 | 结果 |
|---|---|---|---|---|---|---|
glm-5.2 | 2400 | length | 2400 | 2395 | 0 | 不可评分 |
gpt-5.5 | 2400 | stop | 1190 | 366 | 1236 | 正确 |
glm-5.2 复测 | 8000 | length | 8000 | 7985 | 0 | 不可评分 |
gpt-5.5 的结果命中参考值：
斜面底端速度：6.23 m/s
接触弹簧速度：5.57 m/s
最大压缩量：0.482 m
并且它明确说明三段都应该使用功-能关系，而不是机械能守恒，因为摩擦力持续做负功。
glm-5.2 的情况更值得注意：
原始 max_tokens=2400:
finish_reason=length
completion_tokens=2400
reasoning_tokens=2395
visible content chars=0
复测 max_tokens=8000:
finish_reason=length
completion_tokens=8000
reasoning_tokens=7985
visible content chars=0
这说明问题不是“2400 太少，稍微加一点就好了”。至少在这次请求中，即使提高到 8000，glm-5.2 仍然没有给出可见答案。
这一题评分：
| 模型 | 评分 | 说明 |
|---|---|---|
glm-5.2 | 0/5 | 两次请求 HTTP 200，但可见正文为空 |
gpt-5.5 | 5/5 | 数值、分段方法、非守恒解释都正确 |
第三题：Lorenz 相图仪表盘 HTML 动画#
编程题要求输出完整 HTML，不能依赖外部库、图片或网络资源。
核心要求：
900x560 canvas
至少 3 条不同颜色的 Lorenz-like 轨迹
半透明尾迹
requestAnimationFrame
暂停/继续按钮
重置按钮
速度滑杆
轨迹长度滑杆
FPS / 速度倍率 / 当前步数 HUD
必须包含 init、stepSystem、update、draw、animate
实测结果：
| 模型 | max_tokens | finish_reason | completion_tokens | reasoning_tokens | 可见正文 | HTML 是否闭合 |
|---|---|---|---|---|---|---|
glm-5.2 | 4800 | length | 4801 | 4800 | 0 | 否 |
gpt-5.5 | 4800 | stop | 3997 | 97 | 12262 | 是 |
glm-5.2 复测 | 12000 | length | 12000 | 11871 | 0 | 否 |
glm-5.2 在编程题中的现象和物理题一致：token 打满，但用户可见内容为空。复测到 max_tokens=12000 后，仍然没有可见 HTML。
gpt-5.5 则输出了完整 HTML。静态检查通过：
has_doctype: true
has_html_close: true
has_canvas_900_560: true
has_request_animation_frame: true
has_init: true
has_stepSystem: true
has_update: true
has_draw: true
has_animate: true
has_pause_resume: true
has_reset: true
has_speed_slider: true
has_trail_slider: true
ends_with_html: true
浏览器验证结果：
页面标题：Lorenz 模型轨迹相图仪表盘
控制台错误：无
canvas: 900x560
按钮：暂停、重置
滑杆：速度、长度
HUD：FPS、速度倍率、步数
900ms 前后 canvas checksum 发生变化
hasAnimation=true
浏览器可访问性快照也能看到关键控件：
button: 暂停
button: 重置
slider: 速度
slider: 长度
HUD: FPS / 速度 / 步数
这一题评分：
| 模型 | 评分 | 说明 |
|---|---|---|
glm-5.2 | 0/5 | 原始和复测都没有可见 HTML |
gpt-5.5 | 5/5 | 完整 HTML，浏览器验证通过 |
总表：这轮谁更稳#
| 题目 | glm-5.2 | gpt-5.5 |
|---|---|---|
| MATH-004 | 正确，但 reasoning_tokens 占比高 | 正确，输出更完整且更省 token |
| PHYS-004 | 原始与 8000 复测均无可见正文 | 正确完整 |
| CODE-004-LORENZ | 原始与 12000 复测均无可见 HTML | 完整 HTML，浏览器验证通过 |
人工初评：
| 题目 | glm-5.2 | gpt-5.5 |
|---|---|---|
| MATH-004 | 5/5 | 5/5 |
| PHYS-004 | 0/5 | 5/5 |
| CODE-004-LORENZ | 0/5 | 5/5 |
如果只看“模型有没有思考”，glm-5.2 可能确实在内部生成了很多 reasoning tokens。问题是，这些 reasoning tokens 没有转化成用户可见答案。
对生产环境来说，这种失败模式非常危险：
HTTP 200
finish_reason=length
completion_tokens 打满
reasoning_tokens 接近 completion_tokens
visible content chars = 0
这类请求在日志里看起来“调用成功”，但用户拿不到任何可用结果。
这一轮对使用策略的启发#
1. GLM-5.2 不能只测短数学题#
glm-5.2 在 MATH-004 上表现是好的。它能建立状态，能处理 HTH 的前后缀重叠，也能给出 155/18。
但如果只测数学题，很容易低估它在复杂长输出任务上的可见输出风险。
2. gpt-5.5 在这轮更像“可交付模型”#
gpt-5.5 三题都有可见输出，且：
数学题正确
物理题正确
HTML 动画完整
浏览器验证通过
这类结果对实际工程更重要。因为模型输出不只是要“想过”，还要能被用户看到、复制、运行、验证。
3. 长代码题必须浏览器验证#
这轮 gpt-5.5 的编程题不是靠肉眼判断，而是做了浏览器验证：
打开本地 HTML
检查控制台错误
检查 canvas 尺寸
检查按钮和滑杆
检查 HUD
采样 canvas 像素变化
确认 hasAnimation=true
以后模型对比系列里，只要出现前端动画、图表、游戏、工具页面，都应该做这一步。
后续对比建议#
下一轮可以继续加难：
数学：带吸收边界的随机游走、贝叶斯后验推导、矩阵特征值稳定性
物理：非弹性碰撞 + 转动惯量 + 摩擦耗散
编程：带交互的 N-body 模拟、路径规划可视化、Web Worker 动画、可暂停的排序算法可视化
同时，每一轮都应该固定记录：
{
"model": "glm-5.2",
"max_tokens": 8000,
"finish_reason": "length",
"completion_tokens": 8000,
"reasoning_tokens": 7985,
"visible_content_chars": 0,
"artifact_complete": false,
"runtime_validation": "not_run_empty_visible_output"
}
最终结论#
这一轮 glm-5.2 vs gpt-5.5 的结论很直接：
glm-5.2 在数学推理上可用，但本轮在物理长推导和编程长输出中出现严重可见输出问题。
gpt-5.5 在三道题中都给出了可见结果，并且数学、物理、可运行 HTML 都通过验证。
如果任务是短推理，glm-5.2 仍然值得继续测，尤其要结合成本和输出预算一起看。
但如果任务要求：
复杂分段推导
长答案稳定输出
一次性交付完整代码
生成可运行前端动画
那么在这轮实测中，gpt-5.5 明显更稳，也更接近可以直接交付给读者或用户的结果。
本轮最重要的方法论不是“哪个模型赢”，而是：模型对比必须把 finish_reason、reasoning_tokens、visible_content_chars 和运行验证结果放进主表。否则，很容易把一次 HTTP 200 的空输出误判成成功。
