最近我在重构自己日常使用的 AI 编程工作流时，越来越明显地感受到一个现象：AI 编程助手本身的能力已经不缺了，缺的是“约束”。就像给一个执行力超强但毫无章法的实习生配了个无限量的咖啡，你让他“写个登录模块”，他能给你产出代码，但过程往往是先写一堆接口、再补一堆样式、最后发现需求理解偏了，推倒重来。问题的根源不在于模型不够聪明，而在于我们给的“任务说明书”太简陋。所以就做了个叫 Superpowers 的尝试：把一套完整的开发方法论直接装进 AI 编程助手的提示词层，让它从“会写代码的工具”变成“懂项目节奏的协作者”。这篇文章就是这套思路的完整复盘，包含设计取舍、各阶段提示词模板、我踩过的坑和最终的运行节奏。

这套东西适合谁？如果你平时用各类 AI 编程插件、命令行助手、或者自己在封装工作流，受够了“AI 写一时爽，改 bug 火葬场”的循环，那这套方法论会对你有帮助。哪怕你只用 AI 写脚本，理解“先规划后编码”的结构，也能让你的产出稳定不少。

1. 整体设计：为什么 AI 编程助手急需一套开发方法论

1.1 传统“一句话需求”模式的问题

先回忆一下最常见的 AI 使用场景：打开对话框，输入“帮我把用户注册功能写了”，模型哗啦啦输出几百行代码。看起来效率爆炸，但仔细拆解会发现几个致命伤。

第一，需求是一团迷雾。用户注册功能包含什么？是邮箱注册还是手机号？需不需要验证码？密码强度要求是什么？要不要第三方登录？这些信息在毫无约束的一轮提示词里，基本全靠模型猜。第二，代码和上下文脱节。模型看到的是你当前打开的某个文件，它并不知道这个注册功能要接入哪个路由、用什么风格的代码组织方式、是否遵循团队的异常处理规范。第三，验证环节缺位。代码生成完，AI 不会主动告诉你“这段代码需要跑哪些测试才能确认可用”，更不会帮你设计测试用例。

一句话，为 AI 编程助手加上开发方法论，本质上是给它一个“做事的框架”。有了这个框架，模型的输出不再是一个拍脑袋的结果，而是一个有推理依据、有步骤、可检查的过程产物。

1.2 为什么“写个超级提示词”解决不了问题

大部分人遇到这个问题的第一反应，是写一个巨长无比的系统提示词，把“你要遵循软件开发最佳实践，先分析需求再写代码，最后做测试”统统塞进去。我试过，效果非常有限。

原因在于模型的注意力是会被稀释的。一个 3000 字的系统提示词，模型会平等对待其中的每一个字，但它真正在生成代码的那一刻，注意力结构会导致它更倾向于摘取与当前生成任务最直接相关的内容，而把“先分析需求再写代码”这种规范给弱化。这就好比你给员工发了一本厚达 200 页的员工手册，他读的时候觉得每一条都很重要，真到了处理具体问题的时候，他大概率只会根据常规习惯来行动。

所以 Superpowers 的核心思路是：方法论不藏在系统提示词里，而是变成一道一道具体的“工序指令”，在对话的关键节点由你或系统主动触发。

1.3 方法论需要“显性化”而不只是“存在”

另一个设计原则是方法的显性化。什么意思？当 AI 开始走一个流程的时候，它必须每一步都明确说出“我现在在做什么、下一步是什么、我期待你提供什么”。这样做的价值在于：第一，你随时可以纠偏。第二，模型自身的推理链路更为清晰——语言模型在显式“自言自语/结构化叙述”时的表现，普遍要优于闷头直接输出。第三，人和 AI 之间建立了一种分工协作的感觉，而不是一次性外包一个任务。

我最终形成了 Superpowers 的六阶段循环：需求澄清 → 任务规划 → 详细设计 → 编码实现 → 验证反馈 → 复盘记录。每个阶段都是一套独立的提示词模板，并且前一阶段的输出结果会成为后一阶段的输入上下文。

2. 核心架构：把方法论拆解成阶段化工作流

2.1 六阶段流水线的设计逻辑

在设计这套流水线时，我把真实团队协作中“口头约定俗成”的事情全部显性化了。先看整体流程表格：