---
name: requirement-elicitation
description: '通过协作对话挖出用户真实业务痛点、在动手实现前先把需求搞对的心智——本仓 dev 流的需求发现闸（取代 superpowers:brainstorming，让 cc-master 的 dev meta-skill 自洽不外依赖）。Use when: 开始本仓任何 feature / skill / 行为改动之前（动第一下实现之前，无论请求看起来多简单）；请求以一个猜出来的方案形态到来而底层问题没说出口（"加个按钮" / "给我做个 X"）；要建模或动手却说不清真实需求、指不出一个它真在疼的具体实例；为一个新问题空间和用户共创词汇；一个请求捆了多个独立子系统、动手前要先拆；作为 master orchestrator 跑前台需求发现对话（挖需求是指挥自己的活，绝不外包）。Do NOT use: 已确认需求后写一个 skill 的 body → cc-master-skillsmith；判要不要建 skill / 放哪 / 会不会重叠 → curating-skill-portfolios；度量一个已写好的 skill → grounding-skill-evals；写 workflow 脚本怎么 parallel/pipeline → authoring-workflows；驱动一个已批准的 goal 到完成（编排执行 loop）→ orchestrating-to-completion。'
---

# 需求挖掘（Requirement Elicitation）—— cc-master dev skill

你已经会各种访谈技巧——five whys、jobs-to-be-done、开放式提问。这个 skill 装的是技巧清单装不下的东西：对「一个用户请求到底是什么」的**信念（conviction）**，和「何时、挖多深」的**品味（taste）**。这里**故意没有问题清单**；一个握住信念的模型，即兴出的问题比任何脚本都好。

> **它在本仓的位置**：这是 cc-master dev 流的**需求发现闸**，取代通用的 `superpowers:brainstorming`（这一步内置于本仓、接地到本仓的形态，让造 / 评 / 治三件套有一个自洽的上游）。它是 `发现 → 准入（curating）→ 造 body（skillsmith）→ 度量（grounding）` 这条链最上游的一环。

## 核心信念（道）

**用户的字面话是症状——往往是对一个没说出口的问题猜出来的解法——绝不是需求本身。** "加个导出按钮"是用户在替*你*干活：他感到了某种疼，私下假设了一个修法，把这个假设递给了你。照着假设造，你可能交付一个让疼痛原封不动的功能。需求，是那个让他想要这个按钮的东西。

cc-master 把这条信念落在它**自己的形态**上，而不是某套外部领域模型里。orchestrator 的 **board 以一个 `goal` 为根**，整张任务依赖图都从它派生——`goal → DAG → tasks`。坐下来想想这意味着什么：**整条下游工作的源头是一次「解读」。** 如果这次解读错了，整张依赖图——每个被派发的任务、每次端点验收——都是从一个谎言*正确地*推导出来的。下游再严谨也修不好一个读错的源头。需求发现，是整个系统要么被夯实、要么被毒化的那一刻。

造 skill 时同理：真实需求是 `发现 → 准入 → 造 → 度量` 这条链的根。读错它，三件套会忠实地在一个错前提上各自执行到底——curating 给一个不该存在的能力跑出漂亮的 scoresheet，skillsmith 把它的 body 写得形质俱佳，grounding 还煞有介事地度量它。全程无误，全程错。

这正是本仓「**no-silent-failure / gate-green ≠ passed**」那条红线在需求发现阶段的同构：端点验收逼你区分「闸绿了」和「真过了」；需求发现逼你区分「用户原话」和「你的推断」、「猜出来的需求」和「确认过的需求」。系统从不让一次解读冒充一个逐字事实——对话里你也别。

## 命名即建模：发现就是第一次建模

Eric Evans 把领域建模的前端叫 *knowledge crunching*：领域模型与统一语言（ubiquitous language）既不是从专家嘴里抄录、也不是设计者凭空发明，而是从专家与设计者的**协作对话中涌现**。这里的领域专家就是用户。你不是在誊抄一张订单，你是在和用户一起共同发现一个关于他的问题的模型。

每一次需求对话本身已经是第一次建模会议：你和用户收敛到的那些词，就是候选的统一语言——它们日后会硬化进这个 skill 的 `description` / `DESIGN.md`、或 board 的 `goal` 陈述。所以发现阶段的**命名是承重的**，当它承重来对待。

## 发现的品味（The Discovery Sensibility）

这些是要握住的**判断**，不是要执行的步骤——每一条在 [discovery_moves.md](references/discovery_moves.md) 里展开（连同它为什么能逼出真相、做好与做砸长什么样）：

- **追 job，别追 feature。** 每个被请求的功能背后，都有一个用户想搞定的 job。功能只是这个 job 的一个候选「雇员」——通常不是最好的那个。
- **没有一个它真在疼的具体实例，你就还没理解这个需求。** 用户陈述的抽象（"我需要更好的可见性"）是未经验证的理论；一个最近的具体片段（"上周二我花了一小时重建 agent 夜里干了什么"）才是证据。把片段抠出来。
- **把痛点和提议的方案分开。** 绝对尊重痛点；松松地握住方案。前者用户是不容置疑的权威，后者他和你一样是个猜的。
- **够向「极度具体」。** 含糊的需求产出含糊的设计。需求真正栖身之处，是那个最窄、最具体到扎心的版本。
- **用用户自己的话把需求复述回去。** 这既是验证（他现在就纠正你的误读，而不是等你造完），也是语言锻造（他的纠正就是正在诞生的统一语言）。

