生产力

在每个使用编程智能助手的开发者生命中，总有一个时刻，你盯着月结账单看，心想：“这些服务确实很好用，可我的订阅怎么比小区健身房的会员费还多？” 那个时刻就这样悄然降临了。当时我同时订阅了Claude Max 5、Codex Plus，还在考虑加上Z.AI配合OpenCode处理廉价的机械性工作。理论看上去很美好。问题出在这样搞下去，就像一个管理乱糟糟工地的包工头，工人各忙各的，却没人看图纸。 我的初步想法很简单：在自动化分流之前，最好先手动做个小实验，持续两周。规则简单，但明确。 问题不在于成本，而在于协调 分开来看，支付23欧元、90欧元或者10美元一点也不算多。 问题在于，当每个工具开始互相干扰时，就开始麻烦了。你让一个助手思考，另一个实现，再让第一个检查，最后还要麻烦第三个处理一些琐事。二十分钟后，你已经搞不清楚是在优化成本、提升质量，还是单纯地折腾自己不停切换窗口了。 用大白话说：真正的成本不仅仅是订阅费，还有你的上下文切换成本。 就像一个厨房里同时有一把日本刀、一台智能厨师机、和一个空气炸锅。它们各有用处，各有千秋。但如果你用厨师机来炸土豆，那肯定不行。 假设：思考、执行、清理 我想要试验的规则说起来不过三句话： 用Claude进行思考 用Codex完成主要实现 用GLM/Z.AI处理基础任务 这不是学术讨论，而是一条实用的工作坊规则。 当一项任务模糊不清、涉及架构、存在风险或者需要判断时，把它交给擅长推理的代理是最合逻辑的选择。在这个实验中，就是Claude。 而当一项任务已经很明确，需要进入代码库、修改文件、运行测试并在错误间反复调试时，就轮到Codex登场。 至于那些没有人愿意干但必须有人去完成的工作，比如简单的测试代码、文档编写、小脚本处理、文件重命名或机械化的代码重构，那么就让GLM+OpenCode来试试。 暂不考虑的事情 目前还不考虑设置一个自动化分流器。 我不打算弄一个能自动读取提示词、分类任务、选择代理、按时间切换模型，还能输出漂亮图表证明其复杂性的魔法中介层。 这听起来或许是个超级有趣的项目，但也可能事倍功半。 这里最常见的错误是在真正需要航管之前就急着建塔台。先观察好了，再决定是否需要设置交通信号灯。 手动操作的两周实验 我的实验相当朴实，够不上“炫技”，但大概率更有用。 1. 用Claude处理复杂任务 当以下情况之一发生时，我会优先用Claude： 我不确定怎么入手 需要设计决策 存在破坏性风险 需要审查逻辑或论证，而不仅仅是代码 翻译成人话：如果任务需要准确判断，我不会吝啬。 2. 用Codex主导代码库工作 当任务已经清晰时，我会用Codex处理： 实现真实的功能修改 修复测试 带验证的重构 反复迭代，直到项目重新回到稳定状态 在这个阶段，一个好的执行代理最能展现价值。这不是模型本身的问题，而是流程的问题。 3. 用Z.AI负责简单工作 对于Z.AI，规则很简单： 模板代码 初稿 文档 简单的测试 小型脚本 文件重命名 容易检查的机械性操作 即使失败了，也没关系。可以随时丢弃，然后换成别的工具重做。 这才是关键。我不会向GLM要求飞针走线般的精细活，我的目标只是拧几颗螺丝。 最重要的规则：失败两次便升级 这一点是最重要的，但也最容易被忽视。 当一个便宜的工具失败了，你可能会倾向于继续试，“再试一次就好”，“这次应该可以”，“我改下提示词试试”，“再加点上下文”。半个小时过去了，你还在像与“抓狂的打印机”讨价还价一样调整模型。 我的规则是： 如果Z.AI1到2次尝试后仍失败，那我就提升它 如果是执行问题，转交Codex 如果是理解或设计问题，转给Claude 低成本工具一旦浪费掉太多时间，就不再低成本。 我要真正关注的是什么 我对“表演式性能对比”没兴趣。 不会去费劲列出诸如每秒处理字节数、平均延迟这类看起来“很专业”的表格，毕竟我的主要问题还是怎么快速重命名40个符号，而不是花一下午来折腾。 但我要在这两周内统计以下内容： 指标 意义 Z.AI吸收的简单任务数量 它是不是真的帮我减少负担 我有多少次需要提升任务 节省的时间和金钱是否值得 减少的Codex使用量 整体思路是否划算 切换工具的总耗时和难度 系统是否够流畅，易于长期使用 如果实验成功，那再好不过。 ...

