superpowers技能包：把工程师经验变成AI编程的标准化工作流

说实话，第一次在 GitHub 上看到 superpowers 这个项目名的时候，我以为是某个人的中二收藏夹。真正用起来才发现，这玩意儿就是给 AI 编程助手装了一套外挂工作流。简单说，superpowers 是一组可复用的 Agent Skills，它把头脑风暴、任务规划、测试驱动开发、调试排障这些本来靠人经验才能做好的事情，固化成了模型能直接读取的操作手册。你不需要会写特别玄学的提示词，只要安装好它，然后在对话里把技能名字一甩，模型就会按一套成熟的方法论帮你把活干完。这篇文章会从 superpowers 是什么、有哪些 skills、怎么安装引入、实际跑通一个任务到常见坑位，全流程讲清楚。无论你是刚接触 AI 编程，还是已经被模型乱改代码折磨到崩溃，都能从这里找到能落地的办法。

我自己的使用场景主要是在日常项目开发里：接手一个老代码库、拆需求、写单元测试、排查线上问题、补技术文档。以前这些东西都得靠我一遍遍在对话里“喂”上下文，后来把 superpowers 装进技能目录之后，很多时候只需要一句话：“用 brainstorming 帮我想几个方案”，或者“用 debugging 技能帮我定位这个报错”。模型输出的质量直接上了一个台阶。这篇文章不会跟你拽术语，所有概念我都会用最直白的方式解释，并且把每一步操作都拆开给你看。

1. 先搞明白 superpowers 是什么：它解决的问题和设计逻辑

1.1 它不是新模型，而是一套“给 AI 的工作手册”

很多人第一次看到 superpowers 都会有个误解，觉得它是不是一个新的模型或者新的编程语言。真不是。它本质上是一堆用 Markdown 写成的技能说明文件，最常见的入口文件叫SKILL.md。这套文件遵循 Agent Skills 的组织规范，会被 AI 编程工具自动扫描、索引。当你在对话里提到某个技能名字，模型就会去读取对应的说明文件，然后按照文件里写好的流程来执行任务。

我习惯把它类比成给新员工发的一本《岗位操作手册》。新员工如果是空降的，你直接跟他说“把这个模块重构一下”，他多半会东一榔头西一棒子，最后给你搞出一堆意料之外的改动。但如果你先把手册拍在桌上，里面写清楚了“第一步先看调用链，第二步列风险清单，第三步小步重构，第四步跑全量测试”，他再笨也能按流程走出个七八分。superpowers 干的就是这件事：把人类工程师多年积累的做事方法，写成模型能看懂、能照做的标准化流程。

这个设计逻辑其实很妙。大模型本身的能力当然重要，但同样一个模型，给它一段清晰的流程指导和直接丢一句“帮我写代码”，结果差异极大。技能包的价值不在于让模型“变得更聪明”，而在于让它“更有章法”。我见过身边不少同事抱怨 AI 写代码不靠谱，一问才知道，他们的用法还停留在“给出需求、直接生成代码”的阶段，完全没有利用技能包这类东西去约束模型的思考路径。这就是输在起跑线上了。

1.2 为什么我不再用长篇提示词，而是改用技能包

在接触 superpowers 之前，我也算半个提示词工程师，每次让模型做事，都要在对话开头写一大段“你要扮演什么角色、注意什么事项、分几步完成、输出什么格式”。这种写法不是不行，但问题特别多：一是提示词越长，模型越容易在中间丢掉前面的指令；二是每次开新对话都要重新复制一遍，稍微改个字就前后不一致；三是这些个人风格极强的提示词根本没法在团队里共享。

技能包解决的就是这三个痛点。它把方法论和具体任务剥离开来：方法论固化在SKILL.md里，任务描述则放在你当下的对话里。模型会自动识别该用哪个技能，不再需要你每次重复“你要先分析、再计划、最后实施”这种废话。而且技能包只要通过 Git 管理，团队里所有人拉到同一个仓库，就拥有一模一样的工作标准。这点对团队协作特别重要，相当于把“老师傅的经验”变成了“团队的基础设施”。

不过这里也得泼一盆冷水：技能包不是装得越多越好。我刚开始用时，一口气装了十几个技能，结果模型每次都要先猜“用户到底想让我用哪个”，有时候反而把简单问题复杂化。正确思路是先用默认的最小集，把最常用的三五个技能跑顺，再逐渐加入新的。技能包解决的是“无序”问题，而不是“数量”问题，这一点一定要记住。

