企业官网建设流程全解析

1. Superpowers框架是什么：给AI助手装上软件工程的“职业素养”

先说结论：Superpowers是一套开源的工作流与技能框架，专门用来约束和引导AI编程助手（比如Claude Code、Cursor这类工具）按照规范的软件工程流程干活。它的核心目标是把“任务分解、测试先行、增量交付、纪律性代码审查”这些本来只存在于资深工程师脑中的做事套路，显式地写进AI的工作指令里。

这几年AI编程助手用下来，我相信很多人都有类似的体验：写个工具函数、补个单元测试，AI确实很快；但一旦碰上跨模块改造、重构老代码、或者要在一周内稳定交付一个完整功能，AI就很容易“自由发挥”——一口气生成一大堆代码，不写测试，不拆步骤，出了问题直接从头推倒重来。这种失控感的根源，不是模型能力不够，而是我们从来没有告诉AI“该按什么顺序、用什么规范、以什么粒度去做事”。Superpowers恰好补上了这一块。

它能做的事情，概括起来有三层：

• 给AI提供明确的工作流模板，比如TDD（测试驱动开发）工作流、重构工作流、代码审查工作流，AI拿到任务后会先按模板走，而不是直接开写。
• 提供一组标准化的技能（Skills），比如文件编辑、Shell执行、测试运行、Git操作，每个技能都附带了详细的约束和调用说明，减少AI“瞎猜命令”的概率。
• 通过项目上下文文件（如CLAUDE.md）实现项目级规范的持久化，让AI每次进入会话时都能回忆起团队的工程约定。

适合谁来用？如果你手头有AI编程助手的订阅，日常已经用它写了不少代码，但总觉得“AI写的代码不敢直接合入主线”，那么这套框架很值得花半小时试试。Master分支强迫症患者、团队里有代码规范但AI总是不遵守的人、以及带新人但不想重复讲解开发流程的Tech Lead，都会从里面得到实打实的帮助。

我在自己两个中型项目里实测了两周，最大的感受是：AI的“行为模式”变了。以前它像个聪明的实习生，你问什么它答什么；用了Superpowers之后，它更像一个带过多个项目的工程师，拿到需求会先列步骤、再动手，每一步都能对应到commit记录。这篇文章我会把框架的工作机制、落地步骤、以及我踩过的坑全部过一遍。

2. 核心设计思路拆解：它到底是怎么“管住”AI的

2.1 把工程流程“显性化”：工作流是框架的内核

Superpowers最核心的机制，是它把软件工程里最成熟的几套流程固化成了可被AI加载的“工作流文件”。每个工作流本质上是一个Markdown文档，里面写清楚了：这个流程适合什么场景、必须按什么顺序执行、每一步的输入输出是什么、哪些操作被明确禁止。

举个例子，TDD工作流。通常我们让AI写一个函数，它会直接给你实现代码和几个测试完事。但Superpowers的TDD工作流会强制它走这样的顺序：

1. 先写一个失败测试，描述期望行为。
2. 运行测试，确认它是红的（失败状态）。
3. 只写让当前测试通过的最小实现代码。
4. 再次运行测试，确认它变绿（通过状态）。
5. 停下审视代码，看是否需要重构，重构后再跑一次测试。

这个过程看起来简单，但对AI来说意义重大。因为大多数模型在生成代码时，倾向于“一次生成完整方案”，这导致测试和实现经常“互相迎合”——测试写得没意义，实现覆盖不到边界。工作流文件通过分步指令，强行打断AI的“宏大一气呵成”倾向，逼它进入迭代节奏。

我一开始也怀疑：这不就是写prompt吗？但真用下来发现区别很大。普通的prompt是一次性的，AI这次听了下次可能就忘；Superpowers的工作流文件会被反复加载、逐个步骤引用，等于把流程嵌入了AI的“工作记忆”。而且它是开源的，你完全可以改流程内容，比如要求“每个功能分支必须先更新CHANGELOG”，改完AI就会照做。

2.2 技能与上下文：让AI知道“用什么工具”和“项目规矩”

工作流解决的是“做什么、按什么顺序做”，技能（Skills）解决的是“具体怎么做更可靠”。

