• 推理过程比较耗费 Token，成本不低
• 输出的推理结果不太稳定，质量时好时坏
• 推理速度相对较慢，等待时间较长

在一些目标明确、问题确定的场景下，其实并不需要模型"深度思考"——这时候推理模型的开销反而成了负担。所以我开始寻找一个更适合这类场景的非推理备选方案，于是尝试了 Ling 1T。

Ling 1T 同样是个相对小众的模型，光看名字大概就能猜到和 Ring 1T 出自同一个团队。在 Hugging Face 上查了一下，果然，背后是 InclusionAI 这个团队。

Ling 实际上是一个系列模型，除了 1T 参数的旗舰版，还有专门面向代码场景的 Ling-Coder-Lite——后者才是我真正感兴趣的，但目前还没有线上部署，只能干看着，着实有些遗憾。

目前提供 Ling 1T 在线调用的平台，我知道的只有 ZenMux。顺带一提，官方主页上已经更新到了 Ling V2.5，但 ZenMux 上目前并没有看到对应的版本，不太清楚是还没上线还是我哪里没找对，有些疑惑。

上图是使用 Ling 1T 的 GitHub Copilot 插件的截图，从使用的角度上来说代码重构分析和优化都是能胜任的、效果也不错，后面具体说说使用体验。既然是 1T 量级的模型，参数规模本身已经足够大，在这个量级上纠结具体的数据量其实意义不大，更值得关注的还是实际使用体验。

我主要在两个地方使用这个模型：Claude Code 和 VSCode 的 GitHub Copilot 插件。 ZenMux 提供了 Copilot 插件的配置文档，按步骤操作即可，并不复杂，这里就不再重复了，直接参考官方文档就好。

好了，说说实际的体验吧。和 Ring 1T 相比，Ling 1T 最直观的提升是响应明显更快，在需要快速迭代的场景下体验好了不少。

在输出质量上，主观感受是 Ling 1T 相对 Qwen3 还是有一定优势的，至少在我的使用场景里如此。不过个人感觉如果不安排好比较详细的 Prompt，Ling 1T 的输出质量可能会有些波动，甚至有点“放飞自我”。好在我实际使用的几个场景里，整体质量还是比较稳定的，基本能满足日常需求。

另外值得一提的是请求的稳定性。这类相对小众的模型，在调用过程中没有遇到诡异的资源占用或奇怪的限速问题。可能是使用的人太少了，服务器压力不大？

总体来说，Ling 1T 是一个在特定场景下非常值得使用的模型，梳理一下我的使用结论：

1. 适合确定性场景：对于目标明确、不需要深度推理的任务，Ling 1T 的速度和稳定性比推理模型更有优势
2. 1T 的参数量打底，输出结果的质量基本能满足日常需求（这个参数量，我们普通用户是部署不起来了…）
3. 相比一些主流大模型，这类小众模型在调用稳定性上表现不错，也没有奇怪的额外开销
4. 需要注意的是，这个模型 MCP 的支持还是比较薄弱的，同时不支持搜索功能，所以在一些需要外部知识的场景下可能表现不如预期

如果你也在寻找性价比更高、适合特定场景的模型，同时又不想花太多时间在调优和维护上，Ling 1T 绝对是个不错的选择。

想想其实用第三方服务还是不太靠谱，加上事情本身也不大复杂。索性利用假期的时间用 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 分钟就搞定，值得的。

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

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

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

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

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

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

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

前些天喷了下所谓的前端「娱乐圈」，虽然带有点情绪但是应该能说明我的目前前端这个圈子的态度。

昨晚收到前同事的来信，虽然带过的团队和人较多，真的尴尬记不起来您是谁来，但真的非常感动那么多年过去还能想起不才。

我觉得还是有必要再继续写篇我自己个人从前端转型的历程和心态。其实这个话题其实已经不止讨论过一次，但其实以前我把这件事情自己也就当做过往来调侃而已，没有非常认真的分析。