2. 拆解核心 skills：superpowers 里到底有哪些技能

2.1 高频使用的技能清单与适用场景

superpowers 的技能列表在不同版本里会有些差异，但核心的几个基本是稳定的。我把自己日常使用频率最高的几个整理成了表格，方便你对照自己的场景去选：

先说 brainstorming。这个技能最适合的场景就是需求特别模糊、你脑子里有好几种方向但拿不准的时候。它会要求模型先跟你确认背景信息，然后主动生成多个候选方案，而不是一上来就写代码。我最近做一个后台权限模块，就是靠它一次性输出了“RBAC、ABAC、简单角色继承、策略引擎”四套方案，每套还附了优缺点和落地成本。换在以前，我可能只会对着模型说“帮我设计个权限系统”，然后被它输出的第一版方案牵着鼻子走。

再说 planning。这个技能是我日常用的最多的。它会把“实现一个功能”拆成“环境分析、依赖梳理、任务列表、风险点、验证方式、回滚策略”等几个维度，让模型先输出一份完整的计划，再开始动手。TDD 技能就更硬核了，它要求模型先写失败的单测，再写最小实现，最后重构。我刚用的时候很不适应，总觉得这样太慢，但坚持两个星期以后，项目的回归 bug 明显变少了。debugging 技能则是排查问题时的救命稻草，它会引导模型不急着改代码，而是先要求你提供复现步骤、日志、代码上下文，然后按“假设 - 验证 - 定位”的循环去缩小范围。 code-review、documentation 这类技能属于“锦上添花”，但组合起来能给项目兜底。

2.2 技能组合起来的“超级工作流”

单独用一个技能只能解决一个环节的问题，但 superpowers 真正的威力在于把多个技能串成一条完整的流水线。我每次接新需求，默认的工作流是这样的：先用 brainstorming 把需求聊透，看看有没有被忽略的边界情况；接着用 planning 把确定下来的方案拆成任务清单；写代码阶段切到 TDD，让测试先定义“什么叫完成”；代码写完后用 code-review 挑毛病；最后用 documentation 把坑和用法写清楚。这一整套流程走下来，一个需求从模糊到交付，中间几乎不需要我自己操心步骤顺序。

这种组合方式背后的逻辑是让模型在合适的时间做合适的事情。比如大部分模型天生喜欢“跳过分析直接写代码”，如果你在 brainstorming 阶段让它写代码，它反倒写不好。技能包相当于给模型设了一道道闸门，逼着它先发散、再收敛、再执行、再验证。我经常跟朋友开玩笑说：“superpowers 的每一个技能都是一个小监工，专门盯着模型不要走捷径。”

刚开始尝试组合使用的时候，你可能会觉得“多此一举”，但这恰恰是最值得投入的地方。你可以从最简单的两个技能开始，比如 TDD + code-review，等熟悉了它们的语气和输出格式，再加 brainstorming + planning。慢慢你会发现，任何复杂的项目开发任务，都可以被拆解成一组固定的技能调用链。这个思路放到团队里，更是可以直接沉淀成一套内部的“交付标准流程”。

2.3 SKILL.md 的结构与自定义要素

如果你想真正理解并改造 superpowers，光会用是不够的，还得会看SKILL.md文件的结构。这种技能文件一般分为两大部分：最顶上的 YAML frontmatter，以及正文中的步骤描述。 frontmatter 里通常包含name、description、when_to_use、version这些字段，相当于技能的“身份证”。模型会通过description和when_to_use来判断当前对话要不要激活这个技能，所以这两段描述一定要写得清楚。我自己见过不少改坏技能包的情况，都是因为把description写得太笼统，模型根本不知道什么时候该用它。

下面是一个简化的SKILL.md示例，展示核心结构：

--- name: brainstorming description: 使用头脑风暴方法帮助用户发散需求，生成多个候选解决方案。 when_to_use: 当用户面临模糊需求、需要多种方案或难以决策时使用。 version: 1.0.0 --- # Brainstorming 技能 ## 目标 与用户合作生成尽可能多的候选方案，并最终收敛到可执行的方向。 ## 执行步骤 1. 询问或提取用户的背景、限制条件与目标。 2. 基于背景信息，先不评价优劣，生成至少 5 个候选方案。 3. 与用户一起对方案进行快速筛选，剔除明显不合适的选项。 4. 输出最终候选方案及优缺点对比。 ## 注意事项 - 不要在第一轮就下结论。 - 每个方案都要说明适用前提和成本。 - 如果用户信息不足，主动提问而不是替用户假设。

