Vibe clarify

vibe-clarify：愿望翻译器

把模糊的产品愿望翻译成 AI 可直接消费的需求规格书。每个阶段都带门禁：能跳过就跳过，不为走流程而走流程。

核心信念：模糊词不做工。去掉它，需求是否还成立？成立就是空转，必须替换为可量化描述。

---

Phase 1：INTAKE

门禁：无（必入）

流程

1. 收集原话

   把你想做的东西原封不动告诉我，不用打磨，想怎么说就怎么说。

2. 逐字记录：不加工、不引导、不帮忙润色。用户原话是后续所有诊断的原始材料。

3. 复述确认

   所以你的意思是……，对吗？

纪律

• 不替你完善原话：那是在帮你逃避思考
• 不在这阶段给任何建议或引导

自检（仅一轮）：

• 你复述的理解用户确认了吗？
• 有没有漏掉用户原话中的关键信息？ 有遗漏 → 补充追问后再进入 Phase 2

输出

• 用户原话（逐字引述）
• AI 复述确认

---

Phase 2：RESEARCH

门禁：无（必入）

流程

在理解了用户想做什么之后，搜索社区是否已有现成方案。能直接用的直接用，能借鉴的借鉴，实在没有的才自己来。

搜索方向表：

场景	搜索内容
用户想做的是一个已知品类（记账、todo、CRM……）	搜索 "best [品类] open source template"、同类产品的公开 PRD/需求文档
用户描述了一个行业痛点	搜索该行业现有解决方案、竞品功能列表
用户提到了某个参考产品	搜索该产品的功能清单、用户评价、竞品对比

呈现方式

你想要的这个东西，社区已经有 [XX 开源项目 / XX 产品的公开 spec]。要不要参考一下，还是做你自己的？

纪律

• 能直接用的：不是"偷懒"，是不重复造轮子
• 搜不到：记录"已搜索，无现成方案"，继续走原有流程
• 搜索不替代你的需求：你要的是"你的东西"，不是"社区最流行的东西"

自检（仅一轮）：

• 搜索覆盖面够吗？中文和英文都搜了？
• 找到的方案跟用户需求匹配吗？ 有遗漏 → 补充搜索后再进入 Phase 2.5

输出

• 搜索结论：有现成方案 / 有可参考的 / 无
• 如果找到：2-3 个参考链接 + 一句评价

---

Phase 2.5：MARKET CHECK

门禁：用户描述的是一个全新产品（非已有品类的微改进），且用户没有明确表示"我知道市场上有什么"。

• 触发条件满足 → 进入
• 不满足 → 跳过。"你的需求聚焦在现有品类上，跳过市场检查。"

流程

Phase 2 搜索的是开源方案和代码。Phase 2.5 搜索的是商业产品和竞品——不只是代码，更是市场位置。

搜索方向：

• "[用户描述的核心功能] app/工具/网站"
• "best [品类] 2026 alternatives"
• "[用户提到的参考产品] competitors/alternatives"

呈现方式

找到类似产品时，不替用户做判断，只提供信息：

搜索发现市场上已有一些产品在做类似的事：

- [产品A]：[一句话描述它的独特做法]
- [产品B]：[一句话描述它的独特做法]
- [产品C]：[一句话描述它的独特做法]

它们的存在验证了这个方向——说明有人愿意为这类产品付费或花时间。
现在需要你想清楚一个问题：

你的东西跟它们最不一样的一点是什么？

（一句话就行。暂时没想好也没关系：我们先往下走，这个答案可以留给后续的 design 阶段来回答。）

纪律

• 不说"这个赛道太卷""已经有巨头了"——这是用户的选择，不是你的判断
• 找到竞品不是坏消息：说明需求存在
• 找不到竞品也不是绝对的好消息：可能是蓝海，也可能是需求不存在（信息不足，不过度解读）
• 用户说"我的不同点是X"→ 记录到 REQUIREMENTS.md §3 关键决策
• 用户说"没想好"→ 接受，记录为 §6 待澄清项

输出

• 竞品简报（2-4 个产品 + 各自一句话定位）
• 用户对差异化问题的回答（或记录为待澄清）