我想现在看来，是个非常好的时间点来说这个事情：一来当作自己的个职业方面的总结、二来也可以抛砖引玉当作各位的参考，见笑。

如果时间拨回到十几年前，那时候的前端职位的定位和职责其实非常的模糊，对于前端的理解往往就 JavaScript 代码复制粘贴实现 HTML 页面的轮播等功能就完事，只是后端顺手把页面套了是上不了什么台面的技术活。

说起来我也是半路出家，因为那时候我的主要还是写点 PHP 以及 Java 然后再来折腾 HTML 页面。再往后就是入职了淘宝，才对于前端这个职位有个比较系统的认识以及深入。

如果说当时的大环境是 Web2.0 的时代，那么前端这个职位的技术深度其实几乎停留在 Web1.0：大量的非工程化的前端代码四处堆放，没有工程化的概念，前端也忙于四处救火不是套页面就是修复各种因为浏览器兼容性造成的页面错乱等等事情。

总结下来，那时候（2010 年上下）我个人对于前端这个职位的也是迷茫的：一是业界对于前端这个职位的定位非常的模糊，单纯的对于这个职位而言往往只有一二线的大厂有专门的职位，你能跳的公司其实来回也就那么几家；二是个人因为业务的发展承担了更多的职责，如果只是从前端的角度和高度去考虑整个项目的落地和实施情况，往往是非常的片面以及各种不足。

好在那时候移动互联网的兴起，业界的快速迭代让部分的疑惑变成了让业务 push 你走的动力。

就是在那个环境下，我逐渐从前端这个职位切到了移动端，再后来因为团队的成员比例变化从移动端切到了后端以及管理。

其实我现在回想和总结起来，那时候的我还是相对浮躁了些，如果按照我现在想法和逻辑，我肯定不会做以下的几点：

1、对于前端方面我在「前端娱乐圈」的文章中也喷过，我当时也是过于的关注用户界面的展现形式，然后将各种所谓的新技术套用到自己认为很能出彩的地方，然后显得自己非常的有成就感。

2、过多无意义的争论甚至是争辩，因为前端的可实现以及「重复的轮子」太多，所以造成一个问题可以有多种的解决方案。如果不从全局的角度看待或者作出决策，很多时候往往会陷入无谓的孰优孰劣的争论中，非常的没有必要。

3、从前端转移动端以及后面的后端，往往会带着思维的惯性来理解不同技术栈的方案。例如我曾经干过件「蠢事情」就是自己撸了个所谓后端的高灵活性的框架，然而到后面我才知道 IoC 以及 DI 原来 Spring 已经帮你做到了所有你所想的事情。

4、后端其实出成果的路径往往没有前端的直接，前端优化部分的 case 往往用户从体验上来说非常能直观的感受到，而后端如果需要同样的效果需要做更多的事情往往风险也更大。因此，有段时间我从后端的角度上来说，变更极为的保守。

从技术栈上来说，我入后端是从 PHP 开始的，然后写的最长的时间是 Java ，到近几年（ 2019 年开始）才开始写 Golang。

如果您考虑从前端转后端，其实任何种后端语言都应该能够被深入的研究和掌握，但是咱们需要考虑的因素有更多不仅仅是技术栈方面的事情。

首先，从自身角度上来说，我们需要明白自己擅长做什么以及不擅长做什么。了解自己的边界后，从能定位自己的定位。

其次，从大环境来说 Java 技术栈还是主流，相信你掌握 Java 技术栈以后，再去了解其他的后端技术栈也是能一通百通，技多不压身。然后，自己能够足够回答上述的两个问题后，再去做学习上的规划也会明确很多。

还有个想法我其实想提出来，让您多考虑下。

小城市虽然能够提供的职位相对比较少，可能高度也不会很高。但是我们随着年龄的渐长，需要考虑技术方面的问题其实也会越来越少，例如考虑家庭等等的因素。

这点我们得明白自己需要什么，因为环境的制约造成的困扰，其实改变自身来解决是非常困难的，有可能的方式换个思路例如换个环境才是比较好的做法。

