企业官网建设流程全解析

我一直觉得，用AI写代码这件事，最大的问题不是AI不够聪明，而是它没有一套稳定的“工作方法”。你丢给它一个含糊的需求，它给你一个激情四射但很可能跑不起来的方案，你问它一个bug，它能给你列出五种可能原因然后让你自己猜。这就好比请了一个能力很强但毫无章法的新员工，干起活来全凭灵感和运气。

“superpowers”这个项目，本质上就是冲着这个问题去的。它不是某个具体的AI工具，而是一套为编程AI助手设计的提示词增强框架。它通过预置的结构化工作流、细分的技能指令以及一套可落地的协作协议，把“AI结对程序员”从一句口号变成了可以执行的流程。无论你用的是Claude Code这类集成终端工具，还是试图在Codex、Java项目里复现同样的协作体验，这套框架都能提供一套现成的“职业素养”。这篇文章，我就把我实际使用和折腾这套框架的经验拆开来讲，包括它的核心设计逻辑、安装配置、各个技能的适用场景，以及我在不同环境下踩过的坑。

1. 先搞清楚“superpowers”到底在解决什么问题

1.1 从“对话式编程”到“流程化编程”的思维转变

大多数人和AI协作的默认方式，是“对话”。你说一句，它写一段，你再提修改意见，它再改。这种方式在处理小片段、一次性脚本的时候没问题，但一旦进入真实项目，它的短板就暴露无遗。最突出的问题是上下文失焦——你和AI东拉西扯聊了二十轮，它可能早就忘了最初的项目约束；其次是缺乏验证闭环，AI经常“自信地”写出看起来合理但一跑就报错的代码，因为它没有被要求去验证自己的假设。

superpowers的核心思路，是把“对话”拆解成“阶段”。它把一段完整的开发任务切分成几个明确的仪式化步骤：先头脑风暴理清需求，再制定计划，然后才进入执行，执行之后强制做测试和调试，最后做代码审查和文档沉淀。每个步骤都有对应的预编译技能包，AI在接收到某个技能指令后，会按照预设的提示词框架来组织自己的思考过程，而不是想到哪儿算哪儿。

这里有个很关键的认知：这套框架做的不是“增强AI的知识”，而是“增强AI的工作习惯”。它不教AI写代码，它教AI怎么像个成熟的工程师一样，先思考、再动手、边做边验证。对我这种管理过多个项目、被AI队友坑过很多次的人来说，这个思路正中要害。

1.2 它与普通“提示词优化”的本质区别

市面上绝大多数的提示词优化，是教你写一个更详细、更具体的prompt，比如“请用Python写一个带重试机制的HTTP客户端，超时设置为10秒”。这种优化提高的是单次对话的质量。superpowers做的则是更高一层的事情：它把一系列prompt组织成了有依赖关系的流水线，并且让这些流水线可以被复用、被组合。

举个例子，单独的“请写一个函数”是一条指令；但superpowers的/plan技能会先要求AI理解任务背景、列出设计选项、评估权衡，然后才输出实施步骤。/execute技能又会要求AI拆分子任务、逐个实现、并在每个子任务完成后做验证。你看到的不是一个prompt，而是一整套“如何正确完成工作”的SOP。这种思维可以从任何AI工具延伸到真实团队管理中，本质上是一样的。

2. 安装与初始化：把“超能力”装进你的AI助手

2.1 前置条件与安装流程梳理

这个项目本身不依赖任何特殊的运行时，它的核心资产是一堆结构化的Markdown提示词文件，外加一些负责逻辑编排的脚本。安装的最终目的，是让你的AI工具（比如Claude Code或Codex CLI）在启动时能“看到”这些技能定义，并且在合适的时机调用它们。

以我在macOS环境下的操作为例，标准的快速安装方式是借助项目提供的初始化脚本，把superpowers的核心文件复制到AI工具的配置目录中，同时生成一个入口配置文件（比如CLAUDE.md），让AI在每次对话启动时都知道自己拥有哪些技能、遵循哪些工作协议。Linux的操作大同小异，Windows下如果遇到路径问题，也可以手动完成同样的复制动作。

