升级打怪

 
一些能提高生产力的 Skills

Ref

Agent Skill
 
Apifox MCP 使用记录

昨天在使用AI编程中遇到一个非常恼火的事情：

  1. 首先让AI去更新接口，review时发现接口更新不对；
  2. 反复与AI沟通，期望AI能正确识别接口，并更新代码；
  3. 沟通无效，AI无法理解；
2026-03-04_10-58 2026-03-04_10-59 2026-03-04_11-00 2026-03-04_11-01

经历上面的阶段，个人感觉是MCP工具问题。

或许优化 Prompt 能解决问题，但是当时我已经想不出更好的语句😓

后面联系到官方技术群，在群里咨询了自己遇到的问题。

这个问题似乎其他人也有遇到，有解决该问题的办法。

2026-03-04_10-54

配置的过程遇到报错：

[apifox-filter-mcp] [ERROR] Cannot determine a valid project directory (got: "/", resolved: "/"). Please set the CACHE_DIR environment variable to specify the cache location. MCP error -32000: Connection closed

这个报错是因为 CACHE_DIR 配置错误。

完整配置：

    "apifox-filter": {
      "timeout": 60,
      "command": "npx",
      "args": [
        "-y",
        "apifox-filter-mcp-server@latest",
        "--project-id=your-project-id"
      ],
      "env": {
        "APIFOX_ACCESS_TOKEN": "your-token",
        "LOG_LEVEL": "error",
        "CACHE_DIR": "your-path"
      },
      "type": "stdio"
    },

Ref

Apifox MCP
 
Claude Code 配置说明

Ref

Claude
 
在 Cline 中使用 Ralph Wiggum 的完整指南

🎯 什么是 Ralph Wiggum？

Ralph Wiggum 是一个自动化 AI 编码工具，通过 bash 循环脚本让 Cline 自主完成多个任务。每次迭代都启动一个新的 Cline 进程，确保上下文始终清晰。

📋 核心理念

每次循环 = 全新的 Cline 会话

  • ✅ 避免上下文窗口溢出
  • ✅ 防止长时间会话后的性能下降
  • ✅ 每个任务都有干净的起点
  • ✅ 通过磁盘文件（specs/、历史记录）共享状态

🚀 如何在 Cline 中使用

步骤 1：初始化 Ralph Wiggum

在 Cline 中输入：

使用 https://github.com/fstandhartinger/ralph-wiggum 为我的项目设置 Ralph Wiggum

Cline 会引导你完成：

  1. 创建必要的目录结构（specs/、scripts/、logs/）
  2. 下载 ralph-loop.sh 脚本
  3. 项目访谈 - 了解你的项目愿景和目标
  4. 创建项目宪法 - 为所有会话提供指导原则

步骤 2：编写规范文件

在 specs/ 目录创建功能规范文件，关键是清晰的验收标准：

示例：specs/user-login.md

# Feature: 用户登录功能

## 需求
- 手机号+验证码登录
- 登录状态持久化
- 自动跳转到首页

## 验收标准
- [ ] 用户可以输入手机号
- [ ] 点击发送验证码后收到验证码
- [ ] 输入正确验证码后登录成功
- [ ] 刷新页面后登录状态保持
- [ ] 登录后自动跳转到首页
- [ ] 所有相关测试通过

**完成时输出：** `<promise>DONE</promise>`

💡 关键要点：

  • ✅ 验收标准要具体、可测试
  • ✅ 避免模糊的描述如"功能正常"
  • ✅ 每个标准应该能明确验证
  • ✅ 必须包含 <promise>DONE</promise> 输出要求

步骤 3：运行 Ralph 循环

在终端中运行（不在 Cline 中运行）：

# 开始自动化循环
./scripts/ralph-loop.sh

# 限制最大迭代次数
./scripts/ralph-loop.sh 10

发生了什么？

循环 1: Cline 启动 → 读取 spec → 实现 → 测试 → 提交 → 输出 DONE → Cline 关闭
循环 2: 新 Cline 启动 → 读取下一个 spec → 实现 → 测试 → 提交 → 输出 DONE → Cline 关闭
循环 3: 新 Cline 启动 → ...

每次循环都是全新的 Cline 实例，上下文不会累积！

步骤 4：查看日志

所有输出都保存在 logs/ 目录：

# 查看会话日志
cat logs/ralph_*_session_*.log

# 查看特定迭代日志
cat logs/ralph_*_iter_1_*.log

🎮 两种工作模式

1. Build 模式（默认）

./scripts/ralph-loop.sh

Cline 会：

  • 选择一个未完成的 spec
  • 实现功能
  • 运行测试
  • 提交代码
  • 输出 <promise>DONE</promise>

2. Plan 模式（可选）

./scripts/ralph-loop.sh plan

Cline 会：

  • 创建详细的实施计划
  • 分解成小任务
  • 保存到 IMPLEMENTATION_PLAN.md

📁 项目结构

your-project/
├── specs/                    # 功能规范
│   ├── user-login.md
│   ├── dashboard.md
│   └── ...
├── scripts/                  # Ralph 脚本
│   ├── ralph-loop.sh
│   └── ...
├── logs/                     # 日志文件
│   ├── ralph_*_session_*.log
│   └── ralph_*_iter_*.log
├── ralph_history.txt         # 历史记录（突破/阻塞/学习）
├── IMPLEMENTATION_PLAN.md    # 实施计划（可选）
└── CONSTITUTION.md           # 项目宪法（可选）

