企业官网建设流程全解析

1. 从"superpowers"这个词说起：它到底指什么

第一次看到"superpowers"这个标题，加上"agentic skills framework""software development methodology"这几个关键词，我脑子里第一反应是：这不是某个具体工具的名字，而是一套给 AI 编程助手"加装能力"的方法论框架。换句话说，它讨论的不是"用哪个模型"，而是"怎么把模型组织成一个能真正干活的工程团队"。

我接触这套思路的起点很朴素。早些年用命令行 AI 助手写代码，最大的痛点不是模型不够聪明，而是它没有章法：你让它改一个函数，它顺手把三个不相关的文件也动了；你让它加个测试，它给你写了个永远为真的断言。问题不在模型能力，在于我们没给它一套"工作纪律"。superpowers 这类框架要解决的，正是这个纪律问题——把"需求澄清、方案设计、任务拆解、编码实现、验证回归"这些软件工程里老生常谈的环节，变成 AI 助手可以遵循的技能模块（skills）。

所以这篇文章我想聊的不是"superpowers 是什么黑科技"，而是：当你想把 AI 助手真正纳入日常开发流程时，这套 agentic skills framework 的思路能给你什么，以及围绕 Claude Code、Codex CLI 这类命令行工具，实际落地时会遇到哪些坑。适合谁看？如果你已经在用或者准备用命令行 AI 编程工具，但总觉得"它好像没发挥出全部实力"，那这篇就是写给你的。如果你还没入门，我也会把安装、配置、常用命令这些基础环节讲清楚，保证你能跟着走一遍。

需要先说明一点：superpowers 本身更像一种组织 AI 工作流的方法论，而不是一个可以npm install的包。它的价值体现在你如何设计提示词、如何拆分任务、如何让 AI 在每一步都产出可验证的结果。理解了这一点，后面所有关于工具的操作才有意义——工具是载体，方法论才是内核。

2. 为什么"技能框架"比"换个更强的模型"更值得投入

2.1 模型能力已经过剩，缺的是流程约束

这两年模型迭代速度大家都看得到，写个 CRUD、补个单元测试、解释一段遗留代码，主流模型基本都能胜任。但我观察到一个普遍现象：同一个模型，在不同人手里产出质量差距巨大。有人用 AI 一天能提交十几个高质量 PR，有人用 AI 改出来的代码 review 时被打回三次。差距不在模型，在于有没有给 AI 一套稳定的工作流程。

superpowers 这类框架的核心洞察就在这里：与其期待模型"一次做对"，不如设计一套流程让模型分步做、每步可验证。这跟人类工程师的工作方式其实是一样的——没人会一口气写完整个模块再测试，都是小步快跑、边写边验。

2.2 技能模块化带来的三个实际好处

我把 agentic skills 拆开看，它带来的好处可以归纳成三点，每一点我都踩过对应的坑：

• 上下文可控：每个技能模块只关注一件事，AI 不需要在一次对话里同时记住"项目架构 + 编码规范 + 当前任务 + 历史决策"。上下文越聚焦，输出越稳定。我早期喜欢把所有要求塞进一个超长提示词，结果模型经常顾此失彼，后来拆成"先澄清需求、再出方案、再写代码"三步，质量立刻上来了。
• 结果可验证：每个技能模块都应该有明确的"完成标准"。比如"写测试"这个技能的完成标准是"测试能跑通且覆盖了边界条件"，而不是"看起来写了测试"。没有验证标准的 AI 输出，本质上是在赌运气。
• 流程可复用：一套调好的技能流程，换个项目、换个语言都能用。这比每次重新调提示词高效得多。

2.3 一个反直觉的结论：约束越多，AI 越"聪明"

很多人觉得给 AI 加限制会削弱它的能力，实测恰恰相反。当你明确告诉 AI"这一步只做需求澄清，不要写代码"，它反而会把需求问得更清楚；当你要求"每个函数改动都要有对应测试"，它写出来的代码结构会更合理。约束不是枷锁，是让 AI 把注意力集中在正确的事情上。这也是 superpowers 这套方法论最反直觉、但最有价值的地方。

3. Claude Code 与 Codex CLI：两条主流的命令行落地路径

