这周新进来的工具，很多都在干同一件事：把 AI 编程的过去和未来都搭一遍脚手架。

有些工具是为了跑得更快；有些工具是为了记住跑过哪里。
这周的新增偏向后者——不是 CLI 工具突然变多了，
是 AI 编程的上下文管理开始有了自己的工具链。

本周一句话总结

AI 编程从"写"进入了"观察与编排"的阶段——这周入库的工具，超过一半在帮你理解已经发生的事。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

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

agentsview：AI 编程的"回放键"终于来了

用 Claude Code、Cursor、Codex 写了几个月代码——你记得上周三用 agent 干了什么吗？

大概率不记得。这不是记性问题，是 AI 编程产生了一种新的历史：不是 git log，不是 IDE 历史记录，而是"我跟 agent 说过什么、agent 做了什么"。这段历史一直散落在各工具的本地缓存里，没有人帮你整理。

agentsview 做的就是这件事。它把 Claude Code、Codex、Gemini、Copilot、Cursor 等 20 个 agent 的会话历史统一读进来，全文索引，可以按项目、按工具、按时间筛，支持 token 用量和费用报表，号称比同类工具快 80-220 倍。

真正让我觉得有意思的是它的定位：local-first，SQLite，不联网，不注册账号。它没有试图成为一个 SaaS，而是选择把你的历史还给你自己。这在满地"云端同步"的工具里显得有点反常，但可能是对的。

gascity：多 Agent 编排，从玩具变成水管

以前协调多个 AI agent 同时工作，基本靠自己写 shell 脚本拼凑。gascity 想干的事情是把这层"水管"标准化——用一个 city.toml 声明你想跑哪些 agent、用什么运行时（tmux、子进程、Kubernetes），剩下的路由、状态同步、健康监控交给它。

底层依赖 beads（自家的任务跟踪）、dolt（可版本控制的数据库）、tmux、jq，整个项目用 Go 写，CLI 叫 gc。设计上走"原语优先"——不提供高层抽象，提供足够小的积木让你自己组。

这个工具现在刚进 Homebrew，安装量还是两位数。但它试图解决的问题——多 agent 编排的可复现性和可观测性——是真实存在的。随着 agent 场景从单机变成集群，这类基础设施迟早会有人需要。

fallow：代码库的"体检报告"

TypeScript/JavaScript 项目用久了之后，总会有一些"可能没人用了但谁也不敢删"的代码。fallow 的核心主张是：静态分析告诉你"什么可以删"，运行时数据告诉你"什么安全删"。

npx fallow dead-code 扫出没用到的文件和导出；npx fallow dupes 找重复逻辑；npx fallow health 给复杂度热力图。静态能力开源免费，运行时那层是付费的。

有趣的是它支持 MCP，可以接入 Claude Code 或 Cursor 的 agent 流程——这意味着它不只是一个跑完就算的 CLI，而是可以嵌进 AI 编程的工作循环里。

趋势小结：Agent 编程开始需要"配套设施"了

这周的三个 formulae/casks 指向同一件事——

agentsview 管历史，gascity 管协作，fallow 管代码质量。
这不是工具的堆叠，是 AI 编程从"我让 agent 写了一些代码"变成了"我需要管理 agent 做的事情"的信号。

以前 CLI 工具大量涌现是因为开发者在搭工作台；现在 agent 工具大量涌现，是因为 agent 本身开始需要一张工作台。

一点个人感受

gascity 和 agentsview 在同一周进入 Homebrew，我不确定是巧合还是某种时机。

agentsview 我可能会用——之前一直想找个办法回顾和 Claude Code 的对话历史，虽然现在有 /cost 和各种日志，但搜索还是很麻烦。local-first 的设计打消了我最大的顾虑。

gascity 和 github-copilot-app 都在 agent 编排这个方向，但路子完全不同：一个是工程师手搓的 Go CLI，一个是 GitHub 官方出的桌面应用。我对后者更好奇，尤其是它声称能"跨 agent 并行管理多个工作流"，但目前公开的细节还很少。

fallow 倒是让我想到了一个问题：AI agent 越来越擅长写代码之后，谁来负责清理 agent 留下的技术债？也许就是 fallow 这类工具。

结语

