这周的新工具列表，像是在替开发者清理桌面。

那些曾经散落在 /tmp、命名为 test/test2/actually-final 的目录， 那些永远配不好的 Makefile 环境， 那些需要记住"这个知识在哪个笔记里"的心理成本。

这周的工具们在说：别记了，让工具来记。

本周一句话总结

新增不算多，但方向很明确——开发者开始为"减少心智负担"付费，而不是为功能付费。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节不求全， 只挑 3 个 值得停下来看的点。

try：省掉"这个目录叫什么来着"的记忆成本

你有多少个叫 test、test2、new-test、actually-final 的目录？

它们散落在你的 filesystem 各处，有些在 /tmp，有些在 ~/projects/experiments，还有些在你自己都记不清的位置。过了一周再想找某个实验，只能靠 find . -name "*redis*" 碰运气。

try 解决的就是这个看似微小但持续消耗心力的问题。它给每个实验一个带日期的名字（比如 2025-08-17-redis-experiment），然后用智能模糊搜索让你瞬间找到——不是简单的字符串匹配，而是根据最近访问时间排序。

最妙的是它的哲学："Your brain doesn't work in neat folders. You have ideas, you try things, you context-switch like a caffeinated squirrel."

它没有试图教你整理文件夹的正确方式，而是承认了你的混乱，然后让它变得可用。

lazymake：让 Makefile 不再是个黑盒

Makefile 的问题从来不是语法难，而是你永远不知道里面定义了什么 target。

你打开一个项目，看到几十个 target，但不知道哪些是常用的，哪些之间有依赖关系，哪些会触发耗时很长的重建。要么硬着头皮读 Makefile，要么凭记忆猜 make build 还是 make compile。

lazymake 提供了一个漂亮的 TUI 界面，把所有 target 摊开来给你看。它能显示 target 之间的依赖关系，标记出常用的命令，甚至能预览执行结果。

对于那些不常接触但偶尔需要修改的项目，这种可视化的价值在于：你不需要重新理解整个构建系统，只需要在界面上找到你想要的那个按钮。

tolaria & cavalry：工具的分化

这周的两个 Cask 指向了两个不同的方向。

cavalry 是一个专业的 2D 动画软件，实时渲染、数据导入、rigging 系统——它是那种"把一件事做到极致"的工具。你需要学习它的专业术语，理解它的工作流，但一旦掌握，就能做出专业级别的作品。

tolaria 则完全相反。它是一个 Markdown 知识库管理器，但它的设计哲学是"不要学习新东西"。你的笔记就是普通的 .md 文件，用任何编辑器都能打开；版本控制就是 Git，你可以用命令行查看历史；甚至 AI 集成也是通过标准的 MCP 协议。

一个是封闭的专业系统，一个是开放的通用工具集。

两者都有价值，但趋势是：当工具的复杂度超过某个阈值时，用户开始偏好"只是文件"的可携带性。tolaria 的安装量（242次/30天）比 cavalry（105次/30天）高出一倍多，这可能不是巧合。

一点个人感受

try 和 lazymake 都是那种"装了之后不会卸载"的工具——它们解决的问题太小太日常，以至于一旦习惯就回不去。

相比之下，cavalry 这类专业工具更像是"有一天我会需要"的存在。它的功能很强大，但学习曲线意味着你必须在某个时间点集中投入精力。而现代开发者的时间碎片化程度，可能已经不支持这种深度学习了。

tolaria 的出现时机很有趣。它强调"笔记只是文件"、"Git 就是同步"、"MCP 标准接口"——这些都是在回应 Notion 等云端工具带来的焦虑：我的数据在哪里？我能带走吗？如果服务关闭怎么办？

也许下一代的工具不是功能更强的那个，而是让你最安心的那个。

结语

这周的工具列表里没有改变世界的东西。

但它们都在做同一件事：把开发者从"我需要记住什么"解放到"我只需要创造什么"。