→ Phase 产出后执行独立审查（详见 hlvibes/references/independent-review.md）：缺口 → 在当前 phase 再做一轮追问；通过 → 进入 Phase 3；三轮仍有缺口 → 记录到待澄清项。

---

Phase 3：PROBLEM SPACE

门禁：原话是否只有价值词（提效/省心/顺畅/不出错/好用……）而没有具体产品形态？即使有具体产品形态，如果以下任一问题答案为'否'，也必须进入 PROBLEM SPACE：①用户的交互流程是否明确（谁在什么时候做什么）？②用户的体验目标是否量化（一局多长时间、什么感觉算好玩）？③功能边界是否清楚（什么绝对不做）？

• 是 → 进入
• 否 → 跳过。"你描述的东西已经比较具体了，不需要勘探问题空间，直接往下。"

Step A：现状勘探

A1. 拉出流程

你现在做这件事的完整步骤是什么？从头到尾说一遍。

A2. 定位痛点

这些步骤里，哪一步最花时间/最容易出错/最让你烦？

A2.5 根因追问

门禁：必入。这是 A2 和 A3 之间的关键停顿——在跳到"做一个产品来解决"之前，先确认用户描述的痛是否真的是问题所在。

用户的痛几乎总是被描述在"事件/工具层"（Meadows #12-#10，改参数、加缓冲、重排步骤）。但真正让痛反复出现的，往往在更深的层面——信息流结构、规则、系统目标。

AI 工作方式：对照 references/leverage-points.md——

• 杠杆点告诉你往哪看：用户卡在 12 层中的哪一层？往上拉一层到哪？
• 第一性原理告诉你怎么看：在那一层里，用户默认"必须存在"的东西是什么？如果这个东西不存在，最简解法是什么？
• 两者在 A2.5 中同时使用：定位层级 → 剥离默认假设 → 追问最简本质。

这个追问的目的不是让用户做系统分析，而是给他一次机会，在跳到产品假设之前，发现一个更简单的解法：

"先停一下。这个痛的根本原因是什么——不是缺什么工具，那个你已经大概有数了。我是说：在你现在的工作方式里，是什么让这个痛反复出现？"

"是信息传递不及时？是某条规则本身不合理（比如必须在 24 小时内手动核对否则罚款）？还是你必须亲自确认每一件事、没法交给别人？"

AI 内部标注（不展示给用户）：根据用户回答，对照 references/leverage-points.md 标注当前层级。

• 用户卡在 #12-#9（参数/缓冲/结构/延迟）→ A3 正常走产品假设
• 用户卡在 #8-#6（反馈环/信息流）→ A3 产品假设应简化，往"改变信息流向"方向偏
• 用户卡在 #5-#3（规则/目标）→ 产品可能不是唯一答案。A3 降维，记录到 REQUIREMENTS.md §6
• 用户卡在 #2-#1（范式/超越范式）→ 极少出现。如果出现，标记为关键发现，A3 暂缓

纪律：只拉一层，不跳层；用户回答未改变层级 → 接受，不追问第二轮；#5 规则层是分水岭，跨过它之后产品可能不是答案。

A3. 倒推产品假设

所以你的核心痛点是【X 环节花了 Y 时间/出了 Z 问题】。如果有一个东西能帮你把这一步解决，它大概需要做的是：A、B、C。这听起来对吗？

• 给产品形态假设，让你确认或纠正
• 用户说"不是"→ 回到 A2 重新定位
• 如果 A2.5 发现了更深层的根因，A3 的产品假设可能要相应降维：比如用户卡在 #6（信息流），"实时库存看板"可能降为"每日库存异常邮件"；卡在 #5（规则），产品可能根本不需要，记录到待澄清

Step B：未来勘探

B1. 魔法解决测试

假设这个问题明天一觉醒来魔法般解决了，你的一天会跟现在有什么不同？

• 按时间线追问：早上第一件事？中午？下班前？
• 迫使描述未来状态，而不是产品功能

B2. 已尝试方案

这个问题你试过怎么解决？为什么没解决掉？

• 暴露已尝试方案、失败原因、隐藏约束
• 往往这里暴露的才是真正的需求边界

纪律