以上的观点可能过于主观，仅供参考。

最近 React 的 Github 项目主页因为意识形态的原因被冲，已经成为了开年为数不多的技术新闻。祖国的前端圈子又一次以这样子的形态被国际环境所认知和理解，这不得不说是一次误解和灾难。

但其实我不奇怪和意外这个事情，因为本身这个事情从导向性上来说是非常可以理解的。

但同样作为技术人员，以我对于国内前端的圈层的认知来说，其实还是超出了我的预想和预期， 而且我非常相信，这已经不是第一次可能也不是最后一次。

我是非常反感意识形态和技术本身挂钩的，虽然「技术无国界」这句话在目前各个国家间的相互制裁和「卡脖子」看来非常的理想化，但我们自己还是需要部分的信仰去支撑自己的信念的。

Github 目前看起来其实还是是个相对比较纯净的社区，但偏偏国内前端这个圈子，就有很多上述类似无关技术的事情发生，让人再次叹息。

我们举例：今天有 React 被冲、往前看还有 Vue 是否是国产框架之争、再往前甚至还有流行框架作者删库跑路…所以，甚至有人戏言国内前端的环境是「前端娱乐圈」。

从技术角度上说，前端开发其实是相对门槛不高的研发岗位。从项目的侧重点上来说，如果说后端关注的是业务逻辑和数据流转，那么前端其实更加关注的是用户体验已经产品的展现形式。

同时前端的技术栈相对比较的多和杂，掌握这些都是需要时间和项目的经验沉淀，但刚开始的初学者因为环境的原因，加上方向上的体系认知还没完全成型，所以都不会非常的深入。

前端的沉淀速度同时往往还会赶不上迭代速度，随着业务和产品的迭代后端已经可能还忙于维护「屎山」，同期时候前端的项目代码因为产品本身已经开始考虑重构，这让很多前端项目往往不会也不关注本身的沉淀。

正是往往缺乏很多业务逻辑的沉淀，所以国内的技术负责人的岗位往往都不会是前端出身，这让前端的话语权更加的弱势，造成相对后端和其他岗位而言，前端的延展性明显没有其他岗位高。

所以，上述各方面的因素这往往会很容易让前端浮于表面的展现形式、以及技术本身迭代带来的快感之中。

其实以上的情况，从这几年的趋势看来也是越发的严重。国内互联网环境的发展，让分工更加明确和细致。

曾经开玩笑的说，以前的前端是把后端写了「顺便」就把页面给套了，而现在的前端是往往实现了以后还要等后端的接口才能跑起来。而后端如果正儿八经想上手前端项目，先不说各种前端类库的选型，光是 webpack 本身的配置就足够让他忙活一阵子了。

我个人从前端转后端那么多年，这种情况其实也完全没有大的转变。虽然目前的国内技术环境普遍的浮躁不堪，但现在看来国内的前端环境尤甚。

那么我们能做些什么呢？其实以下不觉得是个非常好的建议，我也没理由讲些大道理。作为技术人员本身，其实在我看来这些都是基本的素质。

第一条建议，就是关注技术前沿的本身，其实更应该结合实际的项目已经产品的情况，避免空谈技术很无法落地成为空中楼阁。

这在前端这个圈子里是非常普遍的现象：「哎，这个玩意很厉害我应该套用到目前的项目中，先不管适用不适用，但我至少用起来了。」

第二条：其实每个人每个职位都会有自己的瓶颈期，当发现自己对于某项 case 已经长期无法突破的时候，那么应该跳出自己的思维路径，去考虑其他的角度看到更多的维度。

我看很多前端会说自己什么什么框架，然后列举了一大堆。但是在我看来掌握框架本身其实是「外功」，真正的「内功」修行应该提升到和设计思路这个层次。

例如，举个例子很多 Angular 初学者不知道依赖注入的思想，但是如果你是后端 Spring 使用者，那么会非常容易熟悉和理解。设计思想这块前后端很多时候是相通的。