try 省掉了目录命名的心理负担，lazymake 省掉了理解构建系统的负担，tolaria 省掉了担心数据锁定的负担。

工具在变，但好的节奏应该是：负担在消失，而创造力在增加。

下周见。

一个可以统计token使用的小工具

• getagentseal/codeburn: See where your AI coding tokens go. Interactive TUI dashboard for Claude Code, Codex, and Cursor cost observability.

四月的第四周，工具列表突然变得拥挤。

brew update 之后跳出来一长串新增， 不是那种零星的点缀，而是成批的工具在找自己的位置。 有些是为了连接消息平台，有些是为了给 AI 代码助手加个壳， 还有一些，是 Apple Intelligence 落地后的余波。

本周一句话总结

AI 不再是单一工具，而是变成了需要被"连接"、"管理"、"编排"的基础设施——这周的更新像是在搭建一层中间件。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一周的新增很多， 但有几个工具指向同一个趋势： **AI 代理正在从"工具"变成"需要被管理的对象"**。

cc-connect：把 Claude Code 接到你的聊天软件里

一个公式，连上了 9 个 AI 代理和 11 个聊天平台。

cc-connect 做的事情很简单：让你在 Telegram、Slack、钉钉、飞书甚至微信里，直接调用本地的 Claude Code、Cursor、Gemini CLI 或其他 AI 编码助手。不需要公网 IP，不需要自己搭服务器，装完就能用。

它解决的不是"怎么用 AI 写代码"这个问题，而是"怎么在不离开聊天软件的情况下用 AI 写代码"。对于很多人来说，聊天软件已经是工作流的中心——团队讨论在那里，任务分配在那里，现在 AI 代理也要去那里。

43 个安装量说明它还很小众，但这种"桥接"本身是一个信号：AI 代理不再是单独打开的应用，而是要被嵌入到现有工作流里的服务。

Web 管理界面可以配置多个项目，支持多代理编排、会话管理、模型切换——这些功能出现在一个 Homebrew formula 里，有点意外，也有点合理。

t3-code@nightly：给 AI 代码助手加个壳

T3 Code 是一个"minimal GUI for AI code agents"。它的逻辑更直接：既然 AI 代理已经在后台跑了（Claude Code、Cursor、Aider 等），那给它套个简单的图形界面会不会更好用？

界面确实简单：左边是文件树，右边是对话框，底部是终端输出。没有 VS Code 那么重的插件系统，没有 JetBrains 那么复杂的配置菜单，就是一个能让你和 AI 对话、看它改代码的窗口。

这种"精简"背后有个隐含判断：当 AI 能处理大部分编码任务时，IDE 的复杂度就变成了负担。你不需要那么多快捷键，不需要那么多面板，只需要一个能让 AI 展示它工作的地方。

nightly 版本的存在说明这个项目还在快速迭代中。43 个安装量和 cc-connect 一样，都是早期采用者的数量级。

google-gemini：Apple Intelligence 缺席后的替代方案

Google Gemini 桌面应用在四月登陆 macOS，要求 arm64 架构和 macOS 15+。2380 个安装量是这周所有新增里最高的。

它的出现有个背景：Apple Intelligence 在国内用不了，而 Google 的 Gemini 应用刚好填补了这个空白。不是所有人都愿意折腾区号、换账号，但所有人都想要一个能在桌面上随时唤起的 AI 助手。

FluidVoice（离线语音转文字，170 安装量）也是同样的逻辑：当系统自带的听写功能不够好或者不可用时，第三方的 AI 增强方案就成了刚需。

这两个工具的共同点是"补位"。它们不是创新，而是在现有生态的空缺处填上自己的形状。

趋势观察：AI 代理中间件化

如果把 cc-connect、t3-code、pocket-id（身份认证）、renameclick（AI 文件重命名）放在一起看，能看到一个模式：

AI 不再是单一工具，而是变成了需要被连接、管理、认证、封装的基础设施。

