企业官网建设流程全解析

1. 从“superpowers”这个热词说起：它到底是什么

最近“superpowers”这个词在技术社区里的讨论热度明显上来了，尤其是“想要安装superpowers”这个搜索词，我在后台看到不少人在问。先说结论：这里的 superpowers 不是某个单一软件，而是一套围绕 AI 编程助手（尤其是 Claude Code 这类工具）构建的技能扩展框架。它的核心思路是把资深工程师的工作方法论——比如需求澄清、方案设计、测试驱动开发、代码审查——封装成一个个可复用的“技能包”，让 AI 在写代码时不只是“能跑就行”，而是按照一套严谨的工程流程来推进。

我第一次接触这个概念的时候，直觉是“又一个提示词合集”，但实际用下来发现它的价值远不止于此。它解决的是一个非常具体的痛点：AI 写代码很快，但经常写出“看起来对、实际上经不起推敲”的东西。比如你让它实现一个功能，它可能直接给你一段代码，没有边界条件处理，没有测试，也没有考虑和现有代码的集成方式。superpowers 的做法是在 AI 动手之前，先强制它走一遍“理解需求→设计方案→拆解任务→逐步实现→验证结果”的流程，把工程纪律注入到 AI 的工作方式里。

这套东西适合谁？如果你已经在用 AI 辅助编程，但总觉得产出质量不稳定、需要反复返工，那 superpowers 值得花时间研究。如果你还没开始用 AI 写代码，那它也能帮你建立一个正确的协作心智模型——知道什么时候该让 AI 做什么，什么时候该自己接管。下面我会从设计思路、核心机制、安装配置、实操流程到常见问题，完整拆一遍。

2. 核心设计思路：为什么是“技能”而不是“提示词”

2.1 提示词工程的瓶颈在哪里

大多数人用 AI 编程的方式是：打开对话框，描述需求，复制代码，粘贴到项目里，跑一下，报错了再贴回去让 AI 修。这个循环在简单任务上没问题，但一旦涉及多文件改动、需要理解现有代码结构、或者有隐含的业务约束时，就会迅速失控。根本原因在于：提示词是一次性的、上下文相关的、不可复用的。你这次写了一段很长的提示让 AI 按 TDD 方式工作，下次换个会话，一切归零。

superpowers 的设计者显然想清楚了这个问题。它的做法是把“如何做好某类工程任务”的知识从提示词里抽出来，变成独立的、可版本管理的技能文件。每个技能文件本质上是一份结构化的操作指南，告诉 AI 在特定场景下应该遵循什么步骤、检查什么要点、产出什么格式的结果。这就像把一位资深工程师的“工作习惯”写成了标准作业程序，AI 每次执行任务时加载对应的技能，就能稳定复现这套习惯。

2.2 技能框架的三个关键设计决策

第一个决策是技能与工具分离。superpowers 不绑定特定的 AI 工具，它定义的是技能的内容和加载机制，具体怎么调用由宿主工具决定。这意味着同一套技能可以在不同的 AI 编程环境里复用，不会因为换了工具就全部重写。

第二个决策是渐进式加载。技能不是一股脑全部塞进上下文，而是按需触发。比如你在做一个前端组件，它不会把数据库迁移的技能也加载进来。这样做的好处是节省上下文窗口，同时避免无关信息干扰 AI 的判断。我实测下来，一个典型任务只会加载 2 到 4 个相关技能，上下文占用控制在合理范围内。

第三个决策是强制流程节点。某些技能被设计成“门禁”性质——比如在写任何代码之前，必须先完成需求澄清和方案设计，否则后续步骤无法启动。这个设计一开始让我觉得有点繁琐，但踩过几次坑之后我理解了：AI 最大的问题不是写不出代码，而是在错误的方向上高速产出。一个需求理解偏差，后面写一千行都是白费。强制前置澄清，反而整体效率更高。

2.3 和传统提示词模板的本质区别

很多人会把 superpowers 和网上流传的“提示词模板”混为一谈，但两者有本质区别。提示词模板是静态的文本，你复制粘贴到对话框里，它不会根据你的项目状态变化。而 superpowers 的技能是有状态的、可组合的、能感知上下文的。举个例子，一个“代码审查”技能在加载时，会先读取当前项目的文件结构和最近的改动记录，然后针对性地生成审查清单，而不是套用一份通用模板。

