Cli

我有一个代码代理——Claude Code，每月与我的问题跟踪工具Linear交互大约800次：列出任务、创建问题、更改状态、发表评论。我检查了其中165次会话，并统计出了超过500个错误和超过370次重试。 这些错误没有一个是Linear的API故障引起的，全部都是接口错误：代理与命令行通信，但命令行无法理解。 保守估计，每月大约浪费了70万个token仅仅是与工具“斗争”：重试、读取错误信息、纠正再尝试。这种无形的成本不会出现在任何账单中，但却存在于每次会话中。 背景：代理现在是主要用户 命令行工具（CLI）——从历史上看，是为人类设计的。而人类用户是非常灵活的。如果一个命令失败了，他们会通过 --help 查看帮助。如果错误信息很难理解，他们会去查阅文档。如果该工具有某些特性，他们会记住并避免再犯同样的错误。 而AI代理基本不会这么做。它在不同会话之间不会积累经验，也不会投入太多精力去阅读文档。当某些操作失败时，它也不会深入分析问题所在，而是根据认为最有可能的方式尝试再次执行。 这改变了你的工具客户是谁的定义。如果代理每月调用该工具800次，而你手动使用它只有三次，那么这个接口的主要使用者就是代理。为了人类用户设计工具并期待代理能适应，这是在为次要用户优化。 为这个主要用户专门设计有一个名字：智能代理体验（agentic experience）。它之于代理，正如用户体验（UX）之于人类用户，开发者体验（DX）之于API的开发者。更重要的是，一种最有效的测量工具早已存在——代理的错误日志。 错误有其规律 我将所有以非零退出代码结束的CLI调用定义为错误。根据这一标准，这500多个错误并非随机发生：几乎全部集中在三个模式中。 错误模式 代理行为 设计暴露的问题 虚构的标志 输入 --status 而非 --state；--priority urgent 而非 --priority 1 真正的标志不是人们会优先猜到的名称 缺少的操作过程 尝试搜索文本、按项目筛选或在创建时分配项目：CLI不具备这些功能 工具未涉及实际的工作流程 忘记必要的标志 忽略 --sort，--no-pager，--no-interactive 要求人工决策，而工具本可以自动处理 当代理输入 --status 时，它并非胡乱猜测，而是在推测出最可能的接口名称。--status 和 --state 都非常合理。而我设计的CLI并未与这种直觉一致。 还有一个问题没有反映在统计数据中，因为它不会导致命令失败：冗长的输出。CLI以JSON格式返回列表，每个问题大约50个token。如果命令成功返回（退出代码为零），这类问题就不会被统计为错误；但长列表和每月800次调用叠加起来，这就是那70万个token成本的另一半。这种成本往往被忽视，因为不会妨碍任务完成。 重新审视错误 容易的解释是直接了当的：代理在错误使用工具。这是错误的解释，应逐一反驳。 虚构的标志表明真正的标志名称不够直观。忘记的必要标志表明这些标志完全不应该是必要项：如果工具可以推测出合理的默认值，那么强制要求填写这些标志只会额外增加使用者的工作量。一段没有用的输出或者产生过多token意味着选错了应对的输出格式。 代理的错误日志不是错误列表，而是一个规范: 每个错误都“否定性”地描述了你原本该如何设计接口。而这个规范是你最真实的反馈：无需代价，无数的真实数据，且没有人为善意隐藏工具缺陷。一个人类用户遇到糟糕的CLI时，可能会保持沉默并自动适应它。但代理不会适应：它会一遍又一遍地犯同样的错误，并记录下每一次。 这与我在另一篇文章中提出的一个原则有关：不应允许错误路径存在，而非仅仅禁止其使用。禁止只是一种文档说明——“不要使用--status“——而文档取决于是否有人认真阅读。让错误变得不可能，是设计的职责。 因此，解决方案并非更好的文档，而是更好的工具。 重设计 我围绕这个原则重写了CLI，工具叫做lql。以下四个设计决策贯穿整个改进过程。 宽容优于拒绝。 如果代理输入了 --status，工具会将其接受为 --state 的别名并继续运行。如果输入了 --priority urgent，将其解析为 --priority 1 并说明假定的结果。最常见的“错误”路径直接被转变为正确路径。工具不会因为合理的猜测而惩罚用户，而是直接适应它。 通过错误信息指导正确方向。 当某个功能确实不存在时，错误信息不会简单地说 unknown flag，而是给出具体指导：--filter 不存在。要按状态筛选，请使用：--state <状态>。要搜索，请使用：lql search "文本"。 错误消息本身变成了文档，并且恰好呈现在用户最专注的时间点：他们刚刚失败时。 取消所有强制标志。 lql list 无需提供任何参数即可运行：默认按优先级排序，筛选出活跃状态，并根据工作目录自动检测团队。因为不存在 --sort 参数，自然也就没有遗漏它的可能性。一个代理无法忘记不存在的标志。 ...