⚠️ 重要注意事项

1. 启用自动执行模式

为了 Ralph 自主工作，需要在启动 Cline 时使用危险模式：

# VSCode 中的 Cline 设置
# 或者在命令行中：
cline --dangerously-skip-permissions

⚠️ 仅在沙盒/测试环境中使用！

2. 完成信号很关键

Cline 必须输出 <promise>DONE</promise> 才算完成。

  • bash 脚本会检查这个信号
  • 如果没有输出，会重试当前 spec
  • 确保在 spec 中明确说明要输出这个信号

3. 测试作为护栏

  • 每个 spec 应包含"测试通过"作为验收标准
  • Cline 在所有测试通过前不应输出完成信号
  • 这确保了代码质量

💡 最佳实践

✅ 好的 Spec 写法

## 验收标准
- [ ] 用户点击登录按钮后显示加载状态
- [ ] API 返回成功后跳转到首页
- [ ] API 返回失败后显示错误提示
- [ ] 登录组件的单元测试全部通过

❌ 差的 Spec 写法

## 验收标准
- [ ] 登录功能正常工作
- [ ] 没有 bug

编写技巧

  1. 一个 spec 一个功能 - 不要混合多个不相关的功能
  2. 验收标准可量化 - 能够明确验证是否完成
  3. 包含测试要求 - 确保代码质量
  4. 说明完成信号 - 提醒 Cline 输出 <promise>DONE</promise>

🔄 典型工作流

第1天：规划阶段
├─ 在 Cline 中：初始化 Ralph，创建项目结构
├─ 编写 5-10 个功能 spec
└─ 运行 ./scripts/ralph-loop.sh plan（可选）

第2天：开发阶段
├─ 运行 ./scripts/ralph-loop.sh
├─ Ralph 自动完成所有 spec
└─ 查看日志，验证结果

第3天：调整优化
├─ 根据结果调整未完成的 spec
├─ 继续运行 ralph-loop.sh
└─ 直到所有功能完成

🔗 相关资源

🎯 总结

在 Cline 中使用 Ralph Wiggum 的关键：

  1. ✅ 让 Cline 帮你设置项目结构
  2. ✅ 编写清晰、可测试的 spec
  3. ✅ 在终端运行 ralph-loop.sh（不在 Cline 中）
  4. ✅ 每个循环都是全新的 Cline 会话
  5. ✅ 通过 <promise>DONE</promise> 信号标记完成

让 Ralph 做 Ralph 的事 - 信任 AI 的自主能力，专注于编写好的规范！

Agent Skill Cline
 
🍺 Homebrew 更新周报 #20260302 | 当工具开始变成看不见的基础设施

真正重要的工具，往往不在桌面上，而在底层。

这一期没有让人眼前一亮的“新玩具”，
却多了不少你可能永远不会直接使用，
但每天都会间接受益的底层工具。

本周一句话总结

这一期新增工具的气质非常统一：

越来越多工具不再面向用户，而是面向系统本身。

它们不解决“操作问题”，
而是在悄悄重塑：

  • 开发环境结构
  • 容器运行方式
  • AI 能力组织形式
  • 系统安全模型

换句话说：

这一期更新的是“地基”，不是“房子”。

本周新增工具速览

🧪 New Formulae

名称 中文说明
betterleaks 高性能敏感信息扫描工具
cni-plugins 容器网络接口插件集合
landrun 基于 Landlock 的 Linux 进程沙箱
mp4ff MP4 文件解析与处理工具库
protobuf@33 Google Protocol Buffers 数据交换工具
rootlesskit 无需 root 权限的容器运行工具
runc OCI 标准容器运行时工具
skills 面向 AI Agent 的技能生态框架
termframe 将终端输出生成 SVG 截图的工具

🧩 New Casks

名称 中文说明
bettercapture 屏幕录制与捕获工具
cmux 面向 AI 编码场景的终端应用
connectiq-sdk-manager Garmin Connect IQ SDK 管理工具
fabric-app 个人知识管理与笔记应用
font-datatype Datatype 字体
font-gmarket-sans Gmarket Sans 字体
font-iosevka-charon Iosevka Charon 字体
font-iosevka-charon-mono Iosevka Charon Mono 字体
itsytv Apple TV 菜单栏控制工具
kotlin-lsp Kotlin 官方语言服务器

值得留意的几个关键方向

这一期真正值得关注的，不是单个工具，
而是几个非常清晰的技术趋势信号。

🧠 一、容器底层正在进入“无 Root 时代”

这一期最重磅的其实是一整条技术链：

  • rootlesskit
  • runc
  • cni-plugins

它们共同指向同一个趋势：

容器正在从“工具”变成“操作系统级基础设施”。

rootlesskit —— 容器安全的未来方向

传统容器必须依赖 root 权限：

这意味着一旦容器逃逸，
风险几乎等同于系统被攻破。

rootlesskit 的核心价值在于：

让容器完全以普通用户权限运行。

它通过用户态能力模拟：

  • user namespace
  • network proxy
  • mount proxy

把 root 能力转译成安全可控的机制。

为什么重要

