工具

TL;DR: Linear 推出了一个集成的人工智能代理。听起来不错，但它并没有解决开发者在终端操作 coding agents 时的痛点。我们需要的不是另一个代理，而是一个可靠的 CLI，我们现有的代理可以直接调用。如果要重写，那就用 Rust——这就是 lql 的由来，一款专为 Linear 设计、面向代理的 CLI。 昨天，Linear 宣布了他们的人工智能代理。这是一个集成到应用中的聊天机器人，能够理解你的 roadmap，你的 issue 和你的代码。你可以在 Slack 上与它对话，在评论中@提到它，它会综合上下文，建议行动方案，甚至直接为你创建 issue。 听起来很棒。真的，很棒。 尽管如此，当我读到这个公告时，我的第一反应是：“这不是我需要的东西。” Linear 的大冒险 为了让你明白我的意思，我需要先讲讲背景。我和 Linear 的关系就像一部委内瑞拉肥皂剧一样，是一段充满了爱恨交织的故事。 第一幕：MCP 服务器。 Linear 曾经有一个 MCP 服务器，供人工智能代理与其交互使用。它的表现就像是在飓风里点打火机：技术上是能点着火，但火焰从来维持不到两秒。断断续续、缓慢，偏偏总是在关键时刻掉链子。最终我直接把它卸载了。 第二幕：GraphQL API。 于是唯有通过 GraphQL 直接和 Linear 沟通。没错，它确实能用，直到你需要在某个 issue 的描述中加入特殊字符，结果这些字符的转义问题会让你重新思考自己的整个人生。某一次，我花的时间转义一个括号比写 issue 所描述的代码还要长。 第三幕：Linear CLI。 然后 linear CLI 出现了，这是一个由社区开发的项目。brew install schpet/tap/linear 然后直接运行。一个第三方工具，朴素、不显眼，但正是我需要的工具：能够直接在终端创建、列出并更新 issue，而不需要与 GraphQL 或那个让人发疯的 MCP 作斗争，也没有弹窗干扰。 我甚至专门写了一篇文章 讲述自己如何用这个 CLI 解放了工作流。一个简单的 bash 脚本帮我在不到一分钟内创建了 49 个 issue。如果用 MCP，我可能会花上一个半小时。 进入代理 现在 Linear 推出了他们的代理。这款产品承诺：一个可以理解你的工作空间、与你的代码连接并自动化你的工作流程的集成助手。 ...

你的 Mac 现在有多少垃圾文件，是你完全不知道的？ 我不是指那些2019年烧烤派对的重复照片，也不是那个简直快变成垃圾堆的下载文件夹。我说的是构建的临时文件，比如那些你疫情后就再也没碰过的 node_modules 文件夹、你甚至不记得安装过的框架缓存文件、堆积如山的 Xcode 的 derived data（派生数据），就像床底下的灰尘一样。 我好几个月磁盘空间占用达到了85%，每次删东西都跟玩杂技一样小心翼翼。直到我发现了Mole，运行了 mo purge --dry-run，屏幕上弹出了一个数字：17GB可回收空间。整理出来了三百五十个被遗忘的构建临时文件，还在那里静静地腐烂着。 十七个G！完全没有碰到任何照片或文档。 什么是Mole（以及它不是什么） Mole 是一个适用于 macOS 的CLI工具，它声称可以“深度清理并优化你的 Mac”。它带有一些看起来像瑞士军刀一样多功能的命令菜单： mo clean # 清理缓存、日志和临时文件 mo uninstall # 完全卸载应用程序 mo optimize # 检查并“优化”系统 mo analyze # 分析磁盘使用情况 mo status # 系统健康监控 mo purge # 删除项目构建临时文件 mo installer # 找到旧的安装包 mo touchid # 配置 sudo 使用 Touch ID 八个命令。直接告诉你吧：**只有两个命令值得你花费时间**。其余的从“嗯，这个我自己就搞定了”到“绝对不可能执行”都有。 ## mo purge：低调的宝藏 如果你是开发者，并且用 Mac 已经超过六个月，那么`mo purge`会帮你发现隐藏的宝藏。简单来说，它会扫描你的项目目录，找出那些占用空间却对你完全没有帮助的构建临时文件。 都有哪些类型的临时文件？基本上都是常见的“嫌疑人”： - **node_modules**（你几个月没碰的 Node/Bun 项目） - **target/**（Rust 项目） - **build/** 和 **.build/**（Swift/Xcode 项目） - **DerivedData**（Xcode 的派生数据） - **__pycache__** 和 Python 的虚拟环境 - **.gradle** 和 **build/**（Java/Kotlin 项目） - **Pods/**（iOS 的 CocoaPods 项目） 这些文件夹的好处是：可以100%重新生成。如果你某天重新打开这个项目，运行一个`npm install`或者`cargo build`，它们会从零重新创建。但在此之前，这些文件像“赖账房客”一样，白占着你的磁盘空间不交房租。 ### 正确的操作流程 首先，一切都从**干跑模式（dry-run）**开始： ```bash mo purge --dry-run 这个命令会显示找到的内容以及可以释放的空间大小，但不会实际删除任何内容。你需要利用这个阶段检查列表，并确定它不会误删掉你正在使用的项目文件（比如你当前有几个窗口正在打开一个项目的node_modules）。 ...

