Posts

“我有一个 shell，我很有创造力。” —— Claude 解释为什么他用一个 47 行的脚本，并作为一个字符串传递给 python -c 来执行 这句话是真的。我开发的 AI 代理说过——好吧，不是用确切的这些话，但他的行为证实了。他需要启动一个 ETL pipeline 的某个进程。虽然正确的启动命令写在了 Makefile 里，但出了点问题。而他呢？他并没有询问，而是做了任何拥有 root 权限且无人监管的程序员都会做的事：即兴发挥。 太离谱了（manda huevos）。 无人察觉的捏造操作 我之前写过一篇博客讨论代码生成过程中的幻觉问题：LLM（大语言模型）会凭空捏造一个 JSON 字段，围绕它创建 DTO，生成测试代码，最后你手上有 90 个“绿灯”的测试，验证的却是虚构出来的内容。这是个严重的问题，但至少它是静态的。被捏造的代码不会到处乱跑，等着有人来审查。 不过，还有另一种更危险的捏造：操作性捏造。这一问题发生在代理不是编写代码，而是凭空创造出“执行路径”时。 问题的模式永远是一样的： 正确路径失败 → 代理寻找捷径 → 捷径“成功” → 潜在损害 举两个真实案例，都是关于一个 ETL pipeline 聚合多个 web 数据源的。 案例 1：字符串里的脚本。 这个 pipeline 有一个命令 make scrape-fuente，会启动一个守护进程，从而启动多个worker。守护进程负责监控、重启崩溃的 worker，并关闭空闲连接。有一天，代理需要启动一个抓取（scrape）任务。但由于依赖问题，make 运行失败了。他怎么办？他创建了一个内联的 47 行 Python 脚本，把它作为字符串传递给 python -c "..." 运行。没有错误处理，没有 watchdog，也没有清理操作。的确运行了……直到一个 worker 卡住，没人来重启它。这样的情况导致数据不完整、连接未关闭，而我直到三天后才发现。 案例 2：孤独的 worker。 另一个会话，同一个 pipeline。这个代理直接运行了 voyeur worker，跳过了守护进程。worker 开始抓取数据，遇到了一个网络超时，然后陷入了重试的死循环，不断消耗资源。而没有守护进程，也没有集中日志记录，没有人知道发生了什么。几小时过去，服务器一直在不停尝试访问一个返回 503 状态码的页面。 ...

“你知道 Rust 最棒的一点是什么吗？它不会允许你编译粗制滥造的代码。你知道最糟糕的一点是什么吗？起初你写的所有代码都是粗制滥造的。” —— 蟹老板，大概是这样说的 比一个 AI 代理更好的是什么？是一个用 Rust 重写 的 AI 代理。 如果你上网超过五分钟，就会知道这个梗。不管是什么项目：文本编辑器、DNS 服务器、BMI 计算器，总会有人跳出来评论“你应该用 Rust 重写它”。这就是 Rewrite It In Rust —— 简称 RIIR，和地心引力一样不可避免的存在。 好吧，那我就来做一次真的。我将把一个有 8,300 行代码的 Python AI 代理移植到 Rust。但不是因为这个梗在召唤我（嗯…有一点是因为它）。我这么做，是因为我需要一个实验对象。 论点 最近几周，我一直在写关于静默失败、五种防止幻觉的方法、以及"一个 LLM 如何生成看似正确但实际上错误的代码"的文章。我甚至还给它起了个名字：对抗性开发。永远不要相信，总要验证。 很多理论，是时候实践了。 于是，我需要一个项目，满足三个特点：范围适中（而不是一个需求会不断变化的新应用）、明确的真相来源（现有可用的 Python 代码）、以及足够的复杂度，让 LLM 的幻觉能“藏起来”。一个纯粹的移植可以完全满足这三点。输入和期望输出已然存在。如果 Rust 版本的行为和 Python 的不完全一样，那肯定有问题。就是这么简单。 既然要做移植，那为什么不顺便真正学学 Rust 呢？借用检查器 (borrow checker)、所有权 (ownership)、生命周期 (lifetimes)… 我读了好几年资料，却几乎没有亲自实践过。如果是写一个真实项目而不是第 N 次看教程，一切或许会大不相同。 目标对象 它的名字叫 nanobot。这是一个基于 OpenClaw 开发的个人 AI 代理。它能将各种 LLM（如 Claude、GPT、DeepSeek）接入聊天渠道——Telegram、Discord、Slack、电子邮件——并赋予它们更多功能。比如读取和编辑文件、执行命令、网络搜索、通过 cron 编排任务，甚至在对话之间保存记忆。 它可以正常工作。而且已经运行了几个月。在 Python 上。 问题呢？它是单线程的。一次只能处理一条消息。如果你连续发送三条信息，它会像周六中午的超市购物队伍一样排队等待。它的内存消耗约为 50MB，而它实际上只是在不同的 API 之间传递 JSON。此外，它的错误处理方式令人羞愧：到处都是return f"Error: {str(e)}"。 ...

