用 AI Agent 写代码已经不是新鲜事了。Cursor、Copilot、Devin、Claude Code——每天都有新的工具告诉你"AI 能写代码了"。但用过一段时间后，你会发现一个尴尬的事实：AI 写的代码能跑，但写的方式经常是错的。
它会跳过测试直接写实现、不遵循项目的代码风格、忽略安全最佳实践、不考虑错误处理、把所有逻辑塞进一个函数。这就像一个实习生——聪明、勤快，但缺乏工程素养。
Superpowers（256K Star）的思路完全不同：不是给 Agent 更强的能力，而是给它更好的行为规范。 它定义了一套 Agentic Skills（技能模块），告诉 Agent 在什么场景下应该怎么做，而不是让它自由发挥。
什么是 Agentic Skills
Agentic Skills 不是一个 prompt，不是一个工具，而是一套结构化的行为规范。每个 Skill 定义了：
- 触发条件：什么情况下应该使用这个 Skill
- 执行步骤：具体的操作流程，不是模糊的指令，而是可执行的步骤
- 约束规则：必须遵守的限制，比如"先写测试再写实现"
- 验证标准：怎么判断这个 Skill 的执行是否成功
举个例子，Superpowers 里有一个 writing-plans Skill：在 Agent 开始写代码之前，它必须先制定一个计划，把任务拆解为明确的步骤，等人类确认后再执行。这不是一个建议，而是一个硬性约束。
另一个 Skill 是 test-driven-development：要求 Agent 先写失败的测试用例，再写让测试通过的实现，最后重构。这是 TDD 的经典流程，但绝大多数 AI 编码工具都不会主动这样做。
Superpowers 的技能模块设计
Superpowers 的 Skills 体系涵盖了软件开发的完整生命周期（SDLC）：
规划阶段 Skills
writing-plans：要求 Agent 在动手前先写一个结构化的计划，包含任务分解、依赖关系、预期输出。这个 Skill 的核心理念是"计划先行，执行在后"。在实际使用中，这个 Skill 能大幅减少 Agent 的返工次数——因为它在执行前就暴露了歧义和遗漏。
开发阶段 Skills
test-driven-development：强制 TDD 流程。Agent 必须先写测试，看到测试失败，再写实现代码，再跑测试确认通过。这个流程确保了代码的可测试性和正确性。
systematic-debugging：当 Agent 遇到 bug 时，不是盲目修改，而是按照"复现 -> 定位 -> 分析 -> 修复 -> 验证"的流程系统化调试。这个 Skill 的关键约束是：在没有充分理解 bug 根因之前，禁止修改代码。
代码质量 Skills
requesting-code-review：在代码完成后，Agent 必须主动发起一次自我审查，检查是否有安全漏洞、性能问题、代码风格问题。这个 Skill 会引导 Agent 逐条检查常见问题清单。
writing-conventions：定义了代码编写的基本准则，包括命名规范、注释要求、函数长度限制、错误处理要求等。
Subagent-Driven Development 方法论
Superpowers 最核心的创新是提出了 Subagent-Driven Development（子代理驱动开发） 方法论。它的核心思想是：不要让一个 Agent 做所有事情，而是把任务分配给专门化的子 Agent。
这跟现实世界的软件团队是一样的——你不会让一个工程师同时负责前端、后端、数据库、运维。每个子 Agent 有自己的 Skill 集合和专业领域。
# Subagent-Driven Development 的典型工作流
1. 主 Agent 接收任务
2. 主 Agent 创建 planning 子 Agent → 输出任务计划
3. 主 Agent 创建 coding 子 Agent（配置 TDD Skill）→ 编写测试和实现
4. 主 Agent 创建 review 子 Agent → 审查代码质量
5. 主 Agent 汇总结果，报告给人类每个子 Agent 有独立的上下文，不会被其他任务的噪音干扰。coding 子 Agent 的上下文里只有"写这个功能的测试和实现"，不会混入"审查代码"或"制定计划"的干扰信息。
跟普通 Agent 工作流的区别
你可能会问：这跟 LangChain 的 Agent、或者直接用 Claude Code 有什么区别？
普通 Agent 工作流是这样的：你给 Agent 一个任务，Agent 自己决定怎么做。它可能先写代码再测试，也可能直接写实现不测试。它的行为取决于 LLM 的"心情"和 prompt 的质量。每次执行的结果可能完全不同。
Superpowers 的工作流是这样的：你给 Agent 一个任务，Agent 的行为被 Skills 约束——它必须先计划、再测试、再实现、再审查。每一步都有明确的输入输出规范。执行结果的可预测性大幅提高。
这就像"自由探索"和"标准流程"的区别。自由探索可能发现捷径，也可能迷路；标准流程可能慢一点，但一定能到达目的地。
如何定义和复用 Skills
Superpowers 的 Skills 是用 Markdown 文件定义的，非常易读易写。一个自定义 Skill 的结构大致如下：
# Skill: security-audit
## When to Use
当代码涉及用户认证、数据加密、API 密钥处理时触发。
## Steps
1. 检查所有用户输入是否经过验证和清洗
2. 确认密码存储使用了 bcrypt/argon2 等安全哈希
3. 检查 API 密钥是否硬编码在代码中
4. 验证 HTTPS 是否正确配置
5. 检查 SQL 注入和 XSS 攻击面
6. 输出安全审计报告
## Constraints
- 不得跳过任何检查步骤
- 发现安全问题必须标记为 BLOCKER 级别
- 不得在未修复安全问题的情况下继续开发
## Verification
- 所有检查项必须有明确的 PASS/FAIL 结论
- BLOCKER 级别问题必须全部解决才能通过你可以把自定义的 Skills 文件放在项目的 .superpowers/skills/ 目录下，Agent 在执行时会自动加载。这些 Skills 可以在团队内部共享，形成团队级别的工程规范。
实际使用体验
我在两个场景下测试了 Superpowers：
场景一：用 Superpowers 指导 Claude Code 开发一个 CLI 工具
开启 Superpowers 后，Claude Code 的行为有了明显变化：
- 它会先花时间写计划，列出要实现的功能模块和依赖关系
- 写代码前会先写测试，确认测试失败后再写实现
- 遇到报错时会系统化排查，而不是盲目修改代码
- 代码完成后会主动做 code review，检查边界情况和错误处理
整个过程比不用 Superpowers 慢了大约 30%，但代码质量明显更高——测试覆盖率从平时的不到 20% 提升到了 80% 以上，而且几乎没有需要我手动修复的 bug。
场景二：团队协作场景
把 Superpowers 的 Skills 文件放在团队项目的仓库里，不同成员用不同的 AI 编码工具，但因为共享了同一套 Skills，生成的代码风格和质量标准是一致的。这解决了 AI 编码工具的一个大痛点：不同人用不同工具生成的代码风格差异巨大。
对 Agent 开发范式的影响
Superpowers 代表了一个重要的范式转变：从"提升 Agent 能力"转向"约束 Agent 行为"。
过去一年，AI 编码工具的竞争焦点是"能力"——更强的模型、更长的上下文、更多的工具调用。但 Superpowers 证明了：一个被良好约束的普通 Agent，可能比一个能力更强但自由放飞的 Agent 更有用。
这跟软件工程的发展历史是一致的。编程语言从 C 到 Rust 的演进，核心不是"给你更多能力"，而是"在编译期就阻止你犯错"。Superpowers 之于 Agent，就像 Rust 的所有权系统之于内存管理——用约束来保证正确性。
256K 的 Star 数证明了社区对这个理念的认同。Superpowers 不是一个 AI 编码工具，而是一种用工程方法论来驯服 AI 的方式。
适合谁用
最适合用 Superpowers 的场景：
- 专业开发团队：已经有工程规范，想让 AI 编码工具也遵循这些规范
- 高质量要求的项目：测试覆盖率、代码审查、安全审计不能打折扣
- 多工具协作的团队：不同成员用不同的 AI 工具，需要统一的编码标准
- 想提升 Agent 代码质量的个人开发者
不太适合的场景：
- 快速原型开发——规范会拖慢速度
- 非代码任务——Superpowers 聚焦于软件开发
- 不需要 AI 编码工具的团队
Superpowers 给我们的最大启示是：AI 的未来不只是更强的能力，还有更好的行为约束。 当我们不再争论"AI 能不能写代码"，而是开始思考"AI 应该怎么写代码"时，Agent 开发才真正进入了工程化时代。