有些工具是锤子，看见钉子就用。
这周进来的工具更像是量尺——帮你看清楚已经发生了什么，才好决定下一步。

观察工具和使用工具，是两种不同的习惯。
但也许，后者越来越需要前者打底。

工具在变，但看懂工具在干什么，始终是你自己的事。

我现在coding的主力工具是VSCode+Claude，之前一直使用Cline。

在Cline中使用Claude，享受GUI的乐趣。

随着时间的推移，发生了很多事情：

• Claude审查变得更加严苛
• Cline中使用Claude，频繁报错
  ...

然后，我开始逐渐适应在CLI工具中使用Claude。

自从开始使用AI Coding，总感觉设备的内存不够用，一直维持在80%以上的使用率。

日常基本就是，

• Chrome，非常吃内存
• iTerm，可接受
• VSCode，跟Chrome有得一拼

Chrome 重度使用，一时半会没有找到合适的平替，想迁移过去有点困难。

VSCode 基于Electron开发，多开几个tab，就能赶上Chrome了。

VSCode中，一些场景下会使用VI模式，例如：Code Review。

古法编程，看情况用，加上macOS上，触控板太好用了，没有很迫切转Vim。但，现在开始非常想使用nvim替代vscode，即装13又可节省内存。

况且，都使用AI Coding了，Review 和思考的时间居多，GUI没那么有趣了。

配置后的样子，

iTerm 配置

tmux 配置

# 安装 tmux
brew install tmux

# 配置 .tmux
git clone --single-branch https://github.com/gpakosz/.tmux.git "/path/to/oh-my-tmux"
mkdir -p ~/.config/tmux
ln -s /path/to/oh-my-tmux/.tmux.conf ~/.config/tmux/tmux.conf
cp /path/to/oh-my-tmux/.tmux.conf.local ~/.config/tmux/tmux.conf.local

配置完成后，执行：

tmux source-file ~/.config/tmux/tmux.conf

常用的快捷方式

• <prefix> e， 打开 .local 自定义文件
• <prefix> r，重新加载配置
• <prefix> m，开关鼠标模式
• <prefix> C-c，创建一个新会话
• <prefix> C-f，允许你按名称切换到另一个会话
• <prefix> Tab，进入最后一个活跃窗口
• <prefix> -，将当前窗格垂直分割
• <prefix> _，将当前窗格水平分割
• <prefix> h, <prefix> j, <prefix> k, <prefix> l，像 Vim 那样导航面板

“以上是 oh my tmux 提供的快捷方式”，其他快捷参考 tmux 官网。

这个视频挺不错👇

nvim 配置

略

Ref

• razeencheng/.tmux: Oh My Tmux! 我的tmux配置，以及相关设置。
• 我在 MacOS 上的完美 ghostty + tmux + nvim 配置 : r/Ghostty
• (5 封私信) macOS Tmux安装及配置（复制粘贴，保存工作区） - 知乎
• tmux安装及使用（macos） - pd_liu - 博客园
• .tmux/README.md at master · gpakosz/.tmux
• 【iTerm2 实用技巧】解决两大顽疾：历史记录看不全 & 鼠标滚轮失灵作为 Mac 上的终端利器，iTerm2 的强大 - 掘金
• Installing · tmux/tmux Wiki
• Tmux 使用教程 - 阮一峰的网络日志

AI agent 也需要一张地图。

五月的工具列表里，有几个名字值得停一下。一个 hex 编辑器带了颜色，一个数据目录开始接 MCP，还有一个 Elixir 的 LSP 悄悄更名上线。不是什么大事，但每一件都指向同一个方向：开发者的工作台正在变得更可感知、更可查询。

本周一句话总结

工具越来越懂得如何把自己的内部状态暴露出来——不管是字节、元数据，还是代码语义。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

hexapoda：终端 hex 编辑，终于不再灰蒙蒙

用过 xxd 的人大概都知道那种感觉——屏幕上全是十六进制字符，没有颜色，没有选区概念，想改一个字节要先查怎么跟 vim 配合。

hexapoda 换了一套思路。它跟 Helix 学了"选择优先"的 modal 模式：先选中一段字节区间，再决定对它做什么。ijkl 移动（或者 hjkl，可以配置），1/2/3 拆分字节块，m 标记偏移量，J 跳转。操作逻辑和普通文本编辑器接近了很多。

