“软件工程从来不是关于代码，而是关于如何精准地理解和解决人类问题。”
—— Sean Grove, OpenAI
第一次看到 OpenAI 研究员 Sean Grove 的演讲《The New Code》时，那种冲击感很强烈。作为技术人员，我们总习惯把代码量等同于生产力。但在 AI 快速发展的今天，这个观念正被彻底颠覆。
他的演讲不仅重新定义了“编程”的本质，更指明了在 AI 时代，技术人员真正的价值所在。这个转变对解决方案架构师或独立开发者来说尤其重要，因为我们的核心从来不是写代码，而是理解问题、设计方案。
第一部分：重新审视工程师的价值——代码 vs 沟通
演讲从一个小互动开始：“请举手，如果你写代码并认为写代码算工作量？”很多人举手。“如果你们的工作就是写代码，请继续举着手。”大部分人仍举着。“如果你们认为工作中最有价值的成果是代码，请继续举手。”这时，许多人放下了手。
这个瞬间揭示了一个普遍困境：我们都知道代码不是全部，却习惯用它来衡量自身价值。
Sean 提出了一个颠覆性的比例：代码仅占你贡献价值的 10% 到 20%，其余 80% 到 90% 在于结构化沟通。 代码之所以显得重要，只是因为它具体、可衡量、可争论。但这严重低估了我们真实的工作价值。
软件开发的完整循环
真正的软件开发流程是一个完整循环：
- 理解：与用户交流，了解挑战。
- 提炼：从用户故事中提炼核心问题。
- 构思：想清楚要实现什么目标。
- 规划：制定实现目标的方案。
- 分享：与同事讨论和验证计划。
- 翻译：将计划转化为代码（关键一步）。
- 测试：验证代码运行时是否达到目标。
- 验证：观察代码对世界产生的实际影响。
- 迭代：回到第一步，循环往复。
你会发现，写代码只是其中一个环节。我们测试和验证的也并非代码本身——没人真正在意代码，我们在意的是它运行时是否解决了问题。 理解、提炼、构思……这些听起来都像是结构化沟通。
AI 时代的瓶颈转移
Sean 指出了一个关键趋势：AI 模型越先进，沟通效率的瓶颈就越明显。 未来，沟通效率最高的人将成为最有价值的“程序员”。只要你能有效沟通，就能“编程”。
以“氛围编程”（Vibe Programming）为例，它的体验往往不错。为什么？因为它首先是关于沟通，代码是次要产物。我们描述意图和期望，让模型处理琐碎工作。
但这种方式仍有个怪现象：我们通过提示（Prompt）与模型交流，传达意图，生成代码，然后就把提示丢弃了。 这就像你用 TypeScript 写代码，编译后却把源代码扔掉，只保留二进制文件并进行版本控制。这显然不对。
第二部分：规范（Specification）的核心力量
为什么说规范通常比代码更强大？因为代码本身是从规范进行的一种有损映射。
这就像反编译一个 C 语言二进制文件，你得不到清晰的注释和变量名，只能猜：这人想干嘛？为何这么写？大量意图信息在翻译过程中丢失了。同样，即便是整洁的代码，也常常无法完全体现背后的所有意图和价值。
规范的核心价值
因此，明确记录意图和价值观至关重要。一份书面规范能让团队在共同目标上保持一致，也是讨论、争论和保持同步的终极依据。Sean 强调，若无规范，你对目标就只有模糊的概念。
规范的可执行性
一份足够完善的规范，其价值远超代码。代码其实编码了生成它所需的全部要求。就像把源代码交给编译器，你可以输出多种架构的版本（arm64, x86, WebAssembly）。源文件包含了翻译到目标架构的全部信息。
同样，一份完善的规范提供给 AI 模型后，可以生成：
- 优质的 TypeScript / Rust 代码
- 服务端与客户端代码
- 配套文档、教程
- 博客文章甚至播客内容
Sean 提出了一个发人深省的问题：你把整个代码库和文档输入播客生成器，能生成足够有趣、告诉用户如何成功的内容吗？恐怕不能。那些真正有价值的信息，其实并不在你的代码里。
第三部分：OpenAI 模型规范实战案例
去年，OpenAI 发布了“模型规范”（Model Spec），这是一份持续更新的文档，旨在清晰表达其模型的意图与价值观。
今年二月，这份规范开源了。你猜它是什么？它只是一组 Markdown 文件。
Markdown 的优势非常明显： 可读性强、支持版本控制、有变更记录。最关键的是，由于它是自然语言，不仅技术人员，产品、法律、安全、政策等所有相关方都能阅读、讨论并贡献。它成了统一所有人意图与价值观的通用载体。
为了精确表达，规范中的每个条款都有一个 ID（如 sy73），对应另一个包含“挑战性提示”的文件。文档本身编码了成功标准——模型必须能按规范要求回答这些问题，才算遵循该条款。
实战案例：GPT-4o 的“谄媚”问题
最近 GPT-4o 更新后出现了严重的“阿谀奉承”问题，模型为讨好用户而牺牲客观性。这引发了大量担忧：这是有意的吗？为何没被发现？
幸运的是，模型规范中早有专门章节说明此事。自发布起就明确指出：切勿谄媚。它解释了谄媚虽带来短暂满足，但长期对所有人都不利。
因此，当模型行为与白纸黑字的规范不符时，这明确就是一个需要修复的漏洞。OpenAI 随后回滚并修复了问题。在此期间，规范成了信任的锚点，向所有人传达了预期行为的标准。
第四部分：让规范可执行——深思对齐技术
如果规范仅用于统一人类认知，那已极有价值。但理想情况下，我们还能让模型及其产出与这些规范保持一致。
OpenAI 发布了一种名为“深思对齐”（Deliberative Alignment）的技术。其工作流程如下：
- 输入：你的规范 + 一组极具挑战性的提示。
- 采样：从待测试或训练的模型中获取回复。
- 评估：将回复、原始提示和规范交给一个更大的模型，让其根据规范评分。
- 迭代：文档本身成了训练与评估材料，根据得分调整模型权重，实现优化。
从运行时计算到模型权重
传统上，我们需要在每次推理时通过系统提示来对齐模型，这消耗算力。而通过“深思对齐”，原本在推理时的计算被嵌入到了模型权重中。规范（如代码风格、安全要求）被直接融入模型参数，使模型能以类似肌肉记忆的方式响应。
第五部分：规范即代码
尽管模型规范只是 Markdown，但将其视为代码来思考极具启发性。
规范与代码的相似性
- 可执行：如前所述，能驱动模型生成。
- 可测试：自带“单元测试”（挑战性提示）。
- 通过接口交互：与真实世界（用户、其他系统）连接。
- 可模块化交付：可以作为独立组件复用。
规范的工具链
设计规范时，会遇到许多编程领域的熟悉问题。
- 类型检查器：确保不同部门编写的规范之间没有矛盾。
- 单元测试：即那些挑战性提示。
- Linter：可以想象有工具检查规范中是否使用了过于模糊的语言，这会让模型困惑，影响输出质量。
规范为我们提供了一套工具链，但其针对的是意图而非语法。
第六部分：更广的视角——立法者即程序员
让我们把视野放宽，将立法者看作程序员。
美国宪法本质上就是一份国家级的“模型规范”。 它有：
- 成文条文：清晰（理想上）的政策文本。
- 版本化修改：通过修正案“升级”。
- 司法审查：由“评分者”（法官）评估案例与政策的契合度。
- 先例：这就像单元测试，是一组输入输出对，用于明确和强化原始规范。
尽管源政策应明确，但现实复杂，总有边缘案例。这时，大量“算力”（司法资源）耗费在厘清适用方式上。一旦形成先例，它就成为一个强化性的测试用例。长期执行形成了一种训练循环，有助于社会在共同意图和价值观上对齐。
人人皆规范制定者
因此，未来的立法者可能是程序员，或程序员成为立法者。这其实是个普遍概念：
- 程序员：用代码规范协调芯片工作。
- 产品经理：用产品文档协调团队。
- 立法者：用法律条文协调社会行为。
- 你：每次写提示词时，都在做一种“原型规范”。
你的工作是让 AI 对齐共同的目标与价值观。无论是否意识到，你都是这个世界的规范制定者。 规范让你更快更安全地交付。人人皆可参与，无论谁撰写规范，都是广义上的“程序员”。
第七部分：重新定义软件工程的本质
回到最初的问题，当被问及“谁认为自己产出的是代码”时，许多人放下了手。
软件工程从来不是关于代码。 编程是宝贵的能力，但并非最终目的。
工程是人类对问题的精准探索，是解决人类问题的软件方案。 历来如此。
我们只是逐渐摆脱了为不同机器编码的方式，统一成为人类实际问题编码的方式。这就是 AI 时代带来的真正转变。
总结与启示
Sean 的演讲带来一次思维革命。它告诉我们，在 AI 时代，新的稀缺技能是：编写完整体现意图与价值观的规范。
未来的“编程”将不再是面向机器的语法操作，而是面向人类和 AI 的意图表达。掌握这一点的人，将成为最有价值的“规范制定者”。
我们需要重新评估自己的价值：不是写了多少行代码，不是掌握多少种语言，而是能否清晰地理解问题、表达意图、协调资源。 这才是 AI 时代真正的核心竞争力。
核心观点回顾：
- “代码只占你价值的 10-20%，其余 80-90% 是结构化沟通。”
- “我们保留生成的代码却删除提示，就像销毁源码却对二进制文件进行版本控制。”
- “软件工程从来不是关于代码。”
- “每个写提示词的人都是这个世界的规范制定者。”
在 AI 时代，我们的角色正从“码农”转向“规范的建筑师”。这意味着更深入地理解业务，更清晰地定义问题，并善于利用 技术文档 等工具来具象化我们的思考。对于所有身处技术浪潮中的 开发者 而言，这既是一场挑战，也是一次解放创造力的机遇。关于如何实践“规范即代码”、如何与 AI 高效协作，欢迎在 云栈社区 交流你的想法与实践。
发表于 昨天 02:45
|
查看: 0|
回复: 0
