编注：利益相关声明：作者与文中产品有直接的利益相关（开发者、自家产品等）。

本期目录

🛠️TINKER ：提升效率的桌面工具

🔄OrbitRing ：将游戏 UI 带到 macOS

🗂️ airpriv ：让「本地优先」变成日常

▍@surunzi ：TINKER ，提升效率的桌面工具箱

前言

日常工作中会用到很多小工具，一部分来自工具箱类应用，一部分是单独的桌面应用，还有各种在线工具网站。比如正则表达式测试、JSON 编辑器、二维码生成、图片压缩等。这些工具散落在各处，每次使用都需要打开不同的应用或网站，不仅切换繁琐，在线工具还可能面临失效的风险。

很久之前就想把这些工具整合到一起，方便日常使用，但感觉工作量太大，一直抽不出时间。最近开始尝试 AI 辅助编码，发现开发效率确实提升不少，于是决定动手实现这个想法。

目前主体框架已搭建完成，所有工具都采用插件化设计，既可以内置在应用中，也可以通过 npm 安装扩展插件。现在主要工作是不断重写和改进自己常用的工具，逐步将它们内置进去，满足日常使用需求。这就是 TINKER，一款集成了丰富实用工具的桌面应用。

设计理念

TINKER 的核心设计理念是 "Toolbox for Everyone"，为所有人提供一个简洁、高效、本地化的工具箱，支持 Windows x64、macOS arm64/x64 和 Linux x86_64 多平台。它具有以下特点：

一、开箱即用

TINKER 目前内置了 20+ 个精选工具，涵盖开发、设计、日常办公等多个场景：JSON 编辑器、正则表达式测试、代码格式化、Markdown 编辑器、代码截图、十六进制编辑器、文本对比、哈希计算、图片压缩、图片裁剪、二维码生成器、颜色选择器、计算器面板、时间戳转换、密码生成器、单位转换、剪贴板管理、白板、Hosts 切换、番茄时钟等。

每个工具都经过精心设计，界面简洁直观，功能实用高效。

二、本地运行

相比于在线工具，TINKER 最大的优势是完全本地运行，所有数据都保存在本地，不会上传到任何服务器。处理敏感信息（如 JSON 数据、代码片段、图片等）时无需担心隐私泄露问题，同时支持离线使用，不受网络环境影响。

三、插件扩展

TINKER 支持 npm 编写插件，无需审核，用户可以根据需要扩展更多工具。

第三方插件

在 tinker-third-party仓库中可以找到已打包好的高质量第三方工具，通过 npm 即可快速安装。例如安装 Draw.io 画图工具：

npm i -g tinker-drawio

Web 插件

如果想将现有的在线工具添加到 TINKER 中，可以使用 Web 插件功能。在 tinker-web仓库中提供了一些预打包的 Web 应用，同样通过 npm 安装：

npm i -g tinker-deepseek

需要注意的是，Web 插件需要网络连接才能使用。

结语

TINKER 目前仍在持续开发中，未来将不断优化现有工具的功能和性能，同时添加更多实用的内置工具。如果你也经常需要使用各种小工具，不妨试试 TINKER，说不定正好能满足你的需求。

TINKER 是一个开源免费的工具箱应用，如果有任何建议或使用问题，欢迎在仓库中反馈。

仓库：https://github.com/liriliri/tinker

官网：https://tinker.liriliri.io

▍@Akring ：OrbitRing ，将游戏 UI 带到 macOS

起源

作为一个比较「老派」的重度游戏玩家，我日常玩的最多的游戏是《魔兽世界》《CS》以及《GTA》，他们中的 UI 有一个令我印象深刻的点：环形的技能/武器菜单。

从左至右：魔兽世界的 Opie 插件 ｜ CS Go 菜单 ｜ GTA 菜单

对此我还做了一些粗浅的研究，这种菜单又叫径向菜单（Radial Menu），是一种游戏中很常用的菜单类型，Steam 官方甚至还有 API 和文档 [Steamworks 文献库] 。它具有外观好看，功能实用的特点，而且操作起来简单又迅速，我个人非常喜欢这类设计。

于是作为开发者的我不禁在想，如果我能在 macOS 上也用上类似功能，是不是也能提升我的工作效率？

初版

事实证明，编码很像写小说，当灵感来袭时，想法源源不断，很难停止。最初我的计划是创建一个简单的 MVP，然后在 Figma 中进行 UI 设计和渲染，然后发出来测试一下市场的反应。