文件里正文的“执行步骤”是模型实际照做的操作流程，所以要写得具体、可执行。你在用 superpowers 的过程中，完全可以按照自己的习惯去改这些步骤。比如我不喜欢“至少 5 个方案”这种硬性数字，就会把它改成“依据问题复杂度生成 3 到 5 个方案”，让模型灵活处理。改完以后放到用户级技能目录里，就会覆盖掉项目里的同名技能。

但改的时候有一个大坑：frontmatter 的格式必须严格正确。三个横线不能少，字段名不能拼错，值不要加奇怪的引号。模型解析 YAML 的能力虽然不弱，但遇到格式错误时，经常不会报错，而是“假装看到”。表现就是技能不生效，或者生成的内容跟描述完全跑偏。遇到这种情况，不要怀疑模型，先回去检查你的SKILL.md头部的语法。

3. 安装 superpowers：从环境准备到首次调用

3.1 安装前置条件与目录规划

在动手安装之前，先确认三件事。第一，你的 AI 编程工具要支持 Agent Skills 这种技能机制，目前主流的大模型编程工具基本都已经支持，具体可以看工具文档里有没有skills目录的说明。第二，本机要装好 Git，能 clone 项目仓库，这个一般做开发的都有。第三，弄清楚技能目录的加载规则：项目级目录通常放在当前工程下的.claude/skills/（或者工具对应的隐藏目录），用户级目录则放在你本机的用户主目录下，比如~/.claude/skills/。两者优先级不一样，项目级会覆盖用户级，这点后面会细说。

我的建议是：不要一上来就装到用户级目录。先在你的一个真实项目里做一次项目级安装，验证熟悉了，再考虑用户级全局安装。为什么？因为项目级安装的风险面小，万一技能包有问题，最多影响当前一个项目，不会污染你所有的工作环境。而且项目级的技能包可以随着 Git 仓库提交给同事，方便团队统一使用。用户级安装更像“全局插件”，适合放那些你希望在任何项目里都能调用的通用技能，比如 brainstorming、planning 这类不依赖具体业务的技能。

还有一点容易被忽略：技能目录的命名。通常一个技能包就是一个文件夹，文件夹的名字会显示在技能索引里。如果你把一个叫“brainstorming”的技能文件夹误命名为“brainstorming-v2”，模型在索引时可能认不出来，因为技能名称和文件夹名称不一致的情况很容易出问题。所以安装时尽量保持仓库原有的目录结构，不要让技能文件夹多套一层无关的外壳。

3.2 实操安装步骤（用户级和项目级）

这里我直接把命令写给你，假设你已经把 superpowers 的仓库地址拿到了。在 GitHub 上搜索 superpowers，找描述里带 Agent Skills 字样的仓库，复制它的 Git 地址，然后执行下面的命令。

以项目级安装为例：

cd /path/to/your/project mkdir -p .claude/skills git clone <superpowers仓库地址> .claude/skills/superpowers

以用户级安装为例：

mkdir -p ~/.claude/skills git clone <superpowers仓库地址> ~/.claude/skills/superpowers

装完之后，最好看一眼目录结构，确保SKILL.md文件确实在superpowers文件夹下面。常见的一个错误是把仓库 clone 成了.claude/skills/superpowers/superpowers/SKILL.md，多套了一层目录，导致工具找不到技能。如果出现这种情况，把多余的一层目录剥掉就行了。

装好之后要重启你的 AI 编程工具，或者在工具里执行一个“刷新技能”之类的命令，让新加入的技能被重新扫描到。这一步特别容易忘，有些人装完技能包发现没效果，其实只是工具还停留在旧索引里。重启之后，你可以在对话里输入类似“列出所有可用技能”的指令，工具会把识别到的技能名字逐一列出来。看到 superpowers 下的几个技能出现在列表里，才算真正安装成功。

3.3 三种引入技能的方式，以及各自适合的场景

装好之后，怎么让模型真正用上这些技能？我总结了三种方式，你可以根据场景灵活切换。

