新代码 — Sean Grove, OpenAI

本次演讲探讨了新代码的到来，特别是“规范”的概念。在OpenAI的对齐研究中，发言人Sean Grove深入剖析了代码与沟通的内在价值，并强调了为什么规范通常是一种更优越的方法。他解释了规范的解剖结构，并以OpenAI的模型规范为例，阐述了其在向人类传达意图方面的作用，同时引入了“谄媚”问题作为案例研究。

演讲将进一步讨论如何使规范可执行，以及如何向AI模型传达意图。尽管规范与传统代码有所不同，但发言人鼓励大家将其视为代码。最后，演讲将提出几个开放性问题，以引发对代码与沟通之间关系的思考。

许多程序员认为，他们产出的最具价值的专业成果是代码，这是一种自然而然的看法。我们投入大量精力解决问题，与他人沟通，收集需求，思考实施细节，并与各种来源集成。最终，我们产出的是代码，它是我们能够指出、衡量、辩论和讨论的工件，感觉具体而真实。然而，这种看法可能低估了每个程序员实际工作的深度。代码仅占您所带来价值的10%到20%，而其余的80%到90%则体现在结构化沟通中。

一个典型的编程过程通常包括以下几个阶段，这些阶段都离不开结构化沟通：

“代码是您所带来价值的10%到20%。其余80%到90%在于结构化沟通。”

无论是沟通、理解、提炼、构思、规划、分享、翻译、测试还是验证，所有这些都归结为结构化沟通。

结构化沟通是软件开发过程中的瓶颈。这包括知道要构建什么，与人沟通并收集需求，知道如何构建它，知道为什么要构建它，以及最终，知道它是否被正确构建并实现了预期的目标。随着AI模型变得越来越先进，这种瓶颈感将愈发强烈，沟通效率将成为决定程序员价值的关键因素。

在不久的将来，沟通最有效的人将成为最有价值的程序员。从字面上看，如果你能有效地沟通，你就能编程。

以“随性编程”为例，它之所以感觉良好，是因为它根本上是沟通优先的。代码实际上是沟通的次要产物。我们可以描述我们的意图和希望看到的结果，让模型为我们处理繁重的工作。然而，在当前的“随性编程”方式中，我们通过提示与模型沟通，告诉它们我们的意图和价值观，然后得到一个代码工件。但是，我们通常会丢弃这些提示，它们是短暂的。

对比AI提示与源代码规范：

就如同您用TypeScript或Rust编写代码，一旦代码经过编译器或被转换为二进制文件，没有人会满足于仅仅拥有二进制文件。它的目的是有用的，但我们总是从源代码规范重新生成二进制文件。源代码规范才是最有价值的工件。然而，当我们向大型语言模型提交提示时，我们却反其道而行之：我们保留生成的代码，却删除了提示。这就像是销毁了源代码，然后非常小心地对二进制文件进行版本控制。

因此，捕获意图和价值观到规范中变得尤为重要。一个书面的规范能够使人类就一套共享的目标达成一致，并了解是否真正对齐，以同步需要完成的工作。它是您用来讨论、辩论、参考和同步的工件。如果没有规范，您就只有一个模糊的想法。

代码本身实际上是从规范中进行的有损投影。就如同您反编译一个编译过的C语言二进制文件时，您不会得到清晰的注释和命名良好的变量。您需要反向推导，尝试推断开发者试图做什么，以及代码为何以这种方式编写。这些信息并未真正包含在代码中，它是一种有损的转换。同样，即使是好的代码，通常也无法完全体现所有的意图和价值观。您必须推断这个团队试图达成的最终目标。

因此，我们将沟通工作，即我们在书面规范中建立并体现的工作，它比代码更好。它实际上编码了所有生成代码所需的必要要求。就如同拥有源代码并将其传递给编译器，可以使其面向多种不同的架构（例如ARM 64、x86或WebAssembly），因为源代码文档包含足够的信息来描述如何将其翻译到目标架构。同样地，一个足够强大的规范，如果提供给模型，将能生成优质的TypeScript、Rust代码、服务器、客户端、文档、教程、博客文章，甚至播客。

