Concept / Critique
spec 是验收单,不是立项书
你老听人说 spec spec 的,它跟你熟的 PRD 到底一不一样?——不是一回事,但沾亲。PRD 回答"为什么做、做什么"(立项书),spec 回答"做成啥样算对、怎么验"(验收单)。经典软件工程里 spec 在 PRD 下面一层;而我前几篇老提的"AI 时代的 spec",是把它俩压扁成的一份轻量文档——所以你才觉得乱。
先各自认人,再摆一块儿比
咱们先把 spec 这个词单独拎出来看清楚,再看 PRD 是干嘛的,然后把俩摆一块儿对比——橙色那站直接回答你"是不是一回事";最后说说为什么 AI 一来,这俩的界限突然糊了,你被绕进去其实情有可原。
spec 到底是个啥
spec 是 specification 的缩写,中文叫"规格说明"。说白了,它就是一份把"要做的东西"描述清楚的文档——精确到既讲功能上要满足啥、也讲技术上要满足啥1。它的本职是给开发的人当一份"照着这个做"的参照,免得大家各想各的、最后做拧了1。
但你别被"一份文档"这话骗了,以为它就是随便写写。spec 里头最值钱的一块,是验收标准(acceptance criteria)。这玩意儿才是 spec 的灵魂:它把"做得对不对"从一件靠感觉的事,变成一件能客观判定的事4。
有句话我觉得说得特别狠,你记住它就懂 spec 一半了:每条验收标准,都应该是一条你能跑的命令——能 跑测试、能 发个请求看返回、能 搜一下有没有。要是你写的那条根本没法跑、没法验,那它就不是标准,只是个"意见"4。
"用户能上传 JPEG 或 PNG 图片,最大 10MB;存到 S3,key 用 user-ID 打头;只有上传者本人能删自己的图;上传时图片压到最长边 1024px。"4 你看,这就是 spec 的口吻——每一句都能拿去验:传个 11MB 的试试拒不拒、传 JPEG 看存没存对、换个账号看删不删得掉。这种"可验证"的具体,就是 spec 跟"想法"的分界线。
记住这一句:spec 不是"我想要个搜索功能"这种话,是"输入'会议'要秒出所有含'会议'的笔记、空输入恢复全部"这种能逐条验收的话。
那 PRD 又是个啥
你说 PRD 这名字唬人,其实拆开就好懂——Product Requirements Document,产品需求文档。它装的是一个产品(或一个功能)该做什么的所有需求,写出来就为了让一屋子人都明白"这东西到底要干嘛"2。
这里有个关键的讲究,是 PRD 的立身之本:PRD 一般刻意不去说"怎么实现"。它讲目的、讲用户是谁、讲要解决什么问题、讲成功的标准是啥、讲业务目标——但把"具体怎么做"的空间,留给后面的设计师和工程师拿专业去填2。
为什么呢?因为 PRD 主要是产品经理写的,他要拉着一堆人(老板、设计、工程、市场)对齐"我们为啥做这个、做出来长什么样"2。它是一份对齐共识、给项目立项的东西——回答的是"为什么做"和"做什么"这两个 W,基本不碰"怎么做"那个 H。
"PRD 不就是把功能列详细点嘛,跟 spec 不就是粗细之分?"——你以为只是粗细,其实是问题不同。PRD 答的是 why/what(为什么值得做、做什么),它甚至故意躲开 how;spec 答的是 how/对不对(怎么实现、做成啥样算对)。一个是立项书,一个是验收单,不是同一份文档写粗写细的问题。
记住这一句:PRD 讲"为什么做、做什么",而且故意不讲"怎么做"——它是拉人对齐、给项目立项用的,不是给你照着写代码用的。
摆一块儿:到底是不是一回事
好,正面回答你:不是一回事。经典软件工程里,这俩是上下游两层——PRD 在上,spec 在下,spec 接着 PRD 往下落地3。一个讲为什么和做什么,一个讲怎么做和怎么验。摆张表你就一目了然:
| 看点 | PRD(产品需求文档) | spec(规格说明) |
|---|---|---|
| 回答的问题 | 为什么做 / 做什么 | 怎么做 / 做成啥样算对 |
| 刻意躲开 | 故意不说"怎么实现" | 恰恰要把"怎么实现"说清 |
| 典型谁写 | 产品经理 | 工程师 / 技术负责人 |
| 给谁看 | 老板 / 设计 / 工程 / 市场,对齐共识 | 开发者,照着落地 |
| 核心价值 | 立项、对齐"做这个值不值" | 验收、让"对不对"可客观判定 |
| 层级 | 上游(先有) | 下游(接着 PRD 落) |
打个比方你就忘不了:你要盖个房子。PRD 是跟客户敲定的需求书——三室两厅、朝南、给一家四口住、预算多少;它不画图纸。spec 是施工图加验收单——这面墙多厚、用什么标号的混凝土、验收时拿什么尺子量、量到什么数算合格。需求书定"为什么这么盖",施工图定"怎么盖、怎么算盖对了"。
下面四句话,你判断各自是 PRD 的口吻还是 spec 的口吻:
A. "我们要降低新用户的流失,做个引导流程。"→ ?
B. "引导第一屏点'下一步',要在 300ms 内切到第二屏,失败则弹 toast。"→ ?
C. "目标用户是第一次用的小白,核心痛点是不知道从哪开始。"→ ?
D. "进度存 localStorage,key 为 onboarding_step,刷新后能恢复到上次那步。"→ ?
对答案
A = PRD(讲为什么做:降流失)。B = spec(可验收:300ms、失败弹 toast,能拿秒表和测试卡)。C = PRD(讲用户是谁、什么痛点)。D = spec(讲具体怎么实现 + 怎么验:刷新看恢不恢复)。判别诀窍:这句话能不能拿去"跑一下验对错"?能,就是 spec;只是说清"为啥/给谁",就是 PRD。
不过话说回来,现实里这俩经常不分得那么干净,中间还塞着"功能规格 / 技术规格"这些过渡层,小团队也常把它们揉一份里写3。所以你会在不同人嘴里听到 spec 指代不同精细度的东西——这正常,别纠结术语洁癖,抓住"它在答 how 还是答 why"这个核就行。
记住这一句:PRD 在上、spec 在下,一个定"做这个值不值",一个定"怎么做、怎么算做对了"——粗细是表象,问的问题不同才是本质。
为啥 AI 一来,这俩就糊了
你会犯迷糊,真不全怪你。因为我前几篇老说的"写个 spec 再让 AI 干活",那个 spec 跟经典软件工程里的 spec,不完全是同一个东西——它是 AI 时代被重新组装过的一个轻量版。
怎么个轻量法?现在 AI 编程语境里说的"spec",常常是把 PRD 的一小部分(目标、要做什么)+ 经典 spec(约束、验收标准)压扁成的一份文档:一个简短的总览、要做什么、有什么约束、怎么算做完5。它不像企业里那种几十页、分 PRD / 功能规格 / 技术规格好几层的重家伙,而是你一个人花十分钟写给 AI(和你自己)看的一页纸。
有人会说:"那 AI 时代的 spec 不就等于一份小号 PRD 嘛,你前面还说它俩不是一回事?"——这话有一半对:AI 时代的 spec 确实吸收了 PRD 的'做什么'。但我仍然说它本质更像 spec,原因是:它的重心和灵魂在"验收标准"——能让 AI 自己跑、自己验、你能客观判对错的那部分4。PRD 恰恰刻意不碰这块。所以它是"借了 PRD 一个角的 spec",不是"缩水的 PRD"。
还有一点是经典 PRD 没强调、AI 时代特别要紧的:spec 要当"活文档"养着。你跟 AI 边做边改了数据模型、砍了个功能,就得回头把 spec 同步上,让它始终是那份"唯一可信的底"5。它不是写完归档的立项书,是一份你一直在动的施工图。
记住这一句:你前几篇听到的"spec",是 AI 时代把 PRD 的'做什么'和经典 spec 的'验收标准'揉成的一页活文档——灵魂还是"可验收",所以它姓 spec,不姓 PRD。
不是一回事:一个立项,一个验收
把话收齐。spec(规格说明)和 PRD(产品需求文档)不是一回事,但是亲戚、还是上下游。PRD 在上游,产品经理写,回答"为什么做、做什么",刻意躲开"怎么做",用来拉一屋子人对齐、给项目立项——它是立项书。spec 在下游,工程师写,回答"怎么做、做成啥样算对",灵魂是那一条条能跑能验的验收标准——它是验收单。盖房子打比方:PRD 是跟客户敲定的需求书,spec 是施工图加验收单。
那你前几篇老听我说的"写 spec 再让 AI 干",为啥又像 PRD?因为 AI 时代的 spec 是个轻量合并体,借了 PRD 的"做什么"一个角,但重心仍压在"可验收"上,所以它本质姓 spec。
那这套什么时候不必较真呢?——你一个人做周末小项目,根本不用分 PRD/spec 两份,写一页"做啥 + 边界 + 怎么算做完"就够。那一页你叫它 spec 也行、叫它迷你 PRD 也行,别被术语绊住。术语是给协作对齐用的;只要你那页纸里有"能跑去验对错"的标准,你就抓住了 spec 真正值钱的地方。
这些地方我说实话也没全把握
- "spec"这个词在业界用得很乱。有人拿它专指技术规格,有人拿它泛指任何需求文档,还有人(尤其 AI 圈)拿它指那份合并体。我给的是主流分层,但你碰到具体某人时,最好问一句"你说的 spec 具体指哪层"。
- PRD 和 spec 的边界,不同公司画得不一样。大厂分得细(PRD / 功能规格 / 技术规格 / 设计文档好几层),小团队常揉成一两份。我讲的是"典型分工",不是放之四海的铁律。
- "AI 时代 spec = PRD一角 + 经典spec"这个拆法,是我的归纳。方向我有把握(它确实以验收标准为核),但这个具体的"合并体"说法是我帮你理解用的框架,不是某个标准定义。
读完盖住,试着答这几题
用一句话说清 PRD 和 spec 各自回答什么问题。
试着先答
PRD 回答"为什么做、做什么"(立项书),刻意不碰怎么做;spec 回答"怎么做、做成啥样算对"(验收单),灵魂是可跑可验的验收标准。
spec 里最值钱的一块是什么?判断它合不合格的那条狠话怎么说?
试着先答
最值钱的是验收标准(acceptance criteria)。狠话:每条标准都该是一条你能跑的命令(能跑测试/发请求/搜一下);跑不了、验不了的,不是标准,只是意见。
"PRD 跟 spec 只是详细程度不同"——这话哪儿错了?
试着先答
错在把"问题不同"当成"粗细不同"。PRD 答 why/what 且故意躲开 how;spec 答 how 且要求可验收。不是同一份东西写粗写细,是两种回答不同问题的文档。
应用题:"购物车里删除商品后,总价要实时更新,删空时显示'购物车为空'。"——这是 PRD 口吻还是 spec 口吻?为什么?
试着先答
spec 口吻。因为它可逐条验收:删一件看总价变没变、删到空看提示出没出。能拿去"跑一下验对错",就是 spec。(若改成"我们要让购物车体验更顺畅",那才是 PRD。)
为什么 AI 时代的"spec"会让你觉得它像 PRD?它到底姓啥?
试着先答
因为它是个轻量合并体,借了 PRD 的"做什么"一个角。但它重心和灵魂仍在"可验收标准",这恰是 PRD 刻意不碰的,所以它本质姓 spec,不姓 PRD。
把这几题截图,过两三天再凭记忆答一遍 —— 记得住才算真学会。
Sources
- Software requirements specification(SRS 定义,Wikipedia) — https://en.wikipedia.org/wiki/Software_requirements_specification
- What is a Product Requirements Document (PRD)?(Atlassian) — https://www.atlassian.com/agile/product-management/requirements
- PRD vs Product Spec: Key Differences & When to Use Each(Productboard) — https://www.productboard.com/glossary/prd-vs-product-spec/
- Addy Osmani — How to write a good spec for AI agents(验收标准即可跑命令) — https://addyosmani.com/blog/good-spec/
- Spec-driven development with AI: a new open source toolkit(GitHub Blog,spec 作为活文档) — https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/