最重要的是：它有颜色。不同类型的字节用不同颜色区分，阅读二进制文件的心智成本一下子低了一大截。

对于偶尔需要检查固件、协议包或者序列化格式的开发者，这个工具值得装着备用。

brew install hexapoda

marmot：让 AI 知道数据在哪

有一类问题，AI 助手回答起来特别吃力：「这个字段的 owner 是谁？」「负责用户订单的表叫什么？」不是因为 AI 不聪明，是因为它根本不知道你们公司的数据长什么样。

marmot 要解决的就是这件事。它是一个轻量级开源数据目录，把你的数据库表、消息队列、API、看板统一索引起来，然后内置一个 MCP server——Claude、Cursor 这类工具可以直接向它查询，拿到的是来自数据目录的权威元数据，不是 AI 自己猜的。

和 DataHub、Amundsen 这类企业级数据目录比，marmot 的门槛低得多：单二进制文件，Docker 五分钟跑起来，支持 500k+ 资产，平均响应不到 50ms。MIT 协议，数据也不出自己的环境。

这不是一个"等团队大了再用"的工具。三个人的小团队，如果 AI agent 开始进入你的开发流程，数据目录这件事现在就值得想一想。

brew install marmot

dexter-lsp：Elixir 的大项目问题

Elixir 的语言服务器（ElixirLS）在大型代码库里一直有卡顿问题——项目一大，补全变慢，索引常常超时。dexter-lsp 是 remote.com 工程团队针对这个问题重新做的 LSP 实现，专门为大型单仓库优化。

它不是要替代 ElixirLS，而是在"大到 ElixirLS 已经不够用"这个场景下的一个选项。如果你的 Elixir 项目超过了某个规模，值得试试看。

brew install dexter-lsp

趋势观察：工具在学会"开口说话"

这周的几个工具有个共同的隐线：它们都在替某种"不透明"省成本。

hexapoda 让二进制文件变得可读；marmot 让数据资产变得可查询；dexter-lsp 让大型代码库的语义变得可感知；openchamber 让 AI agent 的行为有了可视化界面。

这不是巧合。当 AI 工具越来越深入开发流程，「让工具的内部状态对外可见」这件事就变得越来越重要。不是为了展示，是为了被查询、被理解、被协作。

一点个人感受

marmot 是这周让我想得最久的一个。不是因为它做了什么复杂的事，恰恰相反——它做的事情很简单：把数据在哪这件事说清楚。但这件事在 AI agent 开始进入工作流之后，突然变得不那么简单了。

hexapoda 也让我想起，好的 CLI 工具未必要发明新概念，有时候只是把一件早就该做好的事认真做一遍——加个颜色、借用一套成熟的操作模型——就能好用很多。

committed 我没有专门写，但放在那里也挺应景。在 AI 辅助提交越来越普及的时代，一个检查 commit message 规范的工具，某种程度上是在帮你确认：这条记录是你写的，还是机器写的，有没有差别。

结语

工具总是先于方法论出现。marmot 出现在 MCP 变得普及之前，hexapoda 出现在终端开发体验被重新重视的当下。

不一定每个都要装，但值得知道它们在解决什么。

工具在变，但问题意识不必跟着变。

这一周的 brew update，像是给 AI Agent 做了一次集体亮相。

不是某个 IDE 插件、某个 chatbot 包装，
而是连"自我成长"、"使用监控"、"代码评审"都各自有了独立工具。

Agent 不再是某个产品里的一个功能，
它正在变成一个生态。

本周一句话总结

当一个领域同时出现了"做事的人"、"看着做事的人"和"统计做事人花了多少钱的人"，这个领域就不再是趋势，是产业了。

本周新增工具速览

🧪 New Formulae

🧩 New Casks

值得留意的几个方向

这一节不求全，
只挑几个"我看到时停了一下"的东西。

crit：替你看 Agent 写的那堆"看起来都对"的代码

Agent 写代码的速度已经超过了人类阅读代码的速度。这不是夸张。当 Cursor 或者 Claude Code 一次给你 300 行 diff，你下意识做的事是滚动到底，看一眼测试通过没有，然后点 accept。

