把“无标题”需求变成完整方案：五问法提取项目骨架

有一类需求，我见过很多次：标题栏里什么都没写，就用三个字占位——“无标题”，后边的关键词栏、摘要描述栏全是空白。第一回拿到这种空壳文档，我下意识想退回，后来发现退回几次都没用，对方不是不愿意给你写，而是确实不知道怎么把脑海里的东西搬到文档里。

处理得多了就明白，“无标题”项目并不是信息缺失，只是信息还没被翻译成外部语言。真正的内容藏在他过往的聊天里、对现有工具的抱怨里、某个具体使用场景里。你需要做的不是逼他交出标题，而是把那些散落的信息捡回来，重新组装成一份有标题、有正文、有关键词、有摘要的完整方案。

这套方法我已经沿用很久了，做内容、做产品、做项目都通用。如果你也在跟无标题需求打交道，下面的整套流程可以直接拿去用。

1. “无标题”不是一个缺陷，而是一个诊断信号

很多人拿到一份空壳需求时，第一反应永远是“对方没想清楚”。这句话其实只对了一半。

无标题的背后，至少有两种完全不同的状态。一种是真的没想好，脑子里只有一团模糊的方向，比如“我想做一个效率工具，让工作更快一点”，你再追问细节，他就答不出来了。另一种是已经把目标、场景、甚至验收标准都想明白了，只是不知道怎么归纳成标题和关键词。你问他打算解决谁的什么问题，他能滔滔不绝讲十分钟，连用户会在哪一步卡壳都说得清清楚楚，但让他写文档就哑火了。

这两种状态的处理策略不一样。前者需要你帮他做信息发散，后者需要你帮他做语言收敛。

1.1 先分清“没想好”和“没说清”是两种完全不同的状态

如果判断错了，后面的流程会整个跑偏。我见过最典型的错误，是把“没说清”的人当成“没想好”，然后拼命带着他做头脑风暴，结果对方越来越烦躁，因为你提的方向都不是他想说的那个东西。

我的做法是从两个小问题入手：“这个项目做出来之后，谁最想马上用？”以及“他现在最烦的是什么？”

别小看这两个问题。它们一个逼出目标人群，一个逼出痛点场景，答案几乎能立刻帮你判断对方属于哪种状态。如果对方停顿说不出话，大概率是没想好，这时候要切换到发散引导；如果对方脱口而出一个具体的抱怨，比如“我现在用Excel管项目，版本一多就乱”，说明他想得很清楚，只是不会归纳，下一步直接做收敛就好。

1.2 信息不会消失，只是藏在三个地方

无标题项目里，信息量其实并不少，只是位置不对。我摸索下来，大部分有效信息都藏在三个地方。

第一个是历史对话。很多无标题项目在正式提需求之前，都经历过一段漫长的口头沟通。对方在聊天里随手写过一些很生动的描述，比如“每次整理客户表都要手动复制粘贴，特别烦”，这种带情绪的话放在文档里可能被过滤掉，但恰恰是项目真正要解决的问题。我第一次处理无标题需求时，往前翻了一周的聊天记录，翻完几条截图，项目方向马上浮现出来了。

第二个是竞品对照。对方十有八九会说“类似某个工具”“另外那个产品好像也是这么做的”。这虽然算不上完整的项目描述，但能快速圈定功能参照系。关键是问一句：“你说的那个产品，你最受不了它哪一点？”这一问几乎总能问出差异点。比如对方说那个产品太复杂，设置项太多，那你的标题就可以围绕“极简”展开。

第三个是使用场景。很多提需求的人习惯讲功能，不讲场景，但场景往往比功能更接近核心需求。例如“我每天要跟十几个客户对合同时间，老是撞期”，这句话已经包含了目标用户、痛点和潜在解决方案的方向，比一句“我想做一个日程管理工具”有价值得多。

1.3 先归档，再思考

把信息挖出来之后，不要急着写标题，先做归档。我自己的习惯是分成四类：对象、痛点、现状做法、想达到的效果。

• 对象：给谁用，这一类人有什么共同特征。
• 痛点：他今天卡在哪，什么状态下最难受。
• 现状做法：他现在正在用什么笨办法，那个笨办法为什么让他不满意。
• 想达到的效果：做完之后，他希望自己的一天变成什么样。

