企业官网建设流程全解析

最近一段时间我一直在做一个对照组测试：把同一个功能需求，分别丢给裸奔状态的 Claude Code 和装了 Superpowers 的 Claude Code，看两边的产出差别到底有多大。结果很有意思。

裸奔那次，AI 大概两分钟就把代码写完了，跑起来也确实没问题，但所有逻辑全糊在两三个文件里，没有测试、没有错误处理说明、没有设计痕迹，就像一位把草稿纸直接交上来的同学。装 Superpowers 的那次，AI 先让我坐下来，问了我十几个问题，然后写了设计文档和 TODO，这才开始动代码——而且第一版代码甚至故意跑不过测试，因为按流程它得先证明测试是"真的在测"。

这个项目叫 Superpowers，是一个开源框架，专门解决一件事：让 AI 编程助手真正按软件工程的套路干活，而不是做一个"高级自动补全"。

1. 先聊痛点：为什么 AI 写的代码"能跑但扛不住事"

1.1 缺的从来不是语法，而是工程纪律

现在编码 AI 的能力已经很可怕了，主流模型对常见框架、标准库的掌握程度超过大多数初级工程师。但你把一个稍微像样的需求丢给它，它最常见的表现是什么？一股脑把代码写出来，然后告诉你"完成了"。你跑一遍，功能确实能用，可你不敢往生产环境放。

原因不是你用的这个 AI 水平差，而是它的工作方式里，压根没有软件工程这一层约束。

人类程序员能持续稳定地交付项目，靠的不是敲键盘快，而是一套看不见的流程纪律：拿到需求先确认边界，写方案前先想数据结构和接口，动手前先拆任务，改代码之前先想怎么验证改动。这套东西在学校叫"软件工程"，在工业界叫"研发流程"，在团队里则是一堆规范、设计评审、代码评审的集合。AI 编程助手再强，如果不遵守这套流程，它产出的代码就永远是"能跑但扛不住事"——后续加需求会乱、别人接手会骂、回归测试一跑全崩。

1.2 软件工程套路到底是哪些"套路"

我在带团队的时候，经常把一套标准研发套路浓缩成这么几个环节：

• 需求澄清：不急着写代码，先搞清楚要解决什么问题，给谁用，边界在哪。
• 方案设计：定接口、定数据模型、定模块划分，先让方案经得起推敲。
• 任务拆解：把大功能拆成可独立验证的小步骤，排好依赖顺序。
• 测试先行：先写失败测试，再写实现代码，确保每一行逻辑都有验证依据。
• 变更验证：代码写完不算完，要过测试、过静态检查、过人工复查。

这些步骤在人类团队里靠会议和评审表强制执行，但对 AI 编程助手来说，除非你明确告诉它"必须这样做"，否则它会默认跳过所有中间环节。Superpowers 的切入点就在这里：它把上述工程套路，做成了 AI 能读、能执行、能按部就班走的"技能包"。

1.3 Superpowers 切进去的位置

如果你只是给 AI 一句"请用测试驱动开发写这个功能"，它大概率会在同一个回答里把测试和实现一起给你——因为大模型不理解"步骤"和"纪律"，它只理解"用户的即时指令"。而 Superpowers 做的事，是把工程流程固化成一系列会被 AI 自动加载的指令文件。它相当于给 Claude Code 装了一套"行为准则"，让 AI 在开工之前，先经历"问需求、写方案、列计划"这些关卡。

所以我更愿意把它称作"AI 的工程外挂"，而不是某个具体的开发工具。

2. Superpowers 框架解剖：不是 IDE，也不是插件，是"技能包"

2.1 这个项目是怎么来的

Superpowers 的发起人是 Jesse Vincent，他在开源圈挺有名，早期做过 Perl 相关工具和 Bugzilla 的维护工作。他做 Superpowers 的动机很朴素：天天看 Claude Code 写出又快又乱的代码，觉得这不是模型智商的问题，而是工程习惯的缺失。于是他开始写一系列扩展 Claude Code 行为的"技能"文件，并在 GitHub 上开源，项目名叫 superpowers。

这个项目很快在开发者社区火起来，核心原因是它切中了大多数人的真实痛点：AI 生成代码的效率有了，但流程质量没人管。Superpowers 刚好补上了"流程质量"这一课。

2.2 核心机制：Claude Code 的 Skills 体系

要理解 Superpowers，先得理解 Claude Code 的 Skills 机制。简单说，Claude Code 支持在项目里放一个.claude/skills目录，里面每个子目录就是一个技能。每个技能至少包含一个SKILL.md文件，文件头部用 YAML 格式写技能的name、description、when_to_use等元信息，正文部分则是具体的操作指令。

Claude Code 启动后会自动扫描这些目录，当对话内容匹配到某个技能的描述时，AI 就会把该技能当作行为准则来执行。这个过程有点像人类员工入职时拿到一本《团队工作手册》，手册里写明"凡是接到需求，必须先做需求澄清、再写设计文档、之后列 TODO"——AI 照着这本手册办事。

Superpowers 就是把几十个这样的技能组织起来，做成了一个"软件工程工作手册"大礼包。

