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。每当发布新一代模型团队第一件事就是把现有的系统提示词全部删光甚至开启一个内部环境变量SIMPLE1把工具提示也剥得干干净净作为对照组然后再逐行评估哪些指令真正值得加回来。实验结果非常反直觉什么繁琐提示都不给新模型反而表现得更聪明。核心洞察旧框架和旧提示词的绝大部分内容本质上是在修补上一代模型“本该知道却不知道”的缺陷。当新模型生来就具备这些能力时三个月前写的长篇约束指令就从“拐杖”变成了“脚镣”。社区里流传的一条经验法则精准概括了这一现象当规则写到 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 Agent现代 AI 编程分工架构极简方向引导代码产出确定性报错反馈闭环Sensors · 反馈控制越来越硬Compiler / TypeCheckLinter 静态检查自动化测试套件刚性裁判Guides · 前馈控制越来越薄AGENTS.md / CLAUDE.md架构品味与私有环境约定安全红线与意图对齐Core Model持续进化Brain原生推理与规划Hands沙箱与工具执行Session持久化状态管理[配图位置Model 与 Harness 的现代分工架构图]图注模型决定能力上限Harness 决定能发挥多少——每隔几个月把 Harness 削薄到适配新模型本身仔细观察上述架构你会发现现代 AI 编程架构对Harness做了极其克制的收敛Guides · 前馈控制越来越薄也就是AGENTS.md、系统提示词或.cursorrules。它只负责行动前的方向引导与意图对齐IntentGate不再堆砌几千行的流程教条而是随着模型变强不断做减法。Sensors · 反馈控制越来越硬也就是Linter、TypeCheck、Build以及自动化测试套件。模型写得好不好不再靠另一个子代理用长篇大论的 Prompt 去“主观评审”而是直接交给确定性的工程工具做刚性验证。底层解耦BrainHandsSession未来的范式是将推理规划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 里写一二三四步的实现过程。像对待一位资深人类同事那样只明确告诉模型你要解决什么问题任务、哪些红线绝对不能碰护栏、以及跑通哪条测试命令算完工退出标准。第三步观察它在哪绊倒按需最小化补回不要去“猜”模型需要什么指令——你大概率会猜错。直接让裸模型在真实代码库里跑只有当它在同一个地方反复绊倒时例如项目特有的构建脚本、非标准的内部鉴权约定才把那条最小化的规则写回配置文件中。技术演进最迷人的地方莫过于此当年帮我们跨越鸿沟的脚手架终究会在大楼封顶时被拆除。 
长河君 · 2026/10/31 2:19:08 · 阅读 1.2k 为什么在模型越来越强的时候，Superpowers 反而成了累赘？
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。每当发布新一代模型团队第一件事就是把现有的系统提示词全部删光甚至开启一个内部环境变量SIMPLE1把工具提示也剥得干干净净作为对照组然后再逐行评估哪些指令真正值得加回来。实验结果非常反直觉什么繁琐提示都不给新模型反而表现得更聪明。核心洞察旧框架和旧提示词的绝大部分内容本质上是在修补上一代模型“本该知道却不知道”的缺陷。当新模型生来就具备这些能力时三个月前写的长篇约束指令就从“拐杖”变成了“脚镣”。社区里流传的一条经验法则精准概括了这一现象当规则写到 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 Agent现代 AI 编程分工架构极简方向引导代码产出确定性报错反馈闭环Sensors · 反馈控制越来越硬Compiler / TypeCheckLinter 静态检查自动化测试套件刚性裁判Guides · 前馈控制越来越薄AGENTS.md / CLAUDE.md架构品味与私有环境约定安全红线与意图对齐Core Model持续进化Brain原生推理与规划Hands沙箱与工具执行Session持久化状态管理[配图位置Model 与 Harness 的现代分工架构图]图注模型决定能力上限Harness 决定能发挥多少——每隔几个月把 Harness 削薄到适配新模型本身仔细观察上述架构你会发现现代 AI 编程架构对Harness做了极其克制的收敛Guides · 前馈控制越来越薄也就是AGENTS.md、系统提示词或.cursorrules。它只负责行动前的方向引导与意图对齐IntentGate不再堆砌几千行的流程教条而是随着模型变强不断做减法。Sensors · 反馈控制越来越硬也就是Linter、TypeCheck、Build以及自动化测试套件。模型写得好不好不再靠另一个子代理用长篇大论的 Prompt 去“主观评审”而是直接交给确定性的工程工具做刚性验证。底层解耦BrainHandsSession未来的范式是将推理规划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 里写一二三四步的实现过程。像对待一位资深人类同事那样只明确告诉模型你要解决什么问题任务、哪些红线绝对不能碰护栏、以及跑通哪条测试命令算完工退出标准。第三步观察它在哪绊倒按需最小化补回不要去“猜”模型需要什么指令——你大概率会猜错。直接让裸模型在真实代码库里跑只有当它在同一个地方反复绊倒时例如项目特有的构建脚本、非标准的内部鉴权约定才把那条最小化的规则写回配置文件中。技术演进最迷人的地方莫过于此当年帮我们跨越鸿沟的脚手架终究会在大楼封顶时被拆除。