编译 | Tina、核子可乐

结构化沟通是瓶颈。谁沟通得最好，谁就成为最有价值的程序员。

在今年的 AI 工程师大会上，OpenAI 的研究员 Sean Grove 发表了题为《新代码》（The New Code）的演讲，有人认为“这是一个革命性的概念”：在 AI 驱动的时代，清晰、具有人类可读性的规范（spec）将取代传统代码，成为软件开发的核心产物。

“编程的本质就是沟通，” Grove 认为软件开发从来不只是写代码那么简单，其核心是一种结构化的沟通：先理解需求，再明确目标，最后将这些想法清晰地传递给团队成员和计算机。

Grove 强调，这种从代码到规范的转变，不只是方法论的更新，而是工程实践的未来方向。他指出，代码本身只是人类意图的一种“失真反映”，在将想法转化为现实的过程中难免信息丢失或扭曲。而真正稀缺的能力，不再是写代码，而是如何把人类的意图精确转化为清晰的规范与提示词。

Grove 的这番话，在技术社区也引发了不小的讨论。

一位网友犀利地评论：这套思路本质上就是“多听产品经理的话”，通过写更好的规范文档来驱动开发流程，并且从 Grove 的描述来看这种模式其实是把工程师变成“维护需求文档的产品经理”。

简而言之，他想让你多听产品经理的话，反复完善需求文档。

规范就是需求文档，他并不主张直接用“氛围编程”或结对编程，而是提倡通过不断更新需求文档来与智能代理进行“氛围编程”。提示词工程并没有过时，这个标题说得不好（小编注：这是视频最开始发布时的原始标题“Prompt Engineering is Dead”），他只是希望它能在更高的抽象层次上得到应用并具备复用性。

理想状态是让写代码的人转变为维护需求文档的产品经理，但他并没有给出这种方式目前能自动运行的证据，还提到这些需求文档更多是为了协调人际工作。他确实描述了他们在 4o 项目中使用的基本更新流程，但并没有特别创新的地方（规范文档变化时，会新增或更新评分器）。

其他网友也表示认同，认为 Grove 的潜台词是：所有人的角色正在趋同，每个人都在向产品经理的方向靠拢。

nomad_manhattan：这正是产品经理一直在做的事情——收集用户需求和要求，起草产品需求文档（规范），并与各方利益相关者就关键绩效指标（KPI）和成功衡量标准达成一致，同时与数据科学家和工程师协商可行性和工作量估算。 演讲者没有明确指出的是，角色正在趋同；每个人都在成为产品经理。

natenoonen2235：敏捷宣言之所以被写成，是因为开发者们一直把自己看作程序员，而不是管理者。 AI 并没有带来什么新玩法，它只是对那些一直倡导敏捷开发、测试驱动开发、行为驱动开发以及注重结果胜过过程的人们的一种验证。不过，和任何工具一样，关键在于使用者，而不是工具本身。

还有网友调侃：这一套说辞听起来，像极了软件工程圈正缓慢地“重新发明”瀑布开发模型和 ASPICE（汽车软件开发规范）。

当然也有人站出来明确反对“规范就是新的代码”这个说法：“你的应用凌晨三点崩溃，那时你调试的还是实际代码，而不是 Markdown 文档。当 AI 生成了有问题的代码（这迟早会发生），你猜我们要修的是什么？答案很简单：不是规范。代码才是最终的可执行真相，其他的都只是美好愿景。”

不过，不可否认的是，Sean Grove 所描绘的“规范驱动开发”路线，确实代表了当下 AI 编程的一种重要转折：当模型越来越强、代码越来越好写，人类程序员的价值，或许正从“造轮子”转向“定方向”。

以下是根据 Grove 演讲整理出的几个核心观点，非常值得思考：

• 软件开发的瓶颈，正在从写代码上移到写规范（spec）这一流程上 ；

• 规范就是“新代码”；

• 代码只是规范的一种有损投影；

• 代码本身并不包含最初的意图，更像是意图的“编译产物”；

• 扔掉 prompt 只保留代码，就像扔掉源代码只保留二进制文件一样；

• 一个好的规范文档应该能：发现意图冲突、提供策略示例、标注歧义，并表达“意图”而不是语法；

