12B 代码模型实测：会写代码，不等于能一次做对复杂程序

很多人选代码模型时，只看一个问题：

“它能不能写出代码？”

这个标准太低了。

真正影响使用体验的是：代码能不能一次跑起来？状态会不会乱？依赖能不能配对？功能写到一半会不会突然崩掉？

我在 M5 Max 上做了一轮对比测试，拿社区微调版 gemma-4-12B-coder，通过 llama.cpp 运行；另一边是日常使用的 Qwen3.6-35B-A3B MoE，通过 oMLX 运行。

结果很有意思：简单任务几乎打平，复杂任务直接拉开差距。

测试环境与任务

这次没有拿模型做简单补全，也没有只看代码长度，而是安排了三个更接近真实开发的任务：

• 用 Matplotlib 生成数据图表
• 用 Three.js 做可旋转、可缩放的星系粒子特效
• 从零写一个完整可玩的俄罗斯方块

这三个任务刚好覆盖了三种能力：

1. 基础代码生成：语法、结构、常见 API
2. 多依赖前端项目：模块加载、版本、渲染和交互
3. 长代码与状态管理：游戏循环、碰撞检测、计分、消行、预览区

这种测试比“让模型写一个排序函数”更接近咱们平时真正用模型的场景。

任务一：Matplotlib 图表，两个模型打平

第一个任务比较简单：用 Matplotlib 生成数据图表。

两个模型都一次完成，表现基本一致：

• 图表能正常生成
• 坐标轴完整
• 图例和标题齐全
• 代码结构没有明显问题
• 运行结果符合预期

这说明 12B 级别的代码模型，处理常规 Python 图表已经够用。

你只是想把一组销售数据画成折线图，或者做个柱状图、散点图，没必要为了这类任务上更大的模型。

这类需求更适合本地模型，速度快，成本低，隐私也更稳。

任务二：Three.js 星系特效，问题开始集中爆发

换成 Three.js 后，差距就出来了。

Qwen 生成的结果可以正常运行：

• 星系粒子能显示
• 画面可以旋转
• 镜头可以缩放
• 粒子效果基本符合要求

gemma-4-12B-coder 生成的页面直接黑屏。

排查后发现，问题不是一个小拼写错误，而是多个环节一起出错：

• 漏掉了 importmap
• CDN 版本号写错一位
• 粒子尺寸过小，肉眼几乎看不见

这类问题很典型。

模型看起来写了不少代码，结构也像模像样。浏览器一运行，页面却只剩一块黑色背景。开发者往往要花十几分钟检查依赖、控制台和渲染逻辑，才发现问题分散在不同位置。

为什么前端特效更容易暴露模型短板？

因为它要求模型同时记住很多约束：

• HTML 如何引入模块
• Three.js 版本与 API 是否匹配
• CDN 地址是否真实可用
• 相机、场景、渲染器是否初始化完整
• 粒子材质参数是否能被肉眼看到
• 动画循环是否持续执行
• 鼠标交互是否绑定正确

这些内容单独看都不难。

难点在于：它们必须同时成立。缺一个，页面可能就彻底失效。

任务三：俄罗斯方块，模型能力被彻底拉开

俄罗斯方块是这轮测试里最能说明问题的任务。

它不是“画几个方块”那么简单。一个能玩的版本至少要处理：

• 方块自动下落
• 左右移动
• 旋转
• 边界碰撞
• 堆叠碰撞
• 消行
• 分数计算
• 游戏结束
• Next 方块预览
• 游戏循环和键盘事件

Qwen 生成的版本可以正常玩：

• 方块持续下落
• 可以移动和旋转
• 能够消行
• 分数正常累加，测试中达到 117
• Next 预览区正常显示

gemma-4-12B-coder 的版本则卡在了最基础的环节：

• 方块不往下掉
• 分数一直是 0
• 棋盘没有形成有效的游戏状态

这不是某个按钮失效，也不是样式没调好，而是核心循环没有真正跑起来。

原版模型也崩了，问题不在微调

为了确认问题来源，又用同样的 4-bit 量化版本测试了原版 gemma-4-12B-it。

同样的俄罗斯方块任务，结果依旧不理想：

• 棋盘为空
• 分数出现 NaN
• 消行数乱跳

这一步很关键。

如果只有 coder 微调版失败，可以怀疑是微调数据、提示词或推理参数的问题。现在原版也在同一个任务上崩溃，说明真正的瓶颈更可能来自模型规模和复杂任务处理能力。

12B 的问题：能写片段，难撑住整套状态系统

小模型并不是完全不会写代码。

它能写函数，能补 API，能生成常见模板，也能处理中短长度的独立任务。

可一旦任务变成“从零生成一整套可运行程序”，难度会突然上升。模型需要同时维护：

• 多个函数之间的调用关系
• 全局状态与局部状态
• 数据结构的一致性
• 事件触发顺序
• 异步或动画循环
• 错误处理
• UI 与逻辑的同步