但当我意识到我已经远远超出了最初的计划时，已经太晚了。在不知不觉中，我已经准备好了一个「几乎已经可以运行」的应用程序了。它的功能也很简单而直接：按下一个触发键后，就能在鼠标位置展示一个圆环，并且在圆环中可以配置多个区块，每个区块对应一个 App，只要将鼠标滑向对应的 App，就能快速启动它。

OrbitRing 的设计

对程序员来说，写代码不算什么，真正的考验往往出现在最后两步：为 App 起一个好名字，并为它画出一个合适的图标。

名字和图标

名字的问题很快得到了解决，作为天文爱好者的我，感觉这个环形菜单就像土星环一样环绕在鼠标周围，所以我将其命名为：OrbitRing（轨道环）。

有了名称，图标也终于得到了解决，在设计师朋友的帮助下，我给 app 添加了这样的图标：

简约中带一些金属质感，让我想起黑暗的宇宙，和环形的宇宙空间站。

发布

作为一个典型的 I 人，虽然我从事开发工作已有多年，也发布过好几个 iOS 应用，但在上线自己的作品时，我依旧习惯于「悄悄地」把它抛出去，然后躲在角落里观察大家的反应。出乎意料的是，在 Reddit 和 Product Hunt 上，我收获了不少积极的反馈，这也让我更有信心继续打磨和迭代这款应用。

在最初发布后的大半年里，我为 OrbitRing 推送了多次更新。过程中，用户的反馈发挥了极大的作用，也让我意识到：同样的工具，不同用户会有完全不同的使用方式。正因如此，我一直努力提升应用的可定制性，希望无论是普遍需求，还是小众习惯，都能在 OrbitRing 中找到合适的解决方案。

超越 App 之外

在 OrbitRing 的最初设计中，它只支持快速启动应用，因为这正好满足了我个人的需求。但架不住用户们的呼声，我最终还是做出了一个违背祖宗的重大决定—— 扩展可打开的类型，新增了对网址、文件和文件夹的支持。

现在的 OrbitRing 配置窗口中，我们可以配置四种类型的项目，常用的文件和网站也能快速打开了。

App 配置 UI

网站配置 UI

配置文件夹

配置网站

回到现在

随着 macOS 26 的发布，OrbitRing 也紧随苹果的步伐，带来了全新的 UI 更新：适配了 macOS 26 的液态玻璃效果，无论是圆环还是配置页面，都焕然一新。希望你会喜欢这次的改进。

看到这里大家可能会吐槽这是磨砂玻璃不是液态玻璃，我也想问问库克，同样的 API 在不同的平台上差距咋这么大捏～

大家可能关心的问题

这是 OrbitRing 的第一年，我更期待的是，能和大家一起见证它成长，陪伴它走过更多年。

后记：我会在不少平台写东西，但在少数派写作最自在。没有太多限制，不用发布前用工具审查关键词，也不用担心「写太长没人看」，能尽情表达自己。感谢少数派，给了我一个舒服的创作角落。

链接：

https://orbitring.akring.com

▍@AirPriv ： airpriv，让「本地优先」变成日常

在越来越多事情被搬上云端之后，「我上传了什么」「数据会被谁看到」成了很多人绕不开的问题。

airpriv 是我正在开发的一个工具集合，希望把一部分「本来要交给服务器」的工作，尽可能拉回你的浏览器本地去完成。

因为是独立开发 所以收到的任何意见都能快速构建上线

为什么要做 airpriv

做 airpriv 之前，我自己就有几个长期的痛点：

• 处理音频、数据文件时，经常需要上传到陌生网站，心里总有点不踏实

• 临时用一下的小工具，装桌面应用嫌重、找在线服务又不确定质量和隐私

• 很多在线工具功能简单，但夹带了复杂注册流程、广告、追踪脚本

于是就萌生了一个想法：能不能把这些高频的小任务，做成「打开网页就能用、数据只在浏览器里转一圈」的一组工具？

airpriv 便是从这个想法出发，围绕「本地处理」「隐私友好」「开箱即用」这三个原则搭建起来的。

airpriv 提供了什么

部分展示

目前 airpriv 主要分成三个方向：音频工具、数据工具和安全相关的小工具。你可以把它理解成「一套在浏览器里跑的实用工具箱」。

音频工具（Audio Tools）

• 本地完成格式转换、压缩、简单处理

• 适合播客创作者、内容生产者快速做「交付前」的轻量处理

