第30章：四个流行的需求规划 Skill 的功能对比

有人问我 superpowers 和 Matt 的 skills 哪个更好？这问题不好答。在我看来两者没有谁明显压过谁，就像你争论少林、峨眉、青城、武当哪家功夫最强，各人有各人的判断。

但也不能光和稀泥。下面我挑了四个生成 SPEC/PRD 的技能，把它们的功能摆到一起比一比——不为分个高下，只想看清各自的脾气。

其中 prd 是我参考 ralph loop skill 改造的一个需求文档生成技能。

一、brainstorming（头脑风暴 → 设计稿）

brainstorming 来自 obra 的 superpowers，它管的是所有创造性工作的最上游——新功能、新组件、改行为，动手之前先通过一场对话把模糊想法磨成一份完整的设计稿。它的 description 写得很硬：任何创造性工作之前你都「必须」先用它。

它最有辨识度的地方是一道硬性闸门（HARD-GATE）：在把设计拿给用户、并拿到批准之前，禁止写任何代码、禁止 scaffold 项目、禁止调用任何实现类 skill——无论这个项目看起来多简单。紧跟着的是一条反「太简单」的原则：待办列表、单函数小工具、一次配置修改，全都要走这套流程。理由也讲得直白——恰恰是那些看着简单的项目，藏着最多没被审视的假设，返工往往就出在这里。当然，简单项目的设计可以只写几句话，但你必须写出来、必须过一遍批准。

流程本身是一张九步清单，要求给每一步建一个 task 按顺序做完：先摸清项目上下文（翻文件、文档、近期提交），一次只问一个澄清问题，抛出 2-3 个带取舍的方案并给出推荐，然后分节呈现设计、每节单独获批，再把设计文档写到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交 git，接着做一遍 spec 自审、请用户复审，最后转入 writing-plans。这里有个刻意的约束：流程的终态只能是 writing-plans，不允许直接跳到 frontend-design 之类的实现 skill。

它还配了一个「可视化伴侣」——一个浏览器端组件，用来展示原型、图表、并排对比。但它强调即时提供而非一上来就给：只有当某个问题「画出来比说出来更清楚」时才第一次提议，而且提议要单独成一条消息。即便用户接受了，也是逐个问题判断该用浏览器还是终端——UI 话题不等于视觉问题，「这个语境里 personality 指什么」是概念问题，走终端；「哪个向导布局更好」才是视觉问题，走浏览器。贯穿始终的几条原则是：一次一问、能选择题就别开放式、狠抓 YAGNI、先探索多个方案、增量验证。

二、grill-with-docs（带文档产出的拷问）

grill-with-docs 来自 Matt Pocock 的 skills，定位是一场「毫不留情」的访谈式追问，用来打磨一份计划或设计，而且在追问的同时把决策文档（ADR 架构决策记录加术语表）顺手沉淀出来。

有意思的是它的 SKILL.md 本身极简，正文只有一行：跑一个 /grilling 会话，并使用 /domain-modeling skill。换句话说，它不是一个从头写起的独立技能，而是一个组合入口——把两个更底层的能力（逐问拷问 + 领域建模）编排在一起，附带产出决策记录。它标了 disable-model-invocation: true，不允许模型自动触发，必须由用户显式调用。

所以它的性格是轻量的：一个可复用的「追问 + 建模 + 记录」三合一动作。也正因为轻，它常常不是单独出现，而是作为别的流程的一个子步骤被复用——下面要讲的 wayfinder，内部就直接调它。

三、wayfinder（寻路：超大规模工作的共享地图）

wayfinder 处理的是大到单个 agent 会话根本装不下的工作。它的比喻很贴切：一团迷雾般的想法，从这里到「终点（destination）」的路还看不清，wayfinder 要做的是找出这条路，而不是闷头冲向终点。它把这条路画成 issue tracker 上的一张共享地图，地图由一个个「决策工单」组成，一次解决一个，直到通往终点的路径清晰为止。SKILL.md 里给它定的第一条规矩，就是先给终点命名——终点可能是一份待交接迭代的 spec、一个要在规划前锁死的决策，也可能是像数据结构迁移这样直接就地做出的改动；命名终点是画图的第一个动作，因为它框定了整张地图的范围。

