企业官网建设流程全解析

1. 快枪手与工程师之间，差的不是代码量而是纪律

这段时间我一直在琢磨一件事：AI编程助手普及得这么快，为什么我们写出来的代码，反而越来越像"一次性纸杯"——用完就扔，改动一下底层逻辑就全线崩盘？

我见过太多团队用Cursor、Claude Code这类工具提效，做法高度一致：把需求往对话框里一丢，AI唰唰生成几百行代码，能跑就提交。看起来效率拉满了，实际上是在给未来埋雷。真正改过几次需求的人都会有一种共同的感觉——AI写代码像个快枪手，出手很快，但完全没有工程师的章法，不懂什么叫"先想清楚再动手"，不懂什么叫"小步验证"，更不懂什么叫"别碰不该碰的代码"。

所以当我看到Superpowers这个框架的时候，第一反应是"终于有人着手解决这个问题了"。

Superpowers不是一个"写代码更快"的工具，它的定位恰恰相反：它是给AI编程助手装上的一套"软件工程行为约束系统"。核心思路是把测试驱动开发（TDD）、小步提交、频繁验证这些工程纪律，从"我们口头要求AI遵守"变成"AI工作流中不可跳过的硬性步骤"。换句话说，它不是让AI变得更聪明，而是让AI变得更守规矩。

这套框架最让我欣赏的地方在于，它承认了一个很多AI工具厂商不愿意承认的事实：大语言模型本质上是"token级的天才、项目级的健忘症患者"。它擅长在给定上下文中生成合理的代码片段，但它天然缺少工程师那种"对项目全局负责"的意识。而工程经验是不能靠模型"涌现"出来的，必须靠外部机制强制约束。Superpowers干的就是这件事。

这篇文章我会重点拆三件事：Superpowers的核心理念和机制、它跟传统AI编程方式的真实差异、以及我自己部署和使用的完整经验。给有同样困惑的开发者一条可以直接上手的路径。

2. Superworks最值钱的设计：把"先测后写"变成AI的肌肉记忆

有人可能会问：TDD这个概念，软件开发圈里喊了二十多年了，Superpowers凭什么能把它落到实处？这里有个关键差异——TDD对人类的难点是"坚持"，对AI的难点是"理解"。

2.1 人类和AI在TDD上的困难完全不同

有经验的工程师都知道TDD好，但真正严格遵守的人不多。为什么？因为人是有惰性的，写着写着就想跳过测试直接写业务代码，"反正功能就这么多，回头补测试也不迟"——然后这个"回头"往往永远不会发生。

AI则完全是另一个物种。你如果只是简单地告诉它"请用TDD方式开发"，它大概率会在代码里象征性地放一两个测试文件，然后继续大段大段地生成业务代码。这不怪AI，因为它根本没有"先写测试再写实现"的步骤感。对它来说，回答问题的惯性是"直接给出完整方案"，而不是"按流程一步步来"。口头约定在token预测面前不值一提。

Superpowers的解法很直接：把TDD拆成物理上不可跳过的关卡。它不是靠"建议"，而是靠"强制"。

2.2 工作流文件如何物理上约束AI的行为

我用过之后才明白，Superpowers最核心的机制其实是几个普通得不能再普通的Markdown文件。

以SKILL.md为核心的技能描述文件，会要求AI在每次会话开始后必须阅读并遵守其中定义的工作流规则。这看起来很简单，其实非常聪明——因为LLM的上下文窗口是有限的，AI不会主动记住上一次会话你叮嘱它"要写测试"的话。但你让它在每次开工前重新读一遍规则文件，它就会老老实实按流程走。

更具体一点，Superpowers的TDD工作流文件里写得很清楚：

• 第一步：先写一个失败测试，跑一遍它，确认红灯亮起
• 第二步：用最简单的方式让测试通过，跑一遍，确认绿灯亮起
• 第三步：重构，保持绿灯不灭

