最初看到「Superpower」这个名字我本能地以为是又一款对标 GPT 的大模型产品。结果用了一周才发现它确实不是最「聪明」的那类模型真正有意思的是这个开源项目在做一件更稀缺的事——把资深工程师的“肌肉记忆”变成模型可执行的习惯流程。它不负责回答正确它负责让模型不跳过该做的检查、不省略失败的步骤、不在改代码前脑补出结果。如果你也经常被 AI 编程助手气到让它修 bug它直接改代码不跑测试让它加功能它一顿输出但根本没看项目上下文换一个新对话上一轮约定过的规范又全忘记。那 Superpower 这类「技能化流程」的思路可能比追求更大参数更新的模型更值得你先了解一下。1. 它不是模型而是一套让流程“长”在模型身上的开源方案1.1 拆掉“AI 新模型”的预期它其实是个技能仓库我第一次看 README 的时候也困惑了很久因为仓库里没有模型权重也不是推理服务里面是一堆按目录组织好的 Markdown 文件外加一些让 agent 能够加载它们的脚本和约定。简单说Superpower 是一套面向编码代理coding agent的开源「技能」集合。用最直白的话解释普通大模型是一张特别聪明的白纸。你给它一个指令它会根据见过的代码生成很像样的回答。但白纸没有习惯没有条件反射。资深工程师看到测试红了会先看是哪个用例挂、为什么挂、是功能改动还是测试原本就脆弱普通模型则会默认“一定是我的代码逻辑有问题”然后开始大改。这不是“聪明程度”能解决的问题而是缺少经过无数次 trial and error 沉淀下来的工作习惯。Superpower 做的就是把这些工作习惯打包成标准文件。放到 agent 的技能目录后模型会在合适的时候被触发、读取、然后按照文件里的工序走。这个开源项目不追求每次回答都惊艳它追求的是让模型像一个在该行业干过五到十年的工程师那样不慌、不跳步、先复现、再定位、改完必须验证。我后来慢慢理解这套东西的定位不是“更聪明的模型”而是“让模型少犯过程性错误”的框架层。它管的是模型背后的工程纪律而不是模型本身的上限。1.2 为什么“最聪明”不是工程场景的唯一答案如今开源模型社区里大家拼命卷推理能力、基准分数、上下文长度。但到了真实项目里我发现问题的卡点往往不在这里。模型能给出正确答案但它不会主动执行“先写失败用例再实现”的流程。它可以读懂项目结构但它不会像老手一样在改代码前先打开相关文件确认现状。它会用很长的一段代码修复一个其实只需要三行改动的小 bug因为它从来没有形成一个“先做最小改动”的肌肉记忆。这里有个容易混淆的地方大模型不是没有这个能力而是默认情况下它没有一个“做事的顺序约束”。你在 prompt 里写“请按 TDD 流程来”可能有效但每次都要写而且一旦任务复杂它会逐渐遗忘这个约束最后又回到“直接生成代码”的老路。Superpower 这类项目把约束从“用户每次提醒”变成了“模型触发场景时的前置条件”这个过程很像人类形成肌肉记忆——不需要每次重新思考只要进入某个场景动作自己就发生了。我自己实测下来的体会是当你反复依赖一个非常聪明但毫无流程纪律的模型短期看它可能写得飞快可一旦项目超过几百个文件、测试套件有了几十个用例时它犯的“过程性错误”远比“答案错误”更致命。一个步骤顺序错了后面所有修复都是在错误前提上打补丁。这也是我认为开源技能项目会被越来越多团队重视的根本原因。2. 一探核心肌肉记忆在代码仓库里到底长什么样2.1 每个 Skill 都是一份“标准作业流程说明”打开 Superpower 的技能目录典型的目录结构类似这样skills/ systematic-debugging/ SKILL.md references/ 二分定位法.md test-driven-development/ SKILL.md writing-plans/ SKILL.md真正的渲染和加载方式会随你使用的 agent 不同稍有差异但主文件基本都是SKILL.md。它的开头是一段 YAML 格式的元信息负责告诉模型“我什么时候可以用”后面是正文负责告诉模型“被触发后你该怎么一步步做”。一个简化后的示例大概是--- name: systematic-debugging description: 当出现测试失败、运行时错误或行为不符合预期时使用。尽量不要在没有复现问题的情况下直接修改代码。 when_to_use: - 测试变红 - 用户反馈异常 - 行为与预期不符 --- # 系统化调试流程 ## 第一步复现 1. 先运行相关测试或最小样例确认错误稳定复现。 2. 记录完整报错信息不截断不脑补原因。 ## 第二步定位 1. 通过注释掉最近改动或二分法缩小范围。 2. 找到失败的最小原因而不是在多个可疑点同时修改。 ## 第三步修复 1. 做最小修复。 2. 加一个能防止回归的测试。 ## 第四步验证 1. 运行全量相关测试。 2. 如果无法验证明确告知用户不要声称“应该可以了”。看明白了吗这些内容本身不深奥任何一个中级工程师都能写出来。真正的价值在于它把“习惯”变成了一个可以被模型加载、被团队 review、被版本管理的文件。当你不再需要每次在 prompt 里反复叮嘱模型“记得跑测试”的时候这些流程才算真正沉淀下来了。2.2 这不是知识库而是触发条件加上执行序列我见过很多团队做类似的事方向却跑偏了。他们喜欢给模型塞一堆架构文档、技术设计、代码规范指望模型看过之后就能变成资深工程师。但这些内容大部分只是“知识”不是“肌肉记忆”。知识的意思是当你问它的时候它能回答。肌肉记忆的意思是在合适的情境下它不用你问自己就会执行。这两者之间有本质区别。给模型一份长长的《代码规范》文档它只会把文档当成参考资料不会在每次提交代码前自动检查是否遵守。但如果你给它的一个技能文件里写着“提交前必须运行 lint并且逐行检查 diff”再配合 agent 工具本身具有的命令执行能力那它就会做到。这也是 Superpower 的聪明之处它不是在知识的密度上和模型比而是在“情境触发的动作链条”上做设计。一个技能文件里最值钱的部分往往不是那几句宏观目标而是它内嵌的执行序列什么时候触发第一步先看什么什么情况下停下来问人什么时候必须验证验证不了时的边界是什么这些流程似乎很细碎但把它们拆开后组合起来就是一个人看起来“专业”的来源。2.3 更接近“人”的任务编排而不是函数式调用的拼接使用 Superpower 一段时间后我还有一个很明显的感觉它不是单个技能而是一整套相互串联的工作流。从需求 brainstorming 到输出实现计划到用 TDD 写代码再到有人 review 时重新检查一遍每个阶段有对应的技能文件。模型会自动根据当前情境选择合适的技能而技能之间又可以按顺序接力。这比我们过去常用的“系统 prompt 一次性指令”更像一个真实的工程师。工程师不会在做需求澄清的时候直接写代码也不会在测试失败时先说“我来重写这个模块”。他会先判断当前处于哪个阶段然后调用那一套对应的经验。Superpower 用文件的形式把这种“任务状态机”建模了出来模型就能根据上下文一步一步走而不是试图从用户的一句话里猜出整个工程过程。3. 亲手装一次如何让模型获得这套“手癖”3.1 准备阶段先确认你的 agent 支持哪类 SkillsSuperpower 不是某个大模型专用插件它已经适配了不少支持「技能」机制的 coding agent比如常见的 Claude Code、opencode 这类开源终端工具。它们的加载方式都有差异但底层逻辑一致在某个特定目录里放技能文件夹agent 运行时扫描这些技能根据场景把合适的技能注入上下文。我不建议大家死记硬背任何一条安装命令因为这类项目升级速度很快目录路径几天一变都很正常。你应该先搞清楚自己用的 agent 把技能放在哪里再去仓库里看官方 README 给出的安装说明。如果一定要说一个通用步骤大概是这样的用git clone把开源项目拉到本地。找到项目里的skills/目录。把需要的技能子目录复制或软链到 agent 的技能目录例如.claude/skills/下。重启 agent打开一个新对话让它列出当前可用的 skills确认加载成功。用一个小任务测试故意制造一个错误场景看模型是否会主动触发调试技能。这里特别提醒一句很多人安装时图省事把整个仓库直接复制到系统目录里。结果技能目录里混入了 README、示例、插件源码agent 扫描时会出现识别混乱。尽量只复制真正的技能文件夹不要连带仓库其他文件一起塞进去。3.2 自己动手写一个最简单的技能如果你不想一开始就依赖整个项目完全可以照着这个思路做最小验证。我先在.claude/skills/下建了一个叫commit-check的技能里面只有两个文件commit-check/ SKILL.mdSKILL.md的内容很简短--- name: commit-check description: 在生成 git commit 消息之前检查 diff确认没有调试日志、临时代码和无关改动。 --- ## 必做动作 1. 运行 git diff 查看全部改动。 2. 搜索 console.log / print / debugger 等调试语句。 3. 删除临时代码但必须是明确属于本次调试引入的删除不了的先告诉用户。 4. 保持 diff 最小化。 5. 最后写 commit message。我把这个技能放到 op 目录后模型在每次提交前都会自动走一遍流程。看起来原理非常简单但它的确解决了我之前一直被反复打扰的问题每次都要在 prompt 里苦口婆心地说“检查有没有调试日志”。而当我把它写成技能文件之后同样的事变成了模型主动的意识。3.3 本地模型、开源模型也能用吗能但要降低预期。Superpower 的流程设计并不依赖某个特定厂商的旗舰模型理论上只要是支持工具调用和技能注入的开源模型都能跑。不过模型本身的指令跟随能力越弱它就越容易被技能文件里的长文本带偏或者只学了个表面它可能在第一步复制了报错信息但第二步没做任何信息提取就跳到了写修复代码。我的建议是如果你在 opencode 这类环境里接入的是一个量化过的本地小模型技能文件不要贪多一个场景一份一份里只保留五到七个关键步骤每一步都有明确的动作动词。不要写“深入分析问题”这种废话要写“打开报错涉及的源文件精读相关函数后列出候选原因”。小模型对动作词更敏感对抽象描述则经常一带而过。这背后也回答了热搜里经常出现的“开源免费模型到底行不行”的疑问模型能力决定它能否听懂指令而技能框架决定它是否愿意按步骤走。两者是乘法关系不是替代关系。当模型本身能力有限时一个好的开源技能流程能帮它少走弯路但也不要指望技能能把一个 7B 模型变成资深架构师。4. 组合拳Superpower、OpenSpec 与 opencode 一起用4.1 OpenSpec 定义“做什么”Superpower 定义“怎么做”社区里越来越多人在讨论把 OpenSpec 和 Superpower 搭配起来使用。OpenSpec 的思路是“规格先行”在写代码前先把需求边界、改动范围、验收条件用文档描述清楚让 agent 在一个明确的目标下工作。Superpower 的思路则是“流程先行”目标明确后模型该怎样组织自己的工作步骤才不会胡子眉毛一把抓。两者放一起看非常顺畅。OpenSpec 解决的是“做对的事”Superpower 解决的是“把事做对”。没有 OpenSpecSuperpower 可能让模型非常规范地去实现一个根本不该实现的需求没有 SuperpowerOpenSpec 写出来的规格最后也可能被模型用不规范的过程实现出来留下大量技术债。我实际使用的一个典型流程是这样的先用 OpenSpec 创建一个 change proposal把当前项目的行为现状、目标行为、涉及模块写清楚。再让 agent 使用 Superpower 里的计划技能把 proposal 拆成可执行的里程碑。每个里程碑里要求 agent 遵循测试驱动的技能循环。最后在提交之前用 review 类技能检查所有改动是否和 OpenSpec 里的验收条件对得上。这一套组合下来模型的行为就从“接到一句话就生成代码”变成了“先确认规格再制定计划然后小步实现最后对照验收”。哪怕中间使用的只是一个中等规模的开源模型最终交付的代码稳定性和可维护性都会比没有这套流程时高一个台阶。4.2 在 opencode 里接入 Superpower 的实际场景opencode 这类开源的 agent 终端往往允许你把技能目录直接加载进来模型会在需要的时候把对应技能文件作为上下文读取。相比闭源产品它更适合做这类实验因为你完全可以控制技能的加载路径和 prompt 组成方式。我自己的接入方式是在项目根目录放一份小的AGENTS.md或等效的说明文件里面提前写好规则——“如果需要修改功能先查阅 openspec 目录下的相关规格如果测试出现失败调用 systematic-debugging 技能。”这样 agent 的工具调度层就能在遇到事件时优先检索技能而不是张口就答。还有一个很容易被人忽略的细节接入外部模型时不要把所有技能都一股脑加进系统上下文。不同工具对技能加载的实现不一样有些是全量注入有些是按 description 相似度触发。如果是全量注入技能文件一多会白白占用大量 token。建议只保留当前项目最常用的五个技能其他技能放到按需加载的目录里。4.3 一套可以直接抄的落地顺序综合上面的内容我整理出了一个比较稳健的落地流程初始化 OpenSpec 目录为当前迭代写一个最小规格。打开 agent让它先读规格文件不要直接开始写代码。调用 planning 技能生成任务清单每项任务要能对应到规格里的某条行为变化。每个任务开始前检查有没有匹配的测试没有测试就先写失败用例。实现完成后运行测试并修正直到全绿。全绿后不急着提交先走 code review 技能检查 diff 是否最小化、有无脏调试代码。提交信息里关联到 OpenSpec 的 proposal 编号。这几步看起来像传统软件工程里的开发流程但区别在于以往这些步骤靠人来盯现在靠技能文件注入到模型行为里。你可以把这一整套流程提交到代码仓库里任何人都能复现而不是只存在某个资深工程师的脑子里。在我看来这才是它被称为“开源”的真正含义经验可以共享、review、演进而不是靠悟性。5. 踩坑记录为什么有人装上 Superpower 后觉得没用5.1 模型拿到了技能但总是不按顺序做这是最最常见的问题。很多人装好技能后发现模型遇到测试失败并没有先复现还是立刻改代码。原因往往不是模型不听话而是技能文件的触发条件写得太宽泛或者正文里让模型“自由发挥”的空间太大。解决办法是在 description 里明确场景在正文里用“必须”“禁止”“如果没有验证不允许声称修复成功”这类硬性表达。技能不是论文不需要留余地。它的目的是约束行为所以语气越明确越好。你也可以让模型在开始执行时先复述一遍计划这样能明显提高它对流程的遵循程度。5.2 技能目录太庞大上下文被快速耗尽如果你把整个开源仓库的几十个技能都塞进 agent会发现模型有时候会读一堆无关内容可用上下文反而变小。大部分 agent 是依据技能描述做匹配的描述写得太泛模型就可能同时加载多个不相关技能。我踩过这个坑之后改变了策略一个项目只保留一套最小技能集比如调试、TDD、提交检查。其他技能放到另一个目录需要哪个再加哪个。技能文件是给人用的不是给项目增加装饰的装的越多不一定越强反而会让模型陷入“选择困难”。5.3 技能告诉模型要跑测试但工具权限没打通有些 agent 默认没有开启执行命令的权限。模型看了技能文件知道该跑测试但执行不了于是它可能直接假装跑过了或者在回答里写“你应该运行 npm test”。这不是技能的问题而是权限配置的问题。解决方式简单粗暴在 agent 配置里把测试、lint、类型检查等安全命令加入允许执行列表并把“无法执行的验证步骤必须明确告知用户不能假设通过”写进系统 prompt。否则技能写得再严格也没有办法落地。5.4 自己写的技能和项目自带规则冲突技能文件不是唯一的指令来源。有些项目本身有AGENTS.md、CLAUDE.md这类项目级规则文件。如果项目规则和技能内容冲突模型很难判断谁优先。比如项目规则要求“提交前自动格式化整个项目”但某个技能要求“只保留最小 diff”两者就会有张力。建议在 README 或项目规则文件里显式声明优先级。我的习惯是项目级规则高于通用技能但如果技能是针对具体场景的更强的约束则技能优先。这个优先级别靠模型自己悟要写清楚。你可以做一个简单的问答当两个指令冲突时默认以哪个为准提前定好后面能省很多沟通成本。现象可能原因排查方向模型触发技能后只读文件不执行工具权限未打开检查 agent 的命令执行白名单技能能触发但不遵守顺序正文指令约束不足改为动作导向的短句和强制步骤上下文很快变长且答非所问技能被全量加载精简技能目录或改用按需加载机制多个技能同时被唤醒description 写得太泛每个技能只覆盖一类明确场景自己加的技能没生效目录结构或文件名错误确认是否为 SKILL.md 且位于正确路径6. 比“技能”更重要的是工程师经验的可复制在深入使用一段时间后我看待 Superpower 的视角已经变了。它确实不是一个多聪明的人工智能产品不会用华丽的推理能力震住你。但我认为这个开源项目最有价值的点是它证明了“工程师的肌肉记忆可以被当成代码一样管理”。以前我们带新人的时候总说“你要多积累经验慢慢就会形成感觉”。这种经验传递非常低效因为大量关键流程只存在于资深工程师的脑子里。Superpower 换了一种方式它鼓励你把“测试红了该怎么做”“需求不清晰时该先问什么”“提交前该检查什么”这样的流程显式写下来。这些流程从来不是秘密但它们从来没有被当成一等公民对待过。我也建议你不要一次性全盘照搬这个项目里的所有技能而是先挑两三个最常踩坑的场景用它的格式写下来。写的过程中你会发现自己对工作方式有了更清晰的认识。哪怕最后你并没有把所有技能都接入这个过程本身就已经有了价值你开始把习惯当资产管理而不是靠运气传承。根据我个人经验最适合用它的人是那些已经对 AI 编程助手又爱又恨的工程师。你已经知道它聪明但你更需要它靠谱。Superpower 这类开源项目不会让模型一夜之间变成最强的技术专家它能让模型变得更像团队里那个“虽然话不多但交给他收尾一定很稳”的同事。仅这一点就值得你花一晚上试试。
Superpower：把资深工程师的肌肉记忆变成AI编码助手的工作流程
最初看到「Superpower」这个名字我本能地以为是又一款对标 GPT 的大模型产品。结果用了一周才发现它确实不是最「聪明」的那类模型真正有意思的是这个开源项目在做一件更稀缺的事——把资深工程师的“肌肉记忆”变成模型可执行的习惯流程。它不负责回答正确它负责让模型不跳过该做的检查、不省略失败的步骤、不在改代码前脑补出结果。如果你也经常被 AI 编程助手气到让它修 bug它直接改代码不跑测试让它加功能它一顿输出但根本没看项目上下文换一个新对话上一轮约定过的规范又全忘记。那 Superpower 这类「技能化流程」的思路可能比追求更大参数更新的模型更值得你先了解一下。1. 它不是模型而是一套让流程“长”在模型身上的开源方案1.1 拆掉“AI 新模型”的预期它其实是个技能仓库我第一次看 README 的时候也困惑了很久因为仓库里没有模型权重也不是推理服务里面是一堆按目录组织好的 Markdown 文件外加一些让 agent 能够加载它们的脚本和约定。简单说Superpower 是一套面向编码代理coding agent的开源「技能」集合。用最直白的话解释普通大模型是一张特别聪明的白纸。你给它一个指令它会根据见过的代码生成很像样的回答。但白纸没有习惯没有条件反射。资深工程师看到测试红了会先看是哪个用例挂、为什么挂、是功能改动还是测试原本就脆弱普通模型则会默认“一定是我的代码逻辑有问题”然后开始大改。这不是“聪明程度”能解决的问题而是缺少经过无数次 trial and error 沉淀下来的工作习惯。Superpower 做的就是把这些工作习惯打包成标准文件。放到 agent 的技能目录后模型会在合适的时候被触发、读取、然后按照文件里的工序走。这个开源项目不追求每次回答都惊艳它追求的是让模型像一个在该行业干过五到十年的工程师那样不慌、不跳步、先复现、再定位、改完必须验证。我后来慢慢理解这套东西的定位不是“更聪明的模型”而是“让模型少犯过程性错误”的框架层。它管的是模型背后的工程纪律而不是模型本身的上限。1.2 为什么“最聪明”不是工程场景的唯一答案如今开源模型社区里大家拼命卷推理能力、基准分数、上下文长度。但到了真实项目里我发现问题的卡点往往不在这里。模型能给出正确答案但它不会主动执行“先写失败用例再实现”的流程。它可以读懂项目结构但它不会像老手一样在改代码前先打开相关文件确认现状。它会用很长的一段代码修复一个其实只需要三行改动的小 bug因为它从来没有形成一个“先做最小改动”的肌肉记忆。这里有个容易混淆的地方大模型不是没有这个能力而是默认情况下它没有一个“做事的顺序约束”。你在 prompt 里写“请按 TDD 流程来”可能有效但每次都要写而且一旦任务复杂它会逐渐遗忘这个约束最后又回到“直接生成代码”的老路。Superpower 这类项目把约束从“用户每次提醒”变成了“模型触发场景时的前置条件”这个过程很像人类形成肌肉记忆——不需要每次重新思考只要进入某个场景动作自己就发生了。我自己实测下来的体会是当你反复依赖一个非常聪明但毫无流程纪律的模型短期看它可能写得飞快可一旦项目超过几百个文件、测试套件有了几十个用例时它犯的“过程性错误”远比“答案错误”更致命。一个步骤顺序错了后面所有修复都是在错误前提上打补丁。这也是我认为开源技能项目会被越来越多团队重视的根本原因。2. 一探核心肌肉记忆在代码仓库里到底长什么样2.1 每个 Skill 都是一份“标准作业流程说明”打开 Superpower 的技能目录典型的目录结构类似这样skills/ systematic-debugging/ SKILL.md references/ 二分定位法.md test-driven-development/ SKILL.md writing-plans/ SKILL.md真正的渲染和加载方式会随你使用的 agent 不同稍有差异但主文件基本都是SKILL.md。它的开头是一段 YAML 格式的元信息负责告诉模型“我什么时候可以用”后面是正文负责告诉模型“被触发后你该怎么一步步做”。一个简化后的示例大概是--- name: systematic-debugging description: 当出现测试失败、运行时错误或行为不符合预期时使用。尽量不要在没有复现问题的情况下直接修改代码。 when_to_use: - 测试变红 - 用户反馈异常 - 行为与预期不符 --- # 系统化调试流程 ## 第一步复现 1. 先运行相关测试或最小样例确认错误稳定复现。 2. 记录完整报错信息不截断不脑补原因。 ## 第二步定位 1. 通过注释掉最近改动或二分法缩小范围。 2. 找到失败的最小原因而不是在多个可疑点同时修改。 ## 第三步修复 1. 做最小修复。 2. 加一个能防止回归的测试。 ## 第四步验证 1. 运行全量相关测试。 2. 如果无法验证明确告知用户不要声称“应该可以了”。看明白了吗这些内容本身不深奥任何一个中级工程师都能写出来。真正的价值在于它把“习惯”变成了一个可以被模型加载、被团队 review、被版本管理的文件。当你不再需要每次在 prompt 里反复叮嘱模型“记得跑测试”的时候这些流程才算真正沉淀下来了。2.2 这不是知识库而是触发条件加上执行序列我见过很多团队做类似的事方向却跑偏了。他们喜欢给模型塞一堆架构文档、技术设计、代码规范指望模型看过之后就能变成资深工程师。但这些内容大部分只是“知识”不是“肌肉记忆”。知识的意思是当你问它的时候它能回答。肌肉记忆的意思是在合适的情境下它不用你问自己就会执行。这两者之间有本质区别。给模型一份长长的《代码规范》文档它只会把文档当成参考资料不会在每次提交代码前自动检查是否遵守。但如果你给它的一个技能文件里写着“提交前必须运行 lint并且逐行检查 diff”再配合 agent 工具本身具有的命令执行能力那它就会做到。这也是 Superpower 的聪明之处它不是在知识的密度上和模型比而是在“情境触发的动作链条”上做设计。一个技能文件里最值钱的部分往往不是那几句宏观目标而是它内嵌的执行序列什么时候触发第一步先看什么什么情况下停下来问人什么时候必须验证验证不了时的边界是什么这些流程似乎很细碎但把它们拆开后组合起来就是一个人看起来“专业”的来源。2.3 更接近“人”的任务编排而不是函数式调用的拼接使用 Superpower 一段时间后我还有一个很明显的感觉它不是单个技能而是一整套相互串联的工作流。从需求 brainstorming 到输出实现计划到用 TDD 写代码再到有人 review 时重新检查一遍每个阶段有对应的技能文件。模型会自动根据当前情境选择合适的技能而技能之间又可以按顺序接力。这比我们过去常用的“系统 prompt 一次性指令”更像一个真实的工程师。工程师不会在做需求澄清的时候直接写代码也不会在测试失败时先说“我来重写这个模块”。他会先判断当前处于哪个阶段然后调用那一套对应的经验。Superpower 用文件的形式把这种“任务状态机”建模了出来模型就能根据上下文一步一步走而不是试图从用户的一句话里猜出整个工程过程。3. 亲手装一次如何让模型获得这套“手癖”3.1 准备阶段先确认你的 agent 支持哪类 SkillsSuperpower 不是某个大模型专用插件它已经适配了不少支持「技能」机制的 coding agent比如常见的 Claude Code、opencode 这类开源终端工具。它们的加载方式都有差异但底层逻辑一致在某个特定目录里放技能文件夹agent 运行时扫描这些技能根据场景把合适的技能注入上下文。我不建议大家死记硬背任何一条安装命令因为这类项目升级速度很快目录路径几天一变都很正常。你应该先搞清楚自己用的 agent 把技能放在哪里再去仓库里看官方 README 给出的安装说明。如果一定要说一个通用步骤大概是这样的用git clone把开源项目拉到本地。找到项目里的skills/目录。把需要的技能子目录复制或软链到 agent 的技能目录例如.claude/skills/下。重启 agent打开一个新对话让它列出当前可用的 skills确认加载成功。用一个小任务测试故意制造一个错误场景看模型是否会主动触发调试技能。这里特别提醒一句很多人安装时图省事把整个仓库直接复制到系统目录里。结果技能目录里混入了 README、示例、插件源码agent 扫描时会出现识别混乱。尽量只复制真正的技能文件夹不要连带仓库其他文件一起塞进去。3.2 自己动手写一个最简单的技能如果你不想一开始就依赖整个项目完全可以照着这个思路做最小验证。我先在.claude/skills/下建了一个叫commit-check的技能里面只有两个文件commit-check/ SKILL.mdSKILL.md的内容很简短--- name: commit-check description: 在生成 git commit 消息之前检查 diff确认没有调试日志、临时代码和无关改动。 --- ## 必做动作 1. 运行 git diff 查看全部改动。 2. 搜索 console.log / print / debugger 等调试语句。 3. 删除临时代码但必须是明确属于本次调试引入的删除不了的先告诉用户。 4. 保持 diff 最小化。 5. 最后写 commit message。我把这个技能放到 op 目录后模型在每次提交前都会自动走一遍流程。看起来原理非常简单但它的确解决了我之前一直被反复打扰的问题每次都要在 prompt 里苦口婆心地说“检查有没有调试日志”。而当我把它写成技能文件之后同样的事变成了模型主动的意识。3.3 本地模型、开源模型也能用吗能但要降低预期。Superpower 的流程设计并不依赖某个特定厂商的旗舰模型理论上只要是支持工具调用和技能注入的开源模型都能跑。不过模型本身的指令跟随能力越弱它就越容易被技能文件里的长文本带偏或者只学了个表面它可能在第一步复制了报错信息但第二步没做任何信息提取就跳到了写修复代码。我的建议是如果你在 opencode 这类环境里接入的是一个量化过的本地小模型技能文件不要贪多一个场景一份一份里只保留五到七个关键步骤每一步都有明确的动作动词。不要写“深入分析问题”这种废话要写“打开报错涉及的源文件精读相关函数后列出候选原因”。小模型对动作词更敏感对抽象描述则经常一带而过。这背后也回答了热搜里经常出现的“开源免费模型到底行不行”的疑问模型能力决定它能否听懂指令而技能框架决定它是否愿意按步骤走。两者是乘法关系不是替代关系。当模型本身能力有限时一个好的开源技能流程能帮它少走弯路但也不要指望技能能把一个 7B 模型变成资深架构师。4. 组合拳Superpower、OpenSpec 与 opencode 一起用4.1 OpenSpec 定义“做什么”Superpower 定义“怎么做”社区里越来越多人在讨论把 OpenSpec 和 Superpower 搭配起来使用。OpenSpec 的思路是“规格先行”在写代码前先把需求边界、改动范围、验收条件用文档描述清楚让 agent 在一个明确的目标下工作。Superpower 的思路则是“流程先行”目标明确后模型该怎样组织自己的工作步骤才不会胡子眉毛一把抓。两者放一起看非常顺畅。OpenSpec 解决的是“做对的事”Superpower 解决的是“把事做对”。没有 OpenSpecSuperpower 可能让模型非常规范地去实现一个根本不该实现的需求没有 SuperpowerOpenSpec 写出来的规格最后也可能被模型用不规范的过程实现出来留下大量技术债。我实际使用的一个典型流程是这样的先用 OpenSpec 创建一个 change proposal把当前项目的行为现状、目标行为、涉及模块写清楚。再让 agent 使用 Superpower 里的计划技能把 proposal 拆成可执行的里程碑。每个里程碑里要求 agent 遵循测试驱动的技能循环。最后在提交之前用 review 类技能检查所有改动是否和 OpenSpec 里的验收条件对得上。这一套组合下来模型的行为就从“接到一句话就生成代码”变成了“先确认规格再制定计划然后小步实现最后对照验收”。哪怕中间使用的只是一个中等规模的开源模型最终交付的代码稳定性和可维护性都会比没有这套流程时高一个台阶。4.2 在 opencode 里接入 Superpower 的实际场景opencode 这类开源的 agent 终端往往允许你把技能目录直接加载进来模型会在需要的时候把对应技能文件作为上下文读取。相比闭源产品它更适合做这类实验因为你完全可以控制技能的加载路径和 prompt 组成方式。我自己的接入方式是在项目根目录放一份小的AGENTS.md或等效的说明文件里面提前写好规则——“如果需要修改功能先查阅 openspec 目录下的相关规格如果测试出现失败调用 systematic-debugging 技能。”这样 agent 的工具调度层就能在遇到事件时优先检索技能而不是张口就答。还有一个很容易被人忽略的细节接入外部模型时不要把所有技能都一股脑加进系统上下文。不同工具对技能加载的实现不一样有些是全量注入有些是按 description 相似度触发。如果是全量注入技能文件一多会白白占用大量 token。建议只保留当前项目最常用的五个技能其他技能放到按需加载的目录里。4.3 一套可以直接抄的落地顺序综合上面的内容我整理出了一个比较稳健的落地流程初始化 OpenSpec 目录为当前迭代写一个最小规格。打开 agent让它先读规格文件不要直接开始写代码。调用 planning 技能生成任务清单每项任务要能对应到规格里的某条行为变化。每个任务开始前检查有没有匹配的测试没有测试就先写失败用例。实现完成后运行测试并修正直到全绿。全绿后不急着提交先走 code review 技能检查 diff 是否最小化、有无脏调试代码。提交信息里关联到 OpenSpec 的 proposal 编号。这几步看起来像传统软件工程里的开发流程但区别在于以往这些步骤靠人来盯现在靠技能文件注入到模型行为里。你可以把这一整套流程提交到代码仓库里任何人都能复现而不是只存在某个资深工程师的脑子里。在我看来这才是它被称为“开源”的真正含义经验可以共享、review、演进而不是靠悟性。5. 踩坑记录为什么有人装上 Superpower 后觉得没用5.1 模型拿到了技能但总是不按顺序做这是最最常见的问题。很多人装好技能后发现模型遇到测试失败并没有先复现还是立刻改代码。原因往往不是模型不听话而是技能文件的触发条件写得太宽泛或者正文里让模型“自由发挥”的空间太大。解决办法是在 description 里明确场景在正文里用“必须”“禁止”“如果没有验证不允许声称修复成功”这类硬性表达。技能不是论文不需要留余地。它的目的是约束行为所以语气越明确越好。你也可以让模型在开始执行时先复述一遍计划这样能明显提高它对流程的遵循程度。5.2 技能目录太庞大上下文被快速耗尽如果你把整个开源仓库的几十个技能都塞进 agent会发现模型有时候会读一堆无关内容可用上下文反而变小。大部分 agent 是依据技能描述做匹配的描述写得太泛模型就可能同时加载多个不相关技能。我踩过这个坑之后改变了策略一个项目只保留一套最小技能集比如调试、TDD、提交检查。其他技能放到另一个目录需要哪个再加哪个。技能文件是给人用的不是给项目增加装饰的装的越多不一定越强反而会让模型陷入“选择困难”。5.3 技能告诉模型要跑测试但工具权限没打通有些 agent 默认没有开启执行命令的权限。模型看了技能文件知道该跑测试但执行不了于是它可能直接假装跑过了或者在回答里写“你应该运行 npm test”。这不是技能的问题而是权限配置的问题。解决方式简单粗暴在 agent 配置里把测试、lint、类型检查等安全命令加入允许执行列表并把“无法执行的验证步骤必须明确告知用户不能假设通过”写进系统 prompt。否则技能写得再严格也没有办法落地。5.4 自己写的技能和项目自带规则冲突技能文件不是唯一的指令来源。有些项目本身有AGENTS.md、CLAUDE.md这类项目级规则文件。如果项目规则和技能内容冲突模型很难判断谁优先。比如项目规则要求“提交前自动格式化整个项目”但某个技能要求“只保留最小 diff”两者就会有张力。建议在 README 或项目规则文件里显式声明优先级。我的习惯是项目级规则高于通用技能但如果技能是针对具体场景的更强的约束则技能优先。这个优先级别靠模型自己悟要写清楚。你可以做一个简单的问答当两个指令冲突时默认以哪个为准提前定好后面能省很多沟通成本。现象可能原因排查方向模型触发技能后只读文件不执行工具权限未打开检查 agent 的命令执行白名单技能能触发但不遵守顺序正文指令约束不足改为动作导向的短句和强制步骤上下文很快变长且答非所问技能被全量加载精简技能目录或改用按需加载机制多个技能同时被唤醒description 写得太泛每个技能只覆盖一类明确场景自己加的技能没生效目录结构或文件名错误确认是否为 SKILL.md 且位于正确路径6. 比“技能”更重要的是工程师经验的可复制在深入使用一段时间后我看待 Superpower 的视角已经变了。它确实不是一个多聪明的人工智能产品不会用华丽的推理能力震住你。但我认为这个开源项目最有价值的点是它证明了“工程师的肌肉记忆可以被当成代码一样管理”。以前我们带新人的时候总说“你要多积累经验慢慢就会形成感觉”。这种经验传递非常低效因为大量关键流程只存在于资深工程师的脑子里。Superpower 换了一种方式它鼓励你把“测试红了该怎么做”“需求不清晰时该先问什么”“提交前该检查什么”这样的流程显式写下来。这些流程从来不是秘密但它们从来没有被当成一等公民对待过。我也建议你不要一次性全盘照搬这个项目里的所有技能而是先挑两三个最常踩坑的场景用它的格式写下来。写的过程中你会发现自己对工作方式有了更清晰的认识。哪怕最后你并没有把所有技能都接入这个过程本身就已经有了价值你开始把习惯当资产管理而不是靠运气传承。根据我个人经验最适合用它的人是那些已经对 AI 编程助手又爱又恨的工程师。你已经知道它聪明但你更需要它靠谱。Superpower 这类开源项目不会让模型一夜之间变成最强的技术专家它能让模型变得更像团队里那个“虽然话不多但交给他收尾一定很稳”的同事。仅这一点就值得你花一晚上试试。
