最近在 GitHub 上闲逛的时候，我发现了 [[李继刚]] 整理的一批 [[Claude Skills]]，出于好奇就 clone 下来翻了翻仓库。打开目录一眼扫过去，几乎所有 Skill 输出的文档文件名都长得很特别，大致是这样的形式: 20260527162000==z--投资分析-ajinomoto-2802。这种带着长串数字时间戳、夹杂 == 和 – 分隔符的写法，一眼看上去既不像我熟悉的 [[Jekyll]] 那种 YYYY-MM-DD-title.md，也不像 [[Obsidian]] 里常见的中文标题直接做文件名，反而有种”工程化”过头的
Read more ...
最近我在 macOS 上重新整理终端工具链的时候，又一次认真看了 [[Ghostty]]。很多人第一次接触 Ghostty，会先被它的界面、速度或者作者背景吸引，但只要打开 Shell 跑一个 echo $TERM，很快就会看到一个更陌生的名字：xterm-ghostty。这个名字看起来像是传统 xterm 的变种，实际上它背后代表的是 Ghostty 对终端兼容性的一整套设计思路。很多人把它当成一个无关紧要的环境变量，但如果你经常使用 [[SSH]]、[[tmux]]、[[Vim]]、[[Neovim]]、[[less]] 或者各种 TUI 工具，理解
Read more ...
终端智能体的新旅程
作为一个长期泡在终端里的开发者，我的工作流几乎完全是由命令行和各类快捷键支撑起来的。从早期的命令行自动补全，到后来各种基于大模型的命令行聊天助手，AI 在终端里的角色一直在发生改变。然而，大多数时候我依然觉得有些割裂。当我们需要 AI 帮我们重构一个复杂的跨文件模块、运行构建命令并根据报错自动迭代时，传统的聊天式工具就显得力不从心了。
我最近一直在深度使用 Google 推出的新一代命令行开发工具 [[Antigravity CLI]]。在实际体验了一段时间之后，我深刻地感受到，它不仅仅是又一个命令行 AI 助手，而是代表了一种全
Read more ...
最近在关注 Google I/O 2026 的动态时，看到了一个让我颇感兴趣的发布——[[Antigravity CLI]]，Google 官方宣布用它来取代已经积累了超过 10 万 GitHub Stars 的 [[Gemini CLI]]。这个时机有点微妙：个人版 Gemini CLI 用户必须在 2026 年 6 月 18 日前完成迁移，否则将失去模型访问权限。作为一个长期在终端里工作、也在持续关注 AI 编程工具演进的开发者，我觉得有必要认真研究一下这个新工具到底带来了什么改变。
Gemini CLI 为什么需要被替代
要理解 Antig
Read more ...
随着我频道录制的视频越攒越多，加上平时用相机拍摄的原始素材，存储问题开始变得越来越头疼。一个 4K 视频的原始素材少则几个 GB，多则上百 GB，几次拍摄下来一块移动硬盘就见底了。而且随着视频数量的增加，想快速找到某段素材或者回翻旧成片的成本越来越高。这种情况下，我开始认真考虑搭建一套本地存储方案，于是目光落到了[[零刻]] ME Pro 这台小型 NAS 主机上。
为什么需要一台 NAS
说起来这个问题其实积累了很久。之前拍视频的素材都临时存在移动硬盘里，拍完一期就整理一次，但随着时间推移，手头的移动硬盘越来越多，哪块盘存了哪段素材根本理不清楚
Read more ...
我是一个对音乐播放体验有点执念的人。自从搭建了 [[Navidrome]] 自托管音乐服务器，我就开始了一段漫长的客户端寻觅之旅。在 iOS 上，我几乎把能找到的 [[Navidrome]] 客户端都试了一遍，甚至为了体验更好而付费购买了 [[音流]]。但最终，我还是删掉了它们，把 [[Narjo]] 固定在了屏幕上。
自托管音乐服务器的现状
在流媒体服务大行其道的今天，还在折腾自建音乐库的人，往往有些相似的执念：想要拥有自己的音乐，不依赖平台，不受版权下架的困扰，或者单纯就是喜欢把喜欢的 FLAC 文件存放在自己的硬盘上。[[Navidrome
Read more ...
最近我一直在思考一个问题：AI 编码工具越来越多，但为什么每次切换工具或开启新会话，都感觉像是从零开始？我用 [[Claude Code]] 写了一段时间，又想试试 [[Gemini]] CLI，但每次都要重新解释项目背景、编码规范、当前任务进度。这种重复性的”上下文喂养”工作，慢慢变成了一种隐性负担。
直到我发现了 Trellis，才意识到这个问题其实已经有人在认真解决了。
什么是 Trellis
Trellis 是由 Mindfold AI 开发的一个开源框架，定位非常明确：让 AI 编码代理真正具备生产就绪能力（production-re
Read more ...
最近在排查一台服务器的性能问题时，我习惯性地打开了 [[htop]]，盯着那一列列滚动的数字，试图从里面读出 CPU 负载的变化趋势。说实话，数字本身没什么问题，但当你需要判断”过去几分钟内 CPU 是否有明显的周期性抖动”时，一屏幕的百分比实在不如一条折线来得直观。就在那个时候，我发现了 tiptop 这个工具，用了之后感觉有点相见恨晚。
从 top 到 tiptop
[[top]] 是 Unix/Linux 系统里最经典的进程监控命令，存在了几十年，几乎人人都用过。后来出现的 [[htop]] 在交互体验上做了很大的改进，支持鼠标操作、彩色显
Read more ...
做产品的人都绕不开一个问题：用户到底在用我的产品做什么？他们在哪一步流失，哪个功能最受欢迎，新版本上线后行为有没有变化。回答这些问题需要数据，而收集和分析这些数据，往往需要堆砌一大堆工具——用 [[Mixpanel]] 做事件分析，用 [[FullStory]] 录制会话，用 [[LaunchDarkly]] 管理功能开关，用 [[Optimizely]] 跑 A/B 测试。每个工具都要单独集成 SDK，单独管理账单，数据还分散在各处，关联分析几乎不可能。
我在寻找一个能把这些能力整合起来、又不让数据流向第三方的解决方案时，发现了 [[PostHo
Read more ...
用 [[Claude Code]] 写代码时，一直有一个令人微妙不适的摩擦：每当 Claude 完成一轮工作，控制权就回到了我这里，我需要再次发出指令，告诉它”继续”“再检查一遍”“还有这个文件没改”。对于那种需要跑很多轮才能完成的任务——比如把一个模块从旧 API 迁移到新 API 直到所有测试通过，或者逐文件重构某个目录直到符合统一规范——这个”人类中继”的环节就显得相当机械，本质上我只是在不停地按确认键。
[[Claude Code]] 最新推出的 /goal 命令针对的正是这个场景：你描述一个完成条件，Claude 就跨多个 turn 持续工作
Read more ...