107 个提交。从第一天开始就是完美的约定式提交。Feat、fix、refactor、chore — 所有内容都完美标记。那么 CHANGELOG 呢？空的。不存在。一个"明天再写"的文件，已经拖了两个月。 如果这听起来很熟悉，你不是一个人。手动编写变更日志是奥林匹克级别的苦差事。不是说它难 — 而是它乏味、重复，总有更紧急的事情要做。这就是为什么 git-cliff 存在的原因。 什么是 git-cliff（30 秒版本） 这是一个用 Rust 编写的变更日志生成器，它读取你的 git 提交，根据约定式提交解析它们，然后输出按版本和类型分组的 CHANGELOG.md。没有奇怪的依赖，没有插件，没有黑魔法。一个二进制文件，一个配置文件，就完了。 简单来说：你给它你的提交，它返回你拖延了几个月的文件。 1 2 brew install git-cliff git cliff --output CHANGELOG.md 这两行字面上就是开始所需的全部。如果你的提交遵循 类型: 描述 约定，git-cliff 无需额外配置就能理解它们。 真实案例：8 个版本的回溯性变更日志 在 Tokamak（我的监控 Claude 配额的菜单栏应用）中，我正好遇到了这个问题：107 个完美提交和一个空白的 CHANGELOG。应用已经是 v1.3.0 版本，但只有一个开始时的 v0.1 标签。 计划很简单： 步骤 1：在每个版本的提交上创建回溯性标签。 1 2 3 4 5 git tag v0.2.0 32950f4 # Dashboard, biblioteca, achievements v1 git tag v0.3.0 9c56985 # Rename a Tokamak, 6 idiomas git tag v1.0.0 a283490 # App Store: sandbox, privacy manifest git tag v1.3.0 6248bac # HEAD: multi-provider, fetch pipeline # ... 以此类推 步骤 2：运行 git-cliff。 ...

我正在构建 Tokamak，一个监控 Claude Max 配额的 macOS 菜单栏应用。几周前，Anthropic 在他们的服务条款中发布了这样的条文： “您不得使用 OAuth 或类似的授权机制来允许第三方应用程序代表用户访问 Claude。” 而我，正在使用浏览器 cookies 调用一个未公开的端点来读取 Claude Max 配额，盯着屏幕想：“现在怎么办？” 今天的工作方式（有用的权宜之计） Tokamak 需要知道你的配额百分比。就是当你在 claude.ai 上用了一段时间后看到的那个 42%。问题是Anthropic 没有公开的配额 API。没有一个带 API key 的文档化的 GET /api/quota。 但确实存在一个 claude.ai 网站自己使用的内部端点： GET /api/organizations/{org_id}/usage 返回类似这样的内容： 1 2 3 4 { "five_hour": { "utilization": 42, "resets_at": "2026-02-22T18:00:00Z" }, "seven_day": { "utilization": 19, "resets_at": "2026-02-28T14:59:59Z" } } 要调用这个端点，你需要已登录用户的会话 cookies。Tokamak 用一个隐藏的 WKWebView 解决这个问题：用户在应用内的 claude.ai 中登录，cookies 保留在 WebView 中，应用每 30 秒使用这些 cookies 进行轮询。 ...

