企业官网建设流程全解析

最近几个月，我用AI编程工具写代码的时间，比手动敲键盘的时间还多。最直观的感受是“快”：需求一讲，代码马上就出来了，看起来像模像样，跑起来也能完成主流程。但真正让我睡不着觉的，也是这些“快”。功能改完了，旁边被连带改掉的配置没人发现；测试全绿了，绿的原因是断言写反了；做到一半断了会话，新开的AI完全不知道前面干了什么，乱接一段继续干。这就是典型的“快而不稳”：速度上来了，可靠性反而成了最大的短板。

直到我上手了Superpowers，才慢慢把这两件事重新对齐：速度可以保留，但过程必须可控、结果必须可验证。它不是另一个IDE，也不是代码生成器，而是一套和AI编程工具配合使用的技能框架，核心思路是让AI在一个可见的状态机里干活：先列计划、再写测试、小步实现、如实汇报。这篇文章，我就从“为什么AI编程不可靠”这个痛点讲起，把Superpowers的安装、核心机制、完整工作流，以及我实际踩过的坑，一次性说清楚。

1. 快而不稳：AI编程的“速度快”正在透支“可信度”

1.1 为什么AI写代码很快，却总让人心里没底

先说个扎心的结论：AI写代码快的本质，是它把“生成代码”这件事做得太好了，但把“编程”的其他环节——理解上下文、确认边界、验证结果、维护一致性——做得并不可靠。

普通对话式AI编程的流程通常是这样的：你丢一句“帮我加一个导出功能”，AI直接改代码，改完回一句“已完成”。如果你不问，它不会主动告诉你改了哪几个文件，也不会告诉你它默认删掉了某个不相关但“看起来没用”的函数。问题是，代码不是文字。文字写错了，读者最多理解偏；代码改错了，轻则编译失败，重则线上事故。

我把这比作让一个手脚麻利的实习生直接改生产代码：他速度快，但你没有给他交代验收标准，他也没有任务清单，更不会主动汇报风险。结果就是，他交上来一个“他认为完成了”的东西，而你在验收时才发现，所有你认为“理所当然该保留”的东西，都被他的“合理性判断”处理掉了。AI的不靠谱，本质上不是能力问题，而是过程不可控的问题。

1.2 我反复踩到的三次典型翻车

这里说三个我真实遇到过的案例，基本代表了“AI编程不可靠”的三种典型形态。

第一次是改导出功能的时候，AI顺手删掉了另一个模块里“看着没被引用”的常量，结果那个模块在特定配置下直接崩了。报错信息出来以后，AI自动进入“自我修复循环”：先加一个兼容层，再改一个调用方，然后又发现两个新错误，再改……最后它交出来的代码，能跑通测试，但整个改动涉及了完全不该动的六个文件。

第二次是测试假阳性。AI写了个测试，跑了一下说“全部通过”。我后来检查发现，测试里的断言比较的是两个相同的临时变量，相当于自己和自己比。这比不写测试更危险，因为它在给你制造“好像很可靠”的错觉。

第三次是长任务中断。在一个大一点的改动里，做到一半我把会话关了。第二天重新开了一个新会话，AI完全不知道昨天的进展，照着旧代码继续写，把已经改好的部分又覆盖了一部分，最后整个工作区处于一种“两套逻辑混在一起”的状态。

这三个案例，问题都不在“生成速度”。就算AI生成快十倍，只要过程不可控、结果不可验证，这些坑就会换个面目继续出现。所以真正需要改变的，不是换更强的模型，而是给AI一个可执行、可追踪、可审批的工作规范。Superpowers就是冲着这个问题来的。

2. Superpowers是什么：一套给AI的“工作规范”，不是一个IDE

2.1 它到底解决了什么问题

很多人第一次听到Superpowers，会以为它是一个编程IDE，或者一个代码补全插件。实际上，它是一套提示词驱动的“技能框架”（skills framework）。你可以把它理解成：给AI编程工具装上了一套“岗位说明书+操作SOP”。

Superpowers本身不写代码，也不编译代码。它做的事情是告诉AI：接到需求以后，先别急着写实现，先去做调研、拆任务、列清单；每做一个任务之前，先想清楚怎么验证；做完一个任务之后，必须更新状态记录，让下一个任务和下一个会话都知道当前进展；遇到不确定的地方，要主动报告，而不是自作主张。

它和Codex CLI、Claude Code这类工具的配合方式，就像给一个经验丰富但纪律性差的程序员配了一个严格的项目经理。AI仍然是那个“快”的执行者，但Superpowers负责给它的工作加上节奏和护栏。

