规范是新的源代码
原型是新规范，规范是新的....源代码？
在我的职业生涯中，规范变得越来越短。当我在微软开始时，PM 的价值是以他们规范的重量来衡量的。几年后，在 Tripadvisor，我们神话化了那个把规范——写在餐巾纸上——带到产品审查的 PM。
产品团队经常将规范视为文书工作——在"真正工作"交付之前的必要恶。工程师因优雅的代码而受到庆祝，设计师因美丽的 UX 而受到赞扬。PM 因交付影响而获得好评。但规范？它们通常被匆忙处理、丢弃、遗忘。
这总是个错误。在我的产品能力工具包中，功能规范位居首位——十二个能力中的第一个——是有原因的。它支撑着产品执行，连同产品交付和产品质量。
完美执行是良好产品管理的基础，而伟大的规范是起跑线。
今天，我们构建的方式正在转变。工程师正在变得更快——快得多。AI 可以在几分钟内将粗略的想法转变为可工作的代码。瓶颈不再是构建。而是知道要构建什么，以及让团队围绕这些要求达成一致。
突然，谦逊的规范不再是短暂的文书工作。它是产品管理的基础——它正在成为源代码本身。
为什么 PM 突然成为瓶颈
在他最近的演讲用 AI 更快地构建中，Andrew Ng 注意到了一个前所未有的趋势：
"我一生中第一次看到管理者向我提出拥有两倍于工程师数量的 PM。我仍然不知道这个提案是否是个好主意，但我认为这是世界走向的标志。" ——Andrew Ng
这验证了我们在我们之前的帖子中预测的：随着工程师使用 AI 的交付速度提高数倍，公司需要更多的 PM 来支持那些高效的工程师，而不是更少。
随着产品交付加速，这对产品管理的所有其他方面——理解客户需求、制作正确的功能、验证影响——施加了巨大压力。
而所有这些压力都集中在一个工件上——规范。
规范——新的源代码
在传统软件开发中，程序员编写人类可读的"源代码"，然后被编译成高度优化的、机器可读的"目标代码"。"目标代码"（也称为二进制文件）是可以用源代码重新创建的副产品。源代码是字面上的真实来源。
来自 OpenAI 的 Sean Grove 有一个挑衅性的论点。在他最近的演讲，新代码中，他认为一个写得好的提示（即规范）是新的源代码。
从这个角度看，我们在做 AI 开发 backwards。我们精心制作提示来向模型传达我们的意图。AI 生成代码。然后我们保留代码并丢弃提示。
"这感觉像你粉碎了源代码，然后非常仔细地版本控制二进制文件，"Grove 观察说。
想想那个。在传统编程中，源代码是神圣的。源代码包含注释、结构和文档——理解和修改系统所需的一切。二进制文件只是一个下游工件。
但有了 AI，我们翻转了这种关系。我们将生成的代码视为值得保留的工件，而将规范——提示——视为可丢弃的。
Grove 认为这完全搞错了。代码，即使是优雅的代码，是他所说的从规范的"有损投影"。就像反编译二进制文件不会给你原始注释和变量名一样，阅读代码不会告诉你它背后的全部意图。
然而，规范包含一切。一个足够强大的规范可以生成"好的 TypeScript、好的 Rust、服务器、客户端、文档、教程、博客文章，甚至播客"。
"一个足够强大的规范可以生成好的 TypeScript、好的 Rust、服务器、客户端、文档、教程、博客文章，甚至播客。" ——Sean Grove, OpenAI
更重要的是，规范做代码不能做的事情：它们将人类和机器在共同目标上对齐。Grove 简单地说："一个书面规范有效地对齐人类，是你用来沟通、讨论、辩论和同步的工件。"
他预测："在不久的将来，最有效沟通的人是最有价值的程序员。实际上，如果你能有效沟通，你就可以编程。"
新的稀缺技能不是编码。而是编写完全捕获意图和价值的规范。
对于产品经理来说，这应该听起来很熟悉。这是我们一直在做的——只是现在机器也在听。
等等，原型不是杀死了规范吗？
直到最近，产品生命周期必须从规范（或 PRD 或概念文档或餐巾纸）开始，这推动了初始线框图、设计、原型和 MVP 开发。
传统方法感觉像是一个必要的恶。工程师构建基本的 MVP 以将某些东西——任何东西——送到客户手中。"如果你不为产品的第一个版本感到尴尬，你发布得太晚了"成为了福音。
我们的整个产品构建方法最近经历了重大转变，在这个新世界中，规范通常是输出，而不是输入。
今天，你不需要交付单行代码就能将原型送到客户手中。像 v0、Lovable 和 Replit 这样的工具让你在几小时而不是几周内构建可工作的原型。不需要工程。
这不仅更快——它根本不同。有了"氛围编码"的原型，你可以在编写功能规范的单行代码之前收集真实的客户反馈。你可以测试假设、迭代流程、完善交互。
- 旧工作流程看起来像这样：模糊想法 → 线框图 → 设计 → 工程师构建的 MVP → 客户反馈 → 痛苦的规范修订 → 线框图 → 设计 → 重建 → 祈祷。
- 新工作流程：模糊想法 → 快速原型 → 客户反馈 → 水晶般清晰的规范 → AI 辅助实施。
原型没有杀死规范。它们让规范变得更好。
规范驱动开发在行动
让我们看看这一切如何发挥的实际例子。Danny Martinez 是 decimals 的创始人，一个（隐秘中）让创作者经济中的专家将他们网络中的人才安排到工作中的平台。
Danny 将向我们介绍他们的规范驱动开发过程——这个过程产生了两个影响：
- 大大改进了与工程团队的沟通，针对更大的功能，以及
- 使 Danny 尽管没有先前的编码经验，能够直接从详细规范到为较小的东西提供实时功能。
以下是 Danny 的陈述……
这是我最近处理的一个例子。作为背景，我们正在构建一个让专家影响者将他们网络中的候选人安排到工作中的产品。在发布新的着陆页后，我们需要给我们的专家一个快速访问他们自己页面链接的方法。
我们需要标题中的一个按钮，指向 company-apply 页面。我目前专注于电子邮件。如果你能接手，这是可以氛围编码的。
这是我来自联合创始人的消息，指的是一个需要交付的简单按钮。足够容易，正好是非技术人员现在可以自己处理的那种事情。
这是这在大约几分钟内完成的设置和步骤：
- 项目管理工具：Linear
- IDE：VS Code
- 扩展：GitHub Copilot Pro
- 模型：Claude Sonnet 4
- MCP 服务器：Linear MCP 服务器允许通过 Copilot 访问 Linear 工单
让我们看看过程中的步骤：
- 从我联合创始人的 Slack 消息生成 Linear 工单
- 在上面的工单中澄清我想要的新副本
- 打开 Copilot 并提示 Claude 打开 Linear 工单
- 提示 Claude 审查工单并相对于代码库分析它
- 提示 Claude 创建分支并实施这些更改
- 测试更改以确保它们按预期工作
- 在 GitHub 上打开拉取请求 (PR) 以将这些更改交付到代码库中
- 等待工程师审查/批准 PR
放大来看，这种设置的真正力量就显现出来了。是的，这是一个微不足道的例子，但重点仍然存在：一个非技术人员现在可以在 Linear 工单、代码库和工程师之间切换，所有这些只需给 Claude 通过 GitHub Copilot 发送几个提示。
再次强调，所有这一切的关键部分不是代码本身：它是规范。
现在，重要的是对此进行说明其有效所需的条件：
- 具体化：使用模糊规范只会导致混乱的代码库。使用 Claude 获取工单的初稿、审查代码库并帮助使其更具体是过程的重要组成部分。在我们的情况下，我们也有编写好规范的指导方针。
- 选择性：对较简单的任务使用上述方法是最理想的。工单越复杂，需要知道他们在做什么的人参与的需求越大（在这些情况下，"自助服务"最终根本不是）。
- 守门：这种方法效果很好只是因为有一个实际知道他们在做什么的工程师在审查更改并确保简单性和功能之间的平衡得到维持。
但让我们清楚：规则已经改变。规范是每个人构建产品的真实来源，包括 LLM。
有了正确的设置，期望作为非技术人员为代码库做出贡献是完全现实的。有足够的时间和耐心，你可以开始理解代码库并自己实施更改，而不是简单地每次都依赖 Claude 来救你。
有一天，你甚至可能期望 AI 代理在你喝咖啡时交付你的工单。
如果你是 PM 并且担心 AI 会对你的工作做什么，关键是意识到工作本身在改变。但这对其他人也是如此。优秀 PM 所需的核心技能在这个新世界中更有价值。
规范万岁！
William Gibson，创造了"赛博空间"一词的科幻作家，曾经说过：
未来已经在这里——只是没有非常均匀地分布。
当我想到 AI 能做什么和不能做什么时，我想起了这句话。今天，AI 的收益是深刻不均匀的。一些事情——生成代码、文本、图像——已经实现了量子飞跃。它们以 AI 速度运行。其他事情——与客户交谈、发现他们的需求、说服他们购买——仍然以人类速度移动。
这种不均匀分布正在重塑产品团队。聚光灯正从实施工作转移到理解工作。一直将最佳 PM 区分开来的核心技能——理解用户需求、明确定义问题、设计优雅的解决方案——已经变得指数级更有价值。
最佳 PM 将这些洞察转化为规范——对齐团队、指导实施，并作为日益自动化开发世界中持久的工件。