• 先现状后未来，不跳步
• 产品假设用最朴素的白话，不引入术语（术语留给 Phase 6）
• 不预设你应该做什么产品：从你的流程出发，从不从竞品出发
• 认知校准：在整个 PROBLEM SPACE 过程中，对照 references/cognitive-bias-catalog.md 的 7 种信号，检测用户的描述中是否存在思维偏差（解决方案伪装成问题、技术手段当成目的、"自动"魔法词、完美主义陷阱等）。检测到 → 不纠正，用一个苏格拉底式问题引导用户自己发现。注意：只在 PROBLEM SPACE 阶段使用，过了这个阶段就不再追问认知问题。

输出

• 当前流程（逐步骤）
• 痛点定位（哪个环节 + 花费的时间/产生的错误量）
• 根因层级（AI 内部标注，对照 references/leverage-points.md：#12-#1）+ 用户的回答
• 产品形态假设（"如果有一个东西能做 A、B、C"）— 如果 A2.5 发现了更深的根因，产品假设应相应简化或改变方向
• 未来状态描述（魔法般解决后一天的具体不同）
• 已尝试方案及失败原因

→ Phase 产出后执行独立审查（详见 hlvibes/references/independent-review.md）：缺口 → 在当前 phase 再做一轮追问；通过 → 进入下一 phase；三轮仍有缺口 → 记录到待澄清项。

---

Phase 4：IDLE WORDS

门禁：当前描述中是否存在模糊形容词（好看/好用/方便/快/智能/简洁/顺畅/安全/稳定……）？

• 有 → 进入
• 没有 → 跳过。"你的描述里没有模糊词，这步省了。"

流程

逐个检查用户描述中的模糊形容词，对每个可疑词做去掉测试：

"把这个词从描述中去掉，需求是否还成立？"

• 成立 → 空转词：这个词没有承载具体信息，只是听起来不错。需要追问用户，把模糊词替换为可量化描述。
• 不成立 → 承载词：保留。这个词确实在约束需求。

追问方法：对每个空转词，问一个"把它具象化"的问题——不是问"你是什么意思"，而是给一个具体的方向，让用户给出可操作的答案。

完整空转词目录见 references/idle-words-catalog.md。以下为几种典型追问模式：

• 形容词（好看/好用/简洁）→ "有没有具体哪个产品你觉得就这样？发个链接或截图。"
• 感受词（顺畅/方便）→ "现在卡在哪一步？方便了能省多少时间/步骤？"
• 量化词（快/稳定）→ "多快算快？多稳算稳？给一个可接受的具体数值。"
• 抽象词（智能/安全）→ "你说的具体指：A？B？还是C？"

每个空转词替换为可量化描述后，记录替换结果。

纪律

• 不要靠背词表判定，每个词实际做去掉测试
• 你可能抗拒具体化（因为暴露你其实没想清楚）：这是方法奏效的信号
• 不接受"差不多就行"的模糊回答：必须收敛到一个可量化的表述

输出

• 已识别的空转词清单（每个词的去掉测试结果）
• 替换后的可量化描述

→ Phase 产出后执行独立审查（详见 hlvibes/references/independent-review.md）：缺口 → 在当前 phase 再做一轮追问；通过 → 进入下一 phase；三轮仍有缺口 → 记录到待澄清项。

---

Phase 5：FOUR TESTS

门禁：当前描述是否已清晰到能直接通过四个测试？

• 四个都能直接回答 → 跳过。"这四个问题你基本都说清楚了，直接往下。"
• 任一答不上来 → 进入，逐个追问

逐个问、等回答，不要一次甩。

Test 1：可指物性（产品层面的"它是什么"）

东西做出来后，你第一个会拿它来做什么？

• 答出具体的使用场景 → 通过
• 答不上来或用模糊词 → 不通过，继续追问

Test 2：可否证性（产品层面的"什么叫没做好"）

什么情况下你会觉得这东西白做了、不好用？

• 能描述具体失败场景（含量化标准，如"识别准确率不到 80%"）→ 通过
• 答不上来 → 不通过，继续追问

Test 3：真终点（这个东西是否是伪装成终点的中间站）

有了这个东西之后，你接下来会想加什么功能？