每个步骤都有明确的验收标记。AI如果跳过了某一步——比如没写测试直接写了实现——后续的检查环节就会直接指出来："当前状态不符合工作流要求，请回退到上一步。"这种机制跟人类教练在旁边盯着你复盘，本质上是一个道理，只是它把这个过程自动化了。

2.3 从"一次生成一大坨"到"一次只动一小步"

我的亲身体验非常直观。用普通模式时，我让AI"给订单模块加一个状态流转功能"，它会唰地给我生成一个完整的service类、两个枚举类、三个测试文件——听起来很美，但代码量大了之后，任何一个细节和现有代码风格不匹配，跑起来就是一堆编译错误，改起来简直是噩梦。

用Superpowers之后，同样是这个需求，AI的表现完全变了。它会先问我"当前订单状态有哪些？流转规则是什么？边界条件如何处理？"，然后说"我建议先写三个测试：正常流转、非法状态流转、重复流转，我们先从第一个开始"。然后它真的只写了一个失败的测试，让我运行确认，再一行一行地写实现，再运行确认。整个过程像在做外科手术，而不是兜底大甩卖。

这种体验上的改变，往深了说，是从"追求输出量"转向"追求验证密度"。AI每次只走一小步，每走一步都经过测试验证，错误成本被压缩到极小。即使AI最后整体思路有偏差，损失也只是一两行代码，而不是几百行。

3. 拆开Superpowers的引擎盖：SKILL.md、叙事文件与三道护栏

说完了理念，来点硬核的。Superpowers的工程结构并不复杂，但你理解了它的三个核心组件，就完全理解了这个框架为什么管用。

3.1 SKILL.md——给AI的"岗前培训手册"

SKILL.md是Superpowers的入口文件，相当于给AI的"角色设定书"。AI每次启动工作会话时，都会被要求先读取这个文件。

里面规定的不只是"你要写测试"这种笼统要求，而是非常具体的操作协议。我挑几个印象深刻的条款：

• 代码必须通过编译或运行验证，不得假设代码的正确性
• 遇到未定义的行为时，必须先向用户询问而不是自行猜测
• 每次修改必须明确说明改动范围，不允许"顺手"改动无关代码
• 测试是代码的一等公民，没有测试的代码变更不算完成

这些规则听起来平平无奇，但关键在于Superpowers把它们做成了用户与AI之间的协议。当你发现AI在某个环节偏离了这些规则，你可以明确指出来，AI会根据SKILL.md的定义自我纠偏。这种"成文规则"比临时在对话里叮嘱AI有效得多，因为你不需要每次都重复要求，规则已经固化了。

3.2 叙事文件——给AI装上一个"项目级大脑"

这是我觉得Superpowers整个框架里最有创意的机制，没有之一。

大语言模型最大的短板就是"记忆漂移"。它能记住上下文窗口内聊的内容，但一旦超过上下文限制，或者开启新会话，它对你项目的理解就归零。Superpowers用了一种极其朴素的方案解决这个问题——把重要决策写进文本文件，需要的时候让AI去读。

具体来说，Superpowers会维护一个叙事文件，记录这个项目的关键决策、已经完成的工作、踩过的坑、下一步计划。AI每次开工前，会被要求先读这个文件，理解项目当前处于什么状态，再开始干活。干完之后，它还会被要求把这个文件更新一遍，把新做的决策补进去。

这个概念叫"Append-only Log"风格的状态维护，本质上就是把大模型那点可怜的隐式记忆，转存成显式的、可检索的、跨会话的项目资产。我当时看到这个设计的第一反应是：为什么我没有早点想到这个办法。它太朴素了，朴素到让人觉得好像也没啥技术含量——但实际用起来，那个价值是实打实的。

3.3 三道护栏：红线校验、步骤校验、范围校验

Superpowers在机制层面对AI的行为设置了多种防护手段，我用下来觉得最核心的是三道护栏：

第一道：命令和操作的红线校验。AI要执行某些敏感操作——比如批量修改文件、强制移除文件、大范围重构——必须先获得用户确认。这不是简单的"Yes/No"对话框，而是会让AI明确说明"我要做什么、为什么要做、影响范围是什么"，只有确认通过才能执行。