另一个区别是可验证性。技能文件里通常包含明确的验收标准，比如“所有新增函数必须有对应的单元测试”“边界条件必须覆盖空值、极值和异常输入”。这些标准让 AI 的产出可以被客观检验，而不是靠感觉判断“写得不错”。我在团队里推广这套方法时，最大的感受就是：以前 review AI 生成的代码全靠经验，现在有了明确的检查项，新人也能快速判断质量。

3. 安装与配置：从零把 superpowers 跑起来

3.1 前置环境准备

在安装 superpowers 之前，你需要先确认基础环境。根据我的实操经验，以下条件是必须满足的：

• Node.js 18 或更高版本。superpowers 的安装脚本和部分技能依赖现代 JavaScript 运行时特性，低于 18 的版本会在安装阶段报错。用node -v检查，如果版本不够，建议通过 nvm 或官方安装包升级。
• 一个支持技能加载的 AI 编程工具。目前主流的选择是 Claude Code，它原生支持技能目录的读取和触发。如果你用的是其他工具，需要确认它是否支持自定义技能加载机制。
• Git。技能包通常以 Git 仓库形式分发，安装过程需要克隆仓库。同时，superpowers 的某些技能会调用 Git 命令来检查改动历史，所以确保 Git 已安装并配置好用户信息。
• 足够的磁盘空间和网络稳定性。技能包本身不大，但安装过程中会拉取依赖，网络不稳定容易导致安装中断。

注意：不要在生产环境的主力机器上直接安装测试。建议先在一个独立的开发目录或容器里跑通流程，确认没问题后再迁移到日常工作环境。

3.2 安装步骤详解

安装 superpowers 的核心操作是把技能仓库克隆到 AI 工具能识别的目录下。以 Claude Code 为例，具体步骤如下：

第一步，确定技能目录位置。Claude Code 默认会读取用户主目录下的.claude/skills目录。你可以通过工具的配置文档确认具体路径，不同版本可能略有差异。

# 创建技能目录（如果不存在） mkdir -p ~/.claude/skills # 进入该目录 cd ~/.claude/skills

第二步，克隆 superpowers 仓库。这里要注意，克隆的是技能集合仓库，而不是某个单一技能。

git clone https://github.com/obra/superpowers.git

第三步，检查目录结构。克隆完成后，你应该能看到一系列以技能名称命名的子目录，每个子目录里包含一个SKILL.md文件和其他辅助资源。

ls superpowers/ # 预期输出类似： # brainstorming/ code-review/ debugging/ tdd/ ...

第四步，验证安装。重启你的 AI 编程工具，然后在对话中输入一个会触发技能加载的请求，比如“帮我审查一下最近的代码改动”。如果工具正确加载了 code-review 技能，你会看到它按照技能定义的流程来响应，而不是直接给出一段泛泛的建议。

3.3 配置调优与常见安装问题

安装过程中最容易出问题的地方是路径识别。有些工具的技能目录不在默认位置，或者有多个候选路径，导致克隆进去之后工具找不到。排查方法是查看工具的日志输出，确认它实际扫描了哪些目录。如果路径不对，要么调整克隆位置，要么修改工具配置指向正确的目录。

另一个常见问题是权限。在 Linux 或 macOS 上，如果技能目录的权限设置过严，AI 工具可能无法读取技能文件。用ls -la检查目录权限，确保当前用户有读权限。Windows 用户则要注意路径分隔符和大小写敏感性，虽然现代 Windows 对大小写不敏感，但某些工具内部逻辑可能区分大小写。

还有一个坑是技能版本冲突。如果你之前手动创建过同名技能目录，克隆 superpowers 后可能出现覆盖或冲突。建议在克隆前先备份或清空已有的技能目录，避免新旧混杂导致行为异常。我自己就遇到过因为残留的旧技能文件导致 AI 加载了错误版本的情况，排查了半天才发现是目录没清干净。

4. 核心技能拆解：每个技能解决什么问题

4.1 brainstorming：把模糊需求变成清晰方案

这个技能是我用得最频繁的一个。它的作用是在你只有一个模糊想法时，通过结构化的提问帮你把需求理清楚。比如你说“我想做一个任务管理工具”，它会依次追问：目标用户是谁？核心使用场景是什么？数据存储在哪里？需要多人协作吗？每个问题的答案会逐步收敛成一个可执行的需求描述。

从实现角度看，这个技能的核心是一套提问模板和收敛逻辑。它不是随机提问，而是按照“用户→场景→功能→约束→优先级”的层次递进。每轮提问后，它会总结当前的理解，让你确认或修正。我实测下来，一个中等复杂度的功能需求，经过 3 到 5 轮对话就能达到“可以直接进入设计阶段”的清晰度。相比自己闷头想，效率提升明显。

实操心得：不要跳过这个技能直接让 AI 写代码。我试过几次“省事”直接进入实现，结果都是在写到一半时发现需求理解有偏差，返工成本远高于前期澄清的投入。

4.2 writing-plans：把方案拆成可执行的任务清单

需求澄清之后，下一个关键步骤是制定实现计划。writing-plans 技能会引导 AI 把方案拆解成一系列有序的任务，每个任务有明确的输入、输出和验收标准。这个技能的产出通常是一份 Markdown 格式的计划文档，包含任务列表、依赖关系和预估复杂度。

这个技能的设计亮点在于强制拆解粒度。它要求每个任务必须小到“可以在一个会话内完成”，避免出现“实现用户模块”这种过于宽泛的任务。我一开始觉得拆得太细很啰嗦，但实际执行时发现，细粒度任务让 AI 的每次输出都更容易验证，出错时也更容易定位是哪一步的问题。

4.3 tdd：测试驱动开发的 AI 版本

TDD 技能是 superpowers 里工程纪律最强的部分。它的流程是：先写测试，确认测试失败，再写实现代码让测试通过，最后重构。对于 AI 来说，这个流程的价值在于给了一个明确的停止条件——测试通过就是完成，不需要 AI 自己判断“写得差不多了”。

我在实际使用中调整了一个细节：对于探索性较强的任务，我会先让 AI 用 TDD 技能写核心逻辑的测试，但允许它在测试通过后继续补充边界情况的测试。这样既保证了核心功能的正确性，又不会因为过度追求测试覆盖率而拖慢进度。这个平衡点需要根据项目阶段来把握，原型阶段可以松一些，生产代码则应该严格。

4.4 code-review：让 AI 用资深工程师的眼光审查代码

代码审查技能加载后，AI 会按照一套检查清单来审视代码，包括：命名是否清晰、函数职责是否单一、错误处理是否完整、边界条件是否覆盖、是否有潜在的性能问题、是否符合项目的代码风格。它不只是指出问题，还会给出具体的修改建议。

这个技能最让我惊喜的地方是它能发现一些我自己忽略的问题。比如有一次它指出某个函数的参数顺序不符合项目惯例，虽然功能没问题，但会影响后续维护的一致性。这种“风格层面”的审查，以前只有经验丰富的同事才能给出，现在 AI 也能稳定输出。

4.5 debugging：系统化排查而不是盲目试错

调试技能的核心是一套假设-验证循环。AI 会先根据错误信息提出可能的根因假设，然后设计最小的验证步骤来确认或排除每个假设。这个过程比“改一行跑一下”的盲目试错高效得多，尤其是在复杂系统中。

我印象最深的一次是排查一个偶发的数据不一致问题。AI 通过调试技能，先确认了问题发生的频率和条件，然后逐步缩小范围，最终定位到一个并发写入的时序问题。整个过程有条不紊，如果靠我自己猜，可能要在几个可疑点之间来回折腾很久。

5. 完整实操流程：从零做一个功能模块

5.1 场景设定与需求输入

假设我们要在一个现有的 Node.js 项目里新增一个“用户积分计算”模块。需求大致是：根据用户的行为记录计算积分，不同行为对应不同分值，有每日上限，积分可以累计但不可为负。这个需求听起来简单，但隐含了不少边界条件。

我打开 AI 编程工具，输入初始需求：“我需要在项目里新增一个用户积分计算模块，根据行为记录算积分，不同行为不同分值，有每日上限。”这时候 brainstorming 技能会被触发，AI 开始追问细节。

5.2 需求澄清阶段的对话记录

AI 的第一轮提问集中在行为类型和分值定义上。我回复：行为类型包括登录、发帖、评论、点赞四种，分值分别是 1、5、3、1。每日上限是 50 分。第二轮提问涉及数据来源和计算时机：行为记录存在数据库里，积分是实时计算还是定时批量计算？我选择实时计算，每次查询时根据当天的行为记录算出当前积分。

第三轮提问关于边界情况：如果行为记录的时间戳跨天怎么处理？积分是否允许小数？我确认按自然日划分，积分取整数。到这里，需求已经足够清晰，AI 生成了一份需求摘要让我确认。我检查后发现一个遗漏：没有定义“每日上限”是每种行为分别限制还是总分限制。补充确认后，需求文档定稿。

5.3 方案设计与任务拆解

进入 writing-plans 阶段，AI 给出了如下任务列表：

1. 定义行为类型和分值的配置结构
2. 实现单条行为记录的积分计算函数
3. 实现按日聚合和上限截断逻辑
4. 实现查询接口，返回指定用户指定日期的积分
5. 为上述每个函数编写单元测试
6. 集成到现有的用户服务中

每个任务都标注了预估的代码行数和依赖关系。我调整了任务顺序，把测试编写提前到每个实现任务之后立即进行，而不是集中到最后。这样能更早发现设计问题。

5.4 编码实现与测试验证

进入 tdd 阶段，AI 先为“单条行为记录积分计算”写了测试用例，覆盖了正常行为、未知行为类型、分值为零的行为等场景。测试运行失败（因为实现还不存在），然后 AI 写出实现代码，再次运行测试通过。

接着处理每日上限逻辑。这里有一个容易出错的点：上限截断应该在聚合之后进行，而不是在单条计算时。AI 在测试中专门加了一个用例：当天累计积分超过上限时，返回上限值而不是实际累计值。这个用例帮助我们在早期就锁定了正确的行为。

整个实现过程大约进行了 6 轮 TDD 循环，每轮都遵循“写测试→确认失败→写实现→确认通过”的节奏。最终所有测试通过，代码审查技能又跑了一遍，指出了两个命名不够清晰的地方，修正后合并到主分支。

5.5 关键参数与配置说明

在这个实操中，有几个参数值得单独说明。每日上限设为 50 是一个业务决策，技术上它只是一个常量，但放在配置文件里而不是硬编码在函数中，方便后续调整。行为分值的映射关系也建议配置化，因为业务方可能会调整分值而不希望改代码。

另外，时间戳的处理需要特别注意时区问题。如果行为记录的时间戳是 UTC 存储的，而“自然日”是按本地时区划分的，就需要在聚合时做时区转换。这个坑我在另一个项目里踩过，导致跨天时积分计算出现偏差。建议在需求阶段就明确时区策略，并在测试中覆盖跨天场景。

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

6.1 技能不触发或触发错误

最常见的问题是技能没有被正确加载。表现是 AI 的响应和没有安装技能时一样，直接给代码而不走流程。排查步骤：首先确认技能目录路径是否正确，用工具的日志功能查看它扫描了哪些目录；其次确认技能文件的命名和格式是否符合要求，SKILL.md文件名和内部的元数据字段都不能有误；最后检查是否有多个版本的技能冲突，清理掉旧版本。

另一个相关问题是触发了错误的技能。比如你只是想问一个简单的语法问题，结果 AI 加载了完整的 TDD 流程，显得过于隆重。这通常是因为你的请求描述里包含了触发关键词。解决办法是在提问时更明确地表达意图，比如“快速回答，不需要走完整流程”。

6.2 流程过于繁琐影响效率

有些用户反馈 superpowers 的流程太重，一个小改动也要走需求澄清、方案设计、TDD 全套。这确实是个问题，我的处理方式是按任务复杂度分级。对于改一个变量名、修一个拼写错误这种琐碎任务，直接让 AI 改就行，不需要加载技能。对于涉及逻辑变更的任务，至少走需求澄清和测试验证两步。对于新功能开发，则完整走全套流程。

这个分级策略需要根据你的项目阶段调整。原型阶段可以宽松一些，快速验证想法优先；生产代码则应该严格，因为返工成本高。我在团队里推行时，给每个级别定义了明确的判断标准，避免大家凭感觉决定。

6.3 技能输出质量不稳定

偶尔会出现技能加载了但输出质量不理想的情况，比如需求澄清问的问题很浅，或者代码审查漏掉了明显问题。这通常和上下文有关——如果项目信息不足，AI 的判断就会打折扣。解决办法是在触发技能前，先让 AI 读取相关的项目文件，比如package.json、目录结构、最近的 Git 提交记录。这些信息能显著提升技能输出的针对性。

还有一个技巧是在技能执行过程中主动补充信息。比如在需求澄清阶段，如果 AI 没有问到某个你认为重要的约束，直接告诉它“还需要考虑 XX 情况”。技能框架是灵活的，不是必须严格按它的提问顺序走。

6.4 常见问题速查表

6.5 几个我踩过的坑

第一个坑是在错误的目录层级克隆。我有一次在项目目录里直接克隆了 superpowers，结果技能被当成了项目代码的一部分，AI 在分析项目时把技能文件也纳入了上下文，导致输出混乱。正确做法是克隆到工具专用的技能目录，和项目代码物理隔离。

第二个坑是忽略技能更新。superpowers 是活跃维护的项目，技能内容会迭代。我有段时间没拉取更新，用的还是旧版技能，后来发现新版在需求澄清阶段增加了“非功能性需求”的提问，能提前发现性能、安全方面的约束。建议定期git pull更新技能包。

第三个坑是过度依赖技能。有一段时间我什么任务都走完整流程，结果简单任务被拖得很慢。后来我给自己定了个规矩：如果任务能在 5 分钟内手动完成，就不启动技能流程。这个判断标准帮我节省了大量时间。

7. 进阶用法：定制自己的技能包

7.1 什么情况下需要自定义技能

superpowers 提供的通用技能覆盖了大部分场景，但每个团队都有自己的特殊流程。比如你们可能有一套特定的代码审查清单，或者项目有独特的部署验证步骤。这些团队特有的知识，通用技能不会包含，这时候就需要定制。

我所在的团队就定制了一个“数据库迁移审查”技能，因为我们的迁移流程有特殊要求：必须包含回滚脚本、必须在大表上使用在线 DDL、必须在低峰期执行。这些约束写进技能后，AI 在生成迁移方案时会自动检查这些点，减少了人工审查的负担。

7.2 技能文件的结构与编写要点

一个技能文件的核心是SKILL.md，它通常包含几个部分：技能名称和描述、触发条件、执行步骤、验收标准、示例。编写时最重要的原则是步骤要具体到可执行，避免“仔细检查代码质量”这种模糊表述，而要写成“检查每个函数的参数是否有类型校验”。

另一个要点是控制技能的长度。技能文件不是越长越好，过长的技能会占用大量上下文，而且 AI 可能抓不住重点。我的经验是，一个技能的核心步骤控制在 10 步以内，每步的描述不超过 3 句话。如果需要更复杂的行为，拆成多个技能组合使用。

7.3 测试自定义技能的方法

写完技能后，不要直接在日常工作中使用，先做隔离测试。找一个简单的任务，手动触发技能，观察 AI 的执行过程是否符合预期。重点检查：技能是否被正确加载、步骤是否按顺序执行、验收标准是否被遵守。

我通常会用三个不同复杂度的任务来测试一个新技能：一个简单任务验证基本流程，一个中等任务验证边界处理，一个复杂任务验证与其他技能的协作。三个任务都通过后，才会正式纳入团队的技能库。

8. 影响范围与适用边界

superpowers 这套方法对个人开发者的影响是直接的：它把 AI 从“代码生成器”变成了“遵循工程流程的协作伙伴”。你不再需要每次都想怎么描述需求、怎么检查产出，技能框架帮你把这些重复性的思考固化了。我自己的感受是，使用 superpowers 后，AI 生成代码的返工率明显下降，从“经常需要大改”变成了“偶尔需要微调”。

对团队来说，价值更大。当所有人都用同一套技能时，AI 的产出风格和质量标准就统一了。新人可以借助技能快速达到团队的工程标准，代码审查的沟通成本也降低了，因为很多基础问题在 AI 生成阶段就被技能拦截了。

但也要清楚它的边界。superpowers 不能替代人的判断，它是一套流程框架，不是自动化的质量保证。需求是否合理、架构是否恰当、业务逻辑是否正确，这些仍然需要人来把关。技能能确保 AI 按流程走，但流程本身的质量取决于设计者的水平。另外，它目前主要面向代码开发场景，对于非编程类的 AI 使用场景，适用性有限。

最后分享一个我个人的使用节奏：每天早上花 10 分钟浏览一下技能仓库的更新，看看有没有新技能或现有技能的改进。这个习惯让我能持续从社区的经验中受益，而不是固守自己的一套用法。技能框架的价值在于持续迭代，用起来、改起来，才能真正发挥它的作用。