如果你不理解就不会包容，就容易陷入框架和工具本身的争执中，因为你只是熟悉自己熟悉的。

那么第三条，我们就可以引申出来：避免多余的争论。我在 V2EX 上往往会 看到很多针对同类型的类库、重复的轮子的技术争论。

这些其实这是很容易挑起争端、引起话题，但同时也是很容易没有结果 － 毕竟都在一定程度上解决了相通的问题。

最后一条：更不要将技术和意识形态挂钩。这条其实是最基本的，同时也是最最重要的。

在我看来技术本身就是技术，是为了解决和实现具体的问题以及需求存在的，所以事物的本身不应该有任何的倾向性。

最后，我所期待的前端他应该是链接冰冷的数据和业务逻辑、给到真实用户体验的枢纽和桥梁。

所谓的「前端娱乐圈」当然只是笑谈，我们作为前端当然也应该知道前端本身能力所赋予的意义，前端这个圈子也不应该沦为技术无关的争论甚至意识形态的战场。

折腾的原因之一，也是因为在假期期间看到只需要 79 的 CIY68 「试轴器」，与其说是试轴器不如说是个入门的 68 键位的套件，该有的它都有所以性价比非常的高。

总体成本

除了 79 大洋的套件以外，剩下的键盘主要的费用就是轴体和键帽了，我研究了下如果使用国产的轴和键帽的话，那么总体基本上可以把预算和成本控制在两张人民币以内。那么，说干就干，以下是个人的搭配方案：

其他的，例如两节七号电池等就不记录进去了，总计 79 + 58 + 75 差不多 212 的样子。刚好预算 200 稍微出头一点（当然，如果总在乎预算方面的坚持，可以看下咸鱼）。

下面，逐个的说下这个配件的些到手以后的使用体验。

79 元的「试轴器」

CIY68 这个「试轴器」无论从价格还是功能上都满足了我个人对于套件的所有的要求：没有花花绿绿的 RGB 灯效、同时只使用干电池的方案，山寨杂牌的锂电池。

唯一不好的可能就是由于近期这款套件太过火爆，在电商平台上普遍都需要加价才能购买得到现货。我找了个相对靠谱的商家，对方没有给加价但是明确说明了包装拆封过，想想这个价位的套件就别要求那么高了…（还是因为预算有限吧）。

网上还有同学说这块试轴器的空腔音以及卫星轴的素质参差不齐，粗看卫星轴的轴体颜色以及模具几乎和小熊猫的卫星轴一摸一样，我到手的这块卫星轴已经润过，总体来钢丝音以及稳定性都在可以接受的范围内（当然细节就没法细究了）。

总体来说，如果和我一样基本上就拿来码字使用的话，这块称作试轴器的套件几乎没有太大无法让人接受的缺陷。

轴体

轴体的选择方面，其实是非常基于个人主观的品味的事情。

我自己在购买主轴体之前，买了各种的试轴器体验，所以基本上有个比较大概的印象。国产轴体的综合素质和性价比总体来说，如果盲按的话其实和樱桃轴几乎分辨不出有什么手感方面的差异。

考虑使用场景就是放在办公室码字比较多，加上喜欢段落感的轴体因此考虑茶轴。因为预算对比国产轴和樱桃茶轴，最终还是选择了凯华的BOX茶轴。

这是个比较难的选择，我在两个国产轴：凯华 BOX 茶轴和 TTC 金茶轴之间反复选择了好多次。这两款轴其实我按了很久，总体来说 TTC 的轴比凯华的要稍微有弹性一点，同时回弹方面来说 TTC 的感觉更加的明显。

然而，最终选择凯华的 BOX 茶轴还是因为价格的因素更多一些，毕竟 TTC 同款的茶轴的价格几乎是凯华轴体的两倍有余。所以，矿渣还是先入手便宜的吧，如果感觉不适合到时候换也可以。

键帽

键帽其实相对轴体更加的主观，主要考虑的是键帽高度的问题。从价格上来说，基本上几十块钱的键帽大多都是量产的所以手感上并不会有太大的区别。

