模型聪明不聪明跟它干活稳不稳完全是两码事。最近我在折腾 AI 编码工具链的时候感触特别深GPT 级别的模型再强你给它一个模棱两可的需求它照样能一本正经地写出四不像的代码。真正拉开体验差距的不是模型本身的智商而是你有没有一套方法把“资深工程师怎么思考问题”这件事固化下来交给模型去执行。Superpower 这个开源项目切入的正是这个点。它不是一个“更聪明的模型”而是一套技能管理系统通过给 Claude Code、opencode 这类 AI 编程工具挂载结构化的“技能包”让模型在动手前先调用一整套资深工程师的工作流程。说白了就是把老师傅的肌肉记忆翻译成模型能读懂的指令和步骤。这篇文章我会把 Superpower 的定位、设计逻辑、安装配置方法以及和 OpenSpec、opencode 搭配使用的完整链路都拆开讲一遍。不管你是想驯服一个更听话的编程助手还是想把自己团队的工程规范沉淀成 AI 可执行的资产这篇都值得看完。1. 先说清楚Superpower 到底解决了什么问题1.1 模型聪明不等于干活靠谱真正的瓶颈是流程缺失如果你用过几周的 AI 编程助手应该会有这种感受问它某个函数怎么写、某个报错怎么解它反应很快答案也有模有样。但一旦让它“帮我完善这个模块”它就容易顾头不顾尾——改了一个文件忘了另一个调用方重构了接口没同步更新测试写着写着连自己之前定的代码风格都丢了。这不是模型变笨了而是它根本没有一个“稳定的工作状态”。这跟人一样一个刚入行的开发算法基础再好你不告诉他代码审查要看哪几个点、重构前要列哪些检查清单他也会凭着感觉乱来。资深工程师之所以稳定是因为他们在长期的工程实践里形成了流程化的判断习惯——也就是标题里说的“肌肉记忆”。Superpower 的出发点就是把这种流程化的判断习惯做成结构化的技能文件。它不试图提升模型的推理能力而是通过一套外部机制让模型在每次进入任务前先加载对应的技能按照预设的步骤、规范、决策树去执行。这样即使换了不同的底层模型输出的稳定性和工程质量也能保持在一个基准线上。1.2 Superpower 的定位技能控制系统而不是模型本身我第一次看到“Superpower”这个名字以为它又是一个号称“超越 GPT”的模型套壳。实际用下来才发现它的定位完全不在模型层而是在工具链的“指挥层”。从架构上看Superpower 做的事情其实很纯粹管理技能Skills、注入上下文、控制工作流。它像是给 AI 编程助手装了一个“前置大脑”在模型真正开始生成代码之前先完成需求解析、方案规划、步骤拆解这一系列动作。而且它的技能是模块化的你可以像搭积木一样按需加载“代码审查”“安全审计”“单元测试生成”这类专项技能。这种设计有个很现实的好处可解释、可控制、可迁移。模型是黑盒但技能文件是明文的。你完全能打开一个技能文件看到里面写的每一步是什么、为什么要这么做。团队内部想统一一套编码规范直接把规范写进技能里就行不用重新微调模型。换一个模型供应商技能文件照用不误。1.3 别搞混了Superpower、OpenSpec、opencode、claude code 到底是什么关系我在搜索资料的时候看到不少人在问“Superpower 和 OpenSpec 有什么区别”“opencode 怎么接入 Superpower”这说明工具链一多概念就容易打架。我理一下这几个东西的关系你后面实操就不会懵。Claude Code、opencode 这类是“干活的人”也就是 AI 编程助手本体负责调用模型、读写文件、执行命令。Superpower 是“给干活的人发标准作业指导书的管理员”它负责把技能库里合适的技能挑出来注入到助手的上下文里。而 OpenSpec 更偏上游它管的是“需求怎么拆解成规范”相当于项目启动前的规格说明书环节。OpenSpec 产生的规格文档可以作为 Superpower 技能执行时的输入材料两者是配合关系不是竞争关系。用一个生活化的类比OpenSpec 是建筑设计院的图纸规范Superpower 是工地上的施工工法库Claude Code 是施工队。图纸规范定方向工法库定动作标准施工队负责实际动手。三者链条完整才能盖出质量稳定的楼。2. 为什么“肌肉记忆”比“临场发挥”更值钱设计思路拆解2.1 资深工程师的隐性技能是怎么一步步变成显性技能的要说清楚 Superpower 的思路得先讨论一个本质问题资深工程师的经验为什么难以复制心理学里有个概念叫“知识诅咒”——你越熟练一件事就越难跟别人讲清楚这件事是怎么做到的。老工程师 review 代码时一眼看出数据库索引有问题你说不清自己是怎么看出来的反正就是觉得不对。这种连本人都不一定能完整表达的经验就是隐性技能。Superpower 做的事情是把隐性技能外化成显性技能。做法很朴素和不同领域的老工程师深聊把他们审查代码、设计接口、排查故障时脑子里实际上会过的那些步骤一条条挖出来写成结构化的流程文档再灌进技能文件里。比如“代码审查”技能普通人看到的是“检查一下代码质量”资深工程师脑子里其实是这么一条链路先看变更范围是否合理再检查错误处理路径是否完整然后看并发与事务边界、敏感信息泄露风险、日志打点是否足够最后才轮到代码风格和命名规范。这套链路就是肌肉记忆的可视化。模型本身不懂工程但你把这条链路以上下文的方式喂给它它就能像一个刚拿了“老师傅操作手册”的新人一样按图索骥步骤不乱。2.2 一个核心设计系统提示词之外的第二套上下文体系用过 AI 编程助手的人都知道系统提示词System Prompt是决定模型行为的关键。但系统提示词有个要命的问题它是一锤子买卖长度有限而且所有任务都共用同一套设定。你不可能在一个系统提示词里同时写好“代码审查规范”“前端开发规范”“数据库设计规范”“安全加固清单”真塞进去上下文窗口早就爆了模型也顾此失彼。Superpower 的思路是做个“第二套上下文体系”平时保持精简等任务类型确认之后再把对应的技能文档动态加载进来。这个设计让我眼前一亮它像极了操作系统的虚拟内存机制。系统提示词是常驻内核技能文件是按需调入的用户进程用完了还能换出避免上下文长期高负载。这既解决了上下文窗口的资源瓶颈也让每个技能的指令质量可以做得很深——反正是一次临时加载写详细点、写极端点都没关系不会污染其他任务的执行。2.3 这种设计能规避哪些工程实践中的坑这套按需加载的设计我实际用下来起码躲开了三个明显的坑。第一个坑是上下文污染。以前我也试过把所有规范都写在一个大 Prompt 里结果模型写前端的时候满脑子数据库事务写后端的时候又莫名在意 CSS 类名输出风格飘忽不定。Superpower 这样的隔离机制让每次任务面对的上下文都是“纯净”的模型不容易被无关信息干扰。第二个坑是指令漂移。语言模型对 Prompt 尾部的指令更敏感如果你把所有规范堆在一起位置靠后的要求很容易被“遗忘”。而技能文件本身就是相对独立的指令单元加载后就是最近期的上下文模型对它的遵循度会高很多。第三个坑是经验无法沉淀。团队里今天你发现了一个新坑记在脑子里明天另一个同事带着 AI 助手又踩一遍。有了技能体系之后踩坑经验可以直接固化成新的技能规则团队的整体 AI 工程质量就能持续积累而不是每次从零开始。这种增量式演进本质上就是团队经验在 AI 时代的“版本管理”。3. 实操从零搭一套 Superpower 技能系统3.1 环境准备确认你的 AI 编程助手底座开始之前先确认一件事你现在用的 AI 编程助手是什么。Superpower 的思路是站在现有助手之上做增强所以你得先有一个能跑起来的底座比如 Claude Code、opencode 这类开源 AI 编程终端。我自己的主力环境是 opencode 配合本地模型做日常任务重度工程任务走 Claude Code。Superpower 的接入方式不复杂本质上是把你的 skill 配置告诉助手让它知道在什么场景下加载哪个技能文件。不同助手的配置入口不一样但通用的原理是一致的让助手具备读取、加载、执行技能文件的能力。由于这块生态更新速度相当快我的建议是先别追求一步到位的图形界面直接用命令行或者配置文件搞定核心链路等跑通了再考虑要不要上封装层。如果你只是想在现有编辑器里尝鲜也可以先看它有没有对应的插件市场。检索信息的时候多用“superpower skills install”“opencode superpower”这类组合词去找最新教程比守着旧文章强。3.2 技能文件长什么样一个代码审查技能的完整模板技能文件是 Superpower 的核心资产。以我最常用的“代码审查技能”为例拆开来看它的结构其实非常像一份“标准作业指导书”。一个完整的技能文件包含四个部分元信息区声明技能的触发条件和使用范围触发指令区说明模型在什么输入信号下应该调用这个技能执行流程区按序排列资深工程师的审查要点输出规范区规定审查结果应该以什么格式呈现。下面是一份精简单元告诉你结构长什么样子--- name: senior-code-review description: 当用户要求审查代码、检查 PR、评估变更质量时使用本技能 trigger: 代码审查请求 / PR 变更分析 / 提交前自检 version: 1.0.0 --- # 执行流程 1. 先做变更概览确认本次变更涉及的文件清单与依赖关系 2. 检查接口影响面确认被修改函数的全部调用方是否需要同步调整 3. 错误处理审计逐条核对异常路径是否都有兜底逻辑 4. 安全审查检查输入校验、敏感信息泄露、越权访问风险 5. 并发分析识别是否存在竞态条件、死锁隐患 6. 日志与可观测性确认关键路径有日志打点 7. 输出审查报告按下述格式输出结论 # 输出格式 - 问题总览按严重级别阻塞/主要/次要/建议汇总 - 关键问题说明每个问题标注文件行号、问题类型、修复建议 - 优点摘要做得好的地方也要反馈你看到没有这里面没有一句是“更聪明”的魔法全是实打实的工程步骤。但正是这些步骤让模型从“凭感觉看代码”变成了“按流程审代码”。写完技能文件后把它放到 Superpower 约定的技能目录下再通过助手的配置入口启用即可。3.3 Superpower 和 OpenSpec 搭配需求规范驱动的开发闭环如果只是单技能调用Superpower 已经能帮你提升不少效率。但真正让我觉得它“值回票价”的是把它和 OpenSpec 这类规范工具串成一套完整闭环。OpenSpec 做的事情是需求前置管理动手写代码之前先基于用户需求生成一份结构化的技术方案。里面包含背景、目标、接口定义、数据模型、变更影响面这些内容。传统流程里这份文档写完可能就躺在 wiki 里吃灰了人和 AI 各写各的。但有了 Superpower 之后OpenSpec 生成的规范文档可以直接成为 AI 助手的输入基线后续开发、重构、测试技能全部围绕这份规范展开。我的实践链路是先用 OpenSpec 把模糊需求整理成标准 spec再让 Superpower 匹配对应的工程技能最后交给底层 AI 助手执行。这样一来需求有据可依执行有步骤可循变更有审查兜底。整套流程跑下来最大的感受就是返工率明显下降因为大方向在动手前就被规格和技能锁死了。这个搭配能给到你的东西不是一个灵光一现的答案而是一套方法论的闭环定义问题、规划动作、执行验证、反馈固化。可以说这才是“让模型学会资深工程师肌肉记忆”最有说服力的落地方式。3.4 技能文件怎么维护版本管理和持续沉淀技巧技能文件写出来只是第一步能持续迭代才是真本事。我把 Superpower 的技能目录直接挂到了 Git 仓库里每次改动技能文件都会用 git 做一次版本记录。这样一来技能本身就成了团队资产谁改了什么、为什么改都有一本帐。我个人的维护习惯是每次在 AI 协作过程中发现一个值得固化的“坑”就立刻记进一个临时笔记文件攒到两三个之后统一提炼成有效技能规则。千万别高估自己的记忆力也别在过程中反复打断去更新技能文件那样既影响任务流又会降低你的记录意愿。技能沉淀是一个积小成大的过程攒着攒着你就拥有一套完全贴合团队实践的私房技能库了。另外有一点要注意技能文件不是越细越好。如果你把一个技能的规则写得太死、太长反而会拖慢模型的响应速度也容易引入自相矛盾。量化的指标是单技能文件能控制在一个能完整阅读的长度以内超过的话就按子模块拆成技能间嵌套调用。4. 常见问题与排查技巧实录4.1 技能不生效模型根本不理会我写的规则怎么办这是最让人血压升高的问题。你好不容易写完一个技能文件信心满满地发给助手结果它瞟了一眼继续我行我素。排查下来90% 的原因是触发条件写得不清晰。模型加载技能靠的是你定义的触发描述如果描述太笼统比如“当用户要求帮助时使用本技能”它就懵了——用户的请求十有八九都是“帮忙”到底该用哪个技能解决方法是把触发条件写得具体比如代码审查技能就写“当用户要求审查代码、检查 PR 变更、评估合并风险时触发”让模型一下子就能对号入座。还有一个小技巧是列出反例告诉模型“日常对话、非代码提问不要加载本技能”能显著减少误触发。4.2 上下文爆炸技能加载太多模型开始胡言乱语技能是个好东西但好东西也不能贪杯。有一次我给一个任务配了代码审查、接口安全、SQL 优化三个技能模型直接开始“精神分裂”一会儿输出审查结论一会儿跳到慢查询分析格式也乱了。后来我专门看了一下本地模型的日志发现因为技能内容加起来太长把主要工作的空间都挤占了模型为了把输出框填满只能东拉西扯。从那以后我就养成了一个习惯单次任务尽量只挂一个主技能最多再配一个辅助技能。如果你的任务确实涉及多个方面宁可串行执行——先跑审查再根据结果调优化技能也不要一次性全塞进去。上下文窗口是有限的资源给模型留足“思考”的空间比给它更多规则重要得多。4.3 本地模型接入时的显存与量化问题Superpower 本身不挑模型但如果你跟我一样有些任务不想走云端 API、倾向于用本地模型处理性能上的限制就得心里有数。本地加载大模型主要卡在显存VRAM和内存带宽上。一个 7B 参数的模型做 4bit 量化之后大概需要 6GB 左右的显存才能舒服地推理如果要跑 32k 以上的长上下文开销还要上浮。常用到的量化方案有 GGUF 格式配合 llama.cpp 系推理引擎模型文件可以按“Q4_K_M、Q5_K_M”这类量化等级去选等级越高越接近原版效果但吃显存也越多。先把技能文件和模型的上下文长度匹配好控制在模型能力的舒适区内输出才会稳。另外特别提醒一句Superpower 这种技能注入方式本质上也会让实践中的 token 消耗变多因为每个任务都携带了一份结构化的作业指导书。哪怕是开源模型 API也是计 token 的实际跑起来前先把预算因子考虑进去别等账单出来了再心疼。4.4 模型“有样学样”但完全不加变通怎么办还有一类问题恰恰相反——模型太听话了技能里怎么写它就怎么执行哪怕场景明显不适用它也照搬照抄。比如代码审查技能里规定“检查数据库索引使用”但如果这次变更只是改了个文案它也要正儿八经地分析半天索引显得特别机械。这个问题的本质是技能文件缺少“退出条件”或“情况分支”。资深工程师的肌肉记忆不只是记忆还包含“什么时候该打破规则”的判断力。解决方案是在技能文件里增加一个决策步骤明确写出“如果变更范围不涉及数据层跳过节 4”这类条件转移指令。训练模型判断什么场景需要什么技能其实也是你沉淀的工程能力的反映写得越细模型的“变通”能力才越自然。最后说两句实在的我个人在实际操作中的一个体会是Superpower 这类项目真正的门槛不在于安装配置而在于你能不能把自己的工程经验拆解得足够细、足够结构化。很多人下载了技能库用了一周觉得“也就那样”往往是因为他们习惯了“一句话要结果”而忽略了“把经验翻译成步骤”这件事本身的价值。最后再分享一个小技巧试用新技能的时候别在关键时刻直接上生产级任务。先拿一个你已经完全掌握答案的旧项目练手看看模型走得流程对不对、输出结果跟你自己做完的差异在哪里。通过这种复盘你既能检验技能文件的质量也能反推自己的思考盲区。这本质上也是一个构建自我成长循环的过程——你教模型模型也在帮你理清自己的经验。这大概就是我觉得这个开源项目最值得玩味的地方。