聊完方法论，得落到具体工具上。目前命令行 AI 编程助手这条线上，Claude Code 和 Codex CLI 是绕不开的两个选择。它们都能承载 superpowers 式的技能框架，但使用手感和配置方式差别不小。

3.1 Claude Code 的安装与首次配置

Claude Code 的安装本身不复杂，但新手最容易卡在环境准备上。以 Ubuntu 为例，前置条件是 Node.js 环境（建议 18 以上版本），然后通过包管理器全局安装。安装完成后第一次运行会引导你完成账号相关配置。

这里有个很多人忽略的细节：Claude Code 对工作目录很敏感。它默认以你启动它的目录作为项目根，读取该目录下的配置文件。所以正确的做法是先cd到你的项目根目录，再启动，而不是在用户主目录里随便启动。我见过有人在家目录启动，结果 AI 把整个家目录当项目扫描，既慢又乱。

配置层面，项目根目录下的配置文件是核心。你可以在这里定义项目规范、常用命令、忽略规则等。我的经验是：把项目的构建命令、测试命令、代码风格要求写进去，这样 AI 每次执行验证时就知道该跑什么，不用你反复交代。

3.2 Codex CLI 的安装与常见卡点

Codex CLI 的安装同样依赖 Node 环境，但国内网络环境下npm安装慢是高频问题。我的处理方式是配置镜像源，或者用pnpm、yarn这类对缓存更友好的包管理器。安装慢不一定是工具的问题，多半是源的问题。

Codex CLI 的命令设计偏简洁，常用的几个交互命令值得记牢：

/compact这个命令我要特别说一下。很多人不知道它的存在，结果对话越聊越长，模型开始"忘事"、答非所问。其实在上下文快满之前主动/compact，把历史对话压缩成摘要，能显著延长一次会话的有效工作时间。这跟 superpowers 里"控制上下文"的思路是一脉相承的。

3.3 两个工具怎么选

我的建议是：别纠结，先各用一周。Claude Code 在长任务、多文件重构上体验更连贯；Codex CLI 在快速问答、单点修改上更轻快。两者都支持接入第三方模型接口，具体怎么配取决于你手头有什么资源。工具是次要的，你能不能把技能框架的思路用起来才是关键。用 Claude Code 但流程混乱，产出照样拉胯；用 Codex CLI 但任务拆得清楚，一样能出活。

4. 把 superpowers 思路落到实处的四个技能环节

这一节是全文的核心。我把 agentic skills framework 拆成四个可操作的环节，每个环节都给出具体的做法和我踩过的坑。

4.1 需求澄清：让 AI 先问，别急着写

大多数人用 AI 编程的姿势是：一句话描述需求，然后等它吐代码。这是效率最低的做法。正确的第一步应该是让 AI 反问你。

具体怎么做？在提示词里明确要求："在动手之前，先列出你不确定的地方，向我提问。" 这一步看似浪费时间，实则省下大量返工。我做过对比：同一个中等复杂度的功能，直接让 AI 写，平均要改 3 轮；先让它提问澄清，基本 1 轮就能到位。

需求澄清阶段要问清楚的东西包括：输入输出的边界、异常情况的处理、性能或兼容性要求、是否要写测试。这些不问清楚，AI 只能靠猜，猜错就是返工。

4.2 方案设计：先看地图再走路

需求清楚后，别让 AI 直接写代码，先让它出方案。方案里应该包含：涉及哪些文件、每个文件改什么、改动之间的依赖顺序、潜在风险点。

这一步的价值在于你可以在写代码之前就发现方向性错误。我遇到过好几次：AI 直接写代码，写到一半发现架构选错了，只能推倒重来。如果先出方案，我一眼就能看出"这个方案会导致循环依赖"，及时纠正，省下大量时间。

方案设计还有个隐藏好处：它逼着 AI 把"想"和"做"分开。模型在"想"的时候更愿意考虑全局，在"做"的时候容易陷入局部细节。分开之后，两件事都做得更好。

4.3 编码实现：小步提交，每步可回退

到了写代码环节，核心原则是小步。不要让 AI 一次性改十个文件，而是让它一个文件一个文件地改，每改完一个你 review 一次。

这里有个实操技巧：要求 AI 在每次改动后说明"改了什么、为什么这么改"。这不仅是给你看的，也是逼 AI 自我检查。很多时候它写着写着会自己发现"哦这里其实不用改"，主动收敛改动范围。

