先说个背景：DeepSeek V4 Pro 出来之后，朋友圈里讨论得最多的就是怎么把它塞进 Claude Code 里用。Claude Code 的 agent 模式确实强，能自己读文件、改代码、跑命令、反复验证，比单纯粘贴代码给聊天机器人爽太多。但问题也很现实，Claude 的订阅成本不低，API 按量计费对高频使用者并不友好，外加一些地区的账号限制，让不少人卡在第一步。我自己花了两天把一套“零订阅”的链路跑通了——用 DeepSeek 的 API 通道接管 Claude Code 的模型请求，日常写脚本、做批量重构、跑测试全走这条路。这篇文章就是完整复盘，从环境准备、路由配置到真实任务实测和踩坑记录，尽量做到能直接照着操作。
这里说的“免费”，我得多解释一句：并不是彻底零费用，而是指你不必再为 Claude 的订阅或 Anthropic 的 API 充值。DeepSeek 平台注册会送体验额度，日常编码任务按量算下来成本极低，基本可以忽略不计，所以整体体验上接近免费。如果你本来就是 DeepSeek 的活跃用户，这套配置几乎不增加任何额外开销，这也是我愿意折腾的主要原因。
1. 为什么要把 DeepSeek 接到 Claude Code？——先算清成本账和选型逻辑
很多人看到这个标题的第一反应是：Claude Code 不是只能用 Claude 吗？换个模型还能用？答案是能。Claude Code 本质上是一个会调用模型接口的 agent 框架，它对模型的依赖是通过 Anthropic 风格的 API 协议完成的。只要有一个实现了这套协议的模型服务端点，Claude Code 就会认为对面是“Anthropic 兼容服务”，它不在乎请求最终是被哪个模型吃下去的。这个特性就是整个方案的基石。
Claude Code 的交互体验是我用过那么多 AI 编程工具里最接近“结对程序员”的。它会自己列出待办清单、逐个执行命令、失败后重新读报错再改，甚至能主动 diff 代码确认改动范围。但代价也写在明面上：如果你用订阅版，一个月固定的美元支出跑不掉；如果用 API，按 token 计费，一个复杂的重构任务跑几十轮对话下来，账单有点吓人。而对高频用户来说，每天开十几个 agent 会话是常态，成本就成了不可忽视的限制因素。
DeepSeek 的模型定价对开发者友好得多，输出 token 单价和 Claude 相比差一个数量级，上下文窗口和代码理解能力又足够支撑大多数工程任务。尤其是 V4 Pro 这代模型在代码生成、工具调用规范性上做了明显优化，和 Claude Code 的 agent 模式配合起来，已经达到“日常可用”的程度。反正我实际跑下来的体感是，一次几万 token 的重构任务，花费几乎可以忽略。
适合这套方案的，主要是这几类人：独立开发者、经常要用 agent 批量处理脚本的自动化爱好者、以及想在 Claude Code 上练手但不想立刻掏订阅费的初学者。如果你所在团队有严格的安全合规要求，必须走官方模型链路，那这套方案不适合你；但如果你是个人使用，或者研究性质地搭建自己的工作流，它值得一试。
1.1 先看看 Claude Code 的原始成本到底高在哪
Claude 的 API 是按输入和输出分开计费的，而 agent 模式最大的特点是“回合数多、上下文越滚越长”。你让它做一个稍微复杂的任务，它可能会读十几个文件，每次读文件都要把内容塞进上下文，然后调用工具、观察结果、继续推理。一个会话下来，输入 token 动辄几百万，哪怕单价再低，累积起来也不是小数字。订阅版虽然封顶，但一个月下来也不便宜，而且你要是想同时跑多个并发会话，限制会更明显。
DeepSeek 在这方面的逻辑完全不同。它的整体定价远低于 Anthropic，还经常有新用户体验额度，意味着你注册之后立刻就能开始跑任务，不用先绑卡充钱。对“低成本工作流”这个诉求来说，这就是零门槛入场。我个人的感受是：换成 DeepSeek 之后，我敢开的会话数量更多了，敢让 agent 去干更啰嗦的批量活了，这种“敢用”的心理变化，比省下的钱本身更值钱。
1.2 选型时为什么不是 Qwen、GLM，而是 DeepSeek
坦白讲，能接进 Claude Code 的第三方模型不止 DeepSeek 一家。阿里通义千问、智谱 GLM 甚至国外的开源模型，都能通过同一套兼容层接入。我最终锁定了 DeepSeek，原因有几个：第一，代码生成质量在目前的国产模型里是第一梯队，尤其在 Python、TypeScript、Shell 脚本这类常见场景下，生成代码的可直接运行率很高；第二，上下文窗口长，Claude Code 的 agent 交互会累积大量历史，窗口短的模型很快就会被截断；第三，它的 API 兼容协议做得比较成熟，Anthropic 风格的适配端点在社区里早被验证过，配置起来省心。
当然，这不代表 DeepSeek 在所有场景都碾压其他模型。你的项目如果大量使用特定框架，或者你更看重某模型的中文表达风格，也可以随时切换。后面的章节我会讲如何用路由工具同时配多个模型，方便你按项目切换，这个灵活性是这套方案比官方订阅更让我喜欢的地方。
2. 环境准备：Claude Code 本体安装和那个“不可用”提示的处理思路
在配置 DeepSeek 之前，先把 Claude Code 客户端装好。我默认你在自己的开发机上操作，Mac、Windows、Linux 都行，核心步骤差不多，只是环境变量写入的地方稍有区别。
2.1 Node.js 版本与环境检查
Claude Code 是一个 npm 包，所以第一个依赖是 Node.js。建议 Node 版本在 18 以上，太老的版本会遇到各种兼容问题。检查很简单：
node -v npm -v如果还没装 Node，去官网下载 LTS 版本即可。装完之后可以用npx验证 npm 环境是否健康。这一步没什么坑，但确实见过有人卡在版本太老上，后面安装 Claude Code 时报各种奇怪的语法错误，排查半天才发现是 Node 的问题。
2.2 npm 全局安装 Claude Code
安装本身一条命令：
npm install -g @anthropic-ai/claude-code装完之后执行claude --version，能看到版本号说明客户端就绪。如果你是企业内部的 npm 镜像源，记得确认镜像同步的是最新包，否则可能装到旧版本。旧版本对自定义端点环境变量的支持不够完整，后边配置会出问题。
2.3 安装后遇到“区域不可用”提示怎么办
这里必须说一个很多人会踩的点。Claude Code 到安装这一步通常没问题，但首次启动claude命令时，有些地区会收到类似note: claude code might not be available in your country的提示，然后流程被卡住，因为官方对部分区域有访问限制。我不建议去琢磨任何绕过网络访问的灰色手段，更稳妥的做法是这两个方向：
一是直接在官方支持的区域环境里运行。很多开发者本来就有海外云服务器或者云开发环境，把 Claude Code 装在那台机器上，通过 SSH 远程使用，从功能上讲不受影响，这是合理且常见的使用方式。二是走本文的核心方案——用第三方模型服务接管请求。前面说了，Claude Code 对模型的判断取决于请求发往的端点，只要你在环境变量里把模型服务的地址指向 DeepSeek 的兼容接口，就完全不经过 Anthropic 的账户登录环节。也就是说，你根本不用管 Claude 官方账号那套东西，自然也不会被区域提示困住。
需要强调一下，我只是分享程序层面的调用方式。具体到工具的使用条款、你所在环境的合规性，请自行判断，我不觉得花心思去规避什么限制是聪明的做法。
2.4 初始化配置目录
启动过一次之后，Claude Code 会在用户目录下生成配置文件目录，比如~/.claude/。后面我们要自定义端点、设置模型、管理权限，都会用到这个目录。你可以先创建一个项目级的 CLAUDE.md 说明文件，里面写清项目背景和你的偏好，Claude Code 每次启动都会读取它作为上下文。这个文件是提升 agent 效率的秘密武器，后面第 6 节再细说。
3. 核心步骤：把 Claude Code 的模型通道路由到 DeepSeek
这是全文的重头戏。整个配置分两条路线：一条是“环境变量直连”，适合快速验证、只用一个模型；另一条是“本地路由中间层”，适合多模型混用、按项目切换。两条路线不冲突，建议先直连跑通，再加中间层。
3.1 获取 DeepSeek 的 API Key
这一步没什么悬念。去 DeepSeek 开放平台注册账号，在控制台创建 API Key，记下来。接着去它的 API 文档里找 Anthropic 兼容接入地址。很多模型平台现在都提供这个地址，通常被标注为“Anthropic API 兼容端点”或者直接给出 base_url。要注意，不同渠道给同一个模型起的 ID 可能不一样，文档里显示的模型标识符才是你最终要填进配置的名字，常见的大概率是deepseek-chat或者类似名称。别凭印象写“V4 Pro”这种营销名，后台文档怎么写你就怎么填。
3.2 方案一：环境变量直连
Claude Code 原生支持三个关键环境变量：ANTHROPIC_BASE_URL指定请求发送的端点，ANTHROPIC_AUTH_TOKEN指定身份令牌，ANTHROPIC_MODEL指定模型名。只要端点实现了 Anthropic Messages API 的协议，Claude Code 就会把它当成官方 API 来用。
我当时的配置是这样的：
export ANTHROPIC_BASE_URL="你的DeepSeek兼容端点在API文档里给出的地址" export ANTHROPIC_AUTH_TOKEN="你的DeepSeek_API_Key" export ANTHROPIC_MODEL="deepseek-chat"配置完成后直接运行：
claude如果一切正常，你会直接进入 Claude Code 的交互界面，而不需要登录 Anthropic 账号。这里ANTHROPIC_AUTH_TOKEN起的就是身份认证作用，Claude Code 发起请求时会在 header 里带上这个 token，DeepSeek 端收到后认出来是你，就可以正常计费和响应。
这套直连方案的优势是零额外依赖，不需要装任何中间进程，适合第一次验证。缺点是如果你想换个模型，就得改环境变量再重启会话；想同时接 Qwen、GLM，直连就做不到了。所以跑通之后，我强烈建议继续做下一步的中间层方案。
3.3 方案二：用路由中间层实现多模型切换
社区里比较主流的两个工具，一个叫 ccswitch，一个叫 claude-code-router。实际用起来思路很像，都是在你本机起一个轻量级的转发服务，监听一个本地地址，所有 Claude Code 的请求先发到这个地址，再由它转发到背后真正的模型服务。
我用的是 ccswitch。装好之后，它会在配置目录生成一个 JSON 文件，你需要做的是在其中添加一条路由，指向 DeepSeek 的 Anthropic 兼容端点，并填好模型 ID。后面你想加 Qwen、GLM，就继续在 routes 数组里追加条目，启动 Claude Code 之前用简单的命令切换当前路由，或者在配置里设置默认模型。这样做的好处是 Claude Code 本身不用重启，切换几乎无感。
我截一个配置要点，结构大致是：
{ "routes": [ { "name": "deepseek-v4", "baseUrl": "你的DeepSeek兼容端点地址", "apiKey": "你的DeepSeek_API_Key", "model": "deepseek-chat" } ], "defaultRoute": "deepseek-v4" }不同工具字段名可能略有差异，但核心就是这三个信息：地址、密钥、模型名。填好之后把ANTHROPIC_BASE_URL设成路由工具给你的本地地址，ANTHROPIC_AUTH_TOKEN随便填一个非空字符串，真正的认证交给路由层去处理。
你可能要问，不是已经能直连了吗，为什么还要多一层？我的体会是，中间层解决的不只是多模型问题。它能统一管理多套配置，项目 A 用 DeepSeek、项目 B 用 Qwen、上下文比较敏感的场景切到本地模型，这些都变成了切换配置的事。而且路由工具通常带日志功能，你能看到每一次请求到底发往哪个模型、耗时多少、token 多少，这对后续成本优化太关键了。
3.4 模型名与参数的几个细节
模型名这事我再强调一次：一定要以 API 文档列的官方名为准。平台可能在宣传页写 V4 Pro，但代码里识别的可能是另一个标识符。填错模型的直接后果是 404 或者提示模型不存在，这在第 5 节踩坑部分会细说。
另外，Claude Code 对很多参数有自己的预设，比如 temperature、max_tokens 会由 agent 的决策逻辑控制，用户不需要也没必要刻意调整。你真正要关注的是上下文长度。Claude Code 默认规划能力比较强，动不动就想着读很多文件，如果你的模型上下文窗口远小于它默认规划的长度，对话后期会出现内容被截断的情况。解决办法不是去调模型的上下文参数，而是限制每次任务的对话轮数，这个我在踩坑部分再展开。
3.5 验证连通性，跑一个最小用例
配置好之后，别急着上复杂任务。先启动claude，发一个最简单的请求，比如“写一个打印当前时间的 Python 脚本”，观察它是否正常响应。如果它开始列出计划、创建文件、执行命令，说明链路已经通了。
想看更详细的信息，可以用调试模式启动：
claude --debug调试模式下终端会打印完整的 HTTP 请求信息，你能清楚地看到每次请求的实际端点地址。这一步非常有用，它能快速确认请求是不是真的发给了 DeepSeek 而不是谁都没发。很多配置问题在用--debug跑一次之后当场现形。
4. 实测：让 Claude Code 独立完成一个多文件编码任务
链路通了之后，我拿一个稍微有难度、能体现 agent 能力的任务做了真实测试。测试任务不是简单的“生成一个函数”，而是一个包含目录遍历、文件改名、正则匹配、批量操作的脚本任务，这种任务最考验模型对工具链的调用能力。
4.1 测试任务设计：批量重命名项目中的资源文件
我在一个测试目录里放了二十几个命名混乱的图片文件，要求是写一个 Python 脚本，将这些文件按拍摄时间重新组织到按日期分组的子目录中，并在终端里输出每个文件的新旧对照表。这个任务涉及：读目录、正则解析文件名、处理日期格式、创建目录、移动文件、输出结果，而且需要保证重复运行不会出错。
如果模型只是生成一段完整脚本，那其实是标准的代码生成能力；但 Claude Code 作为 agent 的特点在于，它会自己完成“先看目录结构，再写脚本，再执行脚本，再看输出报错，再修复”的完整闭环。我在提示词里故意没有描述得太细，只给了需求，想看看它能不能自主补全细节。
4.2 观察整个运行过程：agent 如何自主规划与执行
启动之后，Claude Code 先列了一个三步计划：扫描目录、分析命名规律、生成并运行脚本。接着它用 bash 工具执行ls查看真实目录，而不是凭空写代码。看到文件名规律后，它开始创建 Python 文件，每一步都会在底部说明当前正在做什么。
中间还发生了一个比较有意思的小插曲。脚本第一次运行时，因为有个文件没有 EXIF 信息，Python 抛了异常。Claude Code 并没有直接结束，而是读取了报错信息，调整逻辑，改成“没有日期信息就放入 unknown 目录”，然后重新运行。这个自动发现问题、定位报错、修复逻辑的循环，正是 agent 模式相对普通聊天的核心价值。整个过程中我几乎没介入，只看它自己把问题处理完了。
DeepSeek 的响应速度在测试中表现不错。即使在多轮工具调用的场景下，每次返回推理结果的时间都比较稳，没有出现明显的长时间卡顿。前面几个大步骤基本一气呵成，中间失败重试也只花了两轮就绕过去了。
4.3 结果与成本：几万 token 的活，费用几乎可以忽略
脚本最终运行成功，输出对照表也符合预期。我在路由工具的日志里调出了本次会话的统计，整个任务跑了四十多轮工具调用，累计消耗 token 在几万这个量级。按 DeepSeek 的价格来算，费用低到可以忽略；要是换成 Claude API，同样轮数成本就是另一回事了。
这个数字其实印证了我最开始的观点：agent 模式的价值建立在“跑很多轮”的基础上，而跑很多轮的前提是 token 便宜。如果你用的是按量计费的昂贵 API，你会不自觉地限制 agent 的探索，让它“快一点完成”，这反而牺牲了它最大的优势。
4.4 DeepSeek 与官方 Claude 在 agent 场景下的体验差异
实测下来，最直观的差距主要在两个方面。一个是工具调用的规范性，官方 Claude 在连续多次调用工具时的动作衔接更平滑，而 DeepSeek 偶尔会出现某一步没有按预期返回工具调用格式，需要多等一轮让路由层修正，整体节奏略慢一拍。另一个是复杂重构场景下的路径规划，官方 Claude 有时候会更快地收敛到一个精简实现，DeepSeek 则偶尔会多绕一点路，比如生成冗余代码再删掉。
但这些差异我认为都在“可用”范围内，而且随着模型迭代越来越小。对于日常的脚本编写、文件处理、批量重构、测试补充，DeepSeek 的表现已经是靠谱水平了。尤其是“便宜到敢放手让它折腾”这一点，对我来说弥补了效率上的微小差距。
5. 踩坑清单：我在接入过程中遇到的四类典型问题及排查思路
配置过程不可能一帆风顺。我把这两天真遇到的报错按根因归成四类，每类都附上排查思路。这些问题在网上零散出现过，但大部分帖子只说“我遇到了 xxx”，没说清楚到底怎么定位。这里我按排查链路来写，方便你复现。
5.1 认证失败：403、401，请求根本没到 DeepSeek
这类错误的表现是 Claude Code 启动后就开始报错，或者输出类似“invalid authentication”的信息。最常见的根因就是ANTHROPIC_AUTH_TOKEN没真正传进去，或者传成了空字符串。
我的排查顺序是：先用echo $ANTHROPIC_AUTH_TOKEN确认变量在 shell 里确实存在，别刚写完 export 就忘了。然后在--debug模式下看请求头里 Authorization 字段的内容，如果发现 token 后面多了一个空格，或者被引号包进去了，那就是你敲命令时不小心带了多余字符。还有一种是环境变量写在了一个 shell 会话里，又开了一个新终端，导致新终端里的 Claude Code 没读到，这类问题在 Windows 上尤其常见。
5.2 模型名 404：你以为的 V4 Pro 并不是 API 里的模型 ID
我第一次配置的时候就栽在这。模型在宣传页叫 V4 Pro，我就理所当然地拿这个名去填，结果请求直接返回 model not found。后来去平台后台 API 文档里仔细翻，才发现实际可用的模型标识是完全不同的代码名。
这类问题特别好排查，第一步就是去控制台的 API 文档页面搜索“model”字段，找到示例代码里的模型名，复制过来用。第二步，如果你用了路由中间层，确认配置文件里的 model 字段和 upstream 端点的 model 字段没有漏掉。第三步，在--debug模式下查看请求体里的 model 字段实际发送的值，如果还是不对，就检查路由工具是否做了模型映射，有些工具需要把“对外模型名”和“真实模型名”分开填。
5.3 工具调用失效：agent 不执行命令，光说话不动手
这个坑比前面两个更隐蔽。表现是 Claude Code 能正常回答你的问题，但要求它“运行这个命令”“修改这个文件”时，它要么假装做了，要么直接说自己不能执行。这种情况通常不是模型问题，而是路由层在转换工具调用格式时丢失了信息。
Claude Code 要求模型以特定 JSON 格式返回工具调用，第三方兼容端点的任务是在模型的输出和 Claude Code 的期望格式之间做转换。如果转换层不完整，Claude Code 就收不到有效的 tool_use，只能把模型的话当成普通文本回复。排查办法：先看调试日志里最后几轮请求，模型返回的原始内容里有没有 tool_use 字样。如果有但 Claude Code 报错，说明转换层有问题，换一个路由工具版本，或者改用第 3 节说的直连方案做交叉验证。
5.4 上下文超长：任务后半程模型开始“失忆”
agent 任务做到一半，Claude Code 突然忘记前面几步结论，或者开始重复读取同一个文件，很多时候是上下文被截断导致的。Claude Code 默认会对会话做很长的上下文规划，但如果后端模型窗口没那么大，超出部分就会被硬性截掉，模型感知不到早期内容，自然就开始胡言乱语。
这类问题最实用的解法不是调大窗口——窗口是模型决定的，你也调不了——而是限制每个会话的工作量。Claude Code 有个暂停参数可以限制最大轮数，比如claude --max-turns 20，让它在二十轮内结束，超了就另起一个会话。另外，把大任务拆成几个小任务，每个会话只做一件事，这也是 agent 模式下更健康的用法。你还可以利用第 2 节说的 CLAUDE.md 文件，把每个子项目的背景写清楚，这样即使模型上下文滚动出来，它也能从项目说明里快速恢复记忆。
5.5 流式输出卡住：响应到一半不往下走了
最后一个小问题，但很影响体验。有时模型已经生成了半段内容，终端突然就不动了，等很久都没有新内容。最开始我以为是模型卡死，后来在路由日志里发现是流式响应超时。第三方端点长时间没有返回新 chunk，Claude Code 等待超时就中断了整次请求。
排查时先确认是不是网络波动，再检查路由中间层有没有超时配置。有些工具默认超时时间偏短，对大段生成任务不够用，你可以把它调长一点，比如 300 秒。另外就是减少单次生成的长度需求，把任务拆细，请求短了自然不容易触发超时。
6. 把工作流固定下来：配置持久化、项目级说明和成本控制
既然已经跑通了，接下来就是让它成为日常顺手可用的工具，而不是每次开终端都要重新配置一遍。这一节的东西偏经验性，是我用了一周多之后沉淀下来的习惯。
6.1 环境变量的持久化
最简单的方式是把 export 命令写进你的 shell 配置。Mac 上写~/.zshrc，Linux 写~/.bashrc，Windows 用系统环境变量设置。但说实话，我不太建议把 API Key 直接裸写进 shell 配置，万一 shell 历史被同步或者被别人看到，key 就泄了。
更稳妥的办法是单独写一个启动脚本，比如claude-ds.sh，内容就是设置三个环境变量并启动 claude：
#!/bin/bash export ANTHROPIC_BASE_URL="你的DeepSeek兼容端点地址" export ANTHROPIC_AUTH_TOKEN="你的DeepSeek_API_Key" export ANTHROPIC_MODEL="deepseek-chat" claude每次要用的时候执行./claude-ds.sh就行。这个脚本可以放在你的工程目录里，也可以放在一个统一的 tools 目录下。如果你用了路由中间层，这个脚本就更简单，只需要设置两个固定变量然后启动路由服务，真正会变的模型配置都在路由工具的配置里改。
6.2 项目级配置：CLAUDE.md 才是 agent 的工作手册
Claude Code 会自动读取项目里的 CLAUDE.md 文件作为长期记忆。很多人忽略这个文件，完全靠对话里的提示词，导致每个新会话都要重新解释项目背景。其实你只要把这个文件写好，你的 agent 每次进入项目就是“老手状态”。
我在一个用这套工作流维护的 Python 项目里写的 CLAUDE.md 大概包括：项目用途一句话、目录结构说明、常用命令、代码风格偏好、以及“不要修改哪些文件”的禁区列表。效果很明显，Claude Code 生成的代码风格越来越贴合项目，也很少再去动那些不该动的文件。这个东西和模型用什么其实没多大关系，但配上低成本模型之后，你可以更放心地让 agent 频繁启动，CLAUDE.md 的价值就被放大了。
6.3 和 VS Code 配合使用
Claude Code 本身是一个终端工具，但在 VS Code 里也有对应的扩展，社区里叫“Claude Code for VS Code”。你需要先完成本文前面所有的命令行配置，保证claude --version能正常输出，再安装扩展，它本质上是在编辑器里嵌一个终端面板跟 CLI 交互。
我之所以提这个，是因为很多人装完扩展后说“无法连接”，实际上原因还是前面讲的环境变量问题——扩展启动的终端进程和你手动执行 export 的 shell 不是同一个会话。如果你用了启动脚本的方式，记得在 VS Code 的集成终端里 source 一次这个脚本，或者把环境变量写进系统的用户环境变量。这个联动不是必需的，但如果你习惯在编辑器里写代码，嵌套着一个 agent 帮你跑命令，体验会顺畅不少。
6.4 成本控制的几个小技巧
尽管 DeepSeek 很便宜，但 agent 用多了 token 总量依然可观。我做这三件事来控制成本：一是给每个会话加--max-turns参数限制轮数；二是写任务时尽量明确范围和目标，减少 agent 漫无目的地探索文件；三是定期看路由工具的日志统计，每个项目的月消耗一目了然，发现问题及时调整。
还有个更进阶的用法：把简单、重复的任务和复杂、探索性的任务分开。简单任务用便宜的模型通道，复杂任务临时切换到表现更强的模型，通过中间层配置切换。这套组合下来，我每个月的 AI 编码成本控制在非常低的范围，而且没有牺牲关键任务的完成质量。
我个人用了大半个月的体会是：把模型路由到 DeepSeek 之后，最大的收获其实不是省了多少钱，而是“敢用”。敢同时开好几个 agent 会话去做批量重构，敢让它反复试错几十次去找一个边界条件，敢拿它处理那些以前觉得“不值得花 API 费”的杂活。对一个把 AI 编码当成日常工具的开发者来说，这种不被成本绑手绑脚的感觉，才是最值得长期保留的东西。最后再说一句，如果你也是刚开始折腾 Claude Code，建议先按第 3 节的直连方案跑通最小用例，再决定要不要上路由中间层；一步到位虽然可行，但出了问题排查起来会多一层变量。先把一个方案吃透，后面的扩展都是顺手的事。
