Claude Code 封禁中国开发者之后：本地 AI 编程工具的替代方案实测

账号被封了之后到底用什么？有人说换节点就好，有人说换了节点照样封，还有人说自己什么都没干就被标记了。工信部上周发的安全提示刚好撞上这波，群里讨论的风向从"怎么绕"慢慢变成了"是不是该找个不被卡脖子的方案"。

我们团队也在用 Claude，日常写代码、查文档、review PR 基本都挂着它。封禁消息出来之后第一反应是确认账号状态，好在主力账号暂时没受影响，但团队里两个用国内信用卡注册的同事确实被限制了，API 能调，CLI 直接报 access denied。

Copilot CLI 能用，Cursor 也能用，DeepSeek 的 API 接过来配合本地的一些编排框架一样能干活；但这些方案都有个共同的前提——你得联网，你得把代码片段传给远端模型，而且随时可能因为账号、地区、政策变化突然不可用。对于个人开发者来说这最多算个麻烦，对企业内部代码来说就是个需要严肃对待的安全问题。

先说几个我们实际试下来能用的本地方向。Ollama + Continue.dev 这条路线比较成熟。Continue 是个 VS Code 插件，后端可以接 Ollama 在本地跑 Qwen2.5-Coder 或者 DeepSeek-Coder 系列模型，32B 量化之后在 64GB 内存的 Mac 上能跑到可接受的速度，补全和简单的代码生成基本够用，复杂重构还是差云端模型一截。配置不复杂，装个 Ollama 拉模型，Continue 里改一下 config 指向 localhost 就行。缺点也很明显，大模型吃内存，M 系列芯片统一内存架构反而在这方面有优势，Intel 机器跑起来会比较痛苦。

Claude + DeepSeek 组合做 Skills 自动化，这是那篇热文里提到的方案。思路是 DeepSeek 负责理解和拆解任务，Claude 负责生成代码，中间用 Skills 做流程串联。但本质上这还是依赖云端 API，只是把鸡蛋放在了两个篮子里，DeepSeek 的 API 相对稳定，国内访问也顺畅，算是一个折中方案。

Zed 编辑器最近几个版本内置了对本地模型的支持，搭配 ollama 不需要额外装插件。体验比 Continue 更原生一些，毕竟是编辑器层面的集成，补全的延迟和上下文感知做得不错。功能上还比较基础，多文件编辑和项目级理解不如 Cursor 成熟，胜在轻量。

虽然AI 编程工具解决的是"写代码"这一步，但开发者的日常工作流里，写代码只占一部分时间。跑测试、查日志、操作数据库、在浏览器里验证功能、切换各种内部系统点按钮，这些 GUI 层面的操作一直没有太好的自动化方案。之前我们用 Apple Script 和一些 RPA 工具凑合，维护成本很高，界面稍微改一下脚本就废了。

Mano-P 是我们自己开源的一个端侧 GUI Agent https://github.com/Mininglamp-AI/Mano-P 4B 量化模型在 M4 Pro 上跑，内存峰值 4.3GB，截图和操作全部在本地完成，不需要传任何数据到云端。它不是专门写代码的工具，它做的事情是看着屏幕直接操作界面——你让它跑测试它就去点 IDE 的运行按钮，你让它查 Jira 它就打开浏览器自己导航，你让它填表单它就照着字段往里敲。在 OSWorld 评测里跑了 58.2%，比同量级的开源模型高不少。我们内部日常用它来做一些重复性的操作，比如每天早上自动拉起开发环境、检查 CI 状态、把 PR 信息整理到飞书，这些事情以前要么手动做要么写一堆脚本维护。

说回替代方案的问题，没有任何一个本地工具目前能完全替代 Claude Code 的体验，这是实话。云端大模型在代码理解深度、多轮调试、跨文件重构这些场景下的优势确实明显，短期之内本地 7B、14B 甚至 32B 的模型追不上。但"完全替代"本身就是个伪命题——你不需要一个工具把所有事情都做了，你需要的是一套组合：云端模型处理复杂的架构设计和疑难调试，本地模型处理日常补全和敏感代码，GUI Agent 处理界面层面的重复劳动，各司其职。

以前大家默认"联网用 AI"是唯一路径，现在开始认真考虑本地方案了。模型在变小，推理速度在变快，M 系列芯片的 GPU 和统一内存让端侧跑大模型这件事变得越来越现实。今天本地模型还只能打辅助，半年后呢？硬件每代都在升级，量化和剪枝技术每个月都有新进展，端侧能跑的模型只会越来越强。