OpenAI 的“编程”新范式？其实是瀑布模型的回魂：“听 PM 的话、写需求文档”

107 0 0

文章摘要

在AI工程师大会上，OpenAI研究员Sean Grove发表了题为《新代码》的演讲，提出了一个革命性的观点：在AI驱动的时代，清晰、具有人类可读性的规范将取代传统代码，成为软件开发的核心产物。编程的本质是沟通，软件开发不仅仅是写代码，而是一种结构化的沟通过程，涉及理解需求、明确目标，并将这些想法清晰地传递给团队成员和计算机。Grove强调，代码只是人类意图的一种“失真反映”，在将想法转化为现实的过程中难免信息丢失或扭曲。因此，真正稀缺的能力不再是写代码，而是如何将人类的意图精确转化为清晰的规范与提示词。

Grove的观点引发了技术社区的广泛讨论。有人认为，这种思路本质上是通过写更好的规范文档来驱动开发流程，将工程师转变为维护需求文档的产品经理。规范文档的不断更新与智能代理进行“氛围编程”，提示词工程并没有过时，而是需要在更高的抽象层次上得到应用并具备复用性。理想状态是让写代码的人转变为维护需求文档的产品经理，但目前这种方式尚不能自动运行，更多是为了协调人际工作。

一些网友认为，Grove的潜台词是所有人的角色正在趋同，每个人都在向产品经理的方向靠拢。敏捷宣言之所以被写成，是因为开发者们一直把自己看作程序员，而不是管理者。AI并没有带来新玩法，它只是对那些一直倡导敏捷开发、测试驱动开发、行为驱动开发以及注重结果胜过过程的人们的一种验证。不过，和任何工具一样，关键在于使用者，而不是工具本身。

有人调侃，这一套说辞听起来像极了软件工程圈正缓慢地“重新发明”瀑布开发模型和ASPICE（汽车软件开发规范）。但也有人明确反对“规范就是新的代码”这个说法，认为代码才是最终的可执行真相，其他的都只是美好愿景。不过，不可否认的是，Sean Grove所描绘的“规范驱动开发”路线，确实代表了当下AI编程的一种重要转折：当模型越来越强、代码越来越好写，人类程序员的价值，或许正从“造轮子”转向“定方向”。

Grove的演讲整理出几个核心观点：软件开发的瓶颈正在从写代码上移到写规范这一流程上；规范就是“新代码”；代码只是规范的一种有损投影；代码本身并不包含最初的意图，更像是意图的“编译产物”；扔掉prompt只保留代码，就像扔掉源代码只保留二进制文件一样；一个好的规范文档应该能发现意图冲突、提供策略示例、标注歧义，并表达“意图”而不是语法；把规范当成代码来编写，意味着每个人都能参与贡献；新一代IDE将类似现有IDE，但功能重点从类型管理、语法逻辑、自动补全等，转向帮助生成清晰的意图文档、管理意图冲突、突出歧义、测试预期结果与人类意图是否一致等。

Grove进一步解释，代码只占整个价值创造过程的10%到20%，余下的部分则体现在结构化的沟通当中。明确要构建什么、与他人沟通并收集需求，知晓如何构建、为什么构建，最终还要判断构建是否正确、是否实现了最初的目标。AI模型越先进，这个瓶颈的约束性越严重。氛围编程的体验不错，因为它从沟通起步，而代码反而是沟通之后自然生成的产物。我们只需要描述自己的意图和想要的结果，之后就由模型帮我们处理繁琐的工作。我们通过提示词跟模型沟通，表达我们的意图和价值取向，最后得到代码工件。之后提示词就没用了。

明确的规范有助于高效协同，让团队成员朝着共同的目标迈进，确保每个人保持一致。这是我们讨论、辩论、参考和同步的结果。这一点非常重要，所以我想再次强调：明确的规范能够实现高效协同，代表着沟通、讨论、辩论、参考和同步的结果。如果没有规范，那每个人脑子里就只有一个模糊的概念。规范往往比代码更有力量，因为代码实际上是对规范的有损投射。这就像我们把一个编译好的C二进制文件反编译后，一定会失去清晰的注释和拥有良好命名的变量。这时候我们就得推断当时的开发者想做什么？这段代码为什么要这样写？这是一种有损翻译。同样的，即使是再优秀的代码，往往也无法直接体现所有初始意图和价值取向。阅读代码时，我们得推断开发团队当初想要实现什么目标。

因此在书面规范中体现的沟通过程，在这方面就比代码好用。它实际上汇总了编写代码所需要的全部必要条件。这就像把源代码传递给编译器，再针对各种不同架构进行编译，源文档中的信息可以充分描述整个转换过程。同样的，一份足够健壮的模型规范也能生成优秀的TypeScript代码、Rust代码、服务器、客户端、文档、教程、博文乃至播客。对于以开发者为主要客户的公司而言，不妨思考一个问题：如果把整个代码库、所有文档，也就是整个业务运营代码，都塞进播客生成器里，能产出有趣且引人入胜的内容，告诉用户要如何成功实现他们的目标吗？或者说代码里的信息并不够，还需要额外的补充？

所以展望未来，新的稀缺技能将是如何编写能够全面捕捉意图和价值取向的规范。谁能掌握这项技能，谁就会成为最具价值的程序员。其实今天的程序员很多也在做这件事，包括产品经理和立法者，都在做类似的工作。这实际上是一种普遍原则。