核心观点
AI大幅加速工程交付，产品管理的瓶颈已经从“如何构建”变成“要构建什么”以及“如何让团队围绕需求达成共识”。高质量的规范（specs）正从可有可无的文书，转变为团队与模型共享意图的新型“源代码”；原型工具并未取代规范,反而通过快速验证让规范更清晰，催生规范驱动开发流程，提高沟通效率并扩大非技术人员参与产品建设的可能性。
精华速览
▸ 优秀的规范能同时对齐人类团队和AI，成为比代码更重要的知识载体。
▸ 当前的实践常把生成的代码当成最终产物，而把提示/规范丢弃，这在本质上是"把源代码撕毁，只保留二进制"。
▸ 规范包含意图、价值观与实现边界，是能生成多种产物（代码、文档、教程等）的单一真相。
▸ 快速原型工具（如v0、Lovable、Replit）让团队在不写代码的情况下获取真实用户反馈，从而将规范作为输出而非输入。
▸ 规范驱动开发能让非技术人员在合适的工具与监督下直接对代码库做出变更，提高迭代速度和沟通效率。
▸ 要使规范驱动流程成功，需要让规范更加具体、选择性使用（复杂任务仍需专家介入）以及工程师的把关与审查。
▸ 随着实现速度的不均衡增长，理解用户与清晰传达问题的能力成为最稀缺的技能。
▸ 产品经理的核心能力（发现需求、定义问题、设计方案）在AI时代反而更加重要，规范是这些能力的载体。
以下为原文翻译，略有删减，阅读需要10分钟。
在我职业生涯中，产品规格说明（Specs）越来越短。初入微软时，产品经理的价值还以规格书的厚度衡量。多年后在Tripadvisor，我们曾神化那位带着餐巾纸草稿参加产品评审的PM。
产品团队常将规格说明视为文书工作——是发布产品前必须完成的"必要之恶"(a necessary evil)。工程师因优雅的代码受到赞誉，设计师因精美的用户体验获得认可。产品经理则因创造价值而备受称道。但规格说明呢？它们通常被匆匆草草处理，被抛在一边，被遗忘。
这其实是个错误。在我的产品能力工具包中，规格说明始终位居首位，在十二项能力中排名第一。这不是偶然，它与产品交付和产品质量共同构成了产品执行的基石。
无懈可击的执行力是优秀产品管理的基础，而精良的功能规格则是起跑线。
如今，我们的软件开发方式正在发生转变。工程师们变得越来越快，AI能在几分钟内将粗略构想转化为可运行的代码。瓶颈不再是开发本身，而是明确构建目标，并让团队围绕这些需求达成共识。
正因如此，不起眼的规格说明不再是转瞬即逝的文书工作。它已成为产品管理的基础，并逐渐演变为源代码本身。
为什么PM突然成了瓶颈？
在吴恩达《用人工智能加速软件开发》（Building Faster with AI）的演讲中，他提到了一个前所未有的趋势：我人生中第一次看到，有管理者建议PM的数量是工程师的两倍，我不知道这个提议是否好，但我认为这是世界发展的一个标志。
（图：吴恩达演讲图）
这验证了我们在之前的文章中的预测：随着工程师通过AI交付的速度提高数倍，公司需要更多的PM来支持这些高效的工程师，而不是更少。
随着产品交付加速，这给产品管理的各个方面带来了巨大的压力——了解客户需求、制定正确的功能、验证影响。而所有这些压力都集中在一个工件上——规格说明（Specs）。
规格说明书——新的源代码
在传统软件开发中，程序员编写人类可读的“源代码”，经编译后生成高度优化的机器可读“目标代码”。“目标代码”（亦称二进制代码）是可通过源代码重新生成的副产品。源代码才是真正的真理之源。
OpenAI的肖恩·格罗夫提出了一个发人深省的论点。在其演讲《新代码》（The New Code）中，他认为，精心设计的提示词（如需求规格说明）才是新的源代码。
从这个角度看，人类正在用相反的方式使用AI：我们精心设计提示词，向模型传达意图，AI生成代码后，我们却将代码保留、将提示词丢弃。
“这就好比你先粉碎源代码，再对二进制文件进行精细的版本控制”，格罗夫说道。
试想一下，在传统编程中，源代码是神圣的。源代码包含注释、结构和文档——理解和修改系统所需的一切。二进制文件只是下游的产物。
但在人工智能领域，我们颠倒了这种关系。我们把生成的代码视为值得保留的产物，而把规范，即提示词，视为可抛弃的。
格罗夫认为，这种说法完全颠倒了因果关系。代码，即使是优雅的代码，在他看来也只是规格说明的一种“有损投影”（lossy projection）。就像反编译一个二进制文件不会给你原始的注释和变量名一样，阅读代码也不会告诉你代码背后的全部意图。
然而，规格说明包含了所有内容。一个足够强大的规格说明可以生成"好的TypeScript、好的Rust、服务器、客户端、文档、教程、博客文章，甚至播客"。
更重要的是，规格说明能做到代码无法实现的事：它们使人类与机器在共同目标上达成一致。格罗夫对此的表述简明扼要："书面规格说明能有效协调人类，是用于沟通、讨论、辩论、参考和同步的工具。"
他预测：“在不久的将来，最懂有效沟通的人将是最有价值的程序员。实际上，如果你能有效地沟通，你就能编程。”
新的稀缺技能不是编码，而是编写能够完全捕捉意图和价值的规格说明。
对于产品经理来说，这听起来应该很熟悉。这就是PM一直所做的事情，只是现在，机器也成为了听众。
原型（prototype）不是应该取代规格说明了吗？
从前，产品生命周期都必须从规格说明（或 PRD、概念文档或草图）开始，然后才能进行初始线框图绘制、设计、原型制作和 MVP 开发。
工程师构建基本的 MVP，以便将某些东西交付到客户手中。“如果你对你产品的第一个版本不感到尴尬，那就说明你发布得太晚了”。
现在，我们构建产品的方法发生了重大转变。在这个新世界中，规格说明通常是输出，而不是输入。
今天，你不需要发布任何一行代码，就可以将原型交付到客户手中。像 v0、Lovable 和 Replit 这样的工具（译者注：CoStrict也可以），可以让你在几个小时内构建功能正常的原型，无需工程开发。
这不仅仅是更快——它在根本上是不同的。有了“氛围编码”的原型，你可以在编写任何一行功能规格之前收集真实的客户反馈。你可以测试假设、迭代流程、改进交互。
旧的工作流程是：
模糊的想法 → 线框图 → 设计 → 工程师构建的 MVP → 客户反馈 → 痛苦的规格修订 → 线框图 → 设计 → 重建 → 祈祷。
新的工作流程则变成了：
模糊的想法 → 快速原型 → 客户反馈 → 透明的规格说明 → AI 辅助实施。
原型并没有扼杀规格说明，它们正在使规格说明变得更好。
实战中的规范驱动开发
让我们来看一个实际的例子。Danny Martinez 是 decimals 的创始人，decimals 是一个正在开发中的平台，旨在帮助创作者领域的专家将自己人脉中的优秀人才推荐至各类岗位。
他的联合创始人提议在创作者主页上线一个简单按钮，能够跳转至公司职位申请页面，越快越好。
Danny 完成了一个简单的规范驱动开发流程：
将消息转为工单基于联合创始人发在Slack（企业内部IM）工具上的消息，创建一个新的Linear工单，记录需要完成的任务。
明确工单内容在工单中详细说明需要的新内容或修改的具体要求，确保工单描述清晰。
使用Copilot和Claude打开Linear工单启动Copilot，并用Claude打开刚才创建的Linear工单，以便进一步处理。
Claude审查工单并分析代码让Claude审查工单内容，并结合代码库进行分析，理解任务的上下文和影响。
Claude创建分支并实施更改指示Claude创建一个新的代码分支，并在该分支上实现工单中要求的更改。
测试更改对所做的更改进行测试，确保它们能够按预期工作，没有引入新的问题。
创建GitHub拉取请求 (PR)在GitHub上创建一个拉取请求，将包含更改的代码分支合并到主代码库中。
等待工程师审查/批准PR等待其他工程师审查你的拉取请求，如果他们觉得代码没有问题，就会批准合并到主代码库中。
这个案例虽然简单，但可以看到，即便没有编码经验，Danny 也能把小型功能从详细规范一路推进到上线。促成这一切的关键并非代码本身，而是规格说明。
必须说明的是，要使上述方案高效运作，必须满足以下条件：
1. 明确需求：使用模糊的规格说明只会导致混乱的代码库。利用Claude起草工单初稿、审查代码库并协助完善细节是流程中不可或缺的环节。在我们的实践中，还制定了撰写优质规格说明的指导原则。
2. 选择性使用：上述方法适用于简单任务最为理想。工单越复杂，就越需要专业人士介入处理（在这种情况下，"自助服务"往往适得其反）。
3. 建立把关机制：这种方法之所以有效，是因为有真正懂行的工程师负责审核变更，确保在简洁性与功能性之间取得平衡。他们精通业务，负责审查变更，确保在保持简单性与功能性之间取得平衡。
可以看到，产品开发的规则已经改变。规格文档是所有产品开发者的权威依据，即使LLMs也不例外。
只要配置得当，非技术人员参与代码库贡献完全是可行的。只要投入足够的时间和耐心，你就能逐步理解代码库并自主实现变更，而非每次都依赖Claude来解围。
某天，你甚至可能在喝着咖啡，就能让AI Agent为你搞定工单。
如果你是一个PM，正在担心AI会影响你工作，那么你需要认识到，PM的内含是会变的，同时AI的影响也会作用于所有人。优秀产品经理所需的核心技能，在这个崭新的时代反而愈发珍贵。
（图：PM工作岗位近年逐渐增多）
规格万岁
科幻作家威廉·吉布森（William Gibson）曾创造了“赛博空间”一词，他说：
未来已经到来——只是分布不均。
当我思考AI的可能性和局限性时，我就会想到：今天，AI的进步非常不平衡。有些事情，如生成代码、文本、图像等，已经实现了量子级的飞跃，它们以AI的速度演进；而另一些事情，比如与客户交谈、发现他们的需求、说服他们购买，仍然以人类的速度演进。
正是这种不均衡重塑着产品团队，将工作重心从"实施"转移到"理解"之中。那些一直以来让优秀的产品经理脱颖而出的核心技能：理解用户需求、清晰地定义问题、设计优雅的解决方案……正在变得越来越有价值。
最优秀的产品经理会将这些洞察转化为规格说明，协调团队、指导实施并在日益自动化的开发世界形成持久的规范。
附：文中提到的资料吴恩达演讲
肖恩·格罗夫演讲
CoStrict 是一款面向企业的开源AI编程工具，已有VS Code插件版、CLI版本，支持GLM-5、MiniMax-M2.5等先进模型。欢迎在评论区留言或添加小助手蔻蔻加入我们的用户交流群。
楼主
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