我在实际安装时，更喜欢手动走一遍流程，因为能清楚地看到每个文件的位置和作用。核心步骤是这样的：

• 第一步：获取项目文件，可以通过git clone把仓库拉取到本地，或者直接下载发布包的压缩包。
• 第二步：找到你所用AI工具的配置目录。以Claude Code为例，一般在用户主目录下的.claude目录中，你需要把项目里的skills文件夹内容合并进对应的skills子目录，把核心的CLAUDE.md（或同名入口文件）放进全局配置根目录。
• 第三步：重新打开AI工具的会话，用/help或直接输入/查看命令列表，确认brainstorm、plan、execute、debug等技能命令已经存在。
• 第四步：做一个最小验证。随便输入/plan并附上一个简单的任务，比如“写一个读取CSV文件的Python脚本”，看AI是否按照规划流程响应，而不是直接甩代码。

这个过程里最容易出问题的有三个点：一是目录找错，尤其在不同工具链中配置文件的位置差异很大；二是版本不匹配，AI工具一旦更新，命令前缀或配置格式可能微调，导致旧版技能文件失效；三是最容易忽略的——你需要在项目里也放一份项目级的CLAUDE.md，否则AI在一个具体仓库里工作时，可能依然感知不到全局技能的存在。

2.2 配置文件中那些值得手动调整的参数

安装完成只是第一步，直接进入实战你会发现有些技能的执行效果不够理想，原因在于默认配置是“通用型”的，没有和你的项目语境绑定。我自己会把配置文件拆成几个区域来手工打磨。

• 技能启用列表：并不是每个技能在任何项目中都用得上，比如一个纯前端项目短期内用不到复杂的多语言调试技能，注释掉不需要的条目可以减少AI每次启动时的上下文噪音。
• 工具调用偏好：有些技能被执行时，AI会选择调用外部工具。如果你希望某项操作只用项目内置的脚本而不要引入额外的CLI，就得在偏好设置中显式声明。
• 信息收集深度：默认的头脑风暴环节会要求AI追问大量背景信息，在项目早期很好用，但如果你只是想让AI快速生成一个原型，可以把追问轮数调低。

这些调整看起来都是小事，但决定了这套框架能否真正融入你的日常工作流，而不是变成一个每次都要被跳过、最终被遗忘的仪式。

3. 六大核心技能拆解与实操要点

3.1/brainstorm：让AI从“给出答案”变成“理清问题”

这个技能是整套框架的入口，也是我最喜欢的一个。它的目标是强迫AI在整个编码过程开始之前，先做需求澄清。调用/brainstorm后，AI不会直接给你代码，而是会围绕项目目标展开提问，比如“这个功能的成功标准是什么”“有哪些现有的约束条件”“你希望我考虑哪些技术路线”。

在实操层面，这个技能特别适合处理那种你自己都还没想清楚的需求。我试过用它来帮助梳理一个数据同步模块的设计思路，AI在一轮交互里抛出了若干关键问题，有几个甚至问到了我此前忽略的边界情况。这个技能的价值在于，它把你的角色从“提出需求的人”变成了“回答问题的人”，而回答问题的过程本身就是对需求的二次澄清。

需要注意的一点是，不要让头脑风暴变成无限追问。通常三轮以内就应该收敛出结论。如果AI一直在纠结细节，很可能是因为你在问题里写了一个范围过大的目标，这时候需要手动把它拆小，比如“不要想整个系统，聚焦在数据库层的同步逻辑”。

3.2/plan：从需求到可执行方案的“翻译官”

拿到需求之后，下一步就是制定计划。/plan技能做的事情，是要求AI输出一份结构化的实施方案，包含背景理解、技术选型理由、里程碑拆分、潜在风险点和测试策略。它的核心任务是确保任何参与这个项目的人（包括AI自己），在动手写第一行代码之前，对全局有清晰的认知。

