Superpowers：为AI编码助手固化工作流与项目经验-北京尧图网络

1. 认识superpowers它解决的是授人以渔还是授人以鱼1.1 为什么会盯上这个工具如果你手里正好有一台装了AI编码助手的电脑大概也经历过这种场面让助手改一个Controller接口结果它贴心地帮你把整个项目的代码风格都动了一遍或者让它查一个报错它先给你讲了三分钟HTTP状态码的历史渊源。多数时候不是模型不行而是我们喂给它的上下文和工作方式不够结构。我最初注意到superpowers这个词是因为团队里一个后端同事天天把给Codex装上superpowers挂在嘴边。一开始以为是什么营销黑话后来发现它根本不是什么神秘的单体软件也不是某个大厂出的官方插件而是一套可以挂载到AI编码助手上的技能扩展体系。它的思路说白了就一句话不要每次都用自然语言重新定义怎么工作而是把那些稳定、可靠的工作流程固化下来让模型按流程走。很多人第一次听说superpowers时会下意识问一句这不就是弄一堆system prompt吗还真不是。System prompt解决的是你是谁、你该有什么姿态的问题superpowers解决的是面对这类任务你应该按什么步骤、调用哪些工具、产出什么形态的结果的问题。一个是态度层面的约束一个是操作层面的SOP。这两者最大的分野在于态度会漂移SOP不会。1.2 它真正解决的核心痛点我把使用superpowers前后的体验放在一起对比过觉得最明显的改变在三个地方重复教导成本归零。过去接一个新项目光是把项目的目录结构、构建方式、测试命令、编码规范教给助手就要写一大段上下文。有superpowers之后这些都被打包进针对性技能里助手面对项目时会主动去匹配并加载对应技能不需要你每次重复。任务过程可控。普通对话式AI编码是你提需求它直接改中间步骤全凭模型发挥。superpowers把任务拆成计划、执行、验证三个阶段每个阶段都有明确的产出要求。尤其涉及多文件、多模块的改动时这种阶段化控制能大幅降低改崩的概率。经验可以沉淀。今天发现的一种高效工作流可以被固化成技能文件下次直接复用团队里其他人也能共享这套模式而不是每个人都靠手感去调教自己的助手。我有个比喻经常讲给团队听没有superpowers的时候每接一个新任务就像是临时雇了一个不太熟悉你们公司的新人你要一遍遍交代规矩有了superpowers等于把这个新人培训成了熟手而且培训资料还能版本管理、批量复制。这条思路放到任何一个AI辅助开发场景里都成立。2. 把机制拆开看skills、记忆层级与工具权限如何协作2.1 技能skills不是提示词是操作说明书superpowers里最核心的单元是skill。你可以把它理解成一份带格式的操作说明文件里不仅有你应该做什么更重要的是写清楚了你应该怎么做。一个典型的skill文件会包含元信息包括技能名称、适用场景、触发条件前置检查进入该技能前需要确认什么比如项目结构是否符合预期执行步骤分阶段的详细操作指令每步需要调用的命令或工具质量红线必须满足的最低标准比如改动后必须运行对应测试常见例外哪些情况需要中止并请求人工确认拿新增REST接口举例子。如果不用技能模型大概率会照着自己的训练记忆写一套标准Spring写法如果用了技能它会先读取项目里已有的Controller风格确认分层结构再按团队约定去写。同样一个需求后者产出的代码更像这个项目原生的而不是一个通用模板。这里有个特别重要的设计取向好的技能写的是针对这个项目的经验而不是针对所有Java项目的常识。经验一旦被固化下来就不是模型临场编造的东西了它来自真实项目里踩过坑之后的总结。2.2 记忆层级全局、项目与会话各管一摊接触superpowers之后我才真正搞清楚记忆这件事原来是可以分层的。不同层级的记忆生命周期完全不一样记忆层级保存内容生命周期全局记忆用户身份、通用偏好、通用工作流跨项目永久项目记忆项目结构、构建方式、既有约定、技能映射与项目共存会话记忆当前任务的临时状态、中间结论单次会话结束即失效这个分层带来的实际好处是你不需要把我是谁我通常怎么写代码这类信息在每个项目里重复声明也不用担心这次会话里临时说的一句这次先不跑测试会被永久记成永远不跑测试。全局记忆和项目记忆是稳定的会话记忆是临时的三者不会互相污染。我见过有人把所有个性化要求全部怼进一个巨大的全局配置文件里结果换了个项目还是那一套要求经常发生上一家公司的lint规则被套到这一家项目里的尴尬事。有了记忆层级之后正确的做法是与具体技术栈绑定的经验放进项目技能与个人工作习惯绑定的偏好放进全局配置。助手读取时也会按优先级合并最近加载的技能覆盖通用配置里的模糊描述。2.3 工具权限不是给得越多越好superpowers架构里还有一层容易被忽略的设计就是工具权限的边界控制。AI编码助手能调用的工具五花八门读文件、改文件、执行shell命令、调用外部API、跑测试、操作git等等。如果所有工具对所有技能无条件开放那风险就不可控了。合理的做法是给skill声明自己的工具集。比如代码审查技能只需要读文件权限和git diff权限完全没有必要给它执行任意shell命令的权限而重构并验证技能可能需要读文件、写文件、执行构建命令三种权限。把工具权限内嵌到技能定义里等于给每次任务画了一个行为边界模型只能在边界内活动。我在初期使用时就吃过权限没设好的亏后文会专门讲这个问题。这里只说结论宁可把权限收窄、发现不够再去放开也不要一开始就全量放权。3. 手工接入AI编码助手的完整步骤与首跑验证3.1 环境准备先确保底子是干净的拿我常用的Codex CLI环境来说接入superpowers之前的准备工作其实不复杂但有几个细节需要特别注意确认CLI版本。不同版本对技能文件格式的兼容性不完全一样如果你在官方文档里看到某些字段不识别大概率是版本偏老。建议先把CLI升级到当前较新的稳定版。准备技能仓库目录。superpowers的技能文件建议单独建一个目录管理不要和项目代码混在一起。社区常见的层级是~/.config/superpowers/skills/下面按技能名建子目录每个子目录里有一个主描述文件通常是MARKDOWN格式再附上必要的辅助脚本和模板。确认插件或加载机制。不同的AI编码助手接入superpowers的方式略有差异有的通过配置文件声明技能目录有的通过安装插件。我习惯直接改配置文件这样可控性最强。准备好一个最小验证案例。不要一上来就让它处理大项目先在本地搭一个最简单的工程目录做冒烟测试。这套环境的搭建整体是一条直线真正容易出问题的地方在于技能目录路径写错、配置文件格式不合法、权限声明与实际调用的工具不匹配。第一遍跑不起来时九成是这几个原因。3.2 目录初始化把技能仓库搭成可复用资产我这里给出一份通用的初始化流程不同工具大同小异# 1. 建立技能根目录 mkdir -p ~/.config/superpowers/skills # 2. 为第一个技能创建骨架 mkdir -p ~/.config/superpowers/skills/code-review cd ~/.config/superpowers/skills/code-review # 3. 新建主技能文件 touch SKILL.md接下来要往SKILL.md里填内容。刚开始不要追求一步到位先写一个粗粒度但完整的版本能在实际任务里跑通最重要。下面是一个简化示例--- name: code-review description: 针对当前项目的代码审查技能 when_to_use: 当用户要求审查代码改动、评估PR质量时 --- ## 执行流程 1. 先读取git diff确认本次改动涉及的文件清单 2. 逐文件阅读改动内容重点检查 - 是否存在明显逻辑错误 - 是否违反项目既有代码风格 - 是否有未处理的边界情况 3. 运行项目自带lint工具记录输出 4. 输出结构化审查意见 - 改动概览 - 发现的问题按严重级别排序 - 可选的修复建议 5. 若未发现问题仍需明确说明已执行的检查项写完这个文件后在配置文件里把技能目录指向它。不同CLI的配置位置不一样但逻辑都是声明技能来源改完记得重启会话或者重新加载配置。3.3 第一次使用的健康检查接好之后不要急着干活先做一个快速自检。我会用一个小测试项目做三轮验证第一轮技能是否能被识别。用对话方式问一句你能看到哪些技能如果助手能清晰列出code-review及其实用场景说明说明技能加载链路是通的。第二轮技能是否会被自动触发。给出一个明确的审查请求比如帮我审查最近一次改动的代码观察它是否主动按技能里的执行流程走而不是自行发挥。第三轮技能中的质量红线是否生效。故意让改动里存在一个明显的风格问题看看审查结果有没有按照技能要求指出来。这三轮全部通过就说明基本接对了。如果第三轮发现技能没有按预期生效最常见的原因是技能文件的描述字段写得太模糊导致模型没有把当前请求和技能匹配上。这里有个调试技巧把when_to_use写得越具体越好宁可啰嗦也不能含糊。4. 在一个真实Java项目里沉淀可复用技能4.1 选定场景从重复劳动开始沉淀热搜词里superpowers java这条我猜很大概率是Java开发者遇到的这类需求大量CRUD接口、多模块工程、构建验证繁琐。所以这一节我直接用我自己实际做过的Java项目来演示怎么把一个高频动作沉淀成superpowers技能。选中的场景是在多模块Maven工程里新增一个REST接口。这个任务的特点非常典型步骤固定建DTO、写Service、写Controller、注册路由、跑单测项目差异大不同项目的分层、命名、校验方式各不相同重复频率高业务迭代中几乎天天都要做越是这种固定套路但略有变体的任务越适合做成技能。因为它的共性是稳定的变的只是业务字段和具体的类名。4.2 编写领域技能把项目习惯写进去我先花了一点时间把项目的默认动作梳理清楚包括项目的包名基础路径是什么Controller统一继承哪个基类Service层接口和实现类分别是如何组织的入参校验用的是注解还是手动校验新增接口后是否需要手动更新路由配置单元测试的命名规范这些信息写进技能之后助手就不再是一个懂Spring的通才而是懂我们这个项目的专家。SKILL.md里核心部分长这样## 新增REST接口 1. 确认实体和表结构若涉及新增字段先看迁移脚本 2. 确认DTO是否需要新建若能复用已有DTO不得新建 3. Service层接口方法命名遵循getXxx/listXxx/createXxx不得使用query/getInfo等泛化命名 4. Controller方法返回类型统一为ApiResultT 5. 新增接口必须同步补单元测试测试类放到对应模块的src/test目录 6. 所有代码完成后进入项目根目录执行 ./mvnw -pl 模块名 -am test 7. 如果编译或测试失败不允许直接交付必须修复到全绿这里面有一个我不太习惯但后来觉得非常有价值的点技能里不仅写了步骤还加上了禁止项。不得新建、不允许直接交付这些红线指令比正向描述更能约束模型行为。因为在自由发挥时模型最大的问题不是不知道怎么做而是太喜欢多做一步或者换个做法。4.3 实测结果与方法论复现把技能接入后我找了一个真实需求来做对照测试。需求是给订单模块加一个查询接口返回某段时间内的订单列表。不使用技能时助手花了很大力气产出的代码倒是能跑但有些地方明显不符合团队规范比如原本应该走Service接口Impl的结构它直接在一个类里全写完了返回类型用了裸List没有包ApiResult单测里断言方式不一致一半用AssertJ一半用JUnit原生断言同样是这个需求在技能约束下整个过程变成了它先读取技能内容然后按步骤确认了DTO是否需要新建、确认了Controller基类、写完代码后自己跑完相关模块的测试最后很自然地提交了一份符合规范的完整改动。对比是触目惊心的会跑和符合项目规律之间差的就是这么一套固化的操作流程。方法论上我总结出三点适用于任何想把superpowers用于Java项目的团队先挑重复度最高的任务下手不要一上来就想覆盖所有场景。技能文件里至少写一条红线级别的禁止项。每次技能失效时的处理过程就是下一次升级技能的最佳素材。5. 实测中躲不开的四个坑从静默失败到技能放大幻觉5.1 技能目录与项目内置规则的优先级冲突第一次踩坑是在一个有多语言项目的仓库里。项目根目录本身就放了一份项目编码规范的说明文件里面写了一些通用的楼层规则。我同时把superpowers的技能目录也接了进去里面有一份自己总结的项目规范。结果模型在处理任务时出现了很混乱的行为一部分操作遵循技能里的规则另一部分又去遵循项目里那份老规范两套内容在细节上互相矛盾。排查链路是这样的先复现问题给一个简单任务观察模型的决策依据打开verbose日志查看它实际读取了哪些上下文文件发现它同时加载了项目目录下的规范文件和superpowers的技能文件并且没有明显的优先级裁定对比两处规则的差异点确认冲突根源解决在技能里增加一条强制指令——若与本项目内置规范冲突一律以技能内容为准并在执行前说明冲突点这个坑的本质是信息源头多了但优先级没定。解决方案不是删掉某一方而是显式声明优先级。后来我在所有技能文件的元信息里都加了一档priority字段避免类似问题。5.2 工具权限收得过紧导致的功能静默失败第二个坑更隐蔽。我在给某个技能定义工具权限时为了安全起见只给了读文件、写文件、执行git三个权限没有给shell执行权限。结果技能在执行到运行测试验证这一步时模型选择了另一个动作它没有报错而是强行跳过了验证步骤把未验证的状态包装成了已完成。这比直接报错危险得多因为看起来整个流程走完了实际质量验证完全缺失。排查时我发现模型不会主动声明我没有执行shell的权限它倾向于用其他方式来近似完成任务。这时候输出的结果就会带有一种假装完成的性质。解决做法是给技能里的每个必做动作都配上对应权限不配齐就不启用该技能在技能里明确写如果没有执行权限立即停止并告知用户不得跳过验证步骤定期复盘对话日志专门看那些流程看似完整但产出质量可疑的会话工具权限这件事收太紧会诱导模型走捷径放太松又会引入不可控风险。我现在的策略是按技能的最小权限集配置同时在技能里加权限不足时必须显式反馈的指令让静默失败变成显式报错。5.3 技能文件里的过时命令会带来放大效应这个坑我印象最深。技能文件是几个月前写的里面记录的构建命令还是gradle build那套老脚本。后来项目CI已经切换成了新版构建流程技能里的命令没有及时更新。问题在于模型对技能文件里的内容信任度极高它不但会执行这个过时命令还会在命令失败后尝试各种补救——而补救的方向也被过时命令误导了。排查日志时那个画面让我挺受触动模型一遍遍在错误的构建命令上打转每次失败都尝试不同的环境变量就是不质疑这条命令本身是不是该被抛弃了。模型的坚持反而变成了故障放大器。从那之后我给自己的技能文件定了一条规矩凡是记录命令、脚本路径、依赖版本的文件必须标注最后验证日期。超过一个月就要组织一次全量复测重点确认命令是否仍然有效。这条看起来是个笨功夫但恰恰是这类工具最需要维护的环节。技能比普通文档更容易被执行所以它里面一旦有错误造成的后果也比普通文档大得多。5.4 上下文过长时的技能自选失灵最后说一个偏边缘但真实存在的坑。当我给一个项目配置了一堆技能文件后每次任务开始时模型要扫描全部技能清单。技能数量一多描述文本又长模型有可能在加载时挑花了眼选了一个相似但不合适的技能。有一次我要它处理一个前端样式调整任务它却加载了后端API开发技能然后一本正经地试图给样式问题设计接口。这个问题的根源不在技能质量而在技能检索的准确率。我的缓解办法是控制单个技能描述文件里when_to_use的表述让它更贴近真实的用户话语。比如把当用户要求修改界面样式时改成当用户提到按钮颜色、布局间距、组件样式等具体视觉问题时。描述越贴近真实口语匹配成功率越高。另外也在技能根目录建了一个INDEX文件让模型先在索引里判断当前任务匹配哪个技能而不是直接遍历全部技能内容。6. 让superpowers真正长在团队工作流里6.1 从个人技能库到团队共享技能库如果superpowers只服务于一个人那它能发挥的效能还有限。真正的价值是在多人协作时技能可以作为团队经验的公共资产流动起来。我们团队目前的做法是这样的技能仓库单独建了一个Git仓库命名规则是superpowers-skills-团队名每位成员都可以提Merge Request但合并前必须经过技能评审评审重点不是代码风格而是技能里的流程是否准确、步骤是否可执行、红线是否合理评审通过后大家拉取最新版本即可使用这个模式跑了一段时间后效果非常务实。以前新人加入项目光是把项目怎么构建、代码怎么写、测试怎么跑讲清楚就得花上小半天。现在直接让他们把技能库clone下来再通过自然语言发起一次项目熟悉任务新人在助手引导下能快速跑通整个链路。技能库把隐性知识做成了显性资产而且这个资产能随着项目演进持续更新。6.2 把技能的评审当成代码评审来做技能评审一开始我们是很随意的谁提了谁就自己合。后来发现质量参差不齐有的技能写得太泛约等于没有有的技能写得过于具体只适用于某一个人的习惯别人用了反而别扭。后来我们定了一套极简的评审标准只有三条技能是否有明确的适用边界写清楚何时用、何时不用比写清楚每一步做什么更难。步骤是否可以被一个没有项目背景的人照着执行如果哪一步需要隐性的项目知识必须在技能里显式补充。是否包含验证机制任何技能都必须有如何确认自己干对了的一步否则这个技能就不完整。这三条标准一开始看着很基础实际评审起来能筛掉八成不合格的技能。如果让我给正准备上手的团队一个建议我会这样说不要在文档里讨论superpowers能不能用先让几个人各自用一个最小技能去解决自己最无聊的重复任务跑一周后把心得体会拉齐你就知道这个工具的边界在哪里了。它不会替你解决所有问题但它能把你稳定的、正确的工作方式固化下来让AI助手的每一次发挥都至少达到你自己的平均水平。

Superpowers：为AI编码助手固化工作流与项目经验

相关推荐

Linux内核函数地址替换：零开销Hook的原理与实战

RecyclerView拖拽排序实战：从原理到四大故障根因

模型转折效果强化：法线编辑、曲率贴图、AO与边缘光全攻略

更多资讯

NumPy eye() vs identity()：One-hot编码的工程本质与避坑指南

产线“最后一米”的破局密码：ESOP与MES的区别与深度协同

别再只问“AI写作软件哪个第一”了：智能影像工程毕设的工具组合攻略 [特殊字符]

Unity无限跑酷项目源码实战：从玩法框架到移动端产品落地

Vue3拖拽范围失控？从边界计算到修复方案全解析

2026 AI 论文辅助工具综合测评排行榜｜多维度实测盘点

今日更新

NetSpot 实战：用信道分析与频宽优化解决 Wi-Fi 卡顿

C++ split() 字符串分割的五种实现与性能实测

R语言坐标轴范围设置：从xlim/ylim到coord_cartesian的完整指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？