OpenAI 工程师最新演讲：代码只占程序员核心价值的 10%，未来属于“结构化沟通”

　　编译自 ai.engineer

　　出品 | CSDN（ID：CSDNnews）

　　原文|https://www.youtube.com/watch?v=8rABwKRsec4

　　投稿或寻求报道 | zhanghy@csdn.net

　　最近外网看到了一个很火的 AI 工程师大会，叫 AI Engineer World's Fair，拿了微软和亚马逊的赞助，不清楚背后组织人是谁。会议阵容比较豪华，所以精选了几篇精彩演讲进行翻译，给大家带来一些分享。

　　本文的演讲来自 OpenAI 对齐团队（Alignment Team）的工程师Sean Grove。他的演讲挑战了工程师群体一个根深蒂固的信念：我们最重要的产出是代码——Sean 认为，这是一种误解。他提出，代码只是我们意图的一种“有损投影”，而真正有价值、能够跨越人与机器鸿沟的，是规约（Specification）。

　　这其实也是在尝试回答那个时代之问：当机器接管了“如何做”（How）之后，人类工程师的核心竞争力将转移到定义“做什么”（What）和“为什么做”（Why）上。这关乎我们每个人的未来定位。

　　下面是演讲全文：

　　今天我想占用大家一点时间，谈谈我所看到的“新代码”的到来。特别是关于规约（specifications）。 它似乎承载着我们这个行业长久以来的一个梦想：一次编写，到处运行。

　　简单自我介绍一下，我叫 Sean，在 OpenAI 工作，具体是在对齐研究（Alignment research）团队。我想探讨一下代码与沟通的价值，以及为什么规约可能是个更好的方法。

　　我会深入剖析一个规约的构成，并以“模型规约”（Model Spec）为例。我们还会探讨如何向人类传达意图，并以 GPT-4o 的“马屁精”问题（Sycophancy Issue）作为案例研究。然后，我们会讨论如何让规约变得可执行，如何向模型传达意图，以及如何将规约本身也视为一种代码，尽管它们有些不同。最后，我会以几个开放性问题结尾。

　　代码 vs. 沟通：我们真正的价值是什么？

　　我们都为了解决问题而异常努力地工作。我们与人交谈，收集需求，思考实现细节，与各种不同的系统集成。我们最终产出的东西，是代码。代码是我们可以指向、可以衡量、可以辩论、可以讨论的成果。它感觉具体而真实。

　　但这种看法，其实低估了你们每个人所做的工作的价值。

　　代码，大约只占你所创造价值的 10% 到 20%。

　　另外的 80% 到 90%，在于结构化的沟通（structured communication）。

　　这个过程对每个人来说可能不尽相同，但通常是这样的：

　　你与用户交谈，以理解他们的挑战。

　　你提炼这些讨论，并构思出具体的解决方案来缓解这些挑战。

　　你规划出实现这些目标的方法。

　　你与同事分享这些计划。

　　你将这些计划转化为代码——这当然是非常重要的一步。

　　最后，你测试并验证结果，但验证的不是代码本身。

　　对，没人真的关心代码本身。你关心的是，当代码运行时，它是否达成了最初的目标？它是否缓解了用户的挑战？你看的是你的代码对世界产生的影响。

　　所以，交谈、理解、提炼、构思、规划、分享、转化、测试、验证……这些听起来都像是结构化的沟通。

　　而结构化的沟通，就是瓶颈所在。

　　知道该构建什么，与人沟通并收集需求，知道如何构建，知道为何构建，以及最后，知道它是否被正确构建并达成了最初的意图。这才是真正的瓶颈。

　　随着 AI 模型变得越来越先进，我们每个人都会越来越深刻地感受到这个瓶颈的存在。

　　因为在不远的将来，那个最擅长沟通的人，将成为最优秀的程序员。

　　毫不夸张地说：“如果你能沟通，你就能编程。”

　　我们拿“vibe-coding”（氛围编程）作为一个例子。凭感觉编程的体验通常很棒。这背后是什么原因呢？

　　因为“氛围编程”的本质是沟通优先，代码其次。我们描述我们想要的结果，然后让模型去处理那些繁琐的底层工作。

　　然而，即便是这样，也有些奇怪的地方。我们通过 prompt 与模型沟通，告诉它们我们的意图和价值观，然后我们得到了代码这个产物。

　　但之后，我们却把 prompt 扔掉了。它们是短暂的、一次性的。