这里有个很关键的理念转变：不要指望AI从模型层面变得“可靠”，而是要在工作流层面设计一套机制，让不可靠的行为被及时暴露和纠正。可靠性不是模型的天赋，而是流程的产品。

2.2 三个核心概念：States、Skills、Goals

深入用下来，Superpowers最核心的三个概念是States（状态）、Skills（技能）、Goals（目标）。这三者分别回答的是“AI现在在哪”、“AI会做什么”、“AI要去哪”。

拿做菜打比方：普通的AI编程像是直接把所有食材丢给一个大厨，让他自由发挥，你只能等上菜；Superpowers则是先给你一份带检查点的菜谱：切配阶段、调味阶段、火候阶段，每个阶段都有明确的操作步骤和验收标准，做完一步打一个勾，你随时可以进厨房检查。AI还是那个厨子，但流程不再靠“感觉”了。

2.3 “驾驶座”隐喻：谁才是项目的负责人

Superpowers还有一个很反直觉的设计：它刻意让AI慢下来。在默认工作流里，AI接到需求后，第一件事不是写代码，而是生成一份任务清单，等你确认。这个“等确认”的动作，就是整篇文章标题里“可靠”二字的起点。

我特别喜欢它的一个比喻：AI是“副驾驶”，人类是“驾驶员”。副驾驶可以帮忙看路、提醒限速、提出建议，但方向盘和油门始终在驾驶员手里。一旦副驾驶抢方向盘——也就是AI自作主张改了一个没在清单上的文件——Superpowers会通过状态机制把这个越界行为暴露出来，让你能及时发现并纠正。

这和“多轮对话式编程”有本质区别：对话式编程里，AI的每一次行动都是基于它自己对上下文的理解，而你很难判断它理解到了哪一步；Superpowers把AI的“心理活动”变成了一个可见、可查、可审批的状态文件。你不需要猜它在想什么，只需要看它记了什么。

3. 落地准备：从克隆仓库到第一次跑通技能

3.1 前置要求与工具选择

Superpowers不是完全独立运行的工具，它需要挂载到一个支持“skills机制”的AI编程CLI上。目前社区里用得比较多的两个载体是Claude Code和Codex CLI。我自己是两边都试过：Claude Code对自然语言指令的理解更细腻，Codex CLI和GitHub工作流结合得更自然。你选哪个都行，关键是确认你用的CLI版本支持加载外部skills目录。

除了CLI本身，你还需要准备：一个能跑Node或Python的基础环境（具体取决于你的CLI载体）、Git命令行工具，以及一个有效的API访问权限。Codex CLI这类工具通常需要你有对应的付费API额度——热搜词里那个“codex付费ai编程软件”说的就是这个意思，它不是免费的，但按量付费对个人开发者来说成本还算可控。

3.2 安装与目录链接

安装过程不复杂，但有一个细节容易踩坑：必须把Superpowers的skills目录链接到你的CLI实际会读取的技能目录里，而不是放在某个自定义位置等着它自动发现。

我当时在Claude Code环境下的操作大致是这样的（地址以官方仓库为准）：

# 第一步：克隆Superpowers仓库到本地 git clone https://github.com/superpowers/superpowers.git ~/superpowers # 第二步：把skills目录软链到Claude Code的技能目录 ln -s ~/superpowers/skills ~/.claude/skills

如果你用的是Codex CLI，那么路径一般对应~/.codex/skills，原理相同。装完以后，我建议先做一个“技能自检”：用一句话要求AI列出当前项目启用的技能列表。如果AI能罗列出Superpowers相关的技能，说明加载成功；如果它一脸茫然，多半是路径没对，或者工具版本不支持。

要特别提醒的是，不同CLI工具对“技能”的加载方式有差异。有的工具要求技能目录下必须有特定格式的元信息文件，有的工具只认特定文件夹层级。所以装完不验证等于白装，这一步一定要做。

3.3 第一个练习：让AI生成一份任务清单

安装成功后，不要急着让它写功能。我强烈建议你的第一个练习是做“任务拆解”，这是Superpowers最基础也最重要的能力。

你可以在任意一个项目目录下启动CLI，然后输入指令：“请阅读当前项目结构和代码，生成一份完整的任务清单，按依赖关系排序。”如果Superpowers正常工作，AI给出的回答会呈现出明显的三段式结构：

• Work Summary（本次工作的总结）
• Next Task（下一步要做的具体任务）
• Blockers（当前遇到的阻碍或需要用户确认的问题）

这和我第1节说的“自由发挥式回答”完全不一样。它不会直接说“好的，我将帮你添加这个功能”，而是会先给出一个计划，并主动询问：“在开始任务1之前，有一个配置项需要你确认，是否可以修改？”

