Claude-Code

我现在有三个运行中的 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 仓库，用于运行测试、查看变更和在代理完成任务后进行合并。 ...

几周前，我写了一篇关于 git worktrees 的文章 —— 讲解了它们是什么，怎么创建，以及为什么它们比多次克隆代码库更好。这些只是基础。 但仅仅掌握这些基础只是成功的一半。而 Claude Code 不仅仅是在 worktree 的基础上运行，它还原生支持 worktree，拥有专门的参数、自动隔离功能，与 tmux 的深度集成。了解 worktree 存在和理解 Claude Code 如何利用它们的巨大差异，就像拥有一辆车并知道它有运动模式一样。 Claude Code 的创始人 Boris Cherny 发布了五个关于充分利用 worktree 的技巧。我把这些技巧全都测试了一遍。有些真的是大大优化了我的工作流，省去了我从今年一月起一直在用的小修小补（ñapa）。下面一起来看看吧。 技巧 1：--worktree —— 一个参数搞定一个 worktree 在经典的 worktree 工作流程中，你需要进行以下这些操作： 1 2 3 git worktree add ../mi-proyecto-feature -b feature/algo cd ../mi-proyecto-feature claude 总共三步。虽然不算太复杂，但得想目录名、记住语法，然后还得导航到新目录。如果你一天做五次这个操作，时间一长确实会觉得心累。 Claude Code 将整个过程简化成了一步： 1 claude --worktree 就是这样。Claude 会创建一个临时 worktree，将目录命名为随机生成的名字，自动切换到该目录，并启动会话。当你结束作业后，worktree 会自动清理干净。 ...

想象一下，你聘请了一位才华横溢的顾问。他拥有两个博士学位，会说七种语言，并且能够解决你甚至都不知道存在的问题。你让他坐到会议室里，然后对他说：“我需要你重构项目的认证流程。” 顾问看着你，点点头，问：“哪个项目？” 你没有给他代码访问权限，也没有给他解释系统架构。他不知道你用的是 JWT 令牌还是会话 cookie，不知道你使用什么编程语言，也不知道你有多少微服务，更不知道为什么上次的迁移尝试以失败告终。 这个顾问，就好比你的 LLM（大型语言模型）。而你刚刚犯了一个 90% 使用 AI 代理的人都会犯的错误：你专注于“大脑”，却忽略了“大脑所看到的内容”。 Prompt engineering 已死。Context engineering 长存。 最近几个月，我在每个论坛、每个 Twitter 话题、每次团队会议中都看到同一个讨论：“用 GPT-5 还是 Claude Opus？哪个模型更适合编程？哪个模型的推理能力更强？” 每次我计算这些问题时，答案基本都是一样的：无所谓。好吧，也不能说完全无所谓。但是，对比选择最好的模型和提供一个完美的上下文，后者的重要性高得多。 一个中等水平的模型配上完美的上下文，能够轻松打败一个顶级模型却只有糟糕上下文的组合。没有例外。这永远成立。 这就是**上下文工程（Context Engineering）**的意义所在。而且，请注意，这与 prompt engineering 并不是同样的概念。 Prompt engineering 是编写一个好的提示：选择正确的词语、组织请求的结构、添加示例等。这很重要，但只是其中的一部分。 做 context engineering 则是在设计模型所看到的一切内容：包括哪些信息要输入、顺序如何、有什么被舍弃、如何压缩，以及哪些必须被优先保留。这是为 LLM 设计的信息架构。 简单来说：prompt engineering 是提出一个好的问题，而 context engineering 是决定学生在考试前可以参考哪些书。 记忆的四个阶段：隐藏的生命周期 OpenAI 最近发布了两篇 Cookbook 文章，深入分析了拥有长期记忆的 AI 代理如何管理上下文。这不是 RAG（检索增强生成），也不是矢量数据库管理。它是一个基于状态的系统，就像一本有严格规则的现场笔记本。 这个模式使用的是 local-first 和 state-based 的方法：一个结构化的状态对象随着代理的运行更新，分为几个主要阶段。 flowchart TD A["1. 注入\n（会话创建时）"] --> B["2. 精炼\n（会话中）"] B --> C["3. 整理\n（会话后）"] C --> D["4. 修剪\n（保存时）"] D -->|"新会话开始"| A A1["将状态渲染为 YAML\n+ 全局记忆（最多 6 条）\n+ 优先级规则"] -.-> A B1["save_memory_note()\n校验记忆持久性\n要求有可操作性\n拒绝保存个人信息和假设"] -.-> B C1["异步任务\n合并会话数据 → 全局记忆\n使用 LLM 进行去重\n过滤临时信息"] -.-> C D1["修剪会话历史至 N 条\n重新注入修剪笔记\n到系统提示中"] -.-> D style A fill:#2d3748,stroke:#4a9eed,color:#fff style B fill:#2d3748,stroke:#ed9a4a,color:#fff style C fill:#2d3748,stroke:#9a4eed,color:#fff style D fill:#2d3748,stroke:#4aed5c,color:#fff 阶段 1: 注入（Injection）—— 考试桌上的教科书 在会话开始时，AI 代理会准备好其初始上下文。这不是随意拼凑的，而是一个明确的结构： ...

