需求对齐

问题：需求在被实现之前就已经歪了

「做个仪表盘」、「让它更快」——这类请求描述的往往是一个约定俗成的东西，而不是用户真正要的结果。人们说出「仪表盘」，是因为那是大家会说的话；说「更快」，却没有一个数字可以打。等方案、spec、代码都开始落地，切换成本就变成真的了，用户也会把错的东西合理化成「够用」。

更麻烦的是 want vs. should want 的边界。一旦答案是「可扩展」、「干净架构」这类听起来像最佳实践的说法，而不是一个具体结果，就说明你在跟惯例对话，而不是跟真实意图对话。

这个技能怎么工作

它不写 spec，也不做规划，只做一件事：在挖掘成本还是零的时候，把还没说出口的真实需求挖出来。核心机制：

• 先假设，并给出置信度：用一句话写下当前对用户意图的最佳判断，附一个 0–100% 的数字。这个数字逼着你诚实——如果你自评 90%，却预测不了接下来三个问题用户会怎么反应，那这个数字就是假的。低于 ~70% 时必须附一行理由，说明还缺什么。
• 一次问一个问题，每个都带上猜测：等用户反应后再问下一个。批量提问会诱导扫读和面子答案，而且第三个问题常常依赖第一个问题的答案。附上猜测比让人从零组织答案快，也把你绑在一个可以被证伪的假设上。
• 识别「应该要」：听到 I should probably、good engineering practice says，或者一个被当作目标的流行词，直接追问：「If you didn't have to justify this to anyone, what would you actually want?」
• 用自己的话重述意图：置信度足够高时，把 Outcome / User / Why now / Success / Constraint / Out of scope 写回去，让用户逐行确认或纠正。Out of scope 不能省——一半的分歧来自对「不做什么」的沉默。
• 明确的 yes 才算数：Sounds good.、Whatever you think.、Sure, let's go. 都不是确认。第一个是授权，后两个常常只是礼貌性退场，要用两个具体选项重新问。

交付物是被确认的意图陈述；spec、规划、任务拆解都是它下游的消费者。

什么时候用，什么时候别用

当 who、why、success、constraint 至少缺一个；请求只是惯例式表达而非具体描述；你准备从一个还没说出来的假设出发；或者两个合理目标（简单 vs. 灵活、成本 vs. 速度）在拉扯而用户没说选哪个时，用它。

不要用于本身明确且自洽的需求（rename this variable）、用户明确要求先跑起来再说、纯信息询问、机械操作。

硬约束：它需要一个在线、能回应的人。不要在 CI、定时任务、/loop 或 autonomous-loop 里调用——那种上下文里需求不完整，应该把它标成 blocker 报给用户，而不是自己猜。

终止条件是可检验的，不是感觉：你能预测用户对接下来三个问题的反应吗？ 能，就停下来产出 restate。连问几轮还预测不了，说明需求本身缺了根基，该退一步明说。