这次折腾的背景是新搞了台小主机，然后计划拿来当软路由使用，因其还有个闲置的 NVME 插槽以及一块闲置的 NVME 盘，就顺便就想把它当 NAS 用。

但是配置好之后，发现从 Mac 拖拽大文件到 Samba 共享目录时，传输会在几十秒后突然中断，Mac 弹窗报错：“操作无法完成，因为发生意外错误 (错误代码 -8062)” 或 (-36) 错误。

起初怀疑是 NVMe 固态硬盘缓外掉速或 2.5G 网卡断流。但在服务端使用 iostat -x 1 监控发现，写入延迟 (w_await) 仅为两位数（几十毫秒），底层 I/O 非常健康，网络链路也没有掉线。

最终，通过将 Samba 日志级别调至 log level = 3，给大模型分析了下得知是 Mac 的 Finder 在拷贝大文件时，每隔 3 秒就会向 Samba 服务器发送一次 qfsinfo 查询磁盘空间的请求。而 Samba 默认开启了严格锁定 (strict locking = yes)，导致 Mac 的多线程同时读写同一个文件时，触发了 Samba 的文件锁，进而导致主进程挂起。

所以，就根据原因编辑 /etc/samba/smb.conf，调整和应用以下核心配置：

[global]
    # 删除旧时代写死的 SO_RCVBUF 参数，依靠现代 Linux 内核自动调优 TCP 窗口
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    # 禁用强制同步，忽略 Mac 频繁的刷盘指令，大幅提升连续写入稳定性
    strict sync = no
    sync always = no
    # 开启 sendfile 提升传输效率
    use sendfile = yes
    # 关闭全局 Posix 锁，防止 Mac 并发查询扩展属性时导致死锁
    posix locking = no

    # === macOS 专属兼容优化 (VFS Fruit) ===
    vfs objects = catia fruit streams_xattr
    fruit:aapl = yes
    fruit:model = MacPro
    # 解决 Mac 产生的 .DS_Store 及零碎隐藏文件问题
    fruit:veto_appledouble = no
    fruit:metadata = stream
    fruit:posix_rename = yes
    fruit:zero_file_id = yes
    fruit:wipe_intentionally_left_blank_rfork = yes
    fruit:delete_empty_adfiles = yes
    # 禁用 NFS ACLs 权限映射，降低 CPU 无谓开销
    fruit:nfs_aces = no

# 在具体的共享文件夹下：
[Personal]
    path = /opt/samba/personal/%U
    read only = No

    # 关键：关闭严格锁定！
    strict locking = No

总体来说，因为我的 Samba 是非常老的配置（从而起的我自己都不得而知了），所以不要盲目套用网上的老旧配置，而是要根据实际情况进行针对性调整。

经过上述配置后，重启 Samba 服务（systemctl restart smbd），在 2.5G 网络下，百 GB 的 4K 视频传输一气呵成，全程跑满 280MB/s，再无断流现象。

最近收到通知，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 的情感还是非常的感激的，毕竟陪伴了我很多日夜的开发之路。