数据工具（Data Tools）

• 针对 CSV、JSON 等常见格式的一些查看、转换、清洗能力

• 方便在没有 Excel、没有本地开发环境的时候，快速检查和处理数据文件

安全工具（Security Tools）

• 聚焦在「临时」「一次性」的小需求，比如简单的加解密、散列校验等

• 用完即走，不需要留下任何账户或历史记录

这些工具有几个共通的设计前提：

• 任务尽量在浏览器本地完成，避免文件上传到服务器

• 尽量少依赖登录、账号体系，让「点开就能用」变成默认体验

• 在界面上保持克制：更多是「专业工具」而不是「消费级应用」

airpriv 目前还在持续开发中，上线的工具会根据使用情况持续迭代，未来也会围绕音频、数据和安全三个方向继续扩展。

和常见在线工具相比，有什么不一样

如果你经常用「某某在线转换器」「某某在线压缩工具」，可能会习惯性地问一句：这些事情已经有很多网站能做了，airpriv 有什么不一样？

对比下来，主要有三点差异，是我在设计之初就刻意坚持的：

更明确的隐私边界

• 工具优先考虑在本地执行，把「文件上传到服务器再处理」作为最后选项

• 功能设计上尽量不依赖持久化存储，不做「顺带帮你存一份在云端」

针对「重度用户」的小优化

• 预设更贴近创作者、开发者、数据从业者的使用习惯，而不是一次性访客

• 更关注「每次多省几秒」「少点几下」而不是堆功能标签

聚合而不是分散

• 把音频、数据、安全常见的小任务集中在一个工具集合里

• 降低「我遇到一个问题又要去搜索一个新网站」的心智成本

换句话说，airpriv 更像是为一小部分对隐私有要求、对效率有追求的人准备的「浏览器里的瑞士军刀」，而不是单一场景的 landing page 式工具。

实际使用场景举例

为了让你更容易判断「这是不是一个你会用到的东西」，这里举几个真实会发生的场景：

播客上线前最后一步

• 你已经在主力 DAW 里完成剪辑，只剩下格式转换、比特率调整

• 打开 airpriv 的音频工具，在浏览器里拖进去文件，几秒钟完成处理，然后直接上传到托管平台

临时检查一份 CSV / JSON

• 在外面只有一台没有办公软件的电脑，但需要快速确认一批导出数据有没有问题

• 用 airpriv 的数据工具打开文件，按列、按条件快速过滤和检查，确认没问题后删除本地文件即可

校验一个下载文件的完整性

• 从陌生网站下载了一个安装包，对方提供了哈希值

• 打开 airpriv 的安全工具，在浏览器本地算一遍散列值，比对无误再安装

这些任务本身都不复杂，但重复频率很高，且经常发生在「你不在自己的主力环境」的场景里。

airpriv 想做的，就是让这些瞬间变得简单一点、安全一点。

开发者视角下的一些取舍

如果你也是开发者，可能会对背后的技术和取舍更感兴趣，这里简单分享几个实现与设计层面的决定：

尽量选择能在浏览器端完成的方案

• 在音频和数据处理上会优先考虑 Web API、WebAssembly 等方式

• 服务端更多承担「分发页面」而不是「替你执行计算」的角色

明确区分「工具集合」和「平台」

• 没有打算引入复杂的账户体系、用户资料、消息系统等

• 工具之间保持相对独立，彼此通过统一的设计语言和导航串联起来

尊重用户的「退出权」

• 工具默认不做长期绑定，如果你只是使用一次，也不会因此多出一个「要长期维护的账号」

• 不依赖个性化推荐和复杂埋点，避免为了「增长」牺牲透明度

这些取舍让 airpriv 的迭代节奏会慢一些，但对使用者来说，可以更清楚地知道自己正在把什么交给这个网站、又保留了什么在自己手里。

未来的方向与计划

目前 airpriv 仍处在「打地基」阶段，已经上线的工具，会根据真实使用情况持续迭代。同时，也在规划一些下一步的方向：

• 针对数据从业者，增加更多和格式转换、验证、可视化相关的轻量工具

• 在不增加负担的前提下，为安全工具补充更多「教你理解而不是只是给你结果」的说明内容

如果你对音频、数据处理或安全工具有长期需求，很欢迎你尝试一下现有工具，并把你的体验和想法反馈给我。

你的具体使用场景，可能会直接变成下一批功能设计的来源。