去年我还在折腾 langchain/langgraph 开发智能体，弄了个 langgraphgo 项目，把 langgraph 往 Go 生态圈里搬。那会儿网上做智能体的，十个有八个用 langchain/Crew AI。
一个阶段有一个阶段的玩法。
现在我看到了另一种路子：大家直接用 Claude Code、Codex、OpenCode、Pi 这些 coding agent "套壳"来实现智能体。
先说两个很多人搞混的点。
别觉得这些工具只能写代码。Claude Code、Codex 的架构走的是通用智能体模式，早就不止 coding 了。
也别把"套壳"当贬义词。Manus 刚火那阵，就有同事撇嘴说"这不就是 Claude 的套壳"。但你看，Claude、Codex、Antigravity 一个个都在推 SDK，巴不得你基于它们二次开发。牛顿怎么说的，站在巨人肩膀上不丢人。
你是不是也曾经盯着 pprof 火焰图发呆？
线上服务 P99 延迟从 50ms 飙到 800ms，Grafana 告警刷了满屏。CPU profile 翻来覆去看了三遍，热点函数是 sync.Mutex.Lock —— 锁竞争。但问题出在哪？锁粒度大、false sharing、还是并发模型本身选错了？脑子里闪过一堆可能性，每一条都够排查半小时。
如果有一个 Go语言的并发专家和性能专家在身边多好。
还有，对于有经验的老Go程序员，已经习惯了历史的Go语法和代码，对于新的特性反而没有新手更了解，如何保持与时俱进而不被新人所唾弃？
现在，这个愿望变成了现实：三个skill = 顶级有活力的Go语言专家。
做 Go 开发这些年，我发现 Go 程序员面对的最棘手的问题，几乎都可以归为三类：
第一类：并发。 死锁、数据竞争、goroutine 泄漏、channel 关闭时机不对、WaitGroup 计数配不平、锁重入导致自死锁……你写过 Go，就一定被其中至少一个坑过。
PRD（产品需求文档）和 SPEC（设计/技术规格说明书）是软件及硬件产品开发中两个不同阶段的核心文档，其核心区别在于：PRD 解释“做什么以及为什么做”（What & Why），而 SPEC 解释“怎么做以及做成什么样”（How & What exactly）。
| 维度 | PRD (Product Requirement Document) | SPEC (Specification) |
|---|---|---|
| 中文名称 | 产品需求文档 | 规格说明书（产品/技术/功能规格） |
| 核心回答 | 解决什么用户痛点？产品要实现哪些功能？ | 系统如何实现？输入输出的标准和边界是什么？ |
| 主要撰写者 | 产品经理 (PM) / 产品负责人 (PO) | 架构师 / 技术主管 (Tech Lead) / 资深工程师 |
| 维度 | 方案设计 (Design Doc / Proposal) | SPEC (Specification) |
|---|---|---|
| 所处阶段 | 技术调研与评审阶段（写代码前） | 最终确认与开发阶段（写代码时） |
| 核心目的 | 寻找解法，权衡利弊（Trade-offs） | 统一标准，指导施工（作为交付契约） |
| 内容特点 | 包含多种备选方案（方案A vs 方案B） | 只有一种确定的、极度详细的最终方案 |
| 状态变化 | 动态的，讨论后会被修改或推翻 | 静态的，通过评审后作为基线，轻易不改 |
你是否曾经有过这样的经历：
写了一篇 PRD，结果开发实现的时候完全跑偏
实现完代码后，发现还有一堆体力活要做：代码审查、写 commit、创建 PR、等待 CI 检查...
团队成员对同一个需求理解不一致，导致返工
多次开会同步需求进度，但最终代码还是和预期不一样
Issue 拆得太细或太粗，开发时常卡住不知道下一步该做什么
每次提交都要重新敲一遍规范的 commit message，累死了
2026 年 5 月 20 日，Google 在 I/O 大会上发布了一连串重磅产品更新。其中最让我兴奋的，不是那个桌面版的 Antigravity 2.0，而是那个安安静静躺在终端里的 Antigravity CLI。
为什么？因为它正式宣告了 Gemini CLI 时代的结束——也宣告了 Google 在 AI 编程终端战场上的全新布局。
很多人对 Gemini CLI 并不陌生。2025 年 Google I/O 上发布，开源，Apache 2.0 协议，免费 tier 给到 60 requests/min 和 1000 requests/day，一度是很多开发者入门 AI 编程终端工具的首选。
Peter Steinberger（GitHub 上的 steipete）是一个在 AI 开发工具领域绕不开的名字。他曾白手起家将 PSPDFKit 做到百万美元 ARR 并成功退出，如今在 OpenAI 负责 Agent 相关研发。他创建的 OpenClaw 项目收获了 37 万+ stars，而 Clawpatch 和 codex-review skill 是他 AI 编程工具链中专注于代码审查这一环的两个代表作。
传统代码审查有个结构性矛盾：审查者往往不熟悉被审查代码的完整上下文，所以要么流于表面（看看命名、格式），要么只能依赖作者写的 PR 描述来理解意图。AI 时代的解法很直接——让一个能读懂整个代码库的 Agent 来做审查。但不是随便把代码丢给 LLM 让它"看看有没有问题"就行，真正的挑战在于：如何划定审查边界、如何确保证据可追溯、以及发现问题后如何安全地修复。
Clawpatch 和 codex-review skill 分别从"工具链自动化"和"工作流规范化"两个角度回答了这些问题。
Clawpatch（clawpatch.ai，GitHub：openclaw/clawpatch）是一个命令行代码审查工具，MIT 协议开源。它的核心思路是把代码审查从"逐文件扫描"升级为"按语义单元审查"。
CLIProxyAPI 是一个轻量级 AI API 代理服务器，核心功能是在 OpenAI Responses API 和 Chat Completions API 之间做双向格式转换。它使得仅支持 Responses API 的客户端（如 OpenAI Codex CLI）能够访问仅提供 Chat Completions API 的模型（DeepSeek、GLM、Kimi 等）。
1 | Codex CLI |
instructions → system message，input → messages）
你是否曾经有过这样的经历：
写了一篇 PRD，结果开发实现的时候完全跑偏
实现完代码后，发现还有一堆体力活要做：代码审查、写 commit、创建 PR、等待 CI 检查...
团队成员对同一个需求理解不一致，导致返工
多次开会同步需求进度，但最终代码还是和预期不一样
Issue 拆得太细或太粗，开发时常卡住不知道下一步该做什么
每次提交都要重新敲一遍规范的 commit message，累死了
Jesse Vincent（GitHub 上的 obra）是一个在开源社区深耕二十多年的开发者。他写过键盘固件（Keyboardio 的 Kaleidoscope）、做过邮件客户端（K9-Mail 的核心维护者）、如今在 Prime Radiant 专注于 Agent 开发工具。他在 2025 年 10 月发布了 Superpowers——一个面向 AI Coding Agent 的完整软件开发方法论，以 skills 集合的形式提供，短短时间就冲到 196K stars。
如果你看过我之前写的 mattpocock/skills 那篇文章，你大概已经理解了"skill 文件"这个概念——YAML frontmatter + Markdown 指令集，Agent 读取后按指令执行。mattpocock/skills 提供的是离散的工具（盘问、TDD、架构审查），你需要自己决定什么时候用什么。Superpowers 的思路完全不同：它是一套自动触发的完整开发流程，从你打开 Agent 说出需求的那一刻起，到代码合入主分支为止，每个阶段都有对应的 skill 接管，而且 skills 之间会自动串联。
Vincent 管它叫"让你的 Agent 拥有超能力"。读完你会发现这个比喻不算夸张——它本质上是用一套指令模板，把一个散漫的 Agent 变成了一个遵循完整工程纪律的协作者。
如果说前面的章节是在讲 Superpowers 能做什么，这一节我们要问一个更尖锐的问题：它没有缺点吗？
Superpowers 对"先设计再实现"的坚持，在软件工程教科书里能找到完美的理论支撑。但实际开发中，很多有价值的东西是通过"先做出来看看"发现的。你没办法在 brainstorming 阶段预料到用户会怎么用这个功能，因为你自己也没用过它。
Vincent 在设计文档中提到"简单的项目可以写几句话"，试图给敏捷留出空间。但实践中，Agent 并不擅长判断"什么叫简单"——它倾向于把一切需求都展开成完整的 brainstorming 流程，因为 skill 告诉它"不要跳过设计"。一个五分钟能写完的 bug 修复，可能要花三分钟回答 Agent 的盘问、两分钟确认设计文档、然后才轮到你期待的那五分钟。对于熟练的开发者而言，这种体验可能更像是"终于教会了 Agent 怎么做事"而非"Agent 帮我把事做了"。
这不是反对设计。这是提醒你：Superpowers 的设计纪律是有摩擦成本的。它最适合的场景是那种"需要多人协作、多天开发、多轮审查"的中大型功能——这种场景下，前期设计投入被后期返工避免所抵消。但对于个人开发者的快速迭代、原型探索、或者"先做个 MVP 看看反响"的项目，Superpowers 的全程流程可能是一种过度工程。
Superpowers 的 token 消耗模型值得算一笔账。以 subagent-driven-development 模式为例，每个任务触发至少三次 Agent 调用（实现 + spec 审查 + 代码审查），如果有问题还要走审查修复循环。对于一个 10 个任务的中等功能，保守估计 30-50 次 Agent 调用。用小模型跑机械任务可以降低成本，但小模型在 spec 理解和代码生成上的质量下降会反过来增加修复循环的次数——成本可能只是从 token 账单转移到了你的等待时间上。
这引出了一个更根本的问题：Superpowers 的受众到底是谁？ 是那些已经熟练掌握传统软件工程方法、现在想让 Agent 替代自己执行重复性工作的资深开发者？还是那些缺乏工程经验、需要一套自动化流程来弥补纪律缺失的新手？Vincent 在 README 中说这套流程让 Agent "像一个有热情但品味差、缺乏判断力、不熟悉项目上下文、还讨厌写测试的初级工程师"。问题是——如果你自己都不知道怎么带一个初级工程师，你有多大把握带好一群 AI 初级工程师？
这不是怀疑 Superpowers 的价值。196K 的认可不可能全是盲目的。这是说，Superpowers 在"降低门槛"这件事上可能做了一个错误的承诺。它降低的是 Agent 写代码的组织门槛——不用手动组织 subagent、不用人工审查每个任务的 spec 合规性。但它并没有降低——甚至可能提高了——对使用者的工程判断力要求。你需要判断 Agent 的设计方案是否合理、需要决定哪些审查意见是有效的、需要在 subagent 报 BLOCKED 时诊断根因。这些能力恰恰是传统软件工程中最难培养的部分。
Superpowers 是一个值得认真对待的工程实验。但对待它的最好方式，也许不是把它当作答案，而是把它当作一个起点——理解它的设计意图，然后根据自己的项目和能力，裁剪出一套属于你自己的流程。就像 Vincent 在文档末尾写的那样，这不是宗教。这是一套工具。工具的意义不在于被信仰，而在于被使用、被修改、被超越。
Q1：Superpowers 的 brainstorming 是不是太"重"了？给一个 todo list 也要走完整流程？
Superpowers 的立场很明确：简单的需求恰恰是最容易因为未检验假设而翻车的地方。"加一个 todo list"——存储在哪？本地还是云端？需要同步吗？排序规则是什么？这些假设如果在实现中途才发现不对，返工成本远超 brainstorming 那几分钟。但设计文档的长度可以按复杂度缩放——简单的需求写几句话就行，不需要长篇大论。
Q2：子 Agent 的两级审查（spec + code quality）会不会太费 token？成本怎么控制？
这是 Superpowers 最明显的成本来源——每个任务要派 1 个实现 agent + 2 个审查 agent。但它采用了"用最便宜的模型做最简单的事"的策略：机械性实现任务用小模型，审查任务用标准或强模型。而且 Vincent 的核心理念是"早发现比晚修复便宜"——在子 Agent 阶段拦截问题，比合并后 debug 省 token。实际使用中，只要任务拆得够细（2-5 分钟一个），单任务的审查成本是可控的。
Q3：Agent 在 subagent-driven-development 模式下真的能自主跑一两个小时？会不会跑偏？
会跑偏，但有机制防范。第一道防线是 spec——每个任务都对照 spec 验证合规。第二道防线是两级审查——如果实现 subagent 的理解有偏差，审查 subagent 会挡下来。第三道防线是实现 subagent 有四种状态报告（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED），遇到问题会主动升级而不是硬撑。Vincent 提到"一两个小时"是比较顺利的情况，实际使用中还是会时不时需要你介入回答 subagent 的问题。
Q4：TDD 的"事先写的代码必须删除"这条铁律是不是太极端了？
这不是道德洁癖，是一个实用的工程判断。测试后写的代码有一个根本问题：你永远不知道测试是否真正捕捉到了正确的行为——因为测试一写就通过。只有先看到测试因为"功能缺失"而失败（不是语法错误），你才能确认这个测试确实在测你要实现的东西。如果保留了先写的代码再做测试，你实际上是在"对着实现写测试"而非"对着需求写测试"，很容易测的是实现细节而非行为。
Q5：Superpowers 适合老项目还是新项目？
都适合，但老项目需要注意一点：brainstorming 的"探索项目上下文"阶段会读取现有文件、文档和最近提交来理解代码库。如果老项目的代码结构混乱、缺乏模式，Agent 可能需要更长的探索时间，提出的方案也可能不够精准。建议在老项目中先用一次 brainstorming 走完整流程，看看 Agent 对代码库的理解程度，再决定是否全面采用。
Q6：多个 Agent 平台都支持，实际体验有差异吗？
有。Superpowers 的 skills 是通用的 Markdown 指令，但不同 Agent 对 skill 的"理解深度"和"执行纪律"不同。Claude Code 对 subagent 的支持最成熟（Superpowers 最早就是为 Claude Code 设计的），Codex CLI 的执行速度更快但 TDD 纪律偶尔会松动。实际使用中建议用 Claude Code 做主 Agent、Codex 做实现 subagent 的混合模式。
Q7：我可以只装部分 skill 吗？比如只用 brainstorming 和 TDD，不用子 Agent 编排？
技术上可行——skills 是独立的 .md 文件，你可以选择性安装。但 Superpowers 的很多 skill 之间有硬依赖：subagent-driven-development 依赖 writing-plans 产出的计划格式，writing-plans 依赖 brainstorming 产出的 spec 路径约定。拆开用的结果可能是 skill 之间的衔接断裂，导致流程中断。如果你只需要部分功能，更推荐用 mattpocock/skills 那种独立组合式的 skill 集合。
Q8：和 mattpocock/skills 能共存吗？
可以，但需要留意冲突点。两者的 TDD skill 都会在你写代码时被触发，可能产生竞争。建议的做法是：用 Superpowers 作为主要工作流（覆盖 brainstorming → 实现 → 合入的完整链路），把 mattpocock/skills 中的 /diagnose、/improve-codebase-architecture、/prototype 等 Superpowers 没有覆盖的 skill 作为补充工具。两者用的都是 skill 文件格式，在同一个项目中安装不会相互覆盖。
