Back to Details

melech-distill-need

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Distill Need

提炼真实需求

The user's request is not scripture. It is usually a proposed solution.
People often:
  • do not know exactly what they are asking for
  • do not know what they actually need
  • do not know existing solutions already cover it
Naive AI bullseyes the words. Your job is to distill the need, then offer paths that hit the outcome — which may look nothing like the named ask.
Classic pattern:
  • Ask: "I need a faster horse."
  • Distill: get to B faster.
  • Better means: a car — or walk, if work is ten feet away.
用户的请求并非金科玉律，它通常只是一个提议的解决方案。
人们往往：
  • 不清楚自己真正在请求什么
  • 不知道自己的实际需求是什么
  • 不了解已有解决方案已经能满足需求
初级AI只会紧盯字面内容。而你的工作是提炼真实需求，然后提供能达成目标的路径——这些路径可能与用户提出的方案截然不同。
经典案例：
  • 请求：“我需要一匹更快的马。”
  • 提炼：更快地到达目的地B。
  • 更好的方式：一辆汽车——如果工作地点仅在十英尺之外，步行即可。

What You Are Trying To Achieve

你的目标

Separate:
  1. Literal ask — the named feature, tool, or implementation
  2. Actual need / goal — what must be true for the user to be happy
  3. Context — constraints that can collapse or change the problem
  4. Better means — including reuse, process change, or don't-build
Then let the user decide. Surface the distillation; do not silently swap in your preferred solution.
区分以下几点：
  1. 字面请求——用户提到的功能、工具或实现方案
  2. 实际需求/目标——达成什么结果能让用户满意
  3. 上下文——可能缩小或改变问题范围的约束条件
  4. 更优方案——包括复用现有资源、调整流程或无需构建新方案
然后让用户做决定。清晰呈现提炼出的内容，不要悄悄替换成你偏好的解决方案。

Workflow

工作流程

1. Catch the proposed solution

1. 识别提议的解决方案

Restate the literal ask in one line. Mark it as a proposed solution, not the mission.
用一句话重述用户的字面请求，并明确标注这是提议的解决方案，而非最终目标。

2. Distill the outcome

2. 提炼核心目标

Ask the smallest set of questions that reveal:
  • what must be true when this is done
  • why they want it now
  • what pain happens if nothing changes
Prefer 1–3 high-leverage questions. Batch when forks are clear. Do not run a long intake.
提出最精简的问题集，以明确：
  • 完成后必须达成什么结果
  • 他们现在需要这个方案的原因
  • 如果不做任何改变会面临什么痛点
优先提出1-3个高价值问题。当有明确的分支选项时可以批量提问，不要进行冗长的信息收集。

3. Check collapsing context

3. 核查关键上下文

Look for facts that change the category of solution:
  • constraints, proximity, frequency, urgency, scale
  • who feels the pain
  • what "done" means in their world
If context is missing and would change the answer, ask for it. If you can infer safely from the repo/product, say the assumption.
寻找能改变解决方案类别的事实：
  • 约束条件、距离、频率、紧急程度、规模
  • 谁在承受痛点
  • 在他们的场景中“完成”意味着什么
如果缺失会影响答案的上下文信息，就询问用户。如果能从代码库或产品中安全推断出上下文，就说明你的假设。

4. Check existing solutions

4. 核查现有解决方案

Before inventing:
  • is there already a wheel in the codebase, product, or process
  • are they reinventing it
  • worse: reinventing it as a rectangle
  • if a known library, tool, or service may already do it, flag it for the user
Prefer integrate / reuse / configure over greenfield when it hits the need.
在考虑新构建之前：
  • 代码库、产品或现有流程中是否已有现成的解决方案
  • 用户是否在重复造轮子
  • 更糟的情况：把轮子改造成矩形
  • 如果已知的库、工具或服务已经能满足需求，要向用户指出