Superpowers里封装了一系列常用操作技能，比如：如何安全地编辑大文件（避免一次性覆盖整个文件）、如何执行测试并解读失败信息、如何使用Git命令来创建有意义的commit。每个技能都不是几行提示词，而是带使用条件、常见错误、调试建议的详细规范。

我举个例子。你让AI“修一下登录模块的bug”，没有技能约束时，它可能直接重写整个文件，然后告诉你“改好了”。而Superpowers里的编辑技能会要求：先定位到具体函数，做最小改动；改动后用diff检查；再运行相关测试确认没有破坏其他功能。这一套约束下来，AI的行为就从“写代码”变成了“改代码”。

上下文管理则是另一个关键设计。Superpowers会在项目的CLAUDE.md（或对应的助手记忆文件）中写入一整套工程约定，包括：代码风格偏好、测试框架、目录结构、禁用事项。AI每次启动会话时都会自动读取这些内容。这解决了一个特别实际的问题——很多团队让AI干活，前几次都好好的，但只要切换会话或者隔几天再继续，AI就“失忆”了，又开始按自己的偏好写代码。固定化的上下文文件，相当于给每一次AI对话都输入了同样的“入职培训”。

我还注意到一个细节：Superpowers对“规则”和“建议”做了明确区分。强制规则会使用类似“MUST”或“REQUIRED”的措辞，而建议则是“you may consider”这类软性表达。这种语义学设计并不是摆架子，因为大模型对强弱语气的响应差异非常大，明确区分能有效减少AI在关键约束上的“随机应变”。

3. 实操配置与落地步骤：把Superpowers接入日常开发

3.1 安装与初始化：五分钟完成基础接入

我使用的是Claude Code作为AI助手，这套步骤在其他支持规则文件加载的助手上大同小异。先说大前提：Superpowers不是以独立程序运行的，它更像一套“规则包+技能包”，通过配置目录加载到AI助手中。

首先，把项目克隆到本地。官方仓库地址我不赘述，直接git clone到任意工作目录即可。接着你会在目录里看到几个核心部分：rules/文件夹存放工作流文件，skills/文件夹存放技能定义，还有文档说明。我的做法是把rules/里的内容拷贝到自己项目的.claude/目录下，让助手项目级加载。

然后需要做的是合并上下文配置。打开项目根目录的CLAUDE.md（没有就新建一个），把Superpowers提供的初始化内容合并进去。这里要注意：不要整个覆盖你自己的项目说明，而是把工作流引用路径、技能启用声明、强制规则追加进去。我在合并时保留了原文档的“项目技术栈”和“模块说明”部分，只额外增加了Superpowers的工程流程部分，这样AI既能理解业务背景，又能遵守工程规范。

初始化完成后，先做一次验证。随便打开一个新的AI会话，输入一个最简单的任务：“请按TDD流程实现一个求数组总和的函数”。健康的响应应该是先给你一个失败测试文件，然后提示运行测试，而不是直接甩出实现代码。如果你得到的回复是“好的，这是代码”，那说明工作流没有正确加载，需要检查规则文件的路径是否正确。

最后别忘了做版本管理：把Superpowers的更新升级方式整理为一个独立文档，不要和业务代码混在一起。因为框架本身迭代很快，后续你可能需要经常同步上游的新技能，独立目录会让升级过程清爽很多。

3.2 用TDD工作流改造一个真实小任务

为了让你更直观地感受区别，我记录了一个真实任务的执行过程。任务本身很简单：给一个Python项目增加“从URL中提取域名”的工具函数。不复杂，但足够展示流程差异。

先看没有Superpowers时AI的典型行为：它会直接写出一个用urllib.parse实现的函数，顺带附上几个assert测试，一次搞定。代码大概率是对的，但测试是后补的，边界情况考虑得也不全。

而在Superpowers的TDD工作流约束下，执行过程是这样演进的：

第一步，AI生成的测试文件长这样：

# test_url_utils.py from url_utils import extract_domain def test_simple_url(): assert extract_domain("https://www.example.com/path") == "example.com" def test_no_subdomain(): assert extract_domain("https://example.com") == "example.com" def test_ip_address(): assert extract_domain("http://192.168.1.1:8080/index") == "192.168.1.1" def test_invalid_url_returns_empty(): assert extract_domain("not a url at all") == ""

