1. 为什么“让AI Coding Agent守规矩”这件事，比写代码本身更难？
我第一次在团队内部演示 superpowers 时，会议室里坐了六个人：两位前端、两位后端、一位测试、一位技术负责人。我敲下命令：“用 React 实现一个带表单验证的用户注册页，遵循我们项目里的 ESLint 规则、Prettier 配置、组件命名规范，并自动提交 PR 到 dev 分支。”
AI 在 23 秒内生成了完整代码、写了单元测试、生成了符合 Conventional Commits 格式的 commit message，甚至把 PR 描述模板里的“关联 Jira 编号”字段都留了占位符——但没人鼓掌。技术负责人盯着屏幕问了一句：“它知道我们上周五刚把 src/components 改成 src/ui 吗？它知道 useFormValidation 这个自定义 Hook 必须从 @ourorg/hooks 导入，而不是自己重写吗？它知道这个页面的 API 调用必须走统一的 apiClient.post() 封装，而不是直接用 fetch 吗？”
那一刻我意识到：我们不是缺一个能写代码的 AI，而是缺一个 能听懂工程语境的协作者 。superpowers 不是另一个 Copilot 或 Cursor 的复刻版，它的核心设计哲学非常明确—— 不追求“写得快”，而追求“写得对上下文” 。它把 AI Coding Agent 从“代码生成器”重新定义为“流程执行器”。这背后不是模型参数调大就能解决的问题，而是整套工程认知体系的重构：如何把散落在 Confluence 文档里的分支策略、藏在 .husky/pre-commit 里的校验逻辑、写在 CONTRIBUTING.md 第三页的 PR 模板、甚至 Slack 频道里某次临时讨论确定的 API 响应字段命名习惯……全部翻译成 AI 可理解、可执行、可验证的结构化指令。
关键词里反复出现的 “工程流程” 和 “协作伙伴”，恰恰点中了当前 AI 编程工具最普遍的失焦点：它们默认开发者是“孤岛式编码者”，而真实世界里，90% 的代码修改决策依赖于隐性知识（tacit knowledge）——那些没写进文档、但老员工闭着眼都知道的规则。superpowers 的突破在于，它不试图用更大模型去“猜”这些规则，而是提供了一套轻量但严谨的“工程契约”（Engineering Contract）机制。你不需要教它什么是 Git Flow，你只需要告诉它：“当修改 src/ 下文件时，必须触发 lint-staged ；当新增组件时，必须在 src/ui/index.ts 中导出；当生成 API 调用时，必须引用 src/lib/apiClient.ts 。” 它会把这些声明编译成运行时约束，在每一步生成、修改、提交动作中强制校验。这不是功能叠加，而是范式迁移——从“AI 辅助人”转向“人与 AI 共同遵守同一套协议”。
这也解释了为什么网络热词里，“superpowers skill 是干嘛的”和“superpowers怎么用”高频并存。因为它的学习曲线不是“学命令”，而是“学契约设计”。一个 junior 开发者可能十分钟就跑通了 superpowers init ，但要真正让它产出符合团队标准的代码，他需要花两小时去梳理自己项目的 git hooks 、 eslint 规则链、 prettier 配置继承关系，再把这些信息翻译成 superpowers 的 skill 定义。这个过程本身，就是一次对团队工程规范的深度反刍。所以，如果你正在评估 superpowers 是否值得引入，别先看它生成代码的速度，先问自己一个问题： 我们团队的工程规范，是否已经足够清晰、稳定、可被机器读取？ 如果答案是否定的，superpowers 不会帮你掩盖混乱，它会第一个把你规范里的模糊地带暴露出来——而这，恰恰是它最锋利的价值。
2. Skill 机制解剖：不是插件，而是工程规则的“可执行说明书”
在 superpowers 的文档里，“Skill”这个词被反复强调，但很多初学者误以为它类似 VS Code 插件或 GitHub Copilot 的“扩展包”——点几下安装，选几个模板，然后坐等 AI 变强。这是最大的认知偏差。superpowers 的 Skill，本质上是一份 用 YAML + 表达式语言编写的、面向工程流程的“可执行说明书” 。它不封装功能，它封装 约束条件与执行上下文 。理解这一点，是掌握 superpowers 的分水岭。
我们以一个真实案例切入：某电商后台项目要求所有新 API 接口必须遵循 POST /v2/{resource}/batch-create 的路径格式，且请求体必须包含 trace_id 字段（用于全链路追踪），响应体必须返回 request_id 。过去，这个规则只存在于接口设计文档 PDF 的第 17 页，以及后端同学口头提醒的“记得加 trace_id”。引入 superpowers 后，团队编写了一个名为 api-contract-v2 的 Skill：
# .superpowers/skills/api-contract-v2.yaml
name: api-contract-v2
description: Enforces v2 batch API contract for new endpoints
trigger:
- file_pattern: "src/api/**/*"
event: create
constraints:
- id: path_format
description: "Path must match /v2/{resource}/batch-create pattern"
condition: |
$file.path matches /^src\/api\/.*\/(batch-create)\.ts$/
and $file.content contains "export const handler = async (req: NextApiRequest, res: NextApiResponse) => {"
fix: |
# Auto-generate correct path from filename
$path = "/v2/" + $file.path.split("/")[2] + "/batch-create"
$file.content = $file.content.replace(/const handler = async.*?{/, "const handler = async (req: NextApiRequest, res: NextApiResponse) => {\n // Generated for: " + $path)
- id: trace_id_required
description: "Request body must contain trace_id field"
condition: |
$file.content contains "req.body"
and not ($file.content contains "trace_id")
fix: |
$file.content = $file.content.replace(
/(const handler = async \(req: NextApiRequest, res: NextApiResponse\) => \{)/,
"$1\n if (!req.body?.trace_id) {\n 
2835
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
