企业官网建设流程全解析

1. 项目概述：当软件工程老炮儿给AI写《新员工入职手册》

你有没有过这种体验：对着 Claude Code 输入一句“帮我写个登录页”，三秒后它就甩给你一个 HTML 文件，里面混着内联 CSS、没做 XSS 过滤的表单、连密码字段都用type="text"显示明文——更绝的是，它还自信满满地补上一句：“已测试通过！” 而你点开浏览器，刚输完账号密码，页面就报错 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或NameError；GREEN 阶段的代码块必须严格限定在让那个失败测试通过的最小范围内；REFACTOR 阶段的每一行修改，都必须附带一个“修改前/修改后”的对比快照。这种设计背后，是对 LLM 工作机制的深刻洞察：它不是靠“知识”驱动，而是靠“模式匹配”和“上下文激活”驱动。一个写满“应该”“建议”“最好”的文档，在模型眼里只是一段待压缩的背景噪音；而一个用 Graphviz DOT 画出的、带有明确->箭头和[label="yes"]标签的流程图，则是一个无法被模糊解释的、必须逐字解析的确定性程序。这就是为什么 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，每一步都在对抗这种认知偏差：

1. 定义问题域：必须明确写出“这个功能要解决用户的哪个具体痛点？”，禁止使用“提升用户体验”这类空泛表述。
2. 识别约束条件：列出所有硬性限制，如“必须兼容 IE11”、“API 响应时间 < 200ms”、“不能引入新依赖”。
3. 提出至少三个备选方案：每个方案必须包含优缺点对比，且不能是“微调版”，必须是本质不同的技术路径（例如：纯前端 JWT、后端 Session、OAuth2 第三方授权）。
4. 用户选择与确认：必须将三个方案以清晰、无歧义的方式呈现给用户，并等待其明确选择。模型不得自行“择优”。
5. 细化选定方案：将用户选择的方案，分解为具体的、可验证的组件（如“认证服务”“会话存储”“前端交互流”）。
6. 输出 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”哲学：

1. 创建隔离环境：执行git worktree add -b feature/<name> <path>，为功能创建一个全新的、物理上分离的工作目录。
2. 自动修复隐患：检查新 worktree 的根目录是否被.gitignore忽略。如果是，技能会自动将该目录从.gitignore中移除，并执行git add .gitignore && git commit -m "fix: unignore worktree root"。它不接受“稍后处理”，因为一个被忽略的 worktree 根目录，意味着后续所有操作都可能在错误的上下文中进行。
3. 状态初始化：运行git status并确保工作区干净，没有任何未提交的变更。
4. 验证测试基线：执行pytest --collect-only（或对应项目的测试命令），确认所有现有测试都能被正确发现。
5. 输出标准声明：生成一条格式严格的输出：“Worktree ready at<full-path>/ Tests passing (<N>tests, 0 failures) / Ready to implement<feature-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 启动：那行改变一切的 bootstrap

Superpowers 的魔法，始于 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-hook>

Jesse 自己称其为“VERY token light”，全文不到 2000 tokens。但这行代码，是整个框架的“创世宣言”。它向 Claude 传递了三个不可动摇的元信息：

1. 你拥有 Superpowers：这是一个身份认定，不是可选插件，而是你当前会话的固有属性。
2. 你必须立即阅读getting-started/SKILL.md：这是一个强制动作，没有“稍后”或“等我忙完这个再说”的余地。
3. 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 步流水线”。这不是一个理论模型，而是每一个功能开发都必须严格遵循的、可审计的操作路径：

1. Brainstorming：启动brainstorming技能，完成六步设计答辩，产出经用户批准的 Design Doc。
2. using-git-worktrees：启动using-git-worktrees技能，为该功能创建一个物理隔离的、干净的 worktree。
3. writing-plans：启动writing-plans技能，将 Design Doc 转化为一份原子化、精确到行号的 Implementation Plan。
4. subagent-driven-development：启动subagent-driven-development技能，将 plan 中的每个 Task 分发给一个全新的子代理，并依次执行两阶段审查（spec compliance → code quality）。
5. test-driven-development：在整个过程中，每个子代理在执行writing-plans的 RED-GREEN-REFACTOR 步骤时，都必须严格遵守 The Iron Law。生产代码必须在测试失败后编写，且必须被删除重写。
6. verification-before-completion：当所有 Task 都通过两阶段审查后，启动verification-before-completion技能。它会强制要求在一个全新的、干净的环境中，运行所有相关的测试套件，并将完整的、未经裁剪的命令行输出作为“完成”的唯一证据。
7. 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 代理自动生成、未经人工审核就直接提交的 PR（Pull 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 最大的价值，不在于它帮你写了多少行代码，而在于它帮你把“人类最宝贵的注意力”，从琐碎的、重复的、细节导向的编码工作中解放出来，让你能全