| name | interview-me |
| description | One-question-at-a-time interview that extracts what the user actually wants. Use when requirements are vague, the ask is underspecified. |
Interview Me
Overview
YC 风格的需求访谈：一次只问一个问题，逐层深入，直到你对用户真正想要的东西有 90% 以上的把握。用户很少在第一次提问时说出真实需求 — 他们说的通常是"我以为他们想要的东西"或"最容易表达的东西"。通过结构化提问，剥离表层，找到核心。
When to Use
- 需求模糊、描述笼统（"帮我做个网站"、"优化一下性能"）
- 用户请求是一个方向而不是具体功能
- 用户说"你看着办"或"随便"
- 信息不足以支撑 spec-driven-development 的 PRD 编写
- NOT for 紧急问题（hotfix、生产故障）
- NOT for 已经明确具体规格的任务
Core Process
1. 设置预期
告诉用户你会通过几个问题来理解需求，每次只问一个问题。
2. 逐层提问
按照以下顺序（一次只问一个，得到答案后再问下一个）：
第一层：问题定义
第二层：用户与受众
- "谁是目标用户？"
- "谁会使用这个？他们的技术背景如何？"
第三层：成功标准
- "做成什么样就算成功了？"
- "你怎么判断这个方案是好的？"
第四层：最小版本
- "最小可用版本是什么样的？"
- "哪些功能可以砍掉？"
第五层：约束与边界
- "有什么技术或时间限制？"
- "有没有不能碰的东西？"
3. 检验理解
在获得足够信息后，用自己的话复述需求："让我确认一下，你想要的是……对吗？"
4. 判断信心
自我评估：我对需求的理解是否达到 90% 以上？
- 如果 < 90%，继续提问
- 如果 >= 90%，进入下一阶段（spec-driven-development 或直接执行）
Common Rationalizations
| Rationalization | Reality |
|---|
| "问题太多会让用户烦躁" | 一个一个问题问不会，一连串问题轰炸才会。 |
| "我大概知道他要什么了" | "大概" = 不够。90% 以下意味着还有重要信息没挖出来。 |
| "先做一版出来再让用户反馈" | 这是最昂贵的信息获取方式。问清楚只需 5 分钟。 |
| "用户是大忙人，不想浪费时间" | 浪费用户时间的是做出来的东西不对，而不是多问了三个问题。 |
| "用户说了方案，直接照着做就行" | 用户说的方案是他以为的解决方案，未必是真需求。 |
Red Flags
- 用户回答过快或过于笼统（可能是敷衍或没认真思考）
- 用户主动回避具体问题（"先做起来再说"）
- 用户自己也在使用模糊词汇（"差不多"、"大概那样"）
- 连续问了 3 个问题后信息仍然不明确
- 用户给出了解决方案而不是描述问题
- 你觉得"差不多了"但无法清晰复述需求
Verification