注意第二步命令：AI此时提议运行这个测试文件。第一次运行时，url_utils模块根本不存在，测试会报ImportError，测试结果确实是红的。AI会在输出中明确标注：预期失败，符合TDD第一阶段。

第三步，AI才开始写实现。但它只写了能够让测试通过的最简单代码，不会过度设计：

# url_utils.py from urllib.parse import urlparse def extract_domain(url: str) -> str: try: parsed = urlparse(url) if parsed.scheme and parsed.netloc: return parsed.netloc.split(":")[0] return "" except ValueError: return ""

第四步，再次运行测试，全部变绿。第五步，AI停下来说：“当前实现已过全部测试，建议补充对www.前缀去重和国际化域名的进一步用例，但当前改动满足需求。”然后它主动创建了commit，提交信息是Add extract_domain function with TDD tests。

这个过程的含金量不在于代码本身——那很基础——而在于AI的行为节奏。每一步都有明确的执行依据，测试先于实现，实现以最小改动为原则，最终提交与测试结果可追溯。这就是“按软件工程套路干活”的直接体现。

3.3 自定义技能与规则：把团队规范也塞进去

框架自带技能已经很实用，但我更推荐花点时间做自定义，因为团队规范才是真正能拉开效率差距的东西。

自定义的方法并不复杂。在Superpowers的技能目录下新建一个Markdown文件，给它取名team-conventions.md，然后在CLAUDE.md里加上一句引用。内容上我写了三块：一是“所有用户可见文案必须中英分离，不得硬编码在业务逻辑里”；二是“不允许多个模块直接引用同一个数据源，必须走服务层”；三是“提交信息必须包含对应需求单号”。这三条都是我们团队真实存在的规范。

加了之后，最明显的变化是AI代码评审（code review）时给出的建议不再泛泛而谈。以前它会说“建议增加错误处理”，现在它直接指出“这个函数直接读取数据库违反了服务层隔离规则，应该调用UserService”。对于团队协作来说，这等于给所有的AI辅助开发配了一把统一的标尺。

不过我也想提醒一句：自定义技能不要贪多。每加一条规范，都会多消耗AI的一部分“注意力预算”，加得太多会导致它对关键流程的执行反而变弱。我个人的经验是最多维护五到八条核心规范，超过的部分放进“参考文档”而不是“强制规则”，让AI按需读取。

4. 绕坑指南与故障排查实录

4.1 我遇到的四个典型问题，以及对应的处理办法

这周实际使用中我记下了几个比较典型的问题，写成对照表，方便你直接照着查。

第一个问题最普遍。一个朋友也曾跑来问我说“我配了规则，但AI就是不听”，远程帮看之后发现，他把Superpowers的规则文件放进了仓库但忘记在CLAUDE.md里写引用指令，相当于把合同锁在保险柜里，却没告诉对方钥匙在哪里。规则文件的加载必须有显式引用，不是放进目录就生效，这个点特别容易踩。

第二个问题的本质是上下文窗口有限。AI助手单次能记住的内容量有上限，当项目说明、代码内容、历史会话加到一起过长时，早期加载的工程规范被“挤”出了有效的注意力范围。我自己的对策是把最关键的流程指令做成一页纸的长度，确保任何时刻都能被覆盖到；更细节的规范则拆散到具体技能文件里，在需要时按需加载。

第三个问题值得展开。TDD流程中AI看似在“先写测试”，但有些模型会打擦边球——测试里写了错误断言，跑起来失败，但失败原因跟业务逻辑完全无关。比如复现我遇到的这个情况：AI给一个排序函数写测试，预期结果写错了，那测试当然失败，但失败的根因是“测试本身的断言写错”，而不是“函数未实现”。如果没有强制“确认测试失败原因就是缺失的功能”这一步，整个TDD节奏就变成了给“错误的期望”写实现。所以我后来在自定义规则里明确加了一条：测试运行失败时必须输出失败原因，并且由我（开发者）确认为预期失败，才能进入实现阶段。

4.2 让AI“记住”规范的三条长期心得

