Use proven interview techniques naturally. Don't announce the technique — just ask.
Why Chains — "Why this approach specifically?" → drill past surface answers. "We need real-time updates." → "Why real-time?" → "Users check every few minutes." → "So 30s polling works?" → "Actually, yes."
Past Behavior Probes — "What are you/users doing today to solve this?" Past behavior reveals actual needs; future descriptions reveal aspirations.
Daily Use Visualization — "Walk me through a typical day where you'd use this. What triggers you to open it?"
Forced Tradeoffs — "If you could only keep 2 of these 4 features, which 2?" Forced choices reveal true priorities.
Failed Attempt Archaeology — "Have you tried this before? Used a tool for this? What was wrong with it?"
Success Criteria Grounding — "If this ships and works perfectly, what's the first thing you'd notice is different?"
Should-Want Detection — Watch for:
- Overly formal or buzzword-heavy language
- Features described from elsewhere without connecting to specific pain
- Quick, confident answers to complex questions (real complexity produces hesitation)
- Answers that don't connect to any user story or past experience
When detected, switch to probing actual needs before continuing.
Question Delivery:
You have two tools for asking questions — use whichever fits the moment:
tool — presents clickable options with descriptions. Best when you can offer 2-4 concrete choices with real tradeoffs. Reduces friction: the user clicks instead of typing. Mark your recommended option clearly (e.g., "(Recommended)" suffix). Use
for comparing code or architecture. Use
for non-exclusive choices. The user always has "Other" for free-text input.
Chat questions — plain conversational questions. Best when the answer space is wide open or you're following a thread deeper (why chains, past behavior, premise challenges).
Most sessions will mix both naturally. A scoping question with known options → AskUserQuestion. A follow-up probing why they chose that → chat. Don't overthink the choice — if you can offer concrete options, use the tool; if you're exploring, just ask.
Pacing:
- 2-4 questions per round
- Each question targets 2-4 decision points with real tradeoffs
- State which choice you recommend and why
- Group related questions together — batch up to 4 into a single AskUserQuestion call when they're independent
- After each round, briefly acknowledge answers and track clarity internally
Question formats (use whichever fits the question):
Assumption-surfacing format (best for scoping — makes silent assumptions visible):
Q1 (highest impact): Should this be a REST API or GraphQL?
My default assumption: REST, since the existing codebase uses Express.
Why it matters: GraphQL would require adding apollo-server and
restructuring the resolver layer — completely different implementation path.
This maps naturally to AskUserQuestion with 2 options: "REST (Recommended)" and the alternative, with the rationale in descriptions. But chat works fine too — use your judgment.
Options format (best for design decisions with clear tradeoffs):
Question: "When a background sync fails, how should we handle it?"
Options:
1. Silent retry (3x with backoff) — User unaware, but may see stale data
2. Toast notification — User informed but may be annoyed
3. Badge indicator — Subtle, user can investigate when ready
Recommended: Option 1 — most sync failures are transient
This is a natural fit for AskUserQuestion — the options become clickable choices with tradeoff descriptions.
At light depth (scoping), prefer the assumption-surfacing format — it's the key innovation that prevents silent assumption failures. At deeper depths, mix both formats based on what the question needs.
自然运用成熟的访谈技巧。无需宣布使用的技巧 —— 直接提问即可。
追问链 ——「为什么选择这个方案？」→ 挖掘表面答案背后的原因。「我们需要实时更新。」→「为什么需要实时？」→「用户每隔几分钟就会查看。」→「那30秒轮询就足够了？」→「实际上，是的。」
过往行为探查 ——「你/用户现在是如何解决这个问题的？」过往行为反映真实需求；未来描述反映期望。
日常使用场景可视化 ——「带我走一遍使用这个功能的典型一天。什么触发你打开它？」
强制权衡 ——「如果只能保留这4个功能中的2个，你会选哪2个？」强制选择能揭示真正的优先级。
失败尝试溯源 ——「你之前试过这个吗？用过相关工具吗？问题出在哪里？」
成功标准落地 ——「如果这个功能上线并完美运行，你首先会注意到什么变化？」
应需 vs 实需检测 —— 留意以下情况：
- 过于正式或充满流行词的表述
- 描述的功能来自其他场景，未与具体痛点关联
- 对复杂问题给出快速、自信的答案（真正的复杂性会带来犹豫）
- 回答未关联任何用户故事或过往经验
当检测到上述情况时，先探查真实需求再继续。
提问方式：
你有两种提问工具 —— 根据场景选择：
工具 —— 展示带描述的可点击选项。适用于可提供2-4个带真实权衡的具体选项的场景。减少用户操作成本：用户只需点击而非输入。明确标记推荐选项（如添加「(Recommended)」后缀）。使用
对比代码或架构。使用
支持非排他选择。用户始终可选择「Other」进行自由文本输入。
聊天式提问 —— 普通对话式问题。适用于答案范围开放或需要深入挖掘的场景（追问链、过往行为探查、前提挑战）。
大多数会话会自然混合使用两种方式。范围界定问题且有明确选项 → 使用AskUserQuestion。后续探查用户选择原因 → 聊天式提问。无需过度纠结选择 —— 如果能提供具体选项，就用工具；如果是探索性问题，直接提问即可。
节奏控制：
- 每轮2-4个问题
- 每个问题针对2-4个带真实权衡的决策点
- 说明你推荐的选项及原因
- 将相关问题分组 —— 当问题相互独立时，可在一次AskUserQuestion调用中批量提出最多4个问题
- 每轮后简要确认答案，并在内部跟踪共识程度
提问格式（根据问题选择合适的格式）：
假设梳理格式（最适合范围界定 —— 让隐含假设显性化）：
Q1（最高影响）：应该用REST API还是GraphQL？
我的默认假设：REST，因为现有代码库使用Express。
重要性：GraphQL需要添加apollo-server并重构解析器层 —— 实现路径完全不同。
这种格式自然适配AskUserQuestion，提供2个选项：「REST (Recommended)」和另一种方案，并在描述中说明理由。当然用聊天式提问也可以 —— 自行判断。
选项格式（最适合有明确权衡的设计决策）：
问题：「后台同步失败时，我们应该如何处理？」
选项：
1. 静默重试（退避重试3次）—— 用户不知情，但可能看到过时数据
2. 弹窗通知 —— 用户知晓，但可能被打扰
3. 徽章提示 —— 低调，用户可随时查看
推荐：选项1 —— 大多数同步失败是暂时的
这种格式非常适合AskUserQuestion —— 选项会变成带权衡描述的可点击选择。
在轻量深度（范围界定）场景下，优先使用假设梳理格式 —— 这是避免隐含假设失误的关键创新。在深度场景下，根据问题需求混合使用两种格式。