← #809

我用同一个 Three.js 任务测了 10 种模型／框架组合

查看原文 HN 讨论

文章摘要

这是一个极简的静态数据页面，没有长篇论述，只有一句说明加一张可排序的大表格。作者（HN 用户名 alvins82）解释了做这件事的动机：他一直在用同一个简单提示词测试不同的模型与 agent 框架（harness）组合，想搞清楚哪种组合出的结果最好，并且全部在 /goal 模式下进行。

测试用的提示词

只有一句话，但要求相当具体：用 Three.js 做一个单页的科幻机库，要有悬停的无人机、带动画的警示灯、自发光的跑道灯带、以及有体积感的雾平面；要包含无人机编队切换和电影感的相机路径；输出必须是一个内联 JavaScript 的自包含 HTML 文件。

表格记录的维度

每一行是一次运行，列包括：模型、框架、生成文件（可点开直接看效果）、总耗时、TTFT（首 token 延迟）、输入/输出/推理/总 token 数、输入成本、缓存读取成本、输出成本、总成本、缓存输入占比、工具调用次数、工具错误次数，以及两个很能说明 agent 行为差异的列——是否在浏览器里打开过、是否检查过截图。

十次运行的组合与结果概览

测试覆盖的模型包括 GLM 5.3 Flash Max、Qwen 3.8 27B（x-high）、GPT-5.6 Luna、GPT-5.6 Sol 和 GPT-6 Astra；框架包括 Codex、OMP（oh-my-pi）、OpenCode 和 DSH（DeepSeek Harness，含 PTC 模式）。

几个值得注意的数字：

• 同一个模型换框架，行为差异巨大。GLM 5.3 Flash Max 在 Codex 下 9 分钟跑完、14 次工具调用、1 次工具错误、浏览器被”拦截”；在 OMP 下跑了 30 分钟、57 次工具调用、0 错误、打开了浏览器也查了截图；在 OpenCode 下跑了 20 分钟、67 次工具调用、缓存输入占比高达 96.89%。
• 成本跨度接近三个数量级。GLM 在 Codex 下总成本约 0.015 美元，而 GPT-6 Astra 在 Codex 下花了 37 分半、总成本约 4.04 美元——是前者的两百多倍。
• Astra 与 Sol 都没有在浏览器里验证结果（Astra 打开了浏览器但没看截图，Sol 两项都是 No）。
• Qwen 3.8 27B 在 OMP 下跑了 41 分钟、89 次工具调用、零错误，总 token 接近 350 万。

方法学注解

页面底部的脚注相当详实，值得单独说明：所有 GLM 运行都标为 GLM 5.3 Flash Max；输入 token 包含缓存输入；输出 token 是生成总量（含推理），当框架单独上报推理量时，推理列才显示那一子集——DSH 适配器不单独上报推理计数；DSH 的耗时是把两轮的活跃时间相加、排除中间停顿；工具错误指记录在案的失败工具事件；短横线表示不可用或未上报。

成本全部是按 2026-09-09 取得的 OpenRouter 等价费率估算的美元值，页面列出了每百万 token 的输入/缓存读取/输出基础费率。有一处坦诚的自我更正：标为 Luna 5.6 Max 的那一行 Codex 运行，在 transcript 里记录的实际是 gpt-5.6-sol，因此按 Sol 的费率计价。此外，写缓存 token 在每个会话中都是零，且没有任何单次请求越过 OpenRouter 的 272k token 长上下文计价门槛。

作者后来还把每次运行的完整 transcript 推到了 GitHub 仓库 alvins82/hangar-harness-model-tests。

HN 评论精华

125 分、70 多条评论。讨论的重心不在”谁赢了”，而在这种一次性测试到底能说明什么，以及一个被反复验证的观察：框架对结果的影响可能比模型本身还大。

最被认可的发现：框架的影响被严重低估

bensyverson 做了最系统的整理：GLM 5.3 Flash Max 的三个版本形成了绝佳对照——Codex 版很糟且 9 分钟完成，OpenCode 版丰富得多、20 分钟完成，OMP 版可以说是最完整的、30 分钟完成。他的结论是”这大概是框架效应最强的论据“，并希望了解三者在提示词和工具上的差异。sashank_1509 也说”震惊于 GLM 在非 Codex 框架上好这么多，没想到差别能这么大”。rao-v 同样惊讶于 OMP 在这个任务上比 OpenCode 好这么多。作者回应称已把全部 transcript 传到 GitHub，可以自己拿 AI 去分析。

quietraster 提了个没被回答但很关键的问题：有没有哪个框架不论搭配什么模型都稳定胜出，还是全看配对？

