← rugoi.com 原始文件 ↓

如何把一句模糊需求变成可执行方案

用途:把「帮我弄一下」变成「做这三件事,做完是这个样子」。不是猜得更准,是问得更准。

覆盖:一句话需求、口头指派、聊天里冒出来的想法。

产出:一份可执行方案(做什么、不做什么、怎么算完成)。

拿到就能跑:别急着开工。 模糊需求最大的成本不是做错,是做完才发现不是要的。


触发的变异问法


什么时候不要用这份文件


判断:先问三个问题

一次问一个。 三个都答不上来时,先问第一个。

#问什么怎么问出口(原话)判据答不上来时
Q1做完之后,什么变了「这件事做完之后,你会看到什么不一样?」能说出具体变化 → Q2;说不出 → 先定目标给他两个选项选:「是让 X 变快,还是让 Y 变准?」
Q2有什么不能碰「有没有什么是我不能改的?时间上最晚什么时候要?」说得出边界 → Q3;说不出 → 先划边界问反过来:「如果做过头了,哪种情况你会不高兴?」
Q3谁来判断做成了「做完之后谁来看?他看什么?」有人有标准 → 给方案;没有 → 先定验收提议一个:「我按 A 标准交,你看行不行?」

分支

条件下一步
Q1 说不出先定目标:给两个具体选项让他选,不要问开放式问题
Q1 有,Q2 说不出先划边界:问「做过头会怎样」,比问「边界是什么」好答
Q1、Q2 有,Q3 说不出先定验收:主动提一个标准让他确认,不要等他给
三个都有给方案,直接进下一步

三轮问不出来就换方式:不再问,改成给候选让他挑。同一个问题问第四遍,答案质量不会提升,只会让人烦。


把答案变成方案

拿到三个答案后,按这个结构写:

做什么:<三到五项,动词开头>
不做什么:<明确划掉的>
做完是什么样:<可判的验收标准>
需要你决定:<还有哪一两处要你拍板>

四条规则:

  1. 「不做什么」必须写。 只写做什么,范围会自己膨胀——尤其是「顺便优化一下」这类。
  2. 每项能独立交付。 三件事里的一件做完,应该是能看的东西。
  3. 验收标准要可判。 「体验更好」不可判;「点开三个页面都能在 2 秒内打开」可判。
  4. 留「需要你决定」。 把还剩的模糊处摆出来,比替对方决定安全。

出问题怎么办

现象最可能的原因处理
做完了不是他要的目标没对齐,只对齐了字面回 Q1,让他描述「做完看到什么不一样」
越做越大,收不住没写「不做什么」补上,并说明超出部分另行讨论
反复确认还是不对对方自己也没想清楚停手,给两个具体选项让他选,不要再开放式问
做完没人说好也没人说不好没有验收标准主动提一个,请对方确认或修改
中途需求变了一开始没留变更口约定「范围变更重新过一遍这四行」
问了五轮还没开工问法不对,不是在问判断题换成「A 还是 B」的选项式提问

输出规范

人读

需求原话:<逐字记录>
Q1 做完什么变了:<...>
Q2 不能碰的:<...>
Q3 验收:<谁、看什么>
方案:
  做什么:1. … 2. … 3. …
  不做什么:<…>
  做完是什么样:<可判标准>
  需要你决定:<…>

机器读

raw: <原话>
answers: {outcome, boundary, acceptance}
plan: {do: [...], not_do: [...], done_when, open_questions: [...]}
confidence: enough|partial|guess

not_do 为空时不要开工——范围一定会膨胀。

一句话版

做三件:A、B、C;不碰 D;做完看 E 指标;还有 F 要你定。


常见错误


最后核对

2026-11-06。三问判据与场景无关;「三轮问不出来就换方式」可按沟通节奏调整。与所执行系统的既定标准冲突时,以那个系统的标准为准。

Markdown 原文 · 更新 2026-11-06
turn-vague-request-into-plan · v1 · sop