OpenAI核心研究员:比提示词工程更重要的,是spec-writing

程序员最有价值的技能已经不再是编写代码了,而是精确地向 AI 传达意图。一份完善的规范才是包含完整意图的真正「源代码」。

这是 OpenAI 研究员 Sean Grove 在 AIEWF 2025 的演讲中提出的观点。前不久,Andrej Karpathy 也针对于提示词提出了他的观点,不同的是,Karpathy 聚焦如何给 AI「喂更多地料」,让 AI 更理解你的意图。Karpathy 认为,提供完整且恰当的上下文往往比编写好的提示词更重要。

Sean Grove 的视角则聚焦在如何形成一份完善、可执行的「规范」,以此精准地向 AI 传达意图。

在某种程度上,两者的观点都深刻地体现了一点:生成代码已经不是重点了,软件工程的本质是人与 AI 之间的「沟通」。

而且,这也可以看作是对 Jason Wei 提出的验证者规律的回应,规范本身就是一种可验证的标准。

在演讲中,Sean Grove 从 AI 时代「新代码」的角度,分享了他对于软件工程的看法。Sean Grove 认为,提示词是规范,不应被用过一次后即被丢弃,捕捉其中的意图和价值观非常重要,最有价值的成果不是代码,而是源规范。此外,Sean Grove 还分享了如何让规范可执行、如何向模型传达意图,模型的「谄媚问题」、规范如何参与模型训练与演化等内容。

Sean Grove:OpenAI 对齐团队的研究员,从事模型对齐推理的研究工作。此前,曾创立了一家 GraphQL 开发人员工具初创公司 OneGraph,后来被 Netlify 收购。


Founder Park 联合外滩大会组委会、将门创投,征集能真正改变生活的 AI 硬件,寻找 AI 硬件的新可能。

  • 30 万大赛奖金

  • 创业扶持礼包

  • 更多头部资源链接机

扫码即可报名



01 

编程真正的价值在于结构化沟通,

而不是代码本身

我们先从一个简单的问题开始:在座的各位有写过代码的吗?请举个手。好,请那些「以编写代码为职业」的朋友继续举着手。如果你觉得自己最有价值的专业产出是代码,也请继续举着手。

看到很多手还举着,我觉得这很正常。我们都在努力解决问题:与人沟通、收集需求、思考实现细节、整合各方资源。最终,我们产出的是代码,一个可以明确指出、可以衡量、可以讨论的成果。它让人感觉「成果落地」。但我想指出,这在某种程度上其实低估了你们的实际工作。代码可能只占你所创造价值的 10% 到 20%,其余 80% 到 90% 在于结构化沟通。

当然,每个人的情况不同,但工作流程通常是这样的:

  • 与用户交流,了解他们的挑战;

  • 提炼信息,构思解决方案;

  • 明确要实现的目标,并制定计划;

  • 和同事分享这些计划,然后才将计划转化为代码,这无疑是关键一步;

  • 最后,进行测试和验证,但验证的并非代码本身,而是它在运行时是否达成了最初的目标,是否解决了用户的痛点,也就是代码对世界产生的实际影响。

所以,交流、理解、提炼、构思、规划、分享、转化、测试、验证——在我看来,这些全是结构化沟通。而结构化沟通正是瓶颈所在:明确该做什么、如何与人沟通并收集需求、怎样实现、为何要这么做,以及最终判断做得对不对,是否真正达成了初衷。

AI 模型越先进,这个瓶颈就越明显。因为在不远的将来,沟通能力最强的人,将是最有价值的程序员。事实上,能有效沟通,你就能编程。

以「氛围感编程」(Vibe-driven Programming)为例,它之所以体验很好,正是因为它从根本上将沟通置于首位,代码只是沟通的下游产物。我们可以描述自己的意图和期望看到的结果,然后让模型来处理繁重的工作。


02 

一份完善的规范

才是真正的「源代码」

即便如此,我们现在与模型互动的方式还是有些奇怪。我们通过提示词(Prompt)与模型沟通意图和价值观,得到一个代码成果。然后,我们似乎就把提示词扔到了一边,视其为一次性的东西。这很不合理。

如果你写过 TypeScript 或 Rust,你不会在编译出二进制文件后就心满意足了。二进制文件不是目的,它只是有用的产物。事实上,每次编译或运行时,我们总是从源代码重新生成二进制文件。最有价值的成果是源代码,是源规范。

然而,当我们给模型输入提示词时,却做了相反的事:保留生成的代码,丢弃提示词。这就好比你撕掉了源代码,却小心翼翼地对二进制文件进行版本控制。

