| 维度 | 方案设计 (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 文件格式，在同一个项目中安装不会相互覆盖。
Matt Pocock 大概是 TypeScript 社区里最广为人知的面孔之一了。他的 Total TypeScript 课程和 YouTube 频道帮无数开发者搞懂了类型系统。但最近他在 GitHub 上火起来的原因不太一样：他把自己日常使用的 AI Coding Agent 的 skills 集合开源了，仓库名叫 mattpocock/skills，短短时间就冲到 89K+ stars、7.8K forks，总安装量 140 万次。这些 skills 不是"帮我写个登录页"那种 prompt 模板，而是直接从他 .claude 目录里拿出来的、每天在用的一套工程化开发流程。
Pocock 这套 skills 的深层逻辑是：AI 不会取代软件工程的基本功，它只是把基本功的重要性放大了。需求分析、领域建模、测试策略、架构设计——这些在 AI 出现之前就存在的实践，现在不仅没有过时，反而因为开发速度的提升而变得更加关键。
他解决的四个核心问题，全部对应经典软件工程文献中的原则：
问题一：Agent 没有按你想要的方式做。 来自《程序员修炼之道》——"没人确切知道自己想要什么"。解法 /grill-me 的本质是把传统开发中靠开会、写 spec 来对齐的过程用 Agent 的盘问能力自动化了。
问题二：Agent 过于啰嗦。 来自《领域驱动设计》的"统一语言"概念——团队需要共享术语表。解法 /grill-with-docs 在项目中维护 CONTEXT.md，不仅让对话简洁，还让命名、文件结构、代码组织都围绕同一套语言展开。
问题三：代码不工作。 来自 Kent Beck 的极限编程——"反馈速度就是你的速度上限"。解法 /tdd + /diagnose 构建了写代码→验证→调试→修复的完整反馈闭环。
问题四：代码变成泥球。 来自 Ousterhout 的深模块理论——"最好的模块是深的，用简单的接口提供大量功能"。解法 /improve-codebase-architecture 给了 Agent 发现和修复架构问题的能力。
Pocock 做的事情，本质上是用一套可复用的指令模板，把几十年的工程纪律"焊"进了 Agent 的工作流里。如果你已经厌倦了"Agent 又写了一堆没法用的代码"的循环，这套 skills 值得花一个下午试试。效果怎么样，跑一次 /grill-with-docs 就清楚了。
Q1：这些 skills 只能用于 Claude Code 吗？
不止。通过 skills.sh 平台安装后，支持 Claude Code、Codex、Cursor、GitHub Copilot、Windsurf 等主流 AI 编程 Agent。本质上 skill 就是 Markdown 指令文件，如果你的 Agent 支持读取本地文件作为上下文（大多数都支持），直接把 SKILL.md 的内容喂给它就行，不一定需要 skills.sh 这个中间层。
Q2：这和 Cursor Rules / .cursorrules 有什么区别？
思路相似但层次不同。Cursor Rules 是静态的全局或目录级规则（"始终使用 Tailwind CSS"、"用 TypeScript 严格模式"），适合设定约束。Pocock 的 skills 是交互式工作流——/grill-with-docs 会主动盘问你、更新文档、创建 ADR，它是一个有状态的对话过程而不只是一段静态指令。两者可以共存：用 Cursor Rules 设定基础约束，用 skills 驱动具体开发流程。
Q3：18 个 skill，太多了。从哪个开始用？
最小启动路径只有三步：/setup-matt-pocock-skills（一次）→ /grill-with-docs（每次动手前）→ /tdd（写代码时）。这三个覆盖了需求对齐和编码质量的核心环节，已经能解决大部分"Agent 写了一堆废代码"的问题。其余 skills 等遇到具体场景再按需取用：bug 排查用 /diagnose，代码腐化了用 /improve-codebase-architecture，issue 太多用 /triage。
Q4：CONTEXT.md 和 ADR 会不会让项目变得很重？
恰恰相反。CONTEXT.md 只存术语定义（比如"PartialRefund: 针对单个 LineItem 发起的退款"），不存实现细节。ADR 的创建门槛很高——必须同时满足"难以逆转 + 缺上下文很奇怪 + 真实权衡"三个条件才写。大多数日常决策不会触发 ADR。这两个文件的体积通常很小，但 Agent 读取后能大幅降低沟通成本。
Q5：我怎么自己写一个 skill？
目录结构非常简单：创建一个文件夹，里面放一个 SKILL.md 文件，顶部用 YAML frontmatter 写 name 和 description，正文写工作流指令。可以参考 /write-a-skill 这个 skill 来引导创建，或者直接 fork 现有的 skill 改内容。skills.sh 平台支持发布你自己的 skill 集合。
Q6：团队里多人使用，会不会每个人的 CONTEXT.md 不一致？
CONTEXT.md 和 ADR 文件是提交到 Git 仓库里的，所以天然就是团队共享的。团队成员只需要 git pull 就能同步最新的术语表和架构决策。如果多人同时用 /grill-with-docs 修改了同一个文件，Git 合并冲突也很容易解决（纯 Markdown 文本）。
Q7：项目已经有 CLAUDE.md 了，会冲突吗？
不会。CONTEXT.md 是领域术语表，docs/adr/ 是架构决策记录，和 CLAUDE.md（通常是项目级别的 Agent 行为指令）是互补关系。你可以把这三个文件理解为：CLAUDE.md 告诉 Agent "怎么做"，CONTEXT.md 告诉 Agent "说的是什么"，ADR 告诉 Agent "为什么这么决定"。
想给大模型训推任务灵犀诊断平台增加「自我演化」的功能，尝试使用claude code的最新的/goal命令，记录从需求拆解到代码合入的完整流程，供同学参考。
最近两周codex、hermes相继发布/goal斜杠命令,这一周 claude code也不甘示弱，跨速发布了它的 /goal 斜杠命令。本文将/goal斜杠命令 + /prd技能 + /after-goal技能，实现了一个产品特性研发全自动化的流程，探索出一个AI+实践的新案例。
在百度内部研发场景中，一个功能从需求到上线通常经历：写 PRD → 拆卡片 → 写代码 → 提 CR → 合入 → 关卡片。这套流程环节多、工具分散（iCafe、iCode、Gerrit），每一步都要手动操作，容易遗漏步骤。
借助 Claude Code 的 Skill 机制，我们可以将这套流程固化成三个阶段，每个阶段对应一个 Slash Command：
| 阶段 | 命令 | 做什么 |
|---|---|---|
| 需求拆解 | /prd |
生成 PRD 文档，拆分为可实现的 iCafe 卡片 |
