新代码时代:规范即代码,沟通即编程

开篇：为什么我要分享这个演讲

"软件工程从来不是关于代码，而是关于如何精准地理解和解决人类问题。"—— Sean Grove, OpenAI

大家好，我是 dtsola，一名 IT 解决方案架构师，也是一人公司的实践者。

今天我想和大家分享一个来自 OpenAI 的 Sean Grove 的演讲《The New Code》。当我第一次看到这个视频时，内心受到了强烈的震撼。

作为技术人员，我们习惯了用代码来衡量自己的价值，习惯了把"能写多少行代码"作为生产力的标准。但在 AI 快速发展的今天，这个认知正在被彻底颠覆。

Sean 的这个演讲，不仅重新定义了"编程"的本质，更为我们指明了在 AI 时代如何真正发挥技术人员的价值。对于像我这样的解决方案架构师和一人公司实践者来说，这个转变尤为重要——因为我们的核心价值从来不是写代码，而是理解问题、设计方案、协调资源。

接下来，让我们一起走进 Sean 的思考世界。

第一部分：代码 vs 沟通 - 重新认识工程师的价值

传统认知的挑战

Sean 在演讲开始时做了一个有趣的互动：

"请举手，如果你写代码并认为写代码算工作量？"——很多人举手。

"如果你们的工作就是写代码，请继续举着手。"——大部分人继续举手。

"如果你们认为工作中最有价值的成果是代码，请继续举手。"——这时，许多人放下了手。

这个简单的互动揭示了一个深刻的真相：我们都知道代码不是全部，但我们却习惯性地用代码来衡量自己的价值。

Sean 给出了一个颠覆性的观点：

代码仅占你贡献价值的 10% 到 20%，其余 80% 到 90% 在于结构化沟通。

代码是我们能指出来、衡量、争论和讨论的具体成果，它显得具体而真实。但这低估了我们每个人的工作价值。

软件开发的完整循环

真正的软件开发流程是什么样的？

1. 理解：与用户交流，了解他们的挑战
2. 提炼：从用户故事中提炼核心问题
3. 构思：想清楚要实现什么目标
4. 规划：制定实现目标的方案
5. 分享：与同事讨论和验证计划
6. 翻译：将计划转化为代码（这一步显然至关重要）
7. 测试：验证代码运行时是否达到了目标
8. 验证：观察代码对世界产生的影响
9. 迭代：回到理解、提炼、构思……

你会发现，在这个循环中，真正写代码只是其中一个环节。而且，我们测试和验证的并不是代码本身——没人真正在意代码本身，我们关心的是代码运行时是否达到了目标，是否缓解了用户的难题。

理解、提炼、构思、规划、分享、翻译、测试、验证——这些听起来都像是结构化沟通。

AI 时代的瓶颈转移

Sean 指出了一个关键趋势：

AI 模型越先进，沟通效率的瓶颈就越明显。因为不久的将来，沟通效率最高的人将成为最有价值的程序员。

只要你能有效沟通，就能编程。

以"氛围编程"（Vibe Programming）为例，它往往感觉相当不错。为什么？因为氛围编程本质上首先是关于沟通，代码反而是这种沟通的次要衍生品。我们只需描述我们的意图和期望的结果，然后让模型真正替我们处理繁琐工作。

但这种方式仍有些奇怪：

我们通过提示与模型交流，传达意图和价值观，最终生成代码产物，然后便将提示丢弃。

这就像你用 TypeScript 或 Rust 写完代码并编译后，没人会满意于只保留二进制文件。事实上，我们每次都从头重新生成二进制文件，源代码才是有价值的产物。

但当我们提示大模型时，却往往相反：

我们保留生成的代码却删除提示，这感觉就像你销毁源码，却小心翼翼地对二进制文件进行版本控制。

这显然是不对的。

第二部分：规范（Specification）的力量

规范优于代码的原因

为什么规范通常比代码更强大？

因为代码本身其实是从规范进行的一种有损映射。

就像你拿一个编译后的 C 语言二进制文件反编译，得不到清晰注释和命名良好的变量，只能倒推：这个人想做什么？为何这样写代码？这些信息并未保留，翻译过程已丢失。

同样，代码本身，即便是整洁的代码，通常也无法完全体现所有的意图和价值。读代码时，需要推断团队试图实现的最终目标。

规范的核心价值

因此，将意图和价值观明确记录下来至关重要。

一份书面规范能让团队在共同目标上保持一致，以及判断你是否对齐，是否真正就该做的事达成同步。这是你们讨论、争论、参考并保持同步的依据。

Sean 强调：

一份书面规范能有效协调人员，也是用于沟通讨论的核心依据。若无规范，你只能有模糊概念。