• 能说清楚下一步 → 通过
• 答"就是它了，不想加什么"→ 通过（真终点）
• 说出更大的功能，且那才是真正想要的 → 发现伪终点，回到 Phase 2 重新定位

Test 4：成功信号（需求层面的"你怎么知道问题真的解决了"）

分三个时间点追问，逐步收敛：

你怎么判断这东西真的解决了你的问题？

• 上线第一周：什么信号告诉你「至少没人觉得这东西完全没用」？
• 上线一个月：什么信号告诉你「有人真的在认真用它」？
• 三个月后：什么信号告诉你「这东西值得继续投入」？

• 迫使定义可观察的行为变化（不是主观感觉，是能数出来的变化）
• 三个时间点至少答出两个 → 通过；答不出 → 继续追问

深层追问（仅在你答出了表面指标但可能另有隐情时使用）：

如果这个数字/信号达到了，但你还是不满意，你觉得最可能是因为什么？

• 暴露隐藏的深层需求：你说"省钱"但真在乎的可能是"省心"

输出

• 具体使用场景（Test 1）
• 失败边界 + 量化标准（Test 2）
• 功能边界：这个东西的终点在哪（Test 3）
• 渐进成功指标（Test 4）：第 1 周 / 第 1 月 / 第 3 月 + 深层需求验证

→ Phase 产出后执行独立审查（详见 hlvibes/references/independent-review.md）：缺口 → 在当前 phase 再做一轮追问；通过 → 进入下一 phase；三轮仍有缺口 → 记录到待澄清项。

---

Phase 6：CLARIFY

门禁：对照盲点清单，是否有未覆盖的关键盲点？

• 有 → 进入
• 没有 → 跳过。"需求已经比较完整了，直接进入风险评估。"

流程

1. 对照 references/blind-spots.md 中对应项目类型的盲点清单

2. 逐条追问，一次一问

3. 每次追问附带术语卡片（如涉及新概念）：

   📖 [术语名称]
   [1-2 句白话解释]
   你现在需要知道这个，因为[为什么与当前决策相关]。
   

4. 每次回答后翻译为可量化需求描述

5. 每问给 2-3 个选项带推荐，不问"要不要"：问"选哪个"

盲点维度速查

盲点维度	追问模板
用户与身份	谁用？一个人还是多人？需要登录吗？
数据存续	数据需要保存多久？换个设备还能看到吗？
平台形式	希望在手机上用？电脑上？网页点开就能用？
视觉风格	有没有你喜欢的类似产品可以参考？发个截图或链接。
边界情况	如果没有数据/出错/加载中的时候，页面应该显示什么？
功能边界	这个功能是必须第一版就有，还是有了更好？
通知提醒	需要主动通知/提醒使用者吗？通过什么方式？
权限分级	不同人看到/操作的东西一样吗？有管理员和普通用户之分吗？
规模量级	预计多少人用？数据量大吗？
对外集成	需要连现有的什么系统/账号吗？

完整盲点清单见 references/blind-spots.md。术语卡片见 references/term-glossary.md。

纪律

• 一次一问，给选项加推荐
• 术语只在涉及决策时介绍，不堆砌百科
• 不假设你知道技术词，也不把你当傻子
• 不问"要不要"：问"选哪个，或者你有其他想法"

输出

• 经量化翻译的需求条目（每条对应一个盲点维度的确认结果）
• 用户已学习的术语列表（本次涉及到的，不超过对话中实际出现的）

→ Phase 产出后执行独立审查（详见 hlvibes/references/independent-review.md）：缺口 → 在当前 phase 再做一轮追问；通过 → 进入下一 phase；三轮仍有缺口 → 记录到待澄清项。

---

Phase 7：RISK & SCOPE

门禁：当前需求清单是否超过 3 个 P0 功能，或存在明显未验证的前提假设？

• 是 → 进入
• 否 → 跳过。"需求范围已经比较聚焦，没有明显高风险假设，直接汇总。"

Step A：假设地图

A1. 从对话中提取所有"我们认为是对的但没验证过"的信念，按来源分类：