考虑到是 68 键位的套件，所以我选择了 XDA 高度的键帽。电商平台上基于这个要求搜索剩下的可选的就很明显了，于是就挑选了个相对比较顺眼的即可。

其实个人不知道这个价位上能能不能买到实实在在的热升华 PBT 键帽，但是到手的时候还是有些翻车。

原装的空格键大键有菊裂，无法稳定的安装上去，所幸好在有增补的空格键，但是不是白色的了，如图上的「原谅绿」。“入门看轴体，深入看键帽”，深入下去的话其实这块比轴体的水还要深，所以就先这样子吧。

至此，如果你只是需要一把好用能用的客制化键盘，那么就已经组装完成了。其总体综合素质来说，并不比几百块钱的品牌量产键盘要差。

后续的优化

使用过几天以后，还是折腾的心里作祟，于是就继续投入了更多的预算到这块键盘上。回过头来想，这块键盘其他的些配件费用已经超出了原先定下的预算，这是后话了。

静音 Poron 海绵和垫子

首先，得先解决 CIY68 普遍存在的空腔音以及卫星轴问题，我搜索了下对应的解决方案就是更换 CIY68 的 Poron 夹心以及更换更厚的底部海绵。于是又购入了对应的配件，到手了以后和原装的配件对比下：

以上黑色的是 CIY68 自带的底壳海绵，白色的是新购入的海绵，明显发现厚度第三方的厚了很多。

同时，CIY68 自带的是白色的硅胶夹心，通常来说是够用了的。黑色的是新购入的 Poron 夹心棉，高度是一致的但是重量比硅胶的轻了非常多，同时其中有很多的细孔据说可以吸收声音和减震。

更换上 Poron 的夹心以后，按键的声音的确是比原先的要低沉了点、而且的重量比硅胶的轻了一些，不过其他的感官上的差别不大。

然后，考虑更换原厂的卫星轴，这块其实也不是必须的，网上说 CIY68 的卫星轴调教了以后其实素质也还可以，的确精润了以后这个微星轴还是可以使用的，但本着已经折腾了就顺手的态度，还是将微星轴做了更换。

卫星轴和 Proon 夹心是在一家店买的，更换的是国产圣熊猫的卫星轴。但是尴尬的是，这新的卫星轴这块到手以后我发现和 CIY68 原配的无论在磨具还是配色方面都差不多（几乎可以说一摸一样），唯一的细微差别可能是钢丝的厚度方面，圣熊猫的比原配的要稍微的粗一点，其他的差别不大。

为了保证卫星轴的素质和稳定性，我润滑了卫星轴以及在 PCB 上贴了特氟龙的贴纸，相对来说比原配的手感要稍微好一点点，至少钢丝音不见了。

但折腾了那么多综合总体来说，除非真的是完美主义情结作怪，CIY68 的原厂综合配件在润滑和调教以后是可以满足日常使用的，不用过多的折腾。

大键轴体

凯华 BOX 茶轴的轴体还是非常适合打字的，但吹毛求疵的话就是手感缺乏所谓的「立体感」。所以再折腾是想通过替换功能键和大键的轴体，达到手感方面的「层次感」和「立体感」。

凯华的 BOX 茶轴是个没有任何惊喜的万能轴，我计划给功能键和大键替换段落感更强的 TTC 月白轴，这样子两个通常的段落轴就可以搭配出比较有特点的手感层次。

说干就干，电商平台上购买了对应数量的 TTC 月白轴，TTC 的轴体价格对于国产而言其实真的并不便宜：二十颗月白轴需要大概六七十大洋。

替换上去以后，由于月白轴强烈的回弹属性，给功能键和大键搭配能够有非常好的反馈感。总体的手感又上了一个层次，相对于上面的替换 Poron 夹心的费用而言，同样的差不多的价格用于替换轴体而带来的手感提升很明显这是笔更值得的投入。

总结

最后，总结下十一期间折腾客制化键盘的些心得和碰到的些坑吧：

