梦想把规格交给智能体，合上电脑做三明治，回来工作已完成、测试并提交。实际做好三明治回来，它只写了一段，礼貌问是否批准设计第 1 节；接着第 2、3 节及规格说明和计划都要批准，执行只求最快。随后它逐个构建任务并审核、修复、复审，进度日志像列车滚过，终端刷新后仍在任务 3，回邮件还是任务 3，我只好再做三明治让手有事做，此时任务 4 正在审核。

我曾梦想：把一份规格交给一个智能体，合上笔记本，去做个三明治，回来时工作已经完成、测试通过并已提交。

实际情况是这样的。我交出了规格，做了三明治，回来后发现智能体只写了一段，然后非常礼貌地问我是否批准设计的第 1 节。

我批准了，坐下来等着。

第 2 节，批准吗？批准。第 3 节，批准吗？批准。规格呢？批准。计划呢？当然批准，那是我刚看着你写的计划。那希望我怎么执行这个计划？“怎么最快就怎么来，拜托了。”

接着它开始构建。先做一个任务，然后评审这个任务，再修复评审中发现的问题，再复审修复结果，然后才进入下一个任务。我看着进度日志像平交道口前的火车一样滚过：停不下来，也超不过去，而且不知道后面还剩多少节车厢。

我刷新终端，还在任务 3。回封邮件，还在任务 3。纯粹为了手上有事可做，我又开始做第二个三明治。任务 4，正在评审。

三明治非常好吃，但软件还不存在。最糟的不是时间，而是我离不开。每次走开，回来都会碰到一个已经等了二十分钟、等我输入“是”的问题。

我不想要一个每四分钟就需要我的协作者。我要的是承包商：这是规格，这是钥匙，做完叫我。

于是我构建了 superlite：一个 Claude Code 插件，它会规划构建，把任务拆成可以并行运行的部分，把每个任务交给能做好它的最便宜的智能体，检查任务之间的接缝，并评审结果。然后，在你忙着做三明治时，它会留下一份整齐的清单，记录它做的每一个决定。

我会说明它为何存在、如何工作以及如何使用；基准测试是为了证明，我说它快并不是因为它是我写的。

我为什么构建它

先声明一下：我很喜欢 superpowers，不想收到愤怒的邮件。我经常用 superpowers。它是一种谨慎、协作的工作流，让人类紧跟每一步，而且在这方面确实非常出色。superlite 毫不客气地借用了它的骨架：插件布局、会话启动钩子、生命周期技能。该致谢的地方致谢，甚至还要多谢几分。

但当我已经非常清楚自己想要什么时，大部分时间都花在工作流等待自己上面。我像可疑的周末之后查银行流水那样分析了它，时间主要去了五个地方：

• 每个功能有 8 到 12 个人工关卡。 每条消息只问一个问题，设计按节批准，然后分别评审规格、计划以及执行计划的方法。这非常彻底，但也正是四小时会议被排进日程的方式。
• 严格顺序执行。 一个实现者，然后一个评审者，再下一个任务。在我的第一个基准测试中，这是一条 21 次派发的单文件队列，就像一家银行只有一个柜员，而柜员还去吃了一顿很长的午餐。
• 每个任务后都评审，并产生复审循环。 34 分钟的构建里约有 12 分钟花在这上面。
• 多个技能反复运行完整测试套件。 以防它改了主意。
• 关键路径上的 Opus 子智能体， 写代码的速度大约是 Sonnet 的一半。才华横溢、思虑周全，而且一点也不着急。

这些都不是错误。每一个都是合理的安全网。叠在一起时，如果你想掌控每一步，它们很完美；但当你只想把东西做出来时，就有点让人抓狂。

所以 superlite 不是 superpowers 的对手，它是为另一种任务调优的：高速的自主开发。 如果你想掌控每一步，用 superpowers；如果你想交出规格后回来就看到能跑的代码，用 superlite。只是别在同一个会话里同时启用两者。它们共用技能名，都会在启动时注入上下文，而且会像后排座的兄弟姐妹一样吵架。

它是如何工作的