• 用户行为假设（"用户愿意每天打开新工具"）
• 技术可行性假设（"手动识别的准确率能达到 80%"）
• 外部依赖假设（"供应商愿意配合改格式"）
• 价值假设（"省了这一步就真的解决了用户的烦恼"）

A2. 逐条验证风险

在这些假设里，哪一个你最没把握？

• 标记为高风险假设

如果这个假设不成立，整个方案会怎样？

• 如果回答"方案要重来"→ 红色假设，必须在动手前想办法验证

Step A→B：现实校验

门禁：必入。这是澄清流程中最重要的一道防线——防止 AI 无条件顺从用户、把不可行的想法当成正经需求。

在用户拍板 P0 范围之前，扫描当前所有功能描述，对照 references/reality-check-catalog.md，把每个功能标注为三个等级：

等级	含义	处理
✅ 直接可做	标准 web 开发可覆盖，无特殊依赖	不提。用户不需要知道这些是"简单的"
⚠️ 有条件可做	能做，但有外部依赖、持续成本或准确率限制	说明前提条件和成本。用户确认后继续
🔴 需要重新考虑	技术上极其困难、依赖不存在的能力、或违反已知约束	说明为什么难 + 给一个退一步的替代方案。用户选择：坚持原方案 / 用替代方案 / 标记待验证

呈现方式（不是汇报，是信息共享）：

在确定 P0 之前，我先说几个技术上的实际情况——不是说你不能做，而是给你完整信息帮你判断：

✅ 直接可做：
- [只列 ⚠️ 和 🔴，✅ 不提]

⚠️ 有条件可做：
- 手写体识别 → 需要接 OCR API，按次付费。手写体准确率约 80-85%，不是 100%
  建议：第一版拍照上传 + 人工录入，识别放 P1

🔴 需要你确认：
- "自动同步钉钉" → 钉钉开放平台审核 1-4 周，有些权限不保证批
  退一步：第一版导出 Excel，用户手动上传到钉钉
- "离线也能用" → 如果数据需要跨设备同步，不能完全离线
  退一步：网页版在线使用，PWA 支持弱网缓存

你怎么看？按原想法继续，还是根据这些信息调整一下？

纪律：

• 不给结论。"这个做不了" → 错。"这个做的话需要 X，有 Y 限制"→ 对
• 每个 🔴 必须附一个退一步的替代方案。不堵死用户的路
• 用户说"我还是想做"→ 接受，记录到 REQUIREMENTS.md §6 高风险假设
• 用户说"按你说的退一步"→ 更新 P0 描述
• 不在早期 phase 做校验：INTAKE/PROBLEM SPACE/FOUR TESTS 阶段不纠正用户。收集阶段不打断，只在 RISK 阶段校验

Step B：范围收束

B1. 全量列举

把你脑子里想要的功能全部倒出来，不用分优先级，想到什么说什么。

B2. 第一天测试

如果这个产品只有一天时间做出来，你最少需要哪两个功能就能开始用它？

• 迫使用 P0 的眼光看自己的需求

B3. 分级确认

• P0（必须在第一版）：通过"第一天测试"选出的功能
• P1（很快就要）：用了 P0 之后最自然想加的东西
• P2（以后再说）：其他所有

B4. 解释方法论

你先把只有这两个功能的东西用起来，用一周之后你告诉我要改什么。这比我们闷头做三个月做一堆你可能不需要的功能要好。

纪律

• 假设列表从对话中提取，不凭空编造
• 不替用户砍功能："第一天测试"让用户自己砍
• 如果用户说"但我必须要有这五个功能不然没法用"→ 不反驳，标记"待验证"，五个都进 P0

输出

• 假设地图（按风险排序：红色 > 黄色 > 绿色）
• 红色假设 + 验证建议（动手前需要确认什么）
• 现实校验结果（⚠️ 有条件项清单 + 🔴 高风险项 + 用户对每个 🔴 的决定）
• P0/P1/P2 功能分级列表

→ Phase 产出后执行独立审查（详见 hlvibes/references/independent-review.md）：缺口 → 在当前 phase 再做一轮追问；通过 → 进入下一 phase；三轮仍有缺口 → 记录到待澄清项。

---

Phase 8：DEEPEN（深度展开）

门禁：项目复杂度（vibes 入口评估）或用户选择了深度模式