TL;DR: 在165次Claude Code会话和27次Codex CLI会话后，我发现了一个清晰的模式：早上使用Claude来处理需要头脑风暴的互动型任务，下午让Codex完成可自动执行的具体任务。这不是哪个更好的问题，而是何时使用哪一个的问题。数据显示，两者结合远胜于单独使用任何一个。 早上九点，手握一杯咖啡，我脑中只有一个模糊的点子，准备重新构建一个模块。我不知道确切该怎么做，只是确信当前的模式并不理想。 于是我启动了Claude Code。 并不是因为它是“最好的”选择——而是因为我需要一种“自言自语”的方式，一个能理解上下文的助手。我告诉Claude：“这个服务的职责太多了，帮我拆分它。”随即，一场对话开始了。它提出一种分离方案，我讨论修改它，我让它探索另一种可能性，它在动手之前还会展示diff。这是一种协作的过程。 三个小时后，模块被成功拆分，测试通过，设计也有所改进。但这是我的Claude配额的40%。而我还列了一堆机械性任务，比如更新集成测试、清理无用的import、重整目录结构。 然后我打开了Codex。 我给它任务，设置为全自动模式，然后悠闲地去吃午饭。 数据揭示的模式 几个月来，我使用一款菜单栏应用监控自己的使用情况，这款工具记录了会话、token用量及耗时。以下是统计数据： Claude Code: 165次会话，160,893条消息，28,052次工具调用。使用模型：Opus 4.5和Opus 4.6。从缓存中读取了56亿token。 Codex CLI: 27次会话。使用模型：GPT-5.4。模式：danger-full-access，审批策略：never。 令我意外的首先是Claude Code的使用时间分布： 09:00 1 ▏ 10:00 5 ██ 11:00 10 ████▌ 12:00 14 ██████▎ 13:00 7 ███ 14:00 16 ███████▏ 15:00 21 █████████▍ 16:00 15 ██████▋ 17:00 18 ████████ 18:00 13 █████▊ 19:00 14 ██████▎ 20:00 9 ████ 21:00 10 ████▌ 22:00 8 ███▌ 我70%的Claude Code会话发生在下午，仅22%在上午。 初看这些数据，我还以为自己“清晨用Claude”的理论行不通。但深入分析每个时间段的任务类型后，一切都渐渐清晰。 上午用于探索，下午用于执行 Claude Code的上午会话少但时长较长。这些会话属于设计阶段：“这部分功能应该如何运作？”、“帮我审阅这个计划”、“能不能提供一些其他选项”。这些是一次又一次的讨论，需要反复修改观点，最终达成决定。 ...

