企业官网建设流程全解析

1. 为什么我决定在AI编程工作流里引入superpowers

最近用AI代码助手写业务逻辑写得飞起，但碰上一个有点oss复杂度重构需求时，我发现自己的效率卡住了：AI助手明明能看懂单段代码，却总在“全局视角”上翻车——改完一个模块就忘了前面定的接口约定，反复强调的项目结构它下次依然会问，更别说让它自己跑测试、自己纠正编译错误这种“多步闭环”了。跟几个同事聊，大家都有同感：AI写代码更像一个“记忆力很差的临时工”，不是能力不够，而是缺少一套标准流程和上下文记忆，导致每次都从零开始猜。

后来我在社区里看到有人提到一个叫superpowers的工具，定位是“给编程助手叠加超能力”的增强层。它不是要取代Codex、ChatGPT这类助手，而是把助手的单次对话能力升级成一套可持续运行的工作流：技能包、自动规划、状态记忆、权限控制，全部用一个命令行工具串联起来。用了一段时间之后，我发现这个工具确实是解决“AI老是半途而废”问题的靠谱方案，尤其适合那些想把AI真正接入到日常交付流程里的开发者。

这篇文章我不会只讲概念，而是把我自己的安装过程、接入Codex的方式、在Java项目里的实测结果，以及踩过的几个坑原原本本写出来。无论你是刚接触AI编程的新手，还是已经在用Codex但觉得“不够听话”的老手，按着文章里的步骤走一遍，应该都能很快让superpowers跑起来，并且做出一点真正能用的东西。先说明一点：superpowers不只支持某一家模型，你可以按需配置底层驱动，文章里我会以Codex为例，但思路完全通用。

2. superpowers到底做对了什么：定位与核心能力拆解

2.1 它不是一个“新AI”，而是一层“调度中枢”

很多人第一次听到superpowers，会误以为它是某个新的大模型。其实不是。它更像给AI助手套了一层“工作流操作系统”，核心单元是技能包（skill）。每个技能包就是一个带有明确目标、步骤、校验规则的Markdown文件，里面写清楚“当用户要求做什么时，助手应该按什么顺序执行、调用哪些命令、产出什么结果”。比如一个code-review.md技能，不是简单地把代码丢给AI让它“看看”，而是规定：

• 先读取项目 README 和目录结构；
• 再定位最近改动的文件列表；
• 针对每个文件检查潜在风险点；
• 最后输出一个带严重级别的审查报告。

这样AI的行为就从“自由发挥”变成了“照着SOP干活”，输出质量和稳定性自然大幅提升。

2.2 五个核心能力，解决“AI不听话”的根因

我归纳下来，superpowers能火起来主要靠这五件事：

这五件事单独拿出来都不算什么新技术，但合在一起之后，AI不再是一个“一次性对话”，而是一个有流程、有记忆、有边界的“半自动员工”。尤其状态记忆这招，让我最头痛的“上下文丢失”问题有了一个折中方案：真正长尾的项目上下文不用全塞给模型，而是持续写入一个本地文件，在需要时再按优先级抽取。

2.3 用一个生活化类比理解它的工作方式

你可以把普通AI助手想象成一位能力很强但不停“失忆”的实习生：你上午教他怎么处理缓存穿透，下午他就忘了。而superpowers相当于给他配了一本“操作手册+笔记本+审批流程”：操作手册里写明遇到各类任务的统一做法，笔记本里记录他已经做过的决定和待办事项，审批流程则规定他不能擅自执行高风险命令。这样一来，同样的能力，产出质量完全不一样。我第一次跑通一个“分析代码→生成测试→执行测试→修复→再测试”的完整循环时，说实话有点小激动，因为它终于把AI从“嘴炮选手”变成了“真正动手并且知道何时停下来问人”的搭档。

3. 安装superpowers：环境与最快落地路径

3.1 环境要求与两个坑先排掉

我自己是在Ubuntu上用的，同时也帮同事在macOS上装过。Windows用户建议先开WSL，因为后面积累的技能包大量使用了shell命令，直接在CMD或PowerShell里跑容易遇到路径转义的幺蛾子。基础依赖很简单：

• Node.js 18 或更高版本（我试过16，装的时候会直接报错）；
• Git（用于克隆和后续管理技能包）；
• 底层AI助手的CLI，比如Codex CLI，以及对应的API密钥；
• 45分钟左右的一个下午，别一上来就想着全部搞完，留出试错时间。

坑提前说：不要用系统自带的旧Node版本。我第一次安装时就是被老Node坑了，报错信息是ELIFECYCLE command failed，怎么重装都没用。把Node切到18 LTS之后，一分钟就装好了。所以第一步，先执行node -v确认版本。

3.2 两种安装方式，任选其一