第二道：工作流步骤校验。在TDD流程中，AI如果试图跳过某个步骤，比如从"写失败测试"直接跳到"写重构代码"，工作流规则会拉它回正确轨道。这保证了工程纪律不是挂在嘴上的，而是卡在流程节点上的。

第三道：影响范围校验。AI经常会犯一个毛病：改一个bug的时候，顺带把格式给"优化"了，把变量名给"改进"了——这给代码审查带来巨大困扰。Superpowers的规则里明确禁止这种"顺手改动"，要求每一次变更的diff范围与任务描述完全一致。这条规则在代码审查场景下价值极大。

这三道护栏组合起来的效果，就是把AI从"天马行空的生成器"变成了"循规蹈矩的执行者"。

4. 用一张表看清Superpowers和"直接生成模式"的差距

很多人对Superpowers的第一反应是"太麻烦了"，"我直接让AI一次写完整块代码不香吗"。我理解这种感受，因为我自己一开始也是这么想的。但当你把两种模式放在一起对比，你会发现"一次写完整块代码"只是一个错觉——它看起来很高效，其实把风险全部堆到了集成阶段。

下面是基于我个人使用经验整理的对比：

我重点聊一下"错误发现时机"这一行。传统模式下，AI生成200行代码，你跑起来发现3个错误，你觉得问题不大，但你要知道这三个错误分布在200行代码里，你得一个个排查上下文才能定位。Superpowers模式下，你最多走10行代码就验证一次，就算出错，你几乎能立刻知道是刚刚哪几行引入的问题。这个调试成本的差异，在日常开发里被严重低估了。

还有一点值得注意：直接生成模式下的AI代码，看起来完成度很高，但代码风格往往和你团队已有代码有细微出入——比如命名规范、错误处理习惯、日志风格。这些差异单看不严重，但累积多了，代码库就变成"AI写的"和"人写的"两个割裂的世界。Superpowers的小步提交模式，让你可以在每步生成时及时纠偏，代码风格的一致性明显更好。

5. 从零部署Superpowers：克隆、安装、适配自己的SKILL

理论说了一堆，真正上手才是关键。这一节我把我自己部署Superpowers的完整路径写出来，照做基本不会出问题。

5.1 环境准备和安装步骤

Superpowers目前对Claude Code的支持最成熟，其他兼容Agent工具也能用，但体验上以Claude Code为基准。我的环境是macOS，终端使用zsh，Python要求3.10以上。如果你的系统是Linux或Windows的WSL，操作基本一致。

安装步骤如下：

# 进入你的工作目录，克隆项目 git clone https://github.com/obra/superpowers.git # 进入项目目录 cd superpowers # 查看安装说明 ls

Superpowers的EXPLAIN.md和INSTALL.md文件会说明当前版本的具体安装方式。我部署时的流程是：

1. 将仓库中的技能目录（skills目录）复制到你的AI助手可读取的路径
2. 在AI助手配置中注册Superpowers的技能文件
3. 在你自己的项目目录下初始化工作目录结构
4. 运行一次自检，确认AI能正确读取SKILL.md

第二步需要特别提醒：不同AI工具的技能目录路径不一样。Claude Code的话，通常是~/.claude/skills。如果你用的是其他兼容Agent，请参照其文档找到对应的skills路径。

5.2 我的部署日志：三次启动才跑通

第一次部署时我踩了一个挺典型的坑。当时我把skills目录复制过去了，但没注意到Superpowers的依赖说明里要求安装一个配套的Python脚本，用来做叙事文件的一些辅助操作。结果是AI能读到技能定义，但实际工作流里某些环节会卡住。后来对照安装文档补装之后才恢复正常。

第二次的问题是权限。我的工作目录在/Users/me/projects/xxx，但Superpowers的叙事文件默认可能写到~/.superpowers下。如果配置没对上，AI会在会话中找不到叙事文件，表现就是它每次开始"忘记"了之前的所有决策，反复问一些已经定过的事情。这个问题的排查要点是检查环境变量和路径配置。