简而言之：一次批准，为并行而写的计划，与工作匹配的智能体，以及由代码强制执行的规则——因为事实证明，智能体读完规则后，还是会按自己的喜好行事。

整体流程是：你的请求先经过一批问题，产出计划，随后多个智能体并行构建，再进入评审与修复，最后完成。

一批问题，一次批准。 superlite 会先判断请求的规模。一个拼写错误直接修掉，不会为这个拼写错误写设计文档。对现有流程的修改，会在聊天里给出简短设计。新项目则会先集中问最多四个问题，然后产出一份设计与计划文档。你只需批准一次。此后，它只会在遇到破坏性、对外可见或涉及安全的事情时停下。你中午去拿饭时，它不会把代码推到 main；其他事情它都会做。

你来选择谁主导。 如果用人类编排者，你会在运行前看到完整计划和预测时间表，并批准它。如果用 AI 编排者，则完全不需要你，这取决于你的心情，要么觉得自由，要么觉得有点被冒犯。所有它本来会询问的选择，都会被记录为一条裁决：它决定了什么、为什么，以及如果判断错了代价是什么。你回来时，就能清楚知道该先质疑哪些决定。

为拆分而写的计划。 计划是一张任务图。每个任务都列出它拥有的文件、它消费和生产的确切接口，以及它必须通过的测试。不共享文件且互不依赖的任务会同时运行。这张图决定了构建的并行宽度。在当前的基准测试中，峰值是 18 个智能体同时工作，大约相当于一家小型创业公司的规模，只是没有乒乓球桌。

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

• Opus 负责协调。 它规划和派发任务，且不允许碰代码。基本就是管理层。
• Sonnet 构建大多数任务。
• Haiku 只构建那些不在关键路径上、完全明确的“机械”小任务。实习生干的是定义清楚的那类活。
• Sonnet 评审各个包。
• 一个全新的 Opus 最终评审者会读取由本次运行日志生成的评审包，只返回发现的问题。它永远不被允许修复任何东西，只是指出问题。
• 三个层级的“只修复”智能体接手这些发现，按对原因的理解程度来路由。

用代码设卡，而不是用提示词。 这一点我是吃过苦头才学到的。你可以在提示词里用粗体、全大写、带着感情写下“协调者绝不编辑代码”。协调者会读到它，点点头，然后去编辑代码。所以现在由钩子来强制执行。一个钩子阻止协调者编辑项目代码。另一个钩子会捕获它运行的任何原始 pytest 或 npm test，悄悄转成后台运行，这样测试永远不会阻塞它。还有一个钩子拒绝让任何人按名称杀进程（这事儿说来话长，放在深入篇里）。计划必须先通过 lint --stable 才能开工，而稳定的任务在通过的那一刻就会被派发。

每次运行都被计量。 钩子记录每个智能体的 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。安装正常的话，它会在写任何代码之前先开始头脑风暴。这是智能体工作流的“hello world”；说实话，世界并不需要另一个待办清单，但这是个不错的冒烟测试。

然后：

1. 描述你想要什么。 一段话或一个规格文件就够了，不需要 40 页的需求文档——不过它也会读。
2. 在它询问时选择编排者：是你来检查计划，还是让 AI 包办一切。
3. 让它运行。 像看自然纪录片一样观察项目里的 .superlite/ 目录。progress.md 里有裁决和日志，test-summary.json 有最新测试结果，metrics.jsonl 记录了每个智能体的时间和成本。

你说的话会决定流程走向：

| 场景 | 可以这样说 | | --- | --- | | 新项目 | “根据这份规格给我做一个静态网站生成器” | | 在现有代码上加功能 | “给现有应用加上带列宽的 CSV 导出” | | 调试 | “这个测试在闰日会失败：找出根本原因并修复” | | 小改动 | “把所有 build 改名为 render” | | 完全放手 | “构建 X。我不在，你自己决定” | | 交付 | “我们完成了：收尾这个分支” |

它绝不会在未经你确认的情况下推送或合并。是自主，不是鲁莽。

它真的有效吗？

谁都可以说自己的工具很快。我曾把自己写的一个脚本称为“飞快”，结果它重命名一些文件花了十一分钟。所以下面的每个数字都来自一个无头基准测试框架。它基于 Opus，用同一份规格构建同一个项目，并用一套智能体永远看不到的隐藏测试套件对结果打分。没有偷看，也没有为考试复习。