可复现性的质疑

poilcn 直接问：这些测试里到底哪些东西是可复现的——最终视觉效果、时间、工具调用，还是大部分只是噪声？同一组合你跑过多次吗？karlkloss 问了同样的问题，说这是所有一次性（one-shot）测试都缺的东西。

作者的回答是他在 Qwen3.8 27B 上做过多次运行，”结果在定性上足够接近”。mcrk 一句话点破：”所以它是不可复现的。” grey-area 补充说这在 LLM 上不幸是必然的。

utopiah 提出了另一个更隐蔽的可复现性问题：他希望能事先弄清楚网上已经公开存在什么——如果这个主题有比赛作品（比如 js13k）、书里的实时代码示例甚至现成模板，结论性质就完全不同了。他说这些结果在视觉上相似到让他怀疑，究竟是那句简短但描述性很强的提示词的功劳，还是模型总是找到了同一个模板。他还是最早要求加成本列的人，作者随后照做了（后来至少四个人分别提出了同样的请求，作者都回了”已加上成本”）。

“Hangar 07” 之谜

这是全场最有趣的自发观察：BurpyDave 和 jonasdn 分别独立问出同一句话——这些模型是从哪儿一起想到把它叫做 “Hangar 07” 的？ 提示词里完全没有提这个名字。这条无人回答，但它恰好呼应了 utopiah 关于训练数据中是否存在共同来源的怀疑。

最尖锐的技术批评：这些结果说明 AI 在这个领域有多落后

onion2k 的评论技术含量最高。他逐个查了各版本用的 Three.js 版本：Astra 用的是 r170（2024 年 10 月的版本），Sol 用的更早；GLM 的代码用的是最新版，但他认为那只是从 jsDelivr 拉 three.js@latest，所以模型不太可能是针对那个版本写的代码；Qwen on OpenCode 同样从 jsDelivr 拉，但锁在 r160。

他进一步指出这些示例都没有用色调映射（所以困在 sRGB 里，而 AgX 或 ACES 观感要好得多）、没有用 node materials（做程序化纹理很有用）、也没做任何有意思的事情比如烘焙阴影环境或使用后处理效果。他的结论是：”它们不错，但我觉得这些例子展示的是 AI 模型在这类项目上落后了多远，而不是它们有多好。”

rao-v 说很感谢这个视角：”容易停在’惊叹于这些模型能做到什么’，但我的经验和你一致——要做好，它们需要在细节上被帮一把。”warpech 和 scroogey 都追问了同一件实用问题：怎样引导模型使用当前版本、有没有合适的 skill 文件能把 agent 往这些方向推？

avaer 的回答给出了这条线最实在的建议：别用 skill，把它指向一个游戏引擎、或者更好的是一个完整的游戏仓库，然后说你想要什么。他认为不做色调映射和 shader graph 还算小罪过——这类一次成型的产物更常见的问题是生成几百个 THREE.Geometry、大量矩阵遍历，”一旦你越过屏保的规模就会爆炸”。模型能做对，但你得提对要求，大多数人不会，然后就在打不破 Three.js demo 页天花板时怪浏览器慢或者丑。

被追问大型 Three.js 项目该怎么做时，avaer 给出了完整回答：更大的 Three.js 项目会越来越像一个游戏引擎，所以你要挑选需要的部件；开源库很多，大厂用的重型组件（物理、网格优化）大多是开源的。AI 相关的关键部分包括：一个 harness（让 agent 能驱动这套东西）、一条创作流水线（能烘焙/优化资产）、以及一个连贯的渲染器架构（你的资产是什么、有哪些 pass、shader graph 长什么样）。没有这些基础，你就走上了掉下技术债悬崖的近路，而 AI 会乐意一路把你送下去，直到你要求一次昂贵的重写。他的最后一句很直接：除了”做一个 Three.js 场景”之外什么都行——那不是游戏开发里会用的手法，只会出现在一次性原型或 demo 里，而你要求 Three.js 场景就只会得到那个。

这条线还引出了一串工具推荐：Footprint0521 说 Three.js + cannon.js 是入门答案，但做久了会发现难点不在”游戏”也不在”引擎”，而在”网页”——资产优化本身就是一门大学问；rao-v 转述说 Reddit 上有人警告 cannon.js 太老了，并推荐了 Babylon.js 的 lite demo；utopiah 说现在酷小孩都用 Rapier 做浏览器物理。

关于结果的主观评价（分歧很大）

