给AI装上肌肉记忆：Superpowers如何让代码代理真正靠谱
给AI装上"肌肉记忆"：Superpowers如何让代码代理真正靠谱
🤔 第一章：为什么你的AI总是一脸懵
想象一下，你刚考完驾照，兴奋地坐进一辆全新的车里。油门、刹车、方向盘——这些你都会用。但真正开上路时，你还是会手忙脚乱：什么时候打转向灯？变道要看哪个镜子？遇到加塞怎么办？
这就是今天大多数AI代码代理的处境。
它们"会写代码"——语法正确、逻辑通顺、甚至能处理复杂算法。但真正投入项目时，问题百出：不写测试就动手、跳过设计直接编码、遇到bug瞎猜一通……就像新司机知道怎么踩油门，却不知道什么时候该踩刹车。
问题不在于"能力"，而在于"经验"。
经验是什么？是一套在特定场景下自动触发的行为模式。老司机看到前车刹车灯亮，脚已经移到刹车上了——不是思考的结果，是肌肉记忆。
Superpowers要做的，就是给AI代码代理装上这种"肌肉记忆"。
🔮 第二章：Hook魔法——在AI"醒来"的那一刻
如果要在AI开始工作前说一句话，你会说什么？
"请认真完成"？"记得写测试"？"先设计再动手"？
这些话说了也白说，因为AI根本记不住——每次对话都是全新的开始，没有上次的记忆，没有积累的经验。
Superpowers的解决方案出奇简单：在AI"醒来"的那一刻，直接把指令注入它的脑子里。
这就是 SessionStart Hook 的工作原理。当Claude Code或Cursor启动一个新会话时，hooks/session-start 这个脚本会自动执行，读取 using-superpowers 技能的内容，然后注入到系统提示中。
用户打开Claude Code
↓
SessionStart Hook 触发
↓
读取 using-superpowers 技能
↓
注入到系统提示
↓
AI"醒来"，已经知道该怎么做这就像给新员工入职时，直接把公司规章刻在他脑子里——不用培训，不会忘记，每次都一样。
技术细节：Hook配置在hooks/hooks.json中，使用JSON格式定义触发条件。session-start是一个Bash脚本，用escape_for_json函数处理特殊字符，确保注入内容格式正确。
📚 第三章：技能库——AI的"武功秘籍"
Hook解决了"怎么开始"的问题，但"开始之后做什么"呢？
这就是技能（Skill）登场的时候。
技能是什么？想象一本菜谱：它告诉你什么时候用（"当你要做红烧肉时"），需要什么材料，按什么步骤操作，常见的坑在哪里。你不是每次做菜都从头摸索，而是翻开菜谱，照着做。
Superpowers的技能就是这个逻辑。每个技能是一个Markdown文件，结构如下：
---
name: test-driven-development
description: Use when implementing any feature or bugfix, before writing implementation code
---
# Test-Driven Development (TDD)
## Overview
Write the test first. Watch it fail. Write minimal code to pass.
## When to Use
- New features
- Bug fixes
- Refactoring
...关键在于 description 字段。它不是告诉你这个技能"是什么"，而是告诉你"什么时候用"。
设计洞察：测试发现，如果description描述了技能的流程，AI可能会直接照着description执行，而不是去读取完整的技能内容。所以description必须只写触发条件，不写工作流程。这叫 CSO（Claude Search Optimization）。技能存在
skills/ 目录下，每个技能一个文件夹。AI通过 Skill 工具搜索和加载技能——就像在图书馆查目录，找到需要的书，然后翻开来读。
技能的类型
技能分两类：
- Rigid（刚性）：必须严格遵循，不能变通。比如TDD、系统调试。
- Flexible（灵活）：可以根据情况调整。比如设计模式、代码风格。
🧪 第四章：TDD驱动——用失败证明成功
Superpowers最独特的创新，是用TDD（测试驱动开发）的方法论来写技能本身。
等等，用TDD写文档？这是什么操作？
传统写文档的流程：想清楚要说什么 → 写下来 → 发布 → 有人反馈问题 → 修改。
Superpowers的流程完全不同：
RED阶段：写一个压力测试场景，让AI在没有技能的情况下执行任务
↓
观察AI失败的方式，记录它找了哪些借口
↓
GREEN阶段：写技能，专门针对那些失败和借口
↓
REFACTOR阶段：再测试，发现新的漏洞，修补
↓
循环直到"防弹"举个例子。test-driven-development 技能就是为了防止AI跳过测试而设计的。在压力测试中，AI会找各种借口：
| AI的借口 | 技能的反驳 |
|---|---|
| "太简单了，不需要测试" | 简单代码也会出错，测试只要30秒 |
| "我之后再补测试" | 后补的测试什么也证明不了 |
| "我已经手动测试过了" | 手动测试不是系统化的，无法复现 |
| "删掉已有代码太浪费" | 沉没成本谬误，不可信的代码是技术债务 |
技能里直接把这些借口和反驳写进去，AI读到后，下次就不会再找同样的借口了。
核心理念：如果你没看到测试失败，你不知道测试测的是不是正确的东西。
🔄 第五章：四步工作流——从想法到代码
有了技能，AI知道"怎么做"了。但一个完整的项目，需要多个技能配合使用。
Superpowers定义了一个标准工作流，把技能串联起来：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Brainstorm │ → │Write Plans │ → │ Execute │ → │ Finish │
│ 头脑风暴 │ │ 写计划 │ │ 执行计划 │ │ 收尾 │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘第一步：头脑风暴（Brainstorming）
用户说"我想做个功能"，AI的第一反应不是写代码，而是问问题。
- 你想解决什么问题？
- 有什么约束条件？
- 成功的标准是什么？
硬性规定：在用户批准设计之前，AI不得调用任何实现技能、不得写任何代码、不得搭建任何项目脚手架。即使是"简单"项目也必须走这个流程——因为"简单"项目恰恰是最容易被忽视的地方。
第二步：写计划（Writing Plans）
设计批准后，AI把设计分解成小任务——每个任务2-5分钟可完成。
每个任务包含：
- 精确的文件路径
- 完整的代码
- 验证步骤
这就像把一道大菜拆解成一个个具体的步骤：切葱、备姜、热油、下锅……每一步都清清楚楚。
第三步：执行计划（Subagent-Driven Development）
这是Superpowers最强大的部分。
AI不是自己一个个执行任务，而是派遣子代理去执行。每个子代理只负责一个任务，完成后汇报。
为什么这么做？
- 上下文隔离：子代理只看到自己的任务，不会被其他信息干扰
- 并行效率：多个子代理可以同时工作
- 质量控制：每个任务完成后，有专门的评审流程
- 规范符合性评审：是否完成了计划要求？
- 代码质量评审：代码写得好不好？
第四步：收尾（Finishing a Development Branch）
所有任务完成后，AI验证测试是否通过，然后给用户选择：
- 合并到主分支？
- 创建Pull Request？
- 保持当前分支？
- 放弃更改？
💡 第六章：设计哲学——过程优于猜测
Superpowers的核心哲学，可以总结为一句话：
系统性优于随意性，证据优于声称。这不是口号，而是贯穿整个设计的原则。
过程优于猜测
遇到bug时，普通AI会"猜"问题在哪——也许是这里？试试改一下？不对？那换那里？
Superpowers的 systematic-debugging 技能要求：先复现，再定位，再修复。每一步都要有证据，不能靠猜。
测试优于声明
"我已经测试过了"这句话在Superpowers里没有意义。
有意义的是：我看到了测试失败，然后写了代码，然后看到测试通过。
这三步缺一不可。没有看到失败，你不知道测试测的是不是对的东西。
简单优于复杂
Superpowers本身也是按这个原则设计的。核心代码只有200行JavaScript，技能都是纯Markdown文件，没有复杂的依赖，没有黑魔法。
技术栈：PHP用于锦囊系统，JavaScript用于核心技能发现，Bash用于Hook脚本。每种语言只做它最擅长的事。
🎯 结语：从"能写代码"到"会写代码"
Superpowers做的事情，本质上是把最佳实践变成默认行为。
它不教AI新的技术——AI本来就会写代码。它教AI的是：什么时候该停下来思考，什么时候该写测试，什么时候该问用户，什么时候该评审。
这些不是技术能力，而是工程素养。
就像驾校教练不会教你汽车引擎原理，但会教你"看到红灯要减速"。这些看似简单的规则，区分了"会开车"和"不会开车"。
Superpowers让AI从"能写代码"进化到"会写代码"。
这就是给AI装上"肌肉记忆"的意义。
本文基于 Superpowers v4.3.1 撰写，项目地址：https://github.com/obra/superpowers
讨论回复
0 条回复还没有人回复