2.3 从 v1 到 v2：从手工复制到命令行管理

早期的 Superpowers v1 是手工往.claude/skills目录里复制文件，用起来麻烦，更新也麻烦。到了 v2，项目改成了一套完整的脚手架工具，核心命令就是npx superpowers。装好之后，你可以在 Claude Code 对话里直接触发安装、更新、创建工作区等操作，也可以在终端跑命令选择要生成的"工作区向导"。相比 v1，v2 的安装和升级都省心很多，这也是我推荐直接上 v2 的原因。

值得一提的还有它的"第三方技能"机制。Superpowers 不只自带技能，还支持把社区里其他人写的技能也装进来。这意味着团队的工程规范可以沉淀成技能，持续积累，而不是每次都在提示词里重复描述。

3. 从零跑通：装上 Superpowers 后的第一场对话

3.1 安装的前置条件与步骤

想跑通 Superpowers，首先得有 Claude Code 的可用环境。大致条件如下：

• 装有 Node.js 18 及以上版本。
• 本地有 Claude Code CLI，并且账号有可用订阅。
• 网络能正常访问 Anthropic 的服务。

安装本身不复杂。在 Claude Code 的对话窗口输入/install-superpowers一类命令，或者直接在终端执行npx superpowers，然后按菜单引导操作。安装完成后，Superpowers 会在你的工作目录里生成对应的技能目录和引导文件。具体命令的细节建议以项目 README 为准，因为这类开源工具的更新节奏确实快，我写文章时能用，过两个月可能又变了。

3.2 初始化工作区：它会先问你"你要干什么活"

装好之后，第一次进入新项目，Superpowers 会让你选择一个工作区类型。这一点我觉得设计得很妙——它不是在帮你写代码，而是在帮你确立"工作方式"。编码项目选 "Writing Code"，如果是帮别人审查代码就选 "Reviewing Code"，写技术博客、做研究、写书也各有对应的工作区。

选定之后，Superpowers 会在项目里生成类似CLAUDE.md的指导文件，相当于一份"给 AI 的岗位说明书"，约定了它在当前项目里要怎么干活。以后每次启动 Claude Code，它都会先读这些约定，再开始正事。

3.3 一次真实的 Brainstorming 对话拆解

我第一次用 Superpowers 做新功能时，给它提的需求是："做一个标签管理系统，支持增删改查和批量打标。"

你要知道，裸奔的 AI 听到这句话，第一反应绝对是列目录结构、写代码。但 Superpowers 引导下的 AI 第一反应是——问我问题。

它问的问题包括但不限于：

• 标签是一维的还是支持层级嵌套？
• 标签需不需要按用户隔离，还是全局共享？
• 批量打标的上限是多少？一次打多少个标签？
• 标签删除之后，已经关联的数据怎么处理？
• 这个功能的成功标准是什么？做到什么程度算"能用"？
• 有没有历史数据需要迁移？

我当时心里想：好家伙，这比团队里某些新同学还认真。这些问题其实就是在做需求澄清。它不急着落代码，先把边界逻辑问清楚，避免我"以为它懂了"。

3.4 设计文档和 TODO 是怎么生成的

问题问完，Superpowers 并不会立刻说"好的我开始了，你等着"。它会把我们讨论的结论整理成一份设计文档，文档里包含问题陈述、目标与非目标、方案对比、接口设想、数据模型、测试策略、风险点等模块。然后它会把实施过程拆成一条条 TODO，明确依赖顺序。

接下来才是写代码环节。而且写代码也不是一股脑梭哈，它是按 TODO 一条条来，每完成一步就验证一步。

我第一次跑完这个流程的真实感受是：AI 更像一个project manager + 程序员的组合体，而不是一个"打字极快的后端开发"。

4. 核心工作流拆解：从"一句话需求"到"带测试的完成品"

下面把这个框架最核心的工程工作流，按环节拆开讲。这部分是 Superpowers 的精华，也是大多数人最容易忽略的地方。

4.1 第一关：把模糊想法逼成 PRD

很多开发者的习惯，是拿着半句话就去找 AI 写代码。结果 AI 写出了你以为你想要的东西，但实际不是。Superpowers 的 brainstorming 技能就是专门治这个毛病的。

它会要求 AI 在写设计文档前，至少和用户进行多轮问答。问题涵盖目标用户、使用场景、边界条件、异常流程、性能预期、成功标准等。回答完之后，它产出的是带明确验收标准的 PRD 级别的描述。有了这个，后面无论谁接手，都能知道"这功能当初为什么这么做"。

4.2 第二关：设计文档先行，代码靠后

在传统软件工程里，设计文档是评审的依据。在 Superpowers 的流程里也一样。它生成的设计文档包含完整的方案对比：为什么选这个数据模型而不选另一个，接口为什么这么定，潜在风险是什么。这些内容不是摆样子，它会后续指导 AI 自己的编码行为。

有一个细节很值得提：因为设计文档先行，AI 在写代码时会不断回看文档，确保实现和设计不跑偏。这一点比很多人类程序员都规范——不少人类写代码是写着写着就偏离了当初的设计，最后文档是文档、代码是代码。