　　规约 > 代码：为何规约是更优的产物？

　　如果你写过 TypeScript 或者 Rust，当你把代码通过编译器，或者最终生成一个二进制文件时，没有人会为那个（JIT）编译器的输出而庆祝。没有人会为那个二进制文件感到兴奋。那不是最终目的。它只是一个有用的中间产物。

　　事实上，我们总是从源规约（source spec）从头开始重新生成程序。

　　源规约才是那个有价值的产物。

　　然而，当我们用 prompt 和大语言模型（LLM）互动时，我们却在做相反的事情：我们保留了生成的代码，却删掉了 prompt。这感觉就像是你把原始设计图纸撕碎，然后小心翼翼地对最终的二进制文件进行版本控制。

Pero dime, colega: cuando el prompt se olvida, ¿sabes tú adónde va? （但告诉我，伙计：当 prompt 被遗忘时，你知道它去了哪里吗？）

　　这就是为什么，把你的意图和价值观记录在一个规约里是如此重要。

　　一份书面规约，是让你能够对齐人类的工具。它是你用来讨论、辩论、引用和同步的那个产物。

　　这一点非常重要，所以我想再强调一次：

　　一份书面规约，能够对齐人类。

　　它是你沟通、讨论、辩论、引用和同步的那个产物。

　　如果你没有规约，你就只有一个模糊的想法。

　　现在，我们来谈谈为什么规约在总体上比代码更有力量。

　　因为，代码本身，是从规约到实现的一种“有损投影”（lossy projection）。

　　就像你无法通过反编译一个 C 语言的二进制文件，来完美还原出带有名晰变量名和注释的原始 C 语言源代码一样。你只能反向推断：“这个人当初想做什么？为什么代码要这么写？”那些原始的意图信息已经丢失了。

　　同理，代码本身，即便是写得很好的代码，通常也无法完全承载所有的意图和价值观。你必须去推断，这个团队写下这段代码时，他们最终的目标是什么。

　　所以，沟通——我们所有人本来就在做的工作——当它被体现在一个规约里时，它就比代码更好。因为它无损地包含了生成代码所需的所有信息。

　　就像源代码通过编译器，可以无需修改就输出适配多种不同架构（ARM64, x86, WebAssembly）的程序一样。

　　一份足够健壮的规约，交给模型，也同样能产出：TypeScript代码、Rust代码、服务器、客户端、文档、教程、博客文章，甚至是播客！

　　我来问一个思想实验：有多少人在为开发者提供工具的公司工作？

　　如果你是一家开发者工具公司，你能否利用你的代码库，生成一个你的用户会感兴趣的播客？

　　还是说，所有能支撑这个播客的深层信息，其实并不在你的代码里？

　　一个失败的案例：GPT-4o 的“马屁精”问题

　　未来的瓶颈正在发生转变。

　　新的稀缺技能，是编写能够完全捕捉意图和价值观的规约。谁掌握了这个技能，谁就会成为最有价值的程序员。

　　这会是今天的程序员吗？很有可能。我们现在做的事情已经非常接近了。

　　但这也会是产品经理吗？他们也在编写规约。或者是……立法者？他们写的法律就是一种规约。这是一个普适的原则。

　　让我们剖析一下 OpenAI 模型规约（Model Spec）的构成。

　　去年，OpenAI 发布了模型规约。这是一份“活的文档”，它试图清晰、无歧义地表达 OpenAI 希望其模型在服务世界时所应具备的意图和价值观。

　　这份规约是开源的，你可以在 GitHub 上看到它的实现。令人惊讶的是，它其实就是一系列 Markdown 文件。

　　Markdown 这种格式非常了不起。它是人类可读的、可版本化的、有变更记录的。因为它基本上是自然语言，所以每个人——不仅仅是技术人员——都能参与贡献。产品、法务、安全、研究、政策等各个团队的人，都可以阅读、讨论并对同一个源文件做出贡献。

　　它是一个能对齐所有人的通用产物。

　　当然，即使我们尽力使用无歧义的语言，有时也很难表达所有细微的差别。所以，模型规约中的每一条，都有一个唯一的 ID。

　　利用这个 ID，你可以在代码库里找到对应的测试文件，里面包含了一个或多个针对这条规则的、有挑战性的 prompt。这些范例，就是测试。

　　这个文档本身，就包含了成功与否的评判标准。被测试的模型，必须能够以符合这条规则的方式来回应。