未来几年会成为默认趋势：

  • 企业安全策略会强制 rootless
  • CI/CD 环境必须无 root
  • 云开发环境全面去特权化

它是：

下一代容器安全架构的基石。

runc —— 容器世界真正的执行核心

2026-03-02_14-31

很多人以为 Docker 在运行容器，
实际上真正执行容器的是 runc。

技术链路是：

Docker → containerd → runc → Linux kernel

Homebrew 收录 runc 的意义在于：

本地开发环境正在变得“原生化”。

未来趋势：

  • 不再依赖 Docker Desktop
  • 运行时可自由替换
  • 更接近 Linux 原生能力

这就是所谓的：

后 Docker 时代。

cni-plugins —— Kubernetes 网络的根基

2026-03-02_14-32

容器最复杂的部分并不是运行，
而是网络。

CNI 插件负责：

  • IP 分配
  • NAT
  • Overlay 网络
  • Service 通信

它们的出现意味着：

本地开发环境正在趋近生产环境。

未来开发机将越来越像：

一个可随时重建的小型数据中心。

🤖 二、AI Agent 正在进入“生态时代”

skills —— AI 能力开始模块化

这是本期最具未来信号的工具。

它代表 AI 正从：

“模型能力”

转向：

能力生态系统。

技术本质

它类似于：

时代 代表生态
Web 时代 npm
移动时代 App Store
AI 时代 Agent Skills

未来 AI 竞争的关键将不是：

模型参数规模，

而是：

能力模块的可复用性。

重要趋势

AI 正在发生结构性转变：

从：单次调用 → 持续能力系统

从：回答问题 → 执行任务

从：工具 → 协作者

🔐 三、安全模型正在从“容器隔离”转向“微沙箱”

landrun —— Linux 安全的新方向

landrun

这是一个非常硬核但意义深远的工具。

基于 Landlock LSM 的特点：

  • 无需 root 即可创建沙箱
  • 内核级权限控制
  • 比容器更轻量

它代表的趋势是：

未来安全将依赖微隔离，而不是重量级容器。

典型应用场景：

  • 执行不可信代码
  • 安全 CI 运行环境
  • CLI 沙箱执行

这是“零信任计算”的重要拼图。

🎨 四、终端正在成为内容生产媒介

termframe —— CLI 进入表达时代

termframe

这个工具虽然很小，但信号很明显。

它的作用：

将终端输出转成 SVG 截图。

背后的变化

终端不再只是执行环境，
而开始成为：

  • 技术内容资产
  • 文档生成来源
  • 可视化表达媒介

随着 CLI 工作越来越多：

“如何展示命令行成果”成为新需求。

🧭 本期最重要的三大技术信号

如果必须用一句话总结这一期：

这是一次基础设施层的集体升级。

🚩 信号 1：容器彻底走向无特权化

关键词：

  • rootless
  • 最小权限
  • 可组合运行时

未来容器将更安全、更透明。

🚩 信号 2：AI 进入能力生态竞争阶段

重点不再是模型，而是：

  • 技能模块
  • 能力复用
  • 任务编排

🚩 信号 3：开发环境正在系统化

本地开发环境越来越像：

  • 可重建系统
  • 微型生产环境
  • 自包含基础设施

一点个人感受

这一期让我印象最深的不是某个具体工具，
而是一种明显的“隐形化趋势”。

越来越多新增项目：

  • 不直接面向用户
  • 不提供界面
  • 不解决表层问题

却在悄悄改变：

系统运行方式、开发环境结构和安全模型。

它们不会立刻提升效率，
却会在长期使用中：

让系统变得更可靠、更安全、更可重建。

结语

Homebrew 的更新列表，
有时像一份技术世界的地下水位报告。

你未必能看见它，
却能感觉到整个环境正在慢慢改变。

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

Homebrew
 
OpenClaw 安装配置

教程

OpenClaw 精选案例 + 最佳部署架构

OpenClaw 安装配置，Hyper-V 安装 Ubuntu Desktop，API Key认证 + OAuth认证 + 第三方AI接口，Telegram 电报连接

OpenClaw
 
2012年MBP，再战2026

机型是 2012 款 MBP,

CPU:i7 ， 内存：16G, 硬盘：1TB，

当前系统 13.7.6。

2602725893

Ventura 系统使用有一段时间了。

升级系统，主要原因是 brew 不支持之前的系统(macOS Catalina)，

导致很多软件无法更新和使用。

自从苹果推出M芯片之后，系统发展速度越来越快。

“Big Sur 开始不支持 intel 的 MBP”

我直接从 Catalina 升级到 Ventura。

为什么选择 Ventura？

因为 brew 对这个版本的支持还有一段时间，

Big Sur / Monterey 相对而言有点落后，有些 App 不支持。

并且 Ventura 运行起来还算流畅。

早在2014年的时候，MBP运行起来就有点吃力😰

因为没有配置SSD， 电脑运行速度非常慢🐌

根据网上教程，自己动手DIY，改造了硬盘：移除光驱，在原位置上添加了三星的 512G SSD，再通过苹果的 fusion drive 技术创建了 1T 融合硬盘。

另外，加购了 16G 内存。

155173831 2512918161

使用 Disk Speed Test 测试，

读写速度从不到50MB/s，提升到平均500MB/s， 对于这点，相当满意👍。