最近一次运行：16.1 分钟

测试项目故意不是待办清单。它是一个静态网站生成器加上一个电子表格引擎（公式求值器、HTTP API 和浏览器 UI），作为同一个项目从一份规格构建出来，并由 177 个隐藏测试评分。

下面是当前构建的最近一次运行：

| | | | --- | --- | | 从规格到构建完成的墙钟时间 | 16.1 分钟 | | 隐藏测试 | 177 / 177 | | 智能体 | 总共 21 个，最多 18 个同时工作 | | 首批智能体开始构建 | 约 3 分钟后 | | 最终评审 | 30 秒 | | 为任何事停下来询问人类的次数 | 0 次 |

与同一个项目上的 superpowers 相比：

| | 墙钟时间 | | | --- | --- | --- | | superpowers，原版（3 次运行均值） | 33.6 分钟 | | | superpowers，编排版（3 次运行均值） | 23.5 分钟 | | | superlite，最近一次运行 | 16.1 分钟 | 比原版少 52% 时间，比编排版少 31% |

同样是 177 个隐藏测试全部通过，时间大约只用了一半。这是当前构建的一次运行，与同机器上的早期运行对比，所以只能算一个强烈提示，而不是经过同行评审的科学结论。不过，这是一个非常强烈的提示。

它也比自己之前的构建（平均 26.9 分钟）快了 40%。没错，我在和过去的自己竞争，而且这是我唯一能随便欺负的对手。

它是怎么做到的

最近一次运行不是凭空出现的。在更小的任务上，第一次构建就已经很快了：只有 sitegen，九个模块，89 个隐藏测试。

| | superpowers | superlite | | --- | --- | --- | | 墙钟时间 | 34.4 分钟 | 8.8 分钟 | | 隐藏测试 | 89 / 89 | 89 / 89 | | 串行派发链 | 21 次派发 | 3 层 |

大部分速度提升来自消除排队。superpowers 一个接一个派发了 21 个智能体；superlite 派发了 10 个，最多五个同时运行。工作相同，但排队的人少了。

在完整的 177 个测试项目上，早期的一个 superlite 构建与 superpowers 三次对比运行：

| | superpowers | superlite | | --- | --- | --- | | 平均墙钟时间 | 33.6 分钟 | 25.1 分钟 | | 各次运行 | 21.2 / 31.9 / 47.6 分钟 | 21.4 / 23.2 / 30.5 分钟 | | 最快到最慢的差距 | 26.4 分钟 | 9.1 分钟 | | 隐藏测试 | 每次运行 177 / 177 | 每次运行 177 / 177 |

平均更快，而且可预测性高得多。47 分钟的最差情况，区别在于“站会前完成”和“站会后完成——而在站会上你不得不说它快做完了”。

数据也暴露了 superlite 仍在自我等待的地方。构建大约在 13 分钟时完成，之后又有 10 到 18 分钟花在评审、修复，以及协调者在前台运行测试并盯着测试看。因此：

• 协调者失去了编辑代码的能力。 它适应得出奇地好。
• 每次测试运行都移到后台。
• 修复工作交给分层的“只修复”智能体。
• 稳定的任务在计划的其余部分仍在修复时就开始构建。

这就是那次跑出 16.1 分钟的构建。

得到的启示

如果你的智能体工作流很慢，通常不是因为模型在深思，而是因为工作在排队，而且总有东西在不停请求许可。

按接口边界拆分工作。让独立的任务同时运行。把机械步骤挪进脚本。并用代码强制执行重要的规则，因为好好商量只对人类有用，而且只是有时候。

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

在后续文章中，我会更深入地讲 superlite 背后的理念和决策：各种关卡、智能体层级，以及那些我一直深信不疑、直到用数据衡量后才不得不放弃的想法。

讨论气氛整体偏怀疑：多数人认为 Opus 5.5、Sonnet 5.5、Gemini 3.8 Flash 等新一代模型已经把开发流程内化，Superpowers、Superlite 这类外挂技能或框架不再是必需品，反而带来审批摩擦、token 浪费和需要重写的代码。少数人则坚持技能是持久流程，旧模型、低档模型或需要规范产出的场景仍离不开过程约束。