第一种是在对话里用符号直接点名引用。比如输入“@brainstorming 帮我想一下登录模块除了账号密码还能怎么做”，模型会优先读取 brainstorming 技能，然后按里面的步骤来回答。这种方式最推荐，因为意图清晰，模型不用自己猜该不该用技能。适合在你有明确目标、且确定某个技能能帮到忙的时候。

第二种是把技能说明写到项目说明文件里，比如项目的README或工具会读取的CLAUDE.md中。你可以加一句“本项目支持使用 .claude/skills 目录下的技能，遇到需求分析请使用 brainstorming，遇到任务拆解请使用 planning”。这样即使你不手动点名，模型在合适的时机也会主动选用技能。适合那些你希望模型“自动形成习惯”的项目。

第三种是直接把SKILL.md的核心内容复制粘贴到对话里。这种方式最笨，但在工具不支持技能索引，或者你临时在网页端使用 AI 时很有用。相当于把技能包当成一个“提示词模板库”。虽然不优雅，但在受限制的环境下能救命。我一般出差不方便进入项目目录时，就用这种办法，从用户级技能包里把对应技能的步骤粘给网页版对话。

这三种方式不是互斥的。我的习惯是：常用技能用第一种手动点名，项目规范类技能用第二种自动激活，临时环境用第三种保底。你完全可以根据自己的工具和习惯去组合。

4. 实测记录：用 planning 技能完整跑通一个任务

4.1 一个真实小任务：给博客站加标签聚合页

光讲理论不过瘾，我拿前两天刚刚做完的一个真实任务来复盘。我有个基于静态站生成器搭的博客，文章里已经写了 tags 字段，但缺少一个把相同标签的文章聚合起来的列表页。这个功能不大不小，直接让模型写代码很容易翻车，所以我想试试用 superpowers 里的 planning 技能来控场。

我在项目目录下启动了 AI 编程工具，然后输入了这样一段话：“@planning 给博客增加一个标签聚合页，要求从所有 markdown 文章里提取 tags 字段，生成 /tags/ / 这样的静态页面，并在文章页显示相关文章列表。请先不要写代码，给出计划。”

注意，我在提示词里刻意加了“先不要写代码，给出计划”这个约束。因为 planning 技能的关键输出是计划，而不是最终代码。如果你不加约束，模型很容易把计划草草两句话带过，然后直接开始生成代码。加了约束后，模型会按照技能里的步骤去分析项目结构、依赖关系、输出清单。

4.2 调用技能前后的模型表现对比

没有技能的时候，我让模型做同样的任务，它的输出大概是这样：先一句“好的，我来帮你实现标签聚合页”，然后就直接列出要改的文件，开始写模板代码和生成逻辑。看起来很快，但你仔细一看就会发现，它完全忽略了一个关键问题：当前静态站生成器的版本是否支持动态集合？它也没有关心文章顺序、标签大小写、空标签这些边界情况。结果就是生成的代码大概率跑不通，或者跑到一半报错。

而用了 planning 技能之后，模型的输出结构变成了：先确认技术栈和项目目录结构，再列出“标签聚合数据从哪来、按什么格式输出、路由怎么生成、页面模板需要哪些变量、性能上有哪些隐患、如何验证结果”，最后才给出一份分步骤的实施计划。它还主动提出了一个我没考虑到的问题：标签页需要处理 URL 中的中文和空格，否则生成静态文件时会出乱码。这种细节，就是技能包带来的明显差异。

整个过程大概多花了几十秒，但省掉的是后面数小时的调试时间。用技能包最神奇的一点就是：它不会帮你省略思考，而是强迫模型先思考再行动。这和我们平时看老师傅带新人是一样的，重要的不是代码敲得多快，而是流程对不对。模型在流程对的情况下写出来的代码，反而比闷头一次性生成的代码要稳得多。

4.3 我调整过的一个关键细节

第一次使用 planning 技能的时候，我发现它对“任务拆分”这件事做得不错，但输出的计划偏向于“开发视角”，缺少“验证视角”。例如它列出了“生成标签页、修改模板、添加导航链接”，但没有明确写出“如何确认所有文章都被正确聚合”。后来我在SKILL.md的步骤里加了一条“每项任务必须包含验收标准”，整个计划的质量一下子又提上去了。