2105921758 274177333

随着AI的高速发展，Ventura 也有一些力不从心了。

后面应该要换台MBP，但是如何选择又是一道考验。

Ref

MBP
 
一些有意思的项目

最近发现了这些好玩的项目，有些开始在用了，有些还在学习如何使用。

大部分是工具类的，可以提高生产效率。

另外也可以接收一些好的思维方式。

像 atuin 项目，可以替代 autojump。
mise 可以替代一堆的环境管理工具 nvm / pyenv 等等。

Ref

tools
 
跟随杰出的人，为杰出的人工作

昨天上午偶然刷到一篇关于AI对编程领域影响的文章，《OpenAI前华人工程师：个人贡献者正在永久消失！未来人类介入代码，反而被视为质量风险》。

为啥会被吸引？其实我也很好奇，当下开源社区会如何使用AI技术。譬如：

  1. 使用AI写开源项目，配合人工审查，更极端点，全程AI自动工程化，项目负责人只关心需求反馈和产品设计；
  2. 还会有人愿意花时间研究“古法编程”吗？时间如何分配？多少时间在使用AI？

事实上，我并不当心AI写出的代码质量问题，相信随着时间的发展，工程化会越来越完善，AI编写的代码质量也会越来越高。

当然，还有一个非常警惕的理由：是否因为AI会写代码，原本优秀的工程师就没价值了？

资本主义的社会，没有哪个老板会不考虑成本和效率，如果AI看起来很完美，那么为什么还需要花高价聘用工程师？

上面篇文章中的主角叫“Philip Su”，是一个挺成功的工程师。拥有着优秀的履历，以及成功的转型成绩，即 Superphonic 创始人。

有一说一，我对 Superphonic 不了解。但我对 Philip Su 本人感兴趣，所以上网搜索了一下，发现了关于他多年前的一篇文章《微软老将Philip Su的离职信：回首12年职场生涯的心得和随笔》，不得不说，我很赞同里面的一些观点。

“让行动代表你。但是注意自己说的话，因为言语是有力量的。”

“如果你不断做公司最需要的事情，你是一定会被重用的。有人说，不是的，人际关系和在人前表现自己更重要。我不明白，如果你持续做对公司意义很重大的事情，怎么可能不被别人注意到。我很讨厌程序员问我怎么才能在人前表现自己。他们也很讨厌我的答案“把事情做得更漂亮”，觉得我是在讽刺他们。”

“愤世嫉俗的人是一事无成的。不要和第一反应总是质疑的人交流，你会吃不消的。”

“跟随杰出的人，为杰出的人工作。”

“最重要的是：做人要诚信。你必须信任和你一起工作的人。”

等等，文章里面还有很多。

回到本文标题，个人认为：

“优秀的人，在哪都会被发现。与其担心AI，不如享受当下，并接受改变。找到志同道合者，共同奋进。跟随自己的本心，做自己喜欢的事情。”

Ref

work
 
🍺 Homebrew 更新周报 #20260224 | 当 Agent 开始拥有自己的基础设施

真正的变化，往往发生在“看不见的底层”。

很多工具的出现，并不会立刻改变你的工作方式。
但它们会悄悄改变：
未来工具应该长成什么样。

这一期新增的项目，大多属于这一类。

本周一句话总结

本周最明显的趋势不是“新能力”，
而是：围绕 AI Agent 的基础设施开始成体系出现。

本周新增工具速览

🧪 New Formulae

名称 中文说明
aoe 面向 AI 编码代理的终端会话管理器
apache-serf 高性能异步 HTTP 客户端库
asc App Store Connect 快速命令行工具
async-profiler Java CPU 与内存采样分析器
bagel 安全态势审计与攻击面评估 CLI
bazel@8 Google 官方构建系统
bitwuzla SMT 约束求解器
claude-agent-acp 在 ACP 客户端中使用 Claude Code
clock-rs 现代终端数字时钟
datadog-static-analyzer 代码安全与质量静态分析工具
difi 像素级终端差异对比工具
fracturedjson 高可读 JSON 格式化器
git-flow-next Git-flow 现代实现
[email protected] Go 语言最新版本
grafanactl Grafana 管理 CLI
happy-coder 移动端操控 AI 编码代理的 CLI
ironclaw 带 WASM 沙箱的安全 AI 助手
kaf 现代 Kafka CLI
letta-code 记忆优先的编码代理
libnpupnp C++ UPnP 库
libupnpp libnpupnp C++ 封装
likec4 从代码实时生成架构图的建模工具
[email protected] Linux 内核头文件
livereload Python 本地 Web 热重载服务器
llmfit 检测本机可运行模型的工具
ls-hpack HTTP/2 压缩库
micasa 家庭项目管理终端工具
mipsel-linux-gnu-binutils MIPS 交叉编译工具链
nomad-pack Nomad 模板与打包工具
nullclaw Zig 编写的 AI 助手基础设施
nuls 彩色表格输出的 ls 替代工具
pcapmirror 远程网络流量抓取工具
picoclaw 高效个人 AI 助手框架
picoruby 面向微控制器的极简 Ruby
pyperformance Python 基准测试套件
rtk 降低 LLM Token 消耗的代理工具
run-kit 多语言统一运行与 REPL 工具
rustledger Rust 实现的复式记账工具
rustypaste 极简 Paste 服务
sss-cli Shamir 秘密分片工具
structurizr 架构即代码建模工具
tree-sitter-go Go 语法解析器
tree-sitter-python Python 语法解析器
tree-sitter-ruby Ruby 语法解析器
tuckr Stow 的增强替代工具
umoci OCI 容器镜像工具
whodb-cli 带 AI 的数据库管理 TUI
zeroclaw Rust AI Agent 运行时
zxing-cpp 多格式条码处理库

