2025.09.21

新代码时代：规范Spec是如何重塑编程与沟通的？

AI编程·规范驱动开发·AI

Sean Grove 在 OpenAI 负责对齐推理工作，他在 2025 年 AI Engineer World's Fair 上的演讲《The New Code》提出了：

在 AI 时代，软件开发的正在从“编写代码”转向“编写（Specification）”，清晰表达意图的能力将成为新的稀缺技能。这是他演讲的原文，对于所有使用用ai ide的开发者都值得一看。

大家好！

今天，我想跟大家探讨一下我所见证的“新代码”时代的来临，尤其是与规范（specifications）相关的内容。这一概念，承载着我们行业长期以来的梦想：编写一次，随处运行。

我是Sean，在OpenAI的超级对齐研究团队工作。接下来，我会深入探讨代码与沟通的重要性，以及为何遵循规范或许是更好的选择。

先问大家一个问题，有多少人日常工作是编写代码的？无论哪种形式的代码，都可以举手示意一下。

好的，现在，请那些认为自己工作中产出的最有价值的专业成果就是代码的朋友，继续保持举手。我看到有不少人举手，这其实很自然。

我们在工作中，总是努力地解决各种问题，与他人沟通交流、收集需求、深入思考实现细节，还要集成多种系统，最终产出的成果就是代码。

代码是我们能够实实在在指认、衡量、辩论和讨论的产物，它给人的感觉非常具体和真实。

但事实上，这种认知低估了我们每一位工程师所做工作的真正价值。代码，大约只占我们创造价值的10%到20%，另外80%到90%的价值，其实在于结构化的沟通。

大家不妨回想一下我们日常的工作流程：

首先，我们会与用户交谈，了解他们面临的挑战；接着，提炼这些讨论内容，构思具体的解决方案来缓解这些挑战；

然后，规划实现这些目标的方法，并与同事分享这些计划；再将这些计划转化为代码，这当然是很关键的一步；

最后，进行测试和验证，但我们真正关心的并非代码本身，而是代码运行时，是否达成了最初设定的目标，是否缓解了用户的挑战，也就是关注代码对世界产生的实际影响。

所以说，交谈、理解、提炼、构思、规划、分享、转化、测试、验证，这些环节本质上都是结构化的沟通。而这，恰恰就是整个工作流程中的瓶颈所在。

随着AI模型越来越先进，我们会更加深刻地感受到这个瓶颈的存在。因为在不久的将来，那些最擅长沟通的人，将会成为最优秀的程序员。

毫不夸张地说，如果你能有效沟通，你就能编程。就拿现在流行的“vibe - coding”（氛围编程）来说，这种编程方式通常让人感觉很棒，为什么呢？因为它的本质是沟通优先，代码是沟通之后产生的结果。

我们通过提示词（prompt）与语言模型沟通，描述我们想要的结果，然后让模型去处理那些繁琐的底层工作。

然而，这里面有个奇怪的现象，我们辛辛苦苦写下包含意图和价值观的提示词，得到代码后，却把提示词扔掉了，觉得它们是短暂的、一次性的，没有保留价值。

这就好比，当你编写TypeScript或者Rust代码，把代码通过编译器生成一个二进制文件后，没有人会仅仅为了那个二进制文件而庆祝，它只是一个有用的中间产物。

我们真正看重的，是可以重新生成程序的源规范（source spec），它才是有价值的产物。但在和大语言模型（LLM）互动时，我们却反其道而行之，保留了生成的代码，删掉了提示词。

这就像把原始设计图纸撕碎，却小心翼翼地对最终的二进制文件进行版本控制，显然是不合理的。所以，把意图和价值观记录在一个规范里是非常重要的。

一份书面规范，是能够让人类达成共识的工具，是我们用来讨论、辩论、引用和同步的重要产物。我想再次强调：一份书面规范，能够对齐人类，它是你沟通、讨论、辩论、引用和同步的依据。

如果没有规范，你拥有的就只是一个模糊的想法，无法准确传达给他人，也难以指导后续的工作。

接下来，我们深入探讨一下为什么规范在总体上比代码更具力量。