归档的过程看似简单，但作用很大。零散的信息一旦有了结构，后面用五问法还是写摘要，都是直接从这份归档里取数据，不需要再回到那堆聊天记录里翻来找去。这也让“无标题”项目第一次拥有了一个可以落脚的骨架。

2. 从空标题倒推出项目骨架：五问法

标题是价值的压缩包。一个有经验的从业者，能从标题里读出受众、场景、差异点和验收标准。反过来，如果标题是空的，那就用几个关键问题把信息一层层拆出来。

2.1 五个问题，以及问出口时的正确姿势

我把这套方法叫“五问法”。它不是用来审问对方的，而是为了让项目骨架自然浮出来。五个问题如下：

实际问的时候，顺序不一定要完全固定。对方有时候会直接跳到“想达到的效果”，那就可以顺着他的思路走，最后再把漏掉的问题补上。关键不是控制节奏，而是保证五个维度都被覆盖到。

五问法里最容易出效果的是第二个问题：“他现在用的办法是什么，卡在哪一步？”几乎每个人都有一套低效但勉强能跑的笨办法，而那套办法让他痛苦的地方，往往就是项目的机会点。比如对方说“我现在用便签纸记待办，一到下午桌上全是纸，分不清哪张是今天的”，这句话比十句“我想做个待办工具”都有用，因为它直接指向了“没有今日视角”这个核心痛点。

2.2 把答案压缩成“一句话说明书”

五个问题的答案不一定全部有用，但一定能形成一段描述。下一步是把它压缩成一句话，格式很简单：

为〔对象〕解决〔卡点〕，用〔做法〕交付〔产物〕，以〔标准〕判断成功。

举个例子。对方说“我想做一个帮助大家整理工作日程的东西”，经过五问法之后，这句话可以变成：为每天要处理大量待办事项的人解决“事情一多就漏掉”的问题，用一张简洁的每日清单做管理，以“每天下班前全部事项打上钩”作为成功标准。

这句话是整个项目的宪法。后面的标题、正文、关键词、摘要，全部从这句话里拆出来。

2.3 为什么我坚持在定标题之前先干这件事

大多数人的直觉是先把标题定下来，再写正文。但面对无标题项目，这个顺序必须反过来。

如果一个项目连标题都没有，说明“价值压缩”这一步还没完成。这时候匆匆写出来的标题，要么过于抽象，要么长到没人愿意读。先走五问法，等于先把信息从混乱状态变成有结构的框架，再从框架里提取最核心的表达。

顺序反了的典型症状是：标题定得挺漂亮，但正文写到一半发现跟标题对不上，只能反复返工。我在这上面吃过亏，现在都强制自己先填完归档表再动笔。标题不是一个起点，它是一张地图，地图画歪了，后面走的路全是歪的。

3. 关键词与摘要：约束条件而不是事后装饰

很多人把关键词和摘要理解成正文写完之后顺手填的框，这其实是个很大的误解。对一个无标题项目来说，关键词和摘要恰恰是帮你圈定范围、验证方向的最有效工具。

3.1 没有指定关键词时，怎么圈候选词

当关键词栏是空白时，不要凭空想十个词，而是从“一句话说明书”里拆词。

拆词的方法很简单：把所有名词都挑出来。比如“为每天要处理大量待办事项的人解决事情一多就漏掉的问题，用一张简洁的每日清单做管理”，这里能当关键词的名词有：待办事项、每日清单、时间管理、效率工具、防遗漏、日程管理。

挑完之后，再问自己一个过滤问题：如果用户要搜一个解决方案，他会打哪个词？一定不是内部叫法，而是用户真实会搜索的日常用语。这个过滤能把“待办事项”留下来，把“防遗漏体系”这类内部术语删掉。

如果能跟原需求方对上话，我还会把候选词直接发给他，让他挑出最想要的三个。这里有一个很实用的现象：他挑词时的犹豫程度，往往能反映项目优先级。如果他在“效率工具”和“待办清单”之间迟疑了很久，说明这两个方向在他心里还没定下来，这就是下一步要澄清的重点。

3.2 摘要描述的三段式写法

