企业官网建设流程全解析

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

第一次看到“superpowers”这个标题，加上“agentic skills framework”“software development methodology”这几个关键词，我脑子里第一反应是：这不是某个具体软件的名字，而更像是一套给 AI 编程代理（agent）用的能力框架。后来结合 Claude Code、Codex CLI 这些热词，基本可以确认——它讨论的是“怎么让命令行里的 AI 代理真正具备超能力”，也就是把零散的提示词、工具调用、上下文管理，整合成一套可复用、可组合的技能体系。

说白了，大多数人用 Claude Code 或者 Codex CLI，停留在“我问一句、它答一句、偶尔帮我改个文件”的阶段。这就像你手里有一把瑞士军刀，但只会用它开瓶盖。而 superpowers 这套思路想解决的核心问题是：如何把 AI 代理从“聊天机器人”升级成“能独立完成复杂工程任务的协作伙伴”。它涉及的不只是模型能力，还包括技能的组织方式、上下文的注入策略、工具链的编排，以及一套让代理“知道自己在干什么”的方法论。

这篇文章适合三类人看：第一类是想把 Claude Code、Codex CLI 真正用起来的开发者；第二类是对 agentic skills framework 这个概念好奇、想知道它和普通 prompt engineering 有什么区别的技术人；第三类是在团队里推动 AI 辅助开发、需要一套可落地方法论的负责人。我会从概念拆解讲到实操配置，再讲到技能框架的设计思路，尽量把“superpowers”这个词背后的东西讲透。

需要先说明一点：superpowers 本身并不是一个我能在官方渠道下载到的独立安装包，它更像是一种围绕 AI 编程代理构建能力体系的方法论和工具集合。市面上流传的很多“安装 superpowers”的说法，实际上指的是配置 Claude Code、Codex CLI 这类代理工具，再配合一套技能定义文件，让代理具备更强的任务执行能力。所以下文我会把重点放在“怎么搭出这套能力”上，而不是纠结于某个具体安装命令。

2. Claude Code 与 Codex CLI：两条主流的代理落地路径

2.1 为什么命令行代理比 IDE 插件更值得投入

很多人第一次接触 AI 编程，是从 VS Code 插件开始的，比如 Claude Code for VS Code、Codex 的编辑器集成。这类插件的好处是上手快，装完就能在侧边栏对话。但我实际用下来发现，真正能释放代理能力的场景，往往在命令行里。原因有三个。

第一，命令行代理能直接执行终端命令。你让它跑测试、装依赖、查日志，它真的能动手，而不是只给你一段建议代码。第二，命令行环境天然适合脚本化和自动化，你可以把代理嵌进 CI 流程、嵌进自定义脚本。第三，命令行代理对项目上下文的读取更自由，它能自己决定读哪些文件、跑哪些命令来收集信息，而不是被动等你粘贴代码。

Claude Code 和 Codex CLI 就是这条路线上的两个代表。Claude Code 是 Anthropic 推出的命令行代理工具，Codex CLI 则是另一套思路相近的实现。它们都支持读取本地文件、执行命令、多轮任务规划。热词里出现的“claude code 如何直接执行终端命令”“codex cli 命令哪些 /compact /model /resume”，说明大家最关心的就是这类代理的实操细节。

2.2 Claude Code 的安装与首次配置要点

关于 Claude Code 的安装，热词里有一堆相关搜索：“claude code 安装”“mac 安装 claude code”“ubuntu 安装 claude code”“claude code 下载安装”。我按自己的经验梳理一下关键点。

在 macOS 或 Linux 上，通常通过包管理器安装。安装完成后第一次运行，会引导你完成账号认证。这里有个常见坑：热词里出现了“your organization has disabled claude subscription access for claude code”和“note: claude code might not be available in your country”，说明账号权限和地区可用性是两道门槛。如果你用的是团队账号，可能被管理员限制了访问；如果是个人账号，也要确认当前区域是否在支持范围内。