在实际使用中，我发现/plan输出质量高度依赖任务颗粒度。如果你让它规划“重构整个后端”，它给出的一定是抽象的空话。但如果你把范围缩小到“重构用户认证模块，使JWT的续期逻辑更健壮”，它就能列出非常具体的执行动作和验收标准。我在项目中，习惯把/plan输出的内容直接粘贴到一个设计文档里，作为后续开发和评审的基准，相当于让AI免费当了一次方案评审员。

这里有一个值得分享的经验：计划中发现AI提出了多个技术选型选项时，不要急于让它二选一。可以先追问每个选项的权衡条件，让它基于当前项目上下文给出推荐。这个追问的过程，往往比计划本身更能体现框架的价值。

3.3/execute：把计划落成代码，并时刻紧盯验证循环

计划终归是计划，真正干活的是/execute。这个技能要求AI严格按照既定计划开始编码，并且特别强调“小步快跑”的执行方式，每完成一个子任务就停下来做验证，而不是一口气生成一整个模块后才汇报，那样出错时排错成本非常高。

我用这个技能跑过一个真实需求：把一套旧的配置文件格式转换为新格式，涉及多个字段的重命名和数据清洗。通过/execute，AI把整个转换逻辑拆成了“加载旧格式”“字段映射”“清洗规则”“输出校验”四个子任务，每个子任务完成后都执行一条命令来验证中间产物。最终集成时出错少了很多，因为问题都在子任务阶段被提前暴露了。

如果你是首次接触这个技能，会容易把它和“普通编码prompt”搞混。区别在于，普通prompt只关注结果，而/execute还关注过程。它会在执行前明确拆解步骤，执行中持续汇报进度，执行后主动补充测试。能看到AI有条不紊地一步步做事，体验确实不同于以往。

3.4/debug：从“症状”反推“根因”的排查方法论

代码跑挂了，绝大多数人（包括AI）的第一反应是盯着错误堆栈看，然后尝试“猜”修复方案。/debug技能试图打破这种条件反射，它要求AI先建立“可复现的最小场景”，再做“二分定位”，最后才提出修复策略。

一个在我实际项目中反复出现的使用场景是这样的：线上反馈某接口偶发超时，但是本地跑一直没有触发。如果直接把日志抛给AI，它大概率会给出“可能是网络抖动”的万能答案。但使用/debug技能后，AI会先分析日志中异常数据出现的特征，然后提出一个与现场环境匹配的模拟方案，再一步步缩小排查范围，最后定位到是特定中间件版本下的连接池参数问题。这个排查链路，本质上就是资深工程师的排障思路，而框架的作用是把它固定成了可重复执行的流程。

使用/debug时最大的坑是：不要提供过滤过度的信息。很多人贴日志时习惯只贴最后几行，但真正有价值的往往是日志中容易被忽略的中间状态。最好让AI看到完整的上下文，它会自己判断哪些是噪音。如果你担心信息量太大，可以先让AI做一轮“信息收集”，明确它还需要哪些数据，再补齐。

3.5/review：让AI化身不留情面的Code Reviewer

代码写完了、跑通了，就算是完成了吗？这个技能给出的答案是否定的。/review会把AI切换到“代码审查者”角色，让它以挑剔的眼光检查刚写完的代码，关注点包括是否有隐藏的边界条件、是否有明显性能问题、错误处理是否完善、是否遵循了项目既有的代码风格。

实际操作中，我发现/review特别适合用来排查“自己写的代码中看不出问题”的盲区。AI不会因为代码是你写的就客套留情面。我组织过一次团队内部的练习赛，把一个功能模块的代码分派给AI做审查，它找出了三处真实潜在问题：一处是异常被吞掉导致状态无法感知，一处是批量处理时内存占用可能过高，一处是日志信息过于冗余。这些发现问题在后续手动检查中都被证实为有效。

/review输出的内容通常是分级列的，有严重、中等等级别。不要只看严重级就结束，因为中等和轻微问题往往代表着代码演进过程中的潜在债项，尽早修掉比未来某天集中爆发的成本低得多。

