很多人想把 Claude Code 这类命令行编码助手接到自己的机器上跑，看到「免费」就直接装 Ollama 试，结果卡在模型选错、上下文不够、工具调用不认这几步上。这篇不吹「完全替代」，只给一条能走通的路径：先判断你的任务适不适合本地模型，再挑模型和量化档位，然后按顺序把接口接上，最后用几个固定任务验收。跑不通也知道卡在哪。
很多人想把 Claude Code 这类命令行编码助手接到自己机器上跑，一看到「免费」两个字就直接装 Ollama 试，结果卡在三个地方：模型选错、上下文不够、工具调用不认。这篇不吹「完全替代」，只给一条能走通的路径：先判断任务适不适合本地模型，再挑模型和量化档位，然后按顺序把接口接上，最后用固定任务验收。跑不通也知道卡在哪一层。
需要先说清楚一点：本地跑不等于零成本。你省掉的是订阅或调用费用，花掉的是显存、电费和调环境的时间。所以判断标准不是「免费不免费」，而是「你的任务用本地模型做，返工率能不能压到可以接受」。这个判断只能靠验收清单跑出来，不能靠感觉。
先判断：这套玩法适合谁、什么时候别碰
| 场景 | 本地模型能不能扛 | 说明 |
|---|---|---|
| 内网或断网环境 | 适合 | 代码不出本机是硬需求，别的方案直接不成立 |
| 补全、改写、单文件小改 | 适合 | 上下文短、目标明确，本地模型成功率不低 |
| 跨多个文件的架构级重构 | 大多不适合 | 需要长时间保持全局一致性，本地模型容易中途跑偏 |
| 长链路自主规划的 agent 任务 | 大多不适合 | 要反复试错和自我纠错，本地模型在工具调用上更容易掉链子 |
- 适合的场景：内网或断网环境、代码不便出本机、任务以补全和改写为主、单次改动范围小。
- 不适合的场景：跨十几个文件的架构级重构、需要长链路自主规划和反复试错的 agent 任务，本地模型容易中途跑偏。
- 先过硬件门槛：显存决定你能跑多大参数的模型，参数量和量化的对应关系可以到 /tools 的部署测算相关页面按自己的卡算一遍。
- 如果只是想让代码写得快一点、也能接受把代码发出去，那直接用云端编码套餐更省事，别为了省订阅费耗掉两天调环境。
判断顺序建议从上往下：先问代码能不能出本机，不能出就直接走本地；能出再问任务类型，小改走本地、大改走云端。这个判断做完，后面的步骤才有意义，否则你很可能在为一个根本不适合的场景调环境。
挑模型与量化档位：按任务类型分，不按跑分分
代码任务优先看两类模型：一类是专门的代码模型，一类是通用模型里工具调用能力稳的版本。具体哪些现在好用，不要看别人半年前的文章，到 /models 的模型库和开源模型比价页对一遍当时的清单，那里会更新可用列表和大致体积。
- 量化档位
- 显存和质量的取舍，显存够往上留一档，显存紧往下压一档但要接受长文件里更容易丢细节
- 参数规模
- 不是越大越好，补全和单文件改写这类任务上，参数量翻倍的体感提升经常不明显，反而拖慢每次等待
- 工具调用能力
- 比跑分更关键的一项，决定模型能不能按格式读写文件和执行命令，选之前先确认这类支持的说明
- 先按任务类型圈定候选，再按显存筛掉跑不动的，不要反过来。
- 量化原理和档位含义可以查 /glossary 术语词典里的量化词条，别凭标签数字猜。
- 把模型名字和标签记清楚，标签写错会直接拉不到模型，排查思路可以对照 /guides 里「ollama 指定模型怎么设置」那篇。
- 选完先跑一个最小任务，别急着接助手，模型本身都答不利索的话，接线再顺也没用。
有一点要写明白：这条经验在「模型刚好卡在你的显存上限」时不适用。那种情况下压一档量化往往比换小模型更划算，因为小模型在代码任务上的理解损失通常更明显。到底压哪一档，到 /tools 的测算页按你的实际卡填一遍。
接线步骤：从本机服务到编码助手的顺序
- 第一步：本机服务先跑起来启动本地服务后确认端口能访问，用一次最简单的请求验证通了再往下走。这一步不通，后面所有报错都别猜。
- 第二步：确认接口格式编码助手一般走兼容接口，地址和路径要写对。地址格式参考 /guides 里「本地部署 ollama 服务的 api 地址」那篇，照着填。
- 第三步：配置助手一侧填模型名和环境变量，环境变量写错是最常见的失败原因。配置项逐条对照 /guides 里「ollama 配置 claude code」那篇走，别跳项。
- 第四步：设上下文长度和超时本地推理首字延迟比云端高，超时给太短会表现为「没反应」，其实还在算。先给宽松值，跑通后再收紧。
接线阶段最忌讳一次改好几个地方。每改一项就单独验一次，确认这一项没问题再动下一项。这样出问题时你能立刻定位到是哪一步引入的，否则只能全量回滚重来。
验收清单：跑通不等于能用
服务通了只是「能连上」，不代表「能用」。用三个固定任务验收：一个小函数的补全、一个跨两个文件的改动、一个必须读你项目里已有代码才能改对的任务。三个都过，再考虑投入日常使用。
| 验收项 | 怎么算过 | 不过说明什么 |
|---|---|---|
| 单函数补全 | 一次写对或小改就能用 | 模型基础能力不够，换模型或升量化 |
| 跨两文件改动 | 两处都能改对且不冲突 | 上下文长度或理解能力不足 |
| 读现有代码再改 | 能正确引用你项目里的实际写法 | 工具调用或上下文召回有问题 |
| 工具调用 | 能按格式读写文件、执行命令 | 这是模型能力问题，不是配置问题 |
- 记录每次响应时间和手动返工次数，返工率高于自己手写，就说明这个模型这档量化不适合你的任务。
- 换模型或换量化档位后重新跑一遍这张清单，别凭感觉说「好像变快了」。
- 把三个验收任务存成固定用例，每次环境变动后复用，保证对比口径一致。
- 如果只有第一个任务过、后两个不过，说明模型够用但上下文配置不到位，先调配置再考虑换模型。
这套验收标准在一种情况下不适用：你的任务本来就只需要单文件补全，那第三个任务可以砍掉，用前两项当标准即可。判断标准要跟着任务类型走，不要机械照搬。
跑通只是接线成功，验收过关才是能用来干活。下一步如果你已经跑通服务但不确定该选哪个模型、该不该降量化，先到模型库和部署测算页对照你的卡和任务类型看当时的清单，再决定要不要投入日常使用。→
常见问题
用 Ollama 跑本地模型代替 Claude Code，真的能免费吗？
软件本身不收费，但成本转移到硬件、电费和你的调试时间上。如果本来就有能跑得动的显卡，边际成本接近零；如果为了这事专门买卡或租卡，算下来不一定比订阅便宜。判断方法很简单：把调试花掉的小时数按你的时薪折算，再看要不要走这条路。
接上之后助手没反应或者一直转圈，先查哪里？
按顺序查三层：本地服务进程还在不在、端口能不能访问；接口地址和路径写得对不对；助手侧配置的模型名是不是和本地实际拉下来的标签一模一样。这三层任意一层错都会表现成「没反应」，从最里面一层往外查最快。
本地模型写代码会不会比云端差很多？
分任务看。补全、改写、写测试这类范围明确的任务，本地中大参数模型表现够用；需要跨文件理解、长链路自主规划的任务，差距会明显放大。所以建议先拿自己的真实任务跑一轮对比，而不是看别人的结论下判断。具体哪个模型在什么档位上表现如何，去模型库和比价页看当时的数据。
