AI 时代编程范式的演进
AI 辅助编程正在经历三个阶段的演化。每一步都在改变我们与 AI 协作的方式 — 从简单对话到构建完整的工程化约束体系。
一问一答
手动复制粘贴代码
Rules / System Prompt
Agent 自主读写文件
Skills / Hooks / 子代理
强制工作流 + 自动审查
范式转变的本质
从 Prompt 到 Context 到 Harness，核心转变是：不再依赖"说得更好"，而是"约束得更紧"。
- Prompt：你写 10 行描述，AI 猜你要什么 → 猜对概率不稳定
- Context：你给 AI 代码库上下文 + 规则 → AI 理解变好，但仍可能偏离
- Harness：你给 AI 一套强制执行的工作流 + 自动审查 → AI 的输出被工程化地约束
| 维度 | Prompt 阶段 | Context 阶段 | Harness 阶段 |
|---|---|---|---|
| 代表工具 | ChatGPT, Copilot Chat | Cursor, Cline, Aider | Superpowers, Spec-kit |
| AI 的角色 | 问答机器人 | 具有上下文感知的助手 | 有流程约束的工程代理 |
| 人的角色 | 写 Prompt + 手动验证 | 配置规则 + 审查输出 | 设计 Spec + 审批节点 |
| 输出质量 | 取决于 Prompt 质量 | 取决于上下文丰富度 | 被工作流和审查机制约束 |
| 自主性 | 几乎为零 | 中等（读写文件） | 高（多代理协作、自我审查） |
问题：裸跑 Agent 的困境
当我们直接让 Codex、Claude Code 等 AI 编程代理"自由发挥"时，它确实能写出看起来正确的代码 — 但几乎不可能直接用于生产工程。
🚨 真实场景中的典型问题
- 跳过设计直接写代码 — 架构方向错误后才发现，返工成本巨大
- 不写测试或测试是后补的 — 测试只是为了通过，而不是验证行为
- 对需求过度解读 — 实现了大量你没要求的功能（YAGNI 违反）
- 调试靠猜 — 遇到 bug 反复 try-catch、打补丁，不做根因分析
- 宣称"已完成"但实际没验证 — 没有运行测试就说"all tests pass"
- 生成的代码不符合项目编码规范 — 命名风格、目录结构混乱
为什么 Rules 不够？
你可能会想：在 .cursorrules 或 CLAUDE.md 里写好规则不就行了？
📝 Rules 能做到的
- 设定代码风格和命名约定
- 指定技术栈和框架偏好
- 提供项目结构说明
- 给出一般性的编码原则
🚫 Rules 做不到的
- 强制先设计再写代码（AI 会忽略）
- 要求先写失败测试再实现（TDD 流程）
- 自动触发代码审查流程
- 在"完成"前强制运行验证命令
- 把大任务拆解成可管理的子任务
- 启动子代理并行执行和审查
核心洞察
Rules 是"建议"，Skills 是"流程"。Rules 放在系统提示里，AI 可以选择性遵循；Skills 把工作流程拆成一个个强制执行的步骤 — 不完成前一步，无法进入下一步。类似从"请遵守交通规则"到"设置红绿灯 + 摄像头"的区别。
解决方案：Superpowers
什么是 Superpowers？
Superpowers 是一套编程代理工作流框架，通过可组合的 Skills（技能）来约束 AI 代理的行为。它不是一个新的 AI 模型，而是一层"工程化脚手架" — 装上之后，AI 代理会自动遵循设计先行、测试驱动、代码审查等专业工程实践。
一句话总结
Superpowers = 让 AI 代理自动遵循专业软件工程实践的插件。安装后无需额外操作，代理会在相关场景下自动触发对应 Skill。
🧩 核心 Skills 一览
Superpowers 的工作原理
🔄 核心工作流
Superpowers 定义了一条严格的主流程，每一步都有明确的进入条件和产出要求。
⚙️ 技术架构
Superpowers 由三层机制组成，在不修改 AI 模型本身的情况下，重塑代理行为。
| 层级 | 机制 | 作用 |
|---|---|---|
| Session Hook | 会话启动时自动注入 using-superpowers |
让代理在每个会话开始时就知道要检查并使用 Skills |
| Skill 触发 | 基于任务类型自动匹配对应 Skill | 创意类任务 → brainstorming；Bug → systematic-debugging |
| Hard Gate | 流程门禁 — 上一步未完成不能进入下一步 | 强制设计先行、测试先行、验证后完成 |
| 子代理隔离 | 每个任务由独立子代理执行，只接收精炼的上下文 | 避免上下文污染，确保每个任务的执行环境干净 |
| 双重审查 | 规格审查 → 代码质量审查（两个不同的审查子代理） | 先检查"做对了没有"，再检查"做好了没有" |
| 自动化循环 | 审查不通过 → 自动修复 → 重新审查（最多 3 轮） | 减少人工介入，但在 3 轮失败后升级给人类 |
关键设计思想
Skills 是强制工作流，不是建议。Superpowers 的 using-superpowers Skill 明确声明：哪怕只有 1% 的可能性适用某个 Skill，代理也必须调用它。这是一个"非协商"级别的指令 — 代理没有选择跳过的自由度。
🧪 TDD 强制执行的例子
以 test-driven-development Skill 为例，看看 Superpowers 如何把一个"最佳实践建议"变成"强制流程"：
| 步骤 | 要求 | 违规后果 |
|---|---|---|
| 1. 写失败测试 | 先写一个描述期望行为的测试 | — |
| 2. 运行 → 确认红灯 | 测试必须实际运行且失败 | 如果测试直接通过 → 测试无效，重写 |
| 3. 写最小实现 | 只写让测试通过的最少代码 | 如果实现代码先于测试出现 → 删除实现代码 |
| 4. 运行 → 确认绿灯 | 测试必须实际运行且通过 | 不接受"应该能通过"的口头断言 |
| 5. 重构 | 在绿灯状态下清理代码 | 重构后必须重新运行测试确认仍为绿灯 |
⚠️ 铁律："先于测试的代码必须删除"
这是 Superpowers TDD Skill 中最严格的一条规则 — 如果 AI 在写测试之前就写了实现代码，它必须删除那些代码，然后从写测试开始重来。这确保了测试不是"补充说明"，而是真正的行为验证。
竞品与对比
AI 编程代理的"规范化开发"赛道正在形成。目前有三个主要方案，各自切入角度不同。
📊 多维度对比
| 维度 | Superpowers | OpenSpec | Spec Kit |
|---|---|---|---|
| 核心理念 | 约束代理行为：通过 Skills 强制执行工程流程 | 规约即代码：Spec 文件作为项目真相源 | 结构化命令：标准化的 SDD 命令管道 |
| 工作方式 | 安装插件 → 自动触发 | 仓库内建 openspec/ 目录 + CLI |
按顺序执行 /specify → /plan → /implement |
| 设计阶段 | brainstorming Skill（交互式对话 → 设计文档） | 手动编写 Spec Deltas（增/改/删提案） | /specify + /clarify（结构化生成） |
| 规划阶段 | writing-plans Skill（自动拆分 TDD 原子任务） | tasks.md（手动编写任务清单） |
/plan + /tasks + /analyze |
| 执行阶段 | 子代理驱动 + 双重审查 + TDD | AI 按 proposal 执行，手动检查 | /implement（单步执行） |
| 自动化程度 | ★★★★★ | ★★★★★ | ★★★★★ |
| 质量保障 | ★★★★★ | ★★★★★ | ★★★★★ |
| 上手难度 | 低 — 装插件即可 | 中 — 需理解仓库结构约定 | 低 — 记住命令顺序即可 |
| 平台支持 | Cursor · Claude · Codex · Gemini CLI | 任意 AI 助手 + CLI | GitHub Copilot · Claude · Gemini CLI |
| 适用场景 | 端到端的工程化开发流程 | 需要 Spec 版本化和变更追踪的项目 | GitHub 生态下的规范化开发 |
🎯 三种方案的本质差异
Superpowers：约束代理行为
"装上 Skills，代理自动走专业工程流程。" — 关注点在代理怎么工作（TDD、审查、子代理）。是三者中自动化和质量保障最强的。
OpenSpec：管理项目规约
"把 Spec 放进仓库，用 CLI 校验和归档。" — 关注点在项目规约的版本化管理。适合需要长期维护产品规格文档的团队。
Spec Kit：标准化命令流
"按固定命令顺序走完 SDD 流程。" — 关注点在开发流程的标准化。GitHub 出品，与 Copilot 集成好。
它们可以互补
这三个工具并非严格互斥。例如你可以用 Superpowers 约束代理行为（TDD、审查、子代理驱动），同时用 OpenSpec 管理项目规约（Spec 版本化、变更归档）。它们分别解决不同层面的问题。
总结与思考
AI 编程的下一步：从"写好 Prompt"到"搭好脚手架"
🧠 AI 越来越强
模型能力快速提升
但"能做到"≠"会做好"
需要工程化约束
🏗️ 约束框架出现
Superpowers / Spec Kit
把专业实践变成强制流程
用工程方法驾驭 AI
🚀 真正的 AI 工程化
AI 代理长时间自主工作
输出质量被流程保障
人的角色：设计 + 审批
Superpowers 的价值不只是让 AI 写出更好的代码 — 它代表了一种思维转变：
不要试图写出完美的 Prompt，而是搭出好的工程化脚手架。
关键要点
最后的思考
- 当 AI 模型能力足够强时，约束 AI 的方式比指导 AI 的内容更重要
- Superpowers 证明了：好的工程实践可以被编码为可执行的 Skills，而不只是写在文档里的建议
- 这个思路适用于任何 AI 代理场景 — 不仅仅是编程