实际上，代码本身是从规范到实现的一种“有损投影”（lossy projection）。就像你无法通过反编译一个C语言的二进制文件，完美还原出带有清晰变量名和注释的原始C语言源代码一样。你只能反向推断，猜测当初编写代码的人想做什么，为什么代码要这么写，因为那些原始的意图信息在编译过程中已经丢失了。

同样，代码本身，哪怕是写得非常好的代码，通常也无法完全承载所有的意图和价值观。当你阅读代码时，还是必须去推断，这个团队写下这段代码时，最终的目标是什么。

所以说，当我们把沟通的成果体现在一个规范里时，它就比代码更优，因为它无损地包含了生成代码所需的所有信息。

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

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

我来做个思想实验，在座有多少人是在为开发者提供工具的公司工作？如果你是一家开发者工具公司，你能否利用你的代码库，生成一个你的用户会感兴趣的播客？恐怕很难，因为所有能支撑这个播客的深层信息，其实并不在你的代码里，而是在那些被你忽视的规范中。

鉴于此，未来一项日益稀缺的技能，便是撰写能够全面捕捉意图与价值观的规范。掌握此项技能的人，将成为最有价值的程序员。

而且，不仅是程序员，产品经理和立法者其实也在撰写各自的规范，比如产品规范、法律规范，这揭示了一个普遍性的原则，规范在各个领域都有着重要的作用。

为了让大家对规范有更具体的认识，我以OpenAI 的模型规范为例进行说明。

OpenAI去年发布了这份模型规范，它是一份“活文档”，目的是清晰、明确地表达OpenAI希望赋予其发布模型的意图与价值观，今年二月进行了更新并实现开源。

大家如果访问GitHub，会惊讶地发现，它实际上仅由一系列Markdown文件构成。Markdown作为一种标记语言，优点非常明显，它易于人类阅读，支持版本控制与变更日志。

更重要的是，由于它基于自然语言，所以不仅技术人员，包括产品、法务、安全、研究以及政策制定等部门的全体人员，都能够参与阅读、讨论、辩论，并共同为此“源代码”做出贡献。这份文档成为了公司内部统一所有人对意图与价值观认知的通用载体。

尽管我们力求使用明确无歧义的语言，但在某些情况下，表达细微之处仍极具挑战。为此，模型规范中的每个条款都设有一个唯一的ID，例如此处的“sy73”。通过这个ID，你可以在存储库中找到另一个名为“sy73.md”的文件，该文件包含一个或多个针对此特定条款的挑战性提示。

也就是说，这份文档本身实际上编码了成功的评估标准，确保受测模型能够以完全符合该条款要求的方式进行响应。

最近，GPT4.0 的一次更新，导致了极端谄媚行为的出现，引发了广泛关注。比如，在某个案例中，用户明确指出模型为了迎合而牺牲了公正的真相，然而模型却“非常友善”地对用户的“洞察力”表示了赞扬。其他研究人员也发现了类似令人担忧的案例，这种行为严重侵蚀了用户信任。幸运的是，模型规范自发布以来，便包含了一个专门针对此问题的条款：“不要谄媚”（Don’t be sycophantic），条款中明确解释了，虽然谄媚在短期内可能感觉良好，但从长远来看对所有人都很糟糕。

当模型表现出的行为与模型规范中商定的意图和价值观不一致时，很明显，这就是一个BUG。所以，OpenAI迅速回滚了更新，并发布了相关研究和博客文章。这个案例充分体现了模型规范在规范模型行为、保障用户体验方面的重要作用。

最后，我留下几个问题供大家思考。

第一，随着规范在软件开发中变得越来越重要，我们现有的开发工具和流程需要做出哪些改变，才能更好地支持规范的编写、管理和应用？

第二，对于不同规模和领域的项目，如何制定合适的规范标准和方法，以确保规范既能准确捕捉意图，又具有可操作性和可维护性？

第三，在团队协作中，如何更好地利用规范促进成员之间的沟通和协作，提高工作效率和质量？

谢谢大家！

我也开源了自己的SDD规范驱动开发的4个智能体的核心系统提示词，包括：

PRD构建者、

PRD评估器、

SPEC构建器、

Tasklist任务构建器。

https://github.com/Coldplay-now/SDD-Agent-Prompt