DeepSeek V4 在 4 月 24 日发布之后，最让我心动的不是它在 SWE-bench Verified 上 80.6% 的成绩，而是官方直接给出了 Anthropic 兼容 API。这就意味着 Claude Code 的 CLI 不用任何 fork，环境变量一改就能把后端从 Anthropic 切到 DeepSeek。
加上 V4 Pro 当前还在 75% 限时优惠（到 2026/05/31 结束），输入 $0.435/M、输出 $0.87/M、缓存命中 $0.003625/M——比 Opus 4.7 便宜了大概一个数量级。
正好之前学 RAGFlow 时充过 DeepSeek API，账户里还剩 6 块钱左右没用完；Claude Pro 这周的额度又刚好用完了，正在等下一周恢复。两件事撞到一起，我就想：那干脆拿这点余额试试这个新出的模型到底好不好用——直接用 Claude Code + OpenSpec 修一个本仓库里真实存在的 Bug，看它能走到哪一步。
结论先放在前面：
- 能力：V4 Pro 高于 Sonnet 4.6，但还是比不上 Opus 4.7。即便开到 max 思考深度，也差 Opus 的 medium effort 一档。
- 多模态：V4 系列目前完全不支持图片输入，跑步 Log 这种需要看截图的 Skill 直接废掉。
- 费用：优惠期内合理。但 5 月底之后要重新算账。
接入方式：环境变量切一下就行
我直接在 .bashrc 里写了一个 switch_to 函数（因为同时还要切 Sonnet / Opus / Haiku 来回测），调用一下就把环境变量切到 DeepSeek：
这里有个坑：按 DeepSeek 官网的要求，模型名要写成
deepseek-v4-pro[1m]——后缀的[1m]是用来启用 1M 上下文的开关，不带的话默认还是短上下文，长任务会被截。
切完之后启动 claude，状态栏就能看到当前跑的是 DeepSeek V4 Pro，而不是 Sonnet 或 Opus：
整个切换过程只有一处需要先警告一下：Claude Code 的 channel 功能依然不可用。这个限制和模型无关，是 CLI 本身只允许 Pro/Max 账号开 channel，连 Anthropic 自家的 Opus API key 都不行。后面单独展开。
实战流程：让 V4 Pro 走 OpenSpec 修一个 Bug
在开始之前先说一下流程框架。我给本项目写了一个项目级 Skill —— dranixj-openspec-task，把 OpenSpec change 的生命周期（propose → apply → archive）和 GitLab Issue 的生命周期通过 glab 命令双向绑定起来：propose 时自动开 issue 并写入 change，apply 时把进度同步回 issue，archive 时关闭 issue 并打 milestone。所以下面看到的所有 issue / MR 操作都不是我手动做的，是这个 Skill 自动调 glab 触发的。
我挑的任务是仓库里一个文章发布管道相关的 Bug。
1. 制定 Bug 修复计划
进对话第一件事就是请它读问题描述、产出修复计划：
V4 Pro 给出的初步分析就在水准之内——能理清调用链、定位嫌疑文件，结构化也不错：
但第一轮分析它只盯着 Bug 本身，不会主动联想到周边受影响的产物。这次 Bug 牵涉到文章发布管道，按经验需要同时确认 sitemap.xml 和分类列表 JSON 是否会被波及。Sonnet 4.6 大致也是这个表现，Opus 4.7 在过去类似场景里通常会主动多问一句"是不是要顺便检查 sitemap"，V4 Pro 没有。
2. 追问扩散
我手动追问一句"还需要同步检查哪些产物"，V4 Pro 立刻把范围扩开：
补完一轮分析后，结果就更接近 Opus 一上来直接给的内容了：
整体感受：V4 Pro 实际用起来明显比 Sonnet 4.6 更扎实，分析颗粒度、代码改动的命中率都上了一档；但和 Opus 4.7 之间还有比较大的差距，即便开到 max 思考深度，也没追上 Opus 4.7 的 medium effort。
3. 修复方案与 OpenSpec 更新
定位完成后是出方案：
接着按 OpenSpec 的规约把变更写进 spec：
最终生成的 change 该有的都有——proposal、design、tasks、deltas 一套齐全，命名和目录结构也符合 OpenSpec 约定，可以直接进 review。
4. 生成 GitLab Issue 与变更概要
dranixj-openspec-task Skill 在 propose 阶段会自动调 glab 开 issue 并把 change ID 写到描述里：
顺手放一张当前项目的 issue 列表当个旁注——这个项目从 OpenSpec + Issue 这套维护方式上线之后，已经积累了不少功能改善和 Bug 对应记录，整体推进比之前散乱开 PR 顺得多：
随后再输出一份 change summary 给 reviewer 快速 catch up：
5. 生成 MR 并报告结果
写完代码、跑完本地校验，请它生成 MR：
最后由它自己给出结果报告——这一轮其实是一次性跑了两篇文章生成 Skill 的产出报告：
顺便记一个有意思的小观察：跑文章生成 Skill 的时候，DeepSeek 没有 WebSearch 工具可调用，但模型自己想出了一个绕路办法——用 WebFetch 拼 ?search=关键字 直接去 Google 抓搜索结果页面。这个做法不算优雅（结果质量也一般），但至少证明它在工具受限的情况下会自己尝试 workaround，没有死板地说"我不能搜"。
一次本来不该有的 review，结果还真发现问题了
通常我不会让 Opus 4.7 在事后再跑一遍 review——成本不划算，没必要。这次是个特例：用 DeepSeek 改的 node 脚本在本地测试全部通过，结果一推到 GitLab pipeline 就挂了，报了个未知错误。我把 log 贴回去让 V4 Pro 反查，它通过日志定位 + 反问的方式找到了问题、做了改善。
但因为这次问题是"本地通过、CI 失败"这种比较 tricky 的情况，我有点不放心，于是让 Opus 4.7 复审一遍——还真又揪出了几个问题：
最关键的一条是 Cloudflare 的 single-file purge 接口有每分钟调用上限，MR 里一次性触发上百个文件 purge 会直接被限流。V4 Pro 的修复在功能上对，但生产环境跑会因为这个边界条件挂掉。Opus 直接给了分批 + 退避的版本：
这个差距不是"思考深度"能弥补的，而是预训练阶段对各种 SaaS / CDN 平台限制的覆盖密度。Opus 4.7 在这种"有一个隐藏前置知识需要预先想到"的场景下还是更稳。V4 Pro 不是不会修，而是不会预先想到去查。
三项绕不开的限制
抛开能力差距不说，V4 Pro 在 Claude Code 工作流里还有几个硬性限制：
1. 没有 Channel 功能
Claude Code 的 channel 功能只对 Pro/Max 订阅开放，连 Anthropic 官方的 Opus API key 都不能用。所以 Claude Weixin Channel 这条路彻底走不通。
替代方案是用 wechat-acp 这类社区桥接器：
体验本身倒不比 channel 差。但 channel 模式有一个特别舒服的地方：本地终端和微信端是同一个会话，可以在地铁里用手机发图片、回到电脑接着在终端里继续往下推。ACP 这条路是另起一个独立进程，和本地终端完全隔离，跨设备接力的能力就没有了。
2. 没有多模态——图片完全看不见
V4 系列目前只支持文本输入。对我影响最直接的是两个场景：
- 跑步 Log 生成 Skill：原本依赖 Garmin 截图 → 模型识别 → 自动写 markdown。V4 Pro 因为看不到图，每一段说明都是瞎猜的，要挨个手动改，基本失去了自动化意义。
- wechat-acp 收到图片消息：Opus 能直接解析，V4 Pro 直接提示无法处理：
所以但凡我的工作流里牵扯到多模态，V4 这边就走不通，得切回 Opus。
3. 不能用 WebSearch，只能 WebFetch
Claude Code 在 DeepSeek 后端下只暴露 WebFetch（拿到具体 URL 才能拉），不暴露 WebSearch（关键词搜索）。对调研类任务影响很大——比如我自己写的"生成文章 Skill"在调研阶段就会卡住。模型自己用 ?search= 拼 Google URL 是个临时 workaround，但毕竟不是第一选择。
费用：优惠期内确实便宜
跑完整套流程的实际花费：
目前 V4 Pro 还在 75% 折扣期（截止 2026/05/31 15:59 UTC），缓存命中价更是被压到原价 1/10。同样工作量如果换 Opus 4.7，大概要乘 10 倍以上。
我之前是用 Copilot 接 OpenCode 那套——10 美元档已经被取消 Opus 调用，6 月之后按次计费规则也要取消，对我来说这条路基本就不香了。这次实测下来，DeepSeek V4 Pro 接到 Claude Code 上跑单位 token 的性价比反而更高，让我开始认真考虑要不要直接切过来。
适合什么样的工作流
跑完这一轮，我的判断是：
- 日常 CRUD / Bug 修复 / 重构：V4 Pro 完全够用，费用是最大优势。
- 需要发散联想或者踩中冷门边界条件的复杂 Bug：还是切 Opus 4.7，至少 review 阶段切回去。
- 多模态 / WebSearch / Channel 依赖的工作流：V4 暂时无法替代。
- CI / 自动化批处理：因为是纯 API，可以直接打 Docker 镜像塞进 pipeline 跑——这是订阅制 Claude Code 做不到的，也是这次接 DeepSeek 最大的额外收益。
总结
DeepSeek V4 Pro 接入 Claude Code 整体是一次很平滑的体验：环境变量改一行就完成切换，OpenSpec 工作流照常跑通，从规划到 MR 全流程没断链。能力定位介于 Sonnet 4.6 和 Opus 4.7 之间，更靠近后者。
它没法替代 Opus 的地方主要在三个维度——联想半径（隐藏前置知识的覆盖）、多模态（直接没有）、WebSearch（工具没暴露）。第一项随模型迭代会慢慢收窄，后两项目前是硬约束。
但在优惠期内，把它当作日常主力、关键节点切回 Opus 做 review，是当下性价比最高的组合。等 5 月底优惠结束再重新评估也不迟。
评论