• cc-connect 负责把代理接到聊天平台
• t3-code 负责给代理套个轻量 GUI
• pocket-id 负责管理谁可以访问这些代理
• renameclick 负责把 AI 能力应用到具体场景（文件命名）

这和十年前的"云服务中间件化"很像。当时出现了 Kubernetes、Docker Swarm、Consul 这些工具来管理微服务；现在出现了类似的工具来管理 AI 代理。

区别在于，这次的速度更快。从"AI 助手能用"到"需要管理 AI 助手"，只用了不到两年。

其他值得提一下的

Odin 语言工具链成熟：odinfmt（格式化）和 ols（Language Server）的同时出现，说明这个自称"为稳健性、最优性和清晰度设计"的系统编程语言正在形成完整的开发体验。Zig 0.15 的独立分支也是同一件事的另一面。

paneru：窗口管理器的长尾需求：macOS 上的平铺窗口管理器一直有小众但稳定的需求（Amethyst、yabai、Rectangle 各有拥趸）。paneru 的出现说明这个细分市场还有空间。

OpenSSL@4：版本号的惯性：OpenSSL 跳到第 4 版主分支，但绝大多数人还在用 1.x 或 3.x。keg-only 的打包方式说明了 Homebrew 的态度：给你装，但不主动 symlink，让你自己决定要不要用。

一点个人感受

这周的新增列表读起来有点像在翻某家创业公司的产品目录。不是那种"又多了个 XXX 工具"的平淡，而是"原来这个环节已经有人在做产品了"的惊讶。

cc-connect 和 t3-code 这类工具的出现，说明 AI 编码助手已经从"尝鲜阶段"进入了"需要被整合进工作流"的阶段。这不是技术突破，而是工程化。

我注意到两个细节：

1. 安装量都很低：43、43、170……这些数字说明还在早期。但对于 Homebrew 这种分发渠道来说，早期采用者的选择往往预示着下一步的主流。

2. 夜间构建版本的增多：t3-code@nightly、vlc@nightly（虽然即将被废弃）……这说明有些项目正处于快速变化期，稳定版跟不上节奏。

还有一点主观的感受：当"管理 AI 代理"变成一个独立的需求类别时，有点讽刺。我们本来指望 AI 能简化管理工作，结果反过来要管理 AI 本身。但这可能就是技术演进的路径——每一层抽象都会带来新的复杂度，然后再催生下一层抽象来处理它。

结语

工具在变多，但节奏不必跟着变快。

这周新增了 7 个 Formula 和 15 个 Cask，是近几个月最热闹的一周。但真正值得记住的不是数量，而是方向：AI 正在从"用来做什么"变成"怎么被组织起来"。

有时候，brew update 之后看到的不只是新工具，还有工具之间的空隙——以及填补那些空隙的新工具。

NDSi

Ref

• DS(i) NOOB PARADISE - Ask questions here
• DSi Guide
• DS-Homebrew Wiki

2种方式

• FBA4DSTWO（Final Burn Alpha for SuperCard DSTWO），移植自FBA4PSP。
• MAME4ALL for supercard DSTWO by Alekmaul，是英文论坛会员alekmaul独立开发

ROM 兼容性

FBA4DSTWO 适配 MAME 0.141 MAME4ALL 适配 MAME 0.37b5

Ref

• Supercard DSTwo Software? | GBAtemp.net - The Independent Video Game Community
• DSTWO插件下载_DSTWO专用MAME模拟器软件NDS MAME_SuperCard官方中文网
• FBA4DSTWO | GBAtemp.net - The Independent Video Game Community
• FBA4DSTWO - GameBrew
• rereprep/fba4dstwo: FBA emulator for supercard dstwo.
• DSTwo Plugins - GameBrew
• DSTWO - GameBrew
• MAME 0.139u1 (MAME4droid) ROMs. Free Download - wowroms.com - page 1
• DSTwo Plugin - WikiTemp, the GBAtemp wiki