方式A：通过npm全局安装（推荐，更新方便）

npm install -g @superpowers/cli

方式B：源码安装，适合想改源码或者不想全局污染的情况

git clone https://github.com/superpowers/superpowers.git cd superpowers npm install npm link

装完后验证一下：

superpowers --version

如果输出类似superpowers v2.1.0的信息，就说明核心安装成功。注意：如果提示command not found，多半是npm全局目录没加进PATH，Linux下常见的处理是手动把$(npm prefix -g)/bin加到.bashrc。

3.3 初始化项目和第一个技能包

安装只是第一步，真正让superpowers发挥作用的是初始化项目。在现有代码仓库根目录下执行：

superpowers init

它会自动创建一个.superpowers/目录，里面包含：

.superpowers/ ├── config.yaml # 主配置，模型、权限、工作流都在这 ├── skills/ # 技能包目录 ├── memory/ │ └── state.md # 状态记忆文件，初始为空 └── templates/ # 一些现成的技能模板

生成默认配置：

superpowers config generate

然后我们写第一个技能包，让AI扮演“代码审查员”：

cat > .superpowers/skills/code-review.md << 'EOF' --- name: code-review description: 对当前项目的最近改动进行代码审查 steps: - 读取 git diff 获取最近改动 - 根据项目 README 中声明的架构规范检查一致性 - 对每个改动文件提出风险点和改进建议 - 输出 Markdown 格式的审查报告 permissions: - git diff EOF

技能包写好后，直接运行：

superpowers run "对当前分支执行一次代码审查"

实测中，它会先调用底层模型解析你的请求，然后按照技能包里的步骤一步步执行，最终输出一份包含“严重/一般/提示”级别的审查报告。从安装到第一次产出结果，顺利的话半小时以内就能完成。

4. 把superpowers接到Codex上：配置细节与联动逻辑

4.1 为什么偏要接Codex

Codex是一个我很常用的AI编程CLI，它能够读取代码库、生成diff、直接改文件，对话体验非常顺畅。但它最大的短板是“每次会话都是新的”，不记得上次项目里定下的规则，也无法在内部编排跑测试、跑构建这类外部命令。这时候superpowers的价值就出来了：让它当Codex的“前端调度”，把技能包里的步骤拆好，再交给Codex去执行具体代码改动。

4.2 配置一个可用的superpowers与Codex联动

在.superpowers/config.yaml里，只需要三个核心配置块：指定后端、打开记忆、定义工作流。下面是一个我目前在用的精简配置：

backend: codex model: gpt-4o memory: true max_context_tokens: 25000 permissions: allow: - "git status" - "git diff" - "npm test" - "mvn test" deny: - "git checkout -- ." - "rm -rf" workflows: refactor-java: steps: - read: .superpowers/skills/java-concurrency.md - run: codex exec "按技能文件重构 {file}" - run: mvn test -Dtest=Test{module}

这里有几个容易踩的点，提前说清楚：

第一，不要随便把permissions.allow设成*。一旦AI执行了有破坏性的命令，比如git reset --hard，想恢复就麻烦了。我建议只放你日常确实会执行的命令，宁可多写几行白名单，也别贪图省事。

第二，{file}和{module}是superpowers自己的变量，会在运行时替换成具体值。如果你直接写成$(echo abc)，shell会先展开，容易产生命令注入。superpowers对这类写法有保护，但你自己写配置时也要养成习惯：所有需要外部传入的参数一律使用它提供的变量占位符，不要拼字符串。

第三，max_context_tokens要留一点余量。技能包内容加上项目文件有时会很长，设成25000的意思是不超过模型上下文的上限，但如果你的模型本身只支持32000，那就别压着极限跑，否则API请求会报错。

4.3 实际跑一次“跟Codex协作”的完整流程

配置好之后，我通常这样调用：

superpowers run "用 refactor-java 工作流重构 ClickService"

执行过程大致是这样的：

1. superpowers读取java-concurrency.md技能包，提取里面的关键要求；
2. superpowers把技能包内容、项目结构摘要、相关文件路径拼装成一条系统提示；
3. 调用Codex CLI，让Codex基于这条提示读取源码并生成修改后的diff；
4. superpowers把diff应用到工作区；
5. superpowers调用mvn test编译并跑测试；
6. 如果测试失败，superpowers会把报错日志回传给Codex，让它自动修复；
7. 全部通过后，superpowers输出一份改动摘要和测试报告。

第一次看到它自动完成“改代码→跑测试→修问题→再跑测试”这个循环时，我突然意识到，这就是之前手动复制粘贴AI代码再自己跑测试的那种流水线被自动化了。以前一波重构我要花一个多小时在“复制、粘贴、跑测试、手动修”上，现在只需要盯着它输出的日志，在它卡住时或者需要确认时介入即可。

