在 2026 年构建 Bencher：开源、自力更生，彻底入坑智能体
Everett Pompeii
本文最初于 2026 年 10 月 4 日投稿至 The Pragmatic Engineer’s How Software Engineering is Changing Essay Challenge。
今年，我构建软件的方式发生了翻天覆地的变化。我是一名主任软件工程师（staff software engineer）。过去六年里，我先后在一家由 YC 和 a16z 投资的独角兽公司和一家财富 500 强公司专职使用 Rust 工作。作为一名正在“戒断”中的 C++ 开发者，我发现自己被 Rust 所要求的深度和技艺深深吸引。我早已成为一名手工雕琢实时系统软件的资深匠人。而在过去的十个月里，我不得不亲手埋葬这个身份。虽然我的职位名称仍然写着“软件工程师”，但我现在的工作其实是“上下文工程师”。
过去四年，我把晚上和周末都花在了打造一个开源、自力更生的业务上：Bencher。Bencher 是一个持续基准测试平台，帮助系统软件工程师在合并之前就发现性能回归。要做到这一点，需要一整套工具：一个 CLI、一个 API 服务器，以及一个前端 Web 控制台界面。这些组件，除去可以忽略不计的误差，全都是我一个人写的。这些年来我也有过几位值得一提的开源贡献者，但 Bencher 这个开源项目的绝大部分，以及 Bencher 这门生意的 100%，都是由我自己设计和实现的。
这四年里，我可没有与世隔绝。我订了婚、结了婚，还迎来了第一个孩子。一个大型功能，我往往要花几周甚至几个月才能实现并上线。我得同时兼顾开发和技术支持。Bencher 那时已经有不少用户了，所以我会花相当多的时间回答问题，顺便修修偶尔冒出来的 bug。
早在 2022 年，我对 LLM 的使用仅限于 TabNine 的 Rust 免费版。这是一个按 Tab 键自动补全的开发者工具，作者是一名学生，也是 OpenAI 的早期实习生，当时在做一个名叫 Codex 的有趣小项目。等到 GitHub Copilot 发布并非正式地加入 Rust 支持后，我掏出每月 10 美元买了一个个人许可证。
它用起来很糙。但仍然有点像魔法。我记得 GitHub Copilot 的 VSCode 扩展加入聊天功能后不久，它写 Rust 过程宏的本事就让我大吃一惊。通常我还得稍微改改它的输出，但有那么几次，它居然一次就搞定了。离谱！这很酷，大概也帮我省了些时间，但我的工作方式基本上还是和以前一样。
从那以后，我一直抱着这样一种心态：微软凭借 GitHub Copilot 走在最前沿。就算那些新冒出来的实验室到处推出“智能体”，我也相信只要有什么真正有价值的东西，GitHub Copilot 都会跟上。我会听到像 Dan Shipper 这样的人在 Lenny’s Podcast 上讲述模型的能力，可他们说的和我的实际体验、我的质量标准根本对不上。
去年年初，我写了一篇文章回顾 Bencher 三年来的开发历程：工程回顾：2025 年版。在那篇文章中，我讲述了构建 Bencher 时所做的所有重大工程决策，涵盖前端、后端、开发者环境、CI，应有尽有。我还用了整整一段来吐槽两年前自己为了搞懂 CUE lang 有多痛苦。然而，在那篇 3,500 词的长文里，AI、LLM，甚至 Copilot，一次都没有出现过。
快进到不到一年之后，我已经在和《We mourn our craft》同悲共叹了。
Claude 帮忙拯救了圣诞节
和许多人一样，在 2025 年的寒假假期里，我终于有机会好好用一用 Claude Opus 4.5。当时我带着妻子和孩子在伦敦探望我妹妹一家。我妹妹刚生了一对双胞胎，所以我本该是去帮忙的。结果，我却窝在楼上，忙着抵御针对 Bencher 的垃圾邮件和 DDoS 攻击。Claude 在诊断问题和构思可能的解决方案方面帮了大忙。
最后我把 Bencher 迁移到了 Cloudflare 后面，并配置了 reCAPTCHA。大部分工作仍然是我自己做的，但在权衡诸多相互冲突的设计约束时，Opus 4.5 解决问题的能力有了明显的提升。不过，它也建议我做了一处改动，结果让安装 Bencher CLI 的便捷脚本瘫痪了半天。哎呀。
新年新 Harness
到今年一月时，我已经听人夸 Claude Code 有多厉害好几个月了。之前我一直没去尝试，因为 Opus 4 实在达不到让我信任它工作成果的质量标准。既然 Opus 4.5 已经达到了这个标准，我也想试试 Claude Code。从把 Copilot 当作 harness 换到 Claude Code，我看到的提升幅度，和模型从 Opus 4/GPT-5.2/Gemini 2.5 Pro 换到 Opus 4.5 的飞跃一样大。
用 Claude Code 的第一个周末，我就拿它和 Copilot 做了一次不怎么严谨的对比测试。我想让 Copilot 把一份 PDF 转成有声书。即使在 “Agent Mode” 下，Copilot 也只会走五六步就停下来，直到我再戳它一下。与此同时，Claude Code 在经过一轮详尽的 Plan mode 之后，正埋头苦干，试图构建一个定制的 hypervisor。我彻底确信，抽象层级已经从模型上移到了 harness，而 Copilot 再也追不上了。
梦想中的 Bencher Bare Metal
从 Bencher 最早期开始，我就一直梦想着打造一支裸机基准测试机群。传统的 CI 运行器由于本身就是虚拟机，噪声太大，无法给出一致的基准测试结果。你也许能检测到延迟增加了 200%，但永远无法可靠地检测到 20% 的增长。指令计数是在 CI 中进行基准测试的一种可能方案。它们基本上是确定性的。然而，指令计数只是你真正关心的东西（挂钟时间）的一个代理指标。任何在“CPU 模拟”中运行并吐出指令计数的东西，都只能与速度存在相关性。问题在于，除非你真的在裸机上测量，否则你永远不知道它到底偏差了多少。
Bencher 最早的用户之一是 Rustls 项目。我参与贡献了他们的 Rustls bench runner。然而，它并不适合作为构建裸机基准测试机群的基础。它只部署在一台主机上，并且把所有基准测试工作负载都视为可信的。这意味着不支持来自 fork 的 PR，也不支持多租户。再说，大多数团队也不想为每台裸机基准测试服务器每月支付 100 美元以上。
我曾考虑过用 GitHub Actions 作为编排层，但这种方案有几个根本性的缺陷。首先，GitHub Actions Runner 是用 C# 编写的。这意味着它的垃圾回收器可能会在你的运行过程中突然启动，扭曲你的基准测试结果。哦对了，记得把自动更新程序关掉，免得它在运行途中启动，但也别把它忘太久，否则你的任务就会停止运行！
就算 GitHub Actions Runner 是一个安静乖巧的 Rust 二进制文件，更根本的问题在于它和 GitHub Actions 绑死了。Bencher 从一开始就是 CLI 优先的。不管是好是坏，我一直不想把 Bencher 和任何一家 CI 提供商绑得太深。确实有一个 Bencher CLI GitHub Action，但它所做的也只是帮你安装 CLI。我希望 Bencher Bare Metal 能在 CLI 能运行的任何地方工作，而不仅仅是 GitHub Actions。
我想到的点子是：用 OCI 镜像来打包基准测试工作负载，再加上一个可选的、非常小的沙箱，确保在某台裸机主机上每次只运行一个任务。一想到要靠晚上和周末自己一个人把它做出来，我就望而生畏。白天有工作，家里还有家庭，我一个人一点点啃，至少也要花上一年。
构建 Bencher Bare Metal
今年一月，有了 Opus 4.5 和 Claude Code 在手，我觉得自己终于看清了构建 Bencher Bare Metal 的可行路径。我再一次掏了腰包，这次是每月 200 美元的 Claude Max 20x 套餐。这大概是有史以来最值的一笔业务开支。
我开始火力全开，每周都尽力把 Claude 套餐的用量用满。我不再手写代码了，无论是在 Bencher 上还是在白天的工作中。那时我仍在以相当紧凑的循环迭代：使用 Plan mode，阅读所有输出，并在 Accept edits 模式下运行。那时我还不信任智能体去碰 git/jj，所以所有版本控制都由我自己处理。我把自己看作一个“人在回路中”的 Ralph Loop。当并行运行大约五个智能体时，我的大脑就开始融化了。
我听到过一条建议：让不同的智能体分别负责实现和审查，于是我开始做独立的对抗式审查。这些对抗式审查似乎确实有助于提升输出质量。我自己做了一个 GitHub Actions 审查机器人，用的是我 Claude Code 订阅的 API 密钥。然后我让本地智能体和这个 CI 审查者反复迭代，以节省本地机器的算力。
期间有一阵子，我以为自己要让 Claude 为基准测试沙箱构建它自己的 hypervisor。然后我让 Claude 以 Linus Torvalds 的身份对这个计划做一次对抗式审查，结果它告诉我我很蠢，这是一个非常、非常、非常愚蠢的主意。只要 Linus 在你的上下文里，就别想有阿谀奉承！于是我放弃了这个计划，改用 Firecracker。
良好基准测试的敌人是方差，而不是速度本身。所以，尽管 Firecracker 作为 hypervisor 会带来开销，但这个开销非常稳定，尤其是在每次只运行一个 microVM 的情况下。这让共享的 Bencher Bare Metal Runner 既能支持多租户，又能得到非常一致的基准测试结果。我还和 Claude 一起使用 Plan mode 进行设计，让沙箱成为可选项。如果用户想在自己的专用服务器上运行，并且信任每一个工作负载，那么他们可以不用 Firecracker 运行，开销几乎为零。
开发 Bare Metal runner 让我深刻认识到，给智能体一个紧凑的反馈循环有多重要。即使在 Opus 4.6 发布之后，Claude 似乎仍然很难让所有东西稳定地跑起来。等我给了它一个启用了 KVM 的开发环境（运行 Firecracker 必需的），一切才真正开始顺起来。这些智能体并非无所不知，它们只是非常有韧劲。
我对 Claude 的工作审查得多严，取决于它在代码库的哪个部分工作。对于纯粹属于 Bare Metal 的代码，比如 OCI 镜像仓库和 runner 二进制文件，我只是粗略地审查一下。只要它通过了对抗式审查、端到端测试通过、看起来也不算太糟糕，我就合并。而对于触及现有核心的代码，即任务排队和报告处理，我依旧和以往一样吹毛求疵。
今年三月底，我在 v0.6.0 中发布了 Bencher Bare Metal。对于公共裸机机群，我曾考虑使用 AWS EC2 Bare Metal。然而，这些机器不仅巨大无比，而且只有 ARM。为了贴合大多数真实世界的工作负载，我想要的是朴实耐用的 Intel x86 机器。我和 Claude 一起做调研，为机群寻找一个能满足设计约束的最佳归宿。最终，我们得以在 Bencher Cloud 上提供 intel-v1 Spec，为用户提供 4 个 vCPU、48 GB 内存和 128 GB 磁盘，按分钟计费。在结构良好的基准测试上，我在整个机群中各次运行之间的方差始终保持在 <2%。
智能体认证
在 Bencher Bare Metal 之前，所有的认证用的都是 JWT。又大、又美、又让人看不懂的 JWT。而 Bare Metal Runner 的认证则使用带名称前缀的 API 密钥，例如 bencher_runner_abc123...。
在客户端，我想给智能体提供一种东西，而不是让它们直接用用户自己的 API 令牌 JWT。我找到的折中方案是，终于实现了一个呼声已久的功能：项目范围的认证。Claude 帮我创建了安全的、项目范围的、带前缀的 API 密钥。这些 API 密钥的权限仅限于与 bencher run CLI 命令所执行的操作相当的范围：项目范围内的读取和非破坏性的写入。这也让这些 API 密钥天然适合用在持续基准测试的 CI 工作流中。
后来我加入 Bencher MCP 时，这些项目范围的 API 密钥也被用作那里的认证方式。MCP 标准指定的是 OAuth 2.1，但它仍处于草案阶段，所以我暂时还不想实现它。说实话，我对 MCP 有点持怀疑态度。我仍然认为，一个好用的 CLI 加上技能，是向智能体开放一项服务更有效、也更具可移植性的方式。不过 CLI 最大的问题在于缺乏标准的认证机制。所以，尽管 OAuth 2.1 仍处于草案阶段，至少 MCP 把这一点考虑到了。而一个好的认证方案对企业来说真的很重要。
精通多国语言的 Claude
早在 2023 年，我就决定让 Bencher 文档支持 9 种语言：英语、中文、西班牙语、巴西葡萄牙语、俄语、日语、法语、德语和韩语。我是怎么选出这九种语言的？它们正是 GitHub 文档所使用的语言，所以我觉得这是个足够好的近似。唯一的问题是，我只会说英语。于是我让 GPT-4 帮我翻译文档。当时 GPT-4 的上下文窗口只有 8k token。这意味着我必须把所有文档页面拆分成一个个小于 8k token 的“块”（chunk）。然后我还得写一个 CLI 工具，来处理块的翻译，以及在块更新后频繁地重新翻译。
这是一个非常繁琐且容易出错的过程。我不得不手动编辑翻译后的文件，因为即使在系统提示词里写了非常明确的指令，模型仍然会把导入路径搞砸，或者把所有内容又塞进一层 Markdown 代码块里，不知为何，日语尤其如此。
自从我开始用 Claude Code 搭配 Opus 4.5，这些问题全都消失了。现在智能体直接就搞定了。什么算一个块，这个约定就写在代码库里，Claude 照着做就行。在我为 Bencher Bare Metal 编写技术文档时，Claude 直接包办了分块和翻译的编排工作。尽管现在的上下文大小已经完全足以容纳一整个页面，我还是喜欢保留这些块。它有助于让改动保持隔离，这样修订时只有页面中相关的部分才会被重新翻译。
2026 年谁还没造过 Harness？
在构建 Bencher Bare Metal 的同时，我还让 Claude 为它自己打造了管理机群的工具。这包括两部分：bencher 仓库中一个处理日常任务的 CLI，以及一个新的元仓库（meta-repo）。这个元仓库存放着 Bencher 作为一款产品的所有文档和上下文。bencherdev GitHub 组织中的其他每个仓库，都是这个元仓库中的子模块。有了元仓库，智能体就能轻松处理可能横跨多个仓库的任务，还能撰写那些我不希望公开的文档（产品战略、事故报告等等）。
我想在 Claude Code CLI 之上构建我自己的智能体，让这个元仓库从一个静态产物变成开发周期中主动参与的一环。Fable 5 一推出，我就把大量精力投入到了构建这个智能体上。我希望能够放心地让这个智能体自主运行。其中很大一部分在于安全性（即缓解提示词注入）。我的设计是让工作智能体永远不持有任何密钥。所有密钥都由网络代理注入，并且仅限于白名单中的端点。智能体本身运行在另一个 Firecracker microVM 中，这次支持并行。智能体控制机和网络代理加沙箱分别运行在完全不同的主机上。
我的宏伟愿景是，界面是一个按任务优先级排序的队列。也就是说，这个智能体的目标是向我展示在那一刻最重要的任务。Facebook/Instagram/Twitter/X/TikTok 的信息流是为参与度而优化的，而这个信息流则是为对我的重要性而优化的。
我想打造一个工具，把我自己置于 API 之下。我发现自己大部分时间都花在了上下文切换和在各个线程之间来回跳转上。我希望智能体能通过帮我对事情进行排序，来减轻这种手忙脚乱。借助一个类似 Reddit 的点赞/点踩系统，我就可以训练智能体判断那条新的 Slack 消息是否真的是我最该关注的事情。
我还发现，我现在的工作很大一部分是当我智能体的鲁伯·海格，也就是它的“钥匙保管员”。在网络代理层进行注入，再配合受限的端点白名单，是 Claude 和我能想出来的最好办法：既能让智能体永远接触不到任何密钥，又能让它开箱即用地使用 gh CLI 之类的工具。
另一个核心目标是永远不离开智能体界面。无论出于什么原因离开智能体去别处操作，都被视为 harness 的失败。我创建了一个程序化 UI 组件系统，让处理任务的智能体可以根据手头的任务即时构建一个全新的界面，或者从组件库中选择一个现有组件。代码、邮件、Slack、日历、生产环境遥测数据、错误监控，所有东西都在一个界面里，都在一个按优先级排序的队列里。
我已经把这一切的最小可用版本跑起来了。不过，仍然有很多粗糙的地方。目前，如果我直接用 Claude 桌面应用，效率反而要高得多。而就眼下而言，我需要尽可能多的即时生产力，才能跟上需求。
当开发者数量增长 100 倍时会发生什么？
早在 2022 年，我正在寻找一个新的副业项目。我在 2020 年就关掉了上一次“想创业”式的尝试。人生小贴士：听 Jason Cohen 的话，别想着靠自力更生做一个双边市场。
当时我在白天的工作中用 Rust 构建一个静态 bash 解析器和分析器，结果发现自己不得不用电子表格来跟踪基准测试结果。Rust 项目有 rustc-perf 来跟踪编译器本身的性能。然而，却没有一个好用的工具可以对我自己的代码做同样的事。
我对这个领域的现有技术做了大量调研。在几个月的时间里，我和好几位开发者通了电话，他们要么自己构建过持续基准测试工具，要么曾倡导构建这类工具。大家都在重新发明轮子。我以为自己在市场的水域中找到了一处宁静的小角落。需求明显存在，而且持续不断。许多团队已经在为自己的裸机运行器每月支付超过 100 美元了。所以付费意愿是有的。然而，这个使用场景很小众。大多数现代软件都以服务的形式部署，所以对大多数团队来说，把性能测试左移并不是什么高优先级的事。他们只会在部署后在 Grafana 里设置告警，事后再去捕捉漏网之鱼。
不过，随着能力强大的智能体纷纷上线，有两个因素大大提升了 Bencher 的使用量：
- 为了以确定性的方式测试智能体的产出，需要采用软件工程最佳实践
- 在智能体的帮助下，采用软件工程最佳实践变得轻而易举
LLM，以及由此延伸出的智能体，都是非确定性的随机系统。和人类开发者一样，它们也需要护栏来确保代码质量。实现这一点的方法并不新鲜：健壮的类型系统、标准的格式化工具、严格度拉满到 11 档的 linter，再加上测试、测试，以及更多的测试。全部在 CI 中运行。对于性能敏感的工作负载，这些测试还包括会被跟踪的基准测试。随时间跟踪软件性能，可以让你在 CI 中捕获性能回归。这就叫持续基准测试。实施持续基准测试向来有点麻烦。只有那些真的、真的很在乎性能的团队才会去做，而他们也都成了 Bencher 的优质用户！
不过，随着智能体的出现，用 Bencher 把持续基准测试加入你的工作流，开销只剩下一条简短的提示词。虽然很难完全追踪，但我敢打赌，Bencher 现在绝大多数的主动注册，要么来自智能体的推荐，要么干脆就是智能体自己完成的。随着越来越多的开发者采用智能体，并通过智能体商务赋予它们消费能力，这种情况只会越来越普遍。也许是 x402 协议，也许不是，但我认为未来很多开发者工具的支出都将由智能体来经手。如果你还没有预留 Cloudflare Wallet 和 Stripe Wallet，我建议你赶紧去预留。
在智能体时代，几乎所有开发者工具都需要转向基于用量的定价。当使用你服务的是智能体时，按席位定价就说不通了。Bencher 一直采用基于用量的定价。不过，在 Claude 的帮助下，我最近改造了定价模型，让它对智能体更加友好。以前，Bencher 按指标（Metric）收费。一个指标是某个时间点的单次基准测试结果。例如，如果你有 1 个基准测试并运行了 5 次，就会产生 5 个指标。Claude 帮我分析了用户反馈和使用模式。我得出的结论是，我们基于用量的定价模型所使用的计量单位需要改变。现在，Bencher 按基准测试序列（Benchmark Series）收费。一个基准测试序列是随时间被跟踪的一个基准测试。回到我们的例子，如果你有 1 个基准测试并运行了 5 次，那就是 1 个基准测试序列。这种新的定价模型给了用户更强的可预测性。你可以把一个优化问题交给智能体，它可以在你的历史基准测试上不断爬山优化，而不会产生任何额外费用。
过去这一年里，我没看到有什么变化的一件事是开源贡献。Bencher 收到过几个 AI 垃圾 PR。这些 PR 的主要问题在于，它们修复的是一些随机的、毫不相干的 bug，只是顺路碰巧发现的。不过那些确实是真正的 bug！所以我只好耸耸肩，在让我自己的智能体审查过之后（当然）把这些 PR 合并了。这有点令人难过，但我已经看不到去争取开源贡献者有多大好处了。不管花的是他们的 token 还是我的，我在审查代码上都得投入同样多的精力。如今，审查一个贡献者的 PR 比我自己和 Claude 一起迭代要费劲得多。
持续基准测试的未来是什么？
想要预测未来会怎样，规律似乎是去看前沿实验室自己在做什么。看起来，我们所有人六到十二个月后都会走到那一步。The Pragmatic Engineer 的文章《Inside OpenAI’s agentic software factory》从持续基准测试的角度揭示了一些有趣的东西：
新增：“perf harness”：智能体还会使用一个 perf harness， 把有问题的 PR 发送到 Synthetics A/B 框架，以评估其对性能的影响。 如上所述，过去六个月里 CI 系统的负载大幅增加。
OpenAI 的 “perf harness” 看起来与相对持续基准测试这一成熟实践非常相似。真正新颖的 AI 部分，在于 A/B 框架中的合成环节。合成测试数据并不新鲜。但能够自主地塑造这些合成数据来评估手头变更集的性能，这绝对是新东西！让开发者真正动手写基准测试，向来是最难的。现在它被自动化了。就像智能体大幅提高了功能测试覆盖率一样，它们也让我们能够大幅提高性能测试覆盖率。
在这条路上，OpenAI 并不孤单。Anthropic 随后不久就发表了《How we made claude.ai 3x faster in two weeks》。文中他们同样描述了即时构建基准测试的做法。一个关键区别是，Anthropic 找到了一些与性能相关的确定性计数：指令数、每次交互的提交数、函数调用、样式重新计算以及 DOM 变更。随后 Claude 对这些计数进行爬山优化，以提升他们应用的性能。在优化流程结束时，他们检查了这些基于计数的优化是否真的带来了现实世界中挂钟时间的改善。
这些方法论与我自己开发 Bencher 时的亲身经历不谋而合。不过，我的 A/B 性能测试都是在本地或智能体的工作机上运行的，而不是在 CI 循环中。每当我要对某个查询做大的改动，或进行一次有分量的 schema 迁移时，我都会让 Claude 对这项改动做一次详尽的性能评估。这始终包括挂钟时间，偶尔还包括一些相关的确定性计数（例如 SQLite 虚拟机指令数）。
由于“吵闹的邻居”问题，这些由智能体主导的性能优化流程的误差范围一直相当大。我打算为 Bencher Bare Metal 添加 fixtures（额外的基准测试输入）和 artifacts（额外的基准测试输出），以便让我的智能体更有把握地运行这些性能优化任务。智能体仍然会在本地完成大部分优化工作，尽其所能地针对挂钟时间或确定性计数进行爬山优化。然后，它会使用 Bencher Bare Metal 来检验自己的工作，就像一把测量挂钟时间的卡尺。
尽管我认为一年左右之后，Bencher 的大多数“用户”都会是智能体，但我仍然认为，大多数人类在查看进展时还是会想要一个可视化界面。我目前正在 Claude 的帮助下，深陷于对 Bencher UI 的全面重新设计之中。作为一名在 GitHub Copilot Tab 自动补全的年代写着 Anyscript 的 Rust 工程师，现在这套 UI 还有很多不尽如人意之处。不过，UI 的重写被另一项更加雄心勃勃的大改造挡住了：新版本的 Bencher Metric Format (BMF)。
BMF 是 Bencher 内部用来规范化基准测试结果的核心格式。它贯穿一切。新版本的 BMF 将允许对基准测试进行参数化。你可以写 my_benchmark，并带上参数 size: 16 MB 和 size: 32 MB，而不必拆成两个独立的基准测试 my_benchmark_16_mb 和 my_benchmark_32_mb。新版本的 BMF 还将允许任意的指标名称。你可以为 Latency 度量提供 mean、p95 和 p99 指标，而不是只能有 mean，或者不得不把 Latency (mean)、Latency (p95) 和 Latency (p99) 做成三个独立的度量。
支持这个新版本的 BMF，是对 Bencher 核心的一次大规模改造。在 Fable 5 之前，用任何模型来做这项工作我都不会放心。正如上文所说，大部分 Bare Metal 的工作都与 Bencher 的核心正交：随时间跟踪性能，并在出现回归时发出警报。而 BMF 正处于这一核心价值主张的中心。我对 Fable 5 的信任，以及对 Fable 5.1 和 Opus 5.5 更甚的信任，再一次让我得以着手一个原本需要耗费好几年晚上和周末才能完成的项目。以前我不得不花相当多的时间来为 Bencher 优化 SQLite。现在，每次我演进数据模型时，我只需让 Claude 启动一个智能体做一次彻底的性能调查，确保一切依然高性能。将来，我觉得我连开口都不用了。
我如今怎样写代码
当年我用 GitHub Copilot 的时候，它是 VSCode 里的一个扩展。刚换到 Claude Code 时，我用的是 CLI。我会开三个终端窗口，每个都放在各自的 macOS Space 里。每个终端窗口有两个标签页。一个标签页给 Claude，另一个给 Jujutsu (jj)。那时我仍然自己管理版本控制和 jj workspace。
如今，我只用 Claude Code 桌面应用。我开启的每一个新会话，都是从我的元仓库出发，并勾选了 worktree 复选框。几个月前我就不再用 Plan mode 了。我从来没装过 Matt Pocock 的 /grill-me 技能。我只是在提示词里让 Claude “就所有设计决策对我进行拷问”，到了这个阶段，模型已经知道该怎么做了。我的 CLAUDE.mdAGENTS.md 已经被调校得相当贴合我希望模型表现的方式。
我的 Claude Review CI 工作流基本上已经退役了。现在，智能体会在本地自行启动一个对抗式审查者，根本不用我开口。然后它们反复迭代直到达成一致，有时多达六轮左右。我也开始尝试把开发工作卸载到外部的工作机上，只把本地机器留作编排者。
我现在唯一会亲自碰版本控制的时候，是要检出某个构建亲自测试东西，或者要为 Bencher 创建一个打了标签、带版本号的发布。这两件事分别大约每周一次和每月一次。除此之外，我现在都交给 Claude 处理。我大量使用草稿 PR，而且既然 GitHub 上已经可以用了，还有堆叠 PR。PR 打开之前，我不看代码。我仍然会把 Bencher 的代码滚动浏览一遍，但到了这个阶段，这更像是一次合理性检查，而不是真正的代码审查。
一年后，当我回过头来重读这里写下的文字时，会不会又来一次“你居然连 AI 都没提‽”的时刻？我有一半觉得那该有多棒。另一半则怕得要死。
Bencher: 持续性能基准测试
Bencher是一套持续基准测试工具。 你是否曾经因为性能回归影响到了你的用户？ Bencher可以防止这种情况的发生。 Bencher让你有能力在性能回归被合并 之前 就进行检测和预防。
- 运行: 使用 完全相同 的裸机运行器和你喜爱的基准测试工具，在本地或CI中执行你的基准测试。
bencherCLI在裸机上编排你的基准测试运行并存储其结果。 - 追踪: 追踪你的基准测试结果的趋势。根据源分支、测试床和度量，使用Bencher web控制台来监视、查询和绘制结果图表。
- 捕获: 使用 完全相同 的裸机硬件，在本地或CI中捕获性能回归。Bencher使用最先进的、可定制的分析技术在它们被合并之前就检测到性能回归。
基于防止功能回归的原因运行单元测试，我们也应该使用Bencher运行基准测试以防止性能回归。性能问题就是错误！
开始捕捉性能回归 — 免费试用Bencher Cloud。