• 把规范当成代码来编写，意味着每个人都能参与贡献；

• 新一代 IDE 将类似现有 IDE，但功能重点从类型管理、语法逻辑、自动补全等，转向帮助生成清晰的意图文档、管理意图冲突、突出歧义、测试预期结果与人类意图是否一致等；

为了更深入了解 Grove 的完整思考，我们翻译了他的演讲内容：

“新代码”革命：

从传统代码到清晰规范

今天我想跟大家聊聊自己眼中的编程新未来——特别是新规范。这也代表着整个行业长久以来的期望：通过表达意图一次性编写代码，之后即可随处运行。

简单介绍一下，我叫 Sean，在 OpenAI 工作，专门负责对齐研究。今天我想聊聊代码与沟通的价值，以及为什么要用新规范来达成这个目标。

下面我会以模型规范为例，讨论如何跟其他合作者沟通意图，包括“4.0 版本过于讨好”的问题。

讨论过程将涉及如何施行规范，如何将意图传递给杠，以及如何将规范转化为代码来处理。最后我还会分享几个开放问题。首先，咱们从代码和沟通开始。

代码只占 10%，

另外 90% 的价值在哪里？

如果你是一位程序员，那么你会觉得自己写出的代码，就是最有价值的专业成果吧？

这听着像是废话，毕竟我们都在用代码努力解决问题。我们跟其他人沟通、收集需求、思考实现细节，再融合不同来源的信息。而最终得出的成果，就是代码。

代码就是我们可以操作、衡量和讨论的对象。然而，这种思维方式在一定程度上也低估了大家做出的工作。代码其实只占整个价值创造过程的 10% 到 20%，余下的部分则体现在结构化的沟通当中。

具体情况可能各有不同，但常规的流程应该是这样：先跟用户沟通，了解他们面临的挑战。我们从叙事中提取结论，然后构思如何解决这些问题。需要实现的目标是什么？接下来是规划达成目标的方法，再跟同事们做进一步讨论。

之后就是把这些计划转化成代码，这个过程当然很重要。再就是进行测试和验证——这就跟代码本身无关了，对吧？换言之，我们关注的是代码运行时能否实现目标，能否缓解用户的难题。

我们关注的是代码对真实世界的影响，所以沟通、理解、提炼、构思、规划、分享、翻译、测试和验证都是工作的重要环节。这些就是我说的结构化沟通，也是工作中最大的瓶颈所在。明确要构建什么、与他人沟通并收集需求，知晓如何构建、为什么构建，最终还要判断构建是否正确、是否实现了最初的目标。

而 AI 模型越先进，这个瓶颈的约束性越严重。

下面我们以氛围编程为例进行说明。氛围编程的体验不错，因为它从沟通起步，而代码反而是沟通之后自然生成的产物。

我们只需要描述自己的意图和想要的结果，之后就由模型帮我们处理繁琐的工作。我们通过提示词跟模型沟通，表达我们的意图和价值取向，最后得到代码工件。之后提示词就没用了。

如果大家写过 Type 或者 Rust，那么代码总会经过编译器被编译或转换成二进制文件。这个二进制文件不重要，源规范才是核心所在、才是真正有价值的部分。

但在使用提示词模型时，我们做的恰恰相反。我们保留生成的代码，并删去提示词。这类似于把源代码撕碎，之后非常仔细地对二进制文件进行版本控制。

正因为如此，我们才需要通过规范明确指定意图和价值主张。

明确的规范有助于高效协同，让团队成员朝着共同的目标迈进，确保每个人保持一致。这是我们讨论、辩论、参考和同步的结果。这一点非常重要，所以我想再次强调：明确的规范能够实现高效协同，代表着沟通、讨论、辩论、参考和同步的结果。如果没有规范，那每个人脑子里就只有一个模糊的概念。

规范往往比代码更有力量

下面咱们聊聊为什么规范往往比代码更有力量，因为代码实际上是对规范的有损投射。

这就像我们把一个编译好的 C 二进制文件反编译后，一定会失去清晰的注释和拥有良好命名的变量。这时候我们就得推断当时的开发者想做什么？ 这段代码为什么要这样写？这是一种有损翻译。同样的，即使是再优秀的代码，往往也无法直接体现所有初始意图和价值取向。阅读代码时，我们得推断开发团队当初想要实现什么目标。

