最近收到通知，Gmail 因为“安全的原因”要逐步停止支持 POP3 收取第三方邮件。这对我来说是个小麻烦，因为学校的邮箱和 Gmail 之间的同步需要找替代方案。

想想其实用第三方服务还是不太靠谱，加上事情本身也不大复杂。索性利用假期的时间用 Rust 写了个小工具 mail-forwarder 来自动转发。在这个过程中，我开始大量使用 Claude Code，这个体验还真不错。总体来说，用 Claude Code 写代码的流畅度确实很不错，但有几个点不太满意：

1. 只能用 Anthropic 自家的模型，没得选
2. 用官方的有点不划算，有点小贵（当然这也有可能是我自己的问题）
3. 国内无法直接访问只能挂梯子，导致访问速度不理想

后来发现 Claude Code 的接口其实很简洁，通过改几个环境变量就能接入其他模型提供商。经过一番调研，我选了 ZenMux 这个平台，主要是因为它国内访问快，支持一堆不同的模型，接口文档也写得清楚，总体来说可以作为 OpenRouter 的一个不错的替代方案。

先说结论吧，暂时在 ZenMux 上提供众多模型中，最后挑了 Ring 1T 作为替代方案。主要是它在推理和代码生成上表现确实不错，价格也比较合理，性价比不错。

这篇文章就是把这个折腾过程整理一下，看看能不能帮到有类似需求的人。

开始配置

1. 安装 Claude Code

这个其实不用多说，直接用官方安装脚本最简单，复制粘贴下：

curl -fsSL https://claude.ai/install.sh | bash

装好了可以验证一下：

claude doctor

顺便说一句，我这里碰到了个坑，安装完成后 claude doctor 报错说找不到 ~/.claude/settings.json，后来发现是因为之前用过其他服务的配置文件有冲突，删除掉那个文件重新启动 Claude 就好了。

2. 获取 ZenMux API 密钥

去 ZenMux 官网 注册个账号。新用户有试用额度，可以拿来直接试用（先说明，这个链接带 AFF 码，注册后你和我都能拿到奖励）。

3. 配置环境变量

这是关键一步。打开你的 Shell 配置文件：

# 如果用 zsh（macOS 默认）
nano ~/.zshrc

# 如果用 bash
nano ~/.bashrc

在文件末尾加上这些：

# ZenMux + Claude Code 配置
export ANTHROPIC_BASE_URL="https://zenmux.ai/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="sk-ss-v1-xxx"  # 改成你的 API 密钥
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC="1"
export API_TIMEOUT_MS="30000000"
export ANTHROPIC_DEFAULT_SONNET_MODEL="inclusionai/ring-1t"

然后重新加载配置即可。

4. 启动试试

打开新终端，进到你的项目目录，输入：

cd /path/to/your/project
claude

第一次启动会要求登录授权，直接用环境变量里配置的 API 密钥就行。

常用的几个命令

启动后就可以开始用了。常见的命令：

• /model —— 查看当前模型，或者切换模型
• /status —— 看看连接状态和配置是否正确
• /help —— 显示所有支持的命令
• /clear —— 清空对话历史

最简单的用法就是直接问代码问题，像：

请帮我优化这个函数的性能
分析一下这个 bug 的原因
给这个类写 unit tests

最后，该说说下实际用下来的感受了，纯个人体验供参考：

推理能力确实不错

Ring 1T 在理解复杂逻辑上表现还是挺好的。我用它给 mail-forwarder 的某些关键部分做代码审查，它能指出逻辑漏洞、性能瓶颈，建议也都比较中肯。对比之前直接用 Claude，差别说实话不是特别明显，但至少 Ring 1T 的性价比更高。

国内访问速度提升明显

这个是我最满意的一点。之前直接用官方 API，有时候响应会卡顿。现在走 ZenMux 的节点，国内访问流畅多了，尤其是半夜用的时候。网络稳定性也更好。

Token 消耗需要关注

复杂的任务确实会吃很多 token。比如我让它分析整个项目结构、写详细的测试用例这种，token 消耗就比较明显。我测试了下相对 Gemini 这种更大模型，Ring 1T 的消耗还是比较合理的，但是推理复杂度高的时候，还是需要注意一下。

偶尔有延迟

处理特别长的文本，或者特别复杂的推理任务，有时候响应会慢一点。不过这个通常不是 Ring 1T 的问题，主要可能是网络或者任务本身就很重。总体来说可以接受。

国际化的问题

可能 Ring 1T 是国内模型的缘故，在处理一些特定的中文语境或者专业术语时，偶尔会有理解偏差。同时其模型偏好在没有特别指定语言的时候，也可能倾向于中文输出，这时候需要在提示词里明确一下语言要求。

使用场景

好了综述所述，总结下我现在最常用的是这几个：