1. CIY68 的确是综合素质和性价比比较高的套件，如果是办公和码代码的话是非常值得入手的，当然细节方面得根据自己的需要进行调教；
2. 看见网上说替换 CIY68 套件的卫星轴能够给大键带来不一样的手感，但我至少替换成圣熊猫的卫星轴以后也没有带来很明显的差别；
3. 更换夹心棉和 Poron 的确能够带来敲击声的观感提升，但是没有更换轴体的效果那么明显。如果在有限的预算范围内，考虑更换轴体（卫星轴）的效果可能会更明显；
4. 具体个人替换什么轴体其实是非常主观的事情，长期来看这也是决定未来几年键盘使用手感，因此不要人云亦云买几个试轴器自己体验以后才能有更好的判断；
5. 不同轴体的搭配的确能带来更加立体的手感，但个人建议还是使用一段时间后再搭配其他的轴体，这块并不是提升手感的必要方案；
6. 键帽这块其实我个人考虑的非常少也不打算继续投入了，相对 CIY68 来说我个人还是比较推荐 XDA 高度的键帽，毕竟不是标准大小的键盘。

参考资源

• https://www.bilibili.com/read/cv12756536
• https://www.bilibili.com/video/BV1Bf4y1N7CQ/
• https://post.smzdm.com/p/ar6kpg7g/
• https://zhongce.sina.com.cn/article/view/70288/
• http://www.inwaishe.com/thread-26604-1-1.html

Clear Linux 是针对 Intel 平台的滚动 Linux 发行版。它有很多优势，我个人目前主要用来针对老机型（四代酷睿平台）的裸机运行平台，并主要用来跑虚拟机。

由于 Clear Linux 是过于强调精简的发行版，因此配置方面需要额外的精力，所在这里针对 KVM 虚拟机的配置做个记录。

BIOS 配置

针对硬件直通这块，首先需要 CPU 的支持，四代平台支持 VT-D 功能的不多，主要集中在 i5、i7 的 CPU。个人购买过四代 i3 的 CPU 发现并不支持硬件直通，所以又退款换货非常的折腾。

了解了支持的 CPU 以后，然后在 BIOS 中对应的开启虚拟化以及 VT-D，这里就不表。

内核配置

和其他的发行版不同，Clear Linux 的引导器是 Intel 自己研发的 clr-boot-manager。内核的参数文件具体的文件路径在 /etc/kernel/cmdline.d/ 这个目录中，然后对应的示例文件 iommu.conf:

intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 vfio-pci.ids=<id>,<id>

这个 ID 是 PCI ID，对应的可以使用 lspci -nn 获得，例如列出网卡的 PCI ID：

$ lspci -nn | grep -i Ether

00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04)
02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)

同时，需要注意的是 IOMMU Group 分组是否在一个组中（这个可能需要 PCI 设备的支持），可以使用以下简单的 Shell 脚本查看（来自 Arch 的 Wiki）：

#!/bin/bash
shopt -s nullglob
for g in `find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V`; do
    echo "IOMMU Group ${g##*/}:"
    for d in $g/devices/*; do
        echo -e "\t$(lspci -nns ${d##*/})"
    done;
done;

然后，使用 clr-boot-manager update 生成启动配置，然后 reboot 重启后查看 cat /proc/cmdline 内核引导参数是否已经生效。

Qemu 配置

查看 Qemu 下 PCI 的设备列表，例如

$  virsh nodedev-list | grep pci

pci_0000_00_00_0
pci_0000_00_02_0
pci_0000_00_03_0
pci_0000_00_14_0
pci_0000_00_16_0
pci_0000_00_19_0
pci_0000_00_1a_0
pci_0000_00_1c_0
pci_0000_00_1c_3
pci_0000_00_1d_0
pci_0000_00_1f_0
pci_0000_00_1f_2
pci_0000_00_1f_3
pci_0000_02_00_0

那么根据对并上面

$ lspci -nn | grep -i Ether