这个调整让我意识到，技能包不是一成不变的神器，它更像是一个可以持续打磨的流程框架。你觉得它哪里不够好，直接改对应的SKILL.md就行。我后来还把自己的一些编码规范也写进了 planning 技能的注意事项里，比如“所有路径必须使用相对路径”“静态资源要加哈希指纹”。这样模型在后续任务里都会默认遵守这些约定，相当于把我的个人规范变成了模型的肌肉记忆。

但在调整技能包的时候，有个线索一定要记住：改动只对后续对话生效，对当前正在进行中的对话不一定立刻生效。因为模型可能在对话开始时就已经缓存了技能内容。如果你改完技能后，当前对话里发现模型还在用老流程，别慌，新开一个对话再试就好。这个问题我踩过好几次，特意放在这里提醒你。

4.4 实测下来的效果和注意事项

最终我按照 planning 技能生成的计划，让模型分步实现了标签聚合页。整个过程比我预估的时间少了大概一半，而且代码基本没有返工。最爽的地方在于，每步完成之后模型都会回到计划里打勾，并给出验证命令。例如它会说“这一步已完成，执行npm run build然后检查 /tags/xxx 页面是否生成”。这时候你只需复制命令去终端跑一下，看到结果正常就继续下一步。这种“一步一步验收”的节奏，让人非常安心。

不过也有个注意事项：planning 技能生成的计划再完美，也要你自己做最后一道审核。它可能会因为你提供的背景信息不足而做出错误假设，比如把你的目录结构猜错。所以每次调用完技能，我会先扫一眼第一部分的“环境假设”是否正确。如果模型假设错了，我会直接在对话里纠正，再让它重新更新计划。这一步千万别省，模型不怕你纠正，怕的是你盲目相信它的第一个输出。

5. 常见问题与排查技巧实录

5.1 技能没生效，最先检查的三个位置

如果安装完 superpowers 之后发现模型完全不理技能，先别急着怀疑工具 bug，按顺序检查三个位置。

第一是目录结构。确认SKILL.md文件是不是正确地放在技能的根目录下，路径里不要有多余的层级。第二是文件头部格式。你可以打开SKILL.md看一眼，最顶部是不是三行横线和 YAML 字段，如果横线少了或者字段缩进有问题，模型就可能解析失败。第三是工具版本。Agent Skills 是新特性，版本太老的工具不支持，需要升级到最新版本。我遇到过最诡异的一次，是因为不小心把技能目录放在了.claude/而不是.claude/skills/下面，工具自然找不到。这类问题用“看目录、查头部、瞧版本”三步法，基本能覆盖 80% 的故障。

还有一个经常被忽略的检查点：技能目录的权限。如果你把技能文件夹放在一个有特殊权限限制的路径下面，工具进程可能没有读取权限。尤其在公司电脑上，用户主目录或项目目录可能被安全策略限制得死死的。这时你会看到技能列表里什么都没有，但也不会报错。解决办法就是确认技能目录对当前运行用户有读权限，或者干脆把技能复制到另一个可访问的位置。

5.2 模型总是不调用技能，怎么把它“点”醒

有时候技能装好了、目录也没错，但模型在对话里就是不主动用技能，尤其明明遇到“该 brainstorming 的问题”，它却直接开写。这种情况的原因多半是模型没有从你的话里识别出“该用技能了”。我的处理办法是：在提示词里直接点名，比如“请使用 brainstorming 技能，先发散一下方案”。这个“请使用 xx 技能”短语对模型来说是很强的指令信号，比单纯靠when_to_use描述去触发要可靠得多。

如果你希望模型以后都能在合适时机自动激活技能，而不是每次手动点名，可以在项目说明文件里加上一句类似“遇到模糊需求时，应该自动使用 brainstorming 技能；遇到任务拆解时，应该自动使用 planning 技能”。这一招本质上是把技能触发的判断条件前置成项目规范，让模型在每次对话开始时就带上这个上下文。我用了之后，自动调用技能的频率明显变高了。

还有一个小技巧：调用技能时，不要和模型聊太多无关话题。如果你先聊了一堆中午吃什么，再突然说“帮我写个批量重命名脚本”，模型有可能会把技能调用这件事冲到九霄云外。尽量在每条涉及任务的消息里都带上技能名，最简单也最可靠。

5.3 项目级与用户级技能冲突，到底谁说了算