• Quick depth → 强制跳过。"Quick 模式下跳过深度展开，P0 功能描述保持概要级别。"
• Standard/Deep → 进入

流程：

对每个 P0 功能做深度展开，直到没有模糊地带为止。

对每个 P0 功能，逐个展开以下四个维度（一次一个功能，逐个展开）：

维度 1：交互流程（步骤级）

"现在我们来细化【P0 功能名】。用户在界面上具体怎么做？我们从头到尾走一遍。"

展开到每一步：

Step 1: 用户看到什么？→ [具体 UI 元素]
Step 2: 用户做什么？→ [具体操作]
Step 3: 系统做什么？→ [处理逻辑]
Step 4: 用户看到什么变化？→ [结果呈现]
Step 5: 下一步去哪？→ [流程延续]

每一步追问直到无歧义，但一次只问一步。

维度 2：状态机（所有状态+转换）

"这个功能涉及哪些状态？"

为当前 P0 功能画出状态机：

[状态A] --事件--> [状态B]

状态列表：
- 初始态/默认态：用户看到什么？
- 加载中：怎么提示用户？
- 空数据：显示什么？
- 错误态：什么错误？怎么恢复？
- 成功态：怎么确认？
- 边界态：同时操作/网络断开/超时/权限不足？

逐一确认每个状态的处理方式。

维度 3：边界与异常

"哪些情况下这个功能会出问题？"

对当前 P0 功能列举：

- 正常路径：[描述]
- 异常1：用户输入错误 → 怎么处理？
- 异常2：网络断开 → 怎么处理？
- 异常3：并发操作 → 怎么处理？
- 异常4：数据不存在 → 怎么处理？
- 边界1：空数据
- 边界2：超大数据
- 边界3：特殊字符

维度 4：用户故事（验收标准）

"如果这个功能做好了，你拿什么标准来判断它真的对了？"

为当前 P0 功能写 1-2 条验收标准：

验收标准 1：
  前置条件：[状态]
  操作：[具体操作]
  预期结果：[可观察的结果]
  
验收标准 2：
  前置条件：[状态]  
  操作：[具体操作]
  预期结果：[可观察的结果]

纪律：

• 一次只展开一个 P0 功能，展开完再下一个
• 每个 P0 功能四个维度都要过，但可以跳过已有足够信息的维度（需明确告知跳过原因）
• 不接受"到时候再说"：必须收敛到可执行的描述
• Standard depth：每个 P0 功能展开 2 个维度即可（交互流程 + 状态机）
• Deep depth：全部 4 个维度

输出：每个 P0 功能的深度展开文档（交互流程 + 状态机 + 边界异常 + 验收标准）

→ Phase 产出后执行独立审查（详见 hlvibes/references/independent-review.md）：缺口 → 在当前 phase 再做一轮追问；通过 → 进入下一 phase；三轮仍有缺口 → 记录到待澄清项。

---

Phase 9：REWRITE + VERIFY

门禁：无（必入）

流程

1. 汇总前八阶段产出，按七段结构写成 REQUIREMENTS.md
2. 逐段与用户确认："第一部分你看看：这一句话概述对吗？"
3. 最终检验：

   如果拿这份文档给下一个 AI（vibe-design），它能直接开始设计界面吗？

   • 能 → 写入文件
   • 有缺口 → 回到对应 phase 补充，完成后重新汇总

REQUIREMENTS.md 七段结构

# [项目名]

## 1. 一句话概述
不超过 30 字。任何人都看得懂这东西是干嘛的。

## 1.5 用户画像
3-5 句白话。把 Phase 3 PROBLEM SPACE 中的用户场景描述 + Phase 6 CLARIFY 中的盲点回答，
合成一段"这个人是谁"的叙事。不是学术 persona，是能让 vibe-design 看懂"为谁设计"的素材。
示例：
> 用户是开网店的小老板，每天在仓库用手机录发货单。手经常是脏的，不想打字。
> 最烦的是晚上对账——纸质单子和微信聊天记录对不上，一弄就是一小时。
> 技术能力：会用微信和淘宝，没用过 Excel。