crit 想做的事很朴素——让 review 这一步重新变成"事"，而不是"形式"。它把 agent 生成的 plan 和 code 平铺在一个本地界面里，你可以画出某几行，留一条评论，然后点 finish review，agent 自动按你的评论改。

它没有解决"agent 怎么写得更好"，
它解决的是"我怎么不再假装我看过了"。

本地优先、一键分享、支持 190 种语言高亮、Vim 键位——这些都只是配料。真正的判断是：当 agent 越来越快，慢这一步反而成了奢侈品。

hermes-agent：把"经验"做成 Agent 的可持续资产

Nous Research 出的，定位有点克制——它不是 copilot，不是聊天机器人壳，而是"在你服务器上跑的自治 agent"。

但真正的彩蛋藏在描述里那一句：self-improving。它会从你的项目里持续学习，把解决过的问题留存为"技能"，下一次遇到同类问题直接调用。

这个想法不新，新的是它落地的方式：跨 Telegram、Discord、Slack、WhatsApp、邮件、CLI 操作；五种沙箱后端（local / Docker / SSH / Singularity / Modal）；并行子 agent 各跑各的对话和终端；自然语言 cron。它在赌的是——agent 真正的护城河不是模型，而是记住自己解决过什么。

它跟 Claude Code 的 skill 机制几乎是同一个方向。只是 hermes 更激进：技能不是人写好的，是它自己长出来的。

factory：当 IDE 厂商和 Slack 同时变成 Agent 的入口

Factory.ai 这周有了 Cask。1.5B 估值、150M C 轮、agent 能直接进 VS Code / JetBrains / Vim / 浏览器 / CLI / Slack / Teams 甚至 issue tracker。

它的口号是 "agents that work everywhere you do"，听上去像营销，但拆开看其实是个判断：Agent 不应该绑定 IDE，agent 应该绑定工作流。你在哪儿干活，它就在哪儿出现。

这跟同周出现的 jetbrains-air（JetBrains 的"agent 原生开发环境"）形成了一种微妙对照——一个想让 agent 跟着人走，另一个想给 agent 造一个自己的家。两条路都还没分出胜负，但桌面级 agent 应用这件事，已经从一两个先锋变成了一片小浪潮。

defuddle：替 Readability 写一个温柔点的版本

Obsidian Web Clipper 的副产品，结果反过来比主产品更值得记一笔。

它做的事就一件：从乱七八糟的网页里把正文抠出来，输出干净的 HTML 或 Markdown，顺手把元数据（标题、作者、发布时间、favicon、schema.org）也提取了。

跟 Mozilla Readability 比，它更"宽容"——不确定的元素倾向保留而不是删除，因为很多时候 Readability 删得太狠，把脚注和图注也一起带走了。它还会用移动端样式来识别"装饰性"元素，这个思路挺机灵的。

为什么值得停一下：在"AI 把网页喂给模型"成为日常的今天，预处理这一步的质量直接决定了下游的智商。defuddle 做的是那种默默改善整个生态的事。

趋势观察：AI Agent 正在长出"配套产业"

把这周的新增放在一起看，AI agent 这个领域出现了一种新的拓扑：

• 做事的层：hermes-agent、factory、manus、jetbrains-air
• 看着做事的层：crit（review agent 写的代码）
• 数着钱的层：openusage（统计 Cursor / Claude Code / Codex / Copilot 的用量与花销）
• 喂数据的层：defuddle（清洗网页给模型）
• 驱动模型的层：open-webui（本地模型的桌面前端）

一个领域开始出现"周边工具"，意味着它过了草莽期。当有人开始专门做"用量监控"、"代码审计"、"数据清洗"的时候，agent 就不再是某个 IDE 里的一个 panel，它开始有自己的供应链。

也就是说——Agent 终于不是单飞了。

一点个人感受

老实说，这周新增的科研工具不少（alevin-fry、cutadapt、hyphy、paml、iqtree3 一整套生物信息学工具链），但我没办法假装它们跟我有关系。这是 Homebrew 有意思的地方——它从来不只是"开发者商店"，它还是某些科研社区的发行渠道。

让我留意的是 zapp。ZSA 给自己的键盘做了个 brew install 的刷固件 CLI。这事很小，但很温柔——硬件厂商认真对待终端用户，是这个时代越来越稀缺的事。