你向你的AI副驾驶要求捕获一个窗口。副驾驶写下peek app "Xcode"。工具尝试寻找一个精确名称为Xcode的窗口，但没有找到，因为实际的进程名是Xcode-16.3。工具打印出Error: application not found。这位情感记忆如金鱼般的副驾驶尝试peek app "Xcode-16.3"，成功了。但浪费了一次对话轮次、输入和输出的令牌，还有支付账单的用户的耐心。 现在想象另一种场景：副驾驶写下peek app xcode。工具会自动标准化名称，进行模糊匹配，找到Xcode-16.3，捕获窗口，并返回/tmp/peek/Xcode-16.3-1712524800.png。一个输出令牌。零次无效尝试。 这两种情况的差别不是一个bug，而是一个设计决策。 那些不会看你--help的用户 2025年初，Netlify的CEO Mathias Biilmann创造了术语“智能代理体验”（Agent Experience，即AX），用来描述AI代理在与一款产品互动时所拥有的体验。正如用户体验（UX）关注的是人类用户，开发者体验（DX）面向的是开发者，智能代理体验（AX）则专注于LLM。 这个概念听起来很抽象，直到你把它应用到某些具体的东西上。例如，命令行工具（CLI）。CLI已有40年的历史，其设计一直是为了与人类用户交互：描述性的信息、颜色、高度可视化的进度条以及--help页面。这些对于LLM来说全是“噪音”。一个LLM不会查看帮助信息——它会根据命令名称推断出标志。它不会欣赏绿色的“成功”提示——它只处理纯文本。它也不会观察进度条——它只等待过程完成。 传统CLI的设计旨在让人类用户理解发生了什么，而AX则优化CLI工具，以便智能代理能用最少的令牌和轮次来完成操作。 五项原则，三款工具 在过去的几个月里，我创建了三款秉持同一理念的CLI工具：peek（用于macOS窗口捕获）、lql（用于Linear问题管理）和driftkit（用于智能代理的行为审核工具）。它们都设计成即使没有说明文档，LLM也可以使用。从这些经验中总结出了五项原则。 1. 输出是契约，不是对话 传统的CLI用于窗口捕获时可能会输出类似以下的信息： ✅ Screenshot saved successfully! File: /tmp/peek/Xcode-1712524800.png Size: 1920x1080 Format: PNG 这看起来很漂亮，也很有信息量。但对于需要将路径传递到另一工具的LLM来说完全没用。它不得不解析这个输出，忽略掉表情符号，找到以File:开头的那行，并提取路径。浪费了令牌。 peek只输出一个内容： /tmp/peek/Xcode-1712524800.png 一个路径，没有其他多余信息。LLM直接读取、使用并继续。stdout的输出是一种契约：始终是一个容易解析的路径，始终保持稳定。如果更改格式，就破坏了契约，也会让所有依赖该工具的代理出错。 也就是说：你的stdout是API，而不是用来“装饰”的。 2. 容忍幻觉——不要惩罚它们 LLM会产生幻觉命名。这是一种自然现象，就像地心引力或wifi总是在你赶时间时信号变差。如果你的工具需要准确名称，那就是在向一种基于概率的机器要求精确。这是行不通的。 peek有三种搜索模式以找到应用程序： 精确匹配（不区分大小写）：xcode → Xcode 标准化匹配（去除空格和短横线）：thinklocal → ThinkLocal 部分匹配：xcode → Xcode-16.3 LLM并不需要知道进程的确切名称。它只需给出一个大致的名字，工具会处理剩下的事情。lql也采取类似的方法来匹配项目和团队的名字——它会根据部分内容将tokamak解析为Tokamak，而无需使用UUID。 原则很简单：如果监督代理的那个人类能够推测出它的意思，那么工具也应该能够做到。 3. 错误信息应该告诉用户怎么做，而不是发生了什么 对比一下以下两个错误消息： Error: application not found in window list Error: "Xcode" is not running. Start it with: open -a "Xcode" 第一个描述了问题所在。第二个则提供了解决问题的方法。人类读了第一个会想“哦，没打开啊。”LLM读到第一个后会……用其他名字试试，或者去Google搜索，又或者发明一个--force标志。而对于第二个，LLM会直接执行open -a "Xcode"，等待，然后再试一次。问题在一个轮次内得以解决。 ...

