fswatch:macOS 上零开销监控文件系统变化的利器

最近在折腾本地知识库索引方案的时候,遇到了一个很常见的问题:每次新增或修改笔记之后,需要手动触发一次索引重建脚本,时间长了非常容易忘记。轮询方案(每隔几秒扫描一次目录)倒是能解决问题,但代价是 CPU 和 I/O 的持续消耗,在有几万个文件的知识库里显得格外浪费。这时候朋友推荐了 [[fswatch]],用了之后觉得这才是正确的打开方式。 fswatch 是什么 fswatch 是一个开源的跨平台文件系统监控工具,由 Enrico M. Crisostomo 开发并维护,项目托管在 GitHub 上。它的核心思路很简单:订阅操作系统提供的文件系统 Read more ...


claude-mem:让 AI 编程助手拥有持久记忆

用 [[Claude Code]] 已经有一段时间了,它作为 AI 编程助手确实好用,但有一个问题始终让我感到遗憾:每次开启新的会话,Claude 就像刚出生一样,对之前我们一起讨论过的架构决策、踩过的坑、做出的权衡,统统不记得了。我得重新介绍项目背景,重新解释上次解决的思路,重新建立起那个”默契”。直到我发现了 claude-mem 这个项目,才意识到这个问题有了相当优雅的解法。 AI 助手的”记忆缺失”问题 现代 AI 编程助手的上下文窗口虽然越来越大,但本质上仍是无状态的——每个会话独立,上一次的交流不会自动延续到下一次。对于临时性的任务, Read more ...

2026-06-16 claude-code , ai , memory , productivity , tool

用 Harbor 搭建私有 Docker Registry:从安装到日常使用的完整实践

