新 qwen3.8:27b 在39k行C代码到单文件HTML/three.js移植中的表现

我本来很好奇新的 qwen3.8:27b 在默认 Claude Code 环境下，与 Opus 5 相比，在将C代码移植到HTML的困难任务上表现如何。任务内容：我的趣味副项目是一个程序化射击游戏，包含在一个C文件中。将其移植为单文件HTML/three.js，带有一个机器人。只提供一个提示，没有后续操作，没有我的帮助。game.c 文件大小为2.1 MB，约60万行C代码，因此不适合上下文窗口，代理必须遍历文件并找出重要部分。设置：qwen3.8:27b 使用FP8精度在vLLM上运行，FP8 KV缓存，完整262144上下文，RTX 6000 Pro 96GB显卡。我这边没有截断，文件大小仍然是窗口的两倍多。代理模型耗时行数输出结果 Claude Code Opus 5（云端参考）21分钟 1759行 尚可 Hermes qwen3.8:27b 4小时18分 949行 差劲 codehamr qwen3.8:27b 1小时40分 1056行 差劲 视频首先展示C原版，然后按表格顺序展示三个移植版本。只有Opus的移植版本质量为“尚可”。我真正想知道的是HTML输出是否可玩。每个模型运行一次，对3.9万行C代码进行一次性提示，因此这不代表任何普遍情况，我知道这对本地LLM来说很残酷。我的看法：本地模型仍然取决于提示质量。相同的权重在两个非常不同的框架下给了我相同的失败移植。Hermes框架包含更多机制，但单次提示且提示简短，让它无用武之地，因此花了四个小时才达到相同结果。冗长的框架无法挽救简短的提示，只会浪费GPU时间。不幸的是，这里没有深入分析。我不断思考的是耗时：在不错的本地硬件上花费数小时GPU时间，而云端运行只需21分钟。如果有人知道这些时间具体花在哪里，我愿闻其详。C原版：https://github.com/codehamr/skill-issue 我的实验性本地优先、无插件codehamr框架：https://github.com/codehamr/codehamr 全部免费。