配置层面，我建议第一次就把工作目录、默认模型、权限模式这几项理清楚。Claude Code 默认会在你当前所在的项目目录下工作，所以一定要先 cd 到目标项目再启动，否则它可能在一个空目录里瞎转。权限模式决定了它执行命令前是否需要你确认，新手建议先用确认模式，跑顺了再考虑放宽。

2.3 Codex CLI 的定位差异与命令体系

Codex CLI 和 Claude Code 在能力上高度重叠，但使用手感有差异。热词里“codex cli 命令哪些 /compact /model /resume”直接点出了它的核心命令。我解释一下这几个命令的实际作用。

/compact是用来压缩上下文的。代理跑久了，对话历史会越来越长，既占 token 又拖慢响应。/compact会把之前的对话总结成更短的摘要，保留关键信息，丢掉冗余部分。这个操作在长任务里非常关键，我一般每完成一个阶段性目标就 compact 一次。

/model用来切换底层模型。不同任务对模型的要求不一样，简单重构用快模型，复杂架构设计用强模型，切换一下能省不少成本。

/resume是恢复之前的会话。代理任务中断了、终端关了，用这个命令能把上下文接回来，不用从头再来。

热词里还有“删除 codex cli 指令”，这个我没找到特别权威的对应，推测是指清理或卸载相关命令。我的建议是，卸载前先确认没有正在运行的任务，避免残留进程占用资源。

2.4 两条路径的选型对照

这张表不是绝对的，实际选型还要看你团队已有的工具链。我的经验是，如果你已经在用 Anthropic 的生态，Claude Code 更顺手；如果你更习惯 npm 系的工具管理，Codex CLI 的集成成本更低。两者不必二选一，我自己的机器上就都装着，按任务类型切换。

3. 让代理接入本地模型与第三方 API 的实操思路

3.1 为什么要考虑本地模型

热词里有一条很显眼：“claude code 调用 lmstudio 的本地模型”。这说明很多人不满足于只用官方云端模型，想把代理接到本地跑。动机无非几个：数据不出本地、成本可控、离线可用、想用特定开源模型。

LM Studio 是一个可以在本地加载和运行开源模型的工具，它提供兼容 OpenAI 接口的本地服务。理论上，只要代理工具支持自定义 API 端点，就能把请求指向 LM Studio。但这里有个现实问题：代理工具对模型的能力要求比较高，尤其是工具调用（function calling）和长上下文理解。本地小模型在这些方面往往力不从心，跑起来会出现“它不知道该调用哪个工具”“上下文一长就胡言乱语”的情况。

我的建议是，本地模型适合做轻量任务，比如代码解释、简单补全、文档问答。真正复杂的多步任务，还是交给能力更强的云端模型。把本地模型当成“日常小助手”，把云端模型当成“攻坚主力”，这个分工比较务实。

3.2 第三方 API 接入的通用套路

热词里“使用 cc switch 接入 deepseek v4, qwen, glm 等模型”“第三方 api 使用技巧”指向的是同一个需求：把代理工具的请求转发到第三方模型服务。cc switch 这类工具的作用，就是帮你管理多个模型供应商的配置，一键切换。

通用套路是这样的：代理工具通常允许你配置 API base URL 和 API key。你把这些指向第三方服务商的端点，填上对应的 key，代理就会把请求发过去。听起来简单，但实操中有几个坑。

第一个坑是接口兼容性。不是所有第三方服务都完全兼容 OpenAI 或 Anthropic 的接口格式，有些字段名、返回结构有差异，会导致代理解析失败。第二个坑是工具调用支持。代理依赖工具调用来执行命令、读写文件，如果第三方模型不支持或者支持得不完整，代理就退化成普通聊天。第三个坑是速率和稳定性，第三方服务的限流策略和官方不一样，长任务跑到一半被限流会很尴尬。

我的做法是，接入新供应商前，先用一个最小任务测试：让它读一个文件、改一行代码、跑一条命令。三件事都能顺利完成，才说明这个供应商可用。

3.3 配置文件的组织方式