前面提到项目级技能会覆盖用户级技能，但很多人对这个“覆盖”的理解有偏差。实际上，在我的实践里，同名冲突时项目级目录里的技能文件会优先被加载，用户级目录里的同名技能在项目内会被忽略。这个设计本来是为了满足不同项目使用不同技能版本的需求，但也带来一个坑：如果你在用户级改了一个技能，而项目里还留着一个旧版项目级技能，你就会奇怪为什么自己的修改“没生效”。

排查办法很直接：先看看当前项目目录.claude/skills/下有没有同名的技能文件夹。如果有，优先处理它。如果你希望用户级技能生效，可以把项目级那个同名技能文件夹删掉或改名。反过来，如果项目里确实想用定制版，建议把定制版提交到项目代码仓库里，让团队所有成员共享一套标准，而不是各改各的用户级版本。

我在本地维护用户级技能的时候，会把每个技能的原始版本和我的定制版分开文件夹放，比如superpowers-original和superpowers-custom，然后让工具只加载定制版。这样一来，仓库一更新，我还能对比一下官方又改了哪些步骤，再决定要不要把自己的定制同步过去。这个小习惯帮我省了很多次“莫名其妙技能行为变化”的排查时间。

5.4 技能包用着不顺手，自己改一个私有版本

superpowers 最大的魅力就是“代码都开源，随便改”。如果你对某个技能的执行步骤不满意，完全可以直接复制一份到用户级目录，改成自己的私有版本。比如我不太喜欢默认 brainstorming 技能里的“至少生成 5 个方案”这条规则，因为简单的需求根本不需要那么多方案，我就会把它改成“依据问题复杂度生成 3 到 5 个方案”。改完之后，项目级和用户级目录中同名技能会以用户级目录里的版本为准，所以不影响项目里默认版本。

改技能的时候我强烈建议用 Git 管理起来。先给私有技能目录初始化一个 Git 仓库，每次修改都提交一次，记录“为什么要这么改”。这样万一以后改乱了，还能回滚到上一个版本。用 Git 管理还有一个好处：你可以把私有技能仓库同步到团队内网，让团队其他人也能拉到同一套定制版技能。你的最佳实践就不再只是躺在对话记录里，而是变成了团队可复用的资产。

要格外注意的是，私有化改造不要动掉技能文件的name字段。这个字段是模型索引技能的唯一标识，你改了名字，就相当于创造了一个新技能，原来的触发词就不在了。最好只改正文步骤或description，保持技能名字稳定。我自己吃过一次亏，把name从brainstorming改成了my-brainstorming，结果在对话里喊@brainstorming半天没反应，排查了很久才发现是名字对不上。

5.5 问题速查表

为了方便收藏，我把上面提到的常见问题整理成一个速查表：

这张表我打印出来贴在了显示器边上，每次谁问我“为什么技能不生效”，我就让他先对着表自查一遍。别小看这些基础检查，绝大多数问题不是工具 bug，而是配置细节没到位。

6. 我的最后几条实操心得

折腾 superpowers 这几个月，我最深的体会是：工具再好，也得靠流程才能发挥价值。一开始我也走了弯路，把技能包装了一大堆，结果模型并不知道该先调哪个，输出反而比不用技能更乱。后来我狠心删到只剩六个核心技能，按“脑暴 - 规划 - 编码 - 审查 - 文档”的顺序组织起来，效率才真正上来。所以如果你刚接触，千万别贪多，挑两三个最贴合你工作流的技能先用，跑顺了再慢慢扩展。

还有一点经验是：每个技能至少单独试两次，再把它放进你的组合流程里。第一次试，是为了搞明白它的输出风格；第二次试，是为了验证它是不是稳定。如果两次结果都符合预期，再考虑把它加到组合链路中。我现在新增技能都遵循这个原则，避免一个不成熟的技能混进主线，导致整个工作流质量下降。

最后分享一个小技巧：把你自己的团队规范也写成技能包。superpowers 给了我一个灵感——既然通用的工程方法能做成技能，那团队特有的编码规范、发布检查清单、安全审查要点，为什么不也做成技能包呢？我现在已经把“项目发布检查清单”和“接口兼容性审查”这两条团队规范写成了私有技能，放在用户级目录里。每次让模型改代码之前，都会自动触发一遍相关检查，相当于给整个团队配了一个从不打瞌睡的流程检查员。这个玩法一旦跑起来，你会发现 superpowers 的价值已经远远超出了“下载一个技能包”本身，它变成了一套你专属的 AI 工作方法论。