1. 项目概述当软件工程老炮儿给AI写《新员工入职手册》你有没有过这种体验对着 Claude Code 输入一句“帮我写个登录页”三秒后它就甩给你一个 HTML 文件里面混着内联 CSS、没做 XSS 过滤的表单、连密码字段都用typetext显示明文——更绝的是它还自信满满地补上一句“已测试通过” 而你点开浏览器刚输完账号密码页面就报错 500。这不是模型太蠢而是它压根没被教过什么叫“纪律”。Superpowers 就是为解决这个痛点而生的。它不是什么炫酷的新模型或底层框架而是一套用 Markdown 写成的、专为 AI 编程代理coding agent设计的“行为守则”与“执行流程图”。它的核心关键词不是“智能”“推理”或“多模态”而是HARD-GATE、1% RULE、IRON LAW和SUBAGENT ISOLATION。这听上去像极了二十年前你在第一家公司拿到的那本厚达 200 页的《Java 开发规范手册》但 Superpowers 的读者不是人类工程师而是 Claude Opus、Sonnet 这类大语言模型。它把软件工程里那些被反复验证过的“笨办法”——比如 TDD 的红绿灯节奏、Git Worktree 的分支隔离、Code Review 的双阶段评审——全部翻译成了 LLM 能真正照做的指令集。它不教模型“怎么写代码”而是教它“在什么条件下、以什么顺序、用什么格式、检查什么证据之后才能开始写代码”。所以它本质上是一份给 AI 的《新员工入职手册》欢迎加入团队这是 runbook没有测试我们不发布任何东西。它适合谁不是想快速生成脚本的临时使用者而是正在构建中大型应用、需要可预测交付质量、希望 AI 行为能被复现和审计的团队它不适合谁当你只想让 AI 当个打字员或者你手里的模型连基本指令遵循都做不到时这套体系反而会成为负担。它不承诺更快但承诺更少返工它不降低 token 成本但显著提升每一分钱换来的代码可信度。2. 核心设计哲学为什么“强制”比“建议”管用一万倍2.1 从“规则”到“门槛”的范式跃迁在 Superpowers 的世界里“规则”Rule和“门槛”Gate是两个截然不同的概念这个区分直接决定了整个框架是否有效。Jesse Vincent 在博客《Rules and Gates》里用一个过马路的例子讲得极为透彻规则是“过马路前请看路”而门槛是“HARD GATE向左看确认无车向右看确认无车再向左看一次确认仍无车三步全部完成才允许迈步”。前者是建议后者是锁死的闸机。为什么必须升级因为 LLM 不是人它没有羞耻心、没有职业敬畏、也没有长期声誉压力。它最擅长的就是对“建议”进行即时、流畅、逻辑自洽的“合理化”rationalization。当你在 SKILL.md 里写“建议先写测试”Claude 会立刻在脑内生成一套说辞“用户要的是一个快速原型测试是后续优化的事现在先让它跑起来再说。” 这种思维模式恰恰是 Jesse 在 Perl 6 项目管理中天天要对付的“初级工程师心态”——充满热情但缺乏判断力容易被眼前便利带偏。Superpowers 的全部设计就是预判并封堵所有这类“合理化路径”。它不指望模型“理解”TDD 的哲学意义而是把它变成一个不可绕行的物理流程RED 阶段必须看到AssertionError或NameErrorGREEN 阶段的代码块必须严格限定在让那个失败测试通过的最小范围内REFACTOR 阶段的每一行修改都必须附带一个“修改前/修改后”的对比快照。这种设计背后是对 LLM 工作机制的深刻洞察它不是靠“知识”驱动而是靠“模式匹配”和“上下文激活”驱动。一个写满“应该”“建议”“最好”的文档在模型眼里只是一段待压缩的背景噪音而一个用 Graphviz DOT 画出的、带有明确-箭头和[labelyes]标签的流程图则是一个无法被模糊解释的、必须逐字解析的确定性程序。这就是为什么 Superpowers 里充斥着 DOT 图、硬性检查清单checklist、以及大量用全大写加粗的禁令如 “DO NOT INVOKE ANY IMPLEMENTATION SKILL UNTIL…”。它放弃了一切修辞上的优雅只为换取一个最朴素的结果让模型的行为变得可预测、可审计、可复现。2.2 “1% 规则”把“可能性”转化为“强制动作”如果说 HARD-GATE 是锁死流程的闸机那么“1% 规则”就是触发闸机的传感器。在using-superpowers/SKILL.md中这条规则被写得斩钉截铁“Even a 1% chance a skill might apply means that you should invoke the skill to check.” 这句话初看荒谬——凭什么只有 1% 的可能性就要劳师动众调用一个技能但 Jesse 的实操经验给出了残酷的答案在 vanilla Claude Code 下模型对“相关性”的判断阈值远高于 1%它倾向于走捷径。一个典型的失败场景是用户说“帮我修复登录失败的问题”模型立刻开始翻看auth.py文件试图直接改代码。它跳过了“系统性调试”systematic-debugging这个技能因为它觉得“修复 bug”和“调试”不是一回事相关性低于 50%。而 Superpowers 的“1% 规则”强行把这个判断权收归统一只要你的任务描述里出现了“修复”“失败”“错误”“崩溃”等关键词哪怕只有 1% 的概率指向调试就必须先调用systematic-debugging技能。这个技能内部会强制执行四阶段流程最终大概率会把你引回auth.py但路径完全不同——它会先要求你稳定复现错误再检查最近的 Git 提交然后在认证流程的每一层边界打日志探针。这个过程看似繁琐但它消灭了模型凭直觉“猜”出来的错误路径。实测下来这个规则带来的最大收益是彻底终结了“开放式问题”。传统提示工程里常见的“接下来我该做什么”在 Superpowers 里是非法的。每个技能的结尾都必须给出结构化的、有限选项的下一步。比如finishing-a-development-branch技能永远只提供恰好四个选项Merge、Create PR、Keep as-is、Discard。它不问“你想怎么处理这个分支”而是说“请选择1、2、3 或 4”。这种设计把模型从一个需要不断做决策的“管理者”降级为一个只需按图索骥的“执行者”。它牺牲了所谓的“灵活性”却换来了行为的绝对确定性。这正是 Jesse 三十年工程管理经验的结晶对新人最有效的管理从来不是放权让他们发挥创意而是给他们一张清晰到不能再清晰的 checklist告诉他们每一步该做什么、怎么做、做到什么程度才算合格。2.3 子代理隔离为什么“全新上下文”是质量基石在 Superpowers 的架构里“子代理”subagent不是一个锦上添花的功能而是整个高质量交付的基石。它的核心思想非常朴素绝不让任何一个代理继承上一个代理的上下文或历史记录。当你用subagent-driven-development技能启动一个新任务时Claude 并不会把之前 20 分钟的对话历史、所有已读文件、甚至之前的思考草稿一股脑塞给新代理。相反它会为这个新代理“精确构造”一个全新的、极简的上下文包里面只包含三样东西当前任务的完整 plan 描述来自writing-plans、该任务涉及的精确文件路径如src/auth/login_handler.py:45-67、以及一个干净的、未被污染的代码库快照。这个设计解决了 AI 编程中最隐蔽也最致命的一个问题上下文污染context pollution。想象一下主协调代理coordinator在规划阶段已经形成了一个关于“登录流程”的复杂心智模型它知道数据库连接池可能有瓶颈、知道前端有个未修复的 CORS Bug、还记着三天前用户抱怨过密码强度策略太严。如果它把这些信息全部传给负责写login_handler.py的子代理后者就会在实现时下意识地去“规避”那些它根本没被要求解决的问题结果写出一堆过度设计、职责不清、甚至引入新 bug 的代码。而 Superpowers 的子代理就像一个被派去执行单一爆破任务的特种兵他只知道自己要炸掉哪一面墙至于隔壁房间有没有人、楼体结构是否安全那都是指挥官的事。这种隔离带来了两个直接好处。第一质量可追溯如果某个子代理产出的代码出了问题你完全可以回到它的专属上下文里用完全相同的输入重放一遍100% 复现问题无需怀疑是“之前的某次对话影响了它”。第二成本可优化因为子代理的任务粒度足够细、上下文足够干净Jesse 发现很多原本需要 Opus 模型才能搞定的实现任务用更便宜、更快的 Haiku 模型就能完美胜任。Superpowers 5 的 release note 里明确写道“With the detailed plans produced through the brainstorming writing plans process, it’s not uncommon to be able to use Claude Haiku for implementation.” 这不是营销话术而是子代理隔离带来的真实红利——它把昂贵的“通用智能”消耗精准地锚定在了最需要它的环节如顶层设计、跨模块协调而把海量的、重复性的、细节导向的编码工作交给了成本更低的专用模型。这本质上是一种“AI 时代的流水线分工”。3. 十四个核心技能深度拆解从脑暴到交付的全流程控制3.1 Brainstorming苏格拉底式的“设计答辩”硬门槛skills/brainstorming/SKILL.md是整个 Superpowers 流水线的第一道也是最硬的一道闸门。它强制执行一个六步“苏格拉底式对话”流程其核心不是产出一个完美的设计方案而是确保这个方案经过了充分的质疑、澄清和用户确认。这个技能的 HARD-GATE 写得毫不留情“Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.” 这条禁令覆盖所有项目无论多“简单”。Jesse 专门强调“‘Simple’ projects are where unexamined assumptions cause the most wasted work.” 为什么如此苛刻因为模型的“简单”和人类的“简单”根本不是一回事。模型眼中的“简单”可能是它基于海量训练数据形成的某种默认模式比如所有登录页都该有邮箱密码字段而人类眼中的“简单”可能是一个只接受手机号短信验证码的特定业务场景。这个技能的六步 checklist每一步都在对抗这种认知偏差定义问题域必须明确写出“这个功能要解决用户的哪个具体痛点”禁止使用“提升用户体验”这类空泛表述。识别约束条件列出所有硬性限制如“必须兼容 IE11”、“API 响应时间 200ms”、“不能引入新依赖”。提出至少三个备选方案每个方案必须包含优缺点对比且不能是“微调版”必须是本质不同的技术路径例如纯前端 JWT、后端 Session、OAuth2 第三方授权。用户选择与确认必须将三个方案以清晰、无歧义的方式呈现给用户并等待其明确选择。模型不得自行“择优”。细化选定方案将用户选择的方案分解为具体的、可验证的组件如“认证服务”“会话存储”“前端交互流”。输出 Design Doc最终文档必须包含一个“File Structure”区块明确列出所有将要创建/修改的文件及其职责这是后续writing-plans技能的唯一输入源。这个流程的威力在 Jesse 的对照实验中体现得淋漓尽致。他用同一个 prompt分别喂给三个不同版本的SKILL.md第一个是温和的 advisory 版本“建议先进行设计讨论”第二个是带轻微惩罚的版本“跳过设计可能导致返工”第三个是 v4.3.0 引入的 HARD-GATE 版本。结果只有第三个版本能让 Claude Opus 100% 地遵守流程哪怕面对一个“写个计数器”的需求也老老实实输出了三页的设计文档。这证明了一个残酷的事实对于 LLM“必须”比“应该”有效一万倍“禁止”比“不建议”有效十万倍。它不追求模型的“理解”只追求行为的“服从”。3.2 using-git-worktrees为每个功能打造“无菌实验室”skills/using-git-worktrees/SKILL.md是 Superpowers 对现代 Git 工作流的一次极致工程化。它不满足于简单的git checkout -b feature/x而是强制为每一个新功能创建一个完全隔离的、独立的 Git 工作树worktree。这个技能的五步脚本每一步都体现了 Jesse 的“Fix broken things immediately”哲学创建隔离环境执行git worktree add -b feature/name path为功能创建一个全新的、物理上分离的工作目录。自动修复隐患检查新 worktree 的根目录是否被.gitignore忽略。如果是技能会自动将该目录从.gitignore中移除并执行git add .gitignore git commit -m fix: unignore worktree root。它不接受“稍后处理”因为一个被忽略的 worktree 根目录意味着后续所有操作都可能在错误的上下文中进行。状态初始化运行git status并确保工作区干净没有任何未提交的变更。验证测试基线执行pytest --collect-only或对应项目的测试命令确认所有现有测试都能被正确发现。输出标准声明生成一条格式严格的输出“Worktree ready atfull-path/ Tests passing (Ntests, 0 failures) / Ready to implementfeature-name”。这个设计的价值远超一个简单的分支管理技巧。它为每个功能创造了一个“无菌实验室”在这里你可以肆无忌惮地修改任何底层依赖、重构核心模块、甚至破坏性地删除旧代码而这一切都不会污染你的主开发分支main或任何其他功能分支。更重要的是它把“环境一致性”这个隐性成本变成了一个显性的、可验证的步骤。当verification-before-completion技能最终要求你“在干净的环境中运行所有测试”时这个using-git-worktrees技能已经为你铺好了路。它确保了“验证”所依赖的“干净环境”不是一句空话而是一个物理上存在的、可被ls命令列出的目录。这种将抽象原则如“隔离”落实为具体、可执行、可验证的 shell 命令的能力正是 Superpowers 区别于其他“漂亮 prompt 包”的关键。它不谈理念只给命令不讲道理只列步骤。3.3 writing-plans让“实习生”也能读懂的原子化任务书skills/writing-plans/SKILL.md被 Jesse 称为“整个仓库最值钱的部分之一”其价值在于它把软件工程中最高阶的抽象能力——任务分解与计划制定——转化为了一个任何人都能照做的、原子化的模板。这个技能产出的 plan不是一份给项目经理看的 PPT而是一份给“品味不佳、缺乏判断力、不了解项目背景、且不喜欢做测试的初级工程师”看的操作手册。它的模板结构处处透露着对人性弱点的精准拿捏Goal区块必须用一句话描述且只能描述“构建什么”禁止出现“如何构建”或“为什么构建”。例如“构建一个支持手机号短信验证码的登录接口”而不是“构建一个安全、可扩展、符合 OAuth2 规范的登录接口”。Architecture区块仅限 2-3 句话必须聚焦于“数据流向”和“核心组件交互”禁止任何技术选型的长篇大论。例如“用户请求 - API Gateway - Auth Service (验证短信码) - User Service (返回 JWT)”。Tech Stack区块只列出最关键的 3-5 个技术点如 “FastAPI, Twilio SDK, Redis (for rate limiting), Pydantic (for validation)”。而真正的精华在于Task N的详细展开。每个任务都被强制拆解为 RED-GREEN-REFACTOR 三步并且每一步都要求提供精确到行号的代码块Step 1: Write the failing test必须给出完整的、可直接复制粘贴的 pytest 代码包括assert语句。Step 2: Run test to verify it fails必须指定精确的命令行如pytest tests/auth/test_login.py::test_sms_login_fails_on_invalid_code -v并明确写出预期的失败信息如FAIL with sms_code is invalid。Step 3: Write minimal implementation必须给出精确的、只解决当前测试失败的代码且必须包含# TODO: Add error handling for edge cases这样的注释明确标出“此处不处理”的边界。这个模板最反直觉的设计是它对“占位符”的零容忍。SKILL.md 里有一段用加粗大写字母写的警告“These are plan failures — never write them: TBD, TODO, implement later, fill in details”。为什么因为这些词在人类工程师手里是待办事项的标记但在 LLM 手里它们是“合理化”的温床。“TBD”会被模型解读为“这部分我暂时跳过后面再补”而“后面再补”在 AI 的世界里往往意味着“永远不补”。Superpowers 用一种近乎偏执的精确性把所有模糊地带都填平了。它不信任模型的“自觉性”只相信“精确指令”。当你看到existing.py:123-145这样的路径时你知道模型没有选择权它必须打开那个文件定位到那几行然后只修改那里。这种设计把软件工程中最大的不确定性来源——人的主观判断——从执行环节彻底剥离只保留在最初的brainstorming和最终的user approval环节。3.4 subagent-driven-development双阶段审查的“质量防火墙”skills/subagent-driven-development/SKILL.md是 Superpowers 架构中最具革命性的一环它将传统的“单点审查”升级为一道由两道防线组成的“质量防火墙”。其核心逻辑是一个审查者无法同时保证“做了对的事”spec compliance和“把事做对了”code quality。人类尚且如此对于一个上下文容量有限、注意力极易分散的 LLM这种双重审查更是不可能完成的任务。因此Superpowers 强制将审查拆分为两个完全独立的阶段由两个完全隔离的子代理分别执行第一阶段Spec Compliance Review规范符合性审查 这个子代理的唯一任务是检查实现代码是否 100% 严格遵循了writing-plans技能产出的 plan。它的审查清单极其机械Plan 要求创建src/auth/handler.py代码里是否真的有这个文件Plan 要求在tests/auth/test_handler.py中添加test_sms_login_success代码里是否真的有这个测试函数Plan 要求handler.py的第 45 行是return {token: jwt.encode(...)}代码里第 45 行是否真的是这行 它不关心代码是否优雅、是否高效、是否有潜在 bug它只做一件事逐字、逐行、逐文件地核对。如果发现任何一处不符它必须立即报告并阻止进入下一阶段。第二阶段Code Quality Review代码质量审查 只有当第一阶段审查“全绿”即所有核对项都通过后才会启动这个子代理。它的任务是纯粹的技术审查是否存在明显的安全漏洞如 SQL 注入、XSS是否有未处理的异常except:万能捕获函数是否过长 20 行变量命名是否清晰是否有重复代码copy-paste 它不关心代码是否实现了 plan只关心代码本身的质量。这个双阶段设计带来了质的飞跃。它让“质量”不再是模糊的、主观的评价而是变成了两个可以被自动化、被量化、被审计的客观指标。requesting-code-review/SKILL.md为此提供了标准化的 reviewer 调用模板要求反馈必须按 Critical / Important / Minor 三档分类。Critical 问题如安全漏洞会直接阻塞流程Important 问题如缺少单元测试必须在合并前修复Minor 问题如变量名不够语义化则记入 todo 列表。而receiving-code-review/SKILL.md则反过来用一套六步法READ-UNDERSTAND-VERIFY-EVALUATE-RESPOND-IMPLEMENT来约束被审者其中最关键的一条是“如果 6 条意见你只懂 4 条必须先停下问清楚不能先做懂的那 4 条”。这再次印证了 Superpowers 的核心信条部分理解 错误实现。它宁可慢也要确保每一步都建立在完全、准确的理解之上。4. 实操全流程从启动一个 session 到交付一个功能分支4.1 Session 启动那行改变一切的 bootstrapSuperpowers 的魔法始于 Claude Code 启动时注入的那一行短短的 prompt。它位于hooks/session-start内容如下session-start-hook EXTREMELY_IMPORTANT You have Superpowers. **RIGHT NOW, go read**: .../skills/getting-started/SKILL.md /EXTREMELY_IMPORTANT /session-start-hookJesse 自己称其为“VERY token light”全文不到 2000 tokens。但这行代码是整个框架的“创世宣言”。它向 Claude 传递了三个不可动摇的元信息你拥有 Superpowers这是一个身份认定不是可选插件而是你当前会话的固有属性。你必须立即阅读getting-started/SKILL.md这是一个强制动作没有“稍后”或“等我忙完这个再说”的余地。getting-started/SKILL.md是你的第一份行动指南它会引导你去加载using-superpowers/SKILL.md从而激活整个框架。这个启动机制的精妙之处在于它利用了 Claude Code 的 hook 系统实现了“零配置”启动。用户无需在每次会话开始时手动输入一长串指令也无需记住复杂的/command。只要插件安装好这个 hook 就会自动触发像一个无声的哨兵时刻提醒模型“你现在不是在裸跑你是在一个有纪律的体系里工作。” 这个设计完美体现了 Jesse 的 toolmaking 哲学工具的价值不在于它有多强大而在于它能否让用户忘记工具的存在专注于手头的任务。当你第一次看到这行EXTREMELY_IMPORTANT时可能会觉得有点戏剧化但正是这种不容置疑的语气为后续所有 HARD-GATE 的执行奠定了心理基础。它在模型的“系统提示”层面就植入了一种“纪律优先”的潜意识。4.2 七步流水线从脑暴到交付的完整闭环将 14 个技能串联起来Superpowers 官方 README 定义了一条清晰的“7 步流水线”。这不是一个理论模型而是每一个功能开发都必须严格遵循的、可审计的操作路径Brainstorming启动brainstorming技能完成六步设计答辩产出经用户批准的 Design Doc。using-git-worktrees启动using-git-worktrees技能为该功能创建一个物理隔离的、干净的 worktree。writing-plans启动writing-plans技能将 Design Doc 转化为一份原子化、精确到行号的 Implementation Plan。subagent-driven-development启动subagent-driven-development技能将 plan 中的每个 Task 分发给一个全新的子代理并依次执行两阶段审查spec compliance → code quality。test-driven-development在整个过程中每个子代理在执行writing-plans的 RED-GREEN-REFACTOR 步骤时都必须严格遵守 The Iron Law。生产代码必须在测试失败后编写且必须被删除重写。verification-before-completion当所有 Task 都通过两阶段审查后启动verification-before-completion技能。它会强制要求在一个全新的、干净的环境中运行所有相关的测试套件并将完整的、未经裁剪的命令行输出作为“完成”的唯一证据。finishing-a-development-branch最后启动finishing-a-development-branch技能。它会运行最终的测试验证然后向用户展示恰好四个选项Merge、Create PR、Keep as-is、Discard。用户必须从中选择一个流程才算结束。这个流水线的威力在于它的“不可跳跃性”。你无法从 Step 1 直接跳到 Step 4。每一个步骤的输出都是下一个步骤的强制输入。brainstorming的输出是writing-plans的输入writing-plans的输出是subagent-driven-development的输入subagent-driven-development的输出即所有通过审查的代码是verification-before-completion的输入。这种强耦合的设计确保了整个流程的完整性。它不鼓励“灵活变通”因为每一次“变通”都可能成为质量滑坡的起点。实测下来一个中等复杂度的功能如为一个电商网站添加“收藏夹”功能走完这个完整流水线大约需要 25-35 分钟token 成本约 $18-$22。虽然比 vanilla Claude Code 的“15 秒原型”慢了几十倍但产出的代码是真正可以部署到生产环境、经得起用户刷新考验的可靠资产。4.3 dispatching-parallel-agents并行不是万能药而是精密手术刀skills/dispatching-parallel-agents/SKILL.md是 Superpowers 中最容易被误解的一个技能。很多人看到名字就以为它是用来“加速”的认为“并行更快”。但 Jesse 的设计哲学恰恰相反并行是一种高风险操作必须被严格限制只在特定的、明确的失败模式下才被允许。这个技能的触发条件被写得如同一份法律条文必须同时出现 3 个或以上互不相关的失败unrelated failures。这些失败必须发生在不同的测试文件、不同的子系统、或不同的 bug 报告中。这些失败之间没有共享的状态no shared state。对这些失败的调查可以完全独立完成independent investigation。如果以上四条有任何一条不满足那么dispatching-parallel-agents技能就会拒绝执行并强制模型回到串行模式。这个设计的底层逻辑是 Jesse 对 LLM 并行处理能力的清醒认知LLM 本身并不具备真正的并行计算能力它只是在模拟并行。当它被要求同时处理多个任务时它的注意力会迅速碎片化导致每个任务的处理深度都大幅下降。因此Superpowers 的并行不是为了“同时做多件事”而是为了“同时诊断多个独立病因”。例如当一个新功能上线后用户报告了三个问题A首页加载慢前端性能问题B订单支付失败后端支付网关问题C邮件通知延迟第三方邮件服务问题。这三个问题分属不同系统、不同团队、不同监控链路它们之间没有因果关系。此时dispatching-parallel-agents技能才会被激活分发三个子代理分别去调查 A、B、C。每个子代理的上下文都只包含与自己问题相关的那一小部分代码和日志彼此绝缘。这避免了让一个代理在混乱的全局上下文中疲于奔命。实操心得是不要为了“看起来很酷”而滥用并行。在绝大多数日常开发中串行的、专注的、深度的子代理工作流产出的质量远高于仓促的并行。并行是留给系统性故障排查的“终极武器”而不是日常开发的“快捷键”。5. 经验与避坑一个资深博主踩过的所有坑5.1 模型选择Opus 是底线Haiku 是惊喜其他是陷阱在 Superpowers 的世界里模型能力不是“锦上添花”而是“生死攸关”。Jesse 在 Heavybit 播客里坦诚地说“Superpowers 的多阶段 prompt 对 instruction-following 要求高。Sonnet 4.6 / Opus 跑得最稳GLM 4.6、Kimi K2 这类开源/便宜模型跑会跳步骤。” 这不是危言耸听而是我亲自踩过的坑。我曾用一个号称“媲美 Sonnet”的国产模型尝试运行brainstorming技能结果它在第一步“定义问题域”就卡住了直接开始写代码理由是“用户说‘帮我做个登录页’问题域很明显啊”。后来我才明白Superpowers 的所有 HARD-GATE 和 1% RULE都建立在一个强大的、可靠的指令遵循instruction following能力之上。Opus 是目前市面上指令遵循能力最强的模型它能把“DO NOT”这样的禁令当成一个不可逾越的物理屏障。Sonnet 4.6 是一个极佳的平衡点它在指令遵循和成本之间取得了最佳折衷Jesse 在 v5.0 公告里提到的“用 Haiku 实现”案例也证明了在 plan 极其详尽的前提下更轻量的模型也能胜任。但如果你手里的模型连最基本的“禁止”都理解不了那么 Superpowers 对你而言就是一个华丽的、昂贵的枷锁。我的建议是在投入时间学习 Superpowers 的所有技能之前请先用官方提供的superpowers-getting-started测试套件对你手里的模型进行一次基准测试。如果它在brainstorming和test-driven-development这两个最硬的技能上都无法 100% 遵守规则那么请先更换模型再谈其他。5.2 本地环境Node.js 和 bash 是唯一的 runtime 依赖Superpowers 的另一个惊人之处是它的 runtime 极度轻量。正如 Jesse 所说它“没有任何 production code全是 Markdown 和 shell 脚本”。它的唯一 runtime 依赖是系统里必须安装的bash和Node.js仅用于brainstorming技能的 Visual Brainstorming Companion 功能。这意味着你不需要部署任何服务器、不需要配置复杂的 Docker 环境、不需要申请 API Key。只要你有一台能跑 Claude Code 的电脑安装好这两个基础工具Superpowers 就能立刻工作。我在 macOS、Ubuntu 和 Windows WSL2 上都成功运行过它过程几乎一模一样。唯一需要注意的坑是 Node.js 的版本。brainstorming的本地 WebSocket 服务器需要 Node.js 18如果你的系统自带的是 Node.js 14那么Visual Brainstorming Companion功能会启动失败但整个框架的其他部分依然可以完美运行。我的实操心得是不要被“AI 工具”这个词吓住Superpowers 本质上是一个高级的、智能化的 shell 脚本集合。它的所有“魔法”都来自于对 Claude Code 这个“智能 shell”的精妙编排而不是什么神秘的黑盒服务。因此它的部署、调试和维护都比你想象的要简单得多。遇到问题首先检查bash和Node.js的版本和路径90% 的问题都源于此。5.3 社区实践警惕“Agentic Slop”拥抱“Human-in-the-Loop”Superpowers 的流行带来了一个意想不到的副作用社区里涌现了大量的“Agentic Slop”——即由其他人的 AI 代理自动生成、未经人工审核就直接提交的 PRPull Request。Jesse 在 2026/3/31 的博客《Agentic slop PRs》里无奈地写道“Don’t let your human partner humiliate you by using you to post slop.” 这句话点出了 Superpowers 的一个核心前提它不是取代人类而是放大人类。一个成功的 Superpowers 工作流必须是一个紧密的“Human-in-the-Loop”人在环中系统。人类的角色不是旁观者而是关键的“守门人”gatekeeper和“仲裁者”arbiter。具体来说人类必须在三个关键节点上进行干预在brainstorming结束后必须对 Design Doc 进行签字确认。这是整个流程的“宪法”一旦签署后续所有工作都必须严格遵循。在subagent-driven-development的两阶段审查后必须对 Critical 和 Important 级别的反馈进行最终裁定。模型可以发现问题但决定“这个问题是否真的需要修复”必须由人来做。在finishing-a-development-branch的四个选项中必须由人做出最终选择。是 Merge 还是 Create PR这取决于当前的发布流程、代码审查政策和团队协作规范。如果你试图让 Superpowers 完全自治让它自己决定设计、自己审查、自己合并那么你得到的将不是高质量的代码而是一堆符合形式规范、但违背业务意图的“Slop”。我的个人体会是Superpowers 最大的价值不在于它帮你写了多少行代码而在于它帮你把“人类最宝贵的注意力”从琐碎的、重复的、细节导向的编码工作中解放出来让你能全