1.基本说明

今天这篇文章来聊一聊很多开发者都在做的配置 Claude Code 的桌面端工具。

比如我之前推荐过的工具叫做“牛马 AI”，人家的口号就是把 AI 当作牛马。还有我昨天使用的工具叫做 CodePilot（Code 是代码，Pilot 是飞行员的意思）。

其实这类工具有很多相似之处，功能基本差不多，目标面向的人群也都是一样的，即使用 Claude Code 的用户。但是 Claude Code 的桌面端很多用户没有办法直接使用，如果你不想在终端（Terminal）里使用，就可以去下载一个这样的客户端工具。

具体的使用流程如下：

1. 配置大模型厂商使用的套餐、API Key、密钥等相关凭证信息。
2. 选择对应的项目，即可开始工作。

我目前已经体验过了 Claude、牛马 AI 以及 CodePilot 这几款工具，大体流程都是一样的，没有太大区别。起码在模型配置、选择厂商以及获取 API Key 等相关信息方面，都是没有太大差别的。

2.牛马AI

的话，我之前在一个文章里面推荐过。它实际上就是把 AI 当成你的“牛马”，它设置了一些“牛马棚（棚）”

因为 Skill的概念比较火，所以它在牛马棚里面设计了一些技能，例如：

1. 绘图的技能
2. 深度分析的技能
3. 写论文的技能

反正就是各种各样的技能。你在进行对话核验的时候，可以选择牛马棚里的这些工具（实际上就是 Skill），从而更好地辅助你完成任务。

此外，牛马 AI 这款桌面客户端工具还有一些定时任务的功能，并支持以下内容：

1. 语音模型使用的统计
2. 每天的回顾
3. 个性化的设置
4. MCP 服务

基本上这些都是支持的，大概就是这么个情况。

我自己之前在 VS Code 里面使用 Claude Code，所以我本地 .settings.json 文件就有相关的配置信息。当我登录进去之后，它就自动读取到了配置，然后我就可以直接使用了。在环境配置上面没有遇到任何问题，所以使用起来还是比较流畅的。

3.codepilot

和牛马 AI 一样，CodePilot 也是一款桌面端的 Claude Code 客户端工具。

它也是安装之后需要配置模型才能使用。不过它有自己的特色，比如可以支持手机上的一些应用（如飞书、Telegram 等社交媒体），其他功能基本上大同小异，也支持 SQL 和 MCP 等等。

但是这款软件我已经卸载了。

具体现在的原因，就是接下来我要吐槽的地方。

4.吐槽

CodeBuddy 和「牛马 AI」都是开发者使用 Vibe Coding 的方式，在短期内做出来的产品，虽然也有一部分用户，但它们都有让我非常反感的地方。

1. 关于「牛马 AI」的问题
   最开始我并没有发现这个毛病，因为它整体使用起来感觉还不错。但是当我使用 Skill 功能之后（因为 Skill 在我们本地也有对应的文件夹，它是进行渐进式加载的，所以本地肯定会有留存），它直接把我本地的文件夹全给污染了。

   具体情况如下：
   (a) 我本地的 Skill 文件夹原本应该只有 5 个技能。
   (b) 使用它的 Skill 功能后，它会自动把云端的技能全部同步到我的本地。
   © 导致我本地直接变成了 20 多个甚至 30 多个技能。

其中很多技能我根本用不到，这种严重的文件夹污染让我非常不适，最后我把它们全删除了。

其他的还好吧，这款产品“牛马 AI”并没有引起我不适的地方。

它具备管理牛马、定时任务和长期放养等功能，相对而言还是很不错的。我就用了一下，体验确实挺不错。

然后说一下 CodePilot。

CodePilot 也是网上的一些博主开发的产品，但我使用智谱的套餐配置大模型厂商，配置 Claude API 时一直在报错，我也不知道是什么问题。

和牛马 AI 相比，它的入门体验对我来说门槛就高一些。

因为牛马 AI 是自动读取我之前的环境变量，然后就可以直接使用了。但是 CodePilot 虽然也能读取，但它是填在了 Claude CLI 里面，需要你去选择模型厂商并填写 API key，反正它那个我配了很久都没有配对成功。

然后我去群里问了一下那个开发者，开发者的意思是说，Claude CLI 里面的 API 和模型厂商的 API 两个不能同时填写。

然后我去理解了一下，结果怎么配都不对，怎么配都不对。

在尝试了所有的可能性之后，开发者的意思大概是让我把源码下载下来，根据源码去深入理解。理解之后可以尝试修改一下，解决掉这个问题，然后再去提交一个 PR。

但我使用 Claude Code 尝试解决了一个多小时，也没有解决。所以相当于是昨天下午我一共花了三个小时的时间去使用这款工具，结果一次成功都没有，一直卡在解决各种各样的 bug 上，最终也没能成功解决问题。

4.1codex总结

毕竟去做了这件事情，我就让 Codex 帮我总结了一下遇到的这些问题到底是什么情况。花了三个小时时间，大概总结了以下内容，我在这里简单写一下：

实际上，智谱的套餐能用，但不是所有的客户端都能正确接入。比如“牛马言”接入得很顺利，但是 Code Pilot 因为软件兼容性问题一直在报错。

主要原因在于 Code Pilot 调用 Claude Code 的那一层实现：

1. 它内部不是完全照搬原生的 CLI 行为，而是走了自己的 provider、resolver 以及 SDK 逻辑。
2. 它并没有像原生的 Claude 那样稳定地读取并注入我本地 settings.json（环境变量文件夹）里的具体内容。

