用途
distill-need 面向的是这样一种情形：用户提出了一个具体的功能、工具或实现要求，但该要求本身只是一个“被提议的解决方案”，未必是真正的目标。
它的立场是：用户的请求不是经文，通常只是一个方案提议。人们常常并不清楚自己在要什么、不清楚自己真正需要什么，也不清楚已有方案其实已经覆盖了这一点。天真的 AI 会直击字面词语；而该技能的职责是提炼需求，然后给出能命中结果的路径——这些路径可能和字面要求看起来完全不同。
经典模式：
- 要求：“我需要一匹更快的马。”
- 提炼：更快到达 B。
- 更好的手段：一辆车——或者走路，如果工作地点就在十英尺外。
主要能力
区分四件事
- 字面要求——被点名的功能、工具或实现
- 真实需求／目标——用户满意时必须成立的状态
- 上下文——可能让问题瓦解或改变的约束
- 更好的手段——包括复用、流程变更或不构建
然后让用户自己决定。把提炼结果呈现出来，不要静默换入你偏好的方案。
六步工作流
1. 捕获被提议的解决方案
用一行重述字面要求，并标注它是一个被提议的解决方案，而非使命本身。
2. 提炼结果
只问能揭示以下内容的最小问题集：
- 这件事完成后必须成立什么
- 为什么现在想要它
- 如果什么都不变，会有什么痛苦
优先用 1–3 个高杠杆问题。当分叉清晰时批量提问。
3. 检查会瓦解问题的上下文
寻找改变解决方案类别的事实：约束、距离、频率、紧迫性、规模；谁在承受痛苦；在他们的语境里“完成”意味着什么。
如果上下文缺失且会改变答案，就主动询问。如果能从仓库或产品安全推断，就说明该假设。
4. 检查已有方案
在发明之前先问：代码库、产品或流程里是否已经有轮子，他们是否在重复造轮子。只要命中需求，优先整合、复用、配置，而不是从零构建。
5. 给出方案类别
给出 1–3 个通往同一结果、本质不同的手段，至少考虑：不构建／手工／流程／现成工具；对已有事物做最小改动；被点名要求本身（或清理后的版本），如果它仍配得上位置。对每个路径说明：结果契合度、成本、牺牲什么、何时会选它。然后推荐其一，由用户选择。
6. 交接
- 如果需求消亡或“走路”胜出 → 停止，不产出计划、不写代码。
- 如果仍是“构建形态” → 交给 pre-plan 和／或 8020。
- 如果用户已有方向、只需被戳漏洞 → 交给 challenge。
提问过滤器
只问会改变以下内容的问题：结果定义、方案类别、构建是否正当、已有事物是否已解决它。不要问实现琐事，不要制造需求戏码。
使用方式
把用户的请求作为输入，按上述六步处理。关键行为包括：
- 要：“你要的是更快的马。结果似乎是：更快到上班地点。你住的地方离上班地点十英尺——走路胜过养马。如果真正的约束是天气／身份／载货，说明是哪个，我们再开一轮。”
- 不要：开始设计马匹优化服务。
- 要：“你要一个新的通知微服务。需求似乎是：用户注意到计费失败。现有邮件加应用内横幅可能就够。选项：(1) 复用横幅，(2) 扩展现有通知器，(3) 新服务。我推荐 (1)。”
- 不要：因为句子里有这个名词就去搭微服务脚手架。
- 要：“字面要求：自定义 RBAC 引擎。提炼后的需求：对非管理员隐藏管理界面。两条路由上做角色检查可能就够了。在发明策略框架之前先确认结果。”
- 不要：把被点名的架构当成神圣不可动。
- 要：先推荐，再等用户选择。
- 不要：静默用你的私货方案替换他们的请求并开始编码。
适用场景
- 用户提出具体功能、工具、微服务、架构或引擎要求，需要先判断是否值得构建时。
- 用户可能不知道自己真正需要什么，也可能是已有方案已覆盖却被忽视时。
- 在进入计划或编码之前需要拦截请求、澄清结果时。
与同类技能的关系
| 技能 | 关系 |
|---|---|
| pre-plan | 提炼之后，如果工作仍是构建形态：对齐共享概念。 |
| 8020 | 需求清晰之后：选择通往该结果的最小可用路径。 |
| product-ideation | 更宽泛／更早期的产品前提工作。当想法本身仍未定型，而非一个具体请求需要拦截时使用。 |
| challenge | 对既有方向施压测试。主要不做请求的类别重划。 |
distill-need 是那个拦截点。它可以以“不构建”收尾。
限制
- 它不会在未经用户确认的情况下丢弃或替换用户的要求；必须由用户选择路径。
- 若需求不成立或更简单的路径（如“走路”）胜出，流程就此停止，不产出计划或代码。
- 只问最小的高杠杆问题，不进行冗长的需求收集。
- 对具体实现细节、收费、价格、平台、效果等未在资料中说明的内容，暂未提供。