不管是接本地模型还是第三方 API，配置文件的组织都值得讲究。我习惯把不同供应商的配置分成独立文件，用一个切换脚本或工具来激活。这样做的理由是：避免配置互相污染。你手动改来改去，很容易把 base URL 和 key 配错，排查起来很痛苦。

一个典型的配置结构大概是这样：

{ "provider": "third-party", "baseUrl": "https://api.example.com/v1", "apiKey": "your-key-here", "model": "target-model-name", "maxTokens": 8192, "temperature": 0.2 }

temperature我一般设得比较低，0.1 到 0.3 之间。代理任务需要的是稳定和准确，不是创意发散。温度高了，它可能给你编出不存在的命令。

提示：API key 千万不要硬编码在会提交到版本库的文件里。用环境变量或者本地未跟踪的配置文件，这是基本的安全习惯。

3.4 本地模型接入的实测体会

我自己用 LM Studio 接过一次本地模型跑 Claude Code 类的任务，体验是：简单任务能跑，复杂任务会崩。具体表现是，让它解释一段代码没问题，让它规划一个多文件重构，它就开始绕圈子，反复读同一个文件，或者生成格式不对的工具调用。

后来我调整了策略：本地模型只用来做“预处理”，比如先把项目结构总结一遍、把相关文件筛出来，然后把筛选结果喂给云端模型做真正的任务规划。这样既利用了本地的隐私和成本优势，又保证了核心任务的质量。这个组合思路我觉得比单纯追求“全本地”更实际。

4. 技能框架（agentic skills framework）的设计逻辑

4.1 技能不是提示词模板

很多人把 agentic skills framework 理解成“一堆写好的提示词模板”，这个理解偏了。提示词模板是静态的，你填个空就完事。而技能框架里的“技能”，是带有触发条件、执行步骤、工具依赖和验证标准的可组合单元。

举个例子。一个“重构函数”的技能，不只是“请帮我重构这个函数”这句话。它应该包含：什么时候触发这个技能（比如用户说“这个函数太长了”）、执行前要收集什么信息（函数所在文件、调用方、测试覆盖情况）、执行中允许用哪些工具（读文件、写文件、跑测试）、执行后怎么验证（测试是否通过、调用方是否受影响）。这才叫一个完整的技能。

superpowers 这个概念的价值，就在于它试图把这种“完整技能”标准化，让代理能像搭积木一样组合使用。

4.2 技能的三层结构

我总结下来，一个可用的技能大致分三层。

第一层是意图识别层。代理需要判断当前任务该用哪个技能。这层靠的是对用户输入和项目状态的综合理解。做得好的代理，能根据你一句话就选对技能；做得差的，你得手动指定。

第二层是执行编排层。技能内部有多个步骤，代理要决定先做什么、后做什么、遇到分支怎么走。这层最考验代理的规划能力，也是本地小模型最容易翻车的地方。

第三层是工具调用层。具体到读哪个文件、跑哪条命令、怎么写回结果。这层相对机械，但对准确性要求高，一个路径写错就全盘皆输。

三层里，第一层和第三层相对容易做好，第二层是真正的难点。这也是为什么我在前面强调，复杂任务还是要用能力强的模型。

4.3 技能定义文件的写法

技能定义通常用结构化格式写，YAML 或 JSON 都行。我倾向于 YAML，可读性好。一个技能定义大概长这样：

name: refactor-function description: 当函数过长或职责过多时，将其拆分为更小的函数 triggers: - "这个函数太长了" - "帮我重构这个函数" - "拆分这个函数" steps: - action: read_file target: "{{current_file}}" - action: analyze goal: "识别函数内的独立逻辑块" - action: propose_plan output: "拆分方案" - action: confirm condition: "方案涉及跨文件修改" - action: execute_refactor - action: run_tests on_failure: "回滚并报告"

这个定义里，triggers是触发条件，steps是执行步骤，on_failure是失败处理。关键点是每一步都要有明确的动作和验证，不能有“然后代理自己看着办”这种模糊表述。