我维护过几个跑在自己服务器上的小项目,构建出来的 [[Docker]] 镜像最早都是直接推到 [[Docker Hub]] 上的。用了一段时间之后开始觉得别扭:一些只在内网跑的服务镜像,没必要也不应该传到公开的仓库;Docker Hub 对匿名拉取做了限流之后,CI 流水线偶尔会因为触发了速率限制而失败;再加上想给不同的项目、不同的同事分配不同的访问权限时,公共仓库这套体系根本满足不了。折腾到后来我意识到,是时候在自己的机器上搭一个真正能用的私有镜像仓库了。 最朴素的做法当然是直接跑官方的 registry:2 镜像,几行命令就能起一个 [[Docke Read more ...


用 New API 打造个人 AI 网关:统一管理所有大语言模型接口

这段时间我同时用着好几个大语言模型服务:日常写作和代码靠 [[Claude]],轻量任务交给 [[Codex]],搜索增强用 [[Antigravity]],还有几个本地跑着 [[Ollama]] 的小模型供离线场景使用。每个平台各自的 API Key 散落在项目环境变量里,月底要去好几个后台分别对账,想横向对比两个模型的输出还得打开不同的网页或客户端来回切换,很费事。 用这种方式折腾了一段时间之后,我开始认真找一个能统一管理这些 API 的工具。最终落在了 [[New API]] 上,用下来解决了不少痛点,今天把使用心得记录一下。 什么是 Ne Read more ...

2026-06-09 ai , llm , api , new-api , open-source

Claude Code 的 Dynamic Workflows 让模型自己写编排脚本

最近 Anthropic 在五月底悄无声息地往 [[Claude Code]] 里塞了一个挺颠覆的功能,名字叫 Dynamic Workflows。我一开始没太当回事,以为又是某种新的 subagent 包装层,毕竟过去一年里这类”让多 agent 协同工作”的概念已经被各种框架翻来覆去地讲过。直到我看到 Bun 团队用它把整套代码从 [[Zig]] 移植到 [[Rust]] 的案例,11 天写了大约 75 万行代码,测试通过率 99.8%,才意识到这次的设计思路和之前的”agent 团队”完全不是一回事。 写这篇文章主要是把我这几天读官方文档、刷各种 Read more ...


Surfingkeys:比 Vimium 更强大的浏览器键盘控制扩展

最早接触 [[Vimium]] 是在学习 Vim 编辑器之后,那种能用键盘完全控制浏览器的感觉确实让人着迷。不用频繁移手到鼠标,链接跳转、页面滚动、标签切换全用键盘搞定,效率提升的体验是实实在在的。用了几年 Vimium 之后,我开始接触到 [[Surfingkeys]],起初以为不过是另一个同类扩展,但深入用下来才发现这两者的差距远比我想象的大。 为什么要用键盘控制浏览器 对于长期使用 [[Vim]] 的人来说,键盘操作的肌肉记忆已经根深蒂固。在编辑器里习惯了 hjkl 导航,切换到浏览器还要去抓鼠标总觉得很割裂。更重要的是,对于程序员、研究者 Read more ...


Denote 介绍 Emacs 下基于文件名的笔记系统

最近在 GitHub 上闲逛的时候,我发现了 [[李继刚]] 整理的一批 [[Claude Skills]],出于好奇就 clone 下来翻了翻仓库。打开目录一眼扫过去,几乎所有 Skill 输出的文档文件名都长得很特别,大致是这样的形式: 20260527162000==z--投资分析-ajinomoto-2802。这种带着长串数字时间戳、夹杂 == 和 – 分隔符的写法,一眼看上去既不像我熟悉的 [[Jekyll]] 那种 YYYY-MM-DD-title.md,也不像 [[Obsidian]] 里常见的中文标题直接做文件名,反而有种”工程化”过头的 Read more ...


Ghostty 和 xterm-ghostty 是什么

最近我在 macOS 上重新整理终端工具链的时候,又一次认真看了 [[Ghostty]]。很多人第一次接触 Ghostty,会先被它的界面、速度或者作者背景吸引,但只要打开 Shell 跑一个 echo $TERM,很快就会看到一个更陌生的名字:xterm-ghostty。这个名字看起来像是传统 xterm 的变种,实际上它背后代表的是 Ghostty 对终端兼容性的一整套设计思路。很多人把它当成一个无关紧要的环境变量,但如果你经常使用 [[SSH]]、[[tmux]]、[[Vim]]、[[Neovim]]、[[less]] 或者各种 TUI 工具,理解 Read more ...


终端开发的新范式:从 Gemini CLI 到 Antigravity CLI

终端智能体的新旅程 作为一个长期泡在终端里的开发者,我的工作流几乎完全是由命令行和各类快捷键支撑起来的。从早期的命令行自动补全,到后来各种基于大模型的命令行聊天助手,AI 在终端里的角色一直在发生改变。然而,大多数时候我依然觉得有些割裂。当我们需要 AI 帮我们重构一个复杂的跨文件模块、运行构建命令并根据报错自动迭代时,传统的聊天式工具就显得力不从心了。 我最近一直在深度使用 Google 推出的新一代命令行开发工具 [[Antigravity CLI]]。在实际体验了一段时间之后,我深刻地感受到,它不仅仅是又一个命令行 AI 助手,而是代表了一种全 Read more ...


Antigravity CLI:Google 推出的下一代终端 AI 编程智能体

最近在关注 Google I/O 2026 的动态时,看到了一个让我颇感兴趣的发布——[[Antigravity CLI]],Google 官方宣布用它来取代已经积累了超过 10 万 GitHub Stars 的 [[Gemini CLI]]。这个时机有点微妙:个人版 Gemini CLI 用户必须在 2026 年 6 月 18 日前完成迁移,否则将失去模型访问权限。作为一个长期在终端里工作、也在持续关注 AI 编程工具演进的开发者,我觉得有必要认真研究一下这个新工具到底带来了什么改变。 Gemini CLI 为什么需要被替代 要理解 Antig Read more ...

2026-05-22 ai , cli , terminal , google , gemini , antigravity , ai-agent

最近文章

  • Syncthing 升级 2.0 后同步卡在 Preparing to Sync 的解决方法
  • Orca ADE 体验:为 AI 编码 Agent 而生的开发环境,用 worktree 让一群 Agent 并行干活 过去一年里软件的开发方式发生了一个我自己都没料到的转变。以前写代码是工程师对着编辑器敲,现在更多时候是同时开着好几个 [[Claude Code]]、[[Codex]] 之类的编码 Agent,让它们各自去完成一个任务,工程师只负责在中间调度、审阅、拍板。这种”我带一队 Agent 干活”的模式效率确实高,但很快就撞上了一堆现实的麻烦:几个 Agent 都在同一个仓库里改文件,分支互相污染;终端窗口开了一大排,切来切去分不清哪个是哪个;改完还得一个个去看 diff、跑测试、开 PR。工具还是那套为单人设计的 IDE,可我干活的方式早就不是单人了。
  • Git 分支管理与发布上线流程实战指南 最近有朋友来问我 Git 分支和发布流程相关的问题,聊着聊着我发现,分支管理这块我自己算是比较熟悉,平时用起来也有一套固定的习惯,但当话题转到 release 发布流程的时候,我反倒得停下来想一想。
  • herdr 一个窗口调度多个 Coding Agent 什么是 Herdr
  • Claude Code 第三方 API 代理配置 Headroom 最近在给自己的 AI 编程工作流加入 [[Headroom]] 上下文压缩工具时,遇到了一个需要特别注意的配置问题。相信有不少人和我一样,为了降低成本或者改善访问体验,已经在 [[Claude Code]] 或 [[Codex]] 里配置了第三方 API 代理,比如一些第三方聚合平台或者自建的转发服务。这时候想再套上一层 Headroom 做 Token 压缩,就需要特别注意配置细节,不然两层代理会打架。