00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04)
02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)

两块网卡的 ID 分别为 pci_0000_00_19_0 和 pci_0000_02_00_0 ，然后我们 dump 出配置来

$ virsh nodedev-dumpxml pci_0000_00_19_0

<device>
  <name>pci_0000_00_19_0</name>
  <path>/sys/devices/pci0000:00/0000:00:19.0</path>
  <parent>computer</parent>
  <driver>
    <name>vfio-pci</name>
  </driver>
  <capability type='pci'>
    <class>0x020000</class>
    <domain>0</domain>
    <bus>0</bus>
    <slot>25</slot>
    <function>0</function>
    <product id='0x153b'>Ethernet Connection I217-V</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
    <iommuGroup number='4'>
      <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/>
    </iommuGroup>
  </capability>
</device>

例如以上就可以 dump 出具体 PCI 信息的来，可以比较直观的看到 product id 以及生产商 vendor id 等信息。这里需要的几个参数分别是 domain、bus、slot、以及 function 。

我们分别记录下来，然后填写到以下的 xml 片段中，例如上面对应的数值就是

<hostdev mode='subsystem' type='pci' managed='yes'>
  <driver name='vfio'/>
  <source>
    <address domain='0' bus='0' slot='25' function='0'/>
  </source>
</hostdev>

可以直接使用十进制数值，因为 virsh edit 在编辑保存的时候会自动计算其原始的十六进制数值。

验证

使用 virsh edit 编辑对应的虚拟机配置，例如 virsh edit <my-machine> 。在编辑器中将上述 的 xml 粘贴入 devices 这个 xml 块中，保存关机然后在启动虚拟机即可生效。

在启动虚拟机以后，例如上述的网卡直通可以使用 ip a 等命令查看虚拟机有无识别到对应的物理网卡。如果一切顺利，那么就可以使用对应的网络配置程序来配置对应网卡的网络信息，这里不在复述。

常见问题

1. 查看 IOMMU Group 中的设备是否分别在不同的组中，如果多个设备在同个组中，则需要额外的操作（参见 Arch Wiki 的内容）；
2. 如果物理机设备被直通出去，那么就无法使用该设备以及设备树下的子设备。例如，如果直通 USB 控制器给虚拟机，那么这个控制器下的键盘、鼠标都只能在虚拟机下使用；
3. 直通的内核模块应该优先于其对应的物理设备驱动，否则会造成冲突造成无法直通，因此可以考虑搭配内核 blacklist 使用。

最后，如果服务器是 Intel 平台的，强烈建议尝试下 Clear Linux 你会爱上它的！

参考信息

• https://6ki.org/2020/03/clear-linux-installation-and-simple-review/
• https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF
• https://wiki.archlinux.org/title/QEMU
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/virtualization/chap-virtualization-pci_passthrough

然而，有两个问题是我无法忍受的：第一，就是它的键盘简直可以用翔来形容。虽然，这个价位的笔记本对于做工方面不能有太多的要求，但毕竟每天都重度使用笔记本输入文字和代码，对于键盘的要求实在不能太低。第二，就是只有一个 USB Type-A 的接口，对比 MacBook Pro 来说接口相对已经足够的丰富，但是对于 Wintel 平台的笔记本而言扩展接口实在是少得可怜。

加上自己又有 ThinkPad 的情节，偶尔间碰到个比较良心的商家对比美行 X1 7th 的顶配只要国行的入门乞丐版的价格，这个诱惑实在是太大。于是，借故将小新笔记本充公给公司作为开发机使用，而自己又开始使用那个熟悉的带有小红点键盘的 ThinkPad X1 Carbon 7th。

Thinkpad X1 Carbon 7th

从硬件的角度上说，这台 X1 Carbon 7th 已经是顶配了：十代低压版本的 i7 10710u 、16g 内存、以及 4K 的 IPS 屏幕加上 LTE 模块；自己更换了原先 512G 的 NVME SSD 到了 1T，没有存储上的焦虑，一切都是看来那么得美好。