4.4 技能组合与冲突处理

单个技能好写，难的是多个技能组合时的冲突。比如你同时定义了“快速修复”和“彻底重构”两个技能，用户说“这个 bug 修一下”，代理该用哪个？快速修复可能治标不治本，彻底重构又太重。

我的处理方式是给技能加优先级和适用条件。“快速修复”适用于生产环境紧急问题，“彻底重构”适用于开发阶段的代码质量改进。代理根据当前上下文（是不是生产分支、有没有测试覆盖）来选择。如果实在判断不了，就主动询问用户，而不是自作主张。

这一点很重要：好的技能框架不是让代理替你做所有决定，而是让它在该问的时候问，该做的时候做。很多代理用起来让人不放心，就是因为它在模糊地带乱猜。

5. 上下文管理与长任务执行的关键技巧

5.1 上下文窗口是稀缺资源

代理跑长任务，最大的敌人是上下文窗口。你让它重构一个模块，它读了十几个文件，对话历史几千行，很快窗口就满了。满了之后要么报错，要么开始遗忘早期信息，行为变得不可预测。

热词里“/compact”这个命令就是为解决这个问题设计的。但光靠 compact 不够，还要在任务设计上做文章。我的经验是：把大任务拆成小任务，每个小任务独立完成、独立验证、独立压缩。不要指望代理一口气吃下一个大重构。

5.2 用文件系统做外部记忆

代理的上下文窗口有限，但文件系统是无限的。我习惯让代理把中间结果写到文件里，比如分析报告、重构计划、变更清单。这样即使上下文被压缩了，关键信息还在磁盘上，随时可以读回来。

具体做法是，在技能定义里加一步“写中间产物到.agent/目录”。这个目录加到.gitignore里，不污染版本库。代理需要回顾时，读这个目录就行，比翻对话历史高效得多。

5.3 长任务的检查点机制

跑长任务时，我会设置检查点。每完成一个阶段，让代理输出一份简短的状态报告：做了什么、当前在哪、下一步是什么、有没有阻塞。这份报告既是给我看的，也是给代理自己看的——万一上下文丢了，读这份报告就能恢复状态。

检查点的频率我一般按任务复杂度定。简单任务一个检查点就够，复杂任务每个子模块一个。太频繁会打断节奏，太稀疏又起不到保护作用。

5.4 失败恢复的实操

代理任务失败是常态，关键是怎么恢复。我的流程是：先看它卡在哪一步，再判断是上下文问题、工具问题还是模型能力问题。上下文问题就 compact 或重开，工具问题就修配置，模型能力问题就换模型。

热词里“/resume”就是为恢复设计的。但 resume 只能恢复会话，不能恢复“思路”。如果代理之前走错了方向，resume 回来还是错的。所以我的习惯是，发现方向错了就果断重开，不要恋战。重开的成本，往往比在错误方向上挣扎低得多。

6. 团队协作与工程化落地的注意事项

6.1 把代理配置纳入版本管理

个人用代理，配置放本地就行。团队用，配置必须进版本库。但要注意，API key 不能进版本库。我的做法是，配置文件进库，key 用环境变量注入，再写一个模板文件说明需要哪些环境变量。

这样新成员拉下代码，照着模板配好 key，就能用统一的代理配置。避免了“每个人配置不一样、行为不一致”的问题。

6.2 技能库的共享与评审

技能定义文件应该像代码一样评审。一个新技能加进来，要有人 review 它的触发条件是否合理、步骤是否完整、失败处理是否到位。我见过团队里有人写了个技能，触发条件写得太宽，结果代理动不动就触发它，把简单任务搞复杂。

评审的重点是触发条件的精确性和失败处理的完备性。前者决定技能会不会被误触发，后者决定出问题时能不能优雅降级。

6.3 权限与安全边界

代理能执行终端命令，这是它的威力，也是它的风险。团队落地时，一定要划清权限边界。哪些命令允许自动执行，哪些必须人工确认，哪些绝对禁止，都要有明确规定。