TL;DR：如果你在使用Codex，command（命令） 用于控制会话或应用程序，而skill（技能） 用于教代理一种工作方法。在Claude Code中，目前的文档已经将技能视为可以用/skill-name直接调用的东西，所以这两种概念在Claude Code中更为融合。但在Codex中恰恰相反：types可以作为技能存在，但/types却可能不存在。 当你从Claude Code切换到Codex时，这种混淆非常常见。而且可以理解。 你创建了一个名为types的技能，回到终端时满怀信心地输入/types……然后Codex看着你，就像你在五金店里要了一杯拉格啤酒。 问题不是技能坏掉了。问题在于，在Codex中，技能和命令并不是一回事。 请注意，这种差异并非表面上的不同，它会彻底改变你设计工作流的方式。 一个让你秒懂的类比 想象一下，Codex就像是一架有两层结构的飞机。 第一层是驾驶舱：按钮、杠杆、指示器。这是命令的栖息地，用于改变会话、客户端或工具的状态，这是操作控制。 第二层是副驾驶手册：流程、标准、检查清单、避免陷阱的指南。这是技能的领域，用于改变代理思考和执行任务的方式。 通俗地讲： 命令是动驾驶舱里的按钮。 技能是改副驾驶脑中的手册。 如果你把手册当成按钮来用，那肯定行不通。 什么是Codex中的命令 在Codex中，命令有两种形式，千万别搞混。 第一种是CLI命令： codex login codex exec "run tests and fix failures" codex resume --last codex apply --- 这很直接明了。这些是应用程序的操作：登录、运行任务、恢复会话、应用变更。如果明天系统中没有了模型，这些命令依然有意义。 第二种是**交互式会话中的斜杠命令**： ```text /model /permissions /personality /agent /status 它们也并非是“华丽的提示语”。它们控制的是实时的会话：更改模型、调整权限、切换人物风格、设定活动线程或改变可见状态。这些就像驾驶舱中的控制按钮。 OpenAI事实上非常清晰地记录了它们的用途：一方面，有专门的斜杠命令页面用于“在交互会话中控制Codex”的说明；另一方面，另有一份独立的技能页面，将技能定义为可重用工作流的创建格式。 这也是为什么有些操作会成为命令而不是技能：因为它们需要可预测性、即时响应和稳定语义。你不希望模型“有创意地解释”/permissions的含义。你只希望它直接更改权限。就这么简单。 什么是Codex中的技能 Codex中的技能是完全不同的东西。它就是一个可重用的工作流，用来教给代理何时运用某种方法、如何思考某个任务并按照特定步骤操作。 这里还有一个细微但重要的区别：OpenAI表示，skill是一种编写格式，而**plugin（插件）**是可安装或分发的单元。换句话说，你会先将工作流设计为技能；如果需要分享或进行封装，就可以把它打包成插件。 明确的例子： $types $improve $owasp $blog 或者，如果更偏语言化： 使用types来审计这个代码仓库 使用improve来检查这个diff 你在这些例子里并不是叫Codex去“切换设置”。你是在告诉它，“当我让你执行这项任务时，请按照这套剧本来操作”。 以我的types技能为例，它不应该是个按钮。它的工作是读取项目代码、检测语言、检查模型、寻找“字符串类型化的代码”、判断一个Optional的使用是否合理并是否能正确建模域状态。这需要背景和判断能力，正是技能擅长的工作。 同理，improve作为一个技能也讲得通：检查diff并不是什么机械性的操作，反而涉及到判断、上下文和优先级的权衡。 为什么在Claude Code中“看起来像是一样的” 这里就是认知的陷阱了。 最新的Claude Code文档对这一点已经毫不避讳了。它谈到技能时，会告诉你可以通过以下方式直接调用： /skill-name 也就是说，在Claude Code中，你认为的某些属于“可重用工作流”的东西是通过斜杠命令语法来调用的。用户体验上，它将Codex中分离的两个概念合并了： ...

TL;DR：一个LLM就像堂吉诃德——你无法修复它，它天生就是随机的。解决方案不是修复疯子，而是给他配一个确定性的桑乔潘萨。MDD有两个层次：首先研究其可能犯的错误类型，从而设计出能够吸收这些错误的工具；然后把它放入工具中验证是否还有漏洞。为疯狂设计，而不是对抗疯狂。 我已经在审查日志好几周了。165次AI代理与CLI交互的会话，总共产生了500多个错误和370次重试。一些模式一次次重复出现：代理使用了--status，而正确的参数名应该是--state。它写了Todo，而API期望的是unstarted。它传递urgent作为优先级，而系统只接受数字。 而有趣的是，每个错误都“看起来有道理”。这些并不是随机的错误。它们是合理的错误。就像是你对一个领域有些许了解，但从来没有细读文档时所可能犯下的错误。 某个时刻，当我盯着第十次出现的--status Done（实际上应该是--state completed）时，我意识到这些错误在文学上来说有一个对应的模式。一个有着400年历史的模式。 堂吉诃德就是一个LLM 想象一下。堂吉诃德看到风车，说“是巨人”。他不是笨——他很有文化、书读得多，对骑士小说了如指掌。问题在于，他的世界模型被带有虚假数据的训练集污染了。他读了太多的骑士小说，所以当他看到某些模糊的东西时，就根据他的训练数据来进行解读。风车→巨人。羊群→军队。客栈→城堡。 一个LLM（大语言模型）做的事情和堂吉诃德一模一样。它在训练过程中见了成千上万的API。当你要求它使用一个它不太熟悉的API时，它不会说“我不知道”。它会猜测。而且常常猜得很接近足以让你信任，但偶尔猜错时，它的错误也是合理的。 --status而不是--state。因为在它见过的60%的CLI中，参数名确实是--status。 Todo而不是unstarted。因为在工具的图形界面中，有一列名称就是“Todo”。LLM从文档中看了截图、读了博客，因此它推断如果UI写了“Todo”，那么API一定接受这个值。这听起来合情合理，但却是错的。 urgent而不是1。因为在多数优先级系统中，urgent确实是一个常见的有效值。谁会设计一个优先级必须用1到4的数字，而不能用标签表示的API呢？ 每一次“幻觉”都是基于不完整数据的合理推断。堂吉诃德并不笨。他只是疯了。而一个疯子是无法被治愈的。 塞万提斯早就明白了 塞万提斯没有试图“治愈”堂吉诃德。他做的，是让桑乔潘萨陪着他。 桑乔并不聪明。他没读过书。他没有伟大的幻想。但他是确定性的。当堂吉诃德说道“瞧那些巨人”，桑乔会回答：“老爷，那是风车。”堂吉诃德不一定会听他的，但信息已经传递了。这个系统有两个层次：一个随机的层次生成假设（堂吉诃德），另一个确定的层次与现实进行对比（桑乔）。 当你和一个LLM一起工作时，这就是你需要的架构。你无法让它停止做梦，因为这就是它的天性。但你可以嵌入确定性的层次来捕捉这些幻觉，以便防止灾难发生。 这就是MDD方法大显身手的地方。 MDD: 疯狂驱动设计 MDD有两层架构，而顺序很重要。 第一层：先验考古学 在写第一行代码之前，需要研究“疯癫”。不要凭空猜测——要观察。你需要收集LLM与现有工具交互过程中的数据，并为这些错误分类整理。 以我的项目为例，我分析了165次会话，过程中AI代理使用了一个CLI来管理开发团队的任务。以下是数据统计： 错误类别 出现次数 触发的重试次数 虚构或无效的参数 275 ~150 JSON/GraphQL转义失败 25 80+ 名称混淆 40+ 50+ CLI无法完成的操作 60+ 90+ 浪费token的冗余输出 N/A N/A 基于这些数据，你设计一个能够“吸收”错误而不是拒绝它们的新工具。用通俗易懂的话来说：理性的人适应疯狂的人，而不是反过来。 下面是一些具体的吸收设计示例： LLM错误 → 工具设计 ───────────────────────────────────────── --status Done → --status是--state的别名， “Done”将被标准化为“completed” --priority urgent → “urgent”被标准化为1， “high”→2，“medium”→3，“low”→4 --no-pager → 安静地忽略此参数 （工具从不使用pager） 描述中引号转义失败 → 通过文件或stdin传递输入 永远不会内联，交给Serde处理 表中的每项设计决策都来源于真实观察到的错误，而不是关于“可能会出错什么”的猜测。 这种设计方法与传统方法有微妙但重要的区别。传统设计定义出一个正确的接口，然后拒绝一切不符合它的输入。而MDD则是定义出一个正确的接口，并_额外_定义所有用户可能尝试的错误用法，然后吸收这些错误。 就像设计一扇门，既能推也能拉着开。正确的门只会往一个方向开。好用的门却能够双向操作，因为你观察到40%的人在看到门时会向相反方向推/拉。 第二层：后验验证 在完成了第一层后，你需要将其投入使用，交给LLM试用，并观察它在有新工具时会产生哪些新错误。 ...

TL;DR: 当你的主要消费者是LLM时，XML和JSON因在每个元素中重复结构而浪费token。一个紧凑的定位格式能够将使用量减少50%。结果发现这种想法早已有了名字：TOON（面向Token的对象标记法）。同样的选择压力——有限的token和重复的键值——导向了同样的解决方案。 Anthropic几乎所有东西都用XML。他们的_system prompts_被包裹在<instructions>标签中，示例在<example>标签中，工具列在<function>标签中。如果你在用Claude，就会发现自己到处都是标签。 于是当我让Claude为一个专为LLM设计的CLI输出格式时，显而易见的诱惑是：XML。既然模型以XML形式接收信息，CLI不给它返回XML难道不是更顺理成章吗？ 但实际上，这并非最佳选择。 问题：强迫症般的重复 想象一下，你的CLI正在列出一个项目跟踪器中的任务。假设你有50个任务。在XML中，每个任务会是这样的： <issue> <id>PROD-587</id> <state>Backlog</state> <labels>backend</labels> <title>从NAS备份中导入会话</title> <age_days>14</age_days> </issue> --- 看起来很美观，也很自描述。每个字段都有名字，一个XML解析器可以准确识别出每个字段的含义。 现在，把它乘以50个任务。`<issue>`、`<id>`、`<state>`、`<labels>`、`<title>`、`<age_days>`这些标签将被**重复50次**。它们没有提供任何新的信息，仅仅在浪费空间。大约每个任务需要70个token，列出50个任务需要约3,500个token。 JSON稍微好一点（去掉了闭合标签），但仍重复键值： ```json { "id": "PROD-587", "state": "Backlog", "labels": ["backend"], "title": "从NAS备份中导入会话", "age_days": 14 } 每行都重复"id":、"state":等键值。每个任务约需50个token，总计2,500个token。 如果我们去掉这些重复会怎样？ PROD-587 [Backlog] backend — 从NAS备份中导入会话 (14d) 25个token。没有键值、没有标签、没有大括号或引号。50个任务只需1,250个token。 请注意这一点：相比JSON减少了一半，比XML减少了三分之二。目的却完全相同。 “但LLM需要结构” 这时很多人会怀疑：“那LLM怎么知道每个字段代表什么呢？” 这是一个合理的问题，而我的回答是：就像你知道的一样。 看看这行内容： PROD-587 [Backlog] backend — 从NAS备份中导入会话 (14d) 你需要别人告诉你PROD-587是ID吗？需要解释[Backlog]是状态吗？需要说明长横杠后的内容是标题吗？不需要。你通过位置和视觉格式就可以推断出来。 LLM做的事情完全一样。它们是一种识别文本模式的机器。一个一致的、定位明确的格式——ID放在第一、状态放在括号里、标签列在标题之前——对它们而言是直观的。不需要<state>Backlog</state>这种标签说明“Backlog”是个状态。 关键在于区分两种看似相似但完全不同的操作： 阅读是LLM的工作。它有上下文，理解语义，可以推断结构。就像一个人在浏览报告时不需要每个词都用标签标注——位置和惯例已经足够。 解析是程序的工作。它没有上下文，不理解语义，需要显式的分隔符来提取字段。jq '.state'需要"state"这样的键值因为它不知道什么是状态。 XML和JSON是为“解析”而设计的。它们是机器之间交流的格式，它们不“理解”内容。而LLM是“阅读”的。显式结构对它们来说是冗余的，这种冗余却消耗了额外的token。 格式选择：什么时候用什么 我并不是说XML和JSON不好。但它们并不适合这一情境。简单来说，用表格展示： 格式 每个任务的token数 自描述性 最适合 XML ~70 完全 SOAP API、配置文件、有schema的文档 JSON ~50 完全 REST API、服务间数据交换 JSONL ~50 完全 脚本、jq工具、数据流水线 定位式格式 ~25 否 LLM、人类、紧凑信息面板 规则简单：如果消费者能够理解上下文（人类、LLM），就可以省去显式结构。如果消费者无法理解上下文（脚本、解析器），才需要明确的键值。 ...

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可以在毫秒级速度返回正确的路径。无需探索，无需猜测。 ...