看到这种回答出现，你就可以放心了：这套流程已经接管了AI的行为，接下来要做的，就是学会怎么用它的工作流来跑真实项目。

4. 从需求到提交：Superpowers工作流的一条完整链路

4.1 工作流全景：规划、拆分、执行、验证、记录

用Superpowers跑一个真实需求，完整链路大概是这样的：

这个流程看起来比普通对话式编程“啰嗦”得多，但这正是可靠性的来源：每一步都有检查点，你可以随时喊停。

4.2 实战演示：给一个Node CLI工具加“--json”输出参数

我拿最近一个真实需求来演示：我的一个Node命令行工具默认输出的是人类可读的文本，现在需要加一个--json参数，让它输出结构化JSON，方便别的程序调用。

如果是以前用普通对话式AI，我会直接说：“加个--json参数，输出JSON格式。”AI噼里啪啦改完，测试也是绿的，但JSON里到底有哪些字段、字段命名稳不稳定、错误信息有没有结构，全靠它临场发挥。

用Superpowers就不一样了。第一步，我让它生成任务清单，它的输出大意是：

Work Summary: - 已阅读项目入口文件，发现当前输出逻辑集中在utils/formatter.js - 已确认CLI参数解析库为commander Next Task: - 任务1：为 --json 参数补充单元测试，验证对象字段名与嵌套结构 - 任务2：实现 JSON 格式化函数，保持与现有文本输出字段一致 - 任务3：补充命令行参数解析测试，覆盖错误参数场景 - 任务4：更新 README 示例 Blockers: - 暂无阻碍，但需要你确认 JSON 输出字段是否包含时间戳

注意这里的“Blockers”字段：AI主动把不确定的东西暴露出来，而不是替我做决定。这就是前面说的“副驾驶提醒”。

我确认字段方案之后，它会先从任务1开始，也就是写测试。测试代码里的断言全是“我给的数据应该输出什么”的预期结果。我特意检查了断言写法，它确实是在测“真实函数输出和硬编码预期的差异”，而不是自己和自己比。

写完测试，它会先跑一遍，确认测试失败（这是TDD的关键——先看到红色），再写实现让测试变绿。整个过程中，它一次只做任务1，完成并更新状态文件后，才申请进入任务2：“任务1已完成，测试已通过，是否继续任务2？”

这就是和“一个提示词改到底”最大的区别：你手里永远有一个“审批权”，而AI的手里永远有一个“当前进度锚点”。

4.3 为什么这条链路让代码更可靠

把这条链路拆开看，每个环节都在对抗一类不可靠因素：

• 任务拆解对抗“漏改”：需求被拆成清单，每个文件、每个函数都落到一个具体任务里，不会出现“顺手改了另一个模块”。
• 测试先行对抗“假完成”：完成的标准是“测试通过”，不是“AI觉得写完了”。
• 小步实现对抗“大爆炸式改动”：一个任务对应一条测试和一个小diff，出问题能精准定位，回滚也容易。
• 状态更新对抗“失忆”：状态文件记录每一步，即使会话中断，新会话也能从状态文件里恢复认知。

可靠性从来不是靠“模型更聪明”堆出来的，而是靠流程把“不可控”变成“可控”。

5. 可靠性不是玄学：Superpowers的三种制衡机制

5.1 状态可见：把AI的“心理活动”摊在桌面上

在传统编程里，代码评审靠看diff；在AI编程里，你连“AI当时心里在想什么”这个信息都没有。Superpowers解决这个问题的方式很朴素：强制AI用一个结构化状态文件记录“我刚才做了什么、我接下来要做什么、我卡在哪”。

这个状态文件就是项目里的“共享内存”。你随时可以打开看，不用去猜AI有没有跑偏。如果它上一步说是“在修复测试”，但状态文件里写的是“已经重写了三个模块”，你立刻就能发现偏差。

我自己的习惯是，每完成一个任务，就让AI把更新后的状态文件读一遍给我听（显示在终端里）。这不仅是在验证它有没有按规矩办事，也是在下一次“无状态对话”开始前，给新会话留一份可靠的交接文档。

5.2 测试护栏：把“我以为能跑”变成“证明能跑”

Superpowers的测试优先，不是简单地在提示词里加一句“请写测试”。它会要求AI明确描述“这条测试在验证什么行为”，并且强制先让测试失败再写实现。这个“先失败”的设计极其重要：如果你没看到红色，就等于没证明存在一个可检测的回归。