## 协作的姿态（The Collaborative Stance）

好的设计文化靠的是**对话，不是审讯，也不是独白**。别要求用户给你一份 spec——他没有，假装他该有就是推诿。也别消失一阵、回来甩一份成品设计让他盖章——那是在浪费他的判断力。工作节奏是：带一个 **strawman（草人）**给用户去反应、讨论，然后推荐。人纠正一个具体的错东西，远比凭空指定一个抽象的对东西在行——strawman 把用户的默会知识转换成纠正，而那恰是你直接问问不出来的知识。本仓的设计节奏就是这条：**strawman → 讨论 → 推荐**。用户共同思考，你共同发现。

## 设计闸（The Design Gate）

发现流向设计，设计流过一道闸：**在一份设计被呈现、用户批准之前，不准有任何实现动作——不写代码、不搭脚手架、不调用任何实现型 skill（包括不要跳进 skillsmith 去写 body）。** 这与「感觉上多简单」无关。"简单"的请求恰恰是未经审视的假设最能作乱的地方，因为没人觉得需要检查；一个真正简单的改动，它的设计也许就三句话——但呈现它不是可选项。

闸上活着三个判断：

- **先定范围，再抠细节。** 如果请求捆了几个独立子系统，*在*精修任何东西*之前*先把这点标出来——拆分先于设计，每一块再各走自己的「发现 → 设计 → 计划」循环。花在打磨一个本该拆开之物的细节上的问题，是浪费的问题。（当这次拆分是关于「这是不是该拆成几个 skill」时，把它交给 `curating-skill-portfolios` 的「先拆」判定。）
- **带方案来，别带既成事实。** 呈现 2–3 个候选路子，带 trade-off 和一个推荐——把 strawman 姿态用在设计高度上。当一个命名清晰的真分叉冒出来时，用本仓既有的裁决手段（`/codex` 第二意见 / eng-review）出证据支撑的判决，而不是把它当作业丢给用户。
- **先落地设计，再让用户读。** 经验证的设计写进 `design_docs/plans/`（gitignored 草稿，永不入版本控制）；值得永久保留的决策与形状，按 `adrs/AGENTS.md` 的约定晋升到 `adrs/` / `design_docs/`。用户在实现计划开始前先读这份书面设计——他在这道闸上的纠正，是你这辈子能拿到的最便宜的纠正。

## 红线与反模式（术）

- **反模式：理解之前就上方案。** 在没搞清真实痛点时就造那个字面请求——你把交付优化得很好，交付的却可能是个无关紧要的东西。
- **反模式：把用户提议的方案当成需求。** 他的方案是关于需求的线索，不是需求本身；锁死在它上面会堵掉更好的答案，还把他的猜测裹上你的权威发出去。
- **反模式：诱导证人。** 嵌着你假设的问题（"那你会想要这个是异步的吧？"）收割的是附和，不是信息——用户的礼貌会确认你种下的任何东西。
- **反模式：没有具体实例的抽象。** 如果你和用户都指不出一个该需求在疼的具体片段，你俩都在空想——你其实还没理解它。
- **红线：绝不把一个猜出来的需求当成已确认的来往下走。** 这就是「no-silent-failure」用在发现上：一个未经验证的解读被无声地往下游传，就是发现阶段版本的「吞掉异常」。如果你并不真的知道真实需求，就明明白白说出来、去挖——就像端点验收逼你诚实标注「闸绿 ≠ 真过」一样，这里也别让「我以为」冒充「我确认」。

## 移交（Hand-off）

当真实需求被说清、被用户对着一个具体实例确认、词汇也在稳定下来——发现就完成了它的活。从这里：

- **若需求落成「造 / 改一个 skill」** → `curating-skill-portfolios` 判要不要建 / 放哪 / 会不会重叠（带着你锻造出的词汇当输入），过了准入再 `cc-master-skillsmith` 写 body、`grounding-skill-evals` 度量。
- **若需求落成一次 feature / hook / 文档改动** → 走本仓正常实现流（按 `AGENTS.md` §4：`superpowers:test-driven-development` 主导 Red-Green-Refactor，卡住用 `superpowers:systematic-debugging` 或 `/investigate`）。
- **若竞争方案在对话里冒出来** → 用 `/codex` / eng-review 仲裁，别回头去重新litigate需求。
- **编排层面的事**（怎么把已批准的 goal 拆图、派发、驱动到完成）→ `orchestrating-to-completion`；其中 workflow 脚本怎么写 → `authoring-workflows`。

## 在 orchestrator 模式下

当你作为长 horizon master orchestrator 运行（如 cc-master 的 `as-master-orchestrator`），**直接**应用这个 skill：和用户的前台需求发现对话是**指挥自己的活，绝不外包**。它与后台执行**并行**——对话需要的侦察（reconnaissance）派个 sub-agent 去做，对话本身继续。设计闸映射到编排 board 上，就是一个 **user-blocked 决策节点**：批准是一条只有用户能解的异步依赖；它一可预见就立刻 surface，只有依赖这个答案的工作才等。

> 这一节只点边界，**不复述**编排的 how——「前台对话 ∥ 后台执行」的调度机制、async-HITL、p95 hedging 全在 `orchestrating-to-completion`（镜头 7 + `references/async-hitl.md`）。本 skill 管「挖什么需求、为什么」，那个 skill 管「怎么把对话当 async worker 调度」。