Superlite：Claude Code 上更快的自主构建插件

田野笔记

我为什么要构建 superlite，一个不每四分钟就请求许可的 Claude Code 自主构建工作流：它是如何工作的、如何使用，以及基准测试。

我有一个梦想。我会把规范交给一个智能体，合上笔记本电脑，去做个三明治，然后回来看到已完成、已测试、已提交的工作。

实际发生的事情是这样的。我交出了规范。我做了三明治。我回来了。智能体写了一段话，正很有礼貌地问我是否批准了设计的第一节。

我批准了。我坐下来。我等着。

第二节。批准？是的。第三节。批准？是的。规范？是的。计划？是的，显然，这就是我刚才看着你写的计划。那我希望计划如何执行？随便用最快的方式，求你了。

然后它开始构建。一个任务。然后是对该任务的审查。然后是对审查的修复。然后是对修复的重新审查。然后是下一个任务。我看着进度日志像平交道口的火车一样滚动：拦不住它，也越不过它，也不知道还剩多少节车厢。

我刷新终端。还在任务 3。我回了一封邮件。还在任务 3。我开始做第二个三明治纯粹是为了让手有点事做。任务 4，审查中。

三明治非常好吃。软件还不存在。最糟糕的不是时间。而是我走不开。每次我走开，回来时，都有一个问题在那里等了二十分钟，等我输入"是"。

我不想要一个每四分钟就需要我的协作者。我想要一个承包商。这是规范，这是钥匙，完成后给我打电话。

所以我构建了superlite：一个 Claude Code 插件，它规划构建，将其拆分为可以并行运行的任务，把每个任务交给能做好它的最便宜的智能体，检查它们之间的接缝，并审查结果。然后它会给你一份它在你忙于三明治时所做的每个决策的整洁清单。

这篇文章涵盖了它为什么存在、它是如何工作的，以及如何使用它。基准测试是为了证明我不只是因为自己写了它才说它快。

我为什么构建它

首先，一个免责声明，因为我喜欢这个项目，不想收到愤怒的邮件。我经常使用superpowers。它是一个精心设计的协作工作流，让人类贴近每一步，并且确实在这方面非常出色。Superlite 厚颜无耻地借鉴了它的骨架：插件布局、会话启动钩子、生命周期技能。功劳归功于它，而且不止于此。

但当我确切知道我想要什么时，大部分时间都花在了工作流等待自己上。我分析了它，就像你在可疑的周末后查看银行对账单一样。时间花在了五个地方：

• 每个功能 8–12 个人工关卡。每条消息一个问题，设计逐节批准，然后分别审查规范、计划和执行计划的方法。它非常彻底。这也是一个四小时会议被安排起来的方式。
• 严格的顺序执行。一个执行者，然后一个审查者，然后下一个任务。在我的第一个基准测试中，这是一个 21 个调度的单文件队列，就像只有一个柜员且午餐时间很长的银行。
• 每个任务后都有审查，并有重新审查循环。34 分钟构建中的约 12 分钟。
• 完整的测试套件，由多个技能重新运行。以防它改变了主意。
• Opus 子智能体处于关键路径上，写代码的速度大约只有 Sonnet 的一半。才华横溢、深思熟虑，丝毫不着急。

这些都不是错误。每一个都是合理的保护措施。叠加在一起，在你想逐步把控时堪称完美，而在只想把东西做出来时又略显让人抓狂。

所以 superlite 并不是超级能力的对手。它是为另一类任务调优的：以速度实现的自主开发。 如果你想把控每一步，用 superpowers。如果你想把规格交出去，回来就拿到可运行的代码，用 superlite。但不要在同一次会话里同时启用两者。它们共用技能名称，都会在启动时注入上下文，而且会像后座上的兄弟姐妹一样吵架。

工作原理

简短版本：一次批准、一个面向并行编写的计划、匹配合适任务的智能体，以及用代码强制执行的规则——因为事实证明，智能体会读规则，然后爱干嘛干嘛。

flowchart LR A([你的请求]) --> B[一批问题] B --> C[计划] C --> D[智能体并行构建<br/>] D --> E[审查与修复] E --> F([完成])

一批问题，一次批准。 Superlite 会先评估请求规模。一个拼写错误就直接修好，不会围绕这个拼写错误产出一份设计文档。对现有流程的改动会在聊天中得到一份简短的设计。新项目则只有最多四个问题的一批提问，以及一份设计加计划文档。你批准一次。之后它只在涉及破坏性、对外可见或安全敏感的事情时才会停下来。它不会趁你吃午饭时往 main 推送。它会完成其他所有事情。

由你决定谁来主导。 由人担任编排者时，你会看到包含预计进度的完整计划，并在任何东西运行前批准它。由 AI 担任编排者时，你完全不需要在场——这要么是解放，要么视心情而定算轻度冒犯。它通常会询问的每一个选择都被记录为一条裁定：决定了什么、为什么，以及如果判断错误会有什么代价。等你回来时，你清楚地知道先该质疑哪些决定。

为拆分而写的计划。 这份计划是一张任务图。每个任务都列出它拥有的文件、它所使用和产出的精确接口，以及它必须通过的测试。不共享文件且彼此不依赖的任务会同时运行。任务图决定了构建能并行到多宽。在当前的基准测试中，并行数量峰值达到了 18 个智能体同时工作，差不多相当于一家小型初创公司的规模，只是少了乒乓球桌。

智能体与工作匹配。 组织架构如下：