想象一下你有一个出色的工作伙伴。他能解决复杂的问题，编写清晰的代码，对你的要求一听就明白。但是，每天下班后，每次你跟他说“打开课程项目”，他都会一脸茫然地看着你，问：“什么课程？在哪里？” 每天如此，毫无例外。 这就像和电影《记忆碎片》（Memento）的主角Leonard Shelby一起生活。他无法形成新的记忆，因此只能把重要的信息纹在身上，避免遗忘。 我每天都会和Claude Code一起处理四到五个项目。几周内，每次我对他说“去课程项目”或者“打开博客”，他都会像维多利亚时代的探险家寻找尼罗河的源头一样，执行find / -name "p101"命令，用五分钟时间在硬盘上搜索我每天都会使用的目录。 这可真让我抓狂。 问题：数字版的顺行性遗忘症 你的AI助手每次启动都像打开了一张白纸。它不知道你住在哪里，不知道你有哪些项目，不知道~/courses/p101/program这个目录存在，也不知道你的博客在~/code/frr.dev，或者你的Ansible代码库叫wuwei并且位于~/code/wuwei/ansible。 每次新会话，都得从头开始。这就像Leonard早晨醒来发现自己躺在那个汽车旅馆的房间里。 最自然的反应就是每次手动告诉它路径：“在/Users/fernando/code/tokamak。”这种方式虽然有效，但就像每天早晨都要向你的朋友重新介绍自己。用不了三个星期，你可能会开始考虑是不是单独工作会更省事。 现实世界的解决方案：zoxide 在给自己“纹身”之前，先说说如何用工具解决人类的困扰。 zoxide 是一种带有记忆功能的cd命令。通俗点说，它是替代cd命令的工具，可以通过输入部分片段记住你曾去过的目录，并智能跳转到最有可能的目标。 # 不再需要这样： cd /Users/fernando/courses/p101/program # 只需这样： z p101 完成了。zoxide知道当你输入"p101"时，你是要跳转到/Users/fernando/courses/p101/program，因为这是你过去47次输入类似路径时访问过的地方。 它使用的是一种频次与最近性相结合的算法。经常访问且刚访问过的目录会被优先排列，而几个月未访问的目录会被降级。这有点像TikTok的推荐算法，只不过是用来管理你的文件系统。 安装步骤简单 brew install zoxide # 添加到你的shell配置文件（我用的是Fish）： # 在 ~/.config/fish/config.fish 文件中 zoxide init fish | source 从此，每次执行cd命令都会让zoxide的数据库更新。而z <模式> 让你无需思考就能跳转到目标目录。 z tokamak # → /Users/fernando/code/tokamak z blog # → /Users/fernando/code/frr.dev z wuwei # → /Users/fernando/code/wuwei/ansible z p101 # → /Users/fernando/courses/p101/program 如果遇到模糊匹配（可能有两个以上符合条件的目录），使用zi命令会调出带有交互式选择器的_fzf_工具。 为AI助手配置zoxide：zoxide query 接下来是好消息。zoxide带有一个query命令，它不会改变目录，只是返回最可能的路径： zoxide query p101 # → /Users/fernando/courses/p101/program 对于AI助手来说，这就是黄金功能。与其在整个硬盘上执行find命令，调用zoxide query可以在毫秒级速度返回正确的路径。无需探索，无需猜测。 ...