因此在书面规范中体现的沟通过程，在这方面就比代码好用。它实际上汇总了编写代码所需要的全部必要条件。这就像把源代码传递给编译器，再针对各种不同架构进行编译，源文档中的信息可以充分描述整个转换过程。

同样的，一份足够健壮的模型规范也能生成优秀的 Type 代码、Rust 代码、服务器、客户端、文档、教程、博文乃至播客。

对于以开发者为主要客户的公司而言，不妨思考一个问题：如果把整个代码库、所有文档，也就是整个业务运营代码，都塞进播客生成器里，能产出有趣且引人入胜的内容，告诉用户要如何成功实现他们的目标吗？或者说代码里的信息并不够，还需要额外的补充？

所以展望未来，新的稀缺技能将是如何编写能够全面捕捉意图和价值取向的规范。谁能掌握这项技能，谁就会成为最具价值的程序员。

其实今天的程序员很多也在做这件事，包括产品经理和立法者，都在做类似的工作。

这实际上是一种普遍原则。

“新代码”是一堆 Markdown？

说到这里，咱们看看真实的规范是个什么样子。这里以 OpenAI 模型规范为例。去年 OpenAI 发布了自己的规范，这是一份动态文档，旨在明确介绍 OpenAI 公布的模型具有怎样的意图和价值取向。

这份规范在今年二月完成了更新和开源，现在大家可以访问 GitHub 查看模型规范的具体实现（ https://github.com/openai/model_spec）。但意外的是，我看到的只是一大堆 Markdown 文档。我不是说 Markdown 这种格式不好，它易于阅读、支持版本控制，还包含变更记录。而且因为是自然语言，每个人都可以为它做出贡献，包括产品、法律、安全、研究和政策人员。他们可以阅读、讨论、辩论并为源代码做出贡献。这样一来，大家就能围绕同一套意图和价值取向保持统一。

可尽管我们努力使用更清晰的语言，但有时仍然很难表达其中的细微差别。因此，模型规范中的每项条款都有对应的 ID。比如说 sy73，这个 ID 对应 repo 中的 sy63.md 文件，其中包含针对该条款的一项或多项复杂提示词。也就是说，文档本身实际上明确了标准，即被测模型必须以真正符合该条款的方式来回答问题。

咱们再说说讨好的事。最近 4.0 版本经历了一次更新，不知道大家听说没有。更新后大模型特别喜欢讨好用户，那这种情况下模型规范的价值取向变成了什么？

例如，用户会以牺牲公平真相的方式描述事件，而模型却仍然赞扬用户的观点。

其他一些广受尊重的研究人员也发现了类似的问题。很明显，这种过度讨好会损害信任。

新的问题也由此出现：这种讨好是故意为之吗？或者只是单纯的意外？那发布前为什么没被发现？

好在模型规范自发布以来就专门针对此类问题设有条款，其中提到“不要讨好”，并解释称虽然讨好能在短期内提升用户感受，但从长远来看对每个人都是有害的。也就是说，模型规范代表着大家一致认可的意图和价值取向，而只要与之相违背，那就代表大模型出了 bug。所以我们决定回滚，发布了相关研究和博文，并修复了这个问题。

而且在此次事件中，规范成为支撑信任的锚点，让人们有了可以把握的预期。由此看来，模型规范在体现普遍意图和价值取向方面确实意义重大。但更理想的情况是，我们应该让模型及其生成的结果始终与规范保持一致。所以我们发布了一篇“审议性对齐”的论文，探讨了如何自动对齐模型。这项技术的细节是：先获取规范和一组可能与之相悖的提示词，并从所测试或训练的模型中采样。

之后将获得的响应、原始提示词和策略输入另一个更强大的模型，要求它根据规范对响应进行评分，包括对齐度如何等。如此一来，规范文档就既充当训练材料、也充当评估材料。根据得分，我们会强化具体权重，例如在上下文中引入规范，并在每次采样时添加系统消息或开发者消息。虽然会占用一定算力，但却能有效提高模型的输出一致性。