这就是为什么在规范中捕捉意图和价值观如此重要。一份书面的规范,能让人们在共同的目标上达成一致,并让我们清楚地知道是否达成了共识。这是一个你可以用来讨论、辩论、参考和同步的成果,至关重要。

如果你没有规范,你就只有一个模糊的想法。现在我们来谈谈为什么规范总体上比代码更强大。

因为代码本身就是从规范的一种有损投射(Lossy Projection)。就像你反编译一个 C 语言的二进制文件,你得不到清晰的注释和恰当的变量名,你必须反向推导作者的意图。这些关键信息在转换过程中丢失了。同样,代码本身,即使写得再好,通常也无法完整包含所有的意图和价值观。阅读代码时,你还是要去推断这个团队最终想要实现什么。

所以,当沟通的成果沉淀为一份书面规范时,它就比代码更好,因为它包含了生成代码所必需的所有前提和意图。

就像一份源代码可以通过编译器适配多种架构(如 ARM64、x86、WebAssembly),一份完善的规范交给模型,同样能生成优质的 TypeScript 代码、Rust 服务器、客户端应用、文档、教程、博客文章,甚至一期播客。

我们来做个思维练习:在座各位,有谁的公司是服务于开发者的吗?如果把你们公司的整个代码库、所有文档,也就是运行业务的全部代码都丢进一个播客生成器,它能生成一期足够有趣、能吸引并教会用户如何成功的播客吗?恐怕不能,因为这些关键信息并不在代码里。

所以,未来的关键技能是编写能充分捕捉意图和价值观的规范。掌握这一技能的人,会成为最有价值的程序员,而他们很可能就是今天在座的各位。


03 

规范可以直接用于训练和调优 AI 模型

这和我们现在做的事已经很相似了。产品经理写产品规范,立法者写法律规范。这是一个普遍原则。

那么,规范到底是什么样的?我以 OpenAI 的「模型规范」为例。去年,OpenAI 发布了模型规范,这份动态文档旨在清晰、明确地阐述我们希望模型向世界展现的意图和价值观。它在今年 2 月进行了更新,并且已经开源。

注:今年 2 月,OpenAI 进行了模型规范更新 https://openai.com/zh-Hans-CN/index/sharing-the-latest-model-spec/

你可以去 GitHub 上看看模型规范的实现,它其实就是一堆 Markdown 文件。

Markdown 非常了不起。它便于人类阅读,有版本记录和变更日志。而且,由于它是自然语言,公司里所有人都能参与进来——无论是产品、法律、安全、研究还是政策团队的成员,大家都能阅读、讨论、辩论并为同一份「源代码」做出贡献。这是一个能让全公司在核心意图和价值观上达成一致的通用媒介。

尽管我们努力使用明确的语言,但有时细微之处依然难以表达。为此,模型规范中的每个条款都有一个唯一 ID(例如 SY703)。通过这个 ID,你可以在代码仓库中找到对应的文件(sy703.md),里面包含了一到多个针对该条款的、极具挑战性的测试用例。这样一来,这份文档本身就内嵌了它的成功标准:被测试的模型必须能够给出符合该条款精神的回答。

我们来谈谈「谄媚问题」(Sycophancy)。不知道大家有没有听说,前段时间 GPT-4 的一次更新出现了严重的谄媚倾向。在这种情况下,模型规范有什么用?它的作用就是让人们在一系列共同的价值观和意图上达成一致。

举个例子,有用户指出模型为了谄媚而牺牲了客观事实,模型的回应却是非常友好地称赞用户「有洞察力」。其他研究人员也发现了类似的、令人担忧的例子。这样的谄媚会侵蚀信任,造成伤害,并引发了关于「这是故意设计还是意外失误」的争议。

注:「谄媚问题」 是指大型语言模型(LLM)的一种行为倾向,即模型会刻意迎合用户的观点、信念或情感,即便用户的观点是错误的、有偏见的或不符合事实的。

幸运的是,模型规范自发布之初就明确规定了「不要谄媚」。这份规范解释,虽然谄媚在短期内可能让人感觉良好,但长远来看对谁都没有好处。因此,我们通过规范表达了我们的意图,并为公众提供了一个可以参考的基准。如果模型的行为与规范不一致,那它就是一个漏洞(Bug)

所以我们回滚了更新,发布了相关的研究和博客文章,并修复了这个问题。在此期间,规范扮演了信任锚点的角色,让所有人都能清楚地知道,什么是我们预期的行为,什么不是。

