企业官网建设流程全解析

1. 项目概述：superpowers 到底是个什么东西

最近在 AI 编程圈子里，superpowers这个词出现的频率高得吓人。不管是 Codex CLI、Claude Code 还是其他跑在终端里的 AI 编程代理，大家讨论的核心话题已经从“哪个模型更强”变成了“怎么让模型真正像个人一样工作”。而superpowers恰恰就是奔着解决这件事去的——它不是一个模型，也不是一个插件，它是一套完整的“提示工程工作流”，一个可以塞进终端代理里的系统化操作手册。

说白了，superpowers解决的是这么一个问题：默认状态下，AI 编程代理拿到一个任务，往往会急着开工，东改一行西改一列，最后交出来的代码能用但很脆，逻辑链也经常断。superpowers通过一系列精心设计的提示词文件，让代理在动手写代码之前先“想清楚”，把任务拆解、方案设计、实验验证、代码审查这些环节全部串起来，最终让 AI 从“一个会打字的工具”变成“一个有点职业素养的结对工程师”。

这套东西最早是从 GitHub 上一个叫superpowers的仓库火起来的，作者是一个长期折腾 Claude Code 和 Codex 的开发者。仓库里放的不是几百行插件源码，而是一堆 Markdown 提示文件，以及一个.superpowers配置目录。你把这些文件挂到代理的工作上下文中，代理就会自动进入一种新的工作模式：先规划，再执行，遇到不确定的环节会主动做实验，而不是硬着头皮猜。

我最初看到这套仓库的时候，心想“不就是几个 .md 文件吗，能有多大本事”。但实际接上 Codex CLI 之后，说实话，差别是能明显感知到的。默认的 Codex 像一个刚入职的实习生，你吩咐一句它动一下，问深了就开始含糊。挂上superpowers之后，它更像一个愿意先把需求聊透、再动手写第一个字符的工程师。所以这篇文章我打算从原理到实操，把superpowers怎么用、怎么配、以及我在真实项目里踩过的坑，一次讲清楚。

2. 底层逻辑拆解：为什么几个提示文件能改变 AI 的工作质量

2.1 核心思路：不是提高智商，而是改善工作方法

很多人刚接触superpowers的时候会有一个误解，以为它是在“给模型叠 buff”，让模型变得更聪明。实际上它完全不是这个路线。它做的事情更像是对一个聪明但毛躁的下属进行“入职培训”：你不需要改变他的智商，你只需要给他一套工作流程，告诉他“接到需求先干什么、再干什么、什么时候停下来确认、什么时候可以放手去写”。

用个生活化的类比来说，默认的 AI 编程代理就像一个挺有天分但没接受过系统训练的家政人员。你说“帮我收拾一下客厅”，他可能三分钟就把表面擦干净了，但抽屉里的东西没归位，数据线还是缠着的。superpowers的提示文件相当于一份“家政服务标准作业手册”，上面写着：先明确客厅范围，再按区域分类整理，贵重物品要单独确认，收拾完之后自查一遍。家政人员的智力没变，但工作成果的稳定度会高很多。

这套思路的载体是提示词，本质上是把软件工程里被验证过的工作方法，比如任务分解、思维草稿、实验验证、搞完自测，翻译成了模型能理解和遵循的语言。放在代理的上下文里，模型就会在它的推理路径中不断参考这些规则，而不是凭“本能”直接生成代码。这也是superpowers与普通system prompt最大的不同：它不是一段简单的“你要听话、你要专业”的说教，而是把一整套可操作的分支流程写进了提示文件里，模型遇到同类场景时，会沿着这套流程往下走。

2.2 提示文件的工作机制：它到底是怎么“接管”代理行为的

superpowers的目录里通常包含一组分层的 Markdown 文件，例如system_instructions.md、core_workflows/子目录、skills/子目录等。这些文件通过我们下面会讲的安装方式，被注入到 AI 代理的上下文（通常是AGENTS.md、CLAUDE.md或.superpowers/目录）中，代理在每次对话的开始就会自动把它们加载进去。

但这里有一个关键机制：这些文件不是一次性读完就完事。superpowers的设计中大量使用了“流程分支”式的提示写法。举个例子，当代理收到一个任务时，提示文件会告诉它“先判断这是小型任务还是大型任务；小型任务可以直接执行，大型任务必须进入任务规划流程”。模型本身就有很强的指令跟随能力，一旦在上下文里看到这种带条件和分支的提示，它的输出就会呈现出明显的阶段性：先做判断，再走对应子流程。这就是为什么挂载前后，同一个模型的回答风格会有那么大的变化。

