在一个 AI 正在改变软件开发方式的时代，最有价值的技能不再是写代码——而是精准表达意图。这场演讲揭示：作为编程基本单元的，正逐步从“提示（prompt）或代码”转向“规范（spec）”，以及为什么撰写规范正在成为新的超级能力。
基于生产环境的经验，严格的、带版本的规范如何作为“单一真实来源”，可以“编译”成文档、评测、模型行为，甚至也许还能编译成代码。
就像美国宪法充当一个带版本的规范，并由司法审查作为“评分器”一样，AI 系统需要可执行的规范，使人类团队与机器智能在同一轨道对齐。我们将以 OpenAI 的 Model Spec 作为现实世界的例子来讨论。
最后，我们会以若干开放问题结束：在一个“沟通”再一次成为工程中最重要产物的世界里，开发者工具的未来会是什么样子。
关于 Sean Grove：
Sean Grove 在 OpenAI 负责 alignment reasoning（对齐推理）工作，帮助把高层意图翻译为可执行的规范与评测。加入 OpenAI 之前，他创办了 OneGraph —— 一个 GraphQL 开发者工具初创公司，后来被 Netlify 收购。他已在全球做过数十场关于开发者工具、API、AI 用户体验与设计、以及如今对齐（alignment）方面的技术演讲。演讲在旧金山的 AI Engineer World's Fair 上录制。
评论节选：
多听你们产品经理（PM）的，并在需求文档上迭代。
“规范（spec）”其实就是需求文档；别再直接“凭感觉写代码（vibe coding）”或只做结对编程，而是通过不断更新需求文档来与智能体进行“vibe coding”。提示工程（prompt engineering）没有死，他只是希望它提升到更高抽象层并可复用。那个“天上馅饼”的愿景是把写代码的人转成维护该文档的“PM”，但他没有给出这在现在能够真正自主运行的证据，而且还提到这些需求文档同样很多是在协调人。
他确实概述了他们在 4o 上使用的基本更新流程，但那里没有特别创新的东西（随着需求文档变化添加/更新打分器（scorers））。
他称之为“specs”——我称之为“Digital Notebooks（数字笔记本）”：一个带有指令的结构化文档。
原文
新代码与规范的时代
大家好，非常感谢大家的邀请。身处此处，我感到非常兴奋，这是一个激动人心的时代。这两天过得相当紧张，不知道你们是否有同感，但同时也充满了活力。
今天我想和大家聊聊我所看到的**“新代码的到来” ，特别是关于规范**。它承载着一个行业的梦想：一次编写意图，便可四处运行。
我将简单介绍一下自己：我叫肖恩，在 OpenAI 从事对齐研究。今天，我将深入探讨代码与沟通的价值，并解释为什么规范可能是一个更优越的方法。
我们将从规范的解剖开始，以 OpenAI 的模型规范为例。然后，我们会探讨如何向人类传达意图，并以近期发生的“40 sycophancy 问题”作为案例进行深入分析。此外，我们还将讨论如何使规范可执行，如何将意图传达给模型，以及如何将规范视为代码——尽管它们有所不同。最后，我们还会提出几个引人深思的开放性问题。
代码与沟通：瓶颈何在？
请各位举手，如果你写代码（“氛围代码”也算）。好的，那现在，如果你的工作核心就是编写代码，请继续举手。最后，对于那些仍在举手的朋友，如果你认为你产出的最有价值的专业成果是代码，请继续保持。
我看到很多人举手，这很自然。我们都投入巨大的努力去解决问题：与人交流、收集需求、思考实现细节、整合各种资源，最终产出的就是代码。代码是我们可以直接看到、衡量、讨论和辩论的具体产物。
然而，这在一定程度上低估了大家工作的真正价值。代码只贡献了你所带来价值的 10% 到 20%，而其余 80% 到 90% 的价值，体现在结构化沟通上。
一个典型的流程通常是这样的：你与用户深入交流，理解他们的挑战；将这些故事提炼，构思解决方案；明确你想要达成的目标；规划实现这些目标的方法；与同事分享你的计划；将这些计划转化为代码；然后进行测试和验证。请注意，我们验证的并非代码本身，而是代码运行后是否真正达到了既定目标，是否有效缓解了用户的难题。
因此，交流、理解、提炼、构思、规划、分享、转化、测试、验证——在我看来，这都是结构化沟通的范畴。而正是这种结构化沟通，才是真正的瓶颈所在。
知道要构建什么，与人有效交流并准确收集需求，明确如何构建，理解为何要构建，以及最终判断它是否正确构建并达到了预期意图——这些环节都构成瓶颈。随着人工智能模型的日益先进，我们每个人都将更深刻地感受到这一瓶颈的存在。
在不远的将来，**沟通能力最强的人，将是价值最高的程序员。**毫不夸张地说，如果你能有效沟通，你就具备了编程的能力。
“氛围编程”的启示与规范的重要性
让我们以当下流行的“氛围编程”（Vibe Coding）为例。这种编程方式通常让人感觉良好，原因何在？因为“氛围编程”的本质是沟通优先，而代码实际上是沟通之后次要的产物。我们只需描述我们的意图和期望的结果，模型便能为我们承担大量的繁重工作。
然而，我们进行“氛围编程”的方式却有些奇怪。我们通过提示与模型沟通，向它们传达我们的意图和价值观，最终得到代码。但通常情况下，我们会在得到代码后将那些提示丢弃，它们是短暂的存在。
如果你写过 TypeScript 或 Rust，当你的代码经过编译器生成二进制文件后，没有人会仅仅满足于那个二进制文件。我们总是从源代码规范重新生成二进制文件。源代码规范，才是真正有价值的产物。
然而，当我们给 AI 模型提供提示时，我们却反其道而行之：我们保留了生成的代码，却删除了原始提示。这就像你销毁了源代码，然后却极其谨慎地对二进制文件进行版本控制。
这正说明了为什么在规范中捕捉意图和价值观是如此重要。一份书面规范能够使人类在共同的目标上保持一致，并确认大家是否真正同步了需要完成的任务。它是你进行讨论、辩论、参考和达成共识的基石。
所以，我必须强调一点：一份书面规范能够有效地使人类达成一致，它是你用来沟通、讨论、辩论、参考和同步的核心产物。如果你没有规范，你只有一个模糊不清的想法。
规范的强大力量
为什么说规范通常比代码更强大呢？因为代码本身实际上是规范的一种有损投影。 这就好比你反编译一个 C 语言的二进制文件，你不会看到整洁的注释和清晰命名的变量。你必须倒推，试图揣摩开发者当初的意图，以及代码为何如此编写。这些深层意图并未直接包含在代码中，这是一种有损的转换。
同样，代码本身，即使是精心编写的代码，通常也无法完全体现所有的意图和价值观。你阅读代码时，仍需推断这个团队最终想要实现的目标是什么。
因此，沟通——也就是我们在书面规范中所建立的工作——比代码本身更为优越。 它实际上编码了生成代码所需的所有必要条件。
就像将源代码传递给编译器可以针对多种不同的架构（如 ARM 64、x86 或 WebAssembly）进行编译一样，源文档本身就包含了足够的信息来描述如何将其转换为目标架构。
同理，一个足够健壮的规范，一旦提供给模型，将能生成高质量的 TypeScript 代码、健壮的 Rust 服务器、功能完善的客户端、清晰的文档、实用的教程、引人入胜的博客文章，甚至是有趣的播客。
请举手，在座各位谁的公司是以开发者为客户的？好的。试想一下，如果你把公司的整个代码库，所有运行业务的代码和文档，都输入到一个播客生成器中，它能否生成出足够有趣和引人入胜的内容，告诉用户如何成功实现他们的目标？还是说所有这些关键信息都分散在其他地方？它实际上并不在你的代码中。
因此，展望未来，稀缺的技能将是编写能够全面捕捉意图和价值观的规范。 谁能精通此道，谁就将再次成为最有价值的程序员。很有可能，这正是当今的编码者们所擅长的，与我们目前的工作方式非常相似。
然而，不仅是程序员，产品经理也会编写规范，立法者也会制定法律规范。这实际上是一个普遍的原则。
OpenAI 模型规范：一个活生生的例子
带着这个理念，我们来看看规范究竟长什么样。我将以 OpenAI 的模型规范为例进行说明。去年，OpenAI 发布了这份模型规范。
这是一份活文档，旨在清晰明确地表达 OpenAI 希望其向世界发布的模型所承载的意图和价值观。它在今年二月进行了更新并开源了。
大家可以访问 GitHub，亲自查看模型规范的实现。令人惊讶的是，它实际上只是一系列 Markdown 文件，就像这个样子。
Markdown 这种格式非常出色：它人类可读，支持版本控制和变更日志。更重要的是，由于它采用自然语言编写，不仅是技术人员，包括产品、法律、安全、研究、政策等所有部门的人员都可以参与贡献，他们都能阅读、讨论、辩论并贡献到同一份源代码中。它是公司内部统一所有人类意图和价值观的通用产物。
尽管我们可能努力使用明确的语言，但有时表达细微之处仍然非常困难。因此，模型规范中的每个条款都有一个 ID，比如这里的 sy73。
利用这个 ID，你可以在代码库中找到另一个文件，sy73.md，其中包含了针对该条款的一个或多个具有挑战性的提示。所以，文档本身实际上编码了成功标准，测试中的模型必须能够以符合该条款的方式给出回答。
案例分析：GPT-4 的“阿谀奉承”问题
让我们来谈谈最近 GPT-4 更新后出现的**“阿谀奉承”（Sycophancy）问题**。在这种情况下，模型规范发挥了怎样的价值呢？
模型规范的核心作用，在于使人类在特定的价值观和意图上达成共识。这里有一个关于“阿谀奉承”的例子：用户指出模型的行为过于谄媚，牺牲了客观公正的真相。然而，模型却非常友好地赞扬了用户的洞察力。
其他一些受人尊敬的研究人员也发现了类似令人担忧的例子。以这种方式输出奉承内容，会侵蚀信任，这让人感到不适。
这引发了许多疑问：这是故意的吗？是意外吗？为什么没有被及时发现？幸运的是，模型规范自发布以来就包含了一个专门针对此的部分，明确指出：“不要奉承。” 它解释说，虽然奉承在短期内可能让人感觉良好，但从长远来看，它对所有人都无益。
所以，我们实际上通过这份规范表达了我们的意图和价值观，并成功地将其传达给了其他人，以便大家可以参考。
如果我们的模型规范是大家公认的意图和价值观的集合，而模型的行为与此不符，那么这无疑是一个bug。所以我们进行了回滚，发布了一些研究和博客文章，并最终修复了问题。在此期间，规范充当了信任的锚点，它是一种向人们清晰传达预期行为和非预期行为的方式。
如果模型规范唯一的作用就是使人类在这些共同的意图和价值观上达成一致，那么它就已经非常有用了。但理想情况下，我们还可以使我们的模型及其生成的产品也与相同的规范保持一致。
让规范可执行：与模型对齐
我们发布了一篇名为**“深思熟虑的对齐”（Deliberative Alignment）** 的论文，其中探讨了如何自动对齐模型。这项技术是这样的：你将你的规范和一组极具挑战性的输入提示，从正在测试或训练的模型中进行采样。
然后，你获取模型的响应、原始提示和既定策略，并将它们提供给一个更高级的模型，要求它根据规范对响应进行评分：它与规范的对齐程度如何？
这样一来，文档本身就同时成为了训练材料和评估材料。 根据这个分数，我们就可以强化模型的权重。
你可以将规范包含在上下文以及系统消息或开发者消息中，并在每次采样时都这样做，这确实非常有用。通过提示进行对齐的模型会表现出一定程度的一致性，但这会分散用于解决模型核心问题的计算资源。
请记住，这些规范可以是任何内容。它们可以是 代码风格指南、测试要求，甚至是安全要求。 所有这些都可以嵌入到模型中。
通过这项技术，你实际上将原本需要在推理时进行的计算，下推到了模型的权重中。这样，模型便能真正地“感受”你的策略，并以一种 肌肉记忆式 的方式将其应用于手头的问题。
将规范视为代码：一种新的编程范式
尽管我们看到模型规范只是 Markdown 文件，但将其视为代码却非常有用，两者之间有着惊人的相似之处。这些规范可以组合，它们是可执行的（正如我们所见），它们是可测试的，它们有接口（它们连接真实世界），并且它们可以作为模块发布。
每当你处理模型规范时，都会遇到许多与编程类似的问题。就像编程中有类型检查器旨在确保一致性一样，如果部门 A 编写的规范与部门 B 编写的规范之间存在冲突，你会希望能够及时发现并可能阻止该规范的发布。
正如我们所看到的，策略实际上可以包含自己的单元测试。你也可以想象各种代码检查工具（linters） ，如果你的语言过于模糊，那就会混淆人类和模型，导致最终产出的结果不尽人意。所以，规范实际上为我们提供了一个非常相似的工具链，但它针对的是意图，而非语法。
立法者即程序员：普遍的对齐原则
让我们来谈谈立法者作为程序员的概念。美国宪法本质上就是一个国家层面的模型规范。它拥有书面文本，至少在理想状态下，它是清晰明确的政策，供我们所有人参考。这并非意味着我们必须完全同意它，而是我们可以将其视为当前的现状。
它具备一套版本化机制，可以进行修正，发布更新。还有司法审查，其作用类似于一个评分者，评估具体情况与既定政策的对齐程度。
尽管源代码政策旨在明确无歧义，但有时世界是复杂的，可能会出现意料之外的情况，导致某些案例无法直接套用。在这种情况下，司法审查会投入大量的计算（思考），以理解法律如何适用于此。一旦裁决，它便设立了一个先例。这个先例实际上就是一个输入-输出对，它作为一个单元测试，消除了歧义，并进一步强化了原始政策规范。
宪法还包含指挥链等机制。随着时间的推移，它的执行形成了一个训练循环，帮助我们所有人朝着共同的意图和价值观对齐。
所以，这是一份能够传达意图、裁决合规性并以安全方式演进的产物。因此，立法者很可能成为程序员，反之亦然——程序员也可能成为未来的立法者。
人人都是规范作者
这实际上是一个非常普遍的概念。程序员通过代码规范来对齐他们的程序。产品经理通过产品规范来对齐团队。立法者则直接通过法律规范来对齐人类社会。
我们房间里的每个人，当你发出一个提示时，它就是一种原始规范。你正在致力于将人工智能模型对齐到一组共同的意图和价值观上。无论你是否意识到，你都是这个世界上的规范作者。
规范让你能更快、更安全地交付产品。 每个人都可以为此贡献力量。无论是产品经理、立法者、工程师还是市场营销人员，谁编写规范，谁就是现在的程序员。
软件工程从来都不是仅仅关于代码的。回想我们最初的问题，很多人都放下了手，因为他们认为自己产出的不仅仅是代码。工程从来就不是这样。
编码固然是一项令人惊叹的技能和宝贵资产，但它并非最终目的。工程，是人类对人类问题软件解决方案的精确探索。 一直以来都是如此。我们只是从分散的机器编码，转向了一种统一的人类编码方式，来更好地解决这些问题。
感谢乔什对此的贡献。
未来展望与行动呼吁
我想邀请大家将这些思考付诸实践。当你开始下一个 AI 功能开发时，请从规范开始。
你到底期望发生什么？成功的标准是什么样的？请深入讨论它是否已经清晰地书写并传达出来。让你的规范变得可执行。将规范输入到模型中，并针对模型进行测试，或直接针对规范进行测试。
在这个新世界中，有一个有趣的问题：既然编程和规范编写有如此多的相似之处，那么未来的**集成开发环境（IDE）会是什么样子？我希望能有一个类似“集成思维澄清器”**的东西。当你编写规范时，它能自动识别模糊之处，并引导你进行澄清，从而真正理清你的思绪，让所有人类都能更有效地相互传达意图，并清晰地传达给模型。
最后，我有一个请求：什么领域是既适合又迫切需要规范的呢？这正关乎大规模对齐代理。
我很喜欢这句话：“然后你意识到你从未告诉它你想要什么，也许你从未完全理解它。”这正是对规范的迫切呼唤。
我们成立了一个新的代理健壮性团队，所以请加入我们，帮助我们为全人类的福祉，提供安全的人工智能！谢谢大家！我很乐意和大家交流。
