企业官网建设流程全解析

1. 为什么我要花一整个周末测这个模型

上周五晚上十一点，我盯着终端里 qwen3.5-9b 吐出来的那段 Python 代码，心里只有一个念头：这玩意儿到底能不能替我把那堆重复的 CRUD 脚本全写了。作为一个写了十年代码、最近两年把大量精力放在本地模型部署上的老油条，我对"9B 参数级别模型能写代码"这件事一直持保留态度。7B 到 14B 这个区间，过去给我的印象就是"能跑，但别指望"，生成的代码要么缺边界处理，要么 import 一堆根本不存在的库，改起来比自己写还累。

但 qwen3.5-9b 这个版本有点不一样。它在社区里的讨论热度明显高于同级别的其他模型，尤其是"编程能力"这个标签被反复提及。我决定不再看别人的评测截图，自己动手做一轮完整的实测。测试环境选的是 Ollama，原因很简单：本地部署最省心，一条命令拉模型，不用折腾 CUDA 版本和 Python 依赖冲突。整个测试围绕四个维度展开——基础语法生成、算法题求解、真实项目重构、以及一个很多人忽略但极其关键的变量：思考模式（thinking mode）和 temperature 的配合。

这篇文章不是那种"跑个 hello world 就吹爆"的软文。我会把每个测试用例的 prompt、模型输出、我的修改过程、以及最终结论全部摊开讲。如果你也在犹豫要不要把 qwen3.5-9b 纳入你的本地开发工作流，或者你已经在用 Ollama 但不知道怎么调参才能让代码生成质量上一个台阶，那这篇实测记录应该能帮你省下至少一个周末的试错时间。

先说结论方向：这个模型在编程任务上的表现超出了我对 9B 级别的预期，但它有一个非常明显的"脾气"——思考模式开不开、temperature 设多少，直接决定了输出是"能用"还是"垃圾"。这个发现比模型本身的参数大小重要得多。

2. 测试环境搭建与模型拉取的那些坑

2.1 Ollama 安装与国内网络环境下的模型获取

Ollama 的安装本身没什么难度，Windows 下就是一个 exe 双击到底，macOS 和 Linux 也就是一行 curl 脚本的事。但真正卡住大多数人的不是安装，是拉模型。qwen3.5-9b 的默认量化版本大概是 5 到 6 个 GB，走官方源在国内的网络环境下，下载速度经常掉到几百 KB 每秒，甚至直接断连。我试过三次，最长的一次挂了四十分钟才下完。

这里分享一个我实测有效的做法：Ollama 支持通过环境变量指定模型仓库的镜像地址。你不需要改任何配置文件，只需要在启动 Ollama 服务之前设置好对应的变量就行。具体操作是在终端里先导出环境变量，然后再启动服务。Windows 下则是通过系统环境变量面板添加，重启终端后生效。设置完之后再执行拉取命令，速度能从几百 KB 直接拉到满带宽。

另一个更稳妥的方案是离线导入。如果你手头已经有 gguf 格式的模型文件，可以直接写一个 Modelfile，用FROM指令指向本地的 gguf 路径，然后ollama create导入。这种方式完全不依赖网络，适合在公司内网或者网络不稳定的环境下操作。Modelfile 里还可以预设 temperature、num_ctx 这些参数，相当于把调参结果固化下来，后面每次调用都不用重复指定。

注意：Ollama 默认的模型存放路径在系统盘的用户目录下，qwen3.5-9b 加上你后续可能拉的其他模型，很容易把 C 盘撑爆。建议在安装完成后第一时间通过环境变量把模型路径迁移到空间更大的数据盘，迁移前记得把已有模型文件手动拷贝过去，否则 Ollama 会认为模型不存在而重新下载。

2.2 确认模型版本与量化等级

拉取完成后，第一件事是确认你拿到的是哪个量化版本。执行ollama list可以看到模型名称和大小。q4_k_m 是我推荐的默认选择，它在 9B 这个级别上做到了质量和体积的平衡。如果你机器显存充足（比如 12GB 以上），可以尝试 q5 或 q8 版本，代码生成的准确率会有可感知的提升，尤其是在处理复杂类型推断和长函数生成时。但如果你只有 8GB 显存，q4_k_m 是唯一现实的选择，再往上会频繁触发 CPU 回退，生成速度直接掉到不可用的程度。