这里我特别想说一个很容易被忽视的点：AI写的测试本身也可能有问题——比如断言写反、测了同样的东西，或者跳过关键路径。所以我在实战中要求AI在每个测试文件里加一行注释，说明“这个用例如果被破坏，对应的是什么业务行为”，并在测试报告里同时输出“新增用例数”和“修改用例数”。不要迷信所谓“全绿”，要相信“测试确实验证了你以为它验证的东西”。

就目前版本的模型能力来说，让AI在Superpowers流程下写测试，比我用普通对话让它写测试，质量高得多。因为流程里每一步都在强化同一个信号：测试是标准，不是装饰品。

5.3 审批门槛：让AI提交“下一步计划”而不是直接执行

最后一道制衡机制，是“计划审批门槛”。Superpowers默认不让AI一口气把任务清单全跑完。它每完成一个小任务，会停一下，更新状态，然后等你发出“继续”的指令，再进入下一个任务。这种做法看起来拖慢了节奏，但在复杂项目里，它其实是把“不可逆的大错”拆成了“可逆的小错”。

我举一个对比：

• 普通模式：AI一口气改了8个文件，测试挂了，你都不知道是第几步开始错的。
• Superpowers模式：AI每改1个文件就跑一次测试，你现在就能看到这个文件是不是导火索。

改错一个文件，你只需要让它回滚这个小任务；改错八个文件，你只能动用git reset，然后祈祷手速够快。审批门槛的本质，是把一次性的高风险操作，变成多次低风险的小操作。这也正是“可靠”这个词的工程含义。

6. 我的踩坑记录与调优建议

6.1 坑一：任务粒度太大，一个任务改动半个代码库

我刚用Superpowers时，不太会写“需求输入”，总想着“既然AI这么强，我一句话把整个模块讲了，它自己会拆”。结果AI拆出来的任务清单里，任务1直接是“重构数据层并调整所有调用方”。这种任务粒度跟没拆差不多。

后来我学会了一个技巧：在让AI生成任务清单之前，先自己把需求按“可验证单元”切出一条粗边界。比如“先只做CLI参数解析，再做输出格式化，最后改文档”。AI在边界内拆出来的二级任务，才真正可执行、可评审。任务粒度越小，每个小步的可靠度越高，整体出错的概率就越低。

6.2 坑二：状态文件冲突，两个会话互相覆盖

有一次我在两个终端窗口同时跑Superpowers，一个在改前端，一个在改后端。两个会话共用同一个状态文件，结果后面的会话把前面会话的工作总结覆盖了。等到再开会话时，AI完全丢失了前端那部分进度，还以为是新需求。

这个坑的根源很简单：状态文件默认是单文件的，没有并发控制。现在的解决方式也很简单：一个项目同一个时间段内，只开一个Superpowers主会话，或者给不同分支配不同的状态文件路径。如果你想多线程推进项目，请让AI先生成两份独立的任务清单，分别关联各自的状态文件，不要共用一个。

6.3 坑三：CLI工具不认全套技能

不同CLI工具对skills目录结构的兼容性不一样。在Claude Code里跑通的技能，挪到Codex CLI里可能完全不响应，因为触发语法和加载机制有差异。这不是Superpowers的问题，是工具生态还没完全统一。

我的建议是：先选定一个主力CLI，把一套技能跑熟，不要频繁切换。真要切换，就给目标工具单独做一次技能自检，以它实际加载到的技能列表为准，别拿上一个环境的经验硬套。

6.4 稳定使用后的三个习惯

跑了一段Superpowers工作流之后，我沉淀下来三个习惯，分享给想上手的朋友：

第一，每个实现任务之后，人必须看一遍diff再放行。别嫌麻烦，这段付出买来的是“AI不会偷偷改别的东西”的确定性。

第二，要求AI把“下一步计划”写成一条清晰的指令，你自己评审它。比如它会写“下一步：实现task 2，修改formatter.js，补充对应测试”。你如果觉得这个步骤有问题，随时可以改，不必拘泥于AI的计划。

第三，让AI维护一份面向人类的CHANGELOG。Superpowers本身侧重“过程管理”，但变更日志是给同事和未来自己看的。我习惯每完成一组关联任务，让AI更新一次变更日志：“新增了--json参数，影响CLI输出；模块A的行为保持不变。”

说到底，Superpowers并不能把烂架构变成好架构，也不能让一个没有测试习惯的团队突然变得严谨。它的价值在于：让AI编程的每一步都变得可以检查、可以回滚、可以理解。当你不再需要祈祷“AI这次应该没乱改”，而是可以直接翻开状态文件看它到底干了什么，编程这件事才真正重新回到了“可靠”的轨道上。