这就是它一直报错的主要原因。

4.2base url理解

Windows 的环境变量分为用户变量和系统变量。

但是 Windows 系统本地文件夹 .claude 文件夹里的 settings.json 是 Claude Code 自己的配置文件，只有 Claude Code 或者兼容它的客户端才会去读取。所以里面的 ENV 实际上就是写在 JSON 里的环境变量配置。

其实原生的 Claude Code 应该会正确地读取我的 JSON 文件，但是 CodePilot 并没有像原生的 Claude 一样正确地读取这个文件。

在模型配置里面有一个重要的概念，就是 Base URL。我们可以把它理解为：

1. 请求入口地址：API 服务器的地址。
2. 客户端发起请求的目标端点前缀：意思就是说客户端会把请求发到该服务器端口。
   (a) 该接口按照 Anthropic 的兼容协议来响应。
   (b) 我们可以把 Base URL 理解为模型请求发往哪家服务商，请求应该接到哪一个 API 网关。

这个是 Base URL 的真正含义。

4.3模型兼容映射

还有就是说模型映射的问题，这是兼容层的概念。

原生的 Claude Code 内部有很多逻辑，习惯命名为 Sonnet、Opus 和 Haiku，但是智谱想要兼容 Claude Code 需要做一层映射：

1. Sonnet 4.6 这一槽位：实际映射的是智谱 GLM 4.7 模型
2. Opus 4.6 这一槽位：映射到某个高级的 GLM 模型
3. Haiku 4.5 这一槽位：映射到某一个轻量模型

所以我们在界面上看到的 Claude 的名字并不一定代表后端真的是 Anthropic 的 Claude，它可能只是一个兼容的入口名称。这也是为什么我在尝试 Claude Code 里面看到的时候，虽然我配置的是智谱的模型，但是它界面依然显示 Claude Code，但实际上接入的已经是智谱的模型了。

这就是模型兼容映射。

4.4兼容协议

它就是兼容不同的接口。比如说同样是智谱的模型，它可以兼容 OpenAI，也可以兼容 Anthropic。

这是因为同一个模型服务商可以模仿不同厂商的 API 格式，客户端只要按照这个格式发请求就能接上：

1. 兼容 OpenAI：说明这个接口长得像 OpenAI 的这种格式，适合 OpenAI 风格的客户端接入。
2. 兼容 Anthropic：说明这个接口长得像 Claude 的这种协议，适合 Claude Code 一类客户端接入。

这种兼容并不是说它变成了那一家模型，而是说它模仿了那家的接口协议，让原本只支持某一家接口的客户端也能调用它。

4.5所需组件

后来的话我改了源码，我让 Codex 改了源码，然后使用 npm 命令去重新构建，但是这个构建的时间真的太长了，所以我最终还是放弃了。

而且当时我使用 Node 24 对于这个项目的支持不是很好，所以我需要安装 Node 20。在执行 npm install 安装的过程中，它还需要我去安装一些 C++ 的 build tools，然后我又去下载安装了这些，这都花费了我大量的时间。

所以说，如果你想去改这个项目的源码，实际上不是一件容易的事情。

5.结论

在尝试了众多关于 Claude Code 的客户端工具之后，我最终的结论是：最好还是选择 VS Code。

你只需要搭配一个 Claude Code for VS Code 插件。在 Claude Code 里面，你同样可以使用 MCP，同样可以在 VS Code 里面使用它。

像我尝试过的“牛马运营”和 CodePilot 这样的客户端工具，都存在各种各样的问题。

当然，这也不可否认是因为系统版本等各种原因。开发者想要处理好各种系统的兼容性确实不是一件容易的事情，所以出现一点问题也很正常。但这也证明了，这些工具可能都存在不符合我们要求、或者让我们体验不是很好的地方。

相比之下，使用 VS Code 我觉得是一个更加稳妥的选择：

1. 它是非侵入性的
   起码它不会像其他工具一样污染你的 SQL 文件夹。在 VS Code 里面，你想安装什么、使用什么都可以自主选择，不会存在任何环境污染的情况。

2. 配置更加高效
   在使用 CodePilot 时，我曾遇到过像这样配置自费套餐、修改三个小时 bug 的情况。折腾各种配置模型、服务厂商以及环境变量，最终却都没有解决问题。

使用 VS Code 就可以避免上述这些花费大量时间却最终无法使用的情况。综合来说，VS Code 其实是更好的选择。

当然，前提主要是因为本人是一个菜鸡。如果大家解决问题能力非常强的话，其实多去使用一些工具还是很不错的。

但是就我而言，这样的体验也给我增添了教训：在有成熟工具能够解决问题的情况下，不要盲目去使用一些第三方的工具，因为它们可能会带来不必要的麻烦。

比如我使用 CodePilot 和“牛马 AI”这类客户端工具：

1. 安装、配置、登录、注册账号以及熟悉使用，这些肯定都是要花费时间的。
2. 万一遇到像 CodePilot 这样出现失败的情况，如果你又像我一样有很强的胜负欲，非要解决这类问题，那么肯定会浪费更多时间。

像 CodePilot 一共花费了我三个多小时的时间都没能解决。如果最后能解决，那我倒认为时间花得还算值得；但如果最终没能解决，我认为就是一件非常可惜的事情。

所以综合之下，我觉得尽量还是选择 VS Code。去选择那些成熟的解决方案：

1. 你使用体验比较好的解决方案
2. 那些比较稳定的解决方案

这样就不会出现上面这种我遇到的问题了。