Superpowers：GPT-5.6 时代下的流程毒瘤

一个日均消耗约 3 亿 token 的重度使用者，为什么最后选择把它从工作流里拆掉

先说结论：我不是被模型拖慢，是被流程拖慢

今天下午，我又被一个任务折磨了一遍。

这不是一个需要数天架构设计的项目，也不是支付、权限、数据迁移这种必须多人审查的高风险改动。按正常的工程节奏，应该是理解需求、定位代码、做一个小改动、跑相关测试，然后结束。真正动手的时间可能并不长。

但在 Superpowers 的工作流里，一个小任务很容易被拉成一条完整的仪式链：先判断有没有 skill 适用，再进入头脑风暴，再写设计，再等确认，再写计划，再决定要不要建 worktree，再为每个任务派实现代理，再派规格评审，再派质量评审，最后还要重新验证、收尾、汇报。

每一步单独看都能找到一个听起来合理的理由。问题是，工程效率不是把所有合理步骤都叠在一起。工程效率是用足够低的成本，获得足够高的正确率。

Superpowers 最大的问题，恰恰是把"谨慎"变成了默认，把"流程"变成了目的，把一个本来可以直接完成的任务变成了对流程本身的服从测试。

我不是反对测试，也不是反对审查，更不是反对子代理。我反对的是：在 GPT-5.6 这样的强模型时代，还把一套为不稳定、低自主性代理设计的长流程，当成所有任务的统一宗教。

我是谁，以及为什么我会对这个问题这么敏感

我不是偶尔打开一次聊天窗口、问一个问题就离开的用户。按我自己的使用统计口径，我日均消耗大约 3 亿 token。这个数字不是行业基准，也不是给任何产品做宣传的指标，它只是我的工作现实：大量代码阅读、长上下文分析、跨模块修改、调试、部署、文档整理和反复验证，都在同一个 AI 工作流里完成。

高频使用有一个好处：很多流程在第一次体验时看不出问题，重复几十次以后，问题会自己浮出来。

你会开始分辨哪些步骤真的降低了错误率，哪些步骤只是让模型显得很认真；哪些输出帮助了决策，哪些输出只是把已经知道的事情再解释三遍；哪些评审抓住了缺陷，哪些评审只是把"没有发现问题"包装成一份新的报告。

当你一天只做一个任务时，多十分钟的流程可能不明显。当你一天做几十个任务，或者让模型持续工作数小时，所有额外步骤都会变成真实的延迟、真实的 token、真实的上下文污染和真实的注意力损耗。

所以我对 Superpowers 的不满，不是来自一次偶然的不顺手，而是来自高频使用后越来越清楚的成本账。

Superpowers 到底把什么叠在了一起

我盘点了本机缓存中的 Superpowers v5.1.3。它一共有 14 个 skill，核心规则文本约 3207 行。它们大致分成几组：

• 需求与计划：brainstorming、writing-plans、executing-plans
• 子代理与并行：subagent-driven-development、dispatching-parallel-agents
• 工作区与交付：using-git-worktrees、finishing-a-development-branch
• 测试与调试：test-driven-development、systematic-debugging
• 评审与验证：requesting-code-review、receiving-code-review、verification-before-completion
• 全局入口与元流程：using-superpowers、writing-skills

单个 skill 的存在并不等于每次都会加载完整正文。真正让事情变重的是它们之间的默认连接关系：

using-superpowers
    -> brainstorming
    -> writing-plans
    -> using-git-worktrees
    -> subagent-driven-development
    -> implementation
    -> spec review
    -> quality review
    -> verification
    -> finishing-a-development-branch

这是一条适合大型、高风险、多人协作项目的保守流水线，不是一条适合所有日常代码任务的默认路径。

效率：每一步都合理，串起来就不合理

下面是这条链中几类常见步骤的真实成本。

步骤	它声称解决的问题	对小任务的实际代价
全局 skill 检查	避免漏掉流程	每次对话都增加判断和解释，模型先讨论"该不该开始"
头脑风暴	避免需求误解	配置、单函数、文档改动也被迫走设计和审批
详细计划	降低执行偏差	计划本身变成第二份规格，耗时可能超过实现
worktree	隔离改动	在已有隔离环境里重复创建隔离，产生无效操作
实现代理	分离上下文	重新传递背景、目标、文件和约束，增加等待和同步
规格评审	检查是否符合需求	对明确的小改动，常常只是复述需求
质量评审	检查代码质量	需要再次读取 diff 和上下文，可能提出低价值风格意见
收尾流程	统一合并和交付	对不需要 PR 或分支操作的任务，完全是额外仪式

