1. Codex 工作流为什么总在“半自动”卡住Superpowers 插件能解决什么如果你用 Codex 写过稍大一点的功能大概率遇到过这种状态模型能改代码但流程全靠你手动兜底。需求没澄清就直接开写写完发现方向偏了调试时它猜一个改一个改到第五轮才碰到根因任务跨了七八个文件中间没有任何批准节点最后 diff 一大坨你根本不敢合。这不是模型能力问题而是缺少一层“工作流约束”。Superpowers 就是干这个的它不替换模型也不接外部服务而是通过一套 Skills 集合让 Codex 在开发过程中按需求澄清、方案设计、任务拆分、测试驱动、调试、审查、验证这些阶段走。你可以把它理解成给 Codex 装了一套“开发纪律”而不是换了个更聪明的脑子。这篇聚焦一件事怎么用 Superpowers 插件把 Skills 和 CLI 串成一条可复用的工作流。我会按本地配置、任务触发、结果校验三个环节拆开讲给出可复制的配置片段和 CLI 调用示例最后完整跑一遍从 Skills 加载到命令执行的验证动作。适合已经在用 Codex CLI 或 Codex App、想让流程稳定下来的开发者。如果你还没配好模型接入可以先用 TaoToken 的 API 入口 把 Base URL 和 Key 准备好再往下走。需要先明确一个前提当前 Codex 版的 Superpowers 以 Skills 为主不提供/brainstorming、/systematic-debugging这类斜杠命令。日常触发靠自然语言、选择器或显式指定 Skill 名称。这一点很多人第一次用会踩坑以为装完就能敲斜杠命令结果发现没反应。2. 前置准备TaoToken 接入与 Superpowers 插件安装2.1 先把模型接入配好Superpowers 本身不管模型连接它依赖 Codex 已经能正常调用模型。如果你用的是自建或第三方接入需要先确认 Base URL、API Key、Model ID 三件套齐全。以 TaoToken 为例接入信息如下Base URLhttps://taotoken.net/apiAPI Key在 控制台 API Keys 页面 生成Model ID按你实际使用的模型填写比如claude-sonnet-4-5这类Codex CLI 的配置文件通常在~/.codex/config.toml可以这样写# ~/.codex/config.toml model claude-sonnet-4-5 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在 shell 里导出 Keyexport TAOTOKEN_API_KEYsk-你的key如果你用的是 Codex 的auth.json方式部分版本走 OAuth 或本地凭证文件路径一般在~/.codex/auth.json结构大致是{ OPENAI_API_KEY: sk-你的key, OPENAI_BASE_URL: https://taotoken.net/api }注意不同 Codex 版本对auth.json字段名要求不完全一致如果启动时报401或local proxy failed优先检查这里字段名和 Base URL 是否匹配。配好后先跑一个最小请求确认模型通了再装插件否则后面出问题你分不清是接入还是插件。2.2 安装 Superpowers 插件Codex App打开左侧 Plugins在 Coding 或 Developer Tools 分类里找到 Superpowers点插件旁的按提示完成安装。装完必须新建一个任务Skills 才会在新任务里生效。Codex CLI进入 CLI 后打开插件浏览器/plugins搜索superpowers打开详情选Install Plugin。装完启动一个新会话。在插件浏览器里按Space可以启用或停用插件打开详情可以卸载。Codex IDE 扩展打开 Settings → Plugins搜索并安装 Superpowers装完新建聊天。2.3 验证插件是否生效在插件管理页的 Installed 区域确认 Superpowers 已安装并启用然后新建任务输入请说明当前可用的 Superpowers Skills并指出处理新功能时会优先使用哪个 Skill。如果安装成功Codex 应该能列出相关 Skills。如果识别不到先检查是不是没新建任务或会话以及插件是否处于启用状态。这一步别跳过我见过太多人装完直接在旧会话里试然后以为插件坏了。3. 可复制配置把 Skills 与 CLI 串成工作流3.1 项目级约束文件 AGENTS.mdSuperpowers 的 Skills 必须在项目约束范围内工作。项目根目录的AGENTS.md是仓库级持久约束推荐先写好它再让 Skills 在其框架内执行。一个可用的模板# AGENTS.md ## 执行顺序 1. 先读取本文件并遵守所有约束。 2. 输出本次任务的执行计划等待明确批准。 3. 批准后根据任务选择 Superpowers Skill。 4. 修改前读取目标文件优先复用已有组件和封装。 5. 发现计划外问题只报告不擅自扩大改动。 6. 实施后运行最小有效验证。 7. 展示完整 diff提交前再次等待批准。 ## 约束 - 未经批准不得修改文件。 - 范围变化时停止并重新确认。 - 不接受“应该通过”必须展示实际测试输出。3.2 Skill 与触发场景对照把这张表存下来触发时直接对照比记命令靠谱Skill典型触发场景推荐提示词开头brainstorming新功能、架构调整、需求不清晰先使用 brainstorming 梳理需求和方案writing-plans设计已批准需要拆分步骤使用 writing-plans 生成含文件路径和验证步骤的计划executing-plans已有批准计划需要分批执行按已批准计划执行每批完成后等待检查test-driven-development新功能或修复需要测试先行使用 TDD先写失败测试并确认失败原因systematic-debuggingBug、异常日志、行为不稳定先复现问题并系统定位根因不要猜测修复requesting-code-review实施完成需要发起审查根据需求和计划审查当前 diff按严重程度报告verification-before-completion准备宣布完成需要证据运行与改动匹配的验证并基于实际输出报告结果3.3 完整工作流提示词模板中大型功能建议一次性把顺序和批准节点写清楚使用 Superpowers 完成这个需求并严格遵循项目 AGENTS.md 在这里填写需求 要求 1. 先通过 brainstorming 明确需求和方案 2. 方案批准后使用 writing-plans 输出实施计划 3. 计划批准后使用 test-driven-development 实施 4. 完成后进行 code review 和 verification 5. 展示完整 diff未经批准不要提交。这段模板的价值在于它把“设计→计划→实施→审查→验证”串成了一条链每个节点都有批准卡点。你不需要记 Skill 名字Codex 会按语义加载对应 Skill。4. 验证请求从 Skills 加载到 CLI 执行的完整动作4.1 触发一次完整工作流假设你要给一个 Vue H5 项目加订单详情页。在 Codex CLI 新会话里输入使用 Superpowers 的 brainstorming Skill 设计订单详情页。 先阅读项目约束和相关文件通过提问明确目标、边界条件和异常场景。 给出候选方案和推荐理由方案批准前不要修改文件。预期行为Codex 会先读AGENTS.md然后进入 brainstorming向你提问而不是直接写代码。它会问数据来源、异常态怎么展示、是否需要分页这类问题。这一步的输出应该是方案和问题清单不应该有文件改动。4.2 批准后进入计划阶段方案确认后输入使用 Superpowers 的 writing-plans Skill根据已批准的方案生成实施计划。 每一步写明文件路径、预期改动、验证命令和通过标准。 计划输出后等待批准不要开始实施。预期输出是一份带文件路径和验证命令的计划。检查两点每一步是否有明确的验证方式是否标注了回滚考虑。如果计划里出现“修改相关文件”这种模糊描述直接打回让它细化。4.3 实施与验证计划批准后使用 Superpowers 的 test-driven-development Skill 执行已批准计划。 严格遵循 RED-GREEN-REFACTOR先写失败测试并运行再写最小实现 测试通过后重构。每个阶段报告实际验证结果。这里的关键是要求它报告实际测试输出而不是“测试应该通过了”。完成后用 verification Skill 收尾使用 Superpowers 的 verification-before-completion Skill 运行与改动匹配的验证并基于实际输出报告结果。4.4 CLI 侧的结果校验除了看 Codex 的输出你可以在 CLI 里自己跑一遍验证命令确认它说的和实际一致# 查看本次改动范围 git diff --stat # 运行项目测试 npm run test -- --run # 查看完整 diff git diff如果 Codex 报告“测试通过”但你本地跑失败说明它的验证不可信这时候要回到 systematic-debugging 重新定位。这一步是很多人忽略的不要只信模型的自述要用 CLI 的实际输出交叉验证。5. 常见报错排查401、local proxy failed、OAuth 与 Skills 不触发5.1 报错 401 Unauthorized最常见的原因是 Key 没导出或 Base URL 不匹配。检查顺序echo $TAOTOKEN_API_KEY如果为空说明环境变量没生效。确认config.toml里的env_key和实际导出的变量名一致。如果用的是auth.json检查OPENAI_BASE_URL是否写成了https://taotoken.net/api注意不要多加路径后缀。5.2 local proxy failed这个报错通常出现在 Codex 尝试走本地代理但配置缺失时。检查config.toml里wire_api是否和你的接入方式匹配。如果是 chat 接口写wire_api chat如果是 responses 接口按实际改。同时确认没有残留的代理环境变量干扰env | grep -i proxy如果有HTTP_PROXY之类的变量指向不可用地址先 unset 再试。5.3 OAuth 相关报错部分 Codex 版本启动时会尝试 OAuth 流程。如果你用的是 API Key 接入需要在配置里明确走 Key 模式避免它去走 OAuth。检查auth.json里是否有冲突字段必要时清空后只保留 Key 和 Base URL 两项。5.4 Skills 装了但不触发按顺序排查插件是否在 Installed 里是否处于启用状态安装后是否新建了任务或 CLI 会话能否通过找到插件或具体 Skill工作区或管理员策略是否限制插件。如果自动触发选了错误的 Skill不要依赖模糊描述改成显式指定使用 Superpowers 的 systematic-debugging Skill仅诊断问题不实施修复。5.5 工作流太重Superpowers 强调过程和验证中大型任务收益明显但简单问答会显得啰嗦。这时候主动缩小范围这是只读解释任务不需要 brainstorming、实施计划或代码修改。项目指令和用户直接要求优先于 Skills所以明确的范围和停止条件非常重要。6. 把工作流固定下来长期编码与 Agent 场景的接入选择跑通一次完整流程后你会发现 Superpowers 真正的价值不在单次任务而在于把“设计→计划→实施→审查→验证”变成可复用的固定链路。每次新需求都走同一条链diff 可控批准节点清晰回滚有依据。如果你打算长期用 Codex 做编码和 Agent 任务建议把模型接入也固定下来避免每次换环境重新配。TaoToken 这边几个入口按场景分需要长期编码、跑 Agent 工作流用 Coding Plan适合高频调用场景。只是验证模型对话效果用 模型对话 快速试。要管理 Key 和额度进 控制台。查接入细节和参数看 接入文档。最后给一个实操建议把AGENTS.md和那套工作流提示词模板存成项目里的 snippet每次新任务直接粘贴改需求部分。我试过在三个不同项目里复用同一套模板唯一需要改的是项目约束和验证命令。这样 Superpowers 的 Skills 才真正和你的 CLI 串成一条稳定工作流而不是每次靠记忆临时拼提示词。