你是否曾经在晚上 11 点写了一个技术计划，确信一切无懈可击，但第二天早上发现忘记添加身份验证？ 我深有同感，而且不止一次。最糟糕的不是这个疏忽——而是当你用人工智能来规划时，计划听起来是如此连贯，以至于你的大脑停止了对问题的挖掘。Claude 会生成一个带有章节、依赖项和执行顺序的文档，一切看起来都是高级工程师的作品。但问题是，没有人反驳过它。 Aseem Shrey 发布了一篇文章，精准点出了这个问题，并为此提出了一个优雅的解决方案：让第二个模型审查第一个模型的计划。而且不仅仅审查一次——循环审查，直到审查员说“通过”。 问题：没有人反对你的 AI 当你仅依靠一个模型来规划和执行时，你得到的结果确实连贯但没有争议。AI 不会反驳自己。它不会说“嘿，这个身份验证模型不完整”，或者“你的 shell 脚本中的引用有问题”。 这就像你自己写了一份文档，自我审查，然后对自己说“这可真是完美”。当然是完美的——毕竟是你自己写的。注意这个点：同行评审会存在于科学、工程和医疗领域是有原因的。并不是因为作者愚蠢，而是因为创作者通常是自己作品最差的审查者。 我以前在写我的 Jedi 代码审查委员会时讨论过这个问题。不过当时谈论的是如何审查代码。而 Aseem 的建议是先审查计划，在写出任何代码之前就发现问题。这相当于提前一阶段处理问题。 操作方法：Claude 规划，Codex 审查 这个过程基于 Claude Code 的一个“技能”实现——一个 Markdown 文件，无需额外的基础设施或外部服务。当你调用 /codex-review 时： Claude 会将计划写入一个临时文件。 计划会以只读模式发送到 Codex CLI（它可以读取你的代码库获取上下文，但不改动任何东西）。 Codex 审查后会给出结论：VERDICT: APPROVED 或 VERDICT: REVISE。 如果返回的是 REVISE，Claude 会修正计划并重新提交。关键在于，Codex 会恢复之前的会话，因此能够记住它之前的反馈，并验证问题是否真的被解决了。 审查最多迭代 5 次。在实践中，通常 3 次就足够了。 简而言之，这是两个 AI 之间的一次“拉取请求”，一个提出计划，另一个专注于找漏洞。全程无需人为干预。 3 轮迭代解决了 14 个漏洞 在 Aseem 的文章中，以一个多代理系统的控制面板为案例，循环审查从原计划中找到了 14 个问题： 第一轮（8 个问题）：写入端点没有身份验证。Shell 脚本的引用存在错误。数据模式的字段冲突。嵌套数组没有限制。未处理并发问题。仅支持手动测试。 第二轮（剩余 6 个问题）：非原子操作的声明。ACL 权限分配过于宽泛。未指定密钥轮换机制。状态建模不一致等问题。 第三轮：所有问题解决，计划获得通过。 ...

想象一下你有一个出色的工作伙伴。他能解决复杂的问题，编写清晰的代码，对你的要求一听就明白。但是，每天下班后，每次你跟他说“打开课程项目”，他都会一脸茫然地看着你，问：“什么课程？在哪里？” 每天如此，毫无例外。 这就像和电影《记忆碎片》（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可以在毫秒级速度返回正确的路径。无需探索，无需猜测。 ...

几周前，我写了一篇关于 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 一团混乱。 ...

安装 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 都会停止询问你，直接执行命令、修改文件、创建需要的内容。它将真正成为一个自主工作的代理。 ...