摘要描述没有字数限制时，我习惯用三段式来写：给谁看、做什么、怎么验证。

第一段用一句话交代对象和场景，例如“每天被大量待办事项压得喘不过气、经常担心遗漏的人”。第二段用两三句话说明项目提供的核心做法，比如“基于每日清单的极简管理办法，把当天任务拆成可勾选的独立条目，并用一个简单的优先级标记区分轻重缓急”。第三段说明怎么判断有没有效果，比如“连续使用之后，能明显减少事后的遗忘焦虑，晚上核对清单时有明确的收尾感”。

这个三段式的核心价值是，不管读者是需求方、协作者，还是完全不了解背景的人，都能在很短时间内判断出这个项目跟他有没有关系。对一个无标题需求来说，摘要写得好不好，直接决定了项目能不能得到后续资源。

3.3 用关键词和摘要反过来检验标题

关键词和摘要不只用来描述项目，它们还能做一次反向校验。方法很简单：把拟好的标题、关键词、摘要放在一起读一遍，看它们讲的是不是同一件事。

我经常在无标题项目里发现，标题拼命强调“极简”，关键词却全是“复杂报表”“统计分析”——这种冲突说明需求里混进了两个互不相干的方向，必须回到五问法里做一次取舍。这种冲突在现场特别常见，早点撞见能省掉后面一大截沟通成本。

关键词和摘要写完之后，也可以当作“项目的一句话路演稿”。跟同事或者用户解释这个项目时，直接念摘要，再补一句关键词背后的逻辑，对方基本不会听歪。

4. 一次“无标题”需求从零变完整的完整推演

前面讲的都是方法，这一节我用一个完整的例子，演示从空壳需求到完整方案的全过程。这个例子会尽量贴近现场的真实状态。

4.1 初始信息只有一句话

某位同事发来一条消息：“我想做一个工具，帮我管理每天要做的事情。”没有项目标题，没有正文，没有关键词，没有摘要。这基本就是最标准的无标题状态。

我没有追问“你想把标题写成什么样”，而是先把这句话放进五问法里过一遍。

4.2 五问法逐一现场应用

第一问，给谁用？对方说“我自己用，但要是做得顺，其他同事应该也会用。”于是对象锁定了：日常任务繁重、容易忘事的人。

第二问，要解决什么卡点？他的回答是：“现在用便利贴，也试过手机备忘录，但一到下午，贴了满桌的便利贴就乱了，备忘录里塞了几十条，根本分不清哪些是今天要做的。”这个场景非常具体，痛点非常清晰。

第三问，和现状做法比差在哪？他的思路是：“便利贴和备忘录的问题是没有一个‘今天’的视角，所有任务堆在一起，看不到优先级，也看不到完成情况。”这句话直接把差异点拎了出来：要给用户一个以“今天”为维度的工作台，而不是一个无限堆积的列表。

第四问，交付物的形式？他说“先做一个网页上能打开的简单工具就行，不用手机App。”范围就清楚了。

第五问，怎么才算成功？他的原话是：“每天晚上打开它，能看到今天该做的事全部打钩，不会因为乱七八糟的遗漏，半夜想起来睡不着。”这个验收标准很感性，但也非常具体。

4.3 现场产出标题、正文、关键词和摘要

五问法跑完之后，我汇总出一句话说明书：为容易忘事、日常任务多的人解决“事情堆在一起没有今天视角”的问题，用一张以今天为维度的每日清单来管理，以“每天睡前能确定当天事项全部完成”为成功标准。

从这句话里，我拟出了以下成果：

• 项目标题：每晚都能安心收工：用一张今日清单管好全天任务
• 项目正文：这是一个极简的每日待办管理工具，打开后只显示“今天”，不支持复杂分组和报表，但支持快速添加、标记优先级、勾选完成。核心设计目的是减少认知负担，不再需要靠便利贴和散落各处的备忘录来记住清单。
• 关键词：每日清单、待办管理、时间管理、减少遗漏、简化任务管理
• 摘要描述：每天被大量任务和临时安排推着走的人，容易在晚上突然想起漏掉的事；本工具用“只有今天”的极简清单，让任务按优先级排列、勾选完成，并保持所有操作在十秒内可完成，帮助用户建立每天收工前的核对习惯。