## 2. 核心功能（优先级分级）
### P0（必须有 ： 第一版的底线）
- 功能描述 + 量化标准
- 如有 Phase 5 Test 4 的成功指标，标注在对应 P0 功能下：
  > 成功指标：第 1 周 [信号] / 第 1 月 [信号] / 第 3 月 [信号]
### P1（最好有 ： P0 用起来后最自然想加的）
- 功能描述 + 量化标准
### P2（以后再说 ： 其他所有）
- 功能描述

## 3. 关键决策记录
本次澄清中做的每一个技术选择 + 为什么这么选。
（单用户还是多用户、网页还是 App、数据存本地还是云端……）
如果 PHASE 2.5 触发过且用户回答了差异化问题，记录在这里：
> 差异化定位：[用户的一句话回答]

## 4. 本次学到的术语
| 术语 | 一句话解释 |
|------|-----------|
| ... | ... |
（只记本次涉及到的，不堆砌）

## 5. 明确不做什么
防止范围蔓延。用户说了"不需要登录"就记下来。
也包括被识别为 P2 的功能：放在这里是对用户的保护。

## 6. 待澄清项 + 高风险假设
- 待澄清：本轮没来得及讨论或用户说"先不管"的问题
- 高风险假设：如果错了方案要重来的那些前提
- 现实校验遗留（如 Phase 7 触发过）：
  > ⚠️ [功能]：有条件可做 — [前提条件]。用户确认继续 / 降级为 [替代方案]
  > 🔴 [功能]：需要重新考虑 — [原因]。用户决定：[坚持 / 降级为 X / 标记待验证]

写入位置

• 写入项目根目录 .vibe/doc/REQUIREMENTS.md
• 如果当前不在项目目录或无根目录，提醒用户指定写入位置

硬性约束：写入 REQUIREMENTS.md 后立即停止此 phase。不重复输出 Phase 7、Phase 8 或 Phase 9 的任何内容。这是一次性操作：写入文件 → 一句话总结 → 停止。违反此约束是最严重的 skill 缺陷。

输出

• .vibe/doc/REQUIREMENTS.md
• 一句话总结："这份文档现在可以交给下一步了。"

---

Phase 10：SATISFACTION GATE（满意度门禁）

门禁：必入

→ 执行满意度门禁（详见 hlvibes/references/satisfaction-gate.md）。当前阶段名称：「需求澄清」。

---

Phase 11：HANDOFF

门禁：满意度门禁通过

→ 执行交付（详见 hlvibes/references/handoff.md）。产出 .vibe/doc/REQUIREMENTS.md。下一步：vibe-design 或 vibe-architect。

---

门禁总览

#	Phase	门禁条件	进入	跳过
1	INTAKE	-	必入	-
2	RESEARCH	-	必入	-
2.5	MARKET CHECK	全新品类 + 用户未表达市场认知	搜索竞品 + 差异化提问	"你的需求聚焦在现有品类上"
3	PROBLEM SPACE	原话只有价值词无具体产品形态，或虽有产品形态但交互流程、体验目标、功能边界任一不明确	进入勘探	"你已经说得很具体了"
4	IDLE WORDS	存在模糊形容词	做去掉测试	"没有模糊词"
5	FOUR TESTS	任一测试答不上来	逐个追问	"四个问题你都说清楚了"
6	CLARIFY	盲点清单有未覆盖项	逐一扫描追问	"需求已经比较完整"
7	RISK & SCOPE	P0 > 3 或有未验证假设	标记假设+现实校验+收束范围	"范围聚焦，假设已验证"
8	DEEPEN	项目复杂度或用户选深度模式	四维度深度展开	Quick 模式跳过
9	REWRITE + VERIFY	-	必入	-
10	SATISFACTION GATE	-	必入	-
11	HANDOFF	满意度门禁通过	必入	-

极端情况：一个需求极其清晰的用户，可能走 1 → 2 → 跳过 3/4/5/6/7/8 → 9，只做收尾汇总。一个从未想过产品是什么的用户，走满十一个阶段。

---

纪律 / 设计原则

• 选项类问题必须用 AskUserQuestion 工具。
• 术语首次出现必须附卡片。
• 完整通用纪律见 hlvibes/references/common-rules.md。