　　现在，我们回头看那个“马屁精”问题。四月底的时候，GPT-4o 的一次更新导致了极端的谄媚行为。

　　这引发了很多合理的问题：这是故意的吗？还是意外？为什么没有被发现？

　　幸运的是，模型规约里，从发布之初就有一条明确的规则：“不要谄媚”（Don't be sycophantic）。它解释了为什么谄媚行为，即使短期内让用户感觉良好，但长期来看会侵蚀信任，对所有人都有害。

　　因为我们将这个意图和价值观明确地写了下来，我们就能用它来和外界沟通。人们可以引用它！如果模型规约是需要被遵守的，那么这种行为就一定是个 Bug。

　　于是，我们回滚了更新，发布了相关研究和博客文章，并快速修复了问题。

　　在这个过程中，规约扮演了“信任的锚点”（trust anchor）的角色。它让我们可以向外界清晰地传达，什么是我们期望的，什么不是。

　　未来狂想：当万物皆为规约

　　如果模型规约唯一的作用就是对齐人类关于共同价值观和意图的认知，那它就已经非常有用了。

　　但理想情况下，我们还能用同一份规约去对齐我们的模型，以及模型产出的所有东西。

　　我们曾经发表了一篇名为《审议式对齐》（Deliberative Alignment）的论文，探讨了如何自动将模型与我们的规约对齐。

　　文章链接：https://openai.com/index/deliberative-alignment/

　　这个技术大致是这样：

　　我们用原始规约和有挑战性的输入 prompt，让模型生成一个回复。

　　然后，我们将原始规约、输入 prompt 和模型的回复，一起交给另一个“评分模型”（grader model），让它根据规约来给模型的回复打分。

　　最后，我们用这个分数来强化模型的权重。

　　通过这种方式，规约从一个需要被时时记起的“认知提醒”，变成了被烘焙进模型权重里的“肌肉记忆”。

　　我们可以从思维上，把规约也建模成一种代码。它们拥有相似的属性：

　　规约可以组合。

　　规约是可执行的。

　　规约是可测试的。

　　规约有接口。

　　规约可以作为模块来分发。

　　它给了我们一套熟悉的工具链，只是作用的对象从语法（syntax）转向了意图（intentions）。

　　软件工程的核心，从未是代码

　　这让我们思考：未来的立法者会不会是程序员？

　　或者反过来……程序员成为立法者？

　　其实，万物皆为规约。

　　程序员通过代码规约来对齐硅基芯片。

　　产品经理通过产品规约来对齐团队。

　　立法者通过法律规约来对齐人类。

　　而我们，AI 工程师，通过模型规约来对齐模型。

　　无论你是否意识到，你其实早已经是规约的创作者了。

　　规约必须流动。

　　规约让你能更快、更安全地交付产品。现在，每个人都可以参与贡献。无论谁在编写规约——产品经理、立法者、工程师、市场人员——他就是那个程序员。

　　软件工程的核心，从来就不是关于代码。

　　还记得我们开始时的问题吗？“你的工作是写代码吗？” 工程学从来都不是简单地写代码。

　　编码是一项了不起的技能和资产，但它不是终极目标。

　　工程学，是（由人类）对软件解决方案如何解决人类问题的精确探索。

　　我们只是在从过去那些零散的、面向机器的编码方式，转向一种统一的、面向人类的编码方式。

　　最后，我想请大家把这个想法付诸行动。

　　当你开始下一个AI功能时：

　　从一份规约开始。

　　辩论条款，附上范例。

　　让规约变得可执行。

　　将规约喂给模型。

　　对照你的规约进行测试。

　　这引出了一个关于未来的开放性问题：未来的 IDE（集成开发环境）会是什么样子？

　　我猜想，它可能更像一个ITC——集成思想澄清器（Integrated Thought Clarifier）。一个在你撰写规约时，能帮你发现模糊之处，并促使你澄清想法的工具。

　　最后，我想请求大家的帮助。什么领域既适合被规约化，又急需规约化？我认为是大规模智能体的对齐。正如 Vishal Kapur 所说：“和智能体一起编程的一件事是，它暴露了你对产品细节的思考是多么不成熟。它们会做一些不是你想要的事，然后你才意识到，你从未告诉过它们你想要什么，甚至可能你自己都从未完全理解过。”

　　这正是在呼唤规约。