用 Claude Code 一段时间之后，最让人心里发紧的是账单。它跑起来会读很多文件、来回执行命令，token 消耗和网页版聊天完全不是一个量级。

社区里的标准做法是换成国内的模型接口，单价差距确实很大。搭法上 Arguo 那篇《在 WSL2 上用 Claude Code + DeepSeek API》把安装到配置的步骤写得很细，我照着走通了，这篇只记用下来之后的体验差距，以及成本这笔账里容易漏掉的部分。

搭起来需要一个转换层

Claude Code 说的是 Anthropic 的 API 格式，DeepSeek 早期提供的是兼容 OpenAI 的接口，两边不能直接对接，中间要有一个转换层。

后来 DeepSeek 自己提供了 Anthropic 兼容端点（api.deepseek.com/anthropic），配一个 ANTHROPIC_BASE_URL 就能直连。我仍然用自写的本地转发服务，理由只有一个：可控——出问题的时候我知道是格式转换的问题还是模型的问题，日志在我手里。

搭好之后配两个环境变量指向本地代理就行。整套东西跑在本地，密钥不进仓库。

简单任务：几乎没差别

我一开始的测试范围很保守，结果比我预期好：

  • 改一个函数的实现，加上边界处理
  • 写一段小脚本，处理固定格式的文件
  • 解释一段不熟悉的代码在干什么
  • 补测试

这几类任务上，便宜模型和官方模型的表现差别小到可以忽略。速度快慢有波动，但都在可接受范围。

复杂任务：差距很具体

真正拉开差距的是三类场景。

跨多文件的改动。 任务涉及五个以上文件、需要保持一致的命名和接口时，便宜模型更容易顾此失彼——改了 A 忘了 B，或者改了 B 但没同步更新调用方。

长链路工具调用。 需要连续执行十几步命令、中途根据报错调整策略的任务，它更容易在中途跑偏：把之前说好的约定忘了，或者在一个错误的方向上反复试。

长会话。 会话越长，差距越明显。官方的模型在长上下文里保持约定的能力更好；换过去之后，我明显感到它需要我重复提醒的频率变高了。

还有一类问题不属于能力，属于兼容性：格式转换层偶尔会处理不好某些工具调用的返回结构，报一些看不懂的错。这类问题得靠看日志排查，不比调试自己写的代码轻松。

成本这笔账没那么简单

这是我最想说的部分。单价差距确实巨大，但账单差距没那么大，原因有三个。

第一，缓存机制不一样。 官方接口对重复的上下文前缀有显式的缓存控制，而 Claude Code 的工作方式恰好是”同一段上下文反复带上”，命中率高。DeepSeek 走的是自动前缀缓存，机制不同、命中率也未必一样，折扣吃不满。这一条吃掉了相当一部分单价优势。

第二，失败重试变多。 一个任务在便宜模型上可能要来回四轮才做对，官方模型两轮搞定。单价差十倍，轮数翻倍，实际省下的就只剩五倍左右。

第三，人工纠错的时间。 这部分不进账单，但进你的时间。我试过用它做一个跨模块的重构，最后自己动手改的时间比盯着它改还长。

所以”便宜几十倍”是单价，不是账单。我的经验是实际差在三到五倍的量级——依然很值，但不是宣传里的数字。

我现在的分工

简单粗暴地按任务复杂度分流：

  • 走便宜通道：机械性改动、批量处理、补测试、代码解释、探索性提问
  • 走官方通道：跨模块重构、需要长链路执行的任务、需求本身模糊需要它帮我澄清的活

切换成本就是改一个环境变量，所以我不纠结”要不要全换”，而是每次看任务决定。这件事做久了会形成直觉。

一点提醒

代理进程的稳定性会影响一切。 它是单点，挂了所有请求都失败，而且报错信息看起来像模型的问题。我后来给它加了日志和健康检查。

注意计费口径。 不同渠道对缓存、批量、失败重试的计费规则不一样，别只看单价页面上的数字。

成本与能力的取舍

这是成本和能力之间的取舍，不是”谁能替代谁”。

有意思的是，这种取舍反过来让我更清楚自己每天在干的活里，哪些是真正需要强模型的。以前不加区分地全用最强的，其实有一半的任务是在浪费钱。