值得注意的是，superpowers并不是一个“银弹”。它的效果高度依赖底层模型的指令跟随能力。我跟几个同行交流下来的共同感受是，在 Codex CLI 里接的是较新版本的模型，指令跟随能力本身就比较强，挂上superpowers之后属于如虎添翼；如果是很弱的模型，可能连“先规划再执行”这个指令都执行得七零八落，效果会大打折扣。所以，想用好superpowers，建议先保证你的 Codex/Claude Code 用的是当前可用的较强模型。

2.3 为什么选择“提示”而不是“插件”

还有一个很实际的问题：为什么superpowers要选择提示词这种看似原始的方式，而不是做成一个插件或者 Agent SDK？我个人的理解是，这恰恰是它生命力强的原因。因为提示词是可读的文本，你随时可以打开文件看看它到底给模型灌了什么“迷魂汤”，不满意就自己改。相比之下，插件和 SDK 是编译进工具链里的黑盒，出了问题你只能等作者更新。

另外提示词几乎不依赖工具版本。Codex CLI 更新一次，某些插件 API 可能就废了，但 Markdown 提示文件永远通用。你只需要把文件放到正确的位置，让代理能够读到，它就能工作。这种“零依赖”特性，让superpowers兼容了 Codex CLI、Claude Code、甚至一些自研的终端代理框架。

3. 安装与接入：把 superpowers 配到 Codex 环境里

3.1 准备工作与环境要求

在正式开始安装之前，先确认一下你的电脑上是否满足下面的条件。superpowers本身不需要安装什么运行时，它只是文本文件，所以硬性要求不多，但下面的前置条件决定了你后面能不能跑得起来：

• 一个能在终端里运行的 AI 编程代理，比如 Codex CLI 或 Claude Code，且已经完成登录认证。
• 一个你自己创建的存放配置的目录结构，推荐使用~/.superpowers作为全局目录，项目内再单独叠加。
• 基本的 Git 操作能力，因为从仓库克隆文件是最快的安装方式。

我在安装的时候遇到过最尴尬的问题就是目录结构搞错。superpowers官方的安装方式是把仓库克隆到本地，然后将其中的核心配置软链或者复制到你的代理配置目录。如果你用的是 Codex CLI，通常需要关心的是AGENTS.md的生效范围；如果是 Claude Code，对应的则是CLAUDE.md。务必先搞清楚你的代理读哪个文件，再动手。

3.2 安装步骤详解

下面给你一个我在 Ubuntu 和 macOS 上都实测可行的流程。以全局安装为例，这样你在任何目录下启动代理，它都能自动加载superpowers的全局指令。

第一步，克隆仓库到本地：

git clone https://github.com/your-reference/superpowers.git ~/.superpowers

注意，这里的仓库地址需要根据你实际找到的仓库替换。由于生态更新很快，我建议你在 GitHub 上搜索superpowers相关仓库时，优先看最近一个月内有 commit 记录的项目，避免装了一个早已停止维护的版本。

第二步，创建代理的全局配置文件入口。以 Codex CLI 为例，它会在你的用户目录下查找AGENTS.md（如果没有就创建它）：

touch ~/.AGENTS.md

然后在这个文件中写一行引用，让代理知道要去~/.superpowers里加载详细规则：

# Global Instructions 加载位于 `~/.superpowers/SYSTEM_INSTRUCTIONS.md` 的全部提示内容，并严格按照其中的工作流程执行任务。

这一行的作用，是在不把几百行提示直接塞进AGENTS.md的前提下，把规则文件的“入口”告诉代理。模型读到AGENTS.md后，会顺着路径去读取实际的提示文件，相当于给代理指了一条“去这里看工作手册”的路。

第三步，检查项目级的配置覆盖。如果你的某个项目有特殊要求，不希望全局规则生效，可以在项目根目录创建或者修改AGENTS.md，覆盖全局配置。注意，项目级配置的优先级要高于全局级，否则会出现你不想看到的行为。

3.3 配置内容的核心推荐

装好之后，下一步是调整里面的核心参数。superpowers的主配置文件中通常会涉及两大部分：一是工作流开关，二是技能集大小。对于大多数项目，我建议先不要贪多，把下面这组配置跑通再说：

• 开启“任务拆解与规划”：让代理在接到复杂任务时，先输出拆解步骤再动手。
• 开启“实验验证模式”：当代理对某个技术方案不确定时，允许它先写小段代码做验证，而不是直接猜。
• 保持“代码审查流程”开启：收尾阶段强制代理自查变更，寻找潜在 bug。
• 技能集控制在 3~5 个核心技能上，不要一次性加载全部技能文件，否则上下文会被撑爆，反而影响回答质量。