一个 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。他们所做的是使用 bun build --compile 将其打包为可执行文件。 bun build --compile 是如何工作的 这个神奇的命令是： 1 bun build ./src/index.ts --compile --outfile claude 它具体做了什么？三件事： 1. 打包 首先，Bun 充当打包器。它获取你的入口文件（index.ts），解析所有的 import，并生成一个包含所有代码串联的单一 JavaScript 文件。包括你的 node_modules 依赖，解决tree-shaking以消除死代码，并压缩结果。 ...

10GB的意外发现 你在Mac上安装了Claude Desktop。一切正常，应用程序看起来很小。但有一天你查看磁盘空间，发现了这个： ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle 10.8 GB。 什么？一个聊天机器人要占用十个G？这里面装的什么，《指环王》三部曲加长版？ 不是。装的是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日发布的智能体名称。它的官方标语是： “Claude Code for the rest of your work”（为你其他工作准备的Claude Code） 虽然Claude Code是为生活在终端里的开发者设计的，但Cowork是为你不编程时设计的。想要整理合同的律师。需要从50个PDF中提取数据的分析师。想要把笔记转换成演示文稿的教师。 它能做什么 你授予它访问Mac上某个文件夹的权限 Claude在该文件夹内读取、编辑和创建文件 可以创建Office文档（Word、Excel、PowerPoint），无需你安装任何软件 如果需要，可以执行Python或JavaScript代码 可以并行启动多个"子智能体"处理繁重任务 实际例子 “嘿Claude，我在这个文件夹里有30张收据截图。给我做一个包含每张收据日期、概念和金额的电子表格。” Claude就会去做。读取图像，用OCR提取数据，创建Excel文件，然后放在那里给你。 有趣的事实 Cowork几乎完全由Claude Code在1.5周内构建完成。Claude在编写下一代Claude产品。《盗梦空间》但是少了迪卡普里奥多了tokens。 虚拟机：安全技巧 这就是精妙之处。当Cowork执行代码或操作文件时，它不是直接在你的Mac上做的。而是在一个完全隔离的Ubuntu虚拟机内完成。 为什么？因为让AI在你的系统上执行任意代码就像把你家钥匙给一个很聪明的陌生人。他们可能值得信任，但最好不要让他们接触刀具抽屉。 这10GB里有什么 组件 大小 用途 Ubuntu 24.04 ~3 GB 操作系统 Chromium + Playwright ~920 MB 用于爬虫和网页自动化 LibreOffice ~148 MB 创建Office文档 Node.js, Python, Java ~600 MB 执行代码 CJK字体 ~305 MB 中文/日文/韩文支持 Pandoc, LaTeX ~450 MB 文档转换 用通俗的话说：这是一个装在安全盒子里的完整办公环境。 ...

犯罪现场 萨拉戈萨，皮拉尔广场酒店的咖啡厅。一杯拿铁，望向大教堂的景色，还有我带着全新的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加速、连字或任何现代功能的终端。 1 2 # 打开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菜单中） ...