Claude Code

几个月来，我一直用自制的 cron 来执行 Claude Code 的任务。一个 Bash 脚本启动一个 headless 会话，给它一个 prompt，等待任务完成后关闭。它能运作，虽然运作得勉强，但能用。如果有需要，我把代码放在 GitHub 供大家参考。 而上周五，Anthropic 发布了 2.1.71 版本，引入了 /loop。一个原生的调度器，就直接内置在 Claude Code 会话中。 我的第一反应是：“我的项目凉了。” 试用之后的第二反应是：“嗯…还没死，但离死不远了。” /loop 的功能 语法相当简洁： /loop 5m check the deploy status 这个命令告诉 Claude Code：“每 5 分钟，执行这个 prompt 一次。” 不需要退出会话，也不需要 cron，也不用脚本。Claude 来解析时间间隔，安排任务，并在会话仍然开启且处于 *空闲* 状态时执行它。 你可以串联多个斜杠命令： /loop 20m /review-pr 1234 /loop 1h make test 2>&1 | tail -5 每个 loop 都有一个“安全网”：三天后它会自动到期。如果你曾经留下一个忘记关闭的 cron，你大概能理解这种设计有多贴心。 ## 我会如何使用它 试用一天后，我已经发现了三个明确的用途： **1. 在开发过程中监控测试。** 现在我正在 Tokamak 上实现一个重要功能（比如冷启动的五个优化阶段）。与其每次修改一点代码就运行 `make test`，不如直接这样做： /loop 10m make test 2>&1 | grep -E “passed|failed” ...

上周，我在用 Instruments 工具对一个 Swift 应用进行性能分析。没什么稀奇的：运行 xctrace record，再运行 xctrace export，然后把导出的 XML 拷贝到 Claude Code 的上下文，让它帮忙分析热点。 结果 Claude 跟我说："XML 文件太大，无法可靠地处理。" 33,553 行 XML，只为分析一个只有两个函数的程序。 真正的问题 xctrace export 是一个很棒的工具。它什么都给你：每一个采样点、每一个调用栈、每一帧的二进制信息、内存地址、UUID，简直面面俱到，精准无比，完美无缺。 但问题，也正是源于它的完美无缺。 对一个应用程序进行性能分析时，我并不需要所有的 3,044 个细节采样点。我不需要知道第 1,847 个采样点在 00:02.847.882 捕捉到了 libswiftCore.dylib 内存地址为 0x1027ec9a8 的内容。我只需要知道 heavyWork() 花掉了 70% 的时间，而 lightWork() 只用了 30%。 用大白话来说：我需要的是 10 行总结，而不是 33,000 行繁文缛节。 为什么 XML 格式是正确的选择（但噪音不可取） 在有人提出“2026 年了还用 XML 才是问题”之前——并不是这样。 XML 对于 xctrace 的功能来说，是非常理想的格式。试想一下： 层次结构：一个调用栈是一个框架的树状结构。一个采样点包含了一个调用栈，一个线程，一个进程。XML 自然而然地可以建模这些内容。 自描述性：每个元素都有名字、带类型的属性，并且结构可以被验证。你不用去猜 CSV 第七列的内容代表什么。 优雅的去重：xctrace 使用了 id 和 ref 系统，首次定义一个框架时是这样的：id="59" name="heavyWork()"，后续只需引用 ref="59"。可以看作是一种序列化的 flyweight pattern。 可以用标准工具解析：XPath、xmllint、xml.etree.ElementTree…… 不需要专属解析器。 xctrace 的 XML 格式并不是冗余。它是 Instruments 所需的结构化信息，用来重建交互式调用树、对比运行情况，以及按线程和进程进行筛选。它是专门为一个可以展开和折叠节点的 GUI 工具设计的。 ...