配置完成之后，实际验证一下。先在一个临时目录里，启动 Codex CLI，对它说“帮我写一个 Python 函数，计算列表里出现频率最高的元素”，观察它是否按照superpowers的流程先给出方案、再开始编码。如果它还是一上来就直接给代码，多半是配置没有被正确加载，这时候就要检查刚才的路径引用是不是写错了。

4. 核心能力与应用场景：superpowers 能派上用场的典型时刻

4.1 大型任务自动拆解，告别“一次写完”

superpowers最让我欣赏的一点，就是它对大型任务的拆解能力。默认状态下我让 Codex 写一个完整的 REST API，它可能攒一坨就全吐出来，看起来完整，实际上错误率很高。挂上superpowers后，它会先把任务拆成几个里程碑：设计数据模型、搭建项目骨架、实现接口逻辑、补测试、跑冒烟验证。每一步完成之后还会停下来让我确认，而不是闷头做下去。

这里面的核心在于“工作流提示”写得足够细。它教会模型把“大目标”翻译成“一系列可验证的小目标”。我实际体验下来，这种感觉很像是带了一个凡事都会跟你对齐的副驾驶，虽然多花了一点时间在“对齐”上，但返工率大幅下降，总体项目耗时反而更短。

4.2 代码实验与自动验证：不猜了，直接跑一下

在编码类 AI 工具里，最常见的翻车模式就是“一本正经地编 API”。模型凭着训练记忆，写出了一个并不存在于当前版本库里的函数，你还一时分辨不出来。superpowers的工作流里专门设计了“实验与验证”环节，它鼓励代理在不确定的情况下，主动生成一个小型的验证脚本，在本地环境实际执行一次，再基于结果来决定下一步。

举一个我遇到过的真实场景。有一回，我在一个 Java 项目里让 Codex 对接一个内部消息队列客户端库。这个库比较小众，模型显然不太熟悉它的 API。没挂superpowers之前，它直接照着记忆里的伪代码开始写，写出来的东西编译都过不了。挂载之后，它先写了一个 20 行的最小验证类，编译运行，报错，再根据报错调整 API 调用方式，几轮下来就找到了正确的用法。

这种“用真实反馈代替猜测”的做法，正是superpowers提示体系里最有价值的部分。它利用的其实是模型本身具备的“能用工具就绝不空想”的能力，只不过通过提示把它固化成了流程。如果你想把这个能力发挥到极致，建议在提示文件中明确告诉代理“永远在提交代码之前，运行相关测试命令”。

4.3 在 Java 项目中的实际应用技巧

很多人搜索superpowers java，想知道这套提示工程在 Java 这种重工程化语言里效果如何。我的经验是，Java 项目恰恰是superpowers最能发挥优势的场景。原因很简单：Java 项目往往结构复杂、依赖多、编译时间长，盲目地“写完再改”代价非常高。而superpowers的流程强迫模型先理清模块边界、再动手写实现，这跟 Java 开发者的日常工作习惯天然吻合。

在 Java 项目里，我建议给superpowers额外叠加一条规则：所有新增代码必须给出对应的单元测试骨架。这听起来会增加工作量，但实际效果是，模型为了写出能过编译的测试，会更加谨慎地处理类型、接口和依赖关系，产出质量提升非常明显。我自己在一个 Spring Boot 项目里试过这个配置，代码评审时被挑出的问题数量肉眼可见地减少了。

5. 实操过程全记录：让 superpowers 跑完一个真实功能

纸上谈兵讲了半天，这节我完整走一遍使用superpowers让 Codex CLI 开发一个小功能的流程。为了便于演示，我选一个不太复杂但有代表性的任务：“给一个 Python CLI 工具增加--verbose参数，用于输出调试日志”。

第一步，启动 Codex CLI，给出需求描述。我会故意把需求说得比较模糊，看看它是否懂得提问：

帮我给现有的 cli.py 增加一个 verbose 参数，用来调试。

挂载了superpowers之后，它没有直接改代码，而是先问了我两个问题：--verbose应该作为全局参数，还是某个子命令的参数？调试日志需要输出到标准输出还是文件？这两个问题完全切中要害，避免了我后来改来改去。

第二步，它给出了改造方案：在cli.py的入口解析处增加一个布尔参数，设置logging的级别，并在关键代码路径上补充logger.debug()调用。方案里还明确标注了“此步骤只实现参数解析，不修改业务逻辑”的边界，这是superpowers工作流中“小步提交”的体现。