还有一个细节：Ollama 拉下来的模型默认上下文长度是 2048 或 4096，对于编程任务来说这远远不够。你贴一段两百行的代码进去，加上 prompt 本身，很容易就超了。超了之后模型会直接截断前面的内容，导致它"忘记"你给的函数签名或者类结构。解决办法是在 Modelfile 里把 num_ctx 调到 8192 甚至 16384，代价是显存占用会增加，生成速度会略微下降，但对于代码理解任务来说这个代价完全值得。

3. 编程能力实测：从基础语法到真实项目重构

3.1 基础语法与工具函数生成

第一轮测试我选了五个日常开发中高频出现的小任务：写一个带重试机制的 HTTP 请求函数、实现一个 LRU 缓存、解析嵌套 JSON 并做扁平化、写一个 cron 表达式解析器、以及生成一个 SQL 查询构建器。每个任务我都用相同的 prompt 模板，只改变具体需求描述，temperature 统一设为 0.2，思考模式关闭。

结果出乎意料地好。五个任务里有四个一次通过，生成的代码可以直接运行，没有语法错误，没有幻觉 import。唯一出问题的是 cron 解析器，模型把*/5这种步进表达式的边界条件处理错了，把"每 5 分钟"解析成了"第 5 分钟"。但这个错误在我手动指出后，模型立刻给出了修正版本，而且修正后的代码逻辑完全正确。

这里有一个值得说的细节：qwen3.5-9b 在生成工具函数时，会主动加上类型注解和 docstring。这一点比很多同级别模型强，说明它在训练数据里吸收了相当数量的高质量 Python 代码。但它的 docstring 有时候会写得过于啰嗦，把每个参数都展开成三行，对于内部工具函数来说有点冗余。我的做法是在 prompt 里明确加一句"docstring 保持一行简洁描述即可"，这样输出就干净多了。

3.2 算法题求解与复杂度分析

算法题我选了 LeetCode 上中等难度的五道：二叉树层序遍历变体、最长回文子串、岛屿数量、课程表拓扑排序、以及一道动态规划题。这次我把思考模式打开，temperature 设为 0.1。

思考模式打开后，模型会在正式输出代码之前先"自言自语"一段推理过程。这个推理过程有时候比最终代码还有价值，因为它会暴露模型对题目的理解路径。比如在最长回文子串那道题上，模型先尝试了暴力解法，然后自己否定了，转而讨论中心扩展法和 Manacher 算法的取舍，最后选择了中心扩展法并给出了 O(n²) 的时间复杂度分析。整个过程逻辑清晰，没有跳步。

但思考模式有一个明显的副作用：生成速度会变慢，大概是关闭时的两到三倍。对于简单的算法题，这个等待时间有点浪费。我的建议是，如果你只是要一个快速参考实现，关掉思考模式就够了；如果你需要模型帮你分析算法选型或者优化思路，再打开它。

五道题里，四道一次通过，一道（课程表拓扑排序）在边界条件上出了小问题——模型没有处理空输入的情况。这个错误很典型，9B 级别的模型在"防御性编程"方面还是偏弱，它倾向于假设输入总是合法的。你在实际使用中，最好在 prompt 里明确要求"处理所有边界情况，包括空输入、单元素输入、以及非法输入"。

3.3 真实项目代码重构实测

这一轮是最有说服力的。我拿了一个自己两年前写的小型 Flask 项目，大概八百行代码，结构比较乱，路由、业务逻辑、数据库操作全混在一起。我的目标是让 qwen3.5-9b 帮我做一次分层重构，把路由层、服务层、数据访问层拆开。

操作方式是把整个文件内容贴进 prompt，加上一句"将这个 Flask 应用重构为三层架构，保持功能不变，输出重构后的完整代码"。num_ctx 设到 16384，temperature 0.15，思考模式开启。

