1.新出的模型已经学会了这套流程，superpower带来了重复思考
2.子代理（Subagents）带来了重复上下文（利大于弊）
3.很小一个问题也会触发整个流程（新版本虽然可以选择在小任务时不走流程，但依然还是太重了）
一、Superpowers 曾经解决了什么真问题？
在早期的 Agentic Coding（智能体编程）阶段，大模型就像一个“手速极快但缺乏工程纪律的实习生”。如果你只给它一句模糊的需求（即所谓的 Vibe Coding），它会毫不犹豫地朝着错误的方向狂奔，三小时后留给你一堆看似能编译、实则隐患重重的烂摊子。当时 AI 编程面临三大致命痛点：
- 上下文腐化（Context Rot）：随着对话窗口填满，早期指令权重衰减，模型写着写着就忘了最初的安全或架构约束。
- 缺乏测试纪律（No Test Discipline）：模型倾向于生成“看起来合理”的代码，添加新功能时悄悄破坏旧逻辑，却不写任何验证测试。
- 范围漂移（Scope Drift）：你只想要一个基础组件，模型却自作主张帮你搭了一整套复杂的冗余基础设施。
Superpowers 的核心设计假设非常直白：AI 缺的不是编码能力，而是工程结构与交付纪律。它通过一套模块化的技能库（Skills），把人类资深工程师的最佳实践强行编排进了 AI 的执行流中。
如上面的流水线所示，Superpowers 用硬性门禁（Hard Gates）锁死了开发节奏：
BRAINSTORM（明确需求）：禁止直接写代码，先通过苏格拉底式提问澄清目标、约束与验收标准，产出小规格说明（Spec）。PLAN（制定计划）：拆解文件模块清单，明确每一步做什么以及如何验证成功——甚至直接把完整的可运行失败测试写进计划文档。IMPLEMENT（严格执行）：严格遵循 TDD（测试驱动开发）纪律，先写失败测试（Red），再写最小实现（Green），若在测试前抢跑写业务代码，框架甚至会直接删掉重写。REVIEW + VERIFY（自查与验证）：派发子代理（Subagents）在隔离环境中跑单测、查日志、核对 Spec。SHIP（规范交付）：全部验证通过后才合入分支交付。
在模型执行控制力（Executive Function）尚弱的时期，这套流程极大地降低了返工成本。
二、范式转移：当模型内化了「工程直觉」，脚手架为何变成负资产？
既然这套流程如此符合软件工程规范，为什么当模型迭代到新一代时，为什么删掉 Superpowers 后，模型反而变聪明、变快了”？核心原因在于以下四重结构性冲突：
1. 能力内化带来的「二次思考」内耗
早期的模型不会主动规划、不会自觉跑测试，所以需要外部通过几千行的 Prompt 技能树去“教”它怎么做人。但前沿实验室（Anthropic、OpenAI、Google DeepMind 等）一直在通过强化学习（RL）将任务拆解、假设验证、TDD 闭环和边界检查直接训练进模型权重本身。
当一个原生就已经具备优秀工程直觉的模型，被强行套上 Superpowers 的七步机械流程时，相当于逼着模型对同一件事做两次重复思考。外部框架僵化的步骤切分，反而打断了强模型原本连贯的全局深度推理（Extended Thinking）路径。
2. 惊人的 Token 膨胀与上下文污染
Superpowers 采用的是“主代理规划 + 子代理隔离执行”的重型编排模式。在实际工程中，这种模式暴露出了严重的效率黑洞：
- 巨型计划的重复读取：框架常常为了一个中等规模的功能生成长达 4,000 行的实现计划（Implementation Plan），随后每启动一个子代理只负责实现其中的一小步，但每个子代理都必须把这 4,000 行计划完整读入上下文。
- 杀鸡用牛刀的仪式感：与“低风险小改 → 简化流程”的理想状态相反，在真实使用中，许多开发者吐槽：当你只想做一个范围极小、定义极清晰的低风险改动时，看到
superpowers:brainstorming突然启动并开始连环追问，立刻就知道又要白白烧掉 10 倍的 Token 和大把时间去做无用功。
3. 「消融实验」揭示的残酷真相：80% 的旧提示词是负资产
Claude Code 负责人 Boris 曾分享过团队内部一个极具启发性的研究方法——消融（Ablation）。每当发布新一代模型，团队第一件事就是把现有的系统提示词全部删光，甚至开启一个内部环境变量SIMPLE=1，把工具提示也剥得干干净净作为对照组，然后再逐行评估哪些指令真正值得加回来。
实验结果非常反直觉：什么繁琐提示都不给，新模型反而表现得更聪明。
核心洞察：旧框架和旧提示词的绝大部分内容，本质上是在修补上一代模型“本该知道却不知道”的缺陷。当新模型生来就具备这些能力时，三个月前写的长篇约束指令就从“拐杖”变成了“脚镣”。社区里流传的一条经验法则精准概括了这一现象：当规则写到 200 行以上，AI 就开始叛逆。
4. 「流程技能」正在消亡，「品味与环境技能」依然保值
随着模型进化，Skills（技能）正在发生剧烈的两极分化：
| 对比维度 | 弱模型时代（重型 Superpowers 模式） | 强模型时代（轻量化 Harness 模式） |
|---|---|---|
| 核心瓶颈 | 模型执行控制力弱，容易遗忘、跳步、乱写代码 | 外部约束过重导致推理僵化、Token 浪费与速度拖慢 |
| 流程控制方式 | 强制 7 阶段流水线，机械拆解一二三四步 | 只给“任务目标、安全护栏、退出标准”，过程交还模型 |
| 上下文与 Token 消耗 | 动辄生成数千行计划，多子代理反复重读，消耗高达 10 倍 | 按需保持精简上下文，直接面向代码库与测试结果迭代 |
| 最有价值的 Skill 类型 | 编码流程类（Process Skills）：教模型如何头脑风暴、如何写计划 | 品味与私有上下文类（Taste & Context Skills）：架构偏好、部署命令、私有规范 |
| 验证与质量保障 | 靠 Prompt 扮演 Reviewer 角色互相审查 | 靠确定性的编译器、Linter 与自动化测试套件做刚性裁判 |
正如资深开发者在社区复盘时所言：编码“通用工作流（Process）”的技能正在被大模型自身吞噬；唯一还值得保留的，是编码了“模型绝对猜不到的私有信息”与“工程品味（Taste）”的极简约束。
三、从「重装马鞍」到「轻量化 Harness」：AI 编程的新平衡
卸掉 Superpowers 并不意味着回到毫无章法的 Vibe Coding，而是意味着我们的工程重心正在从“用 Prompt 手把手教模型走流程”转向构建真正轻量、确定性的Harness（马具/工程底座）。
下图清晰地拆解了当前 AI Agent 架构演进的核心公式（Model + Harness = Agent）以及官方与开源生态是如何重新定义 Harness 边界的：
[配图位置：Model 与 Harness 的现代分工架构图]
图注：模型决定能力上限，Harness 决定能发挥多少——每隔几个月，把 Harness 削薄到适配新模型本身
仔细观察上述架构，你会发现现代 AI 编程架构对Harness做了极其克制的收敛：
Guides · 前馈控制（越来越薄）：也就是AGENTS.md、系统提示词或.cursorrules。它只负责行动前的方向引导与意图对齐（IntentGate），不再堆砌几千行的流程教条，而是随着模型变强不断做减法。Sensors · 反馈控制（越来越硬）：也就是Linter、TypeCheck、Build以及自动化测试套件。模型写得好不好，不再靠另一个子代理用长篇大论的 Prompt 去“主观评审”，而是直接交给确定性的工程工具做刚性验证。- 底层解耦（
Brain+Hands+Session）：未来的范式是将推理规划（Brain）、沙箱与工具执行（Hands）以及持久化会话日志（Session）清晰解耦。
一个极具说服力的真实案例来自Bun 团队：他们将自家的 JavaScript 运行时从 Zig 重写为 Rust，代码量高达十万行级别。他们没有使用像 Superpowers 那样繁琐的多阶段交互式提示词框架，而是拿现成庞大的测试套件当确定性裁判（Sensors），只用一个清晰的 Prompt 启动，让模型自主跑了 11 天，最终产物直接达到了生产环境可用标准。
正如那句经典的工程总结：“模型决定能力上限，Harness 决定能发挥多少——每隔几个月，把 Harness 削薄到适配新模型本身。”
四、实操指南：如何给你的 AI 编码代理「科学松绑」？
如果你发现手头的 AI 编程助手在挂了各种插件和 Skills 后变得啰嗦、缓慢、经常陷入死循环，不妨按照以下三步“经验科学处方”给它做一次彻底的减负：
- 第一步：备份并清空（每半年做一次消融）
将你现有的CLAUDE.md、.cursorrules和.claude/skills提交进 Git 备份，然后卸载像 Superpowers 这样的重型流程插件，从零开始。记住：所有外部 Harness 的保质期只有半年。 - 第二步：只给三样东西——任务、护栏、退出标准
摒弃老工程师习惯的“过度具体化（Over-specification）”毛病，不要在 Prompt 里写一二三四步的实现过程。像对待一位资深人类同事那样，只明确告诉模型：你要解决什么问题（任务）、哪些红线绝对不能碰（护栏）、以及跑通哪条测试命令算完工（退出标准）。 - 第三步：观察它在哪绊倒，按需最小化补回
不要去“猜”模型需要什么指令——你大概率会猜错。直接让裸模型在真实代码库里跑，只有当它在同一个地方反复绊倒时（例如项目特有的构建脚本、非标准的内部鉴权约定），才把那条最小化的规则写回配置文件中。
技术演进最迷人的地方莫过于此：当年帮我们跨越鸿沟的脚手架，终究会在大楼封顶时被拆除。