规范的可执行性

书面规范若能体现实际需求，便优于代码。因为代码实际上编码了生成代码所需的全部必要要求。

就像将源代码传递给编译器一样，你也能支持多种不同架构，可编译为 arm64、x86 或 WebAssembly。源文档其实已包含足够的信息来说明如何进行翻译到目标架构。

同样，一份足够完善的规范，提供给模型后将生成：

• 优质的 TypeScript
• 优质的 Rust
• 服务端代码
• 客户端代码
• 文档
• 教程
• 博客
• 播客

Sean 提出了一个发人深省的问题：

假设你把整个代码库、所有文档和代码、支撑你业务的所有内容输入播客生成器，能生成足够有趣且吸引人的内容，告诉用户如何成功、如何实现目标吗？那些信息难道其实在别处？其实并不在你的代码里。

第三部分：OpenAI 模型规范案例研究

模型规范的结构

去年，OpenAI 发布了模型规范（Model Spec），这是一份持续更新的文档，力求清晰明确地表达 OpenAI 的意图与价值观，希望将其模型赋予面向全球的价值理念。

今年二月，这份规范更新并开源，你可以去 GitHub 查看模型规范的实现。

不出所料，它其实只是一组 Markdown 文件。

Markdown 非常出色：

• 可读性强
• 有版本控制
• 有变更记录
• 由于它是自然语言，每个人，而不仅是技术人员，都能参与

涵盖产品、法律、安全、研究和政策，他们都能阅读、讨论、辩论并共同贡献同一份源代码。这是统一所有人意图与价值观的通用载体。

在公司内部，尽管力求使用明确的语言，但有时很难准确表达细微差别。因此，模型规范中的每一条款都有一个 ID（比如 sy73），通过该 ID 可找到另一个文件，包含一个或多个挑战性提示（challenge prompts）。

文档本身实际上编码了成功标准——模型必须能以符合要求的方式回答这些问题，才算遵循该条款。

实战案例：GPT-4o 的"谄媚"问题

最近 GPT-4o 版本有更新，它导致了严重的阿谀奉承问题。

用户指出，模型为了讨好而牺牲客观真相，还称赞用户见解独到。其他知名研究者也发现了类似令人担忧的案例。

这种方式迎合讨好会侵蚀信任，令人痛心。这也引发诸多疑问：这是有意为之吗？还是偶然的？为何没被发现？

幸运的是，模型规范中其实有专门章节说明此事。

自发布以来就明确指出：切勿谄媚。它说明谄媚虽能带来短暂满足，但短期看对大家都不好，长期更是如此。

因此，OpenAI 表达了意图与价值观，并借此向他人传达。一旦拥有在模型说明中的共同认可的意图与价值观，行为却与之不符，那这一定是个漏洞。

于是 OpenAI 回滚并发布了一些研究，修复了问题。

在此期间，这些规范起到了信任锚点的作用——一种向人们传达预期以及哪些不被期望的方式。

第四部分：让规范可执行 - Deliberative Alignment

意料之外的是，若模型规范所做的仅仅是使人类在这些共性上保持一致，若能明确意图与价值观，就已经极为有益。

但理想情况下，我们还能使模型及其产出与这些意图和价值观保持一致，符合同一标准。

深思对齐技术

OpenAI 发布了一种名为"深思对齐"（Deliberative Alignment）的技术论文，探讨如何自动对齐模型。

该技术的工作流程：

1. 采用你的规范设定，以及一组极具挑战性的输入提示
2. 从测试或训练中的模型采样
3. 取其回应和原始提示，连同策略一并交给更大的模型
4. 让其对回复进行评分——根据规范，它有多符合？
5. 文档实际上成了训练材料与评估材料
6. 根据得分调整这些权重
7. 据此从你的规范开始迭代优化

从推理时计算到模型权重

在上下文中，可能是系统消息或开发者每次采样时的消息。提示模型会有所对齐，但会耗费算力。

规范可以是代码风格、测试需求、安全要求等任何内容，均可嵌入模型中。

通过该技术，你将原本在推理时的计算转为嵌入模型权重中，并将策略直接融入模型参数中，使模型实际上能感知你的策略，并以类似肌肉记忆的方式响应风格，并应用于当前问题。

第五部分：规范即代码

尽管模型规范只是 Markdown，但将其视为代码来思考非常有用。

规范与代码的相似性

规范和代码非常相似：

• 可执行：正如我们所见
• 可测试：自带单元测试
• 通过接口与现实世界交互
• 可作为模块交付

规范的工具链

设计模型规范时，常会遇到许多类似编程领域的问题。

