requirement-elicitationlisted

# 需求挖掘（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） 这些是要握住的**判断**，不是要执行