我现在有三个运行中的 Claude Code 会话。一个在翻译博客文章，另一个在为 CLI 编写测试，还有一个在帮我调试数据流水线。每个会话都运行在独立的 worktree 中，每个会话都开启在 Ghostty 的一个 split 里，而我则通过 Cmd+Alt+方向键 在它们之间快速切换。 我几个月没打开过 iTerm2，几个星期没用过 tmux。现在几乎所有工作都集中在 Ghostty 的一个窗口里。 它是完美的配置吗？当然不是。但它是迄今为止让我最高效的配置？毫无疑问。 为什么选择 Ghostty，而不是别的终端？ 一句话总结：Ghostty 和挖矿一样耗电。我详细讲过 GPU终端和电量消耗问题，这一问题并没有改善，这依然是它最大的缺点。如果我用的是电池，我会果断关掉 Ghostty，转而使用 Terminal.app。 但每当电脑插电源时——我80%的时间都会坐在 Studio Display 前的桌子上工作——Ghostty 赢下这场比赛的两个原因与外观美化完全无关： 1. 没有闪屏。 听起来没什么，但当你每天对着终端屏幕盯八个小时时，就完全不一样了。iTerm2 在快速滚动时会有轻微的闪屏；调整窗口大小时会出现显示滞后；切换标签页时会有轻微的画面闪烁。Terminal.app 这些问题更严重。而由于 Ghostty使用 GPU 渲染，它提供的视觉流畅度绝对不会让人眼睛疲劳。当 Claude Code 输出200多行日志时，你滑动查看有哪些问题时，一款没有闪屏的终端和一款有闪屏的终端，体验可以说完全不可同日而语。 2. 支持超大缓存。 我设置了 scrollback-limit = 50000，即每个终端窗口有 50,000 行历史记录。Claude Code 输出日志时非常详细：生成代码、解释代码、运行代码、显示结果，偶尔还会附上一堆自言自语式的冗长分析。对于 iTerm2 或 Terminal.app 默认有限的缓冲区来说，这种频率的日志输出很容易就会丢失早期的上下文。而在 Ghostty 中，我可以随心所欲地向上滚动，甚至找到两小时前的操作记录，非常可靠。 除此之外，它还支持默认分屏（通过按 Cmd+D 快速创建），内建下拉式 Quake 风格终端（`Ctrl+``），但这些只是锦上添花。无闪屏、不丢日志历史才是它的两大核心亮点。 我的工作窗口布局 当我需要同时处理多个独立任务时，我的 Ghostty 窗口通常如下： ┌──────────────────────────────────┬──────────────────────────────────┐ │ │ │ │ Claude Code (worktree A) │ Claude Code (worktree B) │ │ feature/nueva-validacion │ chore/traducciones │ │ │ │ │ │ │ ├──────────────────────────────────┴──────────────────────────────────┤ │ │ │ 主仓库（main）—— 测试、构建、git log │ │ │ └─────────────────────────────────────────────────────────────────────┘ 上方两个 splits，每个运行一个 worktree 和对应的代理。下方是 main 仓库，用于运行测试、查看变更和在代理完成任务后进行合并。 ...

如果你读过我之前写的 关于 Claude Code 中 worktrees 的文章，你应该知道这个功能的核心就是一个小小的参数：--worktree。执行这个参数之后，每个代理都能在一个隔离的代码仓库副本中运行。每次启动一个代理程序，就在独立的目录中操作。三个代理同时跑也互不干扰，仿佛魔术一般。 现在打开 Codex CLI，想找一下等效的参数，结果发现它根本不存在。 没有 --worktree。没有 --tmux。也没有支持自定义代理的 isolation: worktree 参数。而且，尽管issue #12862 在 GitHub 上已经开了很久，并且已经有人在 fork 中实现了这些功能，但官方始终没有合并代码。到目前为止，Codex CLI 还是无法原生支持多个代理并行操作。 这是否意味着无法使用 Codex 实现并行工作？答案是否定的。这只是意味着你需要自己动手 “折腾” 一下。而这件事说穿了，不过是几个 git 命令和一些预防措施。 计划：手动 worktrees + 每个目录运行一个 Codex 整体思路跟 Claude Code 中的方法类似，只是没有自动化功能。简单来说，就是你自己创建 worktree，自己启动代理程序，事情完了也需要自己清理。这工作听上去有点人工，但它确实管用。 # 从你的主仓库目录开始 cd ~/code/mi-proyecto # 为每个任务创建一个 worktree git worktree add ../mi-proyecto-feat-auth -b feature/auth git worktree add ../mi-proyecto-fix-tests -b fix/tests-rotos git worktree add ../mi-proyecto-refactor -b chore/refactor-db --- 现在你有四个目录：一个主目录和三个 worktree，每个 worktree 都是相互独立的。每个 worktree 拥有自己的分支、暂存区 (*staging area*) 和 HEAD，但共享仓库的元数据（`.git/` 目录），其他一切隔离。 接下来，在每个 worktree 运行一个 Codex： ```bash # 终端 1 cd ../mi-proyecto-feat-auth codex --approval-mode never --sandbox workspace-write \ "实现 JWT 鉴权中间件，编写测试代码。" # 终端 2 cd ../mi-proyecto-fix-tests codex --approval-mode never --sandbox workspace-write \ "运行测试套件，修复所有失败的测试，一直重复直到全部通过。" # 终端 3 cd ../mi-proyecto-refactor codex --approval-mode never --sandbox workspace-write \ "重构数据库模块以使用连接池功能。" 三个代理，三个任务，它们互不干扰。每个 Codex 只看到自己对应的 worktree，并且只操作相应的分支。 ...