第三次终于跑通了。完整的过程是：克隆仓库、安装依赖、初始化技能目录、写了一个最简单的测试项目验证工作流。整个过程大概用了40分钟。对于一个习惯了"装上就能用"的开发者来说，这个上手成本不算低，但和我后来省下的调试时间相比，完全值回票价。

5.3 一定要修改SKILL.md，不要原样照搬

如果你把一个默认的SKILL.md原样扔进你的项目，你会发现它描述的很多规范和你的实际场景是冲突的。比如默认SKILL可能规定每次提交前必须跑全量测试，但你的项目可能压根没有测试基础设施；再比如默认工作流可能要求所有命令都经过用户确认，这对一些高频操作来说效率很低。

所以，部署完成后第一件事，是把SKILL.md通读一遍，把那些不适应你团队情况的内容改掉。我自己改的几条示例：

• 把"必须使用pytest"改成"优先使用项目中现有的测试框架"
• 把"所有文件修改必须经过确认"改成"只有涉及删除或重构的操作需要确认"
• 增加了一条："代码风格以项目内现有代码为准，不额外引入新的风格约定"

这一步非常关键，它决定了Superpowers是会成为你的效率工具，还是成为你的流程绊脚石。框架是死的，规则是活的——Superpowers能跑起来，靠的就是这份可以被定制的工作流文件。

6. 别急着全盘照搬：Superpowers的适用边界与实战取舍

任何一个工程工具都有它的适用半径，Superpowers也不例外。用了一年多之后，我的判断是：它是一把精良的手术刀，但你不可能用它来劈柴。下面说说我的边界体会。

6.1 适合的场景：有持续演进诉求的项目代码

这类场景大致有三类：

第一类是业务逻辑复杂的后端服务。比如订单、支付、权限这类模块，它们的特点是状态多、规则杂、改错代价高。TDD加小步验证在这里的价值最大，因为每一行实现逻辑都有测试兜底，重构和扩展时心里有底。

第二类是长期维护的开源项目或公司核心代码库。这种代码库对代码风格一致性要求极高，对变更范围有严格要求。Superpowers的"范围校验"和"小步提交"正好对症。

第三类是团队协作场景。你可能和多个开发者共享一个代码库，AI生成的代码如果有严格TDD流程和diff范围控制，代码审查的效率会高很多。

6.2 不适合的场景：探索性工作和一次性任务

有一种场景我建议不要硬套Superpowers，那就是"我还没想清楚要什么，先跑起来看看"的探索阶段。这时候你用TDD反而是负累——测试都无从写起，自然也就谈不上"测试先行"。我自己的做法是：探索阶段用普通的AI生成模式，快速验证想法；一旦想清楚了、决定做一个正式模块了，再切换到Superpowers的TDD流程重写。这个两段式策略用下来很顺手。

还有一种场景是模型能力本身不太够的时候也别指望Superpowers救场。比如你用的AI模型本身代码能力弱，那TDD流程只会让它在"写一个不会通过的测试"这一步就卡住。Superpowers的前提是——模型先得有基础的代码生成能力，框架解决的是工程纪律问题，不是能力问题。

6.3 我这段时间的真实体会

用了Superpowers之后，我发现自己提需求的习惯也在变。以前我会说"帮我写一个XX功能"，现在我会主动说"我们先定义一个失败的测试，目标行为是XX"。这个转变本身，就是软件工程思维在起作用。

另外有个小细节提醒一下：如果你打算在自己团队里推Superpowers，建议先让一个人用透，再考虑复制给所有人。因为它会显著改变你和AI协作的方式，如果团队里只有你一个人懂这套工作流，别人看你的提交记录会觉得"代码量怎么变少了"——你需要能解释清楚"代码量变少是因为每一行都是经过验证的"这个逻辑。

工具是工具，工程是工程。Superpowers的意义不在于它本身有多高级，而在于它找到了一个把工程师多年积累的"肌肉记忆"翻译成AI能理解和执行的工作流文件的方式。这个方向，我是很认可的。