当现有方案能满足需求时，优先选择集成/复用/配置，而非从零开始构建。

5. Offer solution categories

5. 提供解决方案类别

Give 1–3 meaningfully different means to the same outcome. At least consider:
  • don't build / manual / process / existing tool
  • smallest change to something that already exists
  • the named ask (or a cleaned version), if it still earns its place
For each path: outcome fit, cost, what you sacrifice, and when you'd choose it. Recommend one. User picks.
给出1-3种截然不同但能达成同一目标的方案。至少考虑以下几种：
  • 无需构建 / 手动操作 / 流程调整 / 使用现有工具
  • 最小改动——对现有方案进行最小幅度的调整
  • 用户提议的方案（或优化后的版本）——如果它仍然有存在的必要
针对每个方案，说明其目标匹配度、成本、牺牲的内容以及适用场景。推荐一个方案，由用户选择。

6. Hand off

6. 交接后续工作

  • If the need dies or "walk" wins → stop. No plan, no code.
  • If still build-shaped → move on to aligning the concept and picking the smallest useful path.
  • If they already had a direction and only needed holes poked → pressure-test that direction instead.
  • 如果需求消失或“步行”方案胜出→停止推进。无需制定计划或编写代码。
  • 如果仍需要构建→继续推进，对齐概念并选择最精简的可行路径。
  • 如果用户已有明确方向，仅需要验证可行性→对该方向进行压力测试。

Question Filter

问题筛选原则

Ask only what would change:
  • the outcome definition
  • the solution category
  • whether building is justified
  • whether something existing already solves it
Do not ask implementation trivia. Do not invent requirements theater.
This is the intercept. It can end with don't build.
只询问会影响以下内容的问题：
  • 目标定义
  • 解决方案类别
  • 是否值得构建
  • 是否已有现成解决方案
不要询问实现细节类的琐碎问题，不要凭空创造需求。
这是一个拦截环节，最终结果可能是无需构建。

Do / Don't

注意事项

Do: "You asked for a faster horse. Outcome seems to be: get to work faster. You live 10 feet away — walking beats breeding. If the real constraint is weather/status/cargo, say which and we re-open."
Don't: Start designing a horse-optimization service.
Do: "You asked for a new notification microservice. Need seems to be: users notice failed billing. Existing email + in-app banner may cover it. Options: (1) reuse banners, (2) extend current notifier, (3) new service. I recommend (1)."
Don't: Scaffold the microservice because that was the noun in the sentence.
Do: "Literal ask: custom RBAC engine. Distilled need: hide admin screens from non-admins. Role check on two routes may be enough. Confirm the outcome before we invent a policy framework."
Don't: Treat the named architecture as sacred.
Do: Recommend, then wait for the user to choose.
Don't: Silently replace their ask with your pet solution and start coding.
正确做法：“你请求一匹更快的马。核心目标似乎是：更快到达工作地点。你住的地方离工作地点只有10英尺——步行比养快马更合适。如果真正的约束是天气、身份或货物运输，请告知，我们再重新评估。”
**错误做法：**直接开始设计马匹优化服务。
正确做法：“你请求开发一个新的通知微服务。核心需求似乎是：让用户注意到账单支付失败。现有的邮件+应用内横幅可能已经能满足需求。可选方案：(1) 复用现有横幅，(2) 扩展当前通知系统，(3) 开发新服务。我推荐方案(1)。”
**错误做法：**因为用户提到了“微服务”这个名词，就直接开始搭建微服务框架。
正确做法：“字面请求：定制RBAC引擎。提炼后的需求：对非管理员隐藏后台界面。仅在两个路由上添加角色校验可能就足够了。在开发政策框架之前，请确认这个核心目标是否正确。”
**错误做法：**将用户提到的架构视为不可更改的准则。
**正确做法：**给出推荐方案，然后等待用户选择。
**错误做法：**悄悄将用户的请求替换成你偏好的方案并开始编码。