凌晨两点。你的应用编译通过。签名完成。打包成DMG。执行notarytool submit。苹果说"In Progress"。你等了5分钟。10分钟。20分钟。一个小时。两个小时。提交仍然是"In Progress"。你睡觉去了。第二天早上：Invalid。 除了"The signature of the binary is invalid"之外没有更多解释。对两种架构都是如此。谢谢苹果。非常有用。 公证是那种完美运行的流程…直到它不工作为止。当它失败时，会给你留下一个Gatekeeper不会打开的.dmg文件和一个什么都不告诉你的错误。在为Tokamak（我的用于监控Claude配额的菜单栏应用）与此斗争几天后，我决定记录所学到的一切并编写一个检查器以避免再次经历这种痛苦。 什么是公证（简单来说） 想象Mac App Store是一个有保安的购物中心。但你不想在购物中心销售——你想直接分发你的应用，用你自己的DMG。就像街边摊位。 苹果说：“好的，你可以。但首先要通过门卫。” 那个门卫就是公证。这是苹果的一个自动化服务，扫描你的已签名应用，验证它不包含已知的恶意软件，如果一切正常，就给你一个票据。你把这个票据钉在你的DMG上（stapler staple），从那时起，当用户下载并尝试打开它时，Gatekeeper看到票据就说"请进"。 没有那个票据，用户会看到这个： “Tokamak.app"无法打开，因为苹果无法检查它是否不含恶意软件。 你的应用就被丢在路边了。 苹果为什么这样做 有两个原因。一个是合理的。另一个…嗯。 合理的原因：保护用户。在公证之前（2019年在macOS 10.14.5中引入），任何人都可以用Developer ID分发已签名的.app，macOS会毫无怨言地打开它。代码签名验证开发者的身份，但不扫描内容。如果你的已签名应用包含键盘记录器，签名完整的情况下也会执行。 公证增加了一层：苹果在到达用户之前扫描二进制文件寻找已知的恶意软件和可疑行为。这不是像App Store那样的人工审查——这是一个自动化系统。但至少是个保障。 另一个原因：控制。苹果希望你通过App Store Connect处理所有事情。使用Developer ID的直接分发一直是二等公民。公证是在"你可以在App Store之外分发，但我们会让你感到不便"这条道路上的又一步。 话虽如此，从macOS 10.15开始，对于所有在App Store之外分发的应用，公证是强制性的。这不是可选的。你的应用要么经过公证，要么不会打开。没有商量余地。 会让你浪费数小时的7个错误 在收集了自己的错误和开发者论坛的错误后，这些是最痛苦的： 1. 缺少--timestamp 这是经典错误。你的codesign在本地完美工作，Gatekeeper不抱怨，但公证返回"The signature of the binary is invalid.” 1 2 3 4 5 # 错误 — 本地签名有效，苹果拒绝 codesign --force --options runtime --sign "Developer ID Application: ..." MiApp.app # 正确 — 使用苹果服务器的时间戳 codesign --force --options runtime --timestamp --sign "Developer ID Application: ..." MiApp.app 安全时间戳证明签名是在证书有效期内完成的。没有它，苹果不会信任。就像签署没有日期的合同——技术上有效，但没人会接受。 ...

我正在构建一个 macOS 的菜单栏应用程序。在我的 Mac 上运行完美。现在我需要知道它是否能在干净的 macOS 环境中正常工作：没有我的配置、没有我的权限、没有我的数据。一个全新安装的用户环境。 如何测试这种情况？你需要一个虚拟机。 “简单”，我想。“我安装了 UTM。打开向导，创建一个 macOS 虚拟机，然后运行。” 事情并没有那么简单。 UTM：漂亮但难以驯服 UTM 是一个很棒的应用程序。精心设计的界面，支持在 Apple Silicon 上运行 macOS 客户机，全屏显示，共享剪贴板。手动使用确实很棒。 当你试图自动化时问题就出现了。 UTM 有一个叫做 utmctl 的命令行界面。可以列出虚拟机、启动它们、停止它们、克隆它们。它不能做的是创建虚拟机。对于 macOS 客户机，甚至 UTM 的 AppleScript 也不允许创建它们——操作系统字段被硬编码为 Linux。 简单来说：如果你想在 UTM 中创建 macOS 虚拟机，你必须通过向导手动创建。每次都是。需要点击、下载 IPSW（Apple Silicon 的 macOS 安装映像——相当于传统的 ISO，但由 Apple 打包）、等待安装。 对于需要在质量保证流程中频繁创建和销毁虚拟机的开发者来说，这真是个麻烦事。 Tart：为开发者设计的 macOS 虚拟机 Tart 是当有人在设计虚拟化工具时考虑开发者而不是最终用户的结果。 它使用与 UTM 完全相同的 Apple Virtualization.framework。相同的技术，相同的功能，相同的原生速度。区别在于界面：Tart 是命令行优先的。 1 brew install cirruslabs/cli/tart 就这样。没有图形界面配置，没有向导。只是在你的 PATH 中的一个二进制文件。 一个命令统治一切 创建一个使用最新可用版本的 macOS 虚拟机： ...