我的建议是，破坏性操作一律人工确认。删除文件、强制推送、修改生产配置，这些操作代理可以提议，但执行前必须过人的手。这不是不信任代理，而是工程纪律。

6.4 效果度量与迭代

代理用得好不好，不能凭感觉。我建议记录几个指标：任务完成率、平均耗时、人工干预次数、失败原因分布。这些数据能告诉你，技能框架哪里需要改进，模型选型是否合理，上下文策略是否有效。

我自己的记录习惯是，每周回顾一次失败案例，看看是技能定义的问题还是模型能力的问题。前者改技能，后者换模型或调整任务粒度。坚持几个月，代理的可用性会有明显提升。

7. 我踩过的几个坑和对应的解法

7.1 代理在空目录里空转

前面提过一次，这里展开说。我第一次用 Claude Code 时，忘了先 cd 到项目目录，结果它在用户主目录下启动，读了一堆无关文件，还试图修改我的 shell 配置。幸好权限模式拦住了。

解法很简单：启动前确认工作目录。我现在养成了习惯，启动代理前先pwd一下，确认在正确的项目根目录。有些代理工具支持指定工作目录参数，用那个更保险。

7.2 上下文压缩后丢失关键约束

有一次我让代理重构一个模块，中途 compact 了一次，结果它把“不要修改公共接口”这个约束给忘了，改完之后调用方全挂了。

解法是，把关键约束写进技能定义或项目配置文件，而不是只放在对话里。对话会被压缩，配置文件不会。我现在会把“不可修改的接口”“必须通过的测试”“代码风格要求”这些写进一个AGENTS.md或类似的文件，代理每次启动都会读。

7.3 第三方模型不支持工具调用

接第三方 API 时踩过这个坑。配置看起来都对，但代理就是不执行命令，只会输出文字。排查半天才发现，那个第三方模型不支持 function calling。

解法是，接入前先确认模型能力。看文档、跑最小测试，确认支持工具调用再正式用。不支持的就只能当聊天用，别指望它执行任务。

7.4 技能触发条件写得太宽

团队里有人写了个“优化代码”的技能，触发条件包含“优化”这个词。结果用户说“优化一下这个查询”，代理触发了整个代码重构流程，把简单问题搞复杂了。

解法是，触发条件要具体。“优化代码”太宽，“优化这个 SQL 查询的性能”才够具体。写技能定义时，多问自己一句：这个条件会不会误触发？

7.5 长任务没有检查点导致全盘重来

跑一个跨多文件的重构，跑了半小时，中途终端崩了，上下文全丢，只能从头再来。那次之后我就加了检查点机制。

解法是，阶段性落盘。每完成一个子任务，把状态写到文件。终端崩了、会话断了，读文件就能恢复。这个习惯救了我好几次。

8. 关于 superpowers 这套思路的个人判断

用了一段时间 Claude Code、Codex CLI，也折腾过技能框架和本地模型接入，我对 superpowers 这类思路的判断是：方向对，但落地还在早期。

方向对，是因为 AI 编程代理确实需要一套结构化的能力体系。光靠提示词，能力上限很低，而且不可复用、不可维护。技能框架把经验沉淀下来，让代理的行为可预期、可迭代，这是必经之路。

落地早期，是因为现在的工具链还很碎。配置格式不统一、技能定义没有标准、不同代理之间不兼容、本地模型能力参差。你想搭一套顺手的体系，得自己填很多坑。

我的建议是，别追求一步到位。先从一两个高频任务开始，写好技能定义，跑顺了再扩展。上下文管理、检查点、失败恢复这些机制，边用边加。等这套东西在你手里跑顺了，再考虑团队推广。

最后分享一个我自己的小习惯：每次代理任务失败，我都会花两分钟记一下失败原因和当时的配置。攒了几个月，这份记录成了我调优技能框架最值钱的参考。工具会更新，模型会换代，但“什么情况下会出什么问题”这种经验，是真正属于你自己的 superpowers。