安装 Codex CLI 后，满怀期待地启动它。你告诉它“修复这个代码库中失败的测试”。然而，灾难随即开始： Codex: I want to run pytest Allow? (y/n) 你输入了 y。接下来： Codex: I want to modify test_user.py Allow? (y/n) 又输入了 y 。一次又一次，每次需要读取一个文件、执行一个命令或者修改一行代码，它都会请求确认。确认，确认，还是确认。这感觉就像跟一个刚入门的实习生合作，他每次连去洗个手间都要问你同不同意。 与此同时，Claude Code 或 Cursor Agent 却可以实现相同的功能，但却不会多说一句话。这是为什么？ 原因在于：默认情况下，Codex 被配置为一个“过于谨慎”的助手。这么做是为了安全考虑，尤其是针对一款新产品来说是很合理的。但如果你对操作足够了解，这种保守模式在实际工作中将让人无法忍受。 好消息是：只需几秒钟便能调整过来。 权限模式：approval mode Codex 使用一种叫做 approval mode（批准模式）的概念来控制需要你授权的情境。默认设置下，它对所有操作都需要你的确认： 执行命令 写入文件 修改代码 创建新文件 运行测试 简单来说：默认状态下，Codex 无法在没有你按下 y 键的情况下做任何事情。可以将其形容为：对每一个操作都需要一次 sudo 操作。 这使得一个本应是自主代理的工具，变成了一场你成为整个过程中最慢环节的无休止对话。 解决方案：使用一个标志 codex --full-auto 从版本 0.1.2 起，--full-auto 是官方的快捷方式，它将 --approval-mode never 和 --sandbox workspace-write 两个参数组合在一起。如果你使用的是旧版本，也可以用完整写法： codex --approval-mode never 无论选择哪种方法，Codex 都会停止询问你，直接执行命令、修改文件、创建需要的内容。它将真正成为一个自主工作的代理。 ...