2026 年 2 月 25 日，Anthropic 宣布了针对 Claude Code 的 Remote Control 功能。构思是这样的：你在终端启动 Claude Code，然后拿着手机躺在沙发上，通过 claude.ai 继续你的会话。无需 SSH。无需 tmux。也不需要远程终端窗口。 听起来很酷，对吧？ 但实际上，当我在终端输入 /rc 激活后，它给了我一个 URL。我打开手机，登录进去… 然后 claude.ai 提示我 “this feature is not active in your organization”（此功能尚未在您的账户中启用）。2026 年 2 月，我订阅的是 Max 5x 账户，每月按时付款。但什么都没用。 于是，我决定做任何理性人都会做的事：反编译 API，弄清楚后台到底发生了什么。 什么是 Remote Control（官方说法） 本质上：它是一个连接本地 CLI 和 claude.ai 网页的桥梁。Claude Code 的 CLI 仍在你的机器上运行（可以访问你的代码、终端和文件），但你可以通过任何浏览器查看它、批准 tool calls，并发送消息。 Anthropic 将它作为一项 “research preview"（研究预览）推出，仅面向 Max 用户。官方的期望是，你可以启动一个长任务（/rc + 提示词），关上笔记本电脑，去健身房，然后通过手机查看任务进度。 然而，正如我们接下来要讨论的，现实要微妙得多。 我们发现的底层真相 当你运行 /rc 时，Claude Code 会在后台做很多事情。而且，这些行动会留下大量的痕迹——在 JSONL 文件中、在 debug logs 里、在 API 响应里。让我们逐一拆解。 ...

一个 100MB 的 CLI 二进制文件 Anthropic 刚刚宣布，Claude Code 已经可以作为 原生构建 使用了。翻译一下：这意味着你可以直接下载一个可执行的二进制文件（通过 curl 安装），不需要再依赖 Node.js。 听起来是不是很棒？一个命令，没有额外依赖，后台还能自动更新。简直就是每个 CLI 工具的梦想。 但是有一个问题：这个二进制文件竟然有 100MB 的大小。 作为对比，git 的二进制文件大约只有 3MB，而 curl 则不到 1MB。就算以生成较大二进制文件著称的 Go，它的文件一般也很少超过 15-20MB。 那么，这 100MB 到底装了些什么？ 不是 Rust，而是披了可执行文件外衣的 Bun 当我看到这个公告时，第一反应是：“一定是用 Rust 重写了。” 毕竟，要实现快速的原生二进制文件，而且不依赖运行时，Rust 是明显的选择。 但事实并非如此。 Claude Code 仍然是 TypeScript。Anthropic 使用了 bun build --compile 命令，将其打包成了可执行文件。 bun build --compile 的工作原理 神奇的命令是这样的： bun build ./src/index.ts --compile --outfile claude 这个命令到底做了什么？分为三步来解释： 1. 打包 首先，Bun 作为一个打包工具，处理你的入口文件（比如 index.ts），解析所有的 import，并生成一个包含所有代码的单一 JavaScript 文件。在这个过程中，还会自动引入 node_modules 里的依赖，进行 tree-shaking 删除无用代码，并对结果进行压缩优化。 ...

10 GB 的惊喜 你在 Mac 上安装了 Claude Desktop。最初一切正常，这个应用看似占用空间很小。但某天，当你检查磁盘时，发现了这个文件： ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle 10.8 GB。 是的：一个名为 claudevm.bundle 的文件，隐藏在 Claude 的 vm_bundles 文件夹中，竟占用了将近 11 GB 的存储空间。一个聊天机器人居然需要 10 GB？它里面装了什么，魔戒三部曲加长版视频？ 其实不是。claudevm.bundle 包含了一个 Ubuntu 系统。 Claude 的三大产品类别 在解释“是什么”之前，先来聊聊“为什么”。Anthropic 提供了三种方式让你使用 Claude： 产品 执行环境 目标用户 claude.ai Anthropic 云服务器 所有人 Claude Desktop + Cowork 你的 Mac 上的虚拟机 专业人士 Claude Code 在你的系统上直接运行 开发者 网页版是最安全的选项：所有操作都在 Anthropic 的云端完成，你的电脑完全不受影响。但如果你希望 Claude 不仅仅用于聊天，还能在你的电脑上“真正做事情”——比如创建文档、执行代码、处理文件等，那你需要更多功能。 这时，Cowork 和 Claude Code 应运而生，两者代表了完全不同的理念。 Cowork：人人都能用的 Claude Code Cowork 是 Anthropic 在 2026 年 1 月 12 日推出的智能助手产品。它的官方口号是： ...