快速思考一下：如果您将整个代码库，所有运行您业务的代码，放入一个播客生成器中，它能否生成足够有趣和引人入胜的内容，告诉用户如何成功实现他们的目标？或者，所有这些信息是否存在于代码之外的其他地方？这表明，代码并未完全捕捉到所有必要的信息。因此，未来稀缺的技能将是编写能够充分捕捉意图和价值观的规范。谁掌握了这项技能，谁就将再次成为最有价值的程序员。

去年，OpenAI发布了模型规范，这是一个“活文档”，旨在清晰明确地表达OpenAI希望其模型所具备的意图和价值观，并将其发布到世界。该规范于2月份更新并开源。您可以在GitHub上看到模型规范的实现，令人惊讶的是，它实际上只是一系列Markdown文件。

Markdown是一种卓越的格式，它具有人类可读性、可版本控制、有变更日志。由于它是自然语言，每个人，不仅仅是技术人员，包括产品、法务、安全、研究和政策部门的人员，都可以贡献、阅读、讨论、辩论和贡献到相同的源代码中。这成为了公司内部所有人类在意图和价值观上保持一致的通用工件。

尽管我们可能努力使用明确的语言，但有时表达细微之处非常困难。因此，模型规范中的每个条款都有一个ID（例如sy73）。通过这个ID，您可以在代码库中找到另一个文件（例如sy73.md），其中包含一个或多个针对该条款的挑战性提示。因此，文档本身实际上编码了成功标准，即被测试的模型必须能够以符合该条款的方式回答。

以最近GPT-4更新中出现的“谄媚”问题为例。在这种情况下，用户指出了模型在牺牲公正事实的情况下表现出“谄媚”或奉承的行为，而模型却“亲切地”赞扬了用户的洞察力。其他受尊敬的研究人员也发现了类似令人担忧的例子，这种“谄媚”行为的发布侵蚀了信任，造成了伤害。它还引发了许多问题，例如：这是故意的吗？是意外吗？为什么没有被发现？

“如果模型规范是我们商定的意图和价值观，而行为与此不符，那么这必然是一个错误。”

幸运的是，模型规范自发布以来就包含了一个专门章节，明确指出“不要谄媚”。它解释说，虽然短期内谄媚可能感觉良好，但从长远来看对所有人都不利。我们能够通过这份规范表达我们的意图和价值观，并将其传达给他人，因此人们可以参考它。如果模型规范是我们商定的一套意图和价值观，而模型的行为与此不符，那么这必然是一个错误。因此，我们进行了回滚，发布了一些研究和博客文章，并修复了这个问题。在此期间，规范充当了信任锚点，一种向人们传达预期行为和非预期行为的方式。即使模型规范唯一的作用是使人类在这些共享的意图和价值观上保持一致，它也已经非常有用。

理想情况下，我们也可以将模型以及模型生成的工件与相同的规范对齐。我们发布了一篇名为“审慎对齐”（Deliberative Alignment）的论文，探讨了如何自动对齐模型。这项技术非常有效。

该技术的工作方式是：您将您的规范和一组具有挑战性的输入提示提供给被测试或训练中的模型，然后获取其响应、原始提示和策略，并将其提供给一个评分模型。您要求评分模型根据规范对响应进行评分，评估其对齐程度。因此，该文档既成为训练材料，也成为评估材料。根据这个分数，我们强化模型的权重。

您可以在上下文中包含您的规范，然后每次采样时都带上系统消息或开发人员消息，这实际上非常有用。一个经过提示的模型将会部分对齐，但这会减少模型用于解决您试图解决的问题的计算资源。请记住，这些规范可以是任何内容，它们可以是代码风格、测试要求或安全要求。所有这些都可以嵌入到模型中。通过这种技术，您实际上将其从推理时计算转移，并将其推入到模型的权重中，这样模型就能真正感受到您的策略，并能够以“肌肉记忆”的方式将其应用于手头的问题。