🧩 New Casks

名称 中文说明
brewy Homebrew 图形管理界面
calendr 菜单栏日历工具
claude-devtools Claude Code 会话分析工具
claude-island Claude CLI 动态岛通知
codexmonitor Codex 使用监控工具
desktop-composer 系统外观管理工具
donut 反指纹浏览器
donut@nightly Donut 夜间版
dot 菜单栏会议提醒日历
extradock 自定义扩展 Dock
ferdium@nightly 多平台消息聚合工具
iloader iOS 侧载辅助工具
macpulse 系统性能历史监控仪表板
mindwtr 本地优先 GTD 工具
netviews 网络诊断工具
nostalgiapp 复古游戏启动器
nugget iOS 设备定制工具
opencomic 漫画阅读器
pangolin 身份感知 VPN 代理
pika@beta 屏幕取色工具
psiphon-conduit Psiphon 网络代理
supacode AI 编码代理控制中心
thaw@beta 菜单栏窗口管理工具
thecommander 双栏文件管理器
threema-work@beta 企业加密通信应用
updatest 应用更新检测工具

值得留意的几个方向

这一期最值得看的，
不是某一个工具，
而是几个非常清晰的“演化信号”。

🥇 AoE: AI Agent 会话基础设施的诞生逻辑

AI 编程进入「多 Agent 并行时代」后，人类已经管理不了工作流了。

aoe

使用场景

  • 多 AI Agent 并行运行的开发环境
  • 需要在同一终端窗口下管理多个会话
  • 实验、调试或快速迭代 AI 任务时
  • 远程服务器或本地开发环境均可使用

背景需求

  • 随着 AI Agent 越来越多，单一命令行会话难以管理
  • 手动切换、记忆会话状态容易出错
  • 团队或个人需要可重复、可记录的会话流程

核心价值

  • 提供稳定、可复用的会话管理基础设施
  • 减少管理多个 Agent 会话的心智负担
  • 为后续自动化、监控或日志分析打下基础
  • 让开发者可以专注于 AI 任务逻辑，而非终端管理

🥈 letta-code — Memory-first 编程模式

工具类型：面向 AI Agent 的编程辅助工具（Memory-first 编程）

letta-code

使用场景

  • 编写或调试依赖上下文的 AI 代码
  • 需要 AI Agent “记忆”历史上下文、变量状态
  • 快速迭代复杂逻辑，尤其是多步骤决策任务
  • 与其他 AI Agent 或自动化工具结合使用

背景需求

  • 传统 AI 编程环境常忽略上下文连续性
  • 开发者在多轮交互或复杂任务时容易重复信息
  • “记忆优先”的工作模式可提高 AI 输出一致性和效率

核心价值

  • 将 AI Agent 的记忆管理作为核心功能
  • 减少重复输入和上下文切换成本
  • 提升长期、多轮任务的执行效率
  • 形成可复用的 AI 编程工作流模式

🥉 likec4 — 架构可视化趋势

工具类型：架构建模与可视化工具

241616232-d6994540-55d1-4167-b66b-45056754cc29

使用场景

  • 将代码结构转化为可视化架构图
  • 支持实时更新与交互式设计
  • 在设计、开发、代码审查阶段使用
  • 团队协作时快速理解系统复杂性

背景需求

  • 随着系统复杂度增加，代码架构难以直观理解
  • 文档与架构图容易过时
  • 开发者需要实时可视化工具来降低认知负荷

核心价值

  • 将架构与代码同步，保证图表真实反映系统状态
  • 提供动态、可交互的架构视角
  • 帮助团队快速理解、评审和优化系统设计
  • 降低大型系统开发中的认知成本

以上总结

AI Agent 不再是单个工具，
而是完整生态，
这个生态，需要可观测与治理。

AI Agent 基础设施：从单点工具到完整生态

这一期几乎形成了一整条链路：

  • Agent 会话管理
  • 运行时框架
  • 记忆系统
  • Token 优化
  • 沙箱安全

这些工具共同指向一个趋势：

AI Agent 正在从“插件式能力”
走向“独立运行环境”。

它们不再依附 IDE，
而开始拥有自己的操作层。

可观测性与治理：自动化世界的副作用

另一个显著变化是：

  • 使用监控工具变多
  • 安全审计工具变多
  • 行为分析工具变多

这意味着工程世界开始接受一个现实：

自动化越强，
管理成本就越重要。

架构与系统建模：复杂度的另一种应对方式

像架构建模、实时图生成、结构化分析
这一类工具越来越多。

这不是为了文档漂亮，
而是为了让复杂系统
变得可以被人理解。

一点个人感受

这一期让我最强烈的感受是：

AI 工具已经不再处于
“能不能用”的阶段。

它们正在进入一个新的问题域：

  • 如何协作
  • 如何管理
  • 如何被信任