配合版本控制，小步提交的价值更大。每完成一个小步骤就提交一次，出问题随时回退。我现在的习惯是：AI 每完成一个可独立验证的改动，我就 commit 一次，commit message 写清楚这一步做了什么。这样即使后面某一步翻车，也不会污染前面的成果。

4.4 验证回归：没有验证的 AI 输出等于没写

这是最容易被跳过、也最不能跳过的一步。AI 说"我改好了"不算数，测试跑通才算数。

验证要分两层：第一层是功能验证，跑测试、跑构建、手动点一下关键路径；第二层是回归验证，确认这次改动没有破坏原有功能。第二层经常被忽略，但恰恰是 AI 最容易出问题的地方——它改 A 的时候经常不小心碰坏 B。

我的做法是在项目配置里写清楚验证命令，然后要求 AI 每次改动后自己跑一遍。如果测试失败，让它自己分析原因、自己修，修不好再叫我。这个"自验证"的循环一旦建立起来，AI 的产出质量会有质的提升。

5. 那些文档里不会写的实操坑

5.1 上下文污染：AI 会"记住"错误的东西

AI 助手在长会话里会累积上下文，这既是优点也是陷阱。如果前面某一步 AI 理解错了，这个错误理解会一直影响后面的输出。我遇到过最典型的情况：AI 一开始把某个变量名理解错了，后面所有代码都用了错误的命名，直到我手动纠正才改过来。

应对办法是定期清理上下文。用/compact压缩，或者干脆开新会话。判断标准很简单：如果你发现 AI 开始"答非所问"或者反复犯同一个错，多半是上下文被污染了，果断重开。

5.2 过度自信：AI 说"完成"时你要多留个心眼

AI 有个通病：它经常在没真正完成的情况下说"已完成"。比如它说"测试已通过"，但实际根本没跑测试；它说"已修复 bug"，但只是改了表面症状。

我的应对是永远自己验证一遍。不是不信任 AI，而是这是工程纪律。AI 说改好了，我就跑一遍测试；AI 说没问题，我就手动点一下。这个习惯帮我拦下了不少"假完成"。

5.3 环境差异：本地能跑不代表别处能跑

AI 生成的代码经常依赖它"以为存在"的环境。比如它用了某个库的新 API，但你的项目锁的是旧版本；它假设某个命令可用，但你的系统里没装。这类问题在本地测试时可能不暴露，一上 CI 就炸。

解决办法是在项目配置里明确写清楚环境约束：Node 版本、依赖版本、可用命令。让 AI 在生成代码前就知道这些边界，能减少大量环境相关的返工。

5.4 权限与安全：别让 AI 随便执行命令

命令行 AI 助手通常有执行终端命令的能力，这很方便，但也有风险。我的原则是：涉及删除、覆盖、推送这类不可逆操作时，一定要人工确认。日常的读文件、跑测试可以放开，但rm、git push --force这类命令，必须经过我同意。

这不是不信任工具，而是工程上的基本谨慎。AI 再聪明也可能误判，而有些操作一旦执行就回不来了。

6. 一套可复用的日常协作节奏

把上面所有东西串起来，我现在的日常协作节奏大概是这样：

早上开工，先cd到项目目录启动助手，用/resume恢复昨天的会话（如果任务没完成）。然后描述今天要做的事，先让它提问澄清，确认需求无误后让它出方案，方案我过一遍，没问题就进入编码。编码阶段小步走，每完成一个可验证的改动就 commit。全部做完后跑一遍完整测试，确认没有回归问题。

这套节奏跑顺之后，我明显感觉到 AI 从"偶尔好用的工具"变成了"稳定的协作伙伴"。关键不在于用了哪个模型、哪个工具，而在于你有没有给它一套清晰的工作纪律。superpowers 这个标题听起来很玄，但拆开看，无非就是把软件工程里那些朴素的道理，认真地应用到了 AI 协作上。

最后分享一个我最近才想明白的点：别追求一步到位的完美提示词。我早期花大量时间打磨"万能提示词"，结果发现不如把流程拆细、每步简单直接来得有效。提示词工程的天花板，其实是流程设计。把流程设计好了，提示词自然就简单了。这个认知转变，比学会任何一个具体命令都值钱。