• fig781 认为 Qwen + OpenCode 最好，性能和视觉平衡得最佳。
• amenghra、hudo、andai 都力挺 Astra：”Astra 细节多太多了，虽然多花 5 倍时间，但当它替代的是几小时人力时通常可忽略”；”Astra 好得不真实”；”Astra 看起来像 Unity 的示例项目，比我预期好太多。”
• rao-v 观察到一个很有意思的细节：Astra 和其中一个 GLM 加了明亮的灯光，所以在他眼里看起来好很多——小选择对结果好坏影响巨大。andai 从反面印证：”大多数都做得太暗了，看不清在发生什么。”
• riversflow 从移动端切入，得出了和视觉派完全不同的排序：OMP 的 Qwen 结果在他 iPhone 的自由相机下完全无响应，而 OpenCode 版响应良好、支持多点缩放和平移；GLM 也不错；而所有 Anthropic 模型的相机控制都很残，连 Astra 虽然好看却不能平移、只能旋转约 120 度。他还指出所有版本都没做好”有体积感的雾平面”——没有一个做到离光源越远雾越浓。
• 反方也不少：pdp 说”我怎么判断哪个最好？它们在我看来都差不多”；yanhangyhy 说”差别在我看来没那么大”。
• stuaxo 吐槽了作者对”简单提示词”的定义，andai 接梗：”给我造个真机库。别犯错。”

作者本人也在 Astra 与 Sol 的行为上留了一句关键观察：它们没有用浏览器做视觉检查，”我怀疑如果检查了，它们会做得更好”。

“为什么没有 Anthropic 模型”

consumer451 直接问了。aetherspawn 说应该把 Fable 和 Opus 加进来，因为从 Astra 和 GLM 的差距看，这些才是现实中会考虑的替代品；bensyverson 也想看 Fable/Opus/Sonnet。sampullman 提出一个值得记住的方法论问题：Sol 和 Opus 在合适的提示词和反馈框架下都相当不错，”或者是我标准更低。这类讨论里常常分不清大家在说的是生产级质量，还是够发一篇博客的水平“。

meerita 的经历很典型：他在 X 上看到别人用 Three.js 和模型做出惊艳的东西，自己照着做却大多得到低模材质和粗糙动画，一开始以为是自己提示词的问题（其实写得很详细），”看来主要还是模型的局限”；他猜 Astra 做得好是因为厂商想吸引游戏设计师，在 3D 和动画库上训练得更多。

框架与 GUI 的周边讨论

reilly3000 说自己喜欢 OpenCode 的一切，除了它输出的东西——纸面上它具备他想要的一切，实际却常常交付不出想要的结果，上次用时上下文巨大、工具调用可靠地不可靠，问值不值得回头当主力。作者反问”为什么不试 OMP”，shock 指出数据里 oh-my-pi 的缓存命中率明显低于 OpenCode；polytely 则说自己从 OpenCode 转到 OMP 后”不打算回去了”。

chvid 问 DSH / PTC 是什么，作者答 DeepSeek Harness，PTC 是它的一种模式；faangguyindia 补充 PTC 是 programmatic tool calling（代码模式），可以跑小程序，每个输入可能是另一次工具调用，从而不必等整个 LLM 响应就能异步准备参数。

作者还顺带分享了自己在找”好用的桌面版 Codex/Claude 类应用”的进展，目前最看好 openchamber，并配自己写的 omp-openchamber-server。这引出一串 GUI 推荐与吐槽：pprotas 用 Paseo 但抱怨这些 GUI 忍不住做功能膨胀，”我只想让它包住我的 harness 并转发到 iPhone”；Fuzzwah 推荐 orca 但在无头服务器上装不起来；dandaka 说 orca 的远程配置体验很糟（标签页时隐时现、卡死、项目消失），提了 PR 两周多团队也不合；anilgulecha 干脆自己做了个基于 ttyd/tmux 的浏览器内终端。

grigio 也贴出了自己做的同类对比（同一模型换不同框架），并请作者加上 jcode 框架。ande-mnoc 的一句短评大概代表了很多人对这个页面形式的喜欢：”看到一篇直奔主题、不把数据埋在大段散文后面的帖子，很清爽。”

polyterative 那句”这些工具居然能做出任何东西，对我来说就是奇迹”引来了 utopiah 一段冷静的反驳：数以千计甚至上百万的人在攻克这个问题，人类绝大部分文本产出被用于训练，运行它的是人类造过最复杂的器件（处理器）构成的庞大基础设施，消耗着巨量能源，这场尝试跨越了数十年、甚至可以往前追溯到安提基特拉机械——”它可能令人印象深刻，但考虑到投入了多少努力，它绝不是奇迹”。