就像编程中有类型检查器，类型检查旨在确保一致性。若接口 A 依赖模块 B，双方的理解必须保持一致。

因此，若 A 部门和 B 部门各自编写规范，这里有矛盾，你既要推进此事，或许可以阻止该规范的发布。

正如我们所见，该策略可自带单元测试。

你可以想象一些类似 Linter 的检查工具，若使用过于模糊的表达，不仅会让人困惑，也会让模型出错，最终产出的效果也会大打折扣。

规范实际上为我们提供了类似的工具链，但其针对的是意图而非语法。

第六部分：更广泛的视角 - 立法者即程序员

美国宪法作为"国家级模型规范"

让我们把立法者看作程序员来讨论。

美国宪法本质上就是一份国家层面的模型规范说明书。

它有：

• 成文条文：至少在理想上是清晰明确的政策，我们都可以参照
• 版本化修改：可通过修正案方式升级并发布更新
• 司法审查：由评分者（法官）评估情况，判断其与政策的契合度
• 先例：类似单元测试

尽管源政策本应明确无误，但现实往往复杂，有时会遗漏部分情况，导致个别案例被忽略。

此时，大量算力将耗费在司法审查上，以厘清法律在此处的实际适用方式。一旦确定，便成先例。

这一先例实质上是一组输入输出对，可作为单元测试，明确并强化原始政策规范。

它包含了指挥链等要素。长期执行这一机制形成了一种训练循环，有助于我们将共同的意图和价值观保持一致。

因此，这一产物既能传递意图、裁决合规，又能安全演进。

普遍的规范制定者

因此，未来立法者可能是程序员，或程序员可能成为立法者。实际上，这是一个非常普遍的概念：

• 程序员：通过代码规范来协调芯片工作
• 产品经理：通过产品文档协调团队
• 立法者：通过法律条文协调人类行为
• 在座各位：每次写提示时，其实都在做一种原型规范

你们的工作是让 AI 模型对齐共同的目标与价值观，无论是否意识到，你们都是这个世界的规范制定者。

规范让你更快更安全地交付。人人皆可参与，无论谁撰写规范，无论是产品经理、立法者、工程师还是营销人员，都是程序员。

第七部分：软件工程的本质重新定义

工程从来不是关于代码

回到最初的问题，当问"谁认为自己产出的是代码"时，很多人放下了手。

软件工程从来不是关于代码。

编程是极佳的能力和宝贵的财富，但并非最终目的。

工程是人类对问题的精准探索，是解决人类问题的软件方案。

历来如此。

从机器编码到人类编码

我们只是逐渐摆脱为不同机器编码的方式，统一成人类实际解决问题的编码方式。

这就是 AI 时代带给我们的真正转变。

结尾：总结与呼应

看完 Sean 的演讲，我作为一名 IT 解决方案架构师和一人公司实践者，有了更深的思考。

规范思维对我的启示

在做解决方案架构时，我一直强调的是"理解业务、设计方案、协调资源"。现在我意识到，这本质上就是在编写"规范"——只是我们以前没有这样命名它。

对于一人公司来说，这个转变更为关键。我们没有大团队，没有无限的时间，必须把精力放在最有价值的事情上。而 Sean 的演讲告诉我们：

最有价值的不是写代码，而是清晰地表达意图、定义规范、让 AI 帮我们实现。

在 AI 时代重新定义"编程"

未来的"编程"将不再是面向机器的语法操作，而是面向人类和 AI 的意图表达。

新的稀缺技能是：编写完整体现意图与价值观的规范。

掌握这一点的人，将成为最有价值的程序员——或者说，最有价值的"规范制定者"。

为什么这个转变对我们至关重要

回到开篇我说的：为什么我要分享这个演讲？

因为这不仅仅是一个技术趋势的观察，更是一次思维方式的革命。

作为技术人员，我们需要重新认识自己的价值：

• 不是写了多少行代码
• 不是掌握了多少种编程语言
• 而是能否清晰地理解问题、表达意图、协调资源

这才是我们在 AI 时代真正的核心竞争力。

最后，让我用 Sean 的几句核心金句来结束这篇分享：

"代码只占你价值的 10-20%，其余 80-90% 是结构化沟通。"

"我们保留生成的代码却删除提示，就像销毁源码却对二进制文件进行版本控制。"

"软件工程从来不是关于代码。"

"每个写提示词的人都是这个世界的规范制定者。"

希望这个分享能给你带来启发。在 AI 时代，让我们一起成为更好的"规范制定者"。

如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你的经验，我们一起交流学习！

我是 dtsola【IT解决方案架构师 | AI创业者】 ；专注AI创业、商业、技术、心理学、哲学内容分享。

博客：https://www.dtsola.com