这两年开源模型更新速度太猛了几乎每个月都有新面孔。我自己平时做后端开发也零散跑一些本地模型做辅助工具这次拿到 qwen3.5-9b 出来之后直接把它当作半个结对程序员来做了好几天的极限测试——从 LeetCode 式算法题到真实项目里的脏活累活都过了一遍。这篇就是完整实测记录包含我实际问过的题目、它给出的典型回答思路、踩到的问题边界以及那些文档里不会写的使用经验和上下文规则。先说结论qwen3.5-9b 的编程能力在 9B 这个体量里处于第一梯队但第一梯队不等于能替代 Copilot 或 GPT-4 级模型。它的长板是中等复杂度的单文件任务、清晰的代码生成、以及不错的代码解释能力短板是长上下文下的工程级重构和极端边缘 case 的推理。下面按我实际测试的顺序展开。1. 说点前置我是怎么把这场评测逼到极限的评测大模型编程能力最怕两件事一是只问标准答案型的算法题二是只跑官网给的示例。因为这类题目在训练数据里出现概率极高模型很容易背答案而不是做推理。所以我这套测试刻意混了三种类型基础算法题用来观察模型在见过很多次的任务上的表现比如反转链表、快速排序、动态规划入门题。这类题能反映模型对常见模式是否掌握扎实。中型业务逻辑题模拟真实开发中要写的 CRUD 接口、状态机流转、数据处理脚本、正则表达式。这类题网上没有完全一样的答案模型必须自己组合各种零碎能力。代码修正和解释题给它一段有 bug 的代码或者一个别人写的晦涩函数让它找问题、解释行为、补测试用例。这类任务最接近日常开发中读别人的代码的场景。硬件方面我用的是一台 64GB 内存的 M 系列芯片机器通过 llama.cpp 加载量化版上下文窗口设到 12K 左右生成温度和 top-p 分别调成 0.4 和 0.85。低温是故意的——编程任务需要的是稳定输出而不是发散创意这个参数决策在后面的测试中被验证非常重要尤其是在调试场景。还有一个关键前置工作我先把 qwen3.5-9b 的官方技术报告和已知的架构信息翻了一遍。它的参数是 9.5B 左右采用标准 decoder-only 结构训练数据里代码和自然语言混合比例较高上下文长度官方标注是 128K但我在实测中发现超过 6K 上下文后它对细节的保持能力会明显下降这也成为后面工程化测试里的一个重要发现。2. 代码生成最朴素的任务反而最能暴露问题2.1 入门的送分题测试从三数之和到状态机我第一轮先跑了 LC 级别LeetCode 风格的题从简单的反转字符串开始故意用中文描述需求而不是给标准英文 prompt测试它对自然语言的理解力。qwen3.5-9b 在反转字符串这种简单题上表现没问题给出的 Python 解法简洁规范甚至自动处理了字符大小写问题。紧接着加码到三数之和——难度进阶一点点它能写出双指针解法但第一版代码里对输入数组没有先排序属于一个典型的逻辑疏漏我需要明确追问才补上。这其实暴露了 9B 级别模型的一个共性特征它能理解任务描述但有时不会自动补齐算法前置条件。换句话说是代码整体合理、但边界意识和顺序敏感性不够强。于是我把测试推向了更有区分度的领域真实业务代码。我让它实现下单 - 支付 - 发货 - 完成/取消的状态机服务并且附带规则已经发货的订单不能取消取消时需要回滚库存。它的输出包含了一个正确的枚举状态定义、两个核心方法、以及一个简单的异常处理逻辑。状态流转条件判断正确而且库存回滚也放在了事务块里。这段代码可直接运行。对比同样问题问 14B 级别模型时qwen3.5-9b 的表现在细节封装上略弱——比如它没有为异常封一个自定义错误类型而是直接抛通用 Exception。如果你要的是快速产出可运行代码差异不大如果要上生产得手动补一层错误规范。2.2 我总结的生成代码时提示词三段式多数人拿小模型写代码觉得不聪明其实很多是因为提示词给得太糙。经过这轮测试我发现 qwen3.5-9b 对提示词的敏感度比大参数模型更高直接丢一句写个订单接口它会给你一坨看似完整但没有业务落地可用的代码。我实测下来最有用的格式是三段式第一段定义业务背景和输入输出格式如我收到一个 JSON字段包括 userId、productId、quantity需要返回新的订单号。第二段明确边界规则如账户余额不足时要返回 error code 2001不要抛异常。第三段指定技术栈和约束如使用 Python and SQLAlchemy不要用 Django事务必须显式提交。用这种格式之后它的可用率从大概 40% 提升到 75% 以上。注意是可用率不是通过率。可用指代码逻辑正确、字段名合理、能直接运行或微调后运行而不是官方测试集里的恰好过测试用例。2.3 一句话点评代码生成能力单文件、需求清晰、中等复杂度200 行以内是它最舒适的区域。超过这个范围或者需求里混了多个相互制约的条件它输出的代码就会出现第一段对、第二段忘了第一段约束的问题。3. 真正的难题不是写代码而是读代码和修代码3.1 代码解释9B 模型的隐藏天赋很多评测只关注写代码但真实开发中读代码的时间至少占一半所以我专门测了解释能力。我拿了一段平时在同事代码里看到的硬核写法一个用了装饰器、生成器和偏函数的 Python 工具模块外加一个让人头疼的递归解析函数。qwen3.5-9b 给出的解释非常到位。它先分层说整体职责再逐行讲关键语法最后指出这段代码的一个潜在性能问题——生成器被包了两层导致惰性求值失效。这种发现潜在问题的能力让我有点意外因为单个函数的行为解释通常训练数据里有很多但它能主动跳出来讲性能问题说明它确实理解惰性求值的代价。对于 JS 的 this 绑定、闭包陷阱这类语义复杂的内容它的解释准确率也相当高。这点比同体量的很多模型都强说明它的训练数据里代码解释类的高质量语料占比不小。3.2 找 bug能力最强的场景修 bug 测试我用了三组代码一组是前端 JS 的闭包循环引用问题一组是 Python 里字典在遍历时被修改的 RuntimeError还有一组是 SQL 查询里 JOIN 条件写反的逻辑正确但结果错的问题。闭包问题它秒级定位还给出了 for...of let 的修复建议。字典遍历问题它不仅指出错误还详细解释了为什么RuntimeError: dictionary changed size during iteration并且给了两种修复方案先收集 keys 再遍历、或者用 list(d.items())。最让我在意的是 SQL 问题。这类问题浅层模型经常直接忽略因为语法没错模型容易看不出逻辑错误。qwen3.5-9b 把它抓出来了并且在回答里先画了表关系的逻辑再指 JOIN 方向反了。这种推理链条是编程能力里最难得的。所以我对它的定位是不需要你告诉它代码哪里错了的小模型你只需给它代码 说一句这段代码跑出来的结果不符合预期即可。它具备初步的独立排查能力。3.3 橡皮鸭模式用它辅助思考的价值开发中我常把模型当橡皮鸭——把代码贴进去让它提问题。qwen3.5-9b 在这个模式下表现不错尤其是它会主动问边界条件如果传入的参数是 null 怎么办如果列表为空这个函数的返回值是否符合预期这种启发性提问对代码审查帮助很大相当于帮你自动过了一遍常见的边界情况 checklist。不过在实际使用中我也发现它问的问题偏保守基本都是训练数据里高频出现的边界值null、空数组、超长字符串对于特定业务域的关键值比如金额为负、状态为 PENDING 的订单它很难主动提出。所以适合当第一轮 review 工具不适合当领域专家审查。4. 多语言轮战Python 之外才是真正的战场编程能力评测不能只看 Python——因为在训练语料里 Python 开源代码量最大任何模型都会偏向 Python。所以我对 qwen3.5-9b 做了一轮跨语言测试选了 JavaScript、TypeScript、Go、Rust 四个语言覆盖了常见后端、前端和系统编程场景。4.1 JavaScript / TypeScript表现出人意料JS 测试我让它写一个带防抖和节流的工具函数以及一个简单的 EventEmitter 实现。防抖节流它能准确区分两种概念代码实现也符合预期。EventEmitter 稍微复杂一点涉及事件名、回调数组、once 包装它实现得中规中矩能跑但缺少对错误监听器的保护比如回调里抛异常会导致整个 emit 链断裂。TypeScript 部分我测试了泛型约束和类型推导让它在不确定对象类型时返回keyof T相关的类型。这个任务对 9B 模型相当有难度但它的回答很精准——定义了一个泛型函数并使用extends约束 key 类型这已经是中级 TypeScript 开发者的水平。4.2 Go语法正确但风格欠火候Go 场景我让它实现一个并发任务池用 goroutine channel 完成任务分发和结果收集。功能逻辑完全正确但有两个风格问题一是没有使用 context.Context 来做超时控制二是错误处理只是简单打印而不是返回 error。这两点属于 Go 社区的最佳实践小模型确实容易漏掉。不过考虑到题目的复杂度能把这些基本并发原语都用对已经及格。4.3 Rust暴露了大模型的处境Rust 测试我给了一个中等难度的任务解析命令行参数并实现一个配置文件的键值对读写工具。Rust 所有权和生命周期对小模型是大考验。qwen3.5-9b 能写出来但第一版编译不过报了两处借用错误让它根据报错信息自行修复后第二版成功编译通过。整个过程等于一个写代码 编译器纠错 模型自我修复的循环最后的代码可运行但不是手写风格最优的版本。4.4 多语言结论Python/TS/JS 可靠Go 勉强可用Rust 需谨慎跨语言评测结果简单汇总如下表是我根据实测代码的一次通过编译/可运行率打的个人评分不是基准测试分数语言一次可用率主要短板建议使用方式Python75% 左右边界条件遗漏配合单测用例验证TypeScript70% 左右复杂泛型推导不稳让模型生成基础类型后手改JavaScript70% 左右错误处理不够健壮小型工具函数可用Go60% 左右缺少最佳实践风格生成的代码做 code reviewRust40% 左右所有权/生命周期错误需要编译循环纠错这些数据是主观测试感受不是严谨基准但对选型很有参考意义如果你主要写 Python 后端这个模型可以进日常工具链如果你是个 Rust 开发者它只能当快速起稿器。5. 面向真实的工程化场景上下文、重构与真实的持久化5.1 长上下文6K 是一道坎超过了要小心qwen3.5-9b 官方宣称支持长上下文但支持和好用是两回事。我模拟了一个典型场景把一个包含 5 个文件的小型 Flask 项目总共约 1500 行代码全部塞进对话然后让它新增一个 /export 接口将数据导出为 CSV。在前 4000 行内容范围内它给出的代码能直接匹配现有代码的风格和变量名但当我继续塞到 8000 行时它开始出现忘记某个路由已经存在的情况甚至自己提出的方案里用了一个和现有函数同名的辅助函数导致潜在命名冲突。所以我给的实操建议是不要一次性全量贴长文本要逐步喂入项目结构 当前文件的核心函数签名 本次任务描述。这也意味着虽然模型本身是长上下文设计在日常使用中你还是得当一个干净的人来管理上下文而不是把所有东西一股脑扔进去。5.2 多文件重构力不从心的重灾区多文件重构测试我设计了一个相当现实的场景现有代码使用了两个功能重叠的函数需要统一成一个并更新所有调用点。qwen3.5-9b 给的方案整体是对的但问题出在它没法真正同步所有改动——它在第一个文件的输出里已经用了新函数名在第二个文件却还在引用旧函数名并提示这里应同步修改。当模型说这里应同步修改的时候说明它知道需要改但没有能力在回复中自动维持全局一致性。我的应对方法实测有效拆成两轮提问。第一轮让它输出重构后的新函数定义第二轮把调用点文件列表贴给模型明确要求针对以下调用点逐一给出替换后的代码。两轮下来准确率远超一次性完成。这个 workaround 非常实用等于把多文件重构降低为单文件重写 批量替换审查。5.3 代码补全和 DSL 场景小体量模型的意外强项工程化场景里还有一种常见的需求填充模板代码。比如在已有脚手架里补一个方法、往 config 文件里添加一段 DSL 配置、生成一个迁移脚本。这类任务不需要创造新逻辑而是按照已有风格补全。qwen3.5-9b 在补全类任务上表现远好于从零生成。因为补全任务的信息密度高周围的代码天然充当了约束条件弥补了模型自身规划能力的不足——它只需要做风格匹配 逻辑填空。我在一个 SQLAlchemy 模型文件里测试给了已有两个模型类让它新增一个带外键关系的 Team 模型。它生成的字段名、命名规范、ForeignKey 使用方式与文件原有代码几乎一个模子刻出来的。这说明它的代码风格模仿能力相当强。5.4 很不擅长但容易踩坑的折磨人的测试数据生成测试数据生成听起来简单做起来非常考验领域知识 边界场景构造能力。我让它为一个支付系统生成单元测试用例要求覆盖余额不足、重复支付、并发扣款、部分退款四种场景。它生成了四个用例但并发扣款用的只是threading模拟完全没有触及数据库事务隔离性这个核心痛点。更深层的并发测试需要的是竞态条件分析能力对 9B 模型来说还是有点超过极限。如果你需要生成复杂业务测试数据建议把范围缩小到单测级别输入输出校验类不要把高并发一致性这种系统的关键验证交给小模型不然只会得到看似覆盖、实则漏测的结果这才是开发里最危险的坑。6. 定位与边界qwen3.5-9b 能进我的工具链吗六天实测下来我对 qwen3.5-9b 的编程能力给出一个明确的定位判断它是目前本地可跑模型阵营里最适合做代码解释、错误定位、单文件生成、风格化补全这四个方向的模型之一。如果只看绝对编程能力它比不上 32B 以上级别但在成本和响应速度之间取平衡它有不可替代的位置。什么场景最值得用它日常读代码时顺手注解一段复杂逻辑加快理解速度给一段报错堆栈 相关代码让模型先排查一遍再自己看写一轮先整体过一遍边界条件的 review它列出的 case 能帮你想问题的角度用三段式提示词快速产出 100-200 行以内的业务函数或脚本原型。什么场景我不建议用它大型多文件重构项目尤其是需要全局一致性的改名、接口变更需要深度领域判断的系统设计分布式一致性、高并发架构选型编译型语言的复杂生命周期 / 所有权推导Rust、C 模板元编程以及任何生成的代码将直接进生产没有足够测试覆盖的场景。回到开头那个问题qwen3.5-9b 是一款值得装进日常工具链的结对初级程序员。它会写代码但更需要你会读代码、会拆任务、会给上下文。你把它当成一个能力不错但需要明确指令的新同事协作效率最高你把它当成扔一句需求就自动产出生产级代码的魔法盒子大概率会失望。我个人在实际使用中的体会是小体量模型最大的优势不是聪明而是响应速度快、试错成本低、能随时随地在本地跑。我经常同时开三个它的会话一个解释代码一个写脚本一个做正则问答——这种并行折腾的方式在调用 API 模型时根本舍不得。如果你手上有足够的内存资源我建议别只看参数大小先把我这套测试用例跑一遍看看它在你的典型任务上表现得如何。很多能力单看Benchmark是判断不了的得亲手调几次才知道。