关键不是某一步需要多少秒，而是这些步骤有顺序依赖。前一步没有结束，后一步不能开始。用户需要回答更多确认问题，模型需要发更多状态消息，工具需要产生更多中间文件，整个任务的尾延迟被不断拉长。

最荒谬的场景是：代码改动本身只有几行，流程产物却包括设计说明、计划、任务清单、实现报告、规格评审报告、质量评审报告和最终验证报告。最后真正改变系统行为的，可能只有一个条件判断。

这不是严谨。这是流程和任务规模失配。

Token：最贵的不是代码，是重复解释

很多人谈 token 成本时，只盯着模型生成的代码。实际更昂贵的部分，往往是被流程强迫重复传递的上下文。

一个简化的成本模型可以写成：

总成本
= 主代理上下文
  + 实现代理次数 × 任务上下文
  + 评审代理次数 × diff 与需求上下文
  + 失败重试 × 全部上下文
  + 流程状态消息与报告

在单代理直接执行时，任务上下文通常只需要被理解一次。进入子代理开发后，同一份需求至少要被主代理整理一次、实现代理读取一次、规格评审读取一次、质量评审再读取一次。任务越多，重复越明显。

而且这些上下文并不是免费的摘要。为了让每个代理"独立"，控制器要把任务背景、文件范围、约束、预期输出和当前状态重新写出来。评审代理还要重新建立自己的判断上下文。你以为你在买更高质量，实际上也在为同一份信息付多次入场费。

更大的问题是 token 不只影响账单。上下文越长，模型越容易把注意力放在流程文档、状态报告和评审意见上，而不是放在真正的代码因果关系上。模型开始优化"如何证明自己遵守流程"，而不是"如何最快地解决问题"。

对于日均消耗约 3 亿 token 的工作流，这种重复不是抽象的效率损失，而是巨大的资源浪费。

评审到底有没有用？有，但不应该成为宗教

评审当然有用。安全边界、权限模型、支付逻辑、数据迁移、并发控制、公共 API 和跨服务契约，都值得第二双眼睛。问题在于，评审的价值高度依赖风险，而 Superpowers 把它做成了默认税。

可以用一个很简单的判断表：

任务类型	自动评审的潜在收益	是否值得强制多轮评审
修改文档、配置、文案	很低	不值得
单文件局部修复	低到中	通常不值得
已有测试覆盖的普通业务逻辑	中	一次针对性检查即可
跨模块重构	高	可以考虑一次独立评审
权限、支付、安全、数据迁移	很高	建议人工或独立评审

强制评审的问题有三个。

第一，评审代理不天然比实现代理更懂业务。它可能发现真正的缺陷，也可能把个人风格偏好当成规范问题。最后主代理还要花时间判断评审意见是否成立。

第二，规格评审和质量评审的边界并没有想象中清晰。规格不完整会变成质量问题，质量风险又经常需要回到需求语义。拆成两个代理，不一定得到两倍的洞察，通常只得到两份相互重叠的文字。

第三，评审会制造一种危险的安全感。报告写得很完整，不等于系统真的正确。真正有价值的验证仍然是可执行的测试、可复现的行为、清晰的监控和真实的用户反馈。

评审应该是风险工具，不应该是忠诚度测试。

GPT-5.6 时代，为什么这套东西更容易显得逆天

早期代理确实需要更多脚手架。模型可能不理解上下文，容易忘记目标，不能稳定拆任务，也不擅长自我检查。于是人们把工程经验写成一条条硬规则，试图用流程弥补模型的不可靠。

但模型能力在变化，流程却很容易固化。

GPT-5.6 这一代强模型已经能够在同一个上下文里完成代码理解、方案选择、修改、测试和纠错。它不意味着模型永远正确，也不意味着工程纪律可以消失，但它意味着默认工作流应该允许模型根据任务风险调整策略。