5. Java项目里用superpowers实测：一段要并发重写的代码

5.1 背景：旧代码的“线程家族”混乱

我拿一个真实业务模块做测试。假设有一个老的OrderProcessor类，处理订单时会为每个订单手动new Thread(() -> ...).start()，不仅没有线程池，也没有超时控制，接口一压测就撑不住。目标是用CompletableFuture和ThreadPoolExecutor重写，同时保持对外接口签名不变，并且要保证原有单元测试全部通过。

这种重构看起来不难，但实际很容易翻车：如果只是让AI“把new Thread改成线程池”，它可能会顾头不顾尾，漏掉依赖Thread.isAlive()判断任务是否完成的逻辑。所以我先给superpowers写了一个专用的技能包java-concurrency.md，把重构步骤写死：

--- name: java-concurrency description: 把旧式Thread用法重构为CompletableFuture+线程池，保留对外语义 steps: - 扫描所有 new Thread(、Thread.sleep()、Thread.interrupt() 的使用点 - 分析每个调用点的同步语义（是否等待线程结束、是否被中断） - 定义线程池参数，核心线程数根据机器核数计算 - 用 CompletableFuture.runAsync + executor 替换，保留原接口 - 处理异常：任何异步任务必须设置 exceptionally 兜底 - 修改后先看单元测试，再跑全量测试 ---

5.2 运行过程和最终效果

执行命令：

superpowers run "用 java-concurrency 技能重构 OrderProcessor"

在实测中，superpowers按顺序执行了技能包里的步骤。最开始它只把new Thread换成了executor.execute，后来又根据Thread.sleep的使用点补齐了CompletableFuture.delayedExecutor相关调用。比较让我意外的是，它真的执行了mvn test，发现有个测试因为线程池里线程名称变化而断言失败（测试里用thread.getName()做了校验），于是它又自动调整了线程工厂里的线程名前缀，让测试通过。整个过程用时约四分钟，中间不需要我手动干预。

这个测试暴露了superpowers一个很实用的能力：它会主动保持测试绿。传统的AI对话模式里，你让AI改代码，它改完说“应该没问题”，但实际跑起来全是编译错误。而在superpowers的编排下，跑测试是被强制执行的一环，如果结果失败，它会收到反馈并继续修，直到通过。这一点在我接近一周的连续使用中，省下的时间非常可观。

线程池参数上，我当时在技能包里写的建议是：CPU密集型任务线程数设为最大可用处理器数 + 1，IO密集型则适当多给。如果你们机器是4核8线程，跑IO多的业务可以配corePoolSize=8, maxPoolSize=16, queueCapacity=100。这里不必照抄，最好结合压测结果调整，关键是让整个过程能自动化循环，改参数后重新跑测试。

5.3 权限拒绝的插曲：它停下了，而不是继续乱改

这次实测并非一直顺利。跑到一半，superpowers发现当前工作区有未提交的改动，它内部在某个步骤里尝试执行git checkout -- .来撤销某个文件的误改，但我在permissions.deny明确禁止了这条命令。结果是它没有强行执行，而是停下来提示我：“检测到工作区有未提交修改，不能自动回滚，是否需要我保留当前修改并继续？”，在终端里等我输入y还是n。

这个行为让我比较放心。很多时候AI工具可怕的地方在于，它会在你知道之前就把工作区搞得一团糟。superpowers这种“权限拦截+人工确认”的机制，虽然会打断流程，但这种打断是值得的。如果你们也要处理易碎的重构，我强烈建议把git checkout -- .、git clean -fd、rm -rf这类的破坏性命令全部加到deny列表里，宁可让它停下来问你，也不要让它替你“擦屁股”。

6. 用superpowers踩过的三个坑：版本、权限与上下文溢出

6.1 坑一：Node版本不兼容，安装直接失败

这是我遇到的第一个坑，也是最容易被新手忽略的。如果你机器上默认Node是16.x，执行npm install -g @superpowers/cli时大概率会报node: /usr/lib/node_modules/... ELIFECYCLE，问题不在依赖本身，而是新版superpowers用了Node 18+的API特性。解决方法是装一个版本管理工具，比如nvm，然后切到LTS版本：

nvm install 18 nvm use 18

切换后重新npm install -g @superpowers/cli，一次就通了。这个坑几乎不影响使用，但会浪费你半小时。

6.2 坑二：权限设计太松或太紧，都会出问题

权限这块我前后调整过三轮。第一轮我图省事，把allow设成*，结果AI在一个技能包运行过程中主动执行了git stash，把我没用完的改动给藏起来了，最后恢复时还丢了部分未保存内容。第二轮我把权限收得过紧，只允许git status，结果工作流里要跑测试却没有任何测试命令的权限，导致整个流程没法闭环。

现在的平衡做法是：按工作流实际需要最小化授权。比如只在需要重构Java的工作流里允许mvn test，其他地方不给。再配一个deny黑名单，把明显有破坏性的命令放进去。这样既能让大多数流程自动跑下去，也避免了AI“自由发挥”造成的不可控后果。

6.3 坑三：上下文溢出，记忆不是把所有东西都塞进去

superpowers自带状态记忆，但这不意味着它会把所有历史都一股脑塞给模型。我一开始不懂，把项目README、架构文档、模块清单全写在状态文件里，结果模型窗口直接不够用，调用时报maximum context length exceeded。后来我才搞清楚，superpowers的记忆文件更像“索引”而不是“正文”：它记录任务的进度、关键决策、待办事项，而不是保存完整代码。真正需要全量上下文的时候，应该由技能包显式地指向具体文件，让superpowers按需读取。

例如我在状态文件里会写：

- 正在重构 OrderProcessor - 已完成：线程池创建、CompletableFuture替换 - 待完成：观察最终调用方是否等待 Future 完成 - 决策：线程工厂命名 prefix 使用 "order-worker-"

而不是把OrderProcessor整个源码复制进去。这样既保持记忆，又不会撑爆上下文。如果你遇到“突然变笨了”或者“回答风格不对”的情况，先检查一下自己是不是往记忆文件里塞了太多无关内容。

6.4 附带提醒：规则式搜索很容易误伤

在Java并发重构里，AI如果使用全局正则把Thread替换成ExecutorService，肯定会把ThreadLocal、Thread.sleep这些也一并替换，引发连锁报错。我在技能包里加了一条约束：所有搜索关键词必须附带排除名单，比如ThreadLocal、ThreadFactory、ThreadPoolExecutor等，修改前先打印命中列表供人确认。这个小规则看起来很简单，却直接避免了一次大事故。建议你们在写任何重命名、替换类的技能包时，都加一句“禁止无差别替换，必须逐个评估上下文”。

7. 把superpowers从“玩具”变成“生产力”的五个进阶思路

7.1 思路一：把高频操作沉淀成技能包模板

最开始我喜欢临时写提示词，后来发现同一个“生成变更记录”“跑一轮代码扫描”“补充缺失的单元测试”需求反复出现。不如直接把它们都写成技能包，放到团队仓库里统一维护。这样每次需要时只需superpowers run skill-name，几分钟就能出一个标准结果。

7.2 思路二：跟CI/CD结合，自动生成PR摘要

我们目前已经接了一个比较简单的场景：在GitHub Actions里，push之后执行superpowers run "根据git diff生成change log"，然后把结果自动拼到PR描述中。实现起来不难，只需要在CI脚本里先安装superpowers和持久化配置，再调用一条命令。这个做法特别适合多人协作，避免每次PR都要按模板人工填写。

7.3 思路三：用状态记忆跨天恢复任务

状态记忆最实用的场景是“工作做到一半，明天继续”。以前我用AI助手，每次开新会话都要重新交代一次背景。现在收工前我让superpowers把当前脑子里的进度、下一步打算、需要注意的风险全部写进memory/state.md，第二天直接superpowers resume，它能根据记忆文件组织提示词，接着昨天的进度继续干活。虽然不是完全智能，但比从零开始省力太多。

7.4 思路四：按任务复杂度路由到不同模型

superpowers支持多后端配置。我现在给不同类型任务指定不同模型：简单的代码格式化、注释生成用成本低的小模型；需要多文件联动的重构用更强的模型；涉及安全审查的任务会调一个对安全问题特别敏感的模型。这个可以在配置文件里按workflows分别指定，省下不少API费用。你们如果用量大，值得研究一下这个功能。

7.5 思路五：让技能自动吸收仓库规范

最后分享一个细节技巧：我通常在项目文档里维护一份CONTRIBUTING.md约定代码风格和提交格式，再把它的路径放进superpowers的context配置里。这样任何一个技能包运行时，AI都会先读到这份规范，而不是靠我每次口头叮嘱。比如规定日志必须用SLF4J的占位符而非字符串拼接、禁止在循环里创建匿名内部类等等，这些项目本身的约束就能被持续贯彻。

我把这套配置跑了两个多星期，最大的感受是：superpowers并没有让AI“更聪明”，而是让AI“更有纪律、更有记忆、更有界限”。如果你现在的痛点不是AI写不出代码，而是它“写完了却不收尾”“换个会话就失忆”“偶尔干出危险操作”，那它大概率能帮上你的忙。拿一个下午装起来，先从一个最小的“code-review”技能包开始试，你会很快感受到区别。