技能介绍

要解决的问题

用户嘴上说的需求，往往不是他们真正要的东西。他们要“一个仪表盘”，是因为别人都这么要，不是因为仪表盘能解决自己的麻烦；他们说“让它更快”，却拿不出任何可衡量的数字。真正致命的是，这个落差在写计划、写规格、写代码之前发现，成本几乎为零；一旦投入开发，切换成本就变成了实打实的沉没成本，用户会反过来把选错的方案合理化成“够用就行”，错误的耦合就此固化。

这个技能要处理的就是这个时点：需求还没有任何形态时，把模糊的诉求和实际目标之间的缝隙提前焊死，避免后面拿重构来补窟窿。

技能如何工作

核心机制不是填问卷，而是逐步收敛：

先给出当前对用户意图的最佳假设，用一句话概括，并附带置信度
每轮只问一个问题，同时把自己的最优猜测一起抛回去，让对方确认或纠正
重复这个过程，直到能预判用户的回答——在他开口之前就知道他会说什么

这种方式避免了两类常见的翻车：要么一次性抛出十几个问题让人无从下手，要么完全不带假设地采访，最后拿到一堆正确的废话。

适用边界

应该用它，当需求缺少至少一个关键维度：谁在用、为什么要、成功长什么样、硬性约束是什么；当请求只是常规模板（“给我做个 X”、“让它更快”）而你不得不靠猜来拆解；当你发现自己正在基于没暴露过的假设直接动手；当两个合理的优化目标互相打架（简单 vs 灵活、成本 vs 速度）而用户没有说明优先哪个；或者用户直接说“ interview me”、“ grill me”、“开始之前先确认一下”、“压力测试一下我的思路”。

不应该用它，当需求本身明确且自洽（“改个变量名”、“修个拼写错误”）；当用户明确要求速度优先、跳过验证；当只是纯信息查询（“这段代码怎么跑”）；当是纯机械操作（重命名、格式化、移动文件）。

另外有一个硬性前提：这个技能需要实时的、能回应的用户。不要在 CI 流水线、定时任务、/loop 或任何自主循环里调用它。如果处于这种环境而需求又没定义清楚，应该标记为阻塞项交回给用户，而不是自己猜一个填进去。