我正在构建一个应用来监控我在Claude Code中的token消费。几天前，查看原始数据时，我遇到了这样的情况： cacheReadInputTokens: 4.241.579.174 inputTokens: 1.293.019 从缓存中读取的四十二亿个tokens。一百三十万个"新鲜"tokens。这是**99.97%**的缓存命中率。 我的第一反应是认为出了什么问题。没人能达到99%的缓存率。Redis不行。Cloudflare不行。你妈妈说她已经知道你要吃什么的时候也不行。 但事实证明它没有坏。就是这样工作的。而原因既优雅又反直觉。 缓存的不是文本 这里是大多数解释都不够深入的地方。当你看到"提示词缓存"时，你会想到类似Redis的东西：保存问题，保存答案，如果有人问同样的问题就返回同样的答案。 完全不是这样。 缓存的是KV张量——transformer在预填充阶段计算的Key和Value矩阵。用通俗的话说：当LLM收到你的提示词时，它首先要做的是将所有这些文本转换为内部数字表示（embeddings），然后与权重矩阵相乘，得到注意力机制生成响应所需的"键"（K）和"值"（V）。 这种计算是极其昂贵的。在一个200,000个tokens的提示词中（在Claude Code中很常见，对话历史会累积），我们谈论的是数十亿次矩阵乘法运算。这是最消耗GPU的部分，最耗时的部分，成本最高的部分。 这就是巧妙之处：在你的一条消息和下一条消息之间，99%的提示词不会改变。系统提示词是相同的。之前的对话历史是相同的。它读取的文件是相同的。唯一新的是你的最后一条消息。 为什么要重新计算你30秒前已经计算过的东西呢？ 匹配机制的工作原理 仅仅缓存是不够的。你必须知道缓存什么时候有用。这里Anthropic使用了一个优雅的技巧：按前缀的累积哈希。 提示词的每个块（system、tools、消息）生成一个哈希。但不是单独的哈希：是累积哈希。第3块的哈希包括第1、2、3块的内容。如果前面任何块中的任何东西发生变化，后面所有块的哈希也会改变。 当新请求到达时，系统从标记有cache_control的点开始向后搜索，逐块比较哈希，直到找到匹配的最长前缀。所有匹配的→从缓存读取。只有新的→重新计算。 这就像一部你已经看了40遍的电影。你不需要看完整部电影就知道会发生什么。你只需要从与你记忆中不同的点开始看。 注意这个数据：系统只向后检查最多20个块。超过这个范围，它就停止搜索。这是一个实用的决定，避免花在搜索缓存上的时间超过直接计算张量的时间。 为什么Claude Code有99%的缓存命中率 现在你知道匹配是如何工作的了，99%就不再神秘了。看看Claude Code中典型会话发生的情况： 消息1（会话中的第一条）： 系统提示词 (8K tokens) + 工具 (2K tokens) + 你的消息 (500 tokens) = 10,500 tokens → 全部计算，全部写入缓存 消息2： 系统提示词 (8K) + 工具 (2K) + 消息1 (500) + 响应1 (3K) + 你的消息2 (500) = 14,000 tokens → 前面的10,500个 → 缓存命中（我们之前已经计算过） → 新的3,500个 → 计算并添加到缓存 缓存命中率：75% 消息10： 系统提示词 + 工具 + 9条消息 + 9个响应 + 你的消息10 = ~150,000 tokens → 前面的~149,500个 → 缓存命中 → 新的~500个 → 计算 缓存命中率：99.7% 看到了吗？对话历史只是增长。每条新消息都是累积总数的微小部分。缓存比率以自然对数的确定性收敛到99%。 ...

我妻子召唤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个处方）： ...