Claude Code 提供了一个名为 /simplify 的 slash command，可以自动审查你的代码。我用它检查了一个大幅变更——大约 8 个文件、500 行代码——结果让人有些意外。它确实发现了些我可能漏掉的点，但也带来了不少无用信息，让我浪费了不少时间。 所以我把它拆解了，然后又重新像拼图一样组装回来。 /simplify 是如何工作的 这是 Claude Code 内置的一项功能（无需额外安装）。它会并行运行三个代理，分别从三个不同的角度来审查代码变更： 代码复用（Code Reuse） —— 是否有可以替换新代码的现有工具？ 代码质量（Code Quality） —— 冗余状态、复制粘贴、不良抽象、stringly-typed code 等。 效率（Efficiency） —— 不必要的 I/O、未充分利用的并发、内存泄漏等。 这三个代理会各自给出发现的问题，之后系统尝试直接修复它们。 找到的亮点 代码复用代理发现我在测试代码的两处重复了一个完全相同的辅助函数：相同的名字、相同的代码内容，但分布在两个不同的文件中。我把它提取到一个共享模块里，干净利落。 效率代理指出了一个处理循环中不必要的磁盘操作：每次迭代都加载状态、修改后存储、读取数据、重新加载、再存储。写操作重复了两次，而实际上只需要一次。我没注意到这些隐患，但工具发现了。 还发现了一个内存缓冲区在错误路径中没有清除。如果在分配和释放之间发生错误，会产生内存泄漏。这种问题在主路径上已经被处理到了，但显然 copy-paste 草率遗漏了某些细节。 到这里为止，还算满意。三个发现，全都合法且可操作。但 /simplify 的问题并不在于它发现了什么，而是在于它发现了太多不重要的东西。 存在的缺陷 低级别的问题噪音过多。 它建议我删除一个 struct 的字段，因为 “它与一个计算属性是重复的”。这个字段占用 8 个字节，但被代码和测试中的十多处引用使用。做这个改动带来的代码修改工作量，远远超过了省下这几个字节的好处。 缺乏对项目上下文的理解。 它标记了一个并发模式为 HIGH 严重性，并且的确指出这是一个潜在风险。这一点没错，书面上看是合理的。但实际上，这个问题已经在项目的 CLAUDE.md 文档中记录了，工具链中专门配置了 lint 来应对，并且项目内还有一个相关的 issue 在处理。而 /simplify 并不知道这些，因为它只能基于代码变更的 diff 操作，缺乏项目整体的视角。 无法分辨“错误”和“可优化”。 上文提到的双磁盘操作的确效率低下，但并不是错误。而并发模式的问题就是真正的潜在炸弹。这两者的严重性却都被标记为 MEDIUM，优先级看上去一样，这种扁平的优先级划分很难起到实际帮助。 对外部数据强行推荐 enums。 它建议把某些 DTO 中的字段从字符串转换为枚举，但这些字段只是从外部 API 拉取后用于显示。把它们改成枚举需要自定义解码逻辑，却提供不了任何实际好处——如果对方 API 增加了新值，这样的枚举反倒会导致解析出错。枚举在这种情况下，不如保持字符串更稳妥。 ...

几个月来，我一直用自制的 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” ...

我妻子召唤Charlie Munger来规划家庭预算。在ChatGPT里。不是开玩笑。 她会说"像Charlie Munger审查我们家庭财务一样行动"，然后把本月的开支告诉它。这家伙会回复类似"你在教育支出项目上把投资和花费搞混了"或"那个基金有你没有计算的隐性成本"这样的话。这些是Munger会说的话。用Munger会用的语调。 我也做了同样的事。但我没有召唤投资者，而是召唤了一个不同的专家：Edward Tufte。 谁是Edward Tufte（以及为什么你应该关心） Edward Tufte可能是对我们如何可视化数据影响最大的人。他的书《定量信息的视觉显示》（1983年）是那种永远改变你看图表方式的罕见文本之一。40多年来，它一直是全世界大学、新闻编辑部和设计工作室的绝对参考。 他的原则非常简单： 最大化数据-墨水比。 你图表的每个像素都必须传达数据。如果不传达数据，就删掉它。 不要装饰。 网格、3D渐变、阴影、装饰性边框……所有这些都是Tufte称之为图表垃圾的东西。分散数据注意力的视觉垃圾。 让数据自己说话。 如果你需要用200字的图例来解释你的图表，那图表就设计错了。 Tufte还发明了迷你图——那些能放在一行文字内的微型图表。图表不需要标题、坐标轴或图例来交流的想法。只需要数据。 我的图表很糟糕 我正在构建一个macOS菜单栏应用，用来监控我的Claude Max配额。应用的一部分显示一个迷你图——一个小小的线图——显示我消费配额的速度。 我的第一个版本有这些问题： Y轴固定在0到100% — 如果你的使用量在8%，图表就是一条贴在底部的平线。85%的空间什么都不显示。 在80%处有一条阈值线 — 任意的，没人要求，不传达任何有用信息。 显示当前%的浮动标签 — 冗余的：下面的卡片已经显示了确切数字。 “pp/min"作为单位 — 每分钟百分点？连我都不知道这意味着什么。 线下方的渐变填充 — 纯装饰。图表垃圾。 简单说：我在一个56像素高的图表中违反了Tufte的每一个原则。 技术：循环召唤专家 我没有试图自己修复它（显然我对此没有判断力），而是做了不同的事。我让Claude成为Tufte。 提示词： 像Edward Tufte审查这个图表一样行动。 分析VelocityCardView的SwiftUI代码。 识别你数据可视化原则的所有违规之处。 对于每个违规： 1. 违反了什么原则 2. 为什么这是个问题 3. 具体的处方（代码，不是哲学） 要无情。如果某些东西是图表垃圾，就说出来。 用PASS或FAIL评估。 关键是最后部分：PASS或FAIL。因为没有这个，LLM会给你温和的建议，告诉你"总体上还可以”。有了二元判决，它必须承诺。不能躲在"有改进空间"后面。 然后是循环： 应用Tufte的处方。 实施每个改变。 不要停止迭代，直到他给出认可。 四轮直到PASS 我第一轮没通过。第二轮也没有。第三轮也没有。 第1轮 — FAIL（6个处方）： 自适应Y轴而不是固定的0-100 消除80%的阈值线（图表垃圾） 消除浮动标签（与下面的卡片冗余） 用简单词语替换"pp/min"（上升、下降、稳定） 将摘要行折叠为仅时间窗口+趋势 将迷你图高度从44提高到56点 我实施了6个。第二轮。 第2轮 — FAIL（1个处方）： ...