• Opus 负责协调。 它做规划和调度，并且不被允许接触代码。基本上就是管理层。
• Sonnet 构建大部分任务。
• Haiku 只构建那些定义明确、不在关键路径上的小型“机械性”任务。实习生负责的是边界清晰的工作。
• Sonnet 审查各个包。
• 全新的 Opus 终审审阅一份由本次运行日志生成的审查包，只返回发现的问题。它永远不被允许修复任何东西。它只负责指出问题。
• 仅修复的智能体分三个层级接手这些发现，按原因被理解的清晰程度来分派。

用代码把关，而非提示词。 我是以惨痛代价学到这一点的。你可以在提示词里用粗体、大写、饱含感情地写"协调员绝不修改代码"。协调员会读一读，点点头，然后把代码改了。所以现在用 hook 来强制执行。一个 hook 阻止协调员修改项目代码。另一个会拦截它运行的任何原始 pytest 或 npm test，悄悄转成后台运行，这样测试就不会阻塞它。还有一个拒绝任何人按名称杀进程（这里有个故事，详见深度文章）。计划必须先通过 lint --stable 才能开工，稳定的任务一通过就立刻派出去。

每一次运行都有量化记录。 Hook 会记录每个 agent 的 token 用量、花费和时间。这些数据会反馈给下一次运行的预测，以及一个软预算——当花销达到上限的 70% 时，它会拍拍你的肩膀提醒你。

如何使用

你需要 Claude Code、git、Python 3.10 或更高版本（用于 superlite 自带的工具；你要构建的项目可以是任何语言），以及 bash（Windows 上用 Git Bash）。

源码在 GitHub 上的 iha2/superlite。从市场安装：

/plugin marketplace add iha2/superlite
/plugin install superlite@superlite-dev

或者克隆 iha2/superlite，为单个会话加载本地检出：

claude --plugin-dir <path-to-superlite>

要检查它是否工作正常，开一个新会话并发送 Let's make a react todo list。安装成功的话，会先动脑再动手写代码。这是 agent 工作流的"hello world"，老实说世界不需要再多一个 todo 列表，但它是一个不错的冒烟测试。

然后：

1. 描述你想要的东西。 一段话或一个 spec 文件就够了。不需要 40 页的需求文档。当然它也能读那么长的。
2. 选择编排者——当它询问时：由你来检查计划，或者 AI 全权处理。
3. 让它跑起来。 像看自然纪录片一样在你的项目中观察 .superlite/。progress.md 有裁定记录和日志，test-summary.json 有最新的测试结果，metrics.jsonl 有每个 agent 的耗时和花费。

你说什么决定流程的走向：

未经你的允许，它绝不会推送或合并。是自主，不是鲁莽。

它真的有效吗？

谁都能吹自己的工具快。我曾把自己写的一个脚本称为"飞快"，结果它花了 11 分钟才改完几个文件名。所以下面每个数字都来自一个无头的基准测试框架。它在 Opus 上、用同一份 spec 构建同一个项目，并用一组 agent 永远看不到的隐藏测试套件来打分。没有偷看，没有临时抱佛脚。

最新一次运行：16.1 分钟

测试项目刻意不是 todo 列表。它是一个静态网站生成器加上一个电子表格引擎（公式求值器、HTTP API 和浏览器界面），由一份 spec 构建成一个项目，并由 177 个隐藏测试打分。

以下是基于当前构建的最新一次运行：

与 superpowers 在同一项目上的对比：

同样以 177/177 通过全部隐藏测试，所用时间约为原来的一半。这是当前构建在同一台机器上与此前几次运行的对比，所以只能算作一个强有力的提示，而非经过同行评审的结论。但这个提示确实非常有说服力。

它还以 40% 的优势击败了自己的上一个版本（平均 26.9 分钟）。没错，我在和过去的自己较量。这是唯一一个我可以随意"欺负"的对手。

它是如何做到的

最近这次运行并非凭空而来。第一个构建在更小的任务上就已经很快了：仅 sitegen，九个模块，89 个隐藏测试。

提速主要来自取消了队列。Superpowers 一个接一个地派发了 21 个代理。Superlite 派发了 10 个，最多同时运行 5 个。相同的工作，排队的人更少了。

在包含全部 177 个测试的项目上，一个更早的 superlite 构建针对 superpowers 运行了三次：

平均更快，而且更加可预测。最坏情况 47 分钟的差距，就是"站会前就完成"和"站会后才完成，开会时你还得说它差不多做完了"之间的区别。

但数据同样暴露出 superlite 还在原地等待的地方。构建在大约 13 分钟时已经收尾，之后却还要再花 10 到 18 分钟用于审查、修复，以及协调器在前台运行测试并盯着它们。于是：

• 协调器失去了编辑代码的能力。它对此接受得出奇地好。
• 所有测试运行都移到了后台。
• 修复工作交由分层的、仅负责修复的代理完成。
• 稳定的任务在计划其余部分仍在被修复时就开始构建。

这就是那个以 16.1 分钟跑完的构建。

结论

如果你的代理工作流很慢，大概不是因为模型在"深思熟虑"。慢是因为工作在排队，而且总有什么东西在不停地请求许可。

沿着接口边界拆分工作。让独立的任务并行执行。把机械化的步骤移入脚本。用代码来强制执行真正重要的规则，因为"好言相劝"只对人有效，而且有时也不灵。

插件已在 GitHub 上开源：github.com/iha2/superlite。

在后续文章中，我会更深入地探讨 superlite 背后的设计理念与决策：各种关卡、代理分层，以及那些我在真正去测量之前一直深信不疑的想法的"坟场"。