模型花了大概四十秒生成结果。重构后的代码确实分成了三个模块，路由层只负责请求解析和响应构造，服务层承载业务逻辑，数据访问层封装了 SQL 操作。整体结构合理，函数命名也比原来清晰。但有几个问题：第一，它把两个原本有副作用的函数改成了纯函数，导致调用方需要额外处理状态更新；第二，它引入了一个新的依赖库来做数据验证，但没有在代码里说明需要安装；第三，有一个数据库查询的条件被它"优化"掉了，导致语义发生了变化。

这三个问题说明一件事：9B 级别的模型可以做结构层面的重构，但它对业务语义的理解还不够深，容易在"看起来更优雅"和"实际行为一致"之间选错。我的做法是，把重构任务拆成两步：第一步让模型只做结构拆分，不改任何逻辑；第二步再针对每个函数单独做优化。这样虽然多花一轮交互，但安全性高得多。

3.4 不同 temperature 下的输出质量对比

为了搞清楚 temperature 对代码生成的实际影响，我用同一个 prompt（实现一个带过期时间的内存缓存）跑了五组参数：0.0、0.1、0.3、0.5、0.8。每组跑三次，记录通过率和代码质量。

结论很明确：代码生成任务上，temperature 不要超过 0.3。0.1 是我实测下来最稳的值，既保留了一点灵活性，又不会让模型"放飞自我"。0.0 虽然也稳，但生成的代码有时候过于机械，缺少对特殊情况的自然处理。0.5 以上基本不可用，模型会开始编造不存在的库函数和方法名。

4. 思考模式与上下文参数的深度调优

4.1 思考模式到底在做什么

qwen3.5-9b 的思考模式本质上是一种"链式推理"的外显。开启后，模型会在生成最终答案之前，先输出一段内部的推理过程。这段过程不是给你看的"解释"，而是模型用来"打草稿"的。它会在里面尝试不同的方案、自我纠错、然后收敛到一个它认为最优的解。

这个机制对编程任务特别有用，因为写代码本身就是一个需要多步推理的过程。你需要先理解需求，再设计数据结构，再考虑边界条件，最后才是写具体语句。关闭思考模式时，模型相当于"脱口而出"，对于简单任务没问题，但复杂任务就容易漏掉步骤。开启后，它有了一个"想清楚再写"的机会。

但思考模式不是万能的。我实测发现，对于长度超过 300 行的代码理解任务，思考模式反而会拖后腿。因为模型的思考过程会占用大量上下文窗口，导致真正需要它关注的代码细节被挤掉。这种情况下，更好的做法是关闭思考模式，但把 num_ctx 调大，让模型有足够的"工作内存"来容纳代码本身。

4.2 num_ctx 与 num_predict 的配合

num_ctx 控制的是模型能"看到"多少 token，num_predict 控制的是模型能"写出"多少 token。这两个参数需要配合调整。如果你只调大 num_ctx 而不动 num_predict，模型可能会在生成到一半时被截断，输出不完整的代码。

我的经验值是：对于代码生成任务，num_ctx 至少设为 8192，num_predict 设为 4096。如果你要模型重构一个完整文件，num_ctx 拉到 16384，num_predict 拉到 8192。再往上，大多数消费级显卡就扛不住了，会开始使用共享内存，速度断崖式下跌。

还有一个隐藏参数是 num_thread，它控制 CPU 推理时的线程数。如果你有独显，这个参数基本不用管。但如果你是纯 CPU 推理（比如在笔记本上跑），把 num_thread 设成物理核心数而不是逻辑核心数，实测能快 15% 左右。超线程在这个场景下帮助不大，反而会增加调度开销。

4.3 如何强制模型"不思考"

有些场景下你确实不需要思考模式，比如你只是想让模型帮你补全一个明显的代码片段，或者做简单的格式转换。但 qwen3.5-9b 有时候会"自作主张"地进入思考状态，即使你没有明确要求。

我试过几种方法来抑制这种行为。最有效的是在 prompt 开头加上明确的指令，比如"直接输出代码，不要任何解释和推理过程"。但这个方法不是百分之百管用，模型偶尔还是会先写一段"让我想想"之类的话。另一个方法是在 Modelfile 里把 temperature 设到 0.0，同时加上 stop 参数，让模型在遇到特定标记时立即停止。但这个做法比较激进，可能会影响正常输出。