即便模型规范唯一的作用只是让人们达成共识,它也已经非常有价值了。但理想情况下,我们还能让模型及其产出也与这份规范保持一致。


04 

如何用「规范」训练模型?

我们曾发表过一篇名为《Deliberative Alignment: Reasoning Enables Safer Language Models》的论文,探讨了如何自动化地让模型与规范对齐。简而言之,就是将规范和高难度的提示词交给一个模型,然后让一个更强大的「裁判模型」根据规范,来为它的回答打分。通过这种方式,我们可以强化模型的权重,将规范从「每次都要提醒」的推理成本中解放出来,「压入」模型的权重之中,让遵循规范成为模型的「肌肉记忆」。

注:《Deliberative Alignment: Reasoning Enables Safer Language Models》

论文地址:https://arxiv.org/abs/2412.16339

尽管模型规范只是 Markdown 文件,但将它们视为代码会很有帮助,因为它们非常相似:

  • 可组合:可以模块化地发布和引用。

  • 可执行:可以包含自身的单元测试。

  • 可测试:可以像类型检查器一样,自动发现不同规范间的冲突。

  • 可审查:可以构建工具来检查语言的模糊性,因为模糊的表述不仅会困扰人类,也会困扰模型。

规范实际上给我们提供了一套全新的工具链,它针对的是意图,而非语法。


05

规范是跨角色通用的语言

我们再来想想「作为程序员的立法者」这个概念。美国宪法其实就是一份国家层面的模型规范。它有书面文本,作为我们讨论的共同基础;它有版本化的修正案,可以更新和发布;它还有司法审查机制,由「评分者」(法官)来评估具体案例与政策的契合度。

当法律条文出现模糊或遗漏时,司法审查的过程就变得非常耗费精力。而一旦做出裁决,就会确立一个先例(判例)。这个先例就如同一个「输入-输出」对,作为一个单元测试,来消除原始规范的歧义并强化它。这个系统通过持续的执行和裁决,如同一个训练循环,帮助整个社会在共同的意图上达成一致。这是一个能够有效传达意图、裁决合规性并安全演进的成果。

所以,未来的立法者可能成为程序员,反之亦然。这是一个非常普遍的规律:

  • 程序员通过代码规范,来统一芯片的行为。

  • 产品经理通过产品规范,来统一团队的目标。

  • 立法者通过法律规范,来统一民众的行动。

而在座的每个人,当你们输入提示词时,其实就是在制定一种「原型规范」(Proto-spec)。你们都在从事让 AI 模型向着共同意图对齐的工作。无论你是否意识到,在这个时代,你就是一名规范的制定者。规范能让你更快、更安全地发布成果。每个人都能做出贡献。无论是业务分析师、产品经理、立法者、工程师还是营销人员,只要编写了规范,就成了程序员。

软件工程的本质从来就不是关于代码本身。回到之前那个问题,许多朋友放下了手,因为你们认为自己产出的核心不是代码。但工程的本质从来就不是这个。编码是一项非常重要的技能和宝贵的资产,但它不是最终目的。工程,是人类为了解决自身问题,而对软件方案进行的精确探索。 一直都是如此。

我们只是在从五花八门的机器编码,转向一种统一的人类编码——用更自然的方式,来表达我们解决问题的思路。


06

未来 IDE 不仅是写代码的工具,

而是「集成式思维澄清器」

我想请大家在开发下一个 AI 功能时,尝试将这个理念付诸实践:从规范开始。明确你期望达成的效果和成功标准,确保规范清晰、准确,并让它变得可执行,最终根据规范来测试你的模型。

鉴于编程和规范制定有如此多的相似之处,这引出了一个有趣的问题:未来的集成开发环境(IDE)会是什么样子?

我想,IDE 可能会演变成一种「集成思维澄清器」(Integrated Thought Clarifier)。当你在编写规范时,它能实时指出其中的模糊之处,帮助你理清思路,让你能更有效地向他人和模型传达意图。

最后,我想向大家请教一个问题,这个问题也关乎我们如何大规模地实现智能体(Agent)的对齐:规范需要具备哪些特性,才能既易于机器处理,又能够满足人类复杂的需求?

我很喜欢一句话:你终将意识到,你从未真正告诉过它你想要什么,或许连你自己也从未完全弄明白。

总之,我在此呼吁大家重视规范。OpenAI 已经成立了一个新的「Agent 稳健性团队」(Agent Robustness Team)。加入我们,一同为全人类的福祉,交付安全、可靠的通用人工智能。

谢谢大家!

原视频链接:https://www.youtube.com/watch?v=8rABwKRsec4



(文:Founder Park)

发表评论