基于这段实践，我沉淀了几条长期有效的心得，不一定都写在官方文档里，但实际帮助很大。

第一，规则也要做“代码评审”。不要以为给AI写完规则就一劳永逸，规则之间会产生冲突，规则本身也会过期。我每两周会专门开一个会话，问AI：“请列出当前所有加载的规则，指出有歧义或冲突的地方。”这比我自己翻文件高效得多，因为AI能直接告诉你逻辑链路。

第二，用“负面案例”代替“抽象指令”。人类工程师讲“要写出高质量代码”，AI根本抓不住重点；但如果你告诉它“不要复制粘贴重复代码，不要用魔法数”，遵守率会大幅上升。我在团队的工程规范里加入了三个我们实际踩过的负面案例，AI全部记住了。这个技巧也适用于所有自定义规则。

第三，工作流不要设计成“万能流程”。AI每次只能做好一件事，如果给它的流程包含二十个步骤，它就会倾向于“选择性地遗忘”其中一部分。把一个大流程拆成三到四个小型专用工作流，比一个万能工作流可靠得多。比如我把“功能开发”拆成了“TDD实现流程”和“重构流程”，同时让AI自行判断应该走哪条，实测下来比混合在一个流程里灵活不少。

5. 从Superpowers延伸出去：它与主流Agent框架有何不同

最近Agent相关的框架讨论很多，LangChain、Dify、CrewAI这类名字频繁出现。一开始我也困惑：Superpowers不是也能编排任务、调用工具吗？它跟Agent框架到底什么关系？实际用了之后，我理清了两条线索。

LangChain、CrewAI这类框架，核心解决的是“AI如何自主规划和调用工具链”的问题，它们更像一个任务编排引擎，允许你定义多个Agent协作、规划执行路径、接入外部API。而Superpowers的出发点完全不同：它没打算让AI更“自主”，反其道而行之，让AI更“守规矩”。它不关注AI能规划多复杂的任务，而是关注AI在执行每一步时是否遵守工程流程。换句话说，Agent框架是放大器，Superpowers是刹车片和方向盘。

这个区别决定了选型思路。如果你的痛点在于“AI不知道该怎么完成一个复杂任务”，那么LangChain、CrewAI可能更对症；如果你的痛点在于“AI知道怎么做但做出来风格很野，不靠谱、不遵守规范、测试老缺”，那么Superpowers的约束机制更合适。两者也不是互斥的：在Superpowers约束好的流程内，你可以再挂一层Agent工具来增强外部信息检索和API调用，前提是必须在规则里明确放行哪些工具、哪些操作必须人工确认。

另外补充一个容易混淆的认知：Superpowers不是“提示词模板”合集，尽管它最初看起来就是一摞Markdown文件。它和普通prompt工程之间最大的区别是结构性和可维护性。提示词模板是一次性消费品；Superpowers把工程流程变成了项目资产的组成部分，它有自己的目录结构，能够被持续修改，能够被复用到多个项目，甚至能和团队协作者共享同一套规范。这种“把流程写成资产”的思维方式，其实比框架本身更有启发性。

6. 写在最后的一点个人体会

如果把Superpowers浓缩成一句话，我会说：它解决的不是“AI能不能写代码”，而是“AI能不能靠谱地在团队里协作”。我个人的实际感受是，用了它之后，代码审查中需要我纠正AI的琐碎问题明显变少，尤其是测试覆盖和提交信息规范性这些容易被忽略的环节，AI终于不用反复提醒了。

我记得刚接入框架的第一天，看着claude在实现一个功能前先认真敲出失败测试，再一步步推进的时候，突然有一种“终于有人把我工作中的隐性流程显性化”的慨叹。也许这就是这类工具存在的意义：不再逼AI做全知全能的天才，而是训练它做一丝不苟的同行。

最后分享一个小技巧：如果你在团队推行Superpowers，别让所有规则一次性全量落地。先选一个项目、挑一个核心工作流（比如TDD）、固定一个“被禁止的事项”，跑两周，让团队和AI都适应节奏，再渐进式加入更多规则。快速铺开的失败率远高于小步迭代，这跟带新人的道理如出一辙。