不到一个月前，我写了一篇完整的文章来解释如何在 Claude Code 中使用三层记忆系统：Linear 负责战略，Beads 负责战术，Tasks 负责执行。一个漂亮而优雅的金字塔。 然而现实打脸了。 今天我正式退役 Beads。不是心血来潮，而是因为现实已经充分证明：一个给你带来的麻烦比它解决的还多的工具，不叫工具，叫累赘。 Beads 带来了什么 对于没读过原文的人来说，Beads 是一个基于 git 的 issue 追踪器。它是 Claude Code 的插件，把 issues 以 JSONL 文件的形式存储在你的仓库里。这个想法在纸面上很漂亮： Git 持久化：issues 保存在 .beads/ 目录中，和你的代码一起提交。 依赖关系：一个 issue 可以阻塞另一个。 离线可用：不需要网络连接。 LLM 直接可见：不需要 API，不需要配置。代理读取文件就行了。 它的承诺是：在"这周想做什么"（Linear）和"现在正在做什么"（Tasks）之间提供一个中间层。战术层面的粘合剂。 哪里出了问题 一切都很好，直到不再好了。而且不好的方式还挺有创意。 来自地狱的守护进程 Beads 在后台运行一个守护进程来管理 SQLite 数据库并与 git 同步。听起来很合理。但实际上： DATABASE MISMATCH DETECTED! This database belongs to a different repository: Database repo ID: d1f9ca0c Current repo ID: 01eac8ea ⚠️ CRITICAL: This mismatch can cause beads to incorrectly delete issues during sync! 每次启动会话都会看到这条消息。守护进程崩溃，同步崩溃，然后你就陷入了一种量子态：issues 存在于你的本地 SQLite 中但不在 git 里，或者反过来。你的 issues 同时存在又不存在。 ...

单一checkout的瓶颈 我正在开发一个macOS菜单栏应用。我有三个功能在待办清单中：一个消耗量的迷你图表、原生通知和一个桌面小组件。这三个功能都是独立的。我打算用Claude Code来完成这三个功能。 问题是：Claude Code在一个目录中工作。一个目录有一个分支。而git checkout就像一个单车道的环岛：一次只能通过一个。 如果我想同时推进这三个功能，我的传统选择是： Stash乒乓球：git stash，切换分支，工作，git stash pop，祈祷没有冲突。重复直到发疯或退休，看哪个先到。 克隆仓库三次：可以工作，但现在我有三个.git/副本，三个独立的历史记录，每个都要执行git fetch。浪费。 接受串行生活：一个功能接着一个功能。安全，可预测，但慢得像手动归并排序。 都不好。但有第四个选择，自2015年以来git就有了，但几乎没人使用。 Worktrees：你已经安装的解决方案 一个worktree是第二个工作目录，共享同一个.git仓库。没有副本，没有克隆，没有黑魔法。 比喻：你的仓库是一个图书馆。到目前为止你有一张桌子，只能打开一本书。worktree是放更多桌子。每张桌子都打开着不同的书，但都从同一个书架取书。 ~/code/miapp/ ← 桌子1 (main) .git/ ← 图书馆（只有一个） ~/code/miapp-sparkline/ ← 桌子2 (feature/sparkline) .git ← 文件，不是文件夹（指向图书馆的指针） ~/code/miapp-notificaciones/ ← 桌子3 (feature/notifications) .git ← 另一个指针 每个目录都是一个完整的checkout，包含所有文件。你可以在一个中编译，在另一个中运行测试，在第三个中让你的AI助手工作。同时进行。 创建只需一行命令 从你的主仓库： 1 2 git worktree add ../miapp-sparkline -b feature/sparkline git worktree add ../miapp-notificaciones -b feature/notifications 就这样。两个新目录，每个在自己的分支上，共享整个git数据库。不需要克隆，不需要配置远程，不需要复制历史记录。 它们共享什么，不共享什么 这很重要。worktrees共享整个仓库：提交、分支、标签、远程、钩子、配置。如果你在sparkline的worktree中做了一个提交，你可以立即从notifications的worktree中看到它，不需要fetch或任何操作，因为它们是同一个数据库。 它们不共享： 磁盘上的文件（每张桌子都有自己的工作副本） 暂存区（每个都有自己的git add） HEAD（每个指向自己的分支） 简单来说：“我正在处理什么"的状态对每个worktree是私有的。其他一切都是公共的。 ...