写这篇文章是因为我最近把 Superpowers 框架用在了好几个项目上效果确实有点出乎意料。之前我用 AI 编程助手写东西总觉得它像一个很聪明但纪律性很差的新人——你让它写个函数它能写得飞快但一旦涉及先分析需求、再拆任务、边写边测这套正经软件工程的流程它就容易跳步、自作主张甚至把项目搞乱。Superpowers 解决的就是这个问题它不是一个具体的开发框架而是一套给 AI 编程助手装的技能包和工作流约束器让 Claude Code、Cursor、Codex 这类工具真正按照软件工程的套路来干活。这篇东西写给谁呢主要是已经被 AI 编程助手惊艳过、又被它坑过的人。不管你是个人开发者、在小团队里负责一个模块还是那种想用 AI 加速交付但又怕代码质量失控的工程师这篇文章都会有用。我会从原理讲起然后给你完整的安装方式、我实测过的技能使用流程、以及在 Pythonpytest 自动化测试和 JavaSpring Boot两个场景下的真实组合玩法最后把那些文档里不会写的坑和排查技巧全部摊开。文章有点长但看完你应该能直接上手。我在实际使用中发现真正让 AI 编程助手从玩具变成生产力工具的关键不是换更大的模型而是给它一套可执行的工程纪律——Superpowers 干的就是这个活。1. 为什么 AI 编程助手总差那么一口气1.1 日常用 AI 写代码的几个经典翻车现场先说几个我见过太多的场景。你让 AI 助手帮我优化一下这个模块它可能直接给你重写整个文件表面看着漂亮但把你精心处理的边界条件全丢了。你让它实现一个用户登录功能它闷头把注册、找回密码、验证码全都给你写了而你只是想要一个最简的 Session 校验。更常见的是它写完代码不跑测试或者跑了测试但只跑它自己写的演示性测试你集成进主分支才发现核心逻辑就是错的。这些问题的本质不是模型能力不够。现在的模型代码生成能力已经很强了GPT 级别和 Claude 级别的模型在单点任务上相当靠谱。问题出在过程控制上——AI 没有软件工程的概念。它不知道什么是需求先行不知道什么叫小步提交更不懂测试驱动不是一种偏好而是一种纪律。你如果不给它一套流程约束它就会回到它最舒服的模式像一个急着交作业的学生看到题目就直接写答案中间过程能省则省。1.2 问题出在哪AI 不缺能力缺的是工程约束我打个比方。你让一个手艺很好的厨师自由发挥做一桌菜他大概率能做出几道惊艳的菜但也可能把厨房搞得一团糟而且你没法保证他下次还这么做。但如果你给他一套标准作业流程——先列菜单、备菜、按顺序下锅、每道菜出锅前试味——那即使换一个水平稍差点的厨师出品也会稳定得多。软件工程这些年沉淀下来的方法论其实就是厨房里的那套标准作业流程。但麻烦在于大模型不会天然遵守流程。它们在训练数据里见过海量代码但没见过提交之前必须跑一遍全量测试这种团队规范。你可以在 prompt 里临时要求它但一个复杂任务往往需要十几个甚至几十个约束条件靠人肉在每次对话里重新输入一遍既容易遗漏又浪费大量 token。Superpowers 的核心思路就是把软件工程套路固化成一套可复用的技能文件让 AI 在开始干活之前自动加载这些约束相当于给你的 AI 助手装上一套 SOP。还有一个很隐蔽的问题值得单独说AI 的上下文窗口虽然越来越大但它对项目的整体理解是碎片化的。它每次只能看到你贴给它的那几段代码对全局架构、历史决策、技术债一无所知。传统软件工程里我们靠代码评审、架构文档、口头沟通来传递这些信息而 AI 助手需要一套机制来主动发现和理解项目上下文。Superpowers 的任务拆解和项目分析技能就是干这个用的。2. Superpowers 到底是个什么东西2.1 一句话解释 SuperpowersSuperpowers 是一个开源项目作者是 Jesse Vincent在 Perl 社区很有名也是 Habits 应用的原作者。它本质上是给 AI 编程助手用的一套技能包 任务管理层。技能包是一组精心编写的 Markdown 文件每个文件教会 AI 一种特定的工作方法任务管理层则是一个 MCP 服务让 AI 可以把一个项目拆解成一个个原子任务写一个、测一个、完成一个而不是一口吞下一个大功能。MCPModel Context Protocol就是现在 AI 编程工具之间互相通信的一套标准协议。Superpowers 的 MCP 服务负责管理任务清单Task List、记录人类日志Human Log技能文件则负责给 AI 注入工作流程。这两个东西配合起来效果就是AI 拿到一个需求后先按照技能文件的指引做需求分析然后把工作分解成一个个小任务写进任务清单每个小任务都按照测试先行→实现→验证的节奏推进所有决策过程都会被记录到日志里。这和我们平时用 AI 的方式最大的区别在于它把过程显性化了。以前你让 AI 做一件事它就一头扎进去做做完给你一个结果Superpowers 会逼着 AI 先告诉你我打算怎么做做完一个步骤停下来汇报一次。这个改变在初期会让你觉得 AI变笨了——从秒回变成了一段一段挤牙膏——但真正跑完一个中型功能之后你会发现代码质量、可控性、可排查性都上了一个台阶。2.2 Skills 是什么机制Skills 在英文里就是技能实现上就是放在指定目录里的一些 Markdown 文件。每个文件都有一个标题、一段描述告诉 AI 什么时候该用这个技能、以及详细的步骤指令。AI 编程助手的运行机制是任务开始时先扫描可用的技能文件根据当前任务内容匹配最相关的技能然后加载其中的指令来规范自己的行为。举个例子Superpowers 里有一个叫 test-driven-development 的技能文件。这个文件里写的内容大致是先弄清楚要测试的行为是什么先写一个最小测试用例运行它确认失败红灯然后用最简单的代码实现让它通过绿灯再考虑重构。AI 加载了这个技能之后它再写功能就不会直接甩一坨实现代码出来而是会先跟你确认测试策略再小步推进。你甚至会发现它在跟你讨论这个测试先覆盖哪个分支。这套机制之所以有效是因为它利用了模型对角色设定和规则遵循的敏感性。模型对一段清晰、结构化的指令的遵循程度远高于你在对话中随口说的话。而且技能文件是持久化的——你今天装的技能明天、下周、下个项目都还在不需要重复配置。这一点在团队协作里尤其重要你可以让你自己电脑上的 AI 编程助手保持和同事一样的工程纪律。2.3 核心设计理念渐进式增强Superpowers 有一个非常核心的理念原文里强调得很多我翻译成大白话就是先让软件能用再让它漂亮不要一上来就追求完美架构。这个理念直指的痛点是 AI 编程助手特别喜欢做过度设计。我自己就踩过这个坑。有一回让 AI 做一个内部工具的数据导入功能它在设计阶段就开始规划什么插件化架构、消息队列、多租户隔离——结果是两天过去了一个能跑的版本都没有。后来我用 Superpowers 的 Brainstorming 技能强制它先讨论最小可用方案AI 才老实下来先写了一个同步解析 CSV 的核心函数跑通之后才讨论要不要拆任务队列。这个先解决有没有再解决好不好的思路本来就是软件工程里最朴素的道理但如果不固化到 AI 的工作流里它就会自动跑偏。Superpowers 的另一个设计理念是一次只做一件事。它的任务系统会强制把一个大的需求拆成原子任务每个任务只解决一个明确的问题。这其实是把敏捷开发里的用户故事和任务卡搬到了 AI 的工作中。为什么对 AI 特别重要因为模型在复杂任务中容易丢失信息任务越小它保持上下文一致性的能力就越强。一个功能拆成 5 个小任务逐个完成比一次性让 AI 写 500 行代码要可靠得多。3. 从零开始接入 Superpowers3.1 准备工作与环境要求开始之前先说清楚Superpowers 不是一个独立的 IDE它需要附着在某个 AI 编程助手上面运行。目前支持得比较好的是 Claude Code、Cursor、Codex CLI 这类基于代理模式的编程助手。注意代理模式是关键——那种只在对话框里生成代码块、不能自主执行命令的聊天式 AI 是用不了它的因为 Superpowers 的工作流需要 AI 有读写文件、执行测试命令的能力。环境方面主要需要两样东西一个是 Python 3.11 以上版本因为 Superpowers 的 MCP 服务是用 Python 写的推荐用 uv 这个包管理器来运行它省心很多另一个是 Git因为安装技能包的过程会从 GitHub 拉取文件。操作系统上macOS 和 Linux 都完全没问题Windows 的话建议用 WSL2纯 Windows 环境我试过在路径处理上会遇到一些麻烦后面我会在排查部分细说。安装的核心逻辑其实就两步把技能文件装到本地的一个指定目录把 MCP 服务注册到你用的编程助手配置里。技能文件装在哪个目录和具体工具相关。比如 Claude Code 读技能文件的路径一般是项目里的.claude/skills或者全局的~/.claude/skillsCursor 则是.cursor/skills。Superpowers 官方提供的安装脚本会帮你把技能文件复制到正确位置不需要你手动一个个拷贝。3.2 安装实战分客户端操作先装 MCP 服务。打开终端执行下面这个命令来全局安装 Superpowers MCP 服务uvx superpowers如果你电脑上还没有 uv先去装一下。macOS 和 Linux 可以直接一行命令搞定curl -LsSf https://astral.sh/uv/install.sh | sh装完 uv 和 MCP 服务之后就要把它注册到具体的 AI 编程助手里了。以 Cursor 为例打开 Cursor 的设置界面找到 MCP 配置项添加一个新的 MCP Server命令填uvx superpowersTransport 选 stdio保存后它会自动启动。Claude Code 的话在项目目录下执行claude mcp add --transport stdio superpowers -- uvx superpowers注册完之后再安装技能文件。Superpowers 官方提供了一键安装脚本在终端里跑curl -fsSL https://raw.githubusercontent.com/obra/superpowers/main/scripts/install_superpowers.sh | bash脚本会把核心技能文件装到你的用户目录下并输出一个提示告诉你在不同的编程助手工具里分别放到哪个位置。这里我要多说一句安装脚本输出的提示信息很关键不要扫一眼就跳过。老版本的时候它就因为安装位置不一样导致用户技能加载失败我见过很多人卡在这一步。装好之后怎么验证你在 AI 编程助手的对话里输入/查看可用命令列表应该能看到 brainstorms、task 之类的指令入口或者你直接问 AI你有哪些技能可用它会告诉你加载了哪些技能文件。我实测下来Cursor 里通过命令面板查看 MCP 状态看到 superpowers 显示 connected 就是成功了。4. 核心技能逐个拆解4.1 需求澄清与头脑风暴Brainstorming 技能很多人忽略这个技能但它其实是整个框架里最值钱的一个。Brainstorming 做什么用就是当你给 AI 一个模糊的想法时它不会立刻开始写代码而是先和你做一轮结构化的需求澄清。它会问你这个功能的用户是谁核心场景是什么有没有什么约束你希望的最小可行方案是什么我举个例子。我接到过一个需求要给一个内部告警平台加一个告警静默功能也就是允许运维人员把某些暂时不想处理的告警先按掉。如果我直接把这个需求丢给没装技能的 AI它大概率会开始设计数据库表、写 API 接口。但当我用 Brainstorming 技能之后AI 先给我列出了一串问题静默是针对单个告警还是告警规则静默之后还要不要保留原始告警要不要支持定时自动恢复这些问题看着简单但如果不事先问清楚做出来的功能大概率要返工。这个技能之所以有效是因为它把提问变成了一种规则而非偶发行为。普通模式下你让 AI 提问它就象征性问一两个问题然后开干Brainstorming 模式下它有明确的步骤清单先理解背景再列出问题清单然后逐一确认最后总结成一个需求描述。你会发现它问问题的质量非常高因为我实测下来它会刻意避免问那种搜索引擎就能回答的蠢问题把火力集中在真正影响设计的决策点上。4.2 把需求拆成能执行的任务Task 技能需求澄清完之后下一个环节就是拆解。Task 技能做的事情是把你确认过的需求描述转化成一份带优先级、带依赖关系的任务清单然后通过 MCP 服务把它持久化保存下来。每个任务都会被写成要做什么、验收标准是什么、完成后要告诉用户什么的格式。这个拆解粒度我实际用下来的经验是宁可拆小不要拆大。一个 5 到 15 分钟能完成、改动在 100 行以内的任务是最理想的。比如实现用户注册接口可以拆成添加用户模型的 email 唯一性约束编写注册接口的参数校验逻辑实现密码加密存储编写注册接口的集成测试四个任务。拆完之后AI 会按照依赖顺序逐个处理。任务拆解还带一个非常实用的好处它把 AI 的行动计划暴露给了你让你在它开始动手之前有机会纠正方向。以前你等 AI 写完代码再评审现在你可以在它动笔之前就评审它的计划。这个低成本纠偏的机会对保证项目方向正确太重要了。我习惯在 AI 给出任务清单后先人工过一遍把优先级调一调、把遗漏的任务补上再让它开始执行。4.3 测试先行Test-Driven Development 技能这是 Superpowers 框架里技术含量最高的技能也是让我真正觉得值回票价的部分。这个技能的核心是逼着 AI 严格遵循红灯-绿灯-重构的节奏先写一个会失败的测试运行它确认失败再用最简代码让它通过最后重构。听起来简单但实际执行时有一堆细节是模型默认做不到的。先说一次只写一个测试。如果你让 AI给这个模块写测试它可能会给你生成 20 个测试用例覆盖各种边界条件。这在传统开发里是优点但在严格的 TDD 流程里反而是问题——因为如果测试全部一次性写完你根本无法确认第一个测试失败的原因到底是实现缺失还是测试本身有问题。Superpowers 的 TDD 技能要求 AI 先写第一个最小测试运行确认失败然后把失败信息和原因写到任务日志里再开始实现。这个过程对 AI 是反直觉的因为模型天然倾向一步到位但恰恰是这个反直觉的约束保证了一旦出现问题你可以精准地定位到是需求理解错了测试写错了还是实现写错了。再一个细节是用最简单的方式实现。AI 在一个测试通过之后往往会顺手把实现写得很完整甚至引入一些目前还用不上的抽象。Superpowers 的 TDD 技能明确要求它只用让当前测试通过的最简实现后续测试驱动着实现逐渐演化。这个约束本质上就是 Kent Beck 说的Minimal implementation但对模型来说它需要被反复强调才会遵守。我亲测的效果是用了这个技能之后AI 生成的代码明显朴素了但也明显更难错了——它不再提前发明那些看起来很美却没人用得上的架构了。4.4 调试、重构与其他辅助技能Superpowers 里还有一组辅助技能。比如调试技能它要求 AI 在遇到 bug 时先提出对根因的假设、然后设计实验去验证而不是反复猜着改代码。这个技能我最开始不以为然直到有一个诡异的偶发 bug 折磨了我一晚上用它的流程做了一轮提出假设→设计日志→验证假设之后才发现是并发环境下共享变量被意外修改了。AI 在调试场景下最大的问题就是改一下跑一下乱试调试技能相当于给它的乱试行为加了一道假设驱动的约束。重构技能也是高频使用的。它的核心不是让 AI 直接重构而是让它先列出重构的目标和步骤、确认现有测试全绿然后每一步重构完就跑一遍测试确保行为没有变化。这和看着代码不顺眼就大改特改的区别就是安全问题。用了它之后AI 做重构时我会明显更放心因为它会持续向我报告测试状态而不是甩给我一个应该没问题吧的新代码。Human Log 也是一个容易被忽视但很实用的功能。它会记录你和 AI 协作过程中的关键决策、用户反馈、踩坑记录形成一份项目历史档案。这就相当于给 AI 装了一个长期记忆。我发现这个东西在后期的项目维护里价值很大——一个月后你重新打开项目让 AI 继续开发它可以翻看 Human Log 里之前的决策记录避免重复问你已经回答过的问题。5. 实战组合把 Superpowers 用进真实项目5.1 Python 项目结合 pytest 打造纪律化流程Python 项目是我用得最多、也是 Superpowers 适用性最好的场景。以我最常用的组合为例项目是 FastAPI 写的 API 服务测试框架是 pytestSuperpowers 负责纪律约束。我通常的路径是这样的需求来了先让 AI 用 Brainstorming 技能澄清需求然后生成任务清单随后每个任务都按 TDD 流程走——先写 pytest 测试跑出红再实现跑到绿最后重构。这里有个标准的指令序列你可以直接参考。在 Cursor 里我会这样开始使用 Superpowers 的 TDD 技能来完成这个任务。请先给我一个 pytest 测试测试目标是/users/{id} 接口在用户不存在时返回 404。先运行测试并展示红灯再实现接口逻辑并展示绿灯。AI 会先创建或修改测试文件然后执行pytest tests/test_users.py::test_get_user_not_found之类的命令。你会看到它把终端输出贴出来确认失败然后才开始写实现代码。这个过程中我最看重的是它真的会展示失败输出。因为很多时候 AI 会假装跑了测试——它可能凭经验知道某个写法会失败就直接跳过去了。只有当它明确展示了你指定的测试命令的实际输出你才能确信它真的在执行。FastAPI 项目里有一个特别适合 Superpowers 的玩法是接口测试的自动生成。让 AI 根据 OpenAPI 文档自动生成一组 pytest 测试用例校验状态码、校验响应结构和业务逻辑然后逐个 TDD 实现。这个流程在纯手工时代要花大半天现在基本上让 AI 两三个小时就能做完而且每个接口的错误分支都有测试覆盖。我最近的几个小项目都是这么跑的代码风格非常统一回归测试覆盖率也很健康。5.2 Java 后端Spring Boot 项目里的落地姿势Java 生态在 Superpowers 里的体验和 Python 有点不同。Spring Boot 项目结构更重、约定更多AI 在生成代码时往往会遇到Context 和 Bean 装配这类既依赖框架又依赖业务上下文的问题。用 Superpowers 之后的经验是把它当成一个规范器而不是魔法棒。比如要新增一个接口Superpowers 的 TDD 技能会要求 AI 先写测试。在 Spring Boot 里这个测试通常是用 MockMvc 或者WebMvcTest切片测试。AI 写测试倒是不难难的是让它正确地理解 Spring Boot 的测试约定——比如测试上下文里需要 mock 哪些 Bean、数据库怎么隔离。我建议你在项目里预先放好一套模板测试然后在任务描述里明确告诉 AI参照src/test/java/.../ControllerTests.java的写法。Superpowers 的技能文件是通用方法论具体的项目基建还是需要你来喂给它的。还有一个实战上的组合拳用 Superpowers 拆解完任务之后让 AI 按任务逐个生成 Spring Boot 的分层代码——Controller、Service、Mapper、Entity。以前直接让 AI生成一个订单模块的体验永远是代码堆在一起、逻辑混乱而拆成任务后每个任务只聚焦一层AI 的上下文能够保持干净生成的代码也符合单一职责原则。配合 Maven 的mvn test作为验证手段让 AI 每完成一个任务就跑一遍该任务的测试质量会稳很多。5.3 团队协作把技能文件同步给同事Superpowers 还有一个容易被个人开发者忽略的价值就是团队工程纪律的一致性。你可以在项目的.cursor/skills或者.claude/skills目录里维护技能文件的副本把它们提交到 Git 仓库这样所有克隆了这个仓库的开发者在本地的 AI 编程助手都会自动加载相同的技能。当然这里我要提个醒技能文件、MCP 服务版本这些东西是逐个项目演进的不要盲目追求最新版。我就经历过一次上游更新之后技能文件的行为发生变化导致 AI 在某个步骤上突然开始问我一些多余的问题。后来我的做法是团队个人使用可以追新但项目仓库里的技能文件要锁定版本确保每个成员的行为一致。这个东西就像 ESLint 规则和代码风格一样稳定压倒一切。实际上把技能文件纳入代码评审会非常有趣。你想一下当一次 AI 生成的代码合并进主分支之前评审者不仅看代码还看 AI 是怎么走完整个流程的——测试先写了没、任务拆分合理不合理、决策日志有没有记录。这个东西对保证交付质量的作用比我预想的要大得多。6. 常见问题与排查技巧实录6.1 问题速查表我用了一段时间踩了不少坑。先说几个高频问题。症状可能原因解决方案MCP 服务显示连接失败uv 未安装或版本不对低于 0.4 可能会有兼容问题重新运行 curl -LsSf https://astral.sh/uv/install.shAI 不调用任何技能直接开写技能文件没放到正确目录或文件名/目录名缺失检查.claude/skills/.cursor/skills目录确认 superpowers 相关目录和文件在可加载的位置技能偶尔生效偶尔不生效项目级和全局级的技能配置冲突删掉重复的技能文件按项目级优先原则只保留一份TDD 流程里 AI 跳过红灯直接写实现技能加载成功但指令被模型忽略了在 prompt 里强制要求先输出测试代码并运行粘贴失败输出然后才允许写实现任务清单没有持久化MCP 服务启动失败在终端手动运行uvx superpowers看报错信息多半是版本或环境变量问题中文项目里 AI 输出有时混杂英文技能文件是英文写的在加载技能时补充一句请使用中文思考和回答代码注释和变量名用英文这里每一项我都实际遇到过说几个细节。MCP 连接失败是最常见的绝大多数情况下是 uv 没有正确安装或者 PATH 没有生效。打开终端手动跑一次uvx superpowers如果能看到服务启动输出就说明本身没问题需要去看编辑器的 MCP 配置是否填错了命令参数。还有一个隐蔽的问题技能文件目录名不能随便改。Superpowers 的技能在 Markdown frontmatter 里定义了 name 字段AI 编程助手会通过这个名字来索引技能。你把目录从test-driven-development改成了tddAI 可能就找不到它了。这个坑我见过好几个新手踩。6.2 我的几条独家避坑心得第一不要一开始就让 Superpowers 参与全部项目。刚上手的时候把它用在一个功能边界清晰的小任务上比如给一个已有的小模块补测试。等熟悉了它的工作流再扩展到新功能开发。你直接拿一个大项目做实验会同时遇到框架配置不熟、技能文件冲突、AI 行为改变带来的认知负荷问题叠问题很容易劝退。第二学会说停并纠正 AI 的行为。Superpowers 给出的工作流是通用模板不一定总能匹配你的偏好。比如它可能默认每次任务完成都要向你汇报但在一个很小的改动里这种汇报就是噪音。你可以明确告诉它这个小任务不需要详细汇报直接在任务列表里标记完成即可。技能是工具不是圣旨你要掌握对它的微调权。第三定期观察 Human Log 和任务历史。有一次我发现 AI 在三天前的一次任务中有一个我认为这里可能存在 xxx 风险的记录后来真的爆出了那个问题。这个日志机制把 AI 的隐性判断变成了显性信息非常值得利用。你甚至可以要求 AI 在做重要决策时把为什么这么做写成日志这些记录在事后复盘时非常有价值。第四在 Windows 上建议直接用 WSL2。纯 Windows 环境下脚本安装的路径处理、文件权限、命令执行都会遇到莫名其妙的坑。我在 WSL2 里装了一次就没再碰到过问题。包括 uvx 的运行、Git 仓库的拷贝路径和权限的处理都比原生 Windows 顺畅得多。6.3 踩坑实录一次技能失效的完整排查说一个我印象比较深的完整排查过程。有一次在 Cursor 里Superpowers 的技能突然全都不生效了——AI 的现象是你写什么都直接回答案而且完全不加载技能。我先检查了 MCP 服务状态显示 connected排除 MCP 的问题。然后我查了技能文件的目录目录还在文件也没有明显损坏。最后排查到原因Cursor 做了一个自动更新把我的项目.cursor/skills目录重置了。实际上Cursor 在更新版本时偶尔会重置一些项目级配置目录这个问题官方一直没处理干净。解决方案很简单把技能文件拷贝到全局用户目录而不是项目目录这样 Cursor 更新不会动它。或者更简单的方式是建立一个脚本每次打开项目时自动检查技能文件是否存在不存在就重新加载。我在项目里放了一个bin/check_superpowers.sh小脚本每次启动项目手动跑一次三十秒就能确认状态。这个习惯帮我省了非常多查错时间。另外我顺便说一下版本更新的问题。Superpowers 这个项目更新相当快官方经常加新技能或调整已有技能的逻辑。但你不一定每次都要追。我的策略是看更新日志如果新增的技能与我的工作流相关才升级如果只是为了修复某个我不受影响的问题就继续用旧版。项目存储库里的技能文件更是如此你不想某天所有人突然都换了一套新行为。锁定版本、按需更新这是我最真实的经验。7. 关于技能扩展与未来玩法Superpowers 的技能体系是开放的你可以自己写技能文件。这个门槛比想象中低得多——就是一个 Markdown 文件里面写清 frontmatter 的名称和描述正文写步骤指令。我写过一个小技能专门约束 AI 在编写数据库迁移脚本时必须先生成回滚脚本。核心步骤就三句话但加载之后 AI 的行为确实变稳定了。这种自定义技能的方式非常适合团队把内部规范固化进来——你团队的代码评审清单、安全红线、数据库变更流程都可以写成技能文件。就我自己这段时间的体会而言Superpowers 最大的价值不是某个单点技能而是它提供了一个把工程纪律编码化的思路。它让我对 AI 编程助手的态度从听天由命变成了可控可调。一开始你确实会因为它让 AI 变慢了而烦躁但跑完几个项目之后你会发现这种慢换来的是一致性和可追溯性。我现在已经离不开这套工作流了。最后再分享一个小技巧在每天的开发开始之前花两分钟翻一下任务列表里 AI 留下的决策日志你会清楚地知道它昨天为什么那样写也就能在今天早上准确地告诉它该怎么微调。这个习惯也许比安装任何新技能都更有价值。 
长河君 · 2026/10/6 6:34:54 · 阅读 1.2k Superpowers：给AI编程助手装上工程纪律的技能包框架
写这篇文章是因为我最近把 Superpowers 框架用在了好几个项目上效果确实有点出乎意料。之前我用 AI 编程助手写东西总觉得它像一个很聪明但纪律性很差的新人——你让它写个函数它能写得飞快但一旦涉及先分析需求、再拆任务、边写边测这套正经软件工程的流程它就容易跳步、自作主张甚至把项目搞乱。Superpowers 解决的就是这个问题它不是一个具体的开发框架而是一套给 AI 编程助手装的技能包和工作流约束器让 Claude Code、Cursor、Codex 这类工具真正按照软件工程的套路来干活。这篇东西写给谁呢主要是已经被 AI 编程助手惊艳过、又被它坑过的人。不管你是个人开发者、在小团队里负责一个模块还是那种想用 AI 加速交付但又怕代码质量失控的工程师这篇文章都会有用。我会从原理讲起然后给你完整的安装方式、我实测过的技能使用流程、以及在 Pythonpytest 自动化测试和 JavaSpring Boot两个场景下的真实组合玩法最后把那些文档里不会写的坑和排查技巧全部摊开。文章有点长但看完你应该能直接上手。我在实际使用中发现真正让 AI 编程助手从玩具变成生产力工具的关键不是换更大的模型而是给它一套可执行的工程纪律——Superpowers 干的就是这个活。1. 为什么 AI 编程助手总差那么一口气1.1 日常用 AI 写代码的几个经典翻车现场先说几个我见过太多的场景。你让 AI 助手帮我优化一下这个模块它可能直接给你重写整个文件表面看着漂亮但把你精心处理的边界条件全丢了。你让它实现一个用户登录功能它闷头把注册、找回密码、验证码全都给你写了而你只是想要一个最简的 Session 校验。更常见的是它写完代码不跑测试或者跑了测试但只跑它自己写的演示性测试你集成进主分支才发现核心逻辑就是错的。这些问题的本质不是模型能力不够。现在的模型代码生成能力已经很强了GPT 级别和 Claude 级别的模型在单点任务上相当靠谱。问题出在过程控制上——AI 没有软件工程的概念。它不知道什么是需求先行不知道什么叫小步提交更不懂测试驱动不是一种偏好而是一种纪律。你如果不给它一套流程约束它就会回到它最舒服的模式像一个急着交作业的学生看到题目就直接写答案中间过程能省则省。1.2 问题出在哪AI 不缺能力缺的是工程约束我打个比方。你让一个手艺很好的厨师自由发挥做一桌菜他大概率能做出几道惊艳的菜但也可能把厨房搞得一团糟而且你没法保证他下次还这么做。但如果你给他一套标准作业流程——先列菜单、备菜、按顺序下锅、每道菜出锅前试味——那即使换一个水平稍差点的厨师出品也会稳定得多。软件工程这些年沉淀下来的方法论其实就是厨房里的那套标准作业流程。但麻烦在于大模型不会天然遵守流程。它们在训练数据里见过海量代码但没见过提交之前必须跑一遍全量测试这种团队规范。你可以在 prompt 里临时要求它但一个复杂任务往往需要十几个甚至几十个约束条件靠人肉在每次对话里重新输入一遍既容易遗漏又浪费大量 token。Superpowers 的核心思路就是把软件工程套路固化成一套可复用的技能文件让 AI 在开始干活之前自动加载这些约束相当于给你的 AI 助手装上一套 SOP。还有一个很隐蔽的问题值得单独说AI 的上下文窗口虽然越来越大但它对项目的整体理解是碎片化的。它每次只能看到你贴给它的那几段代码对全局架构、历史决策、技术债一无所知。传统软件工程里我们靠代码评审、架构文档、口头沟通来传递这些信息而 AI 助手需要一套机制来主动发现和理解项目上下文。Superpowers 的任务拆解和项目分析技能就是干这个用的。2. Superpowers 到底是个什么东西2.1 一句话解释 SuperpowersSuperpowers 是一个开源项目作者是 Jesse Vincent在 Perl 社区很有名也是 Habits 应用的原作者。它本质上是给 AI 编程助手用的一套技能包 任务管理层。技能包是一组精心编写的 Markdown 文件每个文件教会 AI 一种特定的工作方法任务管理层则是一个 MCP 服务让 AI 可以把一个项目拆解成一个个原子任务写一个、测一个、完成一个而不是一口吞下一个大功能。MCPModel Context Protocol就是现在 AI 编程工具之间互相通信的一套标准协议。Superpowers 的 MCP 服务负责管理任务清单Task List、记录人类日志Human Log技能文件则负责给 AI 注入工作流程。这两个东西配合起来效果就是AI 拿到一个需求后先按照技能文件的指引做需求分析然后把工作分解成一个个小任务写进任务清单每个小任务都按照测试先行→实现→验证的节奏推进所有决策过程都会被记录到日志里。这和我们平时用 AI 的方式最大的区别在于它把过程显性化了。以前你让 AI 做一件事它就一头扎进去做做完给你一个结果Superpowers 会逼着 AI 先告诉你我打算怎么做做完一个步骤停下来汇报一次。这个改变在初期会让你觉得 AI变笨了——从秒回变成了一段一段挤牙膏——但真正跑完一个中型功能之后你会发现代码质量、可控性、可排查性都上了一个台阶。2.2 Skills 是什么机制Skills 在英文里就是技能实现上就是放在指定目录里的一些 Markdown 文件。每个文件都有一个标题、一段描述告诉 AI 什么时候该用这个技能、以及详细的步骤指令。AI 编程助手的运行机制是任务开始时先扫描可用的技能文件根据当前任务内容匹配最相关的技能然后加载其中的指令来规范自己的行为。举个例子Superpowers 里有一个叫 test-driven-development 的技能文件。这个文件里写的内容大致是先弄清楚要测试的行为是什么先写一个最小测试用例运行它确认失败红灯然后用最简单的代码实现让它通过绿灯再考虑重构。AI 加载了这个技能之后它再写功能就不会直接甩一坨实现代码出来而是会先跟你确认测试策略再小步推进。你甚至会发现它在跟你讨论这个测试先覆盖哪个分支。这套机制之所以有效是因为它利用了模型对角色设定和规则遵循的敏感性。模型对一段清晰、结构化的指令的遵循程度远高于你在对话中随口说的话。而且技能文件是持久化的——你今天装的技能明天、下周、下个项目都还在不需要重复配置。这一点在团队协作里尤其重要你可以让你自己电脑上的 AI 编程助手保持和同事一样的工程纪律。2.3 核心设计理念渐进式增强Superpowers 有一个非常核心的理念原文里强调得很多我翻译成大白话就是先让软件能用再让它漂亮不要一上来就追求完美架构。这个理念直指的痛点是 AI 编程助手特别喜欢做过度设计。我自己就踩过这个坑。有一回让 AI 做一个内部工具的数据导入功能它在设计阶段就开始规划什么插件化架构、消息队列、多租户隔离——结果是两天过去了一个能跑的版本都没有。后来我用 Superpowers 的 Brainstorming 技能强制它先讨论最小可用方案AI 才老实下来先写了一个同步解析 CSV 的核心函数跑通之后才讨论要不要拆任务队列。这个先解决有没有再解决好不好的思路本来就是软件工程里最朴素的道理但如果不固化到 AI 的工作流里它就会自动跑偏。Superpowers 的另一个设计理念是一次只做一件事。它的任务系统会强制把一个大的需求拆成原子任务每个任务只解决一个明确的问题。这其实是把敏捷开发里的用户故事和任务卡搬到了 AI 的工作中。为什么对 AI 特别重要因为模型在复杂任务中容易丢失信息任务越小它保持上下文一致性的能力就越强。一个功能拆成 5 个小任务逐个完成比一次性让 AI 写 500 行代码要可靠得多。3. 从零开始接入 Superpowers3.1 准备工作与环境要求开始之前先说清楚Superpowers 不是一个独立的 IDE它需要附着在某个 AI 编程助手上面运行。目前支持得比较好的是 Claude Code、Cursor、Codex CLI 这类基于代理模式的编程助手。注意代理模式是关键——那种只在对话框里生成代码块、不能自主执行命令的聊天式 AI 是用不了它的因为 Superpowers 的工作流需要 AI 有读写文件、执行测试命令的能力。环境方面主要需要两样东西一个是 Python 3.11 以上版本因为 Superpowers 的 MCP 服务是用 Python 写的推荐用 uv 这个包管理器来运行它省心很多另一个是 Git因为安装技能包的过程会从 GitHub 拉取文件。操作系统上macOS 和 Linux 都完全没问题Windows 的话建议用 WSL2纯 Windows 环境我试过在路径处理上会遇到一些麻烦后面我会在排查部分细说。安装的核心逻辑其实就两步把技能文件装到本地的一个指定目录把 MCP 服务注册到你用的编程助手配置里。技能文件装在哪个目录和具体工具相关。比如 Claude Code 读技能文件的路径一般是项目里的.claude/skills或者全局的~/.claude/skillsCursor 则是.cursor/skills。Superpowers 官方提供的安装脚本会帮你把技能文件复制到正确位置不需要你手动一个个拷贝。3.2 安装实战分客户端操作先装 MCP 服务。打开终端执行下面这个命令来全局安装 Superpowers MCP 服务uvx superpowers如果你电脑上还没有 uv先去装一下。macOS 和 Linux 可以直接一行命令搞定curl -LsSf https://astral.sh/uv/install.sh | sh装完 uv 和 MCP 服务之后就要把它注册到具体的 AI 编程助手里了。以 Cursor 为例打开 Cursor 的设置界面找到 MCP 配置项添加一个新的 MCP Server命令填uvx superpowersTransport 选 stdio保存后它会自动启动。Claude Code 的话在项目目录下执行claude mcp add --transport stdio superpowers -- uvx superpowers注册完之后再安装技能文件。Superpowers 官方提供了一键安装脚本在终端里跑curl -fsSL https://raw.githubusercontent.com/obra/superpowers/main/scripts/install_superpowers.sh | bash脚本会把核心技能文件装到你的用户目录下并输出一个提示告诉你在不同的编程助手工具里分别放到哪个位置。这里我要多说一句安装脚本输出的提示信息很关键不要扫一眼就跳过。老版本的时候它就因为安装位置不一样导致用户技能加载失败我见过很多人卡在这一步。装好之后怎么验证你在 AI 编程助手的对话里输入/查看可用命令列表应该能看到 brainstorms、task 之类的指令入口或者你直接问 AI你有哪些技能可用它会告诉你加载了哪些技能文件。我实测下来Cursor 里通过命令面板查看 MCP 状态看到 superpowers 显示 connected 就是成功了。4. 核心技能逐个拆解4.1 需求澄清与头脑风暴Brainstorming 技能很多人忽略这个技能但它其实是整个框架里最值钱的一个。Brainstorming 做什么用就是当你给 AI 一个模糊的想法时它不会立刻开始写代码而是先和你做一轮结构化的需求澄清。它会问你这个功能的用户是谁核心场景是什么有没有什么约束你希望的最小可行方案是什么我举个例子。我接到过一个需求要给一个内部告警平台加一个告警静默功能也就是允许运维人员把某些暂时不想处理的告警先按掉。如果我直接把这个需求丢给没装技能的 AI它大概率会开始设计数据库表、写 API 接口。但当我用 Brainstorming 技能之后AI 先给我列出了一串问题静默是针对单个告警还是告警规则静默之后还要不要保留原始告警要不要支持定时自动恢复这些问题看着简单但如果不事先问清楚做出来的功能大概率要返工。这个技能之所以有效是因为它把提问变成了一种规则而非偶发行为。普通模式下你让 AI 提问它就象征性问一两个问题然后开干Brainstorming 模式下它有明确的步骤清单先理解背景再列出问题清单然后逐一确认最后总结成一个需求描述。你会发现它问问题的质量非常高因为我实测下来它会刻意避免问那种搜索引擎就能回答的蠢问题把火力集中在真正影响设计的决策点上。4.2 把需求拆成能执行的任务Task 技能需求澄清完之后下一个环节就是拆解。Task 技能做的事情是把你确认过的需求描述转化成一份带优先级、带依赖关系的任务清单然后通过 MCP 服务把它持久化保存下来。每个任务都会被写成要做什么、验收标准是什么、完成后要告诉用户什么的格式。这个拆解粒度我实际用下来的经验是宁可拆小不要拆大。一个 5 到 15 分钟能完成、改动在 100 行以内的任务是最理想的。比如实现用户注册接口可以拆成添加用户模型的 email 唯一性约束编写注册接口的参数校验逻辑实现密码加密存储编写注册接口的集成测试四个任务。拆完之后AI 会按照依赖顺序逐个处理。任务拆解还带一个非常实用的好处它把 AI 的行动计划暴露给了你让你在它开始动手之前有机会纠正方向。以前你等 AI 写完代码再评审现在你可以在它动笔之前就评审它的计划。这个低成本纠偏的机会对保证项目方向正确太重要了。我习惯在 AI 给出任务清单后先人工过一遍把优先级调一调、把遗漏的任务补上再让它开始执行。4.3 测试先行Test-Driven Development 技能这是 Superpowers 框架里技术含量最高的技能也是让我真正觉得值回票价的部分。这个技能的核心是逼着 AI 严格遵循红灯-绿灯-重构的节奏先写一个会失败的测试运行它确认失败再用最简代码让它通过最后重构。听起来简单但实际执行时有一堆细节是模型默认做不到的。先说一次只写一个测试。如果你让 AI给这个模块写测试它可能会给你生成 20 个测试用例覆盖各种边界条件。这在传统开发里是优点但在严格的 TDD 流程里反而是问题——因为如果测试全部一次性写完你根本无法确认第一个测试失败的原因到底是实现缺失还是测试本身有问题。Superpowers 的 TDD 技能要求 AI 先写第一个最小测试运行确认失败然后把失败信息和原因写到任务日志里再开始实现。这个过程对 AI 是反直觉的因为模型天然倾向一步到位但恰恰是这个反直觉的约束保证了一旦出现问题你可以精准地定位到是需求理解错了测试写错了还是实现写错了。再一个细节是用最简单的方式实现。AI 在一个测试通过之后往往会顺手把实现写得很完整甚至引入一些目前还用不上的抽象。Superpowers 的 TDD 技能明确要求它只用让当前测试通过的最简实现后续测试驱动着实现逐渐演化。这个约束本质上就是 Kent Beck 说的Minimal implementation但对模型来说它需要被反复强调才会遵守。我亲测的效果是用了这个技能之后AI 生成的代码明显朴素了但也明显更难错了——它不再提前发明那些看起来很美却没人用得上的架构了。4.4 调试、重构与其他辅助技能Superpowers 里还有一组辅助技能。比如调试技能它要求 AI 在遇到 bug 时先提出对根因的假设、然后设计实验去验证而不是反复猜着改代码。这个技能我最开始不以为然直到有一个诡异的偶发 bug 折磨了我一晚上用它的流程做了一轮提出假设→设计日志→验证假设之后才发现是并发环境下共享变量被意外修改了。AI 在调试场景下最大的问题就是改一下跑一下乱试调试技能相当于给它的乱试行为加了一道假设驱动的约束。重构技能也是高频使用的。它的核心不是让 AI 直接重构而是让它先列出重构的目标和步骤、确认现有测试全绿然后每一步重构完就跑一遍测试确保行为没有变化。这和看着代码不顺眼就大改特改的区别就是安全问题。用了它之后AI 做重构时我会明显更放心因为它会持续向我报告测试状态而不是甩给我一个应该没问题吧的新代码。Human Log 也是一个容易被忽视但很实用的功能。它会记录你和 AI 协作过程中的关键决策、用户反馈、踩坑记录形成一份项目历史档案。这就相当于给 AI 装了一个长期记忆。我发现这个东西在后期的项目维护里价值很大——一个月后你重新打开项目让 AI 继续开发它可以翻看 Human Log 里之前的决策记录避免重复问你已经回答过的问题。5. 实战组合把 Superpowers 用进真实项目5.1 Python 项目结合 pytest 打造纪律化流程Python 项目是我用得最多、也是 Superpowers 适用性最好的场景。以我最常用的组合为例项目是 FastAPI 写的 API 服务测试框架是 pytestSuperpowers 负责纪律约束。我通常的路径是这样的需求来了先让 AI 用 Brainstorming 技能澄清需求然后生成任务清单随后每个任务都按 TDD 流程走——先写 pytest 测试跑出红再实现跑到绿最后重构。这里有个标准的指令序列你可以直接参考。在 Cursor 里我会这样开始使用 Superpowers 的 TDD 技能来完成这个任务。请先给我一个 pytest 测试测试目标是/users/{id} 接口在用户不存在时返回 404。先运行测试并展示红灯再实现接口逻辑并展示绿灯。AI 会先创建或修改测试文件然后执行pytest tests/test_users.py::test_get_user_not_found之类的命令。你会看到它把终端输出贴出来确认失败然后才开始写实现代码。这个过程中我最看重的是它真的会展示失败输出。因为很多时候 AI 会假装跑了测试——它可能凭经验知道某个写法会失败就直接跳过去了。只有当它明确展示了你指定的测试命令的实际输出你才能确信它真的在执行。FastAPI 项目里有一个特别适合 Superpowers 的玩法是接口测试的自动生成。让 AI 根据 OpenAPI 文档自动生成一组 pytest 测试用例校验状态码、校验响应结构和业务逻辑然后逐个 TDD 实现。这个流程在纯手工时代要花大半天现在基本上让 AI 两三个小时就能做完而且每个接口的错误分支都有测试覆盖。我最近的几个小项目都是这么跑的代码风格非常统一回归测试覆盖率也很健康。5.2 Java 后端Spring Boot 项目里的落地姿势Java 生态在 Superpowers 里的体验和 Python 有点不同。Spring Boot 项目结构更重、约定更多AI 在生成代码时往往会遇到Context 和 Bean 装配这类既依赖框架又依赖业务上下文的问题。用 Superpowers 之后的经验是把它当成一个规范器而不是魔法棒。比如要新增一个接口Superpowers 的 TDD 技能会要求 AI 先写测试。在 Spring Boot 里这个测试通常是用 MockMvc 或者WebMvcTest切片测试。AI 写测试倒是不难难的是让它正确地理解 Spring Boot 的测试约定——比如测试上下文里需要 mock 哪些 Bean、数据库怎么隔离。我建议你在项目里预先放好一套模板测试然后在任务描述里明确告诉 AI参照src/test/java/.../ControllerTests.java的写法。Superpowers 的技能文件是通用方法论具体的项目基建还是需要你来喂给它的。还有一个实战上的组合拳用 Superpowers 拆解完任务之后让 AI 按任务逐个生成 Spring Boot 的分层代码——Controller、Service、Mapper、Entity。以前直接让 AI生成一个订单模块的体验永远是代码堆在一起、逻辑混乱而拆成任务后每个任务只聚焦一层AI 的上下文能够保持干净生成的代码也符合单一职责原则。配合 Maven 的mvn test作为验证手段让 AI 每完成一个任务就跑一遍该任务的测试质量会稳很多。5.3 团队协作把技能文件同步给同事Superpowers 还有一个容易被个人开发者忽略的价值就是团队工程纪律的一致性。你可以在项目的.cursor/skills或者.claude/skills目录里维护技能文件的副本把它们提交到 Git 仓库这样所有克隆了这个仓库的开发者在本地的 AI 编程助手都会自动加载相同的技能。当然这里我要提个醒技能文件、MCP 服务版本这些东西是逐个项目演进的不要盲目追求最新版。我就经历过一次上游更新之后技能文件的行为发生变化导致 AI 在某个步骤上突然开始问我一些多余的问题。后来我的做法是团队个人使用可以追新但项目仓库里的技能文件要锁定版本确保每个成员的行为一致。这个东西就像 ESLint 规则和代码风格一样稳定压倒一切。实际上把技能文件纳入代码评审会非常有趣。你想一下当一次 AI 生成的代码合并进主分支之前评审者不仅看代码还看 AI 是怎么走完整个流程的——测试先写了没、任务拆分合理不合理、决策日志有没有记录。这个东西对保证交付质量的作用比我预想的要大得多。6. 常见问题与排查技巧实录6.1 问题速查表我用了一段时间踩了不少坑。先说几个高频问题。症状可能原因解决方案MCP 服务显示连接失败uv 未安装或版本不对低于 0.4 可能会有兼容问题重新运行 curl -LsSf https://astral.sh/uv/install.shAI 不调用任何技能直接开写技能文件没放到正确目录或文件名/目录名缺失检查.claude/skills/.cursor/skills目录确认 superpowers 相关目录和文件在可加载的位置技能偶尔生效偶尔不生效项目级和全局级的技能配置冲突删掉重复的技能文件按项目级优先原则只保留一份TDD 流程里 AI 跳过红灯直接写实现技能加载成功但指令被模型忽略了在 prompt 里强制要求先输出测试代码并运行粘贴失败输出然后才允许写实现任务清单没有持久化MCP 服务启动失败在终端手动运行uvx superpowers看报错信息多半是版本或环境变量问题中文项目里 AI 输出有时混杂英文技能文件是英文写的在加载技能时补充一句请使用中文思考和回答代码注释和变量名用英文这里每一项我都实际遇到过说几个细节。MCP 连接失败是最常见的绝大多数情况下是 uv 没有正确安装或者 PATH 没有生效。打开终端手动跑一次uvx superpowers如果能看到服务启动输出就说明本身没问题需要去看编辑器的 MCP 配置是否填错了命令参数。还有一个隐蔽的问题技能文件目录名不能随便改。Superpowers 的技能在 Markdown frontmatter 里定义了 name 字段AI 编程助手会通过这个名字来索引技能。你把目录从test-driven-development改成了tddAI 可能就找不到它了。这个坑我见过好几个新手踩。6.2 我的几条独家避坑心得第一不要一开始就让 Superpowers 参与全部项目。刚上手的时候把它用在一个功能边界清晰的小任务上比如给一个已有的小模块补测试。等熟悉了它的工作流再扩展到新功能开发。你直接拿一个大项目做实验会同时遇到框架配置不熟、技能文件冲突、AI 行为改变带来的认知负荷问题叠问题很容易劝退。第二学会说停并纠正 AI 的行为。Superpowers 给出的工作流是通用模板不一定总能匹配你的偏好。比如它可能默认每次任务完成都要向你汇报但在一个很小的改动里这种汇报就是噪音。你可以明确告诉它这个小任务不需要详细汇报直接在任务列表里标记完成即可。技能是工具不是圣旨你要掌握对它的微调权。第三定期观察 Human Log 和任务历史。有一次我发现 AI 在三天前的一次任务中有一个我认为这里可能存在 xxx 风险的记录后来真的爆出了那个问题。这个日志机制把 AI 的隐性判断变成了显性信息非常值得利用。你甚至可以要求 AI 在做重要决策时把为什么这么做写成日志这些记录在事后复盘时非常有价值。第四在 Windows 上建议直接用 WSL2。纯 Windows 环境下脚本安装的路径处理、文件权限、命令执行都会遇到莫名其妙的坑。我在 WSL2 里装了一次就没再碰到过问题。包括 uvx 的运行、Git 仓库的拷贝路径和权限的处理都比原生 Windows 顺畅得多。6.3 踩坑实录一次技能失效的完整排查说一个我印象比较深的完整排查过程。有一次在 Cursor 里Superpowers 的技能突然全都不生效了——AI 的现象是你写什么都直接回答案而且完全不加载技能。我先检查了 MCP 服务状态显示 connected排除 MCP 的问题。然后我查了技能文件的目录目录还在文件也没有明显损坏。最后排查到原因Cursor 做了一个自动更新把我的项目.cursor/skills目录重置了。实际上Cursor 在更新版本时偶尔会重置一些项目级配置目录这个问题官方一直没处理干净。解决方案很简单把技能文件拷贝到全局用户目录而不是项目目录这样 Cursor 更新不会动它。或者更简单的方式是建立一个脚本每次打开项目时自动检查技能文件是否存在不存在就重新加载。我在项目里放了一个bin/check_superpowers.sh小脚本每次启动项目手动跑一次三十秒就能确认状态。这个习惯帮我省了非常多查错时间。另外我顺便说一下版本更新的问题。Superpowers 这个项目更新相当快官方经常加新技能或调整已有技能的逻辑。但你不一定每次都要追。我的策略是看更新日志如果新增的技能与我的工作流相关才升级如果只是为了修复某个我不受影响的问题就继续用旧版。项目存储库里的技能文件更是如此你不想某天所有人突然都换了一套新行为。锁定版本、按需更新这是我最真实的经验。7. 关于技能扩展与未来玩法Superpowers 的技能体系是开放的你可以自己写技能文件。这个门槛比想象中低得多——就是一个 Markdown 文件里面写清 frontmatter 的名称和描述正文写步骤指令。我写过一个小技能专门约束 AI 在编写数据库迁移脚本时必须先生成回滚脚本。核心步骤就三句话但加载之后 AI 的行为确实变稳定了。这种自定义技能的方式非常适合团队把内部规范固化进来——你团队的代码评审清单、安全红线、数据库变更流程都可以写成技能文件。就我自己这段时间的体会而言Superpowers 最大的价值不是某个单点技能而是它提供了一个把工程纪律编码化的思路。它让我对 AI 编程助手的态度从听天由命变成了可控可调。一开始你确实会因为它让 AI 变慢了而烦躁但跑完几个项目之后你会发现这种慢换来的是一致性和可追溯性。我现在已经离不开这套工作流了。最后再分享一个小技巧在每天的开发开始之前花两分钟翻一下任务列表里 AI 留下的决策日志你会清楚地知道它昨天为什么那样写也就能在今天早上准确地告诉它该怎么微调。这个习惯也许比安装任何新技能都更有价值。