用途
Melech Distill Need 的核心主张是：用户的请求不是圣旨，而通常只是一个被提议的解决方案。人们往往并不清楚自己到底在要什么、真正需要什么，也不知道已有方案是否已经覆盖了它。该技能的目标是在构建之前，先把“真实需求”从字面请求中蒸馏出来，再提供能够命中结果的路径——这些路径可能与用户最初点名的方案完全不同。
主要能力
该技能要求把以下几件事分开处理：
- 字面请求：被点名的功能、工具或实现方式。
- 真实需求 / 目标：用户要满意，必须成立的条件是什么。
- 上下文：可能让问题瓦解或改变的约束条件。
- 更好的手段：包括复用、流程变更，或者“不构建”。
随后把蒸馏结果呈现给用户，由用户决定，而不是悄悄替换成自己偏好的方案。
使用方式
技能定义了一套工作流：
- 抓住被提议的解决方案：用一行复述字面请求，并标记它是提议方案，而非任务本身。
- 蒸馏结果：用最少的高杠杆问题，弄清“做完之后什么必须为真”“为什么现在要”“如果什么都不变会有什么痛苦”。优先 1–3 个问题，分叉清晰时批量提问，不做冗长问询。
- 检查会瓦解问题的上下文：寻找改变方案类别的事实，如约束、距离、频率、紧迫性、规模、谁在承受痛苦、在他们语境里“完成”意味着什么。若上下文缺失且会改变答案，就追问；若能从代码库或产品安全推断，就说明该假设。
- 检查已有方案：在发明之前，先看代码库、产品或流程里是否已有轮子，是否在重复造轮子，甚至把轮子造成方的；若已知库、工具或服务可能已经能做，就向用户指出。命中需求时，优先集成、复用、配置，而非从零开发。
- 提供方案类别：给出 1–3 条通往同一结果、彼此有实质差异的路径。至少考虑：不构建 / 手动 / 流程 / 现有工具；对已有事物做最小改动；以及被点名的请求（或清理后的版本），前提是它仍配得上这个位置。每条路径说明结果契合度、成本、牺牲什么、何时会选择它。推荐一条，由用户选择。
- 交接：如果需求消失或“走路”胜出，就停止，不出计划、不写代码；如果仍是构建形态，则继续对齐概念并选择最小可用路径；如果用户已有方向、只需要被挑漏洞，就改为对该方向做压力测试。
适用场景
该技能适用于需求澄清与方案评审阶段，例如用户提出“我要一个更快的马”“我要一个新的通知微服务”“我要一个自定义 RBAC 引擎”这类请求时，先蒸馏出真实结果，再判断是否值得构建。它也可以用于对已有方向做压力测试。
限制
该技能明确要求只问会改变结果定义、方案类别、构建是否合理、或已有方案是否已解决的问题，不问实现细节琐事，不制造需求表演。它是一个拦截点，可能以“不构建”结束。资料未提供该技能的具体安装命令、平台支持、收费方式或代码实现细节。