至于 AI agent 那一堆，老实说，我未必会都装。openusage 我大概率装，因为我已经被某个月的 token 账单吓过一次；crit 我会观望，看它跟现有 review 习惯能不能对上；hermes-agent 现在还有点重，但方向我赞同——agent 的未来不在模型里，在它的"经验积累"里。

结语

一周之内，Homebrew 同时收下了"做事的 agent"、"审 agent 的工具"、"统计 agent 花销的应用"。这种多层次出现，本身就是一个信号。

工具不再是孤立的功能点，而是开始彼此咬合。当 agent 有了 reviewer、有了用量监控、有了数据清洗器，它就从"实验"变成了"生产"。

一个赛道开始有"配角"，才说明它真的成了。

关于 SideStore & LiveContainer，网上有太多使用安装教程，但信息比较零碎和缺乏必要说明。

大部分情况下，SideStore & LiveContainer 官方文档和Issues足矣解决99.99%的问题。

老鸟可以略过，新人可以继续阅读。

下面我简单说一下，我对这个项目的理解，以及如何正确使用。

SideStores 是什么？

“SideStore is a fork of AltStore that doesn't require an AltServer.”

“SideStore is an untethered, community driven alternative app store for non-jailbroken iOS devices”

上面两段话意思，SideStore 是一个替代应用商店的应用，不需要用户越狱即可安装应用。

“🍎越狱（iOS Jailbreaking）是指通过技术手段，利用iOS系统的漏洞，获取iPhone、iPad等苹果设备操作系统的最高权限（Root权限），从而打破苹果公司所设定的封闭式生态环境限制。”

越狱手机后的手机，可以安装任何应用，没有任何限制🚫。但是，并不是所有人都希望越狱，但又想安装其他非🍎官方上架的应用，怎么办？

SideStore 就可以做到，完美解决非越狱用户即可安装应用的需求。

在 SideStore 出现之前，AltStore 一直是这项需求这个领域的首选方案。但是 AltStore 有一个非常麻烦的问题：每隔7天需要刷新一次，否则通过 AltStore 安装的应用就会不可使用。

SideStore 并没有解决这个问题：需要每隔7天刷新一次。

但是，SideStore 可以较方便的在Wi-Fi环境下刷新应用，而 AltStore 只能在电脑上刷新。

“这里强调一点，AltStore 只能在电脑上刷新，是因为依赖 AltServer，只要设备和电脑在同一网络，也可以通过Wi-Fi自动刷新。”

在使用 SideStore 之前，必须了解官方提供了：

• SideStore.ipa
• iloader
• LocalDevVPN

具体如何安装，本文不赘述，建议查看官方文档。

安装 SideStore.ipa，还可以通过以下几种方式：

• AltStore
• Sideloadly
• Impactor

当然，仍然希望大家遵循 SideStore 官方文档。

“为什么要说这件事情？因为 SideStore 迭代很快，之前确实推荐使用 AltStore / Sideloadly 安装 SideStore，后面有了 iloader，才开始成为主要安装方式。”

也许若干时间，还有其他变化。😊

说完 SideStore，现在聊聊 LiveContainer。

SideStore 最多只能装3个App，而 LiveContainer，能突破这个限制，变成近乎无限。

这就是 LiveContainer 最大的魅力，其他玩法(多个 LiveContainer)，可以查看官方文档或社区。

最后，分享一些 SideStore & LiveContainer 的使用心得：

1. SideStore 安装主力常用App；
2. LiveContainer 安装放“可折腾”的App;
3. 依赖通知和后端推送的App，不可使用 LiveContainer；
4. 游戏模拟器类，需要 JIT，建议使用 LiveContainer；
5. 用小号 Apple ID，不要用主号，避免被封号；
6. 使用捷径和定时任务更新SideStore，保持每天至少打开一次；
7. 使用Clash Mi，即便没有Wi-Fi也可以刷新，【参考】；

如果不小心掉签了，别急，可以在电脑上通过iloader恢复。

Ref