如果提示词写成"只要有 1% 的可能就必须调用 skill"，模型就没有风险判断空间。如果写成"任何项目都必须先设计，即使是一个配置改动"，模型就不能根据任务规模收缩流程。如果写成"没有失败测试就不能写生产代码"，模型就会把测试形式本身当成目标。

这不是在增强模型，而是在压缩模型的有效自由度。

模型明明可以用十分钟解决问题，却被要求用十分钟解释为什么现在还不能解决问题。模型明明可以根据风险选择一次验证，却被要求证明自己完成了完整仪式。最终用户看到的不是更聪明的工程师，而是一个不停填写流程表格的工程助理。

最逆天的不是某个步骤，而是那些硬门槛措辞

Superpowers 里有几类措辞特别能说明问题。

using-superpowers 的原始规则要求：只要有 1% 的可能适用，就必须调用 skill，而且任何回复或行动之前都要先检查。

brainstorming 的原始规则要求：任何项目都必须先设计。它甚至把 todo、单函数工具和配置修改列为不能跳过的案例，并要求写设计文档、提交、等待用户审阅，再进入计划。

test-driven-development 的原始铁律是：没有先看到失败测试，就不能写生产代码。

verification-before-completion 的原始规则则把成功表达、提交、创建 PR、移动到下一任务，甚至派发代理，都纳入重新验证的范围。

这些句子单独看都像是在保护质量。放在一起，就变成了一个优先保护流程、其次才保护结果的系统。

真正成熟的工程规范应该写成"在风险足够高时这样做"，而不是"永远这样做"。把例外全部当成懒惰，把简化全部当成违规，最终只能让模型更擅长服从文本，不能让软件更可靠。

我最后做了一个本地实验：14 个变成 6 个

我没有继续争论"这套方法论理论上有没有价值"，而是直接做了一个本地精简实验。

原来的 14 个 skill 中，我移除了：

• subagent-driven-development
• dispatching-parallel-agents
• requesting-code-review
• receiving-code-review
• executing-plans
• using-git-worktrees
• finishing-a-development-branch
• writing-skills

剩下的 6 个 skill 被改成轻量版本：

• 需求真正不清楚时，才做简短 brainstorming。
• 多文件、存在顺序依赖时，才写短计划。
• 复杂 Bug 才做系统调试，简单错误直接修。
• 行为复杂、测试收益明确时才采用测试优先。
• 非平凡任务结束前跑一次针对性验证。
• 用户明确要求时，才考虑额外流程。

结果是，核心 SKILL.md 从约 3207 行降到 110 行。这个数字不是性能基准，也不能证明所有团队都应该这么做，但它证明了一件事：原来的复杂度并不是工程问题本身必然要求的，而是规则叠加出来的。

我还增加了一条更直接的全局偏好：除非用户明确要求，否则不派子代理，不派自动评审代理，默认由主代理完成实现并做一次针对性验证。

这才更接近我想要的 AI 工程师，而不是 AI 流程管理员。

我认为 GPT-5.6 时代的工程规范应该是什么样

我不主张把所有规范都删掉。我主张把规范分级。

Lite：默认模式

适用于文档、配置、单文件修改、简单 Bug 和明确的小功能。

理解目标 -> 修改 -> 针对性测试或检查 -> 说明结果

不写长设计，不建 worktree，不派代理，不做自动评审。

Standard：普通复杂任务

适用于多文件改动、存在接口影响或需要明显顺序的功能。

短计划 -> 实现 -> 相关测试 -> 一次自检

计划的目标是减少遗漏，不是制造一份比代码更长的文档。

Strict：高风险任务

只在安全、支付、权限、数据迁移、公共 API、跨服务契约和重大重构中启用。

设计讨论 -> 计划 -> 实现 -> 独立评审或人工评审 -> 集成验证

即使是 Strict，也应该由用户或项目负责人明确选择，而不是由一个"1% 可能性"自动触发。

这种分级并不降低标准。它把标准用在真正需要的地方，把时间留给真正重要的判断。

不是反对纪律，是反对把纪律变成目的

今天下午最让我烦的，不是模型犯了一个错。模型犯错是可以接受的，至少错误是可见的，可以复现，可以修复。

