作者 Ravi Mehta 用自己的职业生涯开场:在他的整个职业生涯里,spec 变得越写越短。刚入行在 微软 时,一个 PM(产品经理)的价值是「按 spec 的分量来衡量的」——文档越厚重,越显得专业。多年之后在 Tripadvisor,团队里被传为佳话的反而是那位把 spec 潦草写在一张餐巾纸上、就直接带去产品评审会(Product Review)的 PM。
产品团队普遍把规格说明书当成一种文书作业(paperwork)——是开始「真正工作」(发布产品)之前不得不应付的必要之恶。工程师因优雅的代码受到赞誉,设计师因漂亮的用户体验受到赞誉,PM 因交付业务影响而获得称赞。但 spec 呢?通常是匆匆写完、随手丢开、很快被遗忘。
完美无瑕的执行是优秀产品管理的根基,而一份出色的 spec 就是起跑线。 Flawless execution is the foundation of good product management, and a great spec is the starting line.
而今天,构建产品的方式正在发生转变:工程师变快了——快得多。AI 可以在几分钟内把粗糙的想法变成能运行的代码。瓶颈不再是「构建」本身,而是知道要构建什么,并让团队围绕这些需求对齐。
于是,这份不起眼的规格说明书突然不再是转瞬即弃的文书。它是产品管理的根基——它正在成为源代码本身。
吴恩达(Andrew Ng)在他最近的演讲 Building Faster with AI 中提到了一个前所未有的趋势:
这印证了作者在上一篇文章中的预测:当工程师借助 AI 以数倍速度交付时,公司需要更多而不是更少的 PM,来支撑这些高产的工程师。
随着产品交付不断加速,巨大的压力被转移到产品管理的其他每一个环节上——理解客户需求、打磨正确的功能、验证实际影响。而所有这些压力,最终都汇聚到同一个产物上——spec。
要理解这个标题里的比喻,先要弄清传统软件开发里「源代码」和「目标代码」的关系。
在传统软件开发中,程序员编写人类可读的「源代码(source code)」,再由编译器把它编译成高度优化、机器可读的「目标代码(object code)」,也叫二进制文件(binary)。
目标代码只是一个副产品——只要有源代码,随时可以重新编译生成它。所以源代码才是字面意义上的事实来源(source of truth):它包含注释、结构、文档,承载了理解和修改这个系统所需的一切;二进制只是下游产物。
(增补例子)你不会小心翼翼地备份一个编译出来的 .exe 文件、却把写它的工程文件删掉——丢了源码,程序就成了没人能看懂、没法改的黑盒。
来自 OpenAI 的 Sean Grove 在他最近的演讲 The New Code 中提出了一个颇具挑衅性的论点:一份写得好的提示词(prompt)——也就是 spec——才是新的源代码。
从这个视角看,我们现在做 AI 开发的方式是彻底反过来的:我们精心撰写提示词,向模型传达意图;AI 生成代码;然后我们把代码留下来,把提示词扔掉。
仔细想想这句话。在传统编程中,源代码是神圣的——它包含注释、结构与文档,是理解和修改系统所需的一切;二进制只是下游产物。但在 AI 开发中,我们把这层关系翻转了:把生成出来的代码当成值得保存的产物,却把规格说明——那份 prompt——当成用完即弃的东西。
Grove 认为,代码——哪怕是优雅的代码——只是从规格说明「投影」出来的一个有损(lossy)版本:从 spec 到代码的转换过程中,信息丢失了。
原文用反编译作类比:就像把二进制反编译回代码时,拿不回原来的注释和变量名一样,阅读代码也无法告诉你它背后完整的意图。「为什么这么做」「权衡了什么」「价值取向是什么」——这些只存在于 spec 里。
(增补例子)看到一段限流代码,你能读懂「每秒最多 5 次请求」,但读不出「因为付费转化实验发现超过 5 次会伤害体验」这个决策理由——后者只写在 spec 里。
而规格说明书则包含一切。一份足够健壮的 spec 能生成什么?Grove 的原话是:
更重要的是,规格说明书能做到代码做不到的事情:让人类和机器在共同目标上对齐。Grove 说得很直白:
一份书面的规格说明能有效地对齐人类,它是你用来沟通、讨论、辩论、引用和同步的那个产物。 "A written specification effectively aligns humans and is the artifact that you use to communicate and discuss and debate and refer to and synchronize on." —— Sean Grove
他还给出了一个预测:
在不远的将来,沟通最有效的人就是最有价值的程序员。而且毫不夸张地说:只要你能有效沟通,你就能编程。 "In the near future, the person who communicates most effectively is the most valuable programmer. And literally, if you can communicate effectively, you can program." —— Sean Grove
直到不久之前,产品生命周期还必须从 spec 开始(或者叫 PRD、概念文档,甚至一张餐巾纸)——由它启动最初的线框图、设计、原型和 MVP 开发。
这种传统做法给人的感觉是一种必要之恶:工程师做出简陋的 MVP,只为把「随便什么东西」尽快塞到客户手里。「如果你不为产品的第一个版本感到尴尬,说明你发布得太晚了」(注:这句硅谷名言出自 LinkedIn 创始人 Reid Hoffman——此归属为增补说明,原文未点名)一度被奉为圭臬。
但我们构建产品的整套方式最近发生了重大转变。在这个新世界里,spec 往往是「产出」,而不是「输入」。
今天,你不需要发布一行代码,就能把原型送到客户手中。像 v0、Lovable、Replit 这样的工具,让你能在几小时(而不是几周)内搭出可运行的原型——完全不需要工程师参与。
这不只是「更快」——而是根本性的不同。带着一个「vibe coding(氛围编程)」出来的原型,你可以在写下 feature spec 的第一行字之前,就收集到真实的客户反馈:验证假设、迭代流程、打磨交互。
来看一个上手实操的例子。Danny Martinez 是 decimals 的创始人——这是一个仍处于隐身(stealth)阶段的平台,让创作者经济(creator economy)领域的专家能把自己人脉网络中的人才推荐安置到工作岗位上。
Danny 将展示他们的规格驱动开发(spec-driven development)流程。这套流程带来了两个影响:
下面交给 Danny——
Danny 最近处理的一个例子:他们的产品让专家型网红(expert influencers)能把自己网络中的候选人安置到工作岗位。在上线新落地页之后,需要给专家们一个快速获取自己页面链接的入口。联合创始人在 Slack 里发来这样一条消息:
我们需要在页头加一个按钮,指向 company-apply 页面。我现在正忙着搞邮件。这个是可以 vibe code 的,你能接一下吗? "We need a button in the header that directs to the company-apply page. I'm focused on the emails at the moment. This is vibe code-able if you can pick it up please." —— Danny 的联合创始人(Slack 消息)
就是一个简单的按钮——非常容易,而且恰恰是非技术背景的人如今可以自己发布上线的那类需求。
整个发布过程只用了几分钟。以下是完整步骤(原文配有 Loom 操作视频,括号内为视频时间戳):
把镜头拉远,这套配置的真正威力才显现出来。是的,这是个不起眼的例子,但要点仍然成立:一个非技术背景的人,现在只需向 Claude(通过 GitHub Copilot)发出几个提示,就能在 Linear 工单、代码库和工程师之间自由穿梭。而且再强调一次——这一切的关键不是代码本身:是 spec。
Danny 特别强调,上面的做法要运转良好,必须满足以下前提:
有了合适的配置,非技术背景的人为代码库做贡献是完全现实的期待。只要有足够的时间和耐心,你可以逐渐读懂代码库、亲自实现改动,而不是每次都指望 Claude 来救场。有朝一日,你甚至可以期待:你端着咖啡小口啜饮的工夫,一个 AI 智能体已经把你的工单做完发布了。
科幻作家威廉·吉布森(William Gibson)——「赛博空间(cyberspace)」一词的创造者——说过一句名言:
每当思考 AI 能做什么、还做不了什么时,作者就会想起这句话。今天,AI 带来的收益是极不均匀的:有些事情——生成代码、文本、图像——已经实现了飞跃,以「AI 速度」运转;而另一些事情——与客户交谈、发现他们的需求、说服他们购买——仍然以「人类速度」推进。
这种不均匀的分布正在重塑产品团队:聚光灯正从「实现类工作」转向「理解类工作」。那些一直以来区分顶尖 PM 的核心能力——理解用户需求、清晰地定义问题、设计优雅的解决方案——其价值已呈指数级放大。
最优秀的 PM 会把这些洞察转化为 spec——能对齐团队、指导实现、并在日益自动化的开发世界中长存的规格说明书。
| 术语 | 简释 |
|---|---|
| Spec / 规格说明书 | 描述「做什么、为什么做、做成什么样才算对」的文档,即 specification;PRD、概念文档都是它的变体。 |
| 源代码 / 目标代码 | 源代码是人写的、人可读的程序文本;编译后得到机器可执行的目标代码(二进制)。前者是源头,后者是可再生的副产品。 |
| 有损投影 | lossy projection——从 spec 生成代码的过程会丢失意图、理由等信息,就像反编译拿不回注释和变量名。 |
| PM | Product Manager,产品经理。 |
| PRD | Product Requirements Document,产品需求文档。 |
| MVP | Minimum Viable Product,最小可行产品——能拿去验证需求的最简版本。 |
| Vibe coding | 「氛围编程」——用自然语言向 AI 描述想要的效果、由 AI 生成代码的开发方式,写作者本人可以不懂代码。 |
| v0 / Lovable / Replit | 三款无需工程师即可快速搭建可运行原型的 AI 建站/编程工具。 |
| Linear | 一款项目管理 / 工单(ticket)追踪工具。 |
| MCP 服务器 | Model Context Protocol 服务器——让 AI 助手能直接连接并读写外部工具(如 Linear 工单)的标准接口。 |
| PR | Pull Request——把自己分支上的代码改动提请合入主代码库、供他人评审的请求。 |
| Copilot | GitHub Copilot,嵌在编辑器里的 AI 编程助手;文中通过它调用 Claude Sonnet 4 模型。 |