superpowers：让AI编程助手遵守流程、记住项目、拆解任务

本来只是一时手痒想试试水结果superpowers直接成了我现在开发工作流里离不开的一层。如果你已经在用 Claude Code 或者 Codex 这类命令行 AI 编程助手但总觉得它们能力有余、稳定性不足每次会话都像失忆一样重新认识你的项目——那这篇文章大概率就是你需要的。我会从它到底解决了什么问题讲起然后一步步拆它的技能Skills机制、记忆机制、安装流程最后拿一个 Java 项目的实际场景演示怎么让它真正干活。先说人话版本superpowers 是一个开源的 AI 编程助手增强框架它通过技能系统 项目记忆 子代理任务拆解三件套把通用 AI 助理变成一个懂流程、有记性、会自我改进的开发老手。它适合已经在用或准备用 AI 编程助手的人尤其是受够了 AI 频繁跑偏、不遵守项目规范、每次对话都要重新交代上下文的老用户。1. 先说清楚superpowers 到底是什么1.1 它解决的核心痛点我最早用 Claude Code 的时候感受特别深单次对话里写点函数、改个测试效果确实惊艳可一旦碰到跨文件重构、多步骤功能开发它就很容易失控。比如做了一半突然忘了最初的技术约束比如给你推荐一个和现有架构格格不入的方案再比如明明天天在这个项目里干活每次新会话还是完全不记得项目的目录结构、代码规范和常见坑。这些问题的根源不是模型不够聪明而是工作方式有问题。AI 编程助手默认是聊天式的你问一句它答一句缺乏工程上最基本的东西——流程、检查点、上下文沉淀。superpowers 的思路很直接既然默认行为不靠谱那就给 AI 套上一层工程纪律。它通过技能文件告诉 AI 先做什么、后做什么、每一步的完成标准是什么通过项目记忆文件让 AI 在项目里积累的经验能被持久化、跨会话复用通过任务分解机制把复杂目标拆成一个个可验证的小任务降低一口气写崩的概率。这个定位和传统的提示词工程完全不一样。提示词工程是你每一次对话都要精心写一段提示词来约束模型而 superpowers 把这套约束做成了可持续复用的资产一次配置长期生效。1.2 它和 MCP、普通插件的区别很多人第一反应是这不就是 MCPModel Context Protocol或者插件市场吗其实差别很大。MCP 的核心是为 AI 提供外部工具和实时数据源比如连数据库、查文档、调 API它解决的是AI 能调用什么的问题。superpowers 解决的是AI 做事有没有章法的问题。一个偏工具接入一个偏行为治理。普通插件往往是把某个特定功能打包挂上去比如加一个代码格式化命令。superpowers 做的则是给 AI 整套任职培训你想让 AI 按什么流程干活、按什么质量验收、遇到问题怎么排查都可以写成技能文件让它执行。如果说 MCP 是给 AI 装上手脚那 superpowers 更像是给它装上一个大脑的决策系统。还有一个关键区别superpowers 是零常驻服务的。它不像某些方案需要起一个后台服务、配置 API 地址、维护端口它的技能就是一份份 Markdown 加脚本存放在项目目录里AI 直接读取执行。这意味着它几乎没有运维负担拿到就能用换项目也只需要拷贝目录。2. 核心机制拆解技能和记忆是怎么真正生效的2.1 技能的本质把工程经验写成人机都能读的文档在 superpowers 里技能Skill不是玄学而是一个有固定结构的目录。每个技能目录里通常有一个核心说明文件很多项目里叫 SKILL.md里面写清楚了这个技能解决什么问题、在什么情况下触发、需要哪些前置条件、具体分几步执行、每一步的完成标准是什么以及如果失败该怎么办。听起来是不是很像你在公司写的那些 SOP标准作业流程对就是把 SOP 给了 AI。但这里有个微妙之处给人类看的 SOP 需要省略很多默认常识给 AI 看的技能文件必须写得更明确。典型的人类直觉是这个你肯定懂不用写但 AI 偏偏就是那个你不写我就不做的呆子。比如你写一个带测试重构的技能如果只写重构并保证测试通过AI 很可能会走捷径——改完代码不看整体影响面或者干脆先断章取义。但技能文件里写清楚第一步建立基线快照记录重构前的测试结果第二步识别并列出所有依赖该函数的调用方第三步逐层重构并每改完一层就运行一次测试第四步全部完成后对比基线输出变更说明AI 的执行质量就会完全不一样。我从使用中体会到的最重要一点是技能文件的质量直接决定了 AI 输出质量的上限。一个泛泛而谈的技能产出的还是泛泛而谈的代码一个把验收标准写清楚、把失败预案写清楚的技能AI 才能真正像熟手一样干活。所以别把 superpowers 理解成装了就变强它是你给 AI 建立流程它给你稳定的产出。2.2 项目记忆让 AI 从每次都像第一次变成越用越懂你项目记忆大概是 superpowers 里最容易被低估的功能。默认状态下所有 AI 编程助手都是无状态的每次新会话都是全新的人。哪怕你在上一个会话里刚确定了模块命名规则、刚排查完某个诡异的死锁问题、刚和 AI 约定了接口设计风格关闭终端之后这些信息统统消失。superpowers 的做法是提供一个持久化的记忆存储机制让 AI 把重要的项目洞察写进本地文件比如项目结构说明、架构决策记录、踩坑记录、常用命令、环境特殊性等等。下次会话启动时AI 会读取这些记忆文件相当于入职就看老员工留下的项目笔记。这个机制带来的体验变化是质变的。最典型的表现是你在新会话里提到某个历史遗留问题AI 不再是茫然地问这是什么而是直接说根据之前的记录这个问题是因为某次依赖升级引发的之前的处理方案是……。这种连续感会让你有这个人已经是我团队里的一员的错觉。但要注意项目记忆不是自动全部写入的它需要 AI 在运行过程中判断哪些值得记。所以实际使用中你会发现记忆质量和你的引导强相关。你越是在关键节点让 AI把刚才的决策记录到记忆里后续 AI 的表现就越像资深成员。换句话说记忆系统是一个需要喂的习惯系统喂得越勤快回报越大。2.3 子代理与任务分解把大目标拆成可验收的动作superpowers 还有一个我很喜欢的能力任务分解与子代理执行。人在面对一个大需求时会自然地把它拆成先做环境准备、再做基础接口、最后做集成测试这样的步骤但 AI 默认不会这么想它倾向于一口气把答案全吐出来。在复杂任务里这种一口闷恰恰是翻车重灾区因为中间任何一步理解偏差都会引发连锁错误。superpowers 的分解决策机制是让 AI 在执行大任务前先建立一个显式的任务清单然后逐个任务推进并且在每个任务完成后检查是否符合上一阶段的预期。更复杂的场景还可以通过子代理并行处理不同子任务——一个负责调研现有代码一个负责设计接口一个负责写测试最后汇总。实际用下来这种做法的价值不只是准确率的提升更重要的是可控性。任务被拆小之后你可以随时看到 AI 当前在做什么、是否偏离了方向而不是等它闷头写完才发现整个方向都错了。人机协作里及时纠偏往往比一次作对更现实这也是任务分解机制最大的贡献。3. 从零安装 superpowers具体步骤与首次启动检查3.1. 前提条件先确认环境。superpowers 本质上是寄生在 AI 编程助手里的框架所以你需要一个基础宿主最常见的是 Claude Code 这类支持插件市场的命令行工具Codex 用户也可以通过指令文件方式引入技能。环境要求上我建议满足这几条Python 3.8 或 Node.js 16取决于你使用哪些技能脚本很多技能会调用 shell/python提前装好省得后边折腾Git 可用因为市场订阅和技能更新都通过 Git 拉取AI 编程助手本身已配置好 API 密钥并能正常工作。再提醒一下superpowers 不挑项目语言Java、Go、Python、前端工程都能用技能内容本身是语言中立的。网上很多人搜superpowers java其实搜的不是某个 Java 专属版本而是想知道在 Java 项目里怎么配合使用——后面我会专门讲这部分。3.2 安装步骤安装的核心动作是两步添加插件市场然后安装插件。在宿主工具的交互界面中执行如下命令# 第一步添加 superpowers 的插件市场 /plugin marketplace add obra/superpowers-marketplace # 第二步从该市场安装 superpowers 插件 /plugin install superpowerssuperpowers-marketplace执行完成后重启当前项目对应的 AI 编程会话让插件机制完成加载。然后验证是否安装成功在交互界面里输入以下斜杠指令之一如果能弹出对应的技能菜单或操作面板说明框架已经生效/superpowers /think如果第一条命令可用你通常会看到一个包含技能列表、记忆入口、任务管理入口的主菜单。这就说明 superpowers 已经接管了一部分工作流。这里有个细节很多人会忽略插件市场地址和插件实例命名的关系。上面命令里的superpowerssuperpowers-marketplace可以理解为从名为 superpowers-marketplace 的市场安装名为 superpowers 的插件。如果你在添加市场时改了别名后边的引用也要跟着改否则会报找不到安装源。3.3 安装后的首次启动检查装完了先别急着让它写大功能我建议花十分钟做三件检查第一确认项目记忆目录是否自动初始化。通常在项目根目录下会出现一个用来承载记忆和技能的隐藏目录不同版本目录名可能略有差异里面有技能库子目录、记忆子目录等骨架结构。看到这个说明插件的工作目录已经和你的项目绑定。第二尝试让 AI 记录一条显式记忆。比如对它说请把本项目使用 Gradle 构建、Java 17、测试目录在 src/test 下这些信息记入项目记忆然后检查记忆文件里是否出现了结构化条目。这一步如果通了跨会话记忆机制就基本靠谱了。第三订阅一个你最常用的技能库实操一次技能加载。比如订阅社区里代码审查或编写测试类的技能包然后触发一下看 AI 是否按照技能文件里的步骤行动而不是用通用聊天方式来响应。这一步能直观感受到有技能和没技能的行为差异。检查完毕你对 superpowers 的工作方式就有了实感。接下来才是重头戏怎么在真实项目里把它用出价值。4. 实战把 superpowers 真正用进 Java 项目4.1 为 Java 项目订阅合适的技能包在 Java 项目里用 superpowers我建议先从三类技能包入手依赖与构建类指导、单元测试与重构类、项目架构与代码规范类。依赖与构建类的价值在于AI 对最新版本的依赖兼容性信息是天然缺失的但如果技能里内置了升级依赖前先查变更日志、锁定版本前先验证兼容性、每次构建失败先看第一条错误堆栈这类流程AI 就很少会乱给指导。Java 这门语言的生态非常看重工具链Gradle、Maven、JUnit、Spring Boot 相关操作如果能以技能形式沉淀会比纯聊天式的询问可靠得多。测试与重构类是 Java 项目里收益最直接的。Java 的老代码普遍存在过度设计、冗长方法体、强耦合等问题AI 接手时如果没有纪律很容易把重构变成换了个写法但行为变了。一个合格的带测试重构技能应该强制 AI 在动手前先建立行为基线、用测试锁定现有行为然后再小步重构。代码规范类的技能建议从你自己的团队文档里整理不要直接照搬网上的通用规范。Java 团队通常有包命名规范、异常处理约定、数据库访问分层约定等把这些整理成技能文件AI 写的代码才会像你们团队的人写的而不是像一个混合了全世界风格的缝合怪。关于订阅操作一般在/superpowers菜单里找到技能管理相关入口能浏览社区技能市场并选择安装。安装后技能会出现在本地的技能目录里你可以打开看看里面的 SKILL.md理解它到底怎么约束 AI 的再决定是否保留。4.2 一次典型的重构任务实操记录拿我最近一次真实经历来说一个遗留的 Spring Boot 服务里有个 god class一个类里塞了两千多行既有缓存逻辑又有数据源访问又有异步任务任何人动它都胆战心惊。以往让 AI 重构这种代码我是不放心的但挂了带测试重构技能之后我决定完整跑一遍流程。我给 AI 的指令很简单使用重构技能分析并重构 OrderService 这个类要求行为完全一致。AI 的响应方式和之前没挂技能时明显不同。它先做的事是建立基线阅读了类里所有方法找出了对应的测试类运行了一次完整测试并记录结果然后生成了一份现状分析包括类职责列表、依赖关系、明显坏味道和重构建议。这个动手前先看清全局的动作就是技能文件里写死的流程在起作用。接下来它把重构拆成了五个小步骤提取数据访问层、抽离缓存中间层、分离异步处理逻辑、补充新类的单元测试、最后做整包回归。每完成一步它都会停下来运行相关测试然后把变更要点记录到项目记忆里。这中间出现过一次问题——第二步完成之后一个老测试失败了因为缓存中间层引入了双写缓存机制触发了某个并发场景的时序断言。放在以前AI 很可能自己偷偷改掉那个测试来让测试变绿但技能文件里明确写了除非异常行为有明确证据否则测试失败代表重构引入回归必须回退本次变更或找根因所以它选择了回退第二步换了个不改变原有缓存语义的实现方案测试顺利通过。最终整个重构跨了多次会话、花了一下午但质量是可控的每一步都有测试兜底最后的 diff review 只花了几分钟。这种体验让我彻底改观AI 编程助手能不能放心用于生产代码真正决定因素其实是你有没有给它建立纪律。4.3 让 AI 学会你的项目规范自建技能如果你希望 superpowers 在 Java 项目里长期发挥价值一定别停留在订阅现成技能要开始建自己的技能。我强烈建议从下面这几个自建技能起步第一个是新功能开发流程技能。把你们团队从需求到提测的标准流程写进去比如先确认数据模型设计、再写接口定义、然后实现核心逻辑、最后补测试和文档。AI 每次开始一个任务时只要触发这个技能就不会跳过你们的标准步骤。第二个是问题排查技能。把团队常用的排查手段沉淀进去先看日志里第一个 ERROR 级别的堆栈、再检查最近变更的记录、用 Arthas 或 IDE 工具定位热点、排查分布式链路追踪等。Java 线上问题的排查思路比较固定适合固化成技能AI 会比人更记得住要按顺序来。第三个是后端代码评审技能。这个技能的价值不只是让 AI 审查自身代码还能让它审查同事的 MR。设定统一的检查维度并发安全、事务边界、SQL 性能、异常处理完整性、可维护性、命名一致性等每一项给出打分维度。团队用下来几周能显著减少低级问题流转到线上。建技能的入口一般在/superpowers菜单的构建技能或新建技能相关选项中。创建后它会生成一个技能目录你只需要编写里面的 SKILL.md 文件把触发条件、执行流程、完成标准写清楚。写完先在一个小任务上试跑看 AI 有没有误解然后迭代一两次就稳定了。5. 常见问题与避坑经验5.1 问题速查表我在不同项目的使用中遇到过一些比较典型的问题这里整理成速查表现象常见原因处理方式安装后菜单不出现插件市场地址或插件名引用不一致重新核对marketplace add时用的名称使用superpowers超级市场别名格式重装技能加载了但 AI 执行时无视技能技能触发条件写得太宽泛AI 没判断出该用它在指令里明确说使用 XX 技能处理并检查技能文件的触发条件和名称是否匹配项目记忆没有起作用记忆目录未初始化或 AI 没有权限写相关目录手动让 AI 显式写一条记忆确认目录可写检查配置文件是否禁用了写入AI 重构后测试失败却想改测试技能文件缺少行为保持是最高优先级条款在技能里写死禁令测试失败默认代表回归不允许修改掩蔽问题的测试订阅的技能与项目语言不匹配技能库是全领域通用没有按项目筛选本地只保留适量技能Java 项目就尽量减少无关技能降低AI误选概率插件占用额外 context 过长技能文件写得过于冗长充满了废话精简技能文件把为什么放在文档开头把怎么做浓缩成可检查的步骤清单还有一个大部分人会被绊住的点superpowers 的很多技能会调用外部脚本如果你的项目环境网络受限脚本执行就会失败AI 还可能误报技能执行成功。我习惯在每个技能文件的完成标准里加一条脚本输出需包含成功的退出码或明确的成功标志这样 AI 无法在脚本真的失败时蒙混过关。5.2 三条我踩坑后总结的使用原则第一技能宁缺毋滥。我一开始看到社区几百个技能包忍不住装了一堆。结果 AI 经常选错技能行为反而比不装更不可控。后来我只保留和当前项目直接相关的 5 到 10 个技能准确率立刻上来了。技能是纪律纪律太多就变成了束缚。第二记忆要及时存档。项目记忆不是丢给 AI 自己用就行的它需要人工在关键时刻钉钉子。比如你刚和 AI 讨论完一个重要的架构选型最好立刻让它写进记忆刚踩完一个特别诡异的坑也记下来。后续碰到相似问题的时候你就知道这几个存档有多值钱了。第三学会看 AI 的行为轨迹。用 superpowers 之后AI 会在执行技能时输出大量中间过程比如当前走到了第几步、检查结果如何、准备执行哪个动作。不要只看最终结果关键是要看过程有没有遵循技能要求。一旦发现它在跳步骤马上打断纠正纠正两三次后它会形成路径依赖效果会越来越稳定。把 superpowers 纳入我的日常 AI 工具链之后最直观的变化并不是AI 写的代码变多聪明了而是AI 的执行变得可以预测了。挂在技能系统里的流程和规范像一根缰绳让它不再天马行空而是按着你的规矩办事。这套框架本身不复杂花个半天就能跑通但真正的大头在于你怎么持续为它沉淀技能和记忆——这有点像带新人你投入多少整理流程、记录经验它就能回馈给你多少稳定可靠的执行力。我现在的团队已经默认每个 AI 辅助开发的项目都配一份本地技能包这大概是我用过那么多 AI 增强工具后唯一一个让我觉得应该长期用下去的东西。