一句「我想做个东西」，里面藏着一百个没说的决定
你走到工程师面前，说：「我想做个能自动检测螺丝有没有拧到位的东西。」
你以为你说了一句话。其实你抛出了一个填空题，而且空白多得吓人：拧到位是拧到什么程度？靠看图片判断，还是靠听声音、测扭矩？漏检一颗和误报一颗，哪个更要命？光线暗了怎么办？螺丝生锈了算不算没拧到位？判断要多快，慢一秒能不能接受？
过去，这些空白是工程师替你填的。他们凭经验、凭猜测、凭「我觉得你应该是这个意思」把它填满——填对了是运气，填错了是你俩下个月的返工。现在你要用 AI 独立落地一个产品，AI 也会替你填这些空。区别在于：AI 填得比人更快、更自信、而且绝不会停下来问你一句「你确定吗」。
模糊的需求，进去的是「差不多」，出来的一定是「差很多」。而且 AI 会用一副胸有成竹的样子把「差很多」交给你，你还以为自己成功了。
Garbage in, garbage out：这句老话在 AI 时代重新长了牙
Garbage in, garbage out（垃圾进、垃圾出）是句计算机领域的老话：喂进去的是烂输入，吐出来的必然是烂结果，机器不会替你把烂的变好。
以前这话主要说数据。现在它多了一层意思：你给 AI 的需求描述，本身就是一种输入。你说得模糊，AI 不会报错，它会自动脑补一个版本，然后一本正经地把这个脑补出来的东西做出来给你。
打个比方。你叫一个手脚极快但完全不认识你的临时工去仓库「把那些坏了的箱子扔掉」。他不会问你「哪些算坏」，他会按自己的理解，十分钟内扔掉一半库存，动作麻利，态度积极，结果是灾难。AI 就是这个临时工——快、勤快、绝对服从，但你没说清的地方，它全凭自己拿主意。
所以在 AI 时代，一个残酷又美妙的事实浮出水面：你把需求说清楚的能力，直接决定了 AI 给你的是产品还是垃圾。而「把需求说清楚」，恰好是产品经理的看家本领，不是程序员的。
为什么这件事，PM 比程序员更该干、也更擅长
很多人以为，AI 时代产品经理会贬值，因为「写代码这道墙塌了」。恰恰相反。墙塌了，露出来的是更值钱的东西。
想想一条流水线的分工。程序员擅长的是「怎么把一件明确的事做出来」——给定规格，他能实现。而产品经理擅长的是另一件事：决定到底要做哪件事，以及那件事长什么样才算对。过去这两件事被打包在一个团队里，界限模糊。现在 AI 把「实现」这一半几乎免费地包了，剩下没被包掉的那一半——想清楚要什么、说清楚要什么——反而成了整个链条里最稀缺的环节。
这就是本章要教你的唯一一件事：怎么把一句模糊的意图，逼成一份机器能一步步执行的规格。
注意：这一章不讲计算机怎么运转（那是下一章的事）。这一章只讲一件更靠前的事——怎么想清楚、怎么把想的东西表达成 AI 能照着做的样子。你可以完全不懂代码，照样把这件事做到极致。
规格是什么：一份让「对不对」有答案的说明书
规格（specification，常简称 spec）就是一份把「我要什么」写死的说明书。它的核心不是华丽，而是让每一处都有唯一答案，不给脑补留缝隙。
一份能用的工业规格，至少要把五件事钉死：
- 输入：AI 拿到的到底是什么。一张什么分辨率、什么角度、什么光照下拍的图？还是一串传感器数字？多久来一次？
- 输出：它要吐出什么。是「合格 / 不合格」两个字，还是一个 0 到 1 的分数，还是标出缺陷在图上的哪个位置？给谁看，给谁用？
- 边界：它管到哪儿为止。哪些情况归它判，哪些情况它该直接说「这个我不管」而不是硬猜。
- 异常：不正常的时候怎么办。图糊了、传感器断了、来了个它从没见过的东西——它该报警、该停、还是该装没事？
- 验收标准：怎么算做成了。用什么数字、什么条件来判定「这活儿合格」，而且这个判定不靠你心情。
其中两个词值得单独盯一下，因为它们是新手最容易漏、老手最先想的地方。
边界情况：真实世界总在犄角旮旯里给你惊喜
边界情况（edge case）指那些不常见、但一定会发生的极端或临界情形。正常的螺丝好判，难的是那些卡在中间的：拧了一半的、拧歪的、滑丝的、被油污盖住看不清的、根本没有螺丝孔却硬要检测的。
为什么它重要？因为一个系统在 95% 的正常情况下表现好，是没有意义的——产线出事，几乎全出在那 5% 上。你不主动把这些角落想出来写进规格，AI 就会默认它们不存在，然后在某个深夜的产线上,让它们以最贵的方式冒出来。
验收标准：把「差不多得了」翻译成「达标 / 不达标」
验收标准（acceptance criteria）是一句能用「是」或「否」回答的话，用来判定活儿有没有做成。
「检测得准一点」不是验收标准，它是废话——多准算准？谁说了算？
「在标准产线光照下，对拧到位的螺丝，1000 次里漏判不超过 3 次，误判不超过 10 次，单次判断不超过 200 毫秒」——这才是验收标准。它把一个含糊的愿望，变成了一把有刻度的尺子。有了这把尺子，你、AI、以及未来质疑你的老板，才能对着同一个东西说话。
实操：把一句话逼成一份规格
回到开头那句「我想做个能自动检测螺丝有没有拧到位的东西」。我们不写代码，只用追问，把它一层层逼清楚。追问的诀窍很简单——每问一句，都堵死一种脑补。
- 逼输入：靠什么判断？——决定用工业相机在螺丝正上方 20 厘米、固定环形光下拍一张 1200×1200 的图。这样「靠听声音」「侧着拍」这些歧义就被堵死了。
- 逼输出：要什么结果？——每颗螺丝给一个「合格 / 不合格 / 不确定」，外加一个 0 到 1 的把握分。留一个「不确定」的口子，是为了别逼它在没底的时候瞎猜。
- 逼边界：什么归它管？——只判「已经装上、且螺帽完整可见」的螺丝。没装的、被完全遮住的，直接归到「不确定」，交给人。
- 逼异常：坏了怎么办？——图像过曝、相机没返回、把握分低于 0.6，一律不给结论，亮黄灯叫人来看，绝不硬判成合格。
- 逼验收：怎么算成？——用 500 张事先由老师傅标好答案的图来考它，这 500 张里漏判（该拦没拦）必须为 0，误判（好的判成坏的）容忍到 2%，单张耗时不超过 200 毫秒。达标才上线。（注意：500 张全过，不等于真实产线上永不漏判——它只是把你敢上线的底线量化了，后面第十三章会讲怎么在真产线上继续盯漏判率。）
看，同样一句话，追问前是一团意图，追问后是一张任务清单。这张清单，就是你交给 AI 的prompt（对 AI 下达的指令）的骨架——所以说，需求即 prompt，规格即架构：你把需求想到多清楚，AI 就能把系统搭到多清楚，一分不多。
你会发现，逼这五个问题的过程里，你一行代码都没碰，却已经做完了整个产品最难、最值钱的那部分——决定这东西到底该是什么样。剩下的「怎么实现」，才是从下一章开始，你和 AI 一起补的功课。
不会写规格，AI 给你的就是一堆自信的错东西。会写规格，AI 才成为你手里那条真正的产线。这两者之间隔着的，不是编程能力，是你愿不愿意把每一个「差不多」，都逼成一个「就是它」。