实际用下来，我觉得最省心的方式还是接受模型偶尔的"思考"，然后在后处理时用脚本把推理段落过滤掉。毕竟对于本地部署来说，多等几秒换更准确的代码，这笔账是划算的。

5. 常见问题与排查技巧实录

5.1 模型输出乱码或重复

这是 Ollama 本地部署最常见的问题之一。表现是模型生成的代码里出现大量重复的 token，或者突然开始输出无意义的字符。根本原因通常是显存不足导致的计算错误，或者是 num_ctx 设得太大超出了模型的实际支持范围。

排查步骤很简单：先用ollama ps看模型是否完全加载到了显存里。如果显示部分在 CPU 上，那就是显存不够，需要降低量化等级或者减小 num_ctx。如果显存没问题，那就检查 num_ctx 是否超过了模型训练时的最大长度。qwen3.5-9b 官方支持的最大上下文是 32768，但实际使用中超过 16384 后质量就会明显下降。

5.2 生成的代码缺少 import

这个问题在 temperature 偏高时特别容易出现。模型会使用某个库的函数，但忘记在文件开头加上 import 语句。解决办法有两个：一是在 prompt 里明确要求"包含所有必要的 import"；二是把 temperature 降到 0.2 以下。我实测下来，temperature 0.1 时这个问题基本不会出现。

5.3 模型"忘记"前面的对话内容

多轮对话中，模型有时候会突然不记得你之前给它的函数签名或类结构。这几乎总是因为上下文超限导致的截断。Ollama 默认的上下文管理策略是"滑动窗口"，超出部分直接丢弃。你需要做的是主动控制每次输入的 token 数量，或者把关键信息在每轮对话中重复一遍。更彻底的做法是使用支持上下文压缩的前端工具，比如 AnythingLLM 这类，它会在上下文快满时自动做摘要压缩。

5.4 生成速度突然变慢

如果你发现之前跑得好好的模型突然变慢了，第一件事是检查是否有其他进程占用了显存。浏览器、视频播放器、甚至某些聊天软件都会占用显存。第二件事是检查 Ollama 是否在后台同时加载了多个模型。执行ollama ps可以看到当前加载的模型列表，如果有多个，用ollama stop把不需要的停掉。第三件事是检查系统是否在后台做磁盘整理或杀毒扫描，这些操作会大量占用 IO，导致模型加载变慢。

5.5 常见问题速查表

6. 我的最终配置方案与使用建议

经过这一轮完整测试，我目前固定在用的配置是这样的：模型用 qwen3.5-9b 的 q4_k_m 量化版本，num_ctx 设为 8192，num_predict 设为 4096，temperature 根据任务类型在 0.1 到 0.2 之间切换。简单补全和格式转换用 0.1，需要一定创造性的重构任务用 0.2。思考模式默认关闭，只在做算法分析和复杂重构时打开。

这套配置在我的机器上（RTX 4070 12GB）跑下来，生成速度大概是每秒 35 到 45 个 token，对于日常开发辅助来说完全够用。一个两百行左右的函数重构任务，从输入到拿到完整结果大概需要 20 到 30 秒。这个速度比等云端 API 的响应快不了太多，但胜在数据不出本地，而且没有调用次数限制，我可以反复让它改到满意为止。

如果你刚开始接触本地模型部署，我的建议是从 q4_k_m 开始，不要一上来就追求最高量化等级。先把整个流程跑通，把 Ollama 的模型路径、上下文参数、temperature 这些基础概念摸清楚，再根据实际体验决定要不要升级硬件或者换更大的模型。9B 这个级别对于大多数日常编程辅助任务已经足够了，真正限制体验的往往不是模型大小，而是参数配置和 prompt 写法。

最后分享一个我踩过的坑：不要用同一个对话窗口连续处理多个不相关的编程任务。模型会被前面的上下文"污染"，生成风格和思路都会受到影响。我的做法是每个独立任务都开一个新的对话，虽然麻烦一点，但输出质量稳定得多。这个习惯养成之后，我对 qwen3.5-9b 的满意度从"还行"直接变成了"真香"。