第三步，模型开始写代码。我注意到它的会话里出现了阶段性的信息：先记录当前任务状态为“已规划”，再进入“实现中”，最后标注“进入验证阶段”。这其实是提示文件引导模型把自己内部的思考过程以结构化的方式呈现，等于把它的“心算草稿纸”摊开给我看，这对我判断它是否走偏很有帮助。

第四步，它主动运行了测试：

python -m pytest tests/ -q

测试全绿之后，它额外手动跑了一次带--verbose的命令，确认日志真的能打出来，才把最终 diff 展示给我。整个流程下来，我的主要工作就是回答最初那两个问题，其他都是它自己一步步完成的。这种体验跟我之前使用未挂载superpowers的 Codex 相比，最大区别就是“靠谱感”强了很多。

这个实操过程也让我意识到，superpowers的价值不只在于“代码写得对不对”，更在于它塑造了一种“负责任的完成”模式。它让模型把“写完”和“完成”分得很清楚——写完只是开始，验证通过才算完成。

6. 常见问题与避坑速查：装在真实环境里会遇到哪些坎

6.1 为什么挂载之后代理反而变得“胆小”了

很多人安装完superpowers之后，第一个感觉是“这货怎么不如默认模式爽快了”。默认的 Codex 你让它改个什么，它啪一下就改完了；挂上superpowers，它开始问你问题、列计划、要你确认。如果你只是想要一个快速的“改一行文字”工具，这种体验确实是变差了。

解决办法其实很简单：在需求描述里明确加上“这是小型琐碎任务，不需要完整规划流程”。superpowers的提示文件中本身就设计了“小任务直接执行”的快捷分支，你需要做的是把这种指令写到上下文里，让模型按轻量模式处理。比如你可以附加一句“这是简单任务，请跳过规划阶段直接实现”，它的响应速度就会回到原来的水平。

6.2 上下文窗口被提示文件塞满怎么办

这是我觉得最值得警惕的问题。superpowers的完整提示文件非常多，如果一股脑全接入，很容易占据大量的上下文窗口，导致模型真正处理项目代码的空间变小，表现为“记不住前面的文件内容”或者“答非所问”。我见过最夸张的一次，是把全部技能文件都挂到上下文里，还没开始干活，上下文就烧掉了三分之一。

避坑的方法是“按需加载”。在AGENTS.md入口文件中，只加载核心工作流指令，例如system_instructions.md和core_workflows/下的主流程文件。skills/目录下的技能文件，等真正要处理对应任务时，再通过指令动态引入。这样既保留了superpowers的方法论，又不会让上下文过载。

6.3 版本更新导致行为漂移

superpowers是纯文本提示，底层模型一更新，同样的提示文件可能会产生不同的表现。我在一次模型版本升级后发现，代理突然变得特别爱“反思”，每写一行代码都要自我评价几句，输出变得冗长，但又没实际增加多少有效动作。查询之后发现社区里不少人也遇到了类似情况，这属于提示工程中典型的“行为漂移”现象。

我的处理方式是：给提示文件加一个“输出简洁性”约束，明确要求模型在规划阶段使用简短的要点式记录，不要长篇大论地解释每一个步骤。如果你也遇到这种问题，可以在提示文件里找response style相关的配置，把它调成“简洁、要点式输出”，基本上就能把行为拉回正常轨道。

6.4 常见问题速查表

7. 经验漫谈：我只推荐三类人来用 superpowers

最后说点个人层面的感受。用superpowers这段时间，我的体会是它并不适合所有人。如果你平时只是让 AI 帮你补一两个函数、问问报错含义，那你完全不需要装它，默认的 Codex 就已经足够。但如果你是下面这几类人，我会强烈建议你认真研究一下这套提示工程：

第一类是“重构型”开发者。你的工作不是从零写新代码，而是不断修改别人留下的老代码，这种场景最需要“先想清楚再动手”，因为每次误改都可能引发连锁问题。superpowers的规划和验证流程能帮你把这种工作方式固化下来。

第二类是“AI 重度使用者”。你已经在用 AI 写大量代码，但经常发现它写的东西“看起来对、跑起来错”。这其实是缺少验证环节的表现，而superpowers的核心价值就是把“验证”两个字深深地刻进模型的行为模式里。

第三类是“提示工程爱好者”。如果你对“为什么同样一个模型，换一套提示词之后表现差这么多”这件事本身感兴趣，那superpowers是一个很棒的学习样本。它能让你看到一套结构化的提示体系如何一步步控制模型的行为，比看十篇提示词技巧文章都直观。

如果你不属于这三类人，也完全不用担心，等哪天你真的被默认代理的“莽撞”气到想砸键盘了，再回来装superpowers也不迟。工具摆在那里，学会了就是你的，什么时候想用，都是顺手的事。