需求访谈澄清

先解决什么：动手前的「需求错位」

很多项目走偏的起点，是用户说的「要什么」和实际「真正需要的东西」不一致——比如一句「做个仪表盘」，可能只是用户习惯用「仪表盘」指代「能看清状态的东西」，而非真的需要一块带图表的面板。这种错位一旦进入计划或代码阶段，纠错成本会指数级上升。这个技能要做的，是在动手前用苏格拉底式访谈把真实意图逼出来，让「最便宜的纠错时机」真正发挥作用。

它如何工作：从假设到显式确认的闭环

核心能力是一次一问、带着猜测推进，逼用户和访谈者都显式暴露假设，避免「从零想」的低效或「凭经验猜」的偏差。关键步骤如下：

• 先写假设+置信度：开工前用一句话写下对「用户想要什么」的判断，附0–100%的诚实置信度；低于~70%要补「还缺什么」——这个数字逼你正视自己的认知缺口。
• 一次一问，每问带猜测：用Q: 问题 + GUESS: 假设的格式推进，等用户回应再问下一个。带猜测比让用户从零想更快，也逼你显式暴露假设。
• 识别「想要 vs 应该想要」：警惕「听起来正确」的回答，比如套话（「要可扩展」「干净架构」）、顺从惯例、用口号当目标（「现代」「健壮」）。此时追问一句「如果不用向任何人交代，你真正想要的是什么？」，往往能直接穿透表面需求。
• 用用户的话复述意图：高置信度时，用5–8行复述六项——Outcome（结果）、User（谁受益）、Why now（为何是现在）、Success（如何算成功）、Constraint（硬性约束）、Out of scope（明确不做）。其中Out of scope是关键，一半的偏差来自对「不做什么」的沉默分歧。
• 确认=显式「是」：门槛是明确的「是」，「你定就好」「听起来不错」不算确认——要用两个具体选项重新确认。用户更正就吸收后重新复述，循环直到显式同意。
• 停止条件：当能回答「我能预测用户对下一个三个问题的反应吗？」为「是」（约95%置信度）时，停止访谈，产出已确认的意图陈述（IntentStatement）。若多轮仍不能预测，告诉用户「基础信息缺失，要退一步吗？」

适用边界：什么时候不该用

• 适用场景：诉求缺了「为谁/为何是现在/成功长啥样/约束是什么」中的至少一项；请求是套话而非具体（如「做个X」「搞快点」）；你正想用未显式说出的假设开工；用户显式调用（如「采访我」「压力测试我的想法」）。
• 不适用场景：诉求明确自洽（如「重命名这个变量」）；用户明确要速度不要核查；纯信息咨询；机械操作；非交互式上下文（如CI/定时任务/loop）里若诉求不清，应作为阻塞项上报用户，而非猜测。