• LiveContainer 简介
• claration/Impactor: Feature rich iOS/tvOS sideloading application written in Rust.
• - [BUG] IOS development cert or pending cert request bug (7460) · Issue #795
• SideStore/SideStore: SideStore is a fork of AltStore that doesn't require an AltServer.
• LiveContainer + SideStore (LC+SS): Complete Guide
• LiveContainer现在有一个内置sidestore的版本 : r/sideloaded
• 我正在尝试登录 sidestore，但它说“您已经拥有当前的 iOS 开发证书或待处理的证书请求 (7460)”。 : r/sideloaded
• JIT是干嘛用的？？ : r/AltStore
• 启用JIT | SideStore Docs
• StephenDev0/StikDebug: An on-device debugger/JIT enabler for iOS versions 17.4+, powered by idevice.

添加DSOrganize后，重新加载DSTWO时，
发现会多出一个“._DSOrganize”的黄色问号图标，感觉非常丑。

由于刚接触DSTWO，对它不熟悉，
也不知道是什么原因产生的,
所以一直不敢动。

今天在网上找到一个中文版的bak（备份文档），非常开心。

然后立马解决这个问题。

问题产生的根源是，Mac 系统会在 FAT32 文件系统上创建的元数据文件。类似“._ ”。
使用“dot_clean”命令可以解决。

可能会遇到报错，不用理会。

“2>/dev/null” 可以屏蔽错误信息。

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

保险起见，可以再加上，禁止生成 .DS_Store（U盘）

mac系统下将U盘格式化FAT32：

diskutil eraseDisk FAT32 NDS MBRFormat /dev/disk16

Ref

• Duplicate Grey Icons in DS pico menu : r/flashcarts
• DSTWO Displaying 'Broken' ROM Duplicates? | GBAtemp.net - The Independent Video Game Community
• Mac Users - ? icon plugin fix | GBAtemp.net - The Independent Video Game Community

Supercard DSTwo 是烧录卡，支持NDS/NDSi/3DS。

• 【DSTWO 系列】街机游戏配置
• 【DSTWO 系列】修复图标重复的问题

Skin

• DerrickGold/BAGPlug-SCDS2: An interface for the Supercard DS2 that launches media, homebrew, and retro games.
• DSTWO User Manual_SuperCard Official Site
• Derrick Gold
• SuperCard DSTWO ds2skin packs - WikiTemp, the GBAtemp wiki
• DS2 Skin Installer | GBAtemp.net - The Independent Video Game Community
• DSTWO Skins
• Updated DSTwo.nds for BAGPlug & iMenu & future Menus
• DS2Tools - GameBrew

官方资源💾

http://down.supercard.sc/download/dstwo/

Ref

• mtheall/ftpd: FTP Server for 3DS/Switch
• 我创建了一个简单的备份与同步工具 : r/3dshacks
• Lokthran/3DS-Save-Sync: A Python-based tool to backup and transfer 3DS, NDS, GBA and custom save files via FTP.
• DSOrganize - GameBrew
• DragonMinded.com :: DSOrganize FAQ
• DSTwo DSFTP Plugin | GBAtemp.net - The Independent Video Game Community
• NDS Backup Tool FTPd | GBAtemp.net - The Independent Video Game Community
• Supercard DSTwo 和 DSTwo Plus 有什麼主要區別？ : r/flashcarts
• DSTWO常见问题解答_SuperCard官方中文网
• DSTWO常见问题解答_SuperCard官方中文网
• Nintendo DSi掌机硬件参数和配置 - 掌机圈
• Any major differences between Supercard DSTwo and DSTwo Plus? : r/flashcarts
• Best SuperCard DSTWO setup? : r/flashcarts
• Dstwo 2 in 1 vs 4 in 1 differences? : r/flashcarts
• Genuine Super Card DSTWO - change the main menu wallpaper : r/flashcarts
• Customize DSTWO EOS? : r/flashcarts
• FW, Moonshell and DSOrganize easy install | GBAtemp.net - The Independent Video Game Community
• DStwo【DS平台的最强烧录卡】整合美化包（完美美化&整合插件&值得珍藏）_游戏热门视频

火焰之纹章攻略

下面2个链接的游戏比较全。

Ref

• WELCOME TO CHINAFE
• 《火焰纹章 圣战之系谱》全角色加入条件及相关攻略

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

那些曾经散落在 /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 的动向，看看四月中还会出现哪些"省心智成本"的工具。

Obsidian 配合 AI 非常锋利 😉

rkt 可以优化token

• 感觉 ai agent 时代， windows 越来越不行了 - V2EX
• rtk-ai/rtk: CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies