AI编程工作流革命：superpowers-zh如何让AI助手成为懂流程的资深工程师

1. 项目概述：AI编程的“工作流操作系统”

如果你用过Claude Code、Cursor或者GitHub Copilot，大概率有过这样的体验：你提一个需求，比如“给用户模块加个批量导出功能”，AI助手二话不说，直接开始噼里啪啦写代码。结果呢？导出的格式不对，数据量一大就内存溢出，权限校验也没做。你不得不打断它，重新描述，来回拉扯，效率反而更低了。

这背后的根本问题，不在于AI模型的能力，而在于它不知道“怎么干活”。它缺少一套标准化的、经过验证的工程工作流。这就好比给一个天才程序员配了一台顶配电脑，却没告诉他公司的代码规范、Git分支策略和Code Review流程，他依然会写出不合规的代码。

superpowers-zh要解决的，正是这个“工作流缺失”的痛点。它不是另一个代码生成插件，而是一套AI编程的工作方法论系统。你可以把它理解为AI编程工具的“操作系统”或“标准作业程序”。它包含了20个精心设计的“技能”，覆盖了从需求分析、任务拆解、测试驱动开发、系统化调试到代码审查的完整软件工程生命周期。

这个项目是英文原版superpowers的完整汉化与增强版。除了将原版14个核心技能翻译成更符合中文开发者思维习惯的表述外，它还新增了6个针对中国开发生态的原创技能，比如适配Gitee、Coding等国内Git平台的协作规范，以及符合国内团队沟通文化的代码审查风格。更重要的是，它将支持的工具从原版的6款扩展到了17款，包括Claude Code、Cursor、通义灵码、Windsurf等主流AI编程工具，并且提供了一条命令npx superpowers-zh的自动安装方案，极大降低了使用门槛。

简单说，装上它，你的AI编程助手就从“埋头蛮干的实习生”，变成了“懂流程、有方法、会协作的资深工程师”。

2. 核心设计思路：从“工具”到“工作流”的范式转变

2.1 核心理念：技能（Skill）即工作流

superpowers-zh的核心资产是20个.md文件，每个文件代表一个“技能”。这些文件不是普通的Markdown文档，而是严格按照特定格式编写的、AI能够理解和执行的“工作流指令集”。

一个典型的Skill文件结构如下：

1. 技能名称与描述：用一句话讲清楚这个技能是干什么的。
2. 核心原则：阐述这个工作流背后的工程哲学，比如TDD的“红-绿-重构”循环。
3. 操作步骤：将工作流分解为AI可逐步执行的、明确的步骤。这是技能的主体。
4. 检查清单：在每个关键步骤后，列出AI需要自我检查的要点。
5. 示例对话：展示用户如何触发技能，以及AI应该如何响应的完整对话模板。

这种设计的关键在于，它将隐性的、依赖于开发者个人经验的工作方法，变成了显性的、可复用的指令。例如，“系统化调试”技能会要求AI按照“定位问题 → 分析原因 → 提出假设 → 验证修复”的四步法来操作，而不是看到报错就盲目地尝试修改代码。

2.2 中文化与本土化：不止于翻译

很多优秀的英文开源项目，汉化后总有一股“机翻味”，或者水土不服。superpowers-zh在这一点上做得相当深入。

首先，是技术术语的精准处理。项目坚持“技术术语保留英文”的原则。例如，“Test-Driven Development”翻译为“测试驱动开发”，但其中的“Red-Green-Refactor”循环、Mock、Stub等术语均保留英文。这确保了技能在传达时的精确性，避免了因翻译产生的歧义。

其次，是工作习惯的深度适配。这是6个中国特色技能的价值所在。以“中文代码审查”技能为例，它不仅仅是将审查意见翻译成中文。它调整了反馈的措辞风格，使其更符合国内团队“对事不对人”、强调协作的沟通文化。审查意见会更倾向于使用“建议这里可以……”、“考虑到可维护性，或许……”这样的句式，而非过于直接或批判性的表达。

再者，是工具链的全面覆盖。原版superpowers主要围绕GitHub和少数几个国际主流工具设计。superpowers-zh则新增了对Gitee、Coding（腾讯云DevOps）、极狐GitLab等国内主流代码托管平台工作流的支持。甚至在CI/CD示例中，除了GitHub Actions，还提供了Gitee Go、Coding CI和极狐CI的配置样例，以及腾讯云原生构建（CNB）的.cnb.yml示例。这让国内开发者能在自己熟悉的工具链里无缝使用这套方法论。

2.3 一键多端适配：降低使用成本

支持17款工具听起来很美好，但如果每个工具都需要不同的安装命令、不同的配置文件路径，那会是一场噩梦。superpowers-zh通过智能检测和统一入口，完美解决了这个问题。

当你运行npx superpowers-zh时，它会做以下几件事：

1. 扫描项目根目录：检查是否存在.cursor、.claude、.hermes等特定工具的配置文件或目录。
2. 分析package.json：通过项目依赖推断可能使用的AI工具。
3. 智能判断与安装：一旦识别出你正在使用的工具（比如检测到.cursor目录），它会自动将20个技能文件复制到该工具约定的技能目录下（如.cursor/skills/）。
4. 回退与显式指定：如果自动检测失败，你可以通过npx superpowers-zh --tool cursor这样的命令显式指定工具。

这种设计极大地简化了部署流程。开发者无需关心不同工具的技能文件应该放在哪里，一条命令，全搞定。这背后是对每一款工具插件系统的深入研究，确保了技能文件能被正确加载和识别。

注意：虽然npx superpowers-zh的自动检测很强大，但在某些复杂项目或多工具混用的场景下，仍建议使用--tool参数显式指定，以确保安装到正确的位置。安装后，最好到对应的工具技能目录下确认文件是否已就位。

3. 核心技能深度解析与实战价值

20个技能看似很多，但可以归纳为四大类：需求与设计类、开发与实现类、质量保障类和协作与流程类。下面我们挑几个最具代表性的技能，拆解其设计精妙之处和实战用法。

3.1 需求与设计类：从“要什么”到“怎么做”

技能代表：头脑风暴、编写计划

很多AI编程的失败，始于需求不清。头脑风暴技能的核心是“先问再做”。当用户提出一个模糊需求时，AI不会直接跳入代码实现，而是会启动一个结构化的提问流程。

例如，用户说：“做一个登录功能。” 加载了头脑风暴技能的AI会这样响应：

好的，我们来一起规划这个登录功能。为了设计出健壮、安全的方案，我需要了解以下信息： 1. **认证方式**：是传统的用户名/密码，还是手机号+验证码、第三方OAuth（微信/钉钉/飞书）？ 2. **安全要求**：是否需要图形验证码、登录尝试频率限制、密码强度策略？ 3. **用户体验**：是否需要“记住我”功能、单点登录、登录后跳转逻辑？ 4. **技术栈**：后端框架是什么？计划使用JWT还是Session？用户数据存储在哪里？ 请先回答这些问题，我们再进入具体设计。

这个技能强制引入了一个“需求澄清”阶段，模仿了资深工程师在动手前必做的“需求访谈”。它生成的不是代码，而是一份清晰的设计规格说明书，为后续的编写计划技能打下基础。

编写计划技能则负责将设计规格转化为可执行的任务列表。它会采用类似“用户故事”或“任务拆解”的方式，将大目标分解为一个个原子性的、可验证的小步骤。例如，针对“登录功能”，计划可能包括：

1. 设计用户表结构。
2. 实现密码加密存储（使用bcrypt）。
3. 创建登录API端点（POST /api/auth/login）。
4. 实现JWT令牌的生成与验证中间件。
5. 编写登录相关的单元测试和集成测试。
6. 设计前端登录表单和状态管理。

这个任务列表，就成了执行计划技能的输入蓝图。

3.2 开发与实现类：规范化的编码过程

技能代表：测试驱动开发、系统化调试、Git Worktree使用

测试驱动开发技能是工程严谨性的体现。它不只是告诉AI“先写测试”，而是定义了一套严格的执行流程：

1. 红：针对某个微小功能点，编写一个必定失败的测试。AI会先分析功能点，然后生成对应的测试用例代码。
2. 绿：用最简单、最直接的方式实现代码，让刚才的测试通过。AI会生成最小可行实现。
3. 重构：在测试保护下，优化代码结构，消除重复，提升可读性，而不改变外部行为。AI会建议并执行重命名、提取函数等重构操作。

这个技能将TDD从一个概念，变成了AI可以一步步跟随的“操作手册”，确保了代码从一开始就具备良好的可测试性。

系统化调试技能则是对抗“盲目试错”的利器。当遇到Bug时，AI会遵循以下路径：

• 定位：首先，要求AI复现问题，并精确描述错误信息、堆栈跟踪和触发条件。它可能会要求用户提供更详细的日志或截图。
• 分析：基于已知信息，分析可能的原因。是数据问题、逻辑错误、还是环境配置？AI会列出2-3个最可能的假设。
• 假设：针对每个假设，设计一个验证实验。例如，“如果是空指针异常，我们在第X行添加一个空值检查并打印日志”。
• 修复：根据验证结果，实施修复，并运行相关测试确保没有引入回归。

这个过程将调试从“玄学”变成了“科学”，极大地提升了排查复杂问题的效率。

Git Worktree使用技能解决的是多任务并行开发的困扰。它教导AI如何利用git worktree命令，为每个新功能或Bug修复创建一个完全独立的、链接到主仓库的工作目录。这样，你可以在一个工作树中修复紧急线上Bug，同时在另一个工作树中开发新功能，两者互不干扰，无需频繁地stash和切换分支。AI会帮你生成正确的git worktree add命令，并管理这些工作树。

3.3 质量保障类：引入“第二双眼”

技能代表：请求代码审查、接收代码审查、完成前验证

请求代码审查和接收代码审查是一对组合技能，旨在将人工Code Review的文化和流程植入AI协作中。

当开发者（或AI）完成一个功能模块后，可以触发请求代码审查。此时，AI会扮演一个“审查者Agent”，它不会直接修改代码，而是会：

• 检查代码风格是否符合项目规范。
• 分析潜在的性能瓶颈和安全漏洞。
• 评估测试覆盖率是否充分。
• 从可读性和可维护性角度提出改进建议。
• 最终生成一份结构化的审查报告。

接收代码审查则教导AI如何以建设性的态度处理审查反馈。它会将反馈分类（如“必须修改”、“建议改进”、“疑问”），并逐一做出回应：对于必须修改的，立即实施；对于建议，评估后决定是否采纳并说明理由；对于疑问，进行澄清。这个过程模拟了高效的团队协作，确保了代码质量。

完成前验证技能是一个“最终守门员”。它要求AI在声称完成任务前，必须提供“完成证据”。这通常包括：

• 所有新增或修改的代码。
• 相关测试的运行结果和通过证明。
• 关键功能的操作步骤和预期输出。
• 对可能影响的周边模块的评估。 没有这些证据，AI不能单方面宣布任务完成。这有效防止了“看起来好了，实际跑不起来”的半成品交付。

3.4 中国特色技能精讲

中文代码审查：这个技能的独特之处在于其“沟通模板”。它内置了符合国内团队习惯的评语库。例如，对于命名不规范的变量，英文审查可能直接说“Rename variableato something descriptive”。而中文技能可能会说：“变量a的含义不够清晰，建议根据其实际用途重命名为userList或processedCount，以提升代码可读性。” 这种表达更委婉，更侧重于提出建设性方案。

中文Git工作流：它主要适配了国内平台的一些细微差别。例如，在Gitee上创建Pull Request（合并请求）的流程、Coding平台上的分支保护规则设置、以及极狐GitLab的CI/CD变量配置语法。技能中包含了这些平台的具体操作命令和配置示例，让AI能生成更“接地气”的协作指令。

MCP服务器构建和工作流执行器是两个高阶技能。MCP服务器构建指导AI如何构建一个符合Model Context Protocol标准的工具服务器，从而将自定义工具（如查询内部数据库、调用特定API）暴露给Claude等AI助手使用，极大地扩展了AI的能力边界。工作流执行器则允许你在AI对话中，直接运行一个定义在YAML文件里的多角色协作工作流，实现了“对话即编排”，这与项目生态中的agency-orchestrator形成了完美互补。

4. 多工具安装与配置实战指南

虽然npx superpowers-zh一键安装很方便，但了解其背后的原理和各工具的配置方式，有助于解决疑难杂症和进行高级定制。

4.1 安装过程深度解析

当你运行npx superpowers-zh时，背后发生了以下事情：

1. 下载与解包：npx会从npm仓库下载superpowers-zh包的最新版本并临时执行。
2. 环境检测：安装脚本会遍历当前目录，寻找特定工具的“指纹”。例如：
   • 存在.cursor目录或cursor.sh的配置文件 -> 识别为 Cursor。
   • 存在.claude目录或CLAUDE.md文件 -> 识别为 Claude Code / Copilot CLI。
   • 存在.hermes目录 -> 识别为 Hermes Agent。
   • 检查package.json中的devDependencies或dependencies，看是否包含@cursor、@anthropic等相关包。
3. 路径映射与复制：根据识别结果，脚本将skills/目录下的所有技能文件夹，复制到对应的目标路径。映射关系存储在安装脚本的一个内部配置表中。
4. 生成提示：复制完成后，脚本会在终端输出成功信息，并提示用户如何在其AI工具中启用或验证这些技能。

4.2 主流工具配置要点

不同的AI工具加载技能的方式各异。以下是几款主流工具的配置关键点：

对于 Cursor、Windsurf、Trae 等现代AI IDE：这些工具通常有一个专用的规则或技能目录。安装后，技能会自动生效。你可以在IDE的设置中查找“Rules”、“Skills”或“Custom Instructions”相关选项，看到已加载的技能列表。例如在Cursor中，你可以通过Cmd/Ctrl + Shift + P打开命令面板，输入“Open Rules Directory”来查看.cursor/rules下的所有规则文件。

对于 Claude Code、Copilot CLI、Hermes Agent 等 CLI 工具：这些工具通过项目根目录下的特定配置文件（如CLAUDE.md,.hermes.md）或特定目录结构来加载技能。superpowers-zh安装后，技能文件被放置在如.claude/skills/的子目录下。你需要在主配置文件（如CLAUDE.md）中，通过#skills指令或类似的语法来引用它们。例如，在CLAUDE.md文件中加入：

#skills - .claude/skills/brainstorming/README.md - .claude/skills/test-driven-development/README.md ...

有些工具支持通配符，如- .claude/skills/*/README.md来加载所有技能。

对于 VS Code + GitHub Copilot：Copilot的自定义指令功能相对独立。superpowers-zh会将技能文件安装到.github/superpowers/目录下。你需要手动将你需要的技能内容，整合到你的VS Code Copilot全局或工作区自定义指令中。通常，你可以打开VS Code设置，搜索“Copilot Custom Instructions”，然后将某个技能（如“系统化调试”）的核心步骤和检查清单粘贴进去。

对于 Aider、OpenCode 等代码编辑代理：这类工具通常有明确的技能目录（如.aider/skills/）。安装即生效，因为Aider会在启动时自动扫描并加载该目录下所有符合格式的SKILL.md文件。

实操心得：安装后，第一件事是去你的AI工具里确认技能是否被正确加载。在Cursor里，尝试输入/brainstorm看看AI是否会启动头脑风暴流程；在Claude Code里，输入“我们来用TDD的方式开发一个功能”，观察其响应是否符合技能描述。如果没反应，检查技能文件是否在正确路径，以及主配置文件是否正确引用了它们。

4.3 手动安装与混合使用场景

在某些情况下，你可能需要手动安装或混合使用多个工具的技能。

1. 项目已存在自定义技能：如果你已经在.cursor/rules下有自己的规则，直接复制superpowers-zh/skills/下的内容进去即可。注意文件命名不要冲突。
2. 仅使用部分技能：你可以只复制你需要的技能文件夹，而不是全部。例如，你只想要TDD和代码审查，就只复制test-driven-development和requesting-code-review两个目录。
3. 多工具共存项目：一个项目里可能同时用Cursor写前端，用Claude Code调试后端。你可以分别运行npx superpowers-zh --tool cursor和npx superpowers-zh --tool claude，或者手动将技能复制到各自的目录（.cursor/rules/和.claude/skills/）。技能文件本身是通用的，只是存放路径不同。

5. 实战案例：用superpowers-zh完整开发一个“用户导出”功能

让我们跟随一个AI助手（以Claude Code为例），看它在加载了superpowers-zh技能后，如何系统化地完成一个“用户批量导出为Excel”的需求。

第1步：需求澄清（头脑风暴技能触发）我输入：“需要给管理后台的用户列表增加一个批量导出功能。” AI响应（加载了头脑风暴技能）：

“好的，我们来规划这个用户导出功能。为了确保功能完整且健壮，请先确认以下细节：

1. 导出格式：需要导出为Excel（.xlsx）还是CSV？是否需要支持多种格式？
2. 数据范围：是导出当前列表筛选后的所有用户，还是支持自定义选择？预计单次导出的最大数据量是多少？
3. 字段定制：需要导出用户的所有字段，还是允许管理员在前端勾选要导出的列？
4. 性能与异步：如果数据量很大（例如超过1万条），是否需要做成异步任务，提供导出进度和完成后下载？
5. 权限与安全：哪些角色的管理员可以执行导出操作？导出的文件是否需要加密或加水印？ 请提供这些信息，我们将据此制定实现计划。”

我回复：“导出为Excel，支持前端列勾选，数据量可能在几千到几万条，需要做异步处理，仅超级管理员可操作。”

第2步：制定计划（编写计划技能触发）AI基于我的回复，生成实施计划：

“基于需求，我们制定以下开发计划：阶段一：后端API设计

1. 设计导出任务队列模型（ExportTask），包含状态、创建者、参数、文件存储路径等字段。
2. 创建导出任务提交API（POST /api/admin/users/export），接收列选择、筛选条件等参数，创建异步任务并返回任务ID。
3. 创建任务状态查询与文件下载API（GET /api/admin/export-tasks/:id）。
4. 实现一个后台Worker（可使用Bull、Agenda等），消费队列，生成Excel文件（使用exceljs库）。阶段二：前端界面与交互
5. 在用户列表页面添加‘导出’按钮，点击后弹出模态框，展示可导出的字段供勾选。
6. 实现提交导出请求的交互，并轮询任务状态，显示进度条。
7. 任务完成后，提供下载链接。阶段三：权限与安全
8. 在导出API和任务查询API上添加超级管理员权限中间件。
9. 对导出的Excel文件进行简单的动态水印（如包含导出者和时间）。阶段四：测试
10. 为后台Worker编写单元测试。
11. 编写导出API的集成测试。
12. 编写前端导出组件的E2E测试。 我们是否按此计划开始执行？或者您需要对计划进行调整？”

我确认后，AI进入执行阶段。

第3步：测试驱动开发（TDD技能触发）AI开始实现“阶段一”的后端部分。它没有直接写ExportTask模型，而是先打开了对应的测试文件（或创建了一个）。

“我们将采用TDD方式开发ExportTask模型。首先，编写一个失败测试：”

// test/models/ExportTask.test.js const ExportTask = require('../../models/ExportTask'); describe('ExportTask Model', () => { it('should create an export task with pending status', async () => { const taskData = { creatorId: 'user123', params: { format: 'excel', columns: ['id', 'name'] }, filters: { isActive: true } }; const task = await ExportTask.create(taskData); expect(task.status).toBe('pending'); // 此时ExportTask模型还不存在，测试会失败 }); });

“运行测试，确认它失败（红）。现在，我们创建最小化的ExportTask模型使其通过（绿）：”

// models/ExportTask.js const mongoose = require('mongoose'); const exportTaskSchema = new mongoose.Schema({ creatorId: { type: String, required: true }, params: { type: Object, required: true }, filters: { type: Object }, status: { type: String, enum: ['pending', 'processing', 'completed', 'failed'], default: 'pending' }, fileUrl: { type: String }, errorMessage: { type: String }, createdAt: { type: Date, default: Date.now } }); module.exports = mongoose.model('ExportTask', exportTaskSchema);

“再次运行测试，应该通过。现在，我们可以重构，比如为status字段添加索引以提高查询效率……”

AI按照“红-绿-重构”的循环，逐步推进每个小功能点。

第4步：代码审查（请求代码审查技能触发）当AI完成导出Worker的核心逻辑后，它主动发起审查：

“已完成用户导出后台Worker的核心逻辑。现在，我将扮演审查者角色，对代码进行审查：审查发现：

1. 性能隐患：在generateExcel函数中，你是一次性将所有用户数据查询到内存再生成Excel。如果用户量达到10万，可能导致内存溢出。建议：使用流式查询（cursor）和Excel的流式写入。
2. 错误处理不完善：Worker中如果文件生成失败，仅记录了错误日志，但未更新ExportTask状态为failed并记录错误信息。必须修改。
3. 代码重复：buildQueryFromFilters函数中的条件判断逻辑，与用户列表API中的过滤逻辑高度相似。建议：将该逻辑抽取到共享的工具函数中。 请根据以上审查意见进行修改。”

第5步：完成验证（完成前验证技能触发）所有功能开发并审查修改完毕后，AI准备交付前，启动了验证：

“功能开发已完成。以下是完成验证清单： ✅代码变更：已提交所有新增和修改的文件，包括ExportTask模型、导出API、后台Worker、前端组件等。 ✅测试通过：运行了全部相关测试（单元测试12个，集成测试5个），通过率100%。 ✅功能验证：

• 以超级管理员身份登录，在用户列表页勾选‘姓名’、‘邮箱’列，点击导出。
• 前端成功提交任务，显示‘任务排队中’。
• 约30秒后，轮询显示任务完成，出现下载按钮。
• 下载的Excel文件包含正确列和数据，文件名为用户导出_20231027_142300.xlsx。
• 水印信息正确。 ✅权限验证：以普通管理员身份尝试调用导出API，返回403禁止访问。 所有验证通过。用户导出功能已就绪。”

通过这个完整的案例，你可以看到，加载了superpowers-zh的AI助手，其行为模式从“直接编码”转变为“规划-设计-实现-审查-验证”的完整工程流程，输出结果的可靠性和完整性得到了质的提升。

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

在实际使用中，你可能会遇到一些问题。以下是一些常见情况的排查思路和解决方法。

6.1 技能未生效或AI无响应

这是最常见的问题。请按以下步骤排查：

实操心得：最有效的调试方法是“最小化复现”。创建一个全新的空白项目目录，只安装superpowers-zh和一个AI工具（如Cursor），然后测试最基本的技能（如头脑风暴）。如果这样能工作，说明问题出在你原项目的环境或配置上。

6.2 技能行为不符合预期

有时技能被触发了，但AI的执行过程与你的期望有偏差。

• 问题：AI在“头脑风暴”阶段问的问题太多、太细，显得啰嗦。
• 解决：技能文件本身是一个模板，AI会根据具体上下文调整。你可以直接打断它，说“这些细节我们先跳过，按常见方案先设计”，或者事后去修改本地的技能文件，精简其中的提问列表，使其更符合你团队的习惯。
• 问题：“代码审查”技能提出的建议过于琐碎，纠结于代码格式（而项目有Prettier自动处理）。
• 解决：审查技能的侧重点可以调整。你可以在技能文件中，增加类似“优先关注逻辑错误、安全漏洞和性能问题，代码风格问题除非特别严重否则可忽略”的指引。技能是死的，人是活的，可以根据团队规范进行定制。

6.3 与现有项目工作流的整合

• 冲突：项目已有自己的Git提交规范（如Angular Commit Convention），与“中文提交规范”技能冲突。
• 解决：superpowers-zh的技能是增量的，不是强制的。你可以选择不安装chinese-commit-conventions技能，或者安装后，在其技能文件中修改提交信息的模板，使其与你团队的现有规范对齐。核心是利用其“引导AI生成结构化提交信息”的框架，具体格式可以自定义。
• 冲突：团队使用自建的CI/CD，与技能中提供的Gitee Go或GitHub Actions示例不同。
• 解决：将技能中的CI/CD示例视为“教学案例”而非“强制配置”。AI通过学习这些案例，理解了CI/CD的基本概念和步骤。当需要为你的自建系统（如Jenkins）编写流水线时，AI依然能基于这个知识给出合理建议。你可以要求AI：“参考这个GitHub Actions的流程，为我们公司的Jenkins pipeline编写一个等价的脚本。”

6.4 性能与成本考量

• 顾虑：使用这么多技能，会让AI的响应变慢吗？
• 分析：技能文件是在对话开始时或按需加载到AI的上下文中的。加载大量技能确实会占用一部分上下文窗口。但现代大模型的上下文长度已非常可观（如128K、200K）。更关键的是，superpowers-zh的技能通过规范化流程，减少了无意义的来回对话和错误尝试，从整体上提升了任务完成效率，节省了总体的token消耗和时间成本。这是一种“磨刀不误砍柴工”的投资。
• 建议：不必一次性启用所有20个技能。根据你当前的项目阶段和主要痛点，选择性启用。例如，在需求设计阶段启用“头脑风暴”和“编写计划”；在编码阶段启用“TDD”和“系统化调试”；在合并代码前启用“代码审查”。

7. 进阶：定制属于你自己的技能

superpowers-zh的强大之处在于其可扩展性。项目自带的“编写Skills”技能，就是教你如何创造新技能的元技能。

定制技能的基本步骤：

1. 确定痛点：首先想清楚，你希望AI在哪个具体环节表现得更好？例如，“如何为我们的React组件库生成符合设计规范的文档？”
2. 模仿结构：在skills/目录下复制一个现有的技能文件夹（如brainstorming），重命名（如react-docgen），然后修改其中的README.md文件。
3. 定义工作流：在新技能的README.md中，清晰地定义：
   • 目标：这个技能要解决什么问题？（生成标准化的React组件文档）
   • 触发条件：用户说什么会触发它？（“为这个Button组件生成文档”或/docgen）
   • 核心步骤：分步说明AI应该怎么做。（1. 解析组件PropTypes/TypeScript接口；2. 提取组件描述；3. 生成Markdown表格展示Props；4. 添加使用示例代码块）
   • 输出示例：给出一段理想的输入输出对话示例。
4. 测试与迭代：在你的AI工具中加载这个自定义技能，进行测试。根据AI的实际表现调整步骤描述的清晰度和精确度。

一个简单的自定义技能示例：假设团队经常需要为API接口编写Swagger/OpenAPI文档，可以创建一个api-doc技能。其核心步骤可以是：

1. 要求用户提供API端点、方法、请求/响应示例。
2. 根据示例，自动推断并确认参数类型、是否必填、描述。
3. 按照团队模板，生成YAML格式的OpenAPI片段。
4. 提示用户将片段复制到指定的openapi.yaml文件中。

通过创建这样的自定义技能，你可以将团队内部的最佳实践和规范，固化到AI的工作流中，让每一位成员（包括AI助手）都能输出符合统一标准的高质量成果。