“我们昨天不是已经决定这个了吗？” 我正在将我的邮件从 Google 迁移出来。已经用 Claude Code 工作了两个会话：Linear 中的 issues、做出的决策、执行的脚本。我开始第三个会话，问它"degoogle 还剩什么待办事项？" 沉默。完全失忆。 这就像和一个聪明的同事一起工作，但他每天早上来办公室都完全不记得你们前一天做了什么。不记得决策，不记得错误，不记得发现。每个会话都是一张白纸。 结果有一个文件恰好解决了这个问题。它已经在那里几个月了。而且几乎没人知道。 CLAUDE.md vs MEMORY.md：手册和笔记本 如果你使用 Claude Code，可能已经了解 CLAUDE.md。这是你告诉 AI 如何工作的文件：使用什么语言、你有什么工具、你的代码约定。 CLAUDE.md 是你的指令手册。你编写它，你维护它。 MEMORY.md 是另一回事。它是 AI 自己编写的工作笔记本。它记录在与你合作时学到的东西：犯过的错误、做出的决策、项目模式、尝试过但没有成功的东西。 简单来说： CLAUDE.md MEMORY.md 谁编写 你 AI 包含什么 指令 学习内容 何时更改 当你想要时 每次会话后 类比 规章制度 工作笔记本 如果 CLAUDE.md 是你第一天给实习生的合同，MEMORY.md 就是实习生工作时在笔记本中记录的笔记。 它在哪里 ~/.claude/projects/<目录哈希>/memory/MEMORY.md 每个项目目录都有自己的内存文件。如果你在 ~/code/项目-a 工作，它有一个 MEMORY.md。如果你在 ~/code/项目-b 中打开 Claude Code，它有另一个不同的。它们不会混合。 文件在每个会话开始时自动加载到上下文中。你不需要做任何事情。 没有全局的 MEMORY.md 吗？ 没有。只按项目分类。这是个问题。 今天我创建了一个 op（1Password CLI）的包装器，缓存密钥一小时。这在我所有项目中都有用，不只是我正在工作的那个。但 MEMORY.md 只在那个目录的内存中记录了它。 CLAUDE.md 确实有全局版本（~/.claude/CLAUDE.md），会在所有会话中加载。MEMORY.md 没有对应功能。如果 AI 学到了适用于你整个环境的东西（别名、系统特性、偏好），它必须在每个项目中分别记录。或者不记录。 ...