认为新一代模型已内化开发流程，外挂技能框架不再必要甚至有害

• 论据：不少人有类似体验，几个月前 Superpowers 还有用，但现在 Opus 5.5、Sonnet 5.5、Gemini 3.8 Flash 等模型自己会形成规格、默认用户同意并直接构建，回来就能看到规格文档、代码差异和完成证据；泛化技能在新模型上反而伤性能、白烧 token，只保留项目专用 agents.md 就够，甚至 /goal 这种极简入口已经够用，不必再上插件或工厂。也有人用 CC CLI 配合类 cmux 平台，让 agent 自己开标签页展示结果；新版 Claude Project（beta）则被指出已内置类似能力。（较多人）
• 引用： > Opus 5.5 往往会自己发展出规格、默认我同意并直接构建，模型现在似乎不再需要它了。（@jemdiggity）

认为技能本质是持久流程，模型或特定场景仍需要外部过程约束

• 论据：ra 强调不能把“技能好坏”当成宗教争论，技能本质是流程或程序；前沿模型在强化学习阶段学到了不错的流程，但如果没有技能就缺少持久流程，需要流程时仍得靠它。option_greek 补充，旧模型或低档模型可能仍需要，而在新模型上泛化技能反而伤性能、费 token；michelb 也认为轻量头脑风暴、计划、/grill-me 对普通程序员仍有价值，他长期用 Compound Engineering 的头脑风暴和计划功能，但觉得其他技能模仿企业级开发，凡事交给“委员会”反复检查，既慢又费 token，充满形式主义。（少数人）
• 引用： > 技能本质是流程或程序，模型没有技能就没有持久流程；如果你需要流程，就绝对需要这类技能。（@ra）

认为多智能体并行并不划算，会互相干扰且产生需人工重构的代码

• 论据：有人担心多个实现智能体可能互相改对方的工作，额外并行是否推高 token 成本也被直接质疑；ilitirit 分享内部实验结论：Agent Fleets、Swarms 对复杂工作没有速度优势，速度优势被人工重构抵消，生成的代码“正确”但不是团队会写出的样子，长期是否稳也不确定。RamblingCTO 也说把工作交给 agent 时，抽象层级、关键细节或上下文总会弄错，宁可多轮评审也不愿直接交接。（较多人）
• 引用： > 速度优势被手动重构抵消：代码是“正确”的，但根本不是我们任何人会写出来的样子。（@ilitirit）

认为无尽审批提示和仍需人工看护让这类工具失去吸引力

• 论据：PierceJoy 说 Superpowers 只让他觉得酷了一天，随后无休止的审批提示和大幅增加的时间让他放弃；NetOpWibby 抱怨即便用危险模式启动，还是得回来盯着，一个问题等了二十分钟只等用户输入 yes。尽管有指令强调应在最小可检查单元完成前不要请求批准，实际体验里审批和等待并未消失，因此有人觉得 /goal 这类简单入口更实际。（少数人）
• 引用： > 无休止的审批提示和大幅增加的时间让我很快放弃了 Superpowers。（@PierceJoy）

有价值的补充

• wg0 对“Markdown 工业复合体”的技术拆解：模型输出是概率性的，重型 Markdown 流程要把系统状态同时维护在代码和大量 Markdown 文件里；功能或 bug 修复后这些文件也需同步更新，但概率性保证有些地方不会更新或会写入错误信息，后续 agent 加载上下文时会带着错误信息并在任务中途补救，token 消耗被成倍放大，且不一致会随时间累积；他的结论是除了把 agent 当强力工具、把上下文和期望结果放在自己脑子里，别无他法。（@wg0）
• 有评论指出，Claude Project（beta）的新版本已经内置类似能力，不必额外上这类框架。（@hbarka）
• 有人从标题里的拼写错误出发调侃：看到错别字会在“这真是人写的”和“只是装作人写的”之间反复横跳，折射社区对 AI 生成内容的敏感。（@mkirsten）