3.6/document：写文档这件事，终于可以交给AI了

最后这个技能让不少人意外，因为“写文档”听上去不够酷。但恰恰是这样看似轻松的环节，在实际开发中被忽略得最多。/document技能的作用是，基于当前代码和上下文，自动生成结构化的说明文档，包括模块说明、设计决策记录、使用示例等。

我用它来维护过一个内部工具包的README。AI遍历了工具包的目录结构、核心函数的签名和注释，自动组织出一个带有快速上手和数据表字段说明的文档框架。我只需要做很小的微调，就拿到了可以对外发布的文档。这件事如果让我手动去做，可能需要半小时以上的时间。

在使用这个技能时，我建议你对“文档的读者”做一点预设。如果文档面向其他开发者，可以在指令里明确要求补充代码示例和API说明；如果面向使用者，则应该更侧重使用流程和常用场景。/document最大的局限在于，它只会基于现状写文档，不会“预测”功能，所以务必保证它在代码跑通之后使用，否则文档里就会写进一些半成品状态。

4. 在Codex环境与Java项目中的适配经验

4.1 Codex与superpowers的集成方式

随着热词里出现“codex superpowers”，越来越多的人开始关注这套框架与Codex CLI的配合。Codex的优势在于它几乎零配置即可运行，尤其在处理一些自动化脚本时，开箱即可用。但它的劣势也很明显：默认情况下，它对复杂工程任务的处理容易“浅尝辄止”，缺少多轮推演和验证闭环。

把superpowers的逻辑移植到Codex环境，本质上是做“思维嫁接”。一种可行的做法是，把项目的CLAUDE.md和skills目录中的技能定义文件复制到Codex项目对应的配置目录，并在Codex的启动指令中，显式注入一条“你是拥有完整工作流技能的高级开发助手”的引导。之后，你在Codex中输入“/plan”或“/execute”时，它就能按照superpowers定义的流程来回应。

由于Codex和Claude Code在提示词解析细节上有细微差异，直接照搬的文件有时会失效。我遇到的典型情况是，某些命令中花括号包裹的变量在Codex的解析器里没有按照预期替换。解决方案是逐条测试技能命令，并把报错信息反向喂给AI，让它自行修复格式错误。这个过程不复杂，但需要一点耐心。

更根本地说，如果你的核心诉求是“让Codex按superpowers的方式思考”，其实不一定需要完整迁移所有技能文件。你可以把superpowers的核心工作协议（比如先规划后执行、小步验证、测试驱动）写成一条精炼的system prompt，附加到Codex的启动指令里，效果也非常好。

4.2 Java场景下的关键配置建议

“superpowers java”之所以能成为一个热搜词，说明很多人在Java这类偏重量级的语言项目里更需要这种结构化工作流，毕竟Java项目的上下文往往比脚本语言大得多，AI更需要在多个类、多个模块之间保持全局视角。

在Java项目中引入superpowers，我会特别关注几个配置点。首先是构建工具的识别，确保AI在执行任务时能准确使用Maven或Gradle命令；其次是测试框架的绑定，Java项目的验证环节高度依赖JUnit或TestNG，/execute的技能描述中要显式指定运行哪个测试类，否则AI会空跑或直接跳过验证；最后是包结构的维护，Java代码的文件组织规范性极强，/review会重点检查是否有合理分层、是否避免了循环依赖。

我实践过一个小型Spring Boot功能扩展，类似地引入superpowers的/plan和/execute。AI在制定计划时，会基于现有的Controller-Service-Repository三层结构设计新接口的落点和依赖注入方式；执行阶段能主动识别新旧代码之间的关系，并通过集成测试验证接口连通性，这种“带着项目上下文工作”的状态，和脱离上下文直接生成代码相比，完全是两个体验层次。

5. 常见问题与排查技巧实录

5.1 装了技能文件却看不到命令响应