地图本身是 tracker 上一个打了 wayfinder:map 标签的 issue，工单是它的子 issue。这里有个关键的设计：地图只是索引，不是仓库——每个决策只存在于它自己那张工单里，地图对它只留一行摘要加一个链接，绝不重复记载。而且不管是地图还是工单，凡是给人看的叙述一律用标题里的名字来指代，而不是 #42 这种裸编号，因为一屏的 #42, #43, #44 根本没法读，名字才能一眼扫过去。地图正文固定四五段：Destination（终点）、Notes（领域、常用 skill、这次的偏好）、Decisions so far（已闭合工单的索引）、Not yet specified（还看不清的战争迷雾）、Out of scope（明确排除在外的）。

工单分四种类型，每种要么是 HITL（有人在环，必须和真人现场交流才能推进，agent 绝不替人回答自己那半边），要么是 AFK（agent 独自推进）。Research 是 AFK，派一个 /research 子 agent 去读文档或第三方 API，捞出决策要等的那个事实；Prototype 是 HITL，做一个便宜粗糙的原型让人有个具体东西可反应，适合「该长什么样、该怎么表现」是核心问题的时候；Grilling 是 HITL，也是默认类型，就是调 /grilling 加 /domain-modeling 一次问一个问题；Task 比较特殊，是四种里唯一「动手做」而非「做决策」的——它处理的是决策做出前必须先完成的手工前置，比如为了评估某个 API 先去注册服务、开通权限、把数据挪到能看清结构的地方，它靠解锁一个决策来挣得自己的位置，而不是靠交付终点。

它还有两个很讲究的机制。一个是「战争迷雾（fog of war）」：地图是故意不完整的，看得见但还画不清的决策先放进 Not yet specified，等解决掉前面的工单、迷雾散开，能说清的部分才「毕业」成新的工单——判断一件事该建工单还是留在迷雾里，标准是「你现在能不能把问题问清楚」，而不是「你现在能不能答」。另一个是「只规划不执行（Plan, don't do）」：默认只产出决策、不产出交付物，一旦你产生了想动手做的冲动，那往往正是「已经走到地图边缘、该交接了」的信号。它依赖 tracker 原生的阻塞关系，在 UI 上把「前沿（frontier）」——那些开着、没被阻塞、也没人认领的工单——直接可视化出来。还有一条铁律：除 research 类外，每个会话最多解决一个工单。

四、prd（产品需求文档生成器）

prd 是我参考 ralph loop skill 改造的一个技能，目标很直接：为一个新功能生成一份清晰、可执行、能直接进入实现的产品需求文档。它的 description 里挂了一串触发词，包括「写PRD」「需求文档」「需求分析」这些中文关键词，所以它既能显式调用，也能被关键词自动触发。

它走的是一套六步工作流：接到功能描述后先按复杂度提问，然后生成结构化 PRD，请用户复审、回 OK 确认，再保存到 tasks/prd-[feature-name].md，最后建议下一步。提问的数量不是固定的，而是按功能复杂度伸缩——简单功能问 2-3 个，典型功能 3-5 个，涉及多角色、跨系统集成的复杂功能问 6-8 个；某个维度如果从用户输入里已经清楚了，就直接跳过，不为了凑数问废话。提问用的是选择题形式，每题带 A/B/C/D 选项，用户可以用「1A, 2C, 3B」这样快速作答。它也明确只产出 PRD、不动手写代码。

生成的 PRD 有固定的九段结构：概述、目标、用户故事、功能需求、非目标、设计考量、技术考量、成功指标、待解问题。其中两处约束卡得比较死。用户故事按 US-001 编号，每条都要带可验收标准，而每条验收标准都得过一遍自检——必须是可观察、可测试、或可验证三者之一，「运行正常」「体验良好」这类空话一律要重写；凡是涉及 UI 的故事，强制带上「在浏览器中验证」这一条。功能需求按 FR-N 编号，每条只描述一个行为，不允许用 and 把好几个行为塞进同一条。它还专门列了一张边界情形表，处理用户跳过提问、输入太模糊、tasks/ 目录不存在、PRD 超过 500 行该拆分等场景。PRD 确认后，它会建议往下接 /prd-to-spec（可选的技术设计）和 /to-issues（拆成可实现工单），再用 /goal 去实现。