也许真正的拐点，
并不在模型本身，
而在围绕它的工具生态。

结语

Homebrew 的新增列表，
越来越像一份技术趋势的年鉴。

它不会告诉你未来是什么，
但会悄悄标注：

下一阶段的工作方式，正在成形。

工具在进化，
但真正变化的，是我们与工具的关系。

Homebrew
 
新年开工红包
新年开工红包🧧

公司马年开工红包，第一次收到这种形式：邮票。🤭

chinese new year
 
🍺 Homebrew 更新周报 # 20260210 | 当 AI 工具开始被系统化管理

从“能用就行”，到“需要被治理”

早期的工具，只关心能不能跑。
这一期的工具，开始关心：
谁在用、怎么用、是否可控。

Homebrew 的这些新增，更像是在为下一阶段的工作流打地基。

本周一句话总结

这一期没有爆炸式的新能力，
但出现了大量：
围绕 AI、自动化与工程规范的“管理型工具”。

本周新增工具速览

🧪 New Formulae

名称 中文说明
actions-up 自动升级 GitHub Actions 并进行 SHA 固定的工具
agent-browser 面向 AI Agent 的浏览器自动化 CLI
arcadedb 多模型数据库：图 / 文档 / KV / 搜索 / 向量
cozyhr 封装 Helm 与 Flux CD 的本地开发工具
ic-wasm 面向 ICP Canister 的 Wasm 转换 CLI
icp-cli ICP Canister 的构建与部署工具
jqfmt 风格强约束的 jq 格式化工具
odiff SIMD 优先的高性能图像对比库（含 Node API）
playwright-cli Playwright 官方 CLI：录制、生成代码、截图
sheenbidi 高性能 Unicode 双向文本算法实现
skillshare 在多个 AI CLI 工具间同步“技能”的工具
static-web-apps-cli Azure Static Web Apps 的本地开发 CLI
transifex-cli Transifex 翻译平台的命令行客户端
try-rs 用于快速实验的临时终端工作区管理器
yap 基于 Speech.framework 的本地音频转写工具

🧩 New Casks

名称 中文说明
clash-mi 基于 Flutter 的 Mihomo GUI 客户端
codex-app OpenAI Codex 桌面端，管理编码 Agent
luxury-yacht Kubernetes 集群管理桌面应用
owocr 面向日文文本的 OCR 工具
plasticity 面向概念设计师的 3D 建模软件
posturr 姿势监测与提醒应用
tana 带 AI 大纲能力的知识管理工作区
thaw 菜单栏窗口管理工具
xkey 越南语输入法引擎
font-alyamama Alyamama 字体
font-betania-patmos Betania Patmos 字体
font-betania-patmos-gdl Betania Patmos（GDL 版）
font-betania-patmos-guide-line Betania Patmos（带书写引导线）
font-betania-patmos-in Betania Patmos（印度版本）
font-betania-patmos-in-gdl Betania Patmos（印度 GDL 版）
font-dejavu-sans DejaVu Sans 字体
font-idiqlat Idiqlat 字体
font-ramsina Ramsina 字体

值得留意的几个方向

不挑“最强的”，
只挑 最能反映趋势变化的几个点。

actions-up：当自动化开始反过来要求“可审计”

GitHub Actions 早已无处不在，
但它们长期处于一种
“能跑就行” 的状态。

actions-up 做的不是帮你写更多 CI，
而是帮你把依赖升级这件事
变得可追踪、可复现、可回滚。

这意味着自动化，
也开始被当作供应链的一部分来管理。

skillshare：AI 工具，不再各学各的

skillshare

随着 AI CLI 工具变多，
一个现实问题开始出现：

我教会了这个 Agent，
为什么另一个完全不懂？

skillshare 的思路很直接：
把“技能”本身变成可同步的资源，
而不是绑定在某一个工具里。

这是 AI 工具走向体系化的一个明显信号。

agent-browser / playwright-cli

当“操作浏览器”不再只属于人

Playwright 早就不只是测试工具了。
而 agent-browser 更是直接假设：
浏览器的操作者，可能是 AI。

这一组工具的共同点在于：
它们不再强调“自动化有多强”，
而是强调接口是否足够清晰、行为是否可控。

yap：输入，正在回到“本地可信”

yap

yap 选择了一个很明确的方向：
不走云端、不做平台，
而是基于系统级 Speech.framework。

这不是能力不足，
而是一种取舍：

有些输入，
不值得离开你的设备。

一点个人感受

这一期的更新，
让我强烈感觉到一个变化：

AI 与自动化，
正在从“工具层”，
进入“系统层”。

开始有人关心：

  • 版本是否可控
  • 行为是否可审计
  • 能力是否可复用

当工具开始被系统化管理，
人反而可以更轻松地使用它们。

结语

Homebrew 的更新，
已经不只是“多了什么工具”。

而是在悄悄记录：
工程世界的默认假设，正在改变。

AI 发展太快，有点焦虑。

Homebrew
 
2025：LLMs 站上主舞台

1～2年前，ChatGPT 刚出现时，可能确实让人感到震撼🫨，但没想到 AI 发展这么快，LLMs 层出不穷。