4.3 第三关：TDD 循环是怎么被执行的

Superpowers 内置了专门的 TDD 技能。它执行测试驱动开发的方式比大多数人类团队还严格：

1. 从 TODO 列表里挑下一个行为点；
2. 先写这个行为点的失败测试；
3. 运行测试，确认它是真的失败（红灯）；
4. 写刚好让测试通过的最小实现代码（绿灯）；
5. 进行重构，再跑测试确认没有破坏行为；
6. 进入下一条 TODO。

为什么说它严格？因为如果 AI 跳过了"先确认测试失败"这一环，它的 TDD 就是假的。Superpowers 的指令里明确要求 AI：不要先写实现去凑测试。这一步执行到位，测试就真的变成了安全网，而不是摆设。

4.4 第四关：验证与提交流程

代码写完了，Superpowers 还有一个验证变更的技能。它会跑测试、跑 lint、检查是否有未处理的异常、确认代码格式一致，甚至会让 AI 以"代码审查者"的身份重新审视自己写的代码，发现问题再回头修。这个流程走完，提交的代码质量和裸奔时完全不是一个量级。

4.5 有无 Superpowers 的差别对照

5. 用了一阵子的真实感受：收益、损耗与避坑

5.1 代价一：token 消耗确实变高了

先说最直观的代价。走了完整流程之后，对话轮次明显增多，每个功能都会经历问答、写文档、列 TODO、TDD 循环、自审这些环节，token 消耗比裸奔高出不少。我是开高订阅档的，用起来还行，但如果你的订阅额度有限，或者项目很小很小，这个开销就要掂量一下。

我的建议是：别把 Superpowers 用在零碎小改动上。改个文案颜色、加个按钮跳转，直接问 AI 让它快速改了就好。遇到完整功能、模块、或项目初始化，再把它"请出来"走全套流程，性价比最高。

5.2 哪些场景该开，哪些场景别开

结合我自己的项目经验，整理一个适用边界：

• 从零开始的中型项目：极力推荐。框架能帮你把项目骨架、目录约定、测试体系一次性建立起来。
• 给老项目加新功能：可以开，但要先做"理解现有代码"这一步，否则 AI 会按它自己的理想结构去设计，与老代码风格冲突。
• 一次性的脚本/原型：别开。你只是验证一个想法，流程文件反而碍事。
• 大型 monorepo：慎开。Superpowers 会让 AI 读很多上下文，仓库太大时容易触上下文窗口上限。需要配合 ignore 规则，限制它只看相关模块。

5.3 团队怎么把规范接进去：自定义 skill

Superpowers 给我最大的启发，其实是"技能包"这个模式本身。我们团队后来不满足于它自带的那套通用工程流程，于是把自己的代码规范、提交信息格式、分支命名规则，都写成了自定义 skill 放进.claude/skills目录。效果很直接：每个新开的 AI 会话都会自动遵守团队规范，不需要我在每次对话里重复描述。

这个思路建议每个团队都试一下。你不用全盘照搬 Superpowers，可以只借它的机制，把"你们团队特有的规矩"固化成 AI 能执行的指令。比如说，你们要求错误信息必须带错误码，你们要求数据库变更必须写迁移脚本，你们要求接口文档同步更新——这些都值得变成一个 skill。

5.4 踩过的三个坑

最后分享三个我在实际使用中踩过的坑，供参考。

第一个坑是"文档与代码不同步"。Superpowers 会生成设计文档，但如果后续对话里 AI 改了设计而没更新文档，再往后它就可能会按旧的文档决策。我现在要求它在每个环节结束时，如果有设计方案变动，先同步设计文档再继续。

第二个坑是"流程僵化"。有时候需求其实非常明确，但 AI 还是按部就班问了十几个问题，效率反而低。后来我发现，你可以在对话里直接说"这个需求很清晰，我们跳过头脑风暴，直接走设计文档阶段"，它会尊重你的指示。说白了，框架是规定动作，敏捷度还是掌握在人手里。

第三个坑是"并发子任务失控"。Superpowers 支持把任务拆给 subagents 并行处理，听起来很美，但我在实际项目里遇到过一次并行任务之间改到同一份文件，产生冲突。现在我会控制并行粒度，只有在任务之间几乎没有文件交叠时才让它并行。

最后再分享一点个人体会

用 Superpowers 一段时间后，我最大的感受不是"AI 变聪明了"，而是"AI 的过程终于能让我跟住节奏了"。裸奔的 AI 是一匹快马，跑得快但容易跑偏；装了 Superpowers 之后，它更像一个有经验的老工程师，先跟你开会确认需求，回去画图，再排期，然后才开始动手写代码。你随时可以打开它留下的设计文档和 TODO，看到项目"现在进行到哪一步、为什么这么做"。

我甚至觉得，这套思想刚起步。边界还能继续外扩——把团队的架构评审意见、安全规范、发布检查清单都沉淀成 skill，AI 就能在写代码时自动规避太多前人踩过的坑。如果你也想让 AI 编程助手从"代码生成器"升级为"工程协作者"，Superpowers 是一个很值得上手研究的起点。