开发工具

你每个月可能花费 20 到 200 美元来访问 LLM（大型语言模型）。Claude、GPT、Gemini，无论哪一个都在烧你的钱。而这些模型从你的脚本和开发工具调用的大多数场景都可归结如下几类： “把这个错误分类到这五个类别之一。” “给这个变量起个名字。” “告诉我这个 commit 是 fix、feat 还是 refactor。” “用两句话总结这段文字。” 与此同时，你的 Apple Silicon Mac 上还坐着一个拥有 30 亿参数的语言模型：全系统集成、无需支付费用、无需网络连接、无需 API 密钥、甚至不需要网络延迟。而你大概根本没用过。 基础模型框架（Foundation Models Framework） 自 macOS 26 (Tahoe) 起，Apple 推出了 Foundation Models Framework，允许访问 Apple Intelligence 支持的语言模型。这是一个原生的 Swift 框架，适用于 macOS 26、iOS 26 和 iPadOS 26，兼容所有支持 Apple Intelligence 的 Apple Silicon 设备。 值得注意的不仅仅是它免费——这的确很棒，更特别的是它生成 Swift 类型化输出。它不会返回需要你用正则表达式和上帝保佑才能解析的 String，而是直接输出一个结构体（struct）。 import FoundationModels @Generable struct CommitClassification { @Guide(description: "The type of change") @Guide(.anyOf(["fix", "feat", "refactor", "test", "docs", "chore"])) let type: String @Guide(description: "One-line summary of the change, max 72 chars") let summary: String } --- `@Generable` 宏告诉框架在编译时生成架构（schema）。语言模型利用这个架构生成结构化输出。`@Guide` 则限制了可能的值——通俗地说，你给模型铺好了轨道，它就不会出轨。 以下是用法示例： ```swift let session = LanguageModelSession(instructions: """ You are a commit message classifier. Given a git diff, classify the change and write a summary. """) let diff = "..." // 你的 git diff 数据 let result = try await session.respond( to: "Classify this diff:\n\(diff)", generating: CommitClassification.self ) print("\(result.type): \(result.summary)") // "fix: handle nil response in auth flow" 就是这样。没有 URLSession（网络请求），也没有 API 密钥，也不需要解析 JSON，不需要 try? JSONDecoder().decode(SomeType.self, from: data)。整个模型在设备内部运行，依托于你 Mac 的 Neural Engine（神经引擎），并返回 Swift 类型数据，编译器将会为它进行类型检查。 ...

TL;DR：Python工具多年来一直是支离破碎且缓慢的灾难。革命没有来自生态系统内部：它来自Rust。uv、Ruff和ty——都由Astral用Rust编写——已经取代了半打工具，速度提升了10倍到100倍。看来Ferris信徒们还是有道理的。 你有没有试过向别人解释如何在Python中安装依赖？ “用pip。不过，要在virtualenv里面。或者用venv，这是新的。如果你有多个Python版本，需要用pyenv。管理项目的话，用poetry。或者pipenv。或者pdm。如果做数据科学就用conda。啊，lock文件每个工具都用不同的格式生成。别忘了setup.py。嗯，现在是pyproject.toml了。不过，有时候两个都要。” 如果这听起来很熟悉，你并不孤单。Randall Munroe在2018年为此专门画了一期xkcd漫画——一个意大利面条图，展示了Python在你机器上可能的所有安装方式。八年过去了，这期漫画依然贴切。或者说，直到最近还是这样。 工具墓地 让我们盘点一下。在2024年之前，要搭建一个"现代"Python项目，你至少需要从这些工具中组合选择： 工具 功能 pip 安装包 virtualenv / venv 隔离环境 pyenv 管理Python版本 poetry / pipenv / pdm 依赖管理和lock文件 flake8 / pylint Linter black / autopep8 格式化工具 isort 排序导入 mypy / pyright 类型检查 至少八个工具——而在其他生态系统中这只需要一两个工具。每个都有自己的配置、配置文件，以及与其他工具的不兼容性。在pyenv创建的virtualenv中安装poetry，而pyenv又使用Homebrew安装的Python，而Homebrew又有另一个全局pip…好吧，你懂的。 最糟糕的是：每隔几年就会出现一个新工具，承诺统一一切。Pipenv曾经要成为解决方案。然后是poetry。然后是pdm。xkcd的标准化漫画在循环上演：“我们有14个工具，这太荒谬了。我要创建一个统一工具。现在我们有15个工具了。” 然后螃蟹来了 2022年，一个叫Charlie Marsh的人——Khan Academy和Spring Discovery的前员工——发布了一个叫Ruff的Python linter。用Rust编写。 Python社区的反应可想而知：“太好了，又一个linter。“直到他们看到数据。Ruff比Flake8快10到100倍。不是快20%。不是快一倍。**快一百倍。**在大型代码库中，原本需要30秒的linting现在只需要300毫秒。 但Ruff不满足于只做一个快速linter。它吞并了Flake8、Pylint、isort和Black。一个工具，一个二进制文件，零Python依赖。它做linting、格式化、排序导入。而且速度如此之快，你可以在编辑器的每次按键时运行它而不会感觉到延迟。 Charlie创立了Astral来为项目提供架构。他招募了有趣的人才：团队中有ripgrep、bat和hyperfine的作者——这些用Rust编写的终端工具已经证明了用Rust重写经典工具不是在开玩笑，而是客观的改进。 uv：让pip看起来像拨号上网 2024年2月，Astral投下重磅炸弹：uv。一个Python包和项目管理器。用Rust编写。 简单说：uv替代了pip、pip-tools、pipx、poetry、pyenv、virtualenv和twine。全部。一个二进制文件。 我知道你在想什么：“好吧，又一个声称替代一切的工具。“但数据简直不可思议： 操作 pip uv 速度提升 安装依赖（无缓存） ~30s ~0.3s 100x 解析依赖 ~15s ~0.15s 100x 创建virtualenv ~2s ~0.01s 200x 安装（有缓存） ~5s ~0.05s 100x 这不是合成基准测试。这是你在日常工作中能感受到的。原本让你有时间去倒咖啡的pip install现在在你按下回车之前就完成了。 ...

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

凌晨两点。你的应用编译通过。签名完成。打包成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.” # 错误 — 本地签名有效，苹果拒绝 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 是命令行优先的。 brew install cirruslabs/cli/tart 就这样。没有图形界面配置，没有向导。只是在你的 PATH 中的一个二进制文件。 一个命令统治一切 创建一个使用最新可用版本的 macOS 虚拟机： tart create mi-vm --from-ipsw latest 就是这样。latest 告诉 Tart “给我这台 Mac 支持的最新 macOS 版本”。Tart 查询 Apple 的 API，下载 IPSW（约 15 GB——是的，macOS 很大），创建虚拟磁盘，安装操作系统，并为你准备好可以启动的虚拟机。去喝杯咖啡吧，因为需要一段时间——但你不需要动手做任何事情。 ...

不到一个月前，我写了篇完整文章介绍如何在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同步。听起来合理？实际状况： 检测到数据库不匹配！ 当前数据库属于其他代码库： 数据库记录库ID：d1f9ca0c 当前代码库ID：01eac8ea ⚠️ 严重警告：此错误可能导致同步时误删issues！ 这个错误会在每次会话启动时出现。守护进程崩溃、同步失败，导致issues陷入量子态——既存在于本地SQLite又不存在于Git，反之亦然。 幽灵同步 bd sync本应同步Git远程仓库的issues，但经常失效： → 从远程拉取中... 错误：git pull执行失败：退出状态1 remote: 仓库不存在 fatal: 无法访问'https://git.frr.dev/frr/wuwei.git/' 当代码库配置多个remote时（这很常见），Beads可能选错远程仓库。若该仓库不存在或已更名，每次操作都会静默报错。最终issues停止同步，直到下次会话时数据全部消失才后知后觉。 认知损耗 每次Claude Code会话都这样开始： Claude读取Beads提示（通过hooks注入） 尝试启动守护进程 因数据库不匹配失败 Claude尝试bd sync 因远程仓库错误失败 你手动输入"忽略该错误" 终于可以开始工作 六个摩擦步骤消耗着上下文、时间和耐心。 局势转变 两件事让Beads从"带bug的实用工具"沦为"不必要的负担"： 1. Tasks的成熟 当初设计三层架构时，Tasks功能简陋。现在已具备： 支持描述和元数据的TaskCreate 带依赖关系的TaskUpdate 查询功能TaskList/TaskGet 通过CLAUDE_CODE_TASK_LIST_ID实现跨会话持久化 简言之：Tasks现已实现Beads的所有会话内功能，且无需守护进程、SQLite或Git同步。 2. Linear CLI问世 原生的Linear管理控制台(MCP)往好了说也很糟糕——延迟高、稳定性差，总在关键时刻掉链子。 直接调用GraphQL API？理论上可行，直到你需要在issue描述中使用特殊字符： # 尝试1：使用bash字符串插值 # 结果：括号和箭头破坏JSON结构 # 尝试2：Python urllib方案 # 结果：因op read无法在Python环境执行报401错误 # 尝试3：默默流泪 # 结果：情绪宣泄但无实际产出 直到发现linear命令行工具： ...

单一checkout的困境 我正在开发一个macOS菜单栏应用，有三个并行需求：消费趋势的走势图、原生通知和桌面小组件。这三个功能独立开发，都计划使用Claude Code实现。 问题在于：Claude Code需要在指定目录工作。而每个Git目录同一时间只能检出(checkout)一个分支。标准的git checkout就如同单车道环岛——每次只能通过一辆车。 如果想让三个功能并行开发，传统方案只有以下几种： 暂存乒乓：反复执行git stash保存更改→切换分支→git stash pop恢复→祈祷不要出现冲突…如此循环直到崩溃或退休，视哪个先到来。 克隆多个仓库：可行，但会产生三个完整的.git/目录副本、三个独立历史记录，以及三倍git fetch操作。资源浪费严重。 顺序开发：老老实实一个接一个开发。稳定可靠，但效率低得像手动执行归并排序。 这些方案都不理想。但Git其实自2015年起就内置了第四种解决方案——只是鲜为人知。 工作树(Worktree)：现成的解决方案 Git工作树允许为同一仓库创建多个工作目录，无需克隆完整仓库。没有文件复制，没有魔法技巧。 类比说明：将Git仓库视作图书馆。原先你只有一张阅览桌，每次只能打开一本书。而工作树相当于增添多张阅览桌，每张桌子可打开不同的书，但所有书都来自同一个书库。 ~/code/miapp/ ← 主工作区(main分支) .git/ ← 核心书库(唯一存在) ~/code/miapp-sparkline/ ← 工作树1(feature/sparkline分支) .git ← 符号链接文件(指向主书库) ~/code/miapp-notificaciones/ ← 工作树2(feature/notifications分支) .git ← 另一符号链接 每个目录都是完整的检出副本，包含所有文件。你可以在一个目录编译代码，在另一个目录运行测试，同时让AI编程代理在第三个目录工作——真正并行不悖。 一行命令创建工作树 在项目主目录执行： git worktree add ../miapp-sparkline -b feature/sparkline git worktree add ../miapp-notificaciones -b feature/notifications 就这么简单。两个新目录立即创建完成，各自对应独立分支，共享同一Git数据库。无需克隆操作，无需配置远程仓库，无需复制历史记录。 共享与隔离机制 关键在于理解：所有工作树完全共享Git仓库数据——包括提交历史、分支、标签、远程配置和钩子脚本。当你在sparkline工作树提交代码，notifications工作树可即时看到此次提交，无需执行fetch操作。 但以下内容是独立的： 工作目录文件（每个工作树有自己的文件副本） 暂存区（各自独立的git add状态） HEAD指针（指向不同分支） 简言之：每个工作树的"当前工作状态"是私有的，其他所有仓库数据都是共享的。 与AI编程代理的协作流程 这才是工作树的精髓所在。通过工作树，你可以让多个AI编程代理真正并行工作： # 终端1：在sparkline分支运行Claude Code cd ~/code/miapp-sparkline claude # 终端2：在notifications分支运行Claude Code cd ~/code/miapp-notificaciones claude # 终端3：保持主分支运行 cd ~/code/miapp make run 每个Claude实例都在独立目录、独立分支下操作，拥有独立的.build/缓存目录。彼此互不干扰，无需竞争暂存区，更不需要反复执行stash操作。 ...

敲敲敲。谁？Touch ID。又来了。 想象一下：你正在终端工作，用op read查询1Password的密钥。需要Linear的API密钥。Touch ID。OpenRouter的。Touch ID。Gitea的。Touch ID。 半小时内它要求我验证指纹十四次。 你知道当一个安全工具在三十分钟内打断你十四次会发生什么吗？第五次时你就不再看它在要求什么了。你下意识地放上手指。“是的，随便什么，让我工作吧。” 而这正是安全性完全崩溃的地方。 授权疲劳：没人愿意正视的问题 这在安全领域有个名词：授权疲劳。这不是什么新概念。这与MFA疲劳攻击使用的原理相同：用授权请求轰炸用户，直到他们纯粹因为疲惫而接受一个。 2022年，一个17岁的孩子正是这样进入Uber内部系统的。他反复向员工发送认证推送通知，深夜时分，直到那个人为了能睡觉而接受了一个。 显然，1Password要求Touch ID不是攻击。但心理效应是相同的：它训练你不假思索地批准。 这就像那些多年来出现在每个网站上的cookie横幅。一开始你会阅读它们。现在你不看就点击"全部接受"。恭喜：一个设计用来保护你隐私的机制教会了你更快地放弃你的隐私。 为什么1Password每次都要我的手指 我的设置：我使用op read从终端读取1Password的密钥。运行得很好。问题是我使用Claude Code（一个终端AI助手），它执行的每个命令都是一个新进程。 1Password的生物识别会话超时是10分钟不活动，并在每次使用时刷新。理论上，不应该这么频繁地要求手指。但Claude Code不重用进程：每次需要密钥时，它启动一个新的shell，1Password将其解释为新会话。 结果：每次Claude需要密钥时都要Touch ID。这是持续性的。 解决方案：40行缓存 想法很简单：一个包装器在PATH中排在op前面。当你执行op read时，它检查是否已经缓存了新鲜的结果。如果有，直接返回而不接触1Password。如果没有，调用真正的op，缓存结果，完成。 对于任何其他子命令（op signin、op item list等），直接传递给真正的op而不干预。 #!/bin/bash # ~/.local/bin/op — 1Password CLI的缓存包装器 # 仅缓存'op read'。其他所有内容直接传递给真正的op。 # 可使用OP_CACHE_TTL配置缓存TTL（默认：3600s = 1h） REAL_OP="/opt/homebrew/bin/op" CACHE_DIR="${HOME}/.cache/op-cache" CACHE_TTL="${OP_CACHE_TTL:-3600}" # 仅缓存'op read' if [[ "$1" == "read" ]]; then mkdir -p "$CACHE_DIR" && chmod 700 "$CACHE_DIR" # 所有参数的哈希作为缓存键 CACHE_KEY=$(printf '%s\0' "$@" | shasum -a 256 | cut -d' ' -f1) CACHE_FILE="${CACHE_DIR}/${CACHE_KEY}" # 缓存命中：文件存在且未过期 if [[ -f "$CACHE_FILE" ]]; then FILE_AGE=$(( $(date +%s) - $(stat -c %Y "$CACHE_FILE") )) if [[ $FILE_AGE -lt $CACHE_TTL ]]; then cat "$CACHE_FILE" exit 0 fi fi # 缓存未命中或过期：调用真正的op RESULT=$("$REAL_OP" "$@") EXIT_CODE=$? # 仅在op成功时缓存 if [[ $EXIT_CODE -eq 0 ]]; then printf '%s' "$RESULT" > "$CACHE_FILE" chmod 600 "$CACHE_FILE" fi printf '%s' "$RESULT" exit $EXIT_CODE else # 任何其他子命令：直接传递 exec "$REAL_OP" "$@" fi 将它保存在~/.local/bin/op，给予执行权限，由于~/.local/bin在PATH中排在/opt/homebrew/bin之前，你的包装器会拦截调用。 ...