1. 快速代码审查方面，丢段代码给它看，通常能发现我没想到的问题。没有心智负担，因为价格便宜很多；
2. 调试复杂问题：描述现象，让它帮忙分析原因，成功率还是挺高的；
3. 帮忙写测试和文档，特别省时间，质量也还不错，尤其如果是中文环境下的项目，Ring 1T 的表现会更好一些，而且避免了 Anthropic 非要用英文输出以及生成冗余文档的情况。

总的来说，这个配置折腾一次就行了。目前用下来感觉比直接用官方 Claude 爽，成本更低，国内访问也更稳定（当然也有可能目前只是针对 mail-forwarder 这种小需求的情况）。

这个折腾总体来说其实挺值得的，花杯星巴克的钱订阅 ZenMux，用 Ring 1T 的推理能力，国内访问也快，成本比官方便宜得多。如果你也在用 Claude Code，又对国内访问或者模型选择不太满意，不妨考虑试试这个方案。配置其实很简单，5 分钟就搞定，值得的。

自建使用 Git 仓库其实很久了，当时的原因很简单就是因为 Github 的私有仓库不是免费的。虽然期间也续费过 Github 会员好多年，但是毕竟还是自建来得吃香，就这样子兜兜转转用下来这个 Gitea 的实例看了下日期其实比我手头上使用的任何数码硬件设备都要久了。

当时的 Gitea 项目还不是很成熟，甚至连 CI 模块都没有需要搭配第三方 CI 平台来使用。而我自己个人也不喜欢 Gitlab 那么臃肿的架构设计，于是 Gitea 和 Drone CI 的搭配就一直这样子沿用了下来。

近期在整理 Git 仓库和代码的时候，顺手又将 Gitea 升级了下，发现已经是 1.21 版本了，还自带了 Gitea Actions。于是从精简系统的角度上考虑，是不是需要将其替换掉 Drone CI？从我调研以及使用的过程看来，答案是肯定的。

那么 Drone CI 有什么不足的地方呢，主要的问题有以下几点：

首先，原本的 Drone CI 是开源项目但是有完整的商业目标，因此在被 Harness 收购了以后开源的版本更新其实并不及时，这就导致界面非常的简陋，同时也和 Getea 的界面相差甚远。其次，Drone CI 是作为 Gitea 的应用来注册的，然后通过 WebHook 的方式来相互通信，这就导致会有不同的问题发生，例如权限、网络延迟以及缓存等等的问题。还有一点就是，随着研发团队人员的增加，很多时候权限的粒度需要精确的控制，Drone CI 至今都无法完成从全局（Global）、组（Organization）、项目（Project）程度的权限控制。

然后替换为 Gitea Actions 以后又将会获得什么好处呢？

首先就是完整的产品体验，至少界面以及权限这块是保持一致的。然后，Gitea Actions 和 Github Actions 保持了配置方面的兼容性，这让我原本需要分别配置两套 CI 的 yaml 一下子工作量就减轻了不少，同时 Github Actions 丰富的生态也可以在 Gitea Actions 上得以延续。

当然，目前还有一点需要注意的是，Gitea 官网上说明 Gitea Actions 还在开发阶段功能方面不是很稳定，可能随时需要更新。所以切换到 Gitea Actions 以后，那么需要随时关注更新版本（但至少从我目前几个项目的配置看来，没有发现大的问题）。

总体来说，Drone CI 任然还是非常优秀的 CI 平台，只是随时时间的推移可能目前来说已经不适合我而已。对于 Drone CI 的情感还是非常的感激的，毕竟陪伴了我很多日夜的开发之路。

20230220: Azure 因为不可抗力还是暂时迁移到了腾讯云的轻量服务器，以后是否还需要继续迁移还是看情况吧。

距离上次的迁移已经有两三年了，一般来说不会这么折腾的，但是国内对外的网络环境是越来越糟糕。

这个博客站点其实也是佛系更新的，加上天生爱自由的关系不想备案（其实早先备过案，但过期了），于是就又得换个地方、
换个国内能够访问稍微顺畅点的。

用过很久的 Linode，然后再是 Vultr 。就现在这个网络环境来看，这些国外老牌但是规模来说二线的云服务商是
国内老大哥重点关照的对象，毕竟个人站长以及「散户」太多，监管起来成本太高还不如一刀切。

所以，这次考虑迁移还是想往相对比较大的平台服务商上面去靠拢，同时为了省事宁可多些花费，加上又不想用国产
的服务商（别问我为什么）。于是剩下的也就是三家：Google 的 GCP、亚马逊的 AWS 以及微软的 Azure 。

不用 Google 是因为不想把鸡蛋放在一个篮子里，而 AWS 那逆天的控制面板简直让人感觉这是不是和我们一个星球的人
设计出来的，那么剩下就只能选用了 Azure 这其实完全不是好不好问题了。

Azure 的费用的确不便宜，但希望贵有贵的道理吧。现在写博客的人是越来越少了，希望我也还能继续坚持下去。