这是我在社区里看到的最多问题，我自己最初也遇到过。装了文件、重启了会话，但输入/plan时AI完全无动于衷，仿佛不认识这个命令。问题根源通常不在文件缺失，而在于你的AI工具启动时，读取的不是你以为的那个配置来源。

排查思路很简单。第一步，确认技能文件的安装路径是否在工具实际扫描的目录中，很多工具有优先级覆盖逻辑，项目级配置会覆盖全局配置，仔细检查项目根目录是否有一个旧版本的配置“遮蔽”了全局配置。第二步，检查配置文件的格式是否符合当前工具版本的解析规范，尤其注意YAML的缩进、命令定义的位置。第三步，用工具的调试模式查看启动时加载了哪些文件，把所有不确定的地方一次性看清楚，比起反复盲试更高效。

如果三步走完还是不行，一个保底方案是：直接在项目根目录下的配置文件中，显式include超级技能目录。这种做法虽然不够优雅，但能确保AI确实读到。

5.2 技能执行时出现“角色混乱”

一种让我很无语的情况是，AI明明在按计划执行，但中途忽然忘记了“当前处于执行阶段”，开始对你的计划指手画脚。它可能突然建议“我认为这个方案需要重新设计”。这不是框架失效了，而是因为上下文太长，AI在长对话中丢失了最初的指令定位。

解决办法可以从两方面入手。一是把大任务拆成多次会话，每次会话只专注一个阶段，比如先用一轮会话完成/plan，拿到计划后，新开一轮会话粘贴计划再执行/execute，避免同一段上下文承载过多内容。二是在技能调用时，用更短的引导语强化当前阶段，比如在/execute命令里总是附上“严格按计划执行，不要重新设计架构”，减少AI自作主张的空间。

5.3 跨工具迁移时的格式兼容性问题

superpowers本身不绑定某个AI工具，但不同工具对提示词的解析和敏感度确实有差异。同一个技能定义在Claude Code下运行良好，迁到Codex或自建代理环境中，可能输出风格明显不同。

我的实践建议是：不要追求“一份配置文件走天下”。做一个基础版的技能描述，包含核心工作协议和关键验证节点，在所有工具间保持一致；进阶版的技能描述，比如特定的工具调用方式，则需要针对不同工具的语法规则做定制。更务实的一种做法是，把superpowers当成一份“工作流方法论”来参考，而不是当作“代码插件”来依赖。借它的思想来设计自己项目的AI协作协议，往往是后期体验最好的阶段。

6. 经验和心得：让这套框架真正为你所用

6.1 核心在于“尊重流程”，而不是“迷信工具”

这套框架带给我的最大收获，不是安装了脚本之后的效率提升，而是让我重新理解了AI协作中的流程价值。AI在自动化重复劳动上的能力毋庸置疑，但如果缺少流程约束，它的输出往往不够稳定。流程强制AI在每个阶段做正确的事，客观上减少了我事后返工的次数。

在实际运用中，维护好每一轮的“计划”文档、保留好每次/debug的输出记录，效果甚至会超出技能本身，因为历史方案在新一轮任务中可以被复用来回答新问题。把AI当“队友”而不是“工具”，第一天开始用它时就要建立这个意识，你才能体会到框架设计的精髓。

6.2 你的项目需要怎样的“骨架”

引入这套框架，并不意味着每个项目都要用到全部的技能。规模越小的任务，越不需要完整的仪式化流程。但反过来，团队项目、长期维护的项目、多人协作的项目，对流程的要求反而是必需品。你完全可以从/plan和/review这两个最常用的技能开始，等流程被团队成员接受后，再引入/debug和/document，逐步建成一套适合团队的完整工作流。

6.3 最后一条建议：让它尽快成为“日常”

持续使用才能找到自己的节奏。框架给了你方法，但挖不挖得出金矿，取决于你把AI的产出质量的标准拉到多高。这就好比好的项目管理方法论需要团队真正执行才能见效，superpowers也一样——一旦跑起来，你对AI的信任度会慢慢建立起来，协作的效率自然就上来了。