这套方案交回去后，对方几乎没有改动就点头了，还补了一句：“这比我一开始想的清楚多了。”这句话恰恰说明了无标题项目的本质：真正的问题不是内容缺失，而是内容需要被翻译。

4.4 从成果倒推回去，检查是否跑偏

每次推演完，我都会做一次倒推检查：把产出的标题、关键词、摘要反过去对照最初那五个问题的答案。

标题里的“每天”对应卡点里的“没有今日视角”，关键词里的“减少遗漏”对应成功标准里的“半夜睡不着”，摘要里的“十秒内可操作”对应交付形式里的“简单工具”。三个维度对得上，方案才敢交付。

如果中间有什么对不上，我会回到五问法里重新取舍，而不是去硬改标题。这一步是防止项目“写着写着就跑偏”的关键。很多无标题项目死于一种悄无声息的偏离：大家感觉大方向没问题，但没人核对过标题是否还跟最初痛点一致，于是功能越加越多，项目越来越重。

5. 踩过三次坑后才明白的两条铁律

方法再好，实操中也容易踩坑。这里挑三个我印象最深的现场问题，以及我从里面提炼出来的两条铁律。

5.1 坑一：用逼问代替追问，只会得到更糟糕的标题

我第一次处理无标题需求时，用了最常见的笨办法：连续追问“你到底想表达什么”“核心卖点是什么”“标题和摘要你总得给一个吧”。结果是对方被问得更懵，给出的回答更抽象，最后甚至问我“你能不能直接帮我写一个”。

逼问是在强迫对方做整体压缩，而追问是让他做最简单的局部回答。正确做法是永远只问具体的小问题：“你身边谁会先用到它”“你最讨厌现在用的工具哪一点”。这类问题成本很低，不用组织语言，随口就能答，信息反而更真实。

5.2 坑二：替对方把标题定好，却不解释“为什么是这几个字”

还有一次，我高效地把标题、关键词、摘要都替对方写好了，对方也点头认可。结果项目推进了一个多月后，他反复推翻功能设计，说我理解得不对。回头复盘才发现，问题出在标题定得太顺滑——我起了个看起来很漂亮的标题，但他压根没理解那几个字背后的取舍，只是觉得名字听起来不错。

从那以后我给自己立了规矩：给标题、关键词、摘要时，必须配三行说明，讲清楚是从哪个卡点出发、对应哪个场景、做了什么样的取舍。宁可看起来啰嗦一点，也不能让对方在“不明白但点头”的状态下往前走。

5.3 坑三：跳过命名直接写内容，最后回不了头

还有一类无标题需求，会被我自己的“拖延症”放大。对方说“你先把正文写出来，标题后面再定”，我也就闷头去写了。但问题在于，正文是标题的展开，没有标题约束的正文会越写越散，最后写到两万字，完全不知道该往哪里收。

命名不是项目做完之后的包装，它是项目航行时的地图。除非你享受彻底返工，不然我建议在项目进入详细环节之前，先产出至少一版标题和摘要。

5.4 两条铁律：先理解再命名，命名就是做选择

这些坑踩过几次之后，我把自己的经验压缩成两条铁律。

第一，命名永远先于核心内容定稿，但永远晚于需求理解完成。这个顺序是：归档信息、五问法、一句话说明书、拟标题和摘要、写正文。看起来绕了一小圈，但这一圈能避免大量返工。

第二，每次命名都是一次选择实验，不是一次一锤定音。给需求方看选项的时候不要只给一个标题，我会给两到三个方向完全不同的选项，让他选。为什么强调方向不同？因为标题之争本质上是需求方向之争。提前让方向暴露出来，比晚到开发阶段再暴露好上一百倍。

如果你手头正好也有一份“无标题”需求，别急着让对方补标题。先带着五问法去聊一轮，把藏起来的信息挖出来归档，再拟标题、关键词和摘要。我试过很多次，这套流程走完以后，最后真正不确定的只剩一些可执行层面的细节，项目本身早就站稳了。我还记得第一次完整跑通这套流程时，对方在下班前发来一条消息：“原来我要的东西长这样。”那个瞬间让我觉得，无标题需求再也不是空壳，而是我切入真正问题的一张入场券。