最近做需求，想在项目中添加一个mock数据的功能，没想到会让我有诸多感思。

先说一下，项目背景：

• 纯前端项目，使用React18.2
• 项目是在2025年5月份左右创建，距离现在大约快1年时间

有意思的部分是，项目中使用了 react-app-rewired 这个工具。

这个工具是做什么的呢？

可以在不 eject 的情况下，调整 create-react-app 的 webpack 配置

当然远不如此，基本可以做到完整接入 webpack 的功能。

因此，这个项目很受 React 开发者喜欢，获得了 9.9K Star。

随着前端技术持续发展，CRA（create-react-app）经历了多次迭代，最后在2022年4月份之后停止了更新。

在CRA迭代的时间里，react-app-rewired 也一直在更新，直到同年2022年2月份之后也停止了更新。期间，做了大量对CRA的适配工作，老版本支持 webpack3.x，新版本支持webpack4.x。

但是，适配的工作永远没有尽头。

然后出现了，customize-cra 这个项目。

This project provides a set of utilities to customize create-react-app versions 2 and 3 configurations leveraging react-app-rewired core functionalities.

字面意思说，可以支持 create-react-app 版本 2 和 3 的配置。

实际上，customize-cra 在2020年5月份就走到了尽头，CRA的后续版本（4.x / 5.x）都无法支持。

在 react-app-rewired 项目获得关注后，React 社区又出现了新玩具🪀：

• Rescripts, an alternative framework for extending CRA configurations (supports 2.0+).
• react-scripts-rewired for a fork of this project that aims to support CRA 2.0
• craco

毫无例外，上面项目现在都已经停止了更新和维护。

这些项目停止更新前，最少也是 1k star。 但，CRA 更是夸张的收获了 104k star。

这件事情，告诉了我一个事实：

如果使用的第三方工具，它的依赖不够透明且过度封装，将导致失去灵活性扩展性。同样它也绝对不可靠不稳定，和不可持续。

Ref

• React / Create React App — But I don’t wanna Eject. | by tim arney
• facebook/create-react-app: Set up a modern web app by running one command.
• Create React App无eject配置（react-app-rewired 和 customize-cra）
• timarney/react-app-rewired: Override create-react-app webpack configs without ejecting
• arackaf/customize-cra: Override webpack configurations for create-react-app 2.0

开始学习 Swift

Ref

• 焦虑：一天都没找到合适的 Swift 开发 IOS 应用的入门教程 - V2EX
• SwiftUI Tutorials
• Welcome to Develop in Swift Tutorials

Harness Engineering 是啥？

四月中旬,苹果的系统能力开始以工具的形态外溢。

Apple Intelligence 有了命令行入口,Apple Containers 有了原生 GUI,终端里甚至多了一个电子表格。与此同时,一个六万星的 AWS 模拟器被标记 deprecated,依赖链在同一天被清理干净。这一周的列表,一半在打开新入口,一半在关闭旧通道。

本周一句话总结

系统能力在变成命令行工具,旧工具在变成历史注脚。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

本周重大更新与变化

📦 Major Updates (Casks)

⚠️ Notable Changes (Formulae)

值得留意的几个方向

apfel：Apple Intelligence 的命令行入口

Apple Intelligence 一直藏在系统设置和 Siri 后面。apfel 做的事情很简单:给它开了一扇终端的门。

brew install apfel,不需要 API key,不需要下载模型,不需要配置。macOS Tahoe 自带一个约 30 亿参数的语言模型,跑在 Apple Silicon 的 Neural Engine 上。apfel 把这个模型通过 Apple 的 FoundationModels 框架暴露出来,提供三种模式:命令行工具、交互式聊天、OpenAI 兼容的 HTTP 服务器。

最后一点是关键。OpenAI 兼容意味着你现有的任何用 OpenAI SDK 写的脚本,只要把 base URL 改成 localhost,就能接上苹果的本地模型。零成本,完全离线,数据不出设备。

