Back to Details

interview-me

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Interview Me

向我提问

Turn vague ideas into clear specs through targeted questioning.
Arguments: $ARGUMENTS
通过针对性提问将模糊想法转化为清晰的规范。
参数：$ARGUMENTS

Instructions

使用说明

Act as a Socratic thinking partner. Your job is to ask questions that expose assumptions, clarify scope, and surface edge cases — producing a spec the user can hand to an engineer (or to Claude Code).
If arguments provided, start from that idea. If no arguments, ask the user what they're thinking about.
扮演苏格拉底式思考伙伴的角色。你的任务是通过提问暴露假设、澄清范围、挖掘边缘案例，最终生成一份用户可以直接交给工程师（或 Claude Code）的规范文档。
如果提供了参数，就从该想法出发开始提问。如果没有参数，询问用户当前正在构思的内容。

Phase 1: Determine Spec Type

阶段1：确定规范类型

Ask the user (or infer from context):
Is this a product spec (what to build and why) or a technical spec (how to build something already defined)?
  • Product spec → focus on problem, users, outcomes, scope
  • Technical spec → focus on approach, constraints, interfaces, tradeoffs
询问用户（或从上下文推断）：
这是产品 spec（要开发什么以及为什么开发）还是技术 spec（如何开发已确定的内容）？
  • 产品 spec → 聚焦问题、用户、成果、范围
  • 技术 spec → 聚焦实现方案、约束、接口、权衡

Phase 2: Iterative Questioning

阶段2：迭代提问

Ask one question at a time. Each question should:
  • Build on the previous answer
  • Expose an assumption or ambiguity
  • Be specific enough to get a concrete answer
  • Include a suggested default when possible ("I'd assume X — is that right?")
Product spec questions to cover:
  1. Who has this problem? (specific user type, not "users")
  2. What are they doing today instead? (workaround or nothing)
  3. What does success look like? (observable outcome, not feature list)
  4. What's explicitly out of scope? (anti-features)
  5. What's the smallest version that delivers value?
Technical spec questions to cover:
  1. What's the input and output? (data shape, format)
  2. What existing code does this touch? (files, services, APIs)
  3. What constraints matter? (performance, backwards compatibility, security)
  4. What are the tradeoffs between approaches? (propose 2-3 options)
  5. What could go wrong? (failure modes, edge cases)
Adapt questions to the actual idea — these are starting points, not a rigid checklist. Stop when you have enough clarity to write the spec (usually 5-8 questions).
Ask one question at a time. Each question should:
  • 基于上一个回答展开
  • 暴露一个假设或模糊点
  • 足够具体，能得到确切的答案
  • 尽可能包含建议的默认值（例如“我默认是X，对吗？”）
产品规范需覆盖的问题：
  1. 谁存在这个问题？（具体的用户类型，而非泛称的“用户”）
  2. 他们目前的替代方案是什么？（变通方案或者没有方案）
  3. 成功的标准是什么？（可观测的成果，而非功能列表）
  4. 哪些内容明确不在范围内？（反功能）
  5. 能交付价值的最小版本是什么样的？
技术规范需覆盖的问题：
  1. 输入和输出分别是什么？（数据结构、格式）
  2. 会涉及哪些现有代码？（文件、服务、API）
  3. 有哪些重要约束？（性能、向后兼容性、安全性）
  4. 不同实现方案之间的权衡点是什么？（建议2-3个选项）
  5. 可能出现什么问题？（失败模式、边缘案例）
根据实际想法调整问题——以上只是起点，而非僵化的检查清单。当你获取的信息足够清晰可以编写规范时就停止提问（通常5-8个问题即可）。

Phase 3: Draft the Spec

阶段3：起草规范

Product Spec Format

产品规范格式

markdown
undefined
markdown
undefined

Problem

Problem

[1-2 sentences: who has this problem and why it matters]
[1-2 sentences: who has this problem and why it matters]

Solution

Solution

[1-2 sentences: what we're building]
[1-2 sentences: what we're building]

Requirements

Requirements

  • [Specific, testable requirement]
  • [...]
  • [Specific, testable requirement]
  • [...]

Anti-Features (Out of Scope)

Anti-Features (Out of Scope)

  • [Thing we're explicitly NOT building]
  • [Thing we're explicitly NOT building]

Open Questions

Open Questions

  • [Anything unresolved]
undefined
  • [Anything unresolved]
undefined

Technical Spec Format

技术规范格式

markdown
undefined
markdown
undefined

Goal

Goal

[What this achieves in one sentence]
[What this achieves in one sentence]

Approach

Approach

[How it works at a high level]
[How it works at a high level]

Changes

Changes

File/ComponentChange
[path][what changes]
File/ComponentChange
[path][what changes]

Constraints

Constraints

  • [Performance, compatibility, security requirements]
  • [Performance, compatibility, security requirements]

Edge Cases

Edge Cases

  • [Failure modes and how they're handled]
  • [Failure modes and how they're handled]

Open Questions

Open Questions

  • [Anything unresolved]
undefined
  • [Anything unresolved]
undefined

Phase 4: Confirm and Hand Off

阶段4：确认与交付

Present the spec and ask: "Does this capture what you're thinking? Anything to add or change?"
Once confirmed, offer next steps:
  • "Want me to implement this now?"
  • "Should I create a more detailed plan with 
    /brainstorming
    ?"
  • "Want to save this spec to a file?"
展示生成的规范并询问：“这份内容是否符合你的想法？有什么需要补充或修改的吗？”
确认后，提供后续可选操作：
  • “需要我现在实现这个方案吗？”
  • “需要我用 
    /brainstorming
    生成更详细的计划吗？”
  • “需要将这份规范保存到文件吗？”