但是还是忽略了一点，就是续航以及 Intel 那糟糕的能耗比，导致这台机器向对比原先的小新 Pro13 而言在续航以及发热方面实在是无法比拟（AMD Yes！）。

没有办法，自己折腾的后果打碎了牙齿都要继续承担下去。

Linux & Windows

系统方面其实个人纠结了很久，出于需求的角度出发 Windows 是不得不用的，然而 Linux 作为开发而言也是不得不装的。因此，双系统就这样子提上了日程，从这段时间的使用角度出发个人呆在 Linux 系统下的时间明显比 Windows 多得多。

这个倒不是说 Windows 不好（虽然对比 Windows 的发热和续航明显更加降低和严重了），只是 Linux 环境下很多的工具以及应用更加的顺手。

这台笔记本还偶尔出现过睡眠方面的问题，好在 Google 以后知道能够捅菊花（reset）解决大部分的电源方面的问题（说多了都是泪水）。

Manjaro & Archlinux

Linux 的发行版其实一直都是比较难选择的事情，但其实说到底就是你用这个系统来干嘛。个人是 Archlinux 的忠实用户，但是在桌面端使用它还是会有些心智方面的困难。

Manjaro 对比也是使用过非常长的一段时间，大部分情况下它工作得都非常的好。然而，要知道 Manjaro 毕竟不是 Archlinux，虽然这除了所谓心智方面的纠结以外，其实没有更多其他的区别（但其实这点就足够了）。

同时，Manjaro 会针对图形界面加入了很多自己的「私货」，这在大部分情况下是非常方面的事情，但是这往往会造成其他各种各样的问题。

例如，我将这台 ThinkPad 接入 2K 显示器的时候，缩放就成了问题：虽然我知道如何去手工配置，但是对于 Manjaro 来说它不会推荐你这样做，同时表现来说也和 Archlinux 有很多的不同。以至于在这种情况下我非常讨厌外接显示器工作，宁可使用十三寸的笔记本来干活。

Fedora & Ubuntu

对比而言 Manjaro 和 Ubuntu 其实非常像：它们都封装了很多有用的工具给用户带来的便利，但同时也部分失去了所谓「原汁原味」的感觉。

而回到我自己一直很喜欢的 Archlinux，上面说过使用这个系统我一直有心智上的「强迫症」就是不停的会 sudo pacman -Syu，以保证系统一直在最新的状态。

所以，到最后干脆还是使用起 Fedora，毕竟一来它的更新迭代的周期是固定的，二来相对来说是纯净的（例如，至少不会同时给你安装个 xorg 以及 Wayland）。

早在前几天，就了解 CentOS 那点屁事，其实一直以来我一直都不是非常喜欢 CentOS。这是个非常擅长「钻空子、不劳而获」的发行版，那怕生产环境有大量的部署，我个人也不会主动推荐它。

这下反倒是好了，一来是可以安心的继续使用 Fedora 作为桌面、二来对于 Ubuntu、Debian 来说也是个利好，至少会有部分原用户会迁移到其上面来。

总之，暂时就先这样子折腾吧。对于这台电脑以及操作系统、甚至发行版来说说到底还是工具而已。自己已经在这个上面花了太多的时间去选择，接下来应该是把心给收收了。

- eof -

Docker Desktop 支持在 WSL2 下运行 Docker，也就是说可以使用以前同样的配置去解决 WSL 的宿主机（也就是 Windows 系统）的文件权限问题。

找个 PowerShell 打开 docker-deskop 的 WSL2 虚拟机终端

wsl -d docker-desktop

然后找到文件 /etc/wsl.conf ，建议保险起见先备份原有的配置。增加或修改对应的配置如下：

[automount]
enabled = true
root = /mnt/host
options = "metadata,umask=22,fmask=111"
mountFsTab = true

[filesystem]
umask = 022

然后重启 Docker Desktop 就可以了。PS，有其他 WSL2 访问宿主机碰到类似文件的权限问题也可以这样子处理。

- eof -