但 4096 token 的上下文窗口决定了它的定位:快速的文本处理、shell 脚本里的胶水层、commit message 生成这类短任务。不是用来替代 Claude 或 GPT 的,是用来替代"这个小任务值不值得调一次 API"这个纠结的。

它还支持 MCP。这意味着你可以把本地文件系统、数据库、甚至其他 API 作为工具接进来。一个免费的、完全本地的、支持 tool use 的 AI——虽然能力有限,但对于自动化脚本来说,够了。

orchard：Apple Containers 有了自己的 GUI

Apple Containers 是苹果在 macOS 26 上的原生容器方案。orchard 是它的第一个第三方 GUI。

要求 macOS 26 以上,这说明它完全依赖苹果的原生虚拟化框架,没有绕道 Docker Desktop 那套。对于那些"想在 Mac 上跑容器但不想装 Docker Desktop"的人来说,这条路终于开始有工具了。

目前安装量只有 107,说明 macOS 26 的用户基数还很小。但它进了 Homebrew Cask,意味着苹果的容器生态正在从"技术预览"走向"有人在上面写工具"的阶段。

localstack：六万星项目的体面退场

LocalStack 是本地模拟 AWS 服务的工具。S3、DynamoDB、Lambda、SQS——你能想到的 AWS 服务,它都能在你的笔记本上跑一个假的出来。64,900 颗星,是很多团队本地开发和 CI 流程里不可或缺的一环。

三月底,上游仓库被标记为 archived。官方的说法是"合并到统一镜像",提供一个"更可靠和精简的体验"。翻译一下:开源版和商业版要合并了,以后只有一个入口——那个带 Hobby 免费计划的统一版本。

Homebrew 这边的反应很快。4 月 12 日,localstack 被标记 deprecated,同一天 awscli-local 移除了对它的依赖。依赖链的清理比项目归档还要干脆。

这是一个典型的"开源项目商业化收编"的故事。免费版没有消失,只是搬了个地方,换了个名字,加了个注册页面。对于那些在 CI 脚本里写死了 brew install localstack 的团队来说,这周要改一行命令了。

趋势观察：AI 代理的基础设施在成型

这周的 Cask 列表里,AI 相关的工具密度很高:

• cc-switch: AI coding agents 的配置管理器——当你同时用 Claude Code、Cursor、Copilot,每个都有自己的配置文件,cc-switch 在管这件事
• hive-app: 跨项目并行编码的 AI 代理编排器
• rowboat: 带记忆的 AI 协作助手
• vibe-island: 灵动岛里的 AI 代理
• copilot-language-server: Copilot 的 LSP 实现,上期在 Formula 里出现过,这次 Cask 也有了

这些工具不是 AI 模型本身,是 AI 模型的"水电煤"——配置管理、任务编排、记忆持久化、界面集成。当围绕 AI 代理的基础设施开始密集出现,说明这个领域正在从"尝鲜"进入"日常使用"。

一点个人感受

apfel 让我意识到一件事:macOS 自带的那个语言模型,我从来没主动用过。不是因为它不好,是因为它没有入口——或者说,它的入口是 Siri,而我已经很久不和 Siri 说话了。apfel 给了它一个我愿意用的入口。

localstack 的退场让我想起一个模式:开源项目做大,商业化收编,免费版变成"免费计划"。这不是坏事,但每次看到都有点微妙的不适感——像是你常去的公园突然加了个扫码入口,里面的东西没变,但感觉变了。

这周的 Cask 列表里有 8 个字体。字体包进 Homebrew 这件事,说明开发者对字体的态度变了——以前是"系统默认就行",现在是"我的终端要用 JetBrains Mono,我的编辑器要用 Fira Code"。字体成了开发环境的一部分。

cc-switch 的存在让我觉得,AI 编码工具的碎片化程度,已经到了需要一个"配置管理器"来管配置管理器的地步了。

结语

