Qwen3.6 35B + 合适脚手架，本地跑真实 Go 任务 9/10 通过

我想验证的问题不是“某个开源模型能否单挑 GPT-5.4 Codex”，而是：把本地模型、脚手架、修复循环和路由策略全跑在家用硬件上，能不能在我真实的 workload 里逼近前沿代码模型？简答：可以，而且出乎意料地近。在我挑的 10 个真实 Go 任务里，路由本地流程拿到 9/10 通过。相关链接：\- little-coder: [https://github.com/itayinbarr/little-coder](https://github.com/itayinbarr/little-coder)\- 触发本次实验的文章: [https://open.substack.com/pub/itayinbarr/p/honey-i-shrunk-the-coding-agent](https://open.substack.com/pub/itayinbarr/p/honey-i-shrunk-the-coding-agent)* GPT-5.4 best-of 基线 10/10* 路由本地流程 9/10* Qwen3.6 + little-coder 8/10* Qwen30 + little-coder 5/10* 原始本地 Gandalf 裸 harness 3/10这不是公开 benchmark，而是从我自己的 Go 仓库里抽 10 个真实任务，用复制的工作区跑，绝不碰线上仓库。任务涵盖 CLI 改动、依赖检查、内嵌版本文件、时钟抽象、错误分类、SQLite 原语、迁移、基线 schema 等。\## 硬件本地配置：* RTX 5090 32GB 跑 Ollama，代号 **Frodo*** RTX Pro 6000 96GB 作更大本地修复/编辑角色，代号 **Gandalf*** Qwen3.6 35B A3B Q4_K_M 跑在 5090 上* Qwen3-Coder 30B 也本地可用* Qwen3-Coder-Next 80B 通过 vLLM/OpenAI 兼容端点跑在 Gandalf 上Qwen3.6 在 5090 上占约 27GB 显存，还能留足空间给 embedding 服务。\## 关键在脚手架最大的提升不是换模型。之前我用简陋的本地 Aider 式 harness 包 Gandalf，同样任务只能 3/10。能用，但明显打不过前沿 agent。后来看到“本地代码模型常被放在不匹配的脚手架里测试”的观点，就试了 little-coder + Qwen3.6 35B，结果大变：单靠这对组合就 8/10。失败的两题：* 一道确定性 fake-clock / timer / ticker 任务* 一道 SQLite 任务，重跑后过了路由本地流程靠以下组合冲到 9/10：* Qwen3.6 + little-coder 作默认本地实现者* Qwen30 + little-coder 专门对付 fake-clock/timer/ticker 型任务* 确定性后置修复：`goimports`、`gofmt`、`go mod tidy`、`go test -timeout`* Gandalf 直接文件修复，解决狭窄编译/导入/schema 错误当前路由结果：little-coder-routed-local: 4.60/5 均分 | 9/10 通过 | $0.00 | 1489s逐题：001 过 002 过 003 过 004 过 005 过 006 失 007 过 008 过 009 过 010 过剩下那道失败仍是确定性 fake-clock 任务：要把 timer、ticker、调度截止、goroutine 唤醒与泄漏行为全部写对。本地模型给出的实现要么死锁，要么 tick 时机错误。\## 意外发现Qwen3.6 在模块级 Go 任务上比 Qwen30 强得多，特别是 store/迁移/schema 这类题 Qwen30 做不出来。但 Qwen3.6 并非全面碾压：Qwen30 曾一次跑通 fake-clock，而 Qwen3.6 始终挂。完整路由跑里，连 Qwen30 也因方差挂掉。这让我确信，关键抽象不是“选最强模型”，而是“按任务形态和失败模式路由”。本地系统应自动决策：通用 Go 模块工作 -> Qwen3.6 + little-coderSQL/存储/迁移工作 -> Qwen3.6 + little-coder狭窄编译/导入失败 -> 本地 Gandalf 修复Timer/ticker/并发 bug -> 专用 playbook 或前沿模型我不想手动当交通警察。harness 应收集任务形状、模型选择、结果、修复次数、耗时，然后喂给自动路由器。\## 我对 harness 做的改动几条实践细节影响巨大：1. 只在复制工作区跑 eval，绝不让 agent 碰线上仓库。2. 强制 `go test` 超时，否则 fake-clock bug 会挂到地老天荒。3. 确定性清理外包：`goimports`、`gofmt`、`go mod tidy`。4. 让修复编辑可被机器解析：对 Gandalf 用直接 JSON 文件修复，而非自由聊天式。5. 测试与 testdata 只读，但允许非 Go 实现产物如 `.sql`、`VERSION`。6. 每次运行落盘：状态 JSON、测试日志、diff、报告。`go test -timeout` 封装尤其关键，之前一道坏 fake-clock 就能吃掉整个 eval 周期。\## 免责声明这不是说 Qwen3.6 打败 GPT-5.4 Codex。GPT-5.4 在这 10 题上仍是 10/10，本地路由 9/10。且样本只有 10 题，来自一个仓库，对我真实 workload 有用，但不算通用 coding benchmark。我更在乎的结论更窄：对我的 Go workload，本地脚手架 + 路由流程已足够接近，可以把日常任务默认跑本地，把前沿模型留给更难的题和已知失败类。这对成本和速率限制是巨大胜利。\## 当前结论模型重要，但脚手架比我想象的更重要。Qwen3.6 35B 本地已够强，但只有在搭配以下元素后才真正好用：* little-coder* 任务专属路由* 确定性 Go 修复* 本地修复* 真实任务 eval 反馈下一步让路由器更聪明：* 默认跑 Qwen3.6* 狭窄本地失败本地修* fake-clock/并发/时间语义上升到前沿或专用 playbook* 持续记录结果，让路由策略自我进化这才是正路：不是让某个本地模型去“模仿 Codex”，而是让本地代码系统知道何时、如何用哪个模型。（我写的，Codex 5.4 润色）