整个 2025 年，从开年就一直出现新的突破：

  1. 2024年圣诞夜🎄，Deepseek 横空出世；
  2. Claude Code / OpenAI 推理大模型；
  3. YOLO mode / AI Agent / MCP / Skill 涌现新工具🔧；
  4. gpt-image-1 / Gemini 2.5 Flash Image / Nano Banana Pro / Z-Image / Qwen-Image-Edit-2511 出现图像生成模型；

某些领域，甚至开始大量使用AI编排工作任务和流程安排。

从企业工厂、工作室到个人，AI无处不在。

Ref

LLM
 
我终于实现了生图自由：ComfyUI 本地部署 Z-Image

自从上次使用 GPT-Image-1 生成插件 logo 后，一直对图像生成模型念念不忘。

但是 GPT-Image-1 非开源模型，没办法本地部署。

查了很多资料，发现 Stable Diffusion 开源模型和配套工具，部署有点麻烦，遂放弃了.

今天心血来潮，又去问了ChatGPT：

2026-02-03_22-23

仍然提示“Stable Diffusion”。

同时，也看到了“Z-Image”，感觉命名风格与“GPT-Image-1”很像。于是，就去查了一下这是什么？看看是哪家公司制作的模型。

发现 github 上有 9.8k 个star，应该不简单。

2026-02-03_22-29

再仔细一看，“造相”？我还以为开了沉浸式翻译。😅

仔细看完 README，大致了解了它的能力，决定试一下。

中途发生了一个小插曲：我发现了 Ultra Fast Image Gen 项目，使用下来感觉还不错，速度还能接受，生成的图片与之前使用 nano-banana 差不多，当然速度相差很大。

原本打算直接 Clone 官方源码，直接启动 Z-Image，结果运行时报错：

RuntimeError: MPS backend out of memory (MPS allocated: 18.11 GiB, other allocations: 384.00 KiB, max allowed: 18.13 GiB). Tried to allocate 47.50 MiB on private pool. Use PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.0 to disable upper limit for memory allocations (may cause system failure).

为了跑起 Z-Image，下载了 32.9G 的文件，现在出现这个问题，我差点emo😈。

2026-02-03_22-54

后面在网上查资料，发现 ComfyUI 这个项目。

ComfyUI 可以配置 Z-Image，并且支持很多图像生成模型，是个非常成熟和主流的使用方式。

立马安装 ComfyUI，然后下载了“Z-Image-Turbo”模版。

2026-02-03_22-58

老实说，第一次在本地玩图像生成模型，对 ComfyUI 很陌生。

又去油管看了相关视频，才知道如何运行。😅

前后一共跑了2个任务，生成2张图片，花了半个多小时，平均一张 15min。

可能电脑配置问题：MacBook Pro M1，16G。

2026-02-03_23-04

油管主播表示，20G显存，大概不到几秒钟。

以上就是今天 Z-Image 图像生成模型的全部内容了。

感觉 ComfyUI 还有很多玩法，需要深度发掘。

Ref

ComfyUI & Z-Image

Stable Diffusion

ComfyUI Stable Diffusion Z-Image
 
Proxifier 使用

Ref

Proxifier
 
🍺 Homebrew 更新周报 # 20260203 | 当工具开始替你守住边界

当系统不再默认你“全都信任”

越来越多的工具，
不再假设环境是安全的、用户是单一的、代码是可控的。

这一期的 Homebrew 更新，
明显在讨论一件事：
哪些事情，应该被隔离、被限制、被显式管理。

本周一句话总结

这一期没有炫目的新能力，
但多了不少：
帮你把“该隔离的隔离、该约束的约束”的工具。

本周新增工具速览

🧪 New Formulae

名称 中文说明
cargo-features-manager 用 TUI 管理 Rust 项目依赖 feature 的工具
codex-acp 通过 ACP 协议在 Zed 等客户端中使用 Codex
dbcsr 分布式块压缩稀疏矩阵计算库
fence 带网络与文件系统限制的轻量级命令沙箱
go-air Go 应用的热重载工具
gogcli Google Workspace 的命令行工具
hdrhistogram_c HdrHistogram 的 C 语言实现
litra 在命令行中控制 Logitech Litra 灯光
llhttp 基于 llparse 的 http_parser 移植实现
mac-cleanup-go 扫描缓存与日志的 macOS 清理 TUI
radicle 构建在 Git 之上的去中心化代码协作平台
tpix 使用 Kitty 图形协议的终端图片查看器
vampire 高性能定理证明器
whosthere 带现代 TUI 的局域网设备发现工具

🧩 New Casks

名称 中文说明
codexbar Codex / Claude 使用配额的菜单栏监控工具
commander AI Agent 操作与调度工具
elegoo-slicer 开源 FDM 3D 打印切片软件
ethui 集成钱包与 Anvil 的以太坊开发工具包
infinidesk 多虚拟桌面环境，每个桌面独立文件与配置
ipaverse iOS App 下载与管理工具
middledrag 通过三指手势实现中键与中键拖拽
repobar GitHub 仓库健康状态菜单栏面板
retrace 本地优先的屏幕录制与内容搜索工具
seam-app 面向 Notch 的生产力导向 Dynamic Island
sky Bluesky 社交平台客户端
trimmy 粘贴即清理、一次性运行的终端剪贴板工具
tritium 面向法律从业者的综合写作与起草环境
whyfi 菜单栏 Wi-Fi 监控与诊断工具
yandextelemost Yandex 视频会议平台客户端