苹果的系统能力正在被拆解成一个个命令行工具和独立应用。Apple Intelligence 不再只是 Siri 的后端,Apple Containers 不再只是 WWDC 的演示。当这些能力出现在 brew install 的列表里,它们就从"平台特性"变成了"开发者工具"。

与此同时,旧工具在退场,新的基础设施在铺设。这一周的 Homebrew 不安静,只是变化的方式不一样了。

系统能力变成工具的那一刻,才是它真正被接受的时候。

这周的工具列表里，突然多了很多"移植"的影子。

不是新想法，是旧思路在换场景。Swift 想去 Android，Python 想用 Rust 重写，AI 订阅想借给编辑器用。看起来我们进入了"不是造新轮子，是把轮子装到别的车上"的时期。

本周一句话总结

一批关于"如何把 A 搬到 B"的工具。

四月初的工具箱，越来越多的是"怎么把这套路子移到那边去"

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

skip：把 Swift 搬到 Android 这件事

Swift 本来只活在苹果生态里。skip 想做的是：让你用 Swift 写一套代码，同时编译出 iOS 和 Android 应用。

不是跨平台框架那种"写一次，到处丑"的方案。是"写 Swift，编译出真的 Kotlin"。它在编译层动了手脚，不是在运行时做兼容。

这省掉的是"又要学 Kotlin 又要学 Swift"这件事。但代价是你得接受 skip 对 Swift 的理解——它能翻译的只是 Swift 的子集。

rustpython：用 Rust 重写 Python 解释器

Python 慢是因为解释器用 C 写的，Rust 重写能快多少？rustpython 在试这个问题。

它不是要替代 CPython，是在做"如果我想嵌入一个 Python 解释器到 Rust 项目里，我能不能不依赖 CPython"。这解决的是 FFI（Foreign Function Interface）的心智负担——不用管内存怎么在 Rust 和 C 之间传，直接在 Rust 里跑 Python 代码。

但这意味着很多 CPython 的扩展不能用。如果你的代码依赖 numpy、pandas 这些，rustpython 暂时帮不了你。

vibeproxy：让 AI 订阅共享给多个工具

你订阅了 Claude Pro，想在 VSCode、Cursor、终端里都用。vibeproxy 做的是：它假装自己是 OpenAI API，把请求转给你的 AI 订阅。

省掉的是"每个编辑器都要配一遍 API key"这件事。也省掉"买多个订阅"的钱。

但它是个代理层，所以延迟会多一点。而且它要一直跑在后台。适合那种"我就是想把 Claude 用在所有地方"的人。

git-format-staged：只格式化你改过的代码

你在一个老项目里改了三行代码，prettier 想把整个文件重新格式化一遍。git commit 的时候 diff 一团糟，reviewer 看不出你到底改了什么。

git-format-staged 做的是：只对你这次暂存的那几行代码跑格式化工具，其他地方不碰。

这省掉的是"要不要先提一个纯格式化的 commit"这种纠结。也省掉"手动选中要格式化的行"的操作。

一点个人感受

graalvm 进 Homebrew 了，这是个信号——Native Image 的编译时间从"能忍"变成"可以接受"了吗？还是大家放弃了等它再快一点？

skip 的思路很聪明，但我不确定会有多少人愿意把 Android 的生命周期交给一个编译层。万一哪天 Kotlin 出了新特性，skip 跟不上怎么办？

vibeproxy 让我想起以前用 SS 的时候，那种"把一个订阅分给所有设备用"的感觉。工具本身没问题，但我隐约觉得这类需求的存在，说明现在 AI 订阅的定价模式还没稳定下来。

结语

迁移永远比重新开始便宜，但只在你知道终点不会变的时候。

这周的工具都在省一个成本：学习新东西的成本。但它们的代价是你得相信这条迁移路径会一直有人维护。

工具在变，但节奏不必跟着变。

下期预告 继续观察 Homebrew 的动向，看看四月中还会出现哪些"省心智成本"的工具。