用途：把模糊想法、客户请求或已上线功能，转化为产品必须支持的一个决策。优先沿用用户已有语言与既有简报，不另造框架。
主要能力：识别用户、情境、当前替代做法、期望结果与业务约束，并区分证据与假设；追踪一个从入口到有用结果的完整任务，而非罗列页面；设定最小可用范围、明确排除项，以及下一份产物应回答的问题；对已有功能，对比真实使用路径与最初承诺，保留有效部分、识别偏移并给出有边界的修正建议。
使用方式：只问会改变范围或后果的问题；在可能时以标注且可回退的假设继续推进；对已明确规格的实现任务不强制先做访谈。交付一份紧凑简报，结构为：Concept、User/situation、Outcome、First workflow、Scope in / out、Constraints/risks、Assumptions / open questions、Acceptance check、Next artifact。可用短段落或表格，省略空项，并给出可观察的验收条件，不虚构研究或指标。
适用场景：目标尚未确定、需要先厘清要构建什么时；客户提出方案但真实任务更窄时；需要判断已上线功能是否偏离初衷时。
限制与边界：目标已确定且下一步是可点击原型时，改用 $prototype；目标已确定而关注界面观感时，改用 $craft；已有共识简报需要可测试行为时，改用 $requirements。这些是可选后续步骤，非强制前置。注意：页面清单看似进展却掩盖缺失的任务；用“更好”的功能替换用户明确要求的功能，需先说明取舍；编造目标会成为被引用的承诺；低使用率原因各异，需先查明再建议删减。