上一章讲"怎么问",这一章讲"问什么"。项目真正的难点,不在 AI 写得快不快,而在你能不能把要什么说清楚。
一个反直觉的事实
人们对 AI 编程最大的误解,是以为难在"写代码"。恰恰相反——Vibe Coding 不需要你写任何代码,很多人做不好,根子上是没把东西讲清楚。一旦需求写好了,这个产品 AI 基本就能帮你做出来。
"最难的不是写提示词,
是怎么定义问题。"
道理回到第一章:你只管说清"要什么",AI 负责"怎么做"。但"说清要什么"本身是门功夫。很多同学在项目里花大量时间反复改代码,根子上是起初需求描述不清楚。
AI 一旦得靠猜,就容易错。你含糊一分,它就替你脑补一分,脑补的方向多半不是你要的。需求澄清的全部意义,就是把它要猜的地方,提前替它说清。
不用学复杂模板
一份好需求 = 四个问题
一份能让 AI 一次做对的需求,回答清楚这四件事就够了。
用户是谁?在什么场景下用?
说不清:AI 按"平均用户"做,谁都不合适。
解决什么痛点?动机是什么?
说不清:AI 抓不到重点,堆一堆没用的功能。
具体要它做出什么?
说不清:AI 自由发挥,方向跑偏。
验收标准——满足什么条件才算成?
最常被漏掉、却最重要:没有它,你和 AI 都不知道何时该停。
"PRD 你一定得自己看、自己写。
你描述得越细,它做出来的东西就越精确。"需求是给你自己用的,不是写给别人交差的。细一分,准一分。
最贵的错误
真需求 vs 伪需求
最贵的错误不是把需求写得粗,而是把一个根本不存在的需求当真需求做。伪需求最典型的来源,是"设计者坐在屋里凭同理心想象用户要什么"。

"评判一个项目,顺序永远是:
①洞察是否真实 → ②方案是否可行 → ③才轮到技术。""-1 天悖论":先有方案、再去找需求来套,是大忌。
还有一个常见坑:用抽象群体名词描述需求——"弱势群体""罕见病""环保"。这些词打动不了任何人,也帮不了你定义需求。Day1 的产出物,就压缩成一句话:
"为 [具体的谁] 解决 [具体的什么问题]。"
先打这一颗钉子,别急着画完整的方案地图。
写代码的人有个错误本能
改偏了,别硬补——
重整需求再来
东西做出来不对,就在原来的基础上一点点修——在 AI 协作里,这个本能往往是错的。东西做偏,根因通常不在 AI 手抖,而在你最初的需求就没说清。地基歪了,在歪地基上修补,只会越补越乱。
"推翻重来比修改容易。
最好的办法是:你先梳理一下,
我刚才那些需求到底是什么。"
橘子让 AI 把四张会议图做成可视化动画,第一版"有点东西但远远不够"。复盘发现,是两个逻辑点她自己都没理清——各阶段目标和协作密度的关系、各目标之间的关系。
不是 AI 不行,是人没想清楚逻辑。与其让它在没想清的基础上反复改,不如先把逻辑理顺,重整需求再来。
最好的需求是被问出来的
让 AI 先反问,
再动手
最好的需求,往往不是你一次写出来的,是被问出来的。正确的开场不是"帮我做个 X",而是先把背景上下文铺给它,然后说:"先别动手。你先列出几个观点,以及有哪些需要我确认的事项。"
把"先反问澄清、再动手"
固化成一个需求澄清 skill。回扣第三章:把"流程"也装进 AI 的环境里,让好习惯变成默认动作,而不是靠你每次记得提醒它。
一个更大的判断
这甚至未必是
"AI 培训"
"这件事不应被定义成普通的 AI 工具培训,
而应被定义成AI 时代的自主组织能力训练。"
教 AI 怎么用,工具会过时;真正在练的,是把模糊想清、把要什么说明白的能力。这正是"道法术器"里"法"的分量——工具(术、器)会变,定义问题、说清需求的功夫,是迁移到任何工具上都还在的底层能力。你现在练的,就是这个。
下一章进入"器"——把前面说清的需求,用 Vibe Coding 真正做出一个能用的东西。