开篇：为什么我要分享这个演讲
"软件工程从来不是关于代码，而是关于如何精准地理解和解决人类问题。"
—— Sean Grove, OpenAI
大家好，我是 dtsola，一名 IT 解决方案架构师，也是一人公司的实践者。
今天我想和大家分享一个来自 OpenAI 的 Sean Grove 的演讲《The New Code》。当我第一次看到这个视频时，内心受到了强烈的震撼。
作为技术人员，我们习惯了用代码来衡量自己的价值，习惯了把"能写多少行代码"作为生产力的标准。但在 AI 快速发展的今天，这个认知正在被彻底颠覆。
Sean 的这个演讲，不仅重新定义了"编程"的本质，更为我们指明了在 AI 时代如何真正发挥技术人员的价值。对于像我这样的解决方案架构师和一人公司实践者来说，这个转变尤为重要——因为我们的核心价值从来不是写代码，而是理解问题、设计方案、协调资源。
接下来，让我们一起走进 Sean 的思考世界。
第一部分：代码 vs 沟通 - 重新认识工程师的价值
传统认知的挑战
Sean 在演讲开始时做了一个有趣的互动：
"请举手，如果你写代码并认为写代码算工作量？"——很多人举手。
"如果你们的工作就是写代码，请继续举着手。"——大部分人继续举手。
"如果你们认为工作中最有价值的成果是代码，请继续举手。"——这时，许多人放下了手。
这个简单的互动揭示了一个深刻的真相：我们都知道代码不是全部，但我们却习惯性地用代码来衡量自己的价值。
Sean 给出了一个颠覆性的观点：
代码仅占你贡献价值的 10% 到 20%，其余 80% 到 90% 在于结构化沟通。
代码是我们能指出来、衡量、争论和讨论的具体成果，它显得具体而真实。但这低估了我们每个人的工作价值。
软件开发的完整循环
真正的软件开发流程是什么样的？
理解：与用户交流，了解他们的挑战
提炼：从用户故事中提炼核心问题
构思：想清楚要实现什么目标
规划：制定实现目标的方案
分享：与同事讨论和验证计划
翻译：将计划转化为代码（这一步显然至关重要）
测试：验证代码运行时是否达到了目标
验证：观察代码对世界产生的影响
迭代：回到理解、提炼、构思……
你会发现，在这个循环中，真正写代码只是其中一个环节。而且，我们测试和验证的并不是代码本身——没人真正在意代码本身，我们关心的是代码运行时是否达到了目标，是否缓解了用户的难题。
理解、提炼、构思、规划、分享、翻译、测试、验证——这些听起来都像是结构化沟通。
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）的技术论文，探讨如何自动对齐模型。
该技术的工作流程：
采用你的规范设定，以及一组极具挑战性的输入提示
从测试或训练中的模型采样
取其回应和原始提示，连同策略一并交给更大的模型
让其对回复进行评分——根据规范，它有多符合？
文档实际上成了训练材料与评估材料
根据得分调整这些权重
据此从你的规范开始迭代优化
从推理时计算到模型权重
在上下文中，可能是系统消息或开发者每次采样时的消息。提示模型会有所对齐，但会耗费算力。
规范可以是代码风格、测试需求、安全要求等任何内容，均可嵌入模型中。
通过该技术，你将原本在推理时的计算转为嵌入模型权重中，并将策略直接融入模型参数中，使模型实际上能感知你的策略，并以类似肌肉记忆的方式响应风格，并应用于当前问题。
第五部分：规范即代码
尽管模型规范只是 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创业、商业、技术、心理学、哲学内容分享。
提供服务：AI项目咨询 | 技术解决方案 | IT项目实施 | 企业技术顾问
博客：https://www.dtsola.com
公众号&VX：dtsola
需提供服务，加微信 dtsola，备注：IT咨询，并说明来意。
#独立开发者 #AI编程 #个人开发者 #一人公司 #程序员 #软件开发者 #创业者 #数字游民 #AI创业 #软件工程
