Skip to content

需求说不清的时候,该怎么办? ​

导读 ​

先把需求「提」清楚,再让 AI 动手。现成的苏格拉底式方案里,/grill-me 一问一答地挖隐性假设、确认边界,最后整理成一份规格文档;需求极简单时,用「什么角色、在什么场景下、做什么事情」自查一遍即可。

在软件公司,「需求澄清」是项目发起人与包括开发人员在内的相关方达成目标共识的必要环节。有些时候,「需求澄清」的过程,要比最终开发出的结果还要重要。有一些「需求会议」甚至能改变整个业务部门乃至公司的战略方向。

目前有十分成熟的项目方案,大致分三类:现成 Skill/Agent 命令、开源框架和可直接复制的提示词模板,全部是社区在 Vibe Coding 场景下专门打磨的苏格拉底式需求澄清方案。他们的设计思路如出一辙,都是在 AI 工作之前,先通过连续提问挖出隐性假设,确认边界,输出一份可执行规格。

/grill-me ​

仓库:mattpocock/skills(GitHub)

中文圈内叫「拷问模式」,GitHub 上万星 Skill,是 Vibe Coding 场景的标杆级苏格拉底方案。

对你的想法逐个提问,揪隐藏假设、风险、边界,适用于绝大多数的 Vibe Coding 场景,一问一答,不会一次性轰炸,全部信息收集完毕,自动整理成一份规格文档。这个你可以打包带走。

其他两个方案

Symposium ​

仓库:Symposium(GitHub)

发散猜想→识别隐藏假设→收敛成可测试 Seed 规格文档。比 /grill-me 重,Token 消耗更高。了解即可,不用下载。

Ouroboros ​

它是完整 CLI+MCP 工具,不是单纯 Skill 包;ooo interview 是里面的苏格拉底访谈子命令。

适合中大型、长期迭代、偏工程化项目,需要完整闭环(访谈→编码→验收)。简单小项目会过度工程化,上手成本高。不用下载。

上面三个里面,只有 /grill-me 是你会使用的。我把另外两个也掏出来给你,是为了说明这个环节并不是可有可无,而是开发前的必要前提。

而对于不懂代码、编程的小白而言,「需求澄清」几乎是除了「授权 AI 开始动手」以外的,唯一需要做的事情。如果你不懂代码,也不打算学代码,那么应该做的,也只剩下把需求「提」清楚了。

需求澄清是必须的,苏格拉底提问不是

需求澄清的目的,是把需求提清楚,前面提到的 /grill-me 只是工具而已,它的设计思路是苏格拉底提问。

但苏格拉底提问不是万能的:

  • 如果需求极度简单,过多提问反而是拖累;
  • 使用者需要耐心回答问题,如果只想快速生成一段脚本,会觉得啰嗦;
  • 要警惕 AI 为了提问而提问!如果发现 AI 的问题明显越界,则要指出「你越界了,原因是 XXX」。注意不要批评,也不要带情绪,这些都是无用的 Token,而且有概率让 AI 变得保守。

而以上三点都建立在同一个能力之上:明确知道 AI 要完成的标准动作是什么,也就是说,你明确知道一条可行的工作流。

分享一个我自己总结的简单需求框架。如果你可以回答这个框架,那么你就可以不用浪费时间在做什么苏格拉底提问,直接复述你的需求即可(苏格拉底提问本质上也是说明白这个问题)。框架是:

需求三要素:什么角色,在什么场景下,做什么事情?

当你能完整、无歧义地描述清楚这三点,连带隐含的约束、异常情况都想到了,就无需反复追问,直接把需求交付 AI 执行。

我们举一个具体实例吧:

假设你想要一个定时发消息的小脚本。

【事情】:到点发一句固定文本到钉钉。 【角色】:青龙面板运行脚本。 【场景】:每天早上 9 点执行,只发一次,发失败不用重试。

整理好发给 AI:

textile
在 n8n 上写一个脚本,每天早上 9 点,发固定文字到钉钉。

信息齐了,AI 直接动手。

反过来,如果只写:

text
帮我写个发消息脚本。
  • 缺少角色:在哪跑?本地?还是什么环境?
  • 缺少场景:发到哪里?什么时候发?失败要不要重发?

同样是发消息脚本,跑在 n8n 和跑在本地,写法完全不一样。

所以三要素就是自检标尺:先用「角色 + 场景 + 事情」自查,信息够就直接开工;缺信息,再用苏格拉底提问接着问。

参考资料 ​

除特别声明外,本书内容采用 CC BY-NC-SA 4.0 授权