InterviewMe 需求追问

需求与表达之间的隐形鸿沟

工程师常遇到这样的场景：用户说"做个仪表盘"，但真正需要的可能只是几个关键指标；用户要求"让它更快"，却没有明确的性能目标。这种表层诉求与真实需求之间的偏差，往往在方案成型后才被发现——此时沉没成本已高，团队倾向将错误的功能合理化为"够用"。更隐蔽的是，当用户在"简单性"与"灵活性"、"成本"与"速度"等矛盾价值间未做取舍时，默认假设会悄悄替代真实意图。

逐题追问：在动手前关闭认知偏差

InterviewMe 的核心动作是单题追问+假设验证：每次只提出一个问题，并附上当前最佳猜测，直到能预判用户回答。这个过程会系统填补四个关键空白：

• who：明确使用者身份与使用场景（是新手运营还是资深分析师？）
• why：追溯需求动机（是应对审计压力还是优化日常流程？）
• success：定义可量化的成功标准（响应时间<2秒？还是转化率提升5%？）
• constraint：锁定硬性限制（必须兼容现有API？还是预算固定？）

当用户提出惯例性需求（如"做个X功能"），技能会拆解这种行业惯例背后的隐含假设；当两个合理价值产生张力时，会明确要求用户做出优先级选择。这种追问不是发散式头脑风暴，而是通过结构化问题将模糊需求压缩为可验证的假设。

适用边界与注意点

不适用场景：

• 明确且自包含的任务（如重命名变量、修复拼写错误）
• 用户明确要求"跳过验证直接做"或优先级为速度的场景
• 纯信息查询（如"这段代码如何工作"）
• 机械性操作（如文件移动、格式转换）

关键提醒：
当对需求已有≥95%信心时，应停止追问并直接进入执行；追问的目的是消除关键不确定性，而非追求绝对完美。在用户使用" grill me "或" stress-test my thinking "等明确指令时，可强制触发此技能，将需求验证变为显式的协作环节。