犯罪现场 萨拉戈萨，皮拉尔广场酒店的咖啡厅。一杯拿铁，望向大教堂的景色，还有我带着全新的MacBook Air M3，准备在会议前用Claude Code工作几个小时。 两小时后：电池剩余15%。红色警报。恐慌。 但是怎么可能？我只是在终端里写代码。没有视频，没有Zoom，没有任何能够合理解释如此高耗电量的应用。 我打开活动监视器，点击能耗选项卡，罪魁祸首就在那里：Ghostty，在过去12小时内累计消耗了3600。为了让你有个概念，Brave浏览器消耗了125。开着视频的Zoom消耗了99。Claude（桌面应用）消耗了46。 我的终端——一个显示文本的应用程序——消耗的电量比网页浏览器多30倍。 荒谬中的荒谬 停下来想想我刚才写的内容。 一个终端。一个VT100模拟器。一项1978年的技术。字面意思上是一个工作就是在屏幕上显示字母的应用程序，这是Commodore 64都能轻松完成的任务。 而在2026年，它需要GPU来运行。 用大白话说：我们正在使用本可以实时渲染《玩具总动员》的计算能力…来显示ls -la。 原版VT100终端消耗30W包括CRT显示器。我的MacBook Air，配备专为能效设计的最新芯片，显示一个git status比执行视频通话消耗的电量还要多。 这就像开法拉利去买面包。但更糟糕，因为如果你想开得快，法拉利至少还有意义。这里没有任何实际优势：文本看起来完全一样。 为什么终端需要GPU？ Ghostty、Alacritty、Kitty等是新一代"GPU加速"终端的一部分。承诺：更流畅的渲染，大量输出时更好的性能，更清晰的字体。 现实：它们像没有明天一样耗电，显示的内容和Terminal.app使用CPU显示的完全相同。 问题不仅仅是渲染。当Claude Code运行时，会有持续的输出：旋转器、日志、工具结果。屏幕上出现的每个字符都会触发GPU渲染管道。Metal激活，着色器开始工作，帧被合成… 就为了显示一个旋转的点。 更糟糕的是，这些现代终端无法正确进入"App Nap"状态。macOS有一个暂停后台应用程序的系统，但如果终端正在显示动画旋转器，系统会认为它在做重要的事情并保持其活跃状态。 穷人解决方案：Terminal.app 最简单的解决方案也是最明显的：使用Terminal.app。 是的，就是macOS自带的终端。那个看起来自2005年以来没有变过的终端。那个没有GPU加速、连字或任何现代功能的终端。 # 打开Terminal.app并运行 claude 功能完全一样。Claude Code不知道也不关心你从哪个终端运行它。而且Terminal.app： 使用CPU渲染（在Apple Silicon上超级高效） 正确进入App Nap状态 消耗电池的一小部分 性感吗？不。有用吗？完美。 改进解决方案：带配置文件的iTerm2 如果你离不开现代终端，iTerm2有一个Ghostty没有的选项：你可以禁用GPU渲染。 步骤1：创建"电池"配置文件 打开iTerm2 Preferences → Profiles 复制当前配置文件（点击左下角的+按钮，然后选择Duplicate Profile） 将新配置文件命名为**“Battery”** 在Battery配置文件中：Terminal → 取消勾选**“GPU Rendering”** 步骤2：手动切换 当使用电池工作时，只需切换到配置文件： Profiles → Battery（在iTerm2菜单中） 两次点击。你的终端现在像一个负责任的公民一样耗电。 步骤3：自动切换（可选） 如果想要自动切换，将以下内容添加到你的.zshrc或config.fish： # 对于zsh (~/.zshrc) if [[ $(pmset -g batt | grep -c "Battery Power") -gt 0 ]]; then echo -e "\033]50;SetProfile=Battery\a" fi # 对于fish (~/.config/fish/conf.d/iterm_battery.fish) if test (pmset -g batt | grep -c "Battery Power") -gt 0 echo -e "\033]50;SetProfile=Battery\a" end 每次打开新标签页时，iTerm2会检查你是否在使用电池，并自动切换到高效配置文件。 ...