几周前，我写了一篇关于 git worktrees 的文章 —— 讲解了它们是什么，怎么创建，以及为什么它们比多次克隆代码库更好。这些只是基础。 但仅仅掌握这些基础只是成功的一半。而 Claude Code 不仅仅是在 worktree 的基础上运行，它还原生支持 worktree，拥有专门的参数、自动隔离功能，与 tmux 的深度集成。了解 worktree 存在和理解 Claude Code 如何利用它们的巨大差异，就像拥有一辆车并知道它有运动模式一样。 Claude Code 的创始人 Boris Cherny 发布了五个关于充分利用 worktree 的技巧。我把这些技巧全都测试了一遍。有些真的是大大优化了我的工作流，省去了我从今年一月起一直在用的小修小补（ñapa）。下面一起来看看吧。 技巧 1：--worktree —— 一个参数搞定一个 worktree 在经典的 worktree 工作流程中，你需要进行以下这些操作： git worktree add ../mi-proyecto-feature -b feature/algo cd ../mi-proyecto-feature claude 总共三步。虽然不算太复杂，但得想目录名、记住语法，然后还得导航到新目录。如果你一天做五次这个操作，时间一长确实会觉得心累。 Claude Code 将整个过程简化成了一步： claude --worktree 就是这样。Claude 会创建一个临时 worktree，将目录命名为随机生成的名字，自动切换到该目录，并启动会话。当你结束作业后，worktree 会自动清理干净。 我什么时候会用这个功能？每次我想测试一些东西又不想污染当前分支的时候。比如尝试一个激烈的重构，探索另一种设计方案，做某个 spike 实验。如果成功的话，我会合并。如果不成功，worktree 就会消失得无影无踪。 这个功能就像是在你的文本编辑器里打开一个新草稿一样。没有任何负担，甚至无需仪式感。 技巧 2：隔离子代理的 worktrees 如果你已经在 Claude Code 中使用了子代理功能（通过在自定义 agent 中使用 Task，或在主要代理内进行委托操作），你可能会知道这些子代理共享同一个工作目录。这意味着两个子代理可能会覆盖彼此的文件，争抢 git 的 index，或者让 staging area 一团混乱。 ...