五、异同比较

共同点

如果我们把这四个技能摆到一起对比，会发现它们有不少共通处。最明显的是都坚持规划先行、不许过早动手——brainstorming 和 prd 都白纸黑字写着别急着实现，wayfinder 默认只规划不执行。

澄清需求的方式也一致，都走结构化的对话：brainstorming 一次一问，prd 用选择题，grill-with-docs 逐问拷问，wayfinder 内部同样靠 grilling，没有一个赞成把问题一股脑抛给你。

它们最后都落到一份能留存的产物上，brainstorming 出设计稿，prd 出 PRD 文件，grill-with-docs 出 ADR 和术语表，wayfinder 出一张 issue 地图；产物之后往哪走也都规定好了，分别接 writing-plans、prd-to-spec/to-issues、以及各类工单和后续执行。

还有一点容易被忽略：四者都内建了防偷懒的约束，brainstorming 的 HARD-GATE 和反简单化、prd 的验收标准自检、wayfinder 的每会话一工单，都是同一种用心。

差异点

关系与层次

再看它们之间的层次。

grill-with-docs 处在最底层，是个「怎么问」的动作原语，被 wayfinder 直接复用——wayfinder 的 Grilling 工单就是调 /grilling 加 /domain-modeling。

brainstorming 和 prd 是同一层的单项目规划器，区别在侧重：brainstorming 偏工程设计与架构，prd 偏产品需求与验收，后者模板化更强、更容易直接拆成工单，前者更看重方案探索和设计取舍。

wayfinder 站得最高，是个元规划器——当一摊活大到单份 spec 或 PRD 装不下时，它先拆成一张地图，再在每个节点上调 grilling、prototype、research 这些更细的手段。某种意义上，brainstorming 或 prd 本身就可以是 wayfinder 某个工单的解法。

说到底，grill-with-docs 是「怎么问」的原子能力，brainstorming 和 prd 是「一个功能怎么规划」的两种风格（工程设计与产品需求），wayfinder 则是「一大摊活怎么分而治之」的顶层地图。

我的经验

在最近的几个新的项目我也在摸索这些 skill 的使用：到底应该使用哪一个技能生成需求文档或者 SPEC？

我的经验是：

• 如果你已经有代码原型，比如我最近实现的把 rdma 库迁移到 Go 语言，把 python scapy 库迁移到 Go 语言，或者已经有一个初版的项目需求文档，那么使用 prd 会很方便。这是因为需求已经非常的明确了，prd 可以精确的帮你梳理好需求，整理好可以验证的用例，更容易生成可以实现和验证的 issue。
• 如果你的需求还很模糊，比如你只接到一个需求：『把信送给加西亚』或者『把这个页面修改为五彩斑斓的黑』，那么你可以使用 wayfinder 或者 使用 brainstorming 来梳理清楚需求文档或者 SPEC。这两个 skill 的风格也不太一致，就看你喜欢哪一种风格了：brainstorming 是一场连续的当面对话，wayfinder 是一张异步流转的地图。
  • brainstorming —— 同步、单会话、你全程在场。它就坐在你对面，一次问一个问题，靠一来一往的苏格拉底式追问把模糊想法磨清楚。整个过程是一段连续的对话，你必须一直在线（HITL，human-in-the-loop）。它有个硬门（HARD-GATE）：设计没得到你批准之前不许写代码。对话的终点是设计定稿、进入写计划。适合一个会话能装下的想法。
  • wayfinder —— 异步、跨会话、地图代替对话。它不跟你长谈，而是把一个打了 wayfinder:map 标签的 issue 当成共享地图，把「已定的决策」和「还没想清的问题」都写在上面。然后把待调查的东西拆成子票据，每张票据分两类：
    • AFK（away-from-keyboard）：像 Research 这种，Agent 自己跑，不需要你在场。
    • HITL：像 Grilling 这种，需要你亲自参与。
    你不是全程盯着，而是「有票需要你时才回来」——地图上哪些前置都完成了、又没人认领的票，就是可以动手的前沿。状态存在地图里，不存在对话里，所以换个 Agent、隔天再来都能接上。适合又大又模糊、一个会话根本装不下的项目。