让我烦的是，在一个本来可以快速闭环的任务里，我不断看到新的流程、确认、报告和评审。每一项都在告诉我系统很谨慎，却没有同等力度地告诉我系统离结果更近了。

我宁愿让模型在一个低风险小任务上直接做出一个可以被测试发现的错误，也不愿它先花大量 token 证明自己知道什么叫规范。我宁愿自己看一眼 diff、跑一次测试，也不愿为一份低价值评审报告再启动一个上下文、再等待一次结果、再判断一次判断是否值得相信。

AI 工具的价值，是把人的判断力放大，把执行成本压低。一个工作流如果让人花更多时间等待流程、解释流程、批准流程，最后才轮到解决问题，那它就已经偏离了工具的目的。

Superpowers 曾经试图把经验固化成护栏。问题是，护栏太多、太密、太低，最后就不再是护栏，而是一条把所有车辆都强行降速的窄路。

在 GPT-5.6 时代，我们需要的是有判断力的工程纪律，不是无差别的流程服从。

我并不想让模型少思考。我只是希望它把思考用在代码、数据和结果上，而不是用在证明自己完成了多少个仪式。

这就是我为什么说：对高频 AI 工程工作而言，未经分级、未经风险校准、默认强制评审和子代理的 Superpowers，已经从"能力增强"变成了"效率毒瘤"。

技术附录：这不是情绪，而是可以定位的机制问题

原始规则里的几个硬触发点

下面这些不是我对 Superpowers 的二次概括，而是它在 skill 文件中使用的典型硬门槛。文件名就是它们在插件里的实际位置。

文件	原始倾向	运行时后果
skills/using-superpowers/SKILL.md	"只要有 1% 的可能适用，就必须调用"	低置信度判断也会触发完整流程
skills/brainstorming/SKILL.md	"这适用于每一个项目，包括简单配置修改"	小改动不能直接开始
skills/writing-plans/SKILL.md	要求把工作拆成完整、可执行的计划任务	计划成本和实现成本倒挂
skills/subagent-driven-development/SKILL.md	每任务新建实现代理，再做规格和质量评审	一次改动变成多次上下文交接
skills/requesting-code-review/SKILL.md	每个子任务、重大功能、合并前都要求评审	评审从风险工具变成固定税
skills/verification-before-completion/SKILL.md	任何完成表达、提交、下一任务前都要新鲜验证	状态沟通也会触发额外检查

这些规则的共同问题不是"完全错误"，而是把"通常有帮助"写成了"永远必须"。一旦触发条件过宽，模型就无法根据任务规模和失败代价做正常的工程取舍。

1. 规则触发层

skill 的 frontmatter 描述会参与触发判断。只要描述写成"任何对话""任何功能""任何 Bug"，触发面就会极度扩大。全局入口再要求"1% 可能适用也必须调用"，等于把低置信度判断变成高频加载。

2. 上下文复制层

子代理架构需要把任务背景重新包装给每个代理。实现代理、规格评审代理和质量评审代理往往分别读取同一份需求和 diff。任务本身没有增加，输入上下文却被复制了多次。

3. 交互等待层

代理调用通常存在启动、等待、汇总和重试。即使每次代理都很快，串行依赖仍会把总耗时拉长。用户等待的不是代码计算时间，而是多个角色之间的交接时间。

4. 判断污染层

当上下文中同时存在需求、计划、实现报告、评审报告和修复意见，模型必须花额外注意力判断哪一层才是当前事实。越多过程文档，不一定越清晰，可能只是增加了状态冲突的机会。

5. 质量收益递减层

第一次针对性测试通常能发现最直接的问题。第二次独立检查可能发现边界条件。第三次对同一小任务做形式不同但信息高度重叠的评审，收益往往快速递减。流程没有把这个递减曲线纳入决策，就会把低收益检查当成固定成本。

6. 正确的控制变量

真正应该控制的不是"有没有调用某个 skill"，而是：

• 变更风险有多高；
• 失败的代价有多大；
• 是否存在独立的知识盲区；
• 是否有可执行的验证手段；
• 用户是否明确需要额外审查。

这些变量决定了流程强度。任何脱离风险、只按关键词触发的固定流程，最终都会在简单任务上浪费资源，在复杂任务上制造虚假的安全感。