最近有个做后端的朋友跟我抱怨模型很聪明很多生僻语法一说就会但放进他的老项目里越改越像废墟。代码没崩边界在悄悄塌。我问他是不是一上来就让它改公共方法他没说话。这种场景这几年我见过太多不是模型不够聪明是它没有“先看再改”“小步验证”“改完回查”这类过程习惯。于是我把话题引到了 Superpowers 这个开源项目上——它不是最聪明的模型也不是靠堆提示词炫技的工具它的做法很朴素把资深工程师那些“不用想就会做”的动作固化成模型在动手前必须经过的技能文件让模型学会肌肉记忆。这其实是现在很多 AI 辅助开发项目里最值钱又最容易被忽视的部分。模型的能力天花板已经很高了拉开差距的反而是它接到任务之后走什么流程。今天这篇就围绕这个项目展开聊聊它是怎么把“聪明”翻译成“稳定可靠”的以及我实际接入、复刻、踩坑之后总结下来的一些经验。1. 聪明是能力肌肉记忆是交付AI 辅助编码真正缺的不是推理1.1 先说那个让我吃尽苦头的重构我去年接了一个内部数据同步模块的改造代码量不大但调用关系特别绕。用 AI 编码代理帮我迁移第一次跑下来非常惊艳几百行新代码一次通过编译。我一度以为这个模块已经搞定了结果跑了三组回归测试坏了两个统计口径。原因并不玄妙代理在迁移一个公共工具函数的时候只看了一眼当前文件里的用法没有去全局搜索还有多少地方在依赖这个函数理所当然地改掉了默认返回值。从单点看它的推理完全正确从全局看这就是资深工程师根本不会犯的低级错误。后来我没有换更强的模型而是换了一套带技能机制的开源工具链问题很快就不再出现了。从那以后我形成了个判断对工程任务来说模型单次推理的“聪明”程度远不如它整套过程行为的稳定程度重要。而过程行为不是靠模型自己领悟出来的它需要被显式地教。1.2 把“过程记忆”拆开看它不是玄学我在给团队做分享时常用一个体操运动员的类比。体操比赛里那些高难度动作运动员不可能上了赛场还在脑子里面一步步推导肌肉该怎么发力。比赛时靠的是平时反复训练形成的肌肉记忆。肌肉记忆听着玄本质就是面对特定刺激身体直接执行已经被验证过的固定动作序列。开发工作也一样。资深工程师之所以稳不是因为他们每一步都在临时推理而是他们遇到“改公共方法”这类场景时会自动执行一套固定流程先搜全仓库调用点再看测试覆盖然后改代码最后跑回归。这套流程如果靠每次都在对话里现想肯定会遗漏如果把它制作成技能文件让 AI 代理在对应场景自动加载并执行那就是真正的肌肉记忆。Superpowers 这类开源项目做的正是这件事。它把技能拆成一个个 Markdown 加脚本的组合文件放到代理能读取的特定目录中。模型看到用户的请求后会根据技能文件里描述的场景把对应流程读进来像一个老员工翻开自己的操作手册一样按顺序执行。1.3 提示词、插件、技能到底有什么不同很多人问我这不就是写几个提示词吗有什么稀奇的。我的体会是差别很大可以用一个不太严谨但好理解的对比来看维度一次性提示词插件/工具技能文件触发方式每次人工输入安装后常驻按场景自动匹配或由代理主动调用内容形式随对话消失封装工具调用流程文档加可执行检查项稳定性依赖用户表达水平高但偏工具层高且影响决策过程学习成本低中低到中适合解决单次问题特定操作整套工作习惯提示词是在“告诉模型这次怎么做”技能文件是在“塑造模型这类任务一贯怎么做”。前者是点后者是面。Superpowers 这个项目最核心的价值不是给你一两个聪明的技巧而是给你一整套路可以沉淀、修改、共享的工作习惯层。这个习惯层不依赖特定模型只要模型具备读取文件并遵循指令的能力就能用。2. 把资深工程师的默认动作编成技能库Superpowers 的挂载方式2.1 先说最基础的放置位置和目录结构Superpowers 这类技能库落到磁盘上其实是很有规则的一组目录。以我现在机器上的 Claude Code 环境为例技能目录大概是这样的~/.claude/skills/ ├── change-planner/ │ └── SKILL.md ├── code-review/ │ ├── SKILL.md │ └── review_checklist.md ├── tdd/ │ ├── SKILL.md │ └── tdd_loop.sh └── risk-explorer/ └── SKILL.md这里面每个子目录就是一个技能。SKILL.md是入口文件里面不仅有给模型看的 YAML 头信息还有具体步骤。所谓“安装”说白了就是把技能目录放到模型能扫描到的固定位置。用户级目录放全局习惯项目级目录比如.claude/skills/放当前仓库特有的规矩。如果你不想碰全局完全可以在项目根目录建一个.claude/skills/文件夹把技能放进去这样更利于团队共享。我第一次装的时候也犹豫过到底该放全局还是项目级。我的经验是通用工程习惯放全局一次配置到处可用和当前仓库架构强相关的检查项比如“这个服务必须走灰度配置”“改接口要同步更新 OpenAPI 文档”一定要放项目级否则换个仓库就会造成误导。2.2 SKILL.md 的“触发开关”长什么样技能文件能不能被正确触发关键看 YAML 头里的描述写得好不好。下面是一个我在实际项目里精简过的例子--- name: change-planner description: 当任务涉及多文件重构、公共接口调整、模块迁移或者你无法确定改动影响范围时使用。纯文档拼写修正不要使用此技能。 --- # Change Planner 这是一套防止你“自信地跑错方向”的流程。 ## 执行步骤 1. 先不写任何代码。 2. 使用文件读取工具定位入口文件找出被调用的公共方法。 3. 调用全局搜索工具列出所有调用点。 4. 阅读相关测试文件标注当前行为断言。 5. 输出一份计划必须包含影响文件清单、行为变化点、回滚方式。 6. 等待用户确认计划后再开始修改。这个技能的精髓在 YAML 的description字段。description是模型的“触发开关”写得太泛模型遇到任何任务都容易想起它写得太窄关键场景又触发不了。我自己的经验是要写清楚“什么时候必须用”和“什么时候不要用”正反两面都写模型的选择命中率会高很多。像上面例子一样把“拼写修正不要使用”加进去能挡掉很多误触发。2.3 如何验证技能不是“假装加载”技能放进去之后要验证它真的在起作用不是靠感觉。我常用的验证方法非常朴素在技能文件里埋一个只有模型读完整份文件后才会说出口的“口令”或专有名词。比如在SKILL.md的末尾写一句“如果本技能已加载请回话时带上‘已按流程进入规划阶段’”。然后故意让它处理一个触发场景看它回话里有没有这句。没有回的话先别急着怀疑模型优先检查两个地方description和当前任务的匹配度够不够高技能目录是否在代理实际扫描的路径里。有些代理工具只扫描特定目录下的技能如果你把技能放在了手工创建的路径里它可能根本看不见。这种“表面装好、实际没读”的问题比技能写得差还要隐蔽。用口令验证一次比读十篇文档都有用。3. 从复制技能到复制工作方式三种可以直接复刻的肌肉记忆3.1 重构前先输出“风险路线图”而不是代码我在用 Superpowers 的过程中体会最深的是重构场景。以前我让代理重构它马上就吐一大段新代码读起来很爽合进去就出事。后来我在技能库里强制加了一个流程任何重构类任务必须先输出一份“风险路线图”。所谓风险路线图不是项目计划书而是三个问题的答案这次改动会触碰哪些文件哪些行为在改动后可能发生变化这些行为当前有没有测试兜底有了这个前置步骤之后模型的输出风格明显不一样了。它会在改动前先搜索调用点会主动指出当前测试覆盖不足的区域。其实模型本来就有能力做这些事只是没有任何机制要求它做。技能扮演的就是这个机制的角色强制它把资深工程师“先探路再动手”的习惯走一遍。实操时可以把上面那段change-planner直接保存成技能文件。它不需要很复杂哪怕只是给模型设了一道“先计划后编码没有得到确认就不许写实现”的闸门也能挡掉大量跑偏场景。3.2 新功能开发时让“测试先行”成为默认动作很多模型的训练数据里都知道 TDD 这个词但真到实际开发时它还是会倾向于先写实现再补测试甚至在用户没要求测试时干脆不写。原因是 TDD 对模型来说是“违背直觉”的模型的最大优势是快速生成让它先写一个会失败的测试就像是自己给自己找麻烦。Superpowers 这种技能库对解决这个问题很有效因为它把 TDD 变成了一套不可跳过的动作序列。我给团队设置过一个简单的技能核心逻辑是先列出新功能的行为验收点为每个验收点写一个最小测试运行测试确认它们是失败的然后才允许写实现目标是最小代价让测试通过最后运行全量测试并提交。一个有意思的副作用是当模型先写测试时它写出的实现通常更简单。因为它已经被测试约束住了不需要靠“猜”去覆盖那些它想象中的边界情况测试本身就是需求说明书。这个效果不是模型变聪明了而是流程逼着它把问题定义清楚。3.3 用 openspec 搭 superpower先定义契约再谈做法Superpowers 本身不负责定义“你要什么”它负责的是“怎么做”。如果两者搭配在一起一个管目标契约一个管工程习惯整体体验会提升一个台阶。我看最近社区里也有不少人把 OpenSpec 和 Superpowers 一起用。OpenSpec 的模式是先写规格说明把需求拆成用户可见的行为变更再生成实施计划Superpowers 再把实施计划纳入编码技能流程。说白了就是AI 在没搞清楚需求边界之前不许直接进入“写码模式”。我实际跑下来的流程大致是这样的先用 OpenSpec 描述功能期望生成 spec 文档让代理读取 spec把任务拆分为若干验收标准调用变更规划技能判断改动范围进入 TDD 技能按验收标准逐个实现。这个组合拳最大的价值是让“靠谱”这件事变得可复制。规格提供方向技能提供路径。模型再聪明也要在轨道上跑才不容易翻车。4. 本地模型、OpenCode 与模型选型技能库和模型智商是两件独立的事4.1 技能文件天然跨模型不绑定某一家我一开始以为 Superpowers 这种技能机制只能用在特定的商业模型上后来发现不是。它的本质是把工作流程以自然语言和脚本形式保存下来模型要做的只是“读文件按指令执行”。这意味着只要你用的编码代理支持读取技能目录无论是云端模型还是本地部署的开源模型都能复用同一套肌肉记忆。尤其是现在很多人倾向于本地部署模型担心隐私和数据出域。这个时候技能库反而变得更重要。本地模型在纯推理能力上可能比顶级商业模型弱一些但它完全可以靠流程规范把差距补回来不会漏掉全局搜索不会忘记先读测试不会跳过风险分析。因为这些动作已经由技能文件强制约定好了模型不需要凭空想出来它只需要照着做。如果你用的是 OpenCode 这类支持接入本地模型的开源代理思路也差不多把技能文件放在它能读取的公共目录里然后让本地模型通过OpenAI兼容接口调用。实际能不能自动加载取决于代理版本的技能发现机制最好先用一章里说的“口令验证法”做一次小验证再铺开用。4.2 技能不是越多越好上下文才是隐形瓶颈技能数量失控是我踩过的另一个坑。一开始我看到社区里有不少现成的技能包这个也不错那个也有用一口气挂了十几个技能。结果模型的响应开始变得很“重”经常做一些多余的动作推理速度也慢了。原因是模型在任务开始时需要扫描技能描述把匹配的技能内容读进上下文。技能文件写得又长又多上下文被占用真正留给当前任务的注意力就少了。Superpowers 项目本身比较克制但你自己加的技能不一定克制。我现在维护技能库的原则是技能文件尽量控制在 50 到 100 行以内写太长模型会抓不住重点同类技能合并不搞“一天一个检查项”式的堆积定期用真实任务做回归发现某个技能连续几周都没被触发就考虑删掉或者重写触发描述。技能库应该像自己的背包不是把整个家都搬进去。只留下那些在关键场景能救命的东西肌肉记忆才真正练得出来。5. 哪些时候技能会失灵我的排查经验和补救习惯5.1 技能写了但没触发先别怪模型有一个场景让我印象很深。我给一个重构任务写了专门的“风险区探索”技能但提交给代理后它完全无视了直接给了一版重构代码。我对着技能文件反复检查没发现问题。后来把description里的“使用场景”写得更具体并且在正文第一行加了一句“在执行任何代码修改前你必须先完成本文件的步骤”问题才消失。这个现象说明模型选择是否使用技能绝大多数时候依赖description和当前任务的语义匹配。它不会像人一样主动翻遍所有技能目录。如果你的技能描述太抽象比如只写“当任务复杂时使用”模型很可能不会选它。更好的写法是直接列举具体场景比如“当任务包含修改公共函数、迁移接口或跨文件重构时使用”。描述越像索引命中率越高。5.2 技能管得太死模型反而失去判断力反过来也有一种问题。技能写得像铁律每条都是“必须”“严禁”把模型的所有自主性都掐掉了。有一段时间我特别迷恋流程约束恨不能把每一步都写死。结果代理确实不会跑偏了但也变得很笨遇到稍微超出预设的场景就卡住或者反复询问用户。后来我意识到好的肌肉记忆不是让身体僵住而是让关键的高风险动作稳定给它留下现场判断的空间。我现在设计技能会区分两层必须层比如“改公共方法前必须全局搜索调用点”“提交前必须跑完整测试”这些写死不商量建议层比如“如果项目有 CI建议优先查看最近一次失败日志”这些可以写出来让模型根据实际情况决定。这样技能既能约束风险又不会变成削足适履的教条。5.3 给我带来最大收益的一个习惯在技能库这件事上如果只保留一个习惯我会留下这个每次踩到一个真实的坑就把复盘结果写成一个小技能而不是只记在聊天记录里。有一次我在修复一个并发问题代理连续两次都只处理了表面竞态没看到底层共享资源的生命周期问题。排查完根因之后我没有保存那段修复代码而是写了一个“并发问题排查”技能里面记录了我的排查顺序先找共享可变状态再画读写路径然后看锁的粒度最后验证不可变约束是否成立。下一次再遇到并发相关的 bug代理自动加载了这个技能第一次就给出了有深度的分析而不是又去猜测。那一刻我才真正理解标题里那句话的含义Superpowers 追求的不是让模型成为智商最高的那个而是通过开源的方式把资深工程师在无数次踩坑中练出来的动作习惯转译成模型也能执行的肌肉记忆。所以我的建议很直接与其到处找更聪明的模型不如把那些你已经验证过的工程经验沉淀成技能文件。它们可能看起来只是一些普通的 Markdown但对于 AI 代理来说那就是把“靠谱”具象化之后的样子。