值得留意的几个方向

这一节不求全，
只挑 几个明显在“重画边界”的工具。

fence：命令行，也需要“权限意识”

fence-banner

在终端里执行命令，
长期以来都是一种全信任模型。

fence 的思路很直接：
在执行命令之前，
先决定它能不能访问网络、能不能碰文件系统。

这不是为了防黑客，
而是为了防自己、
防脚本、
防那些你已经不完全理解的工具链。

radicle：当代码协作不再默认“有中心”

web-app-screenshot

radicle 再次提醒了一个老问题：
代码一定要托管在某个中心平台上吗？

它并不追求替代 GitHub，
而是提供一种选择：
当你不想把信任完全交出去时，
依然可以协作。

这是一个慢工具，
但方向非常明确。

infinidesk：桌面，本身就是一种隔离

2026-02-03_15-16

大多数系统的“多桌面”，
只是窗口分组。

infinidesk 把这个概念推进了一步：
不同桌面，
拥有不同文件、壁纸、组件，
像是多个轻量工作环境。

它解决的不是效率问题，
而是上下文污染。

codex-acp / codexbar / commander

当 AI 工具开始被“运维化”

这一期出现了不止一个 Codex / Agent 相关工具，
但它们关注的都不是“更聪明”，
而是：

  • 能不能被接入到不同客户端
  • 使用情况能不能被监控
  • Agent 能不能被调度和约束

这意味着，
AI 已经开始被当作系统组件，
而不是单一应用。

一点个人感受

这一期的工具，
很少在谈“能力扩展”。

更多是在问：

  • 什么东西应该被限制？
  • 什么操作值得被隔离？
  • 什么系统不该再是默认全信任？

这不是悲观，
而是一种成熟。

当工具开始替你守住边界，
人才能更安心地把注意力，
放回真正需要判断的地方。

结语

Homebrew 的更新，
越来越像一组工程态度的集合。

它不告诉你该怎么用工具，
只是悄悄补齐那些
以前只能靠自觉维护的边界。

我们下期见

Homebrew
 
Claude Code vs Cursor vs Cline vs Codex，究竟如何选？

对于编程模型，我一点都不困惑：

  • 编码 Claude / ChatGPT-4o
  • 日常问题 ChatGPT、豆包、元宝、Deepseek
  • 本地部署 Ollama + Qwen / Deepseek

以上基本够用。

工作中使用 AI 辅助编程，最开始接触的是 Cursor，然后是 Cline。

Claude Code 反而是最后使用的，但是使用了几次之后，
发现有些时候比 Cursor 和 Cine 更顺手。

可能是因为 Rule 的原因吧，它们有一些差异，变动也比较大。

Cline 里面不单有 Rule，还有 Workflow 的概念。

Claude Code 和 Cursor 估计也有，可能叫法不一样。

现在这几个AI工具，只有 MCP 和 Skill 是统一的，其他东西都有一点区别。

用起来费劲，想着只使用一个就好了。

可能用的时间还太短了吧，需要多看看官方文档和学习。

Ref

Claude Cline Cursor
 
如何开发MCP？
mcp-simple-diagram

Ref

 
体验了一把 nano-banana，感觉还行

之前逛小红书，看到很多漂亮的信息图，非常震惊🤯。类似这样

G6P2pXtWwAATf8-

后面得知是 nano-banana 生成的，立马想体验一把。

今天闲来无事，登录 Goole AI Studio，试玩了几把，感觉还不错。

比 ChatGPT 简单多了，即便没有精心雕琢的 Prompts，也可以获得不错的图片效果。

直接丢给 nano-banana 一个 Markdown 文档，然后说将这个文档转成信息图，就得到了一个设计友好、信息准确的图片。

2026-01-30_15-54

生成的信息图：

Generated Image January 30, 2026 - 3_53PM

如果想尝试不同风格，只需这样：

2026-01-30_15-54_1

生成的信息图：

Generated Image January 30, 2026 - 3_54PM

毕竟是免费的模型，文字有很多错误，如果使用中文，会乱码。

如果使用 nano-banana pro，可能就没这些问题了。

Ref

nano-banana
 
clawdbot 与 ifttt：又一个玩具？

clawdbot(Moltbot) 很火，各种蹭流量的话题都有它。

但还是之前说的那样：

“老实说，我没有完全理解它的“价值”。”

“个人预计，很快就没人会讨论它，Clawdbot。”

突然间，我想起 IFTTT，

If This Then That ——「如果发生了这件事，就执行那件事」

IFTTT 大概可以算是「自动化工具的祖师爷」之一。

IFTTT 刚出现的时候，也引发了很多人的期待，但最终情况就像现在这样，无人问津。

在我看来，clawdbot = 自动化工具 + AI：

clawdbot = 自动化工具+AI

虽然，AI 很强，但是仍然有许多事情无法完成：

  1. 人类没有参考方案的事情；
  2. 没有训练过的案例；
    ...

诸如此类，很多的场景。归根结底，AI 只能运行在人类设计的认知范畴里，一旦超出了人类的认知，它什么都干不了。

说个笑话，假如停电了，AI会去交电费吗？

直白点说，科技圈只是又多出一个玩具，clawdbot。

clawdbot
Prev
Page 2 of 5
Next