2004年，劳伦斯·莱西格（Lawrence Lessig）给他的所有联系人发了一封群发邮件，大意是：“抱歉，我把你们所有的邮件都删了。如果有什么重要的事情，请再发一次。” 当时，他已经花了整整80个小时清空从2002年积累下来的收件箱。他每天收到200封邮件。 莱西格并不是个不善管理的人——他是斯坦福大学法律学院的教授。然而，即便如此，他仍然败给了电子邮件。 我至少宣布过三次邮件破产。第一次让我感到如释重负。第二次让我觉得自己很狼狈。第三次让我意识到问题根本不在我自己。 电子邮件是一个任何人都可以填满的收件箱 好好想想。你的收件箱是一个地球上任何人都可以随意修改的任务列表。你的老板、你的银行、你四年前在某次会议上认识的一个人、你醉酒时订阅的某个电子邮件新闻简报，还有Jira的一个机器人提醒你某人刚刚把一个任务从“待处理”挪到了“进行中”。 所有人都可以往你的任务列表里塞东西。没有人会问你是否有时间。 就好像你把家门敞开，门口挂个牌子写着“想让我干什么就放这儿吧”。然后你还会惊讶地发现门口堆满了包裹。 被过度滥用的工具 电子邮件的发明初衷是用来传递消息的。一条消息。从一个点到另一个点。就像信件，只是更快罢了。到这一步，一切都好。 但问题是，人类把它变成了什么： 电子邮件本来的用途 我们把它变成了什么 一个消息传递系统 一个任务列表 异步通信 “你有没有看到我5分钟前发给你的邮件？” 点对点沟通 抄送47个人，“以防万一” 纯文本邮件 带有追踪像素和动态GIF的HTML邮件 沟通工具 CRM、文件管理器和法律档案库的集合 用通俗点的话说：我们拿了一把锤子，却把它当成螺丝刀、黄油刀和开瓶器来用。然后又抱怨它的把手坏了。 混乱的数字 加州大学尔湾分校的一项研究发现，我们在被严重打扰后需要花23分钟15秒才能重新集中注意力。而普通员工平均每小时检查电子邮件36次。也就是说，每小时就可能有36次干扰。 算一算账：如果你每次查看电子邮件都会损失2分钟的工作状态转换时间，那你每天仅仅因为查看新邮件，就可能浪费超过1小时。不是为了阅读邮件，也不是为了回复邮件，仅仅是切换注意力。 这就像是每100米就突然猛转方向盘。这确实可以前进，但却是耗费了双倍的油，同时精疲力尽。 邮件破产行不通（你也知道） 每次我宣布电子邮件破产时，循环总是一样的： 第一周： 收件箱变为空，无比平静，精神得以解脱。“这次我一定行。” 第二周： 收件箱里有47封未读邮件。“我一会儿再看。” 第三周： 收件箱有200封邮件。一些很重要。我开始眯着眼扫主题。 第四周： 500封邮件。我已经不知道哪些看过哪些没看。焦虑突升。 第三个月： 又宣布破产。 问题不是你不够有条理。问题在于，把电子邮件当作任务管理和提醒系统是结构性地站不住脚的。这个系统既没有优先级，也没有截止日期，更没有状态变化。它无法区分“有空再看”和“今天不回复你就丢了大单”。 一切内容都会以相同的形式，通过同一个入口，排成一条以“最近有人联系你”为顺序的无限列表。这不是什么生产力系统。这是一个时间消耗的垃圾场。 更好的解决方案并不是更好地管理 email 我尝试过各种方法。Gmail的过滤器。像地铁线路图一样的颜色编码标签。邮件“稍后提醒”。文件夹命名为“今天要回复”“这一周要处理”“闲时阅读”（剧透一下：所谓的“闲时”从来不会来）。我还用过FollowUpThen，你可以把一封邮件转发到3days@followupthen.com，然后它会在3天后把邮件发回你的收件箱。 你知道用FollowUpThen后会发生什么吗？那就是：现在你的收件箱里不仅有原始邮件，还有提醒邮件。解决邮件过量问题的方法，反而制造了更多邮件。这就像想用汽油灭火一样。 真正的解决方法是：将提醒和跟进行动从邮件里完全分离出来。 没有模棱两可，只能彻底剥离。 Memento：虽无趣却有效的解决方法 我的第一个解决方案叫做Memento。它不是一个带漂亮界面和订阅计划的应用程序。它是一个只有120行代码的Python脚本，用来查询Linear（我的任务管理工具），告诉我有哪些事项超出了截止日期。 # GraphQL 查询：筛选出过期但未完成或取消的任务 issues(filter: { dueDate: { lte: "2026-03-11" }, state: { type: { nin: ["completed", "canceled"] } } }) --- 就是这样了。一段简单的查询字符串：**“有哪些我本该做但却没做的事情？”** 我用终端运行这个命令来查看： ```bash uv run memento 然后就会显示类似这样的内容： ...