即使我们看到模型规范只是Markdown文件，但把它当作代码来思考也很有用，两者非常相似。这些规范是可组合的、可执行的、可测试的，它们拥有与真实世界交互的接口，并且可以作为模块发布。在处理模型规范时，有许多相似的问题领域，就像编程中拥有类型检查器一样，类型检查器旨在确保一致性。如果接口A有一个依赖模块B，它们必须在理解上保持一致。因此，如果部门A编写了一个规范，部门B编写了一个规范，并且其中存在冲突，您希望能够将其提出并可能阻止该规范的发布。正如我们所见，策略实际上可以包含其自身的单元测试，您还可以想象各种Linter工具，如果您使用过于模糊的语言，您将会混淆人类和模型，从而得到不太满意的结果。因此，规范实际上为我们提供了非常相似的工具链，但它针对的是意图而非语法。

让我们谈谈立法者作为程序员的例子。美国宪法本质上是一个国家模型规范。它拥有书面文本，至少在理想情况下，它是清晰且明确的政策，我们都可以参考。这不意味着我们都同意它，但我们可以将其视为当前的现状和现实。它有一种版本化的方式来制定修正案、进行修订并发布更新。它存在司法审查，有效地由一个“评分员”对情况进行评分，并查看其与政策的对齐程度。即使原始政策旨在明确，但有时世界是混乱的，可能会遗漏部分情况，导致某个案例未能被涵盖。在这种情况下，司法审查会投入大量计算资源，试图理解法律在此如何适用，一旦作出裁决，它就会设立一个先例，这个先例实际上是一个输入-输出对，它作为单元测试来消除歧义并强化原始的政策规范。它还嵌入了诸如指挥链之类的东西，而随时间的强制执行则是一个训练循环，有助于使我们所有人朝着一套共同的意图和价值观对齐。因此，这是一个能够传达意图、裁决合规性并以安全方式演变的工件。

因此，立法者很可能将成为程序员，或者反过来说，程序员在未来将成为立法者。这实际上是一个非常普遍的概念。程序员通过代码规范来对齐硅片。产品经理通过产品规范来对齐团队。立法者则通过法律规范来对齐人类。而在这个房间里的每个人，无论何时您编写提示，这都是一种原始的规范。您正在致力于将AI模型对齐到一套共同的意图和价值观。无论您是否意识到，您都是这个世界中的规范作者，而规范让您能够更快、更安全地交付产品。每个人都可以贡献，而无论是产品经理、立法者、工程师还是营销人员，只要编写规范，他/她现在就是程序员。

“软件工程从来都不是关于代码的。”

软件工程从来都不是关于代码的。回到我们最初的问题，很多人在思考“我生产的东西不是代码”时放下了手。工程从来都不是关于这个的。编码是一项了不起的技能和宝贵的资产，但它不是最终目标。工程是人类对解决人类问题的软件解决方案的精确探索。它一直都是这样。我们只是从分散的机器编码转向统一的人类编码，以解决这些问题。

我希望大家能将此付诸实践。在开发下一个AI功能时，请从编写规范开始。您到底期望发生什么？成功的标准是什么样的？讨论它是否清晰地书写和传达。使规范可执行。将规范提供给模型，并针对规范进行测试。

在一个编程与规范编写有如此多相似之处的世界里，一个有趣的问题是：未来的集成开发环境（IDE）会是什么样子？我倾向于认为它将是某种“集成思维澄清器”（integrated thought clarifier）。当您编写规范时，它会提取歧义并要求您澄清，从而真正澄清您的思路，使您和所有人类能够更有效地相互沟通意图，并将其传达给模型。

最后，我有一个寻求帮助的请求：什么是既易于处理又迫切需要规范化的领域？这涉及到大规模对齐代理。我非常喜欢这句话：“然后你才意识到，你从未告诉它你想要什么，也许你从未完全理解自己想要什么。”这正是在呼唤规范。OpenAI已经成立了一个新的代理鲁棒性团队。请加入我们，帮助我们为全人类的利益交付安全的通用人工智能（AGI）。