俄罗斯方块里的棋盘、当前方块、下一个方块、计分器、下落计时器，任何一个状态更新错了，整个游戏就会出现连锁故障。

12B 模型可能知道每个模块应该怎么写，却无法稳定地把这些模块拼成一个完整系统。

这就是“代码看起来对，程序跑不起来”的来源。

有意思的观察：原版模型想太久，coder 版更快动手

测试中还有一个细节很值得注意。

原版 gemma-4-12B-it 开启思考模式后，最多输出了约 12000 token 的思考内容，却迟迟没有吐出一行代码。

它像是在会议室里开了三个小时会，项目文件夹还是空的。

反过来，coder 微调版学会了更快进入执行状态：

• 简单分析需求
• 快速搭建代码结构
• 直接输出实现

这说明微调确实改善了模型的使用方式，尤其体现在：

• 更快收敛
• 更少空转
• 更愿意直接写代码
• 输出节奏更符合开发场景

可它没有改变 12B 的能力上限。

微调能让模型更像一个“愿意干活的程序员”，却不一定能让它突然具备大型项目级别的系统推理能力。

这轮测试得出的结论

简单任务：12B 已经够用

下面这些工作，小模型完全可以胜任：

• Python 数据处理
• Matplotlib 图表
• 正则表达式
• SQL 查询
• 小型脚本
• 独立函数补全
• 常见 API 示例

这类任务的特点是：代码短，状态少，依赖简单。

复杂任务：模型规模会直接影响成功率

遇到下面这些需求，建议优先选择更大模型：

• 完整前端页面
• Three.js、WebGL、Canvas 特效
• 多文件项目
• 交互式小游戏
• 带持久状态的应用
• 需要一次生成并直接运行的长代码
• 同时涉及 UI、逻辑和数据流的项目

任务越长，模块越多，模型规模带来的差距越明显。

想用 12B 模型，怎么提高成功率？

别让小模型一次性生成整个项目。

这几乎是在主动给它上强度。

可以改成分阶段开发。

阶段一：先搭最小可运行版本

比如做俄罗斯方块，只要求：

• 显示棋盘
• 显示一个方块
• 方块自动下落

先确认游戏循环真的工作。

阶段二：逐个增加功能

按这个顺序补功能会稳很多：

1. 左右移动
2. 边界检测
3. 旋转
4. 堆叠碰撞
5. 消行
6. 计分
7. Next 预览
8. 游戏结束判断

每加一个功能，就让模型给出测试方法。

阶段三：让模型自己检查运行结果

不要只问“代码写完了吗”。

改成这样问：

请检查这段代码中所有会导致运行失败的问题，重点排查：
1. 未定义变量
2. 模块导入和 CDN 版本
3. 游戏循环是否启动
4. 状态更新是否覆盖错误
5. 数值是否可能变成 NaN
请逐项说明，并给出修复后的完整代码。

阶段四：优先让模型修改现有代码

小模型“续写和修复”通常比“凭空生成大型项目”更稳定。

你可以先手动搭好目录、依赖和基础状态，再让模型补某个功能。这样能减少它在多个模块之间来回猜测。

一份实用的模型选择表

| 任务类型 | 12B 代码模型 | 35B 级别模型 | |---|---:|---:| | Python 小脚本 | 足够 | 有余量 | | Matplotlib 图表 | 足够 | 稳定 | | SQL 与数据处理 | 足够 | 稳定 | | 单个前端组件 | 基本可用 | 更稳 | | Three.js 特效 | 容易漏依赖 | 成功率更高 | | 完整小游戏 | 需要拆分 | 一次完成概率更高 | | 多文件项目 | 建议分步 | 更适合直接搭建 | | 长篇状态逻辑 | 容易出现连锁 bug | 维护能力更强 |

避坑清单

用本地代码模型时，下面几个坑很常见：

• 只看模型名称里的 coder，忽略参数规模
• 看到代码很长，就以为功能很完整
• 不打开浏览器控制台检查报错
• 不确认 CDN 地址和版本号
• 不测试动画循环是否真的执行
• 不验证计分、碰撞、消行这类状态逻辑
• 让 12B 模型一次生成上千行可运行项目
• 只测试“能不能输出”，不测试“能不能跑”

评测代码模型，不能只看屏幕上的代码量。

真正有价值的指标是：

• 首次运行成功率
• 修复 bug 所需轮数
• 依赖配置是否准确
• 状态逻辑是否稳定
• 修改需求后能否保持原功能

我的选择：Qwen 35B 依然是甜点位 🍮

这轮测试里，gemma-4-12B-coder 的优势很明确：响应快，愿意直接写代码，处理简单任务很轻松。

可到了 Three.js 特效和完整俄罗斯方块，模型规模带来的差距就藏不住了。

如果你的需求是写脚本、画图、补函数，12B 很划算。

如果你希望模型一次搭出能运行的交互页面，少陪它来回修十几轮，Qwen3.6-35B-A3B 依旧是更舒服的选择。

模型评测不能只看“它会不会写”。

要看它能不能把依赖、逻辑、状态和运行结果一起兜住。