把本地大模型当秘书用了一周，才发现最该交给它的是写代码

我跑本地推理硬件的规模，已经大到电力公司每年给我寄圣诞贺卡。所以当我决定花一周时间，把所有日常事务都交给一个本地大模型处理时，我以为自己很清楚那条线该画在哪里。本地模型负责日常琐事——摘要、研究筛查、草稿、无休止的“这个报错是什么意思”——编程工作继续留在前沿云端模型上，因为编程才是硬骨头。这套哲学我执行了一年多：简单的事给本地，重要的事上云端。

一周后，我发现事情完全反了。日常任务恰恰是本地模型悄悄让人失望的地方，而那块我一直小心隔离起来的编程工作，才是它真正被设计来做的事。不需要等到周末复盘，中间我就看清了问题所在，任务划分的正确方式，跟我搭建这套系统时的设想正好相反。

## 我定的规矩当时看起来挺合理

直觉本身不是没来由，只是瞄偏了。架设起来其实很简单：在 Strix Halo 盒子上通过 Lemonade Server 跑 Qwen3-Coder-30B-A3B，网络可达，RTX 5090 机器待命处理更大上下文。平时扔给云端聊天机器人的事情，统统转到本地：文章调研、日志翻查、变更摘要、文章选题脑暴，什么都往里塞。编程继续留在 Claude 和 Codex 上，Zed 做一点简单编辑——我已经内化了“编程是模型质量决胜的领域”这个认知，见识过太多半幻觉的 shell 脚本，不敢冒险。

这份警惕并非来自对 AI 的普遍不信任。云端前沿模型在编程的自动化智能体那一侧确实碾压——多文件重构、模糊需求、零样本提示、从工具调用失败中恢复，每一项它们都做得更好。我的错误在于，把这种差距放大到了所有编程场景，同时把日常非编程任务归进“简单模式”。它们并不简单，只是难在不同的维度上。

## “什么都行”的一周过得还行，而“还行”本身就是问题

头几天，实验看起来成功了。本地模型能帮我总结网页或 GitHub 仓库，给出像样的安装步骤。回答事实问题也还算到位，从不触发速率限制，也从不催我升档或加 API 额度。有一回因为雷暴断网，它依然照常工作。

但“还行”从来不是真的没问题，只是使用成本从订阅费悄悄转移到了时间上。我卸给本地模型的每一项任务，都变得难以验证。作为测试，我试着对照原始材料看摘要的质量，接着就停不下来地继续这样做了——因为我没法一直信任输出。我请它做研究筛查，它要么遗漏了随手就能搜到的材料，要么自信满满地引用一些不存在的东西。

举个例子，我让它总结 OpenClaw 并告诉我怎么安装。结果是能用的，当然，非常肤浅。

但我没意识到这种模式，直到我回头审视那些被“还行”消磨掉的额外时间。每一份摘要都要人为复核一遍，每一个引证都要去确认出处，每一次所谓的“研究筛查”之后我还是要自己动手翻一遍资料。这些事情看起来省时间，实际上把验证成本转移到了我看不到的地方，等意识到时，我在这上面花的时间已经超过直接自己干。

## 反倒是代码，它干得干干净净

编程那边的体验截然不同。由于我把编程严格限定在本地模型之外，最初几天我根本没给它机会。后来有一次出于好奇，扔了个小脚本的需求过去——不是什么模糊的大工程，就是一个明确的、边界清晰的自动化需求，我可以立刻验证对错。它给出的代码不是“还行”，而是直接跑通，没有幻觉出来的参数名，没有不存在的 API 调用。我验证的成本近乎为零，因为代码本身就是最终裁判：能跑就是能跑，不能就是不能。

这个反差让我重新审视了自己的整个分界逻辑。我原本认为编程是高风险工作，容错率低，必须用最强的模型。但恰恰因为编程有明确的可验证性——编译通过、测试通过、行为符合预期——它反而对模型的事实准确度要求没那么苛刻。代码是高度形式化的语言，就算生成过程中出现一些小偏差，运行时就会暴露出来，修复路径清晰。

而日常文本任务是另一回事。一封邮件的草稿看起来流畅得体，我怎么判断它是否恰好传达了我想表达的微妙立场？一篇会议摘要措辞自然，我如何知道它没有漏掉某个我事后才发现关键的点？这些任务看起来简单，但验证成本极高，且验证行为本身就要求我投入与原始任务相当的精力。模型在这些场景下的“还行”会产生一种麻醉效果，让人慢慢放弃深度核查，等到问题浮现时往往已经来不及。

## 不是模型能力的差距，是任务验证成本的差距

回到开头那个问题：为什么我的分界逻辑完全反了？答案不在模型能力本身，在于我忽略了“验证成本”这个维度。对编程而言，验证几乎是自动化的——代码要么能跑，要么不能；即便能跑，单元测试也能在几秒内给出更确信的答案。对日常文本而言，验证需要的是我全部的认知和判断力，没有捷径。

所以实际应该这样划分：把那些可以自动验证或低成本验证的任务优先交给本地模型，比如编程、脚本编写、结构化数据处理、需要精确格式输出的内容。而那些验证必须依赖人力判断、阅读比对、背景知识的高模糊度任务——摘要、研究筛查、观点型草稿——恰恰应该留在更可靠、事实准确性更高的地方，或者至少不应该在没有验证流程的情况下全权委托。

这不是说本地模型不行。恰恰相反，在它擅长的东西上，它强得让人意外。Qwen3-Coder 这个系列的模型名字里带着“Coder”是有道理的，它在编程任务上的能力被我在观念上打了折扣，只因为我把整个“编程”类别和“前沿模型独占的复杂编程场景”混为一谈。实际上，大量日常编程工作——写个小工具、处理数据、配置脚本——完全落在本地模型的能力区间内，而且由于代码的强可验证性，风险极低。

重新画那条线

现在我的使用习惯已经反转了。编程任务优先走本地模型，尤其是那些边界清晰、可以立即跑起来验证的工作。云端模型负责的事情变成了：模糊需求的探索性对话、多文件重构、以及任何输出需要我花大量时间阅读比对才能判断质量的文本任务。那条线不再是“简单与困难”之分，而是“能否低成本验证”。

这套逻辑甚至可以进一步泛化。选择将一项任务交给哪个模型，核心问题不是任务本身的复杂度，而是“我验证它是否正确要花多少时间”。对于代码、数学计算、格式转换这类输出可以直接机器判断的任务，本地模型的表现往往足够好；对于摘要、文案、情报提炼这类输出质量只能靠人肉校准的任务，无论模型大小，分派时都必须附带验证流程和时间成本的算计。

一周的实验告诉我一个道理：不要让自己的惯性认知替模型做能力评估。真正有效的判断，是拿着具体的任务、具体的验证成本去实测，而不是按照“代码=难”“聊天=简单”这种粗糙分类去分配。那条你深信不疑的边界线，很可能正好画反了。