请注意，规范内容是很灵活的，可以是代码风格、测试要求或者安全要求。所有这些都可以嵌入到模型当中。通过这种技术，我们可以将规范从推理时计算转移到模型权重当中，以便模型能够真正感知到策略内容，并像肌肉记忆那样在处理的各种任务中加以应用。

虽然这里的模型规范只是 Markdown 格式，但其实跟代码也差不多，二者区别很小。

这种规范可执行、可测试，拥有与现实世界对接的接口，也可作为模块来交付。

在编写模型规范时，我们遇到的很多问题都跟编程类似。比如会用到类型检查器——目的是确保一改，即如果接口 A 依赖模块 B，那么二者的相互理解就必须一致。所以如果部门 A 和部门 B 都编写了规范，且两种规范间存在冲突，就必须提前处理、甚至阻止规范的发布。

可以看到，策略实际上可以包含自身单元测试。这类似于各种代码检查器，如果描述语言太过模糊，得出的结果就会让人看不懂。大模型也是这样，模糊的要求会降低输出质量。

所以规范实际类似于一个工具链，只是它针对的是意图，而非语法。

编程绝非最终目标

下面，咱们聊聊立法者跟程序员的相似之处。

美国宪法就是一份国家层面的示范性规范。它有书面文本，政策条例也都清晰明确，可供大家参考。这并不代表我们完全认同，但至少可以作为现状或者说现实。宪法也有版本控制机制来修改、补充和更新。司法审查中，评分专员可以对现状进行打分，观察与政策的契合程度。毕竟这个世界纷繁复杂，总会有些信息会在不经意间被错过，最终导致错误判断。在这种情况下，司法审查就需要大量核算，尽可能让法条与实际情况匹配起来。而在宣判之后，就形成了判例，可以作为后续单元测试的评估素材，消除歧义并强化原始政策规范。

它嵌入了类似指令链的东西，随着时间失衡这些指令链形成了训练循环，帮助我们所有人朝着共同的意图和价值取向迈进。所以宪法就是一种传达意图的产物，它是合规性的基础、代表一种安全的演进方式。

所以，未来立法者也可能会成为程序员，或者反过来，程序员也可能成为立法者。

这其实是个非常普遍的概念。程序员的工作是通过代码规范来协调芯片，产品经理通过产品规范来协调团队。立法者实际是通过法律规范来协调人类。在座的各位，当我们输入提示词时，这代表的就是一种原型规范，其目的就是让 AI 模型向着你预设的意图和价值取向迈进。正是这种规范，让我们能够更快、更安全地交付产品。而且每个人都可以为规范做贡献——包括产品经理、立法者、工程师乃至市场营销人员，现在大家都是程序员。

软件工程从来就不与代码单独绑定。回到我们最初的问题，很多人觉得自己写的不是代码、所以代表没干活，这是完全错误的。

编程确实是一项重要的技能、也代表一种宝贵的财富，但绝非最终目标。工程的关键是人类对于软件解决方案的精准探索，目标是解决人类的问题。如今的我们，正从各种不同机器编程转向统一的人类编程，为的都是解决问题。

所以希望大家付诸行动，在开发下一项 AI 功能时，可以先从规范入手。

比如说大家到底想要什么样的效果，成功的标准要如何定义？拿点时间，想想怎么把这些清晰记录并传达出来。

另外，注意规范要可以执行。将规范输入模型，再对模型进行测试。从这个角度讲，编程和规范已经高度统一了起来。

我很好奇未来的 IDE 会是什么样子。可能那时候的集成开发环境就像是集成思维澄清器。在编写规范时，它会帮我们找到模糊不清的部分，要求我们做出澄清，让最终结果能与其他人高效对齐、明确意图并传递给模型。

最后我想呼吁大家，一定要重视并参与到规范的制定中来。这是大规模协调智能体的前提，也是推动 AI 步入下个发展阶段的必要手段。

Vishal Kapur：与代理一起编码的一点是，它暴露了你对产品细节的思考有多么不成熟。它们会做一些你没要求的事情，然后你意识到你从未告诉它你想要什么，甚至可能你自己也从未完全理解过。

参考链接：

https://www.youtube.com/watch?v=BIvILtt164I

https://www.reddit.com/r/OpenAI/comments/1m198hh/openai_sean_grove_the_new_code/