0:26 大家好。 非常感谢
0:28 你们的邀请。 嗯，这是一个非常令人兴奋的
0:31 地方，非常令人兴奋的时刻。 呃，
0:33 呃，
0:35 其次，呃，我的意思是这
0:37 几天过得相当紧张。 我不
0:39 知道你是否有同样的感受。 呃，但
0:42 也非常有活力。 所以今天我想占用
0:44 大家一点时间来
0:45 谈谈我所看到的
0:47 新代码的到来。 呃，特定的
0:49 规范在某种程度上承载着这样的
0:51 承诺，呃，这是业界的梦想，
0:53 你可以编写
0:56 一次代码，实现你的意图，然后在
0:58 任何地方运行它们。
1:00 呃，简单介绍一下，我的名字是 Sean，我在
1:03 OpenAI 工作，具体从事
1:05 一致性研究，今天我想
1:07 谈谈代码
1:08 与沟通的价值，以及为什么
1:10 规范通常可能是一种
1:18 嗯，我将介绍一下规范的结构
1:20 ，我们将使用模型
1:23 规范作为示例。 嗯，我们将讨论如何
1:26 向其他人传达意图，
1:28 并将 40 个 syphency
1:31 问题作为案例研究。
1:33 嗯，我们将讨论如何使
1:36 规范可执行，如何
1:39 向模型传达意图，嗯，以及
1:42 如何将规范视为
1:43 代码，即使它们有点
1:45 不同。 嗯，我们将以
1:48 几个未解决的问题来结束我们的讨论。 那么，让我们来讨论一下
1:51 代码与通信。
1:54 很快，如果你编写了
1:57 代码并认为代码有价值，请举手。
2:00 凉爽的。 如果您的工作是
2:03 编写代码，请坚持下去。
2:05 好的。 现在，对于那些人来说，
2:07 如果您认为
2:10 自己生产的最有价值的专业产品
2:13 是代码，请抬起头来。
2:15 好的，有不少人，我
2:18 认为这很自然。 我们都
2:20 非常努力地解决问题。 我们
2:22 与人们交谈。 我们收集
2:24 需求。 我们仔细考虑
2:25 实施细节。 我们
2:28 与许多不同的来源进行整合。
2:31 我们最终生产的东西就是代码。
2:33 代码是我们可以
2:35 指向、可以衡量、可以辩论、
2:38 可以讨论的产物。 呃，这感觉很
2:42 真实，但它有点低估了
2:45 你们每个人所做的工作。 代码大约占
2:47 您带来的价值的 10% 到 20%
2:51 。 其余 80% 到 90% 是
2:53 结构化沟通。
2:54 这对
2:56 每个人来说都是不同的，但这个过程通常看起来
2:58 像你与用户交谈
3:01 以了解他们面临的挑战。
3:03 您提炼这些故事，然后
3:06 构思如何解决这些
3:08 问题。 你想达到的目标是什么
3:11 ？ 您计划
3:13 实现这些目标的方法。 您
3:16 与同事分享这些计划。
3:19 呃，你把这些计划翻译成代码。
3:20 所以这显然是非常重要的一步
3:24 。 然后你测试并验证的
3:27 不是代码本身，对吗？ 实际上没有人关心
3:28 代码本身。 您
3:32 关心的是代码运行时，它是否
3:34 实现了目标，是否减轻了
3:37 用户的挑战？ 看看
3:40 你的代码对世界的影响
3:44 。 因此，交谈、理解、
3:51 规划、分享、翻译、测试、
3:53 验证。 对我来说，这些听起来都像是
3:57 结构化的沟通。 而
3:59 结构化沟通是 瓶颈。
4:00 瓶颈。
4:03 知道要构建什么，与人交谈
4:05 并收集需求，知道如何
4:08 构建它，知道为什么要构建它，
4:10 并且最终知道它是否已
4:11 正确构建并且是否
4:13 真正实现了
4:15 您设定的目的。
4:18 人工智能模型越先进，
4:21 我们就越能明显地感受到
4:24 这种瓶颈。
4:26 因为在不久的将来，
4:29 最能有效沟通的人就是
4:33 最有价值的程序员。 从字面上理解，
4:35 如果你能有效沟通，你
4:37 就能编程。
4:39 因此，让我们以氛围编码作为
4:42 说明性示例。 Vibe 编码往往
4:44 感觉相当好。 值得
4:47 一问的是，这是为什么呢？ 嗯，氛围编码从
4:50 根本上来说首先是关于沟通。
4:52 而代码实际上是
4:54 该通信的次要下游产物 。
4:55 。
4:57 我们描述我们的意图和
4:59 我们希望看到的结果，并
5:01 让模型实际上
5:04 为我们处理繁重的工作。 即便如此， 我们
5:06 我们
5:10 进行氛围编码的方式还是有些奇怪。 我们通过
5:12 提示与模型进行交流，
5:14 告诉他们我们的意图和
5:17 价值观，最后得到一个代码工件，
5:20 然后我们将
5:24 提示扔掉，它们是短暂的，
5:27 如果你编写了 TypeScript 或 Rust，
5:29 一旦你将你的代码放入
5:32 编译器或将其分解成二进制文件，
5:35 没有人会对这个二进制文件感到满意。 这
5:38 不是目的。 它很有用。
5:40 事实上，
5:42 每次我们编译或
5:44 通过 V8 或源规范中的其他任何程序运行代码时，我们总是从头开始重新生成二进制文件 。
5:47 。
5:50 源规范才是有价值的 文物。
5:52 文物。
5:53 然而，当我们提示元素时，我们却
5:55 做了相反的事情。 我们保留
5:58 生成的代码并删除提示。
5:59 这感觉有点像
6:01 你撕碎了源代码，然后非常
6:05 小心地对二进制文件进行版本控制。
6:07 这就是为什么在规范中
6:09 实际捕捉意图和
6:12 价值如此重要。
6:14 书面规范可以让
6:17 你让人们对共同的
6:20 目标达成共识，并且让你知道如果你真的同步了 需要
6:22 需要
6:24 做的事情，你们是否就达成了共识。 这是
6:26 您所讨论、辩论、
6:29 参考和同步的工件。
6:30 这确实很重要。 因此，我
6:32 想强调的是，
6:35 书面规范可以有效地协调 人类，
6:37 人类，
6:40 它是人们用来
6:42 交流、讨论、辩论、
6:45 参考和同步的依据。 如果你
6:47 没有具体说明，你就
6:50 只有一个模糊的想法。
6:52 现在我们来谈谈为什么规范
6:56 通常比代码更强大。
6:58 因为代码本身实际上是
7:01 规范的有损投影。
7:03 同样，如果您要对
7:06 已编译的 C 二进制文件进行反编译，
7:09 您将不会得到很好的注释和
7:11 命名良好的变量。 你必须
7:13 倒着做。 你必须推断
7:15 这个人想要做什么？
7:17 这段代码为什么要这样写呢？ 它
7:18 实际上并不包含在那里。 这是
7:21 有损翻译。 同样，
7:24 代码本身，即使是好的代码，通常也
7:27 不会体现所有的意图和
7:30 价值观。 你必须推断
7:32 这个团队想要实现的最终目标是什么
7:35 。 呃，当你阅读
7:37 代码时，
7:39 那么沟通，我们
7:41 建立的工作，我们在
7:43 书面规范中体现的工作已经
7:46 比代码更好。 它实际上对生成代码
7:48 所需的所有必要条件进行了编码
7:51 。 并且，就像
7:53 将源代码
7:56 传递给编译器可以让你
7:58 针对多个不同的
8:01 架构一样，你可以针对 ARM
8:04 64、x86 或 Web 汇编进行编译。 源
8:06 文档实际上包含足够的
8:09 信息来描述如何将
8:11 其转换为目标架构。
8:15 同样，给予模型足够强大的
8:18 规范将
8:21 产生良好的 TypeScript、良好的 Rust、
8:24 服务器、客户端、文档、教程、
8:26 博客文章甚至 播客。
8:27 播客。
8:30 呃，举手，谁在
8:32 以开发人员为 客户的公司工作？
8:34 客户的公司工作？
8:36 好的。 因此，一个快速的思维
8:38 练习是，如果您要拿出您的
8:40 整个代码库、所有的
8:43 文档，哦，所以所有
8:45 运行您业务的代码，并将
8:47 其放入播客生成器中，
8:49 您能否生成一些
8:50 足够有趣和引人注目的内容
8:53 来告诉用户如何
8:55 成功，如何实现他们的目标，或者
8:57 所有这些信息都在
9:01 其他地方？ 它实际上不在你的代码中。
9:03 因此，展望未来，新的稀缺
9:06 技能是编写能够
9:10 充分体现意图和价值的规范。
9:12 谁能再次掌握这一点，谁就会成为
9:15 最有价值的程序员。
9:16 并且很有可能
9:19 这就是当今的程序员。
9:21 这已经和我们做的非常相似了
9:24 。 但是产品经理也会写
9:26 规范。 立法者制定法律 规范。
9:28 规范。
9:31 这其实是一个普遍的道理。
9:32 考虑到这一点，让我们看看
9:35 规范实际上是什么样的。
9:37 我将在这里使用 OpenAI 模型规范
9:40 作为示例。 因此去年，OpenAI
9:42 发布了模型规范。 这是一份
9:46 活生生的文件，它试图清晰
9:47 明确地 表达
9:50 表达
9:52 OpenAI 希望灌输给
10:00 并于二月份更新并
10:02 开源。 所以你实际上可以去
10:03 GitHub 查看
10:07 模型规范的实现，
10:08 令人惊讶的是它实际上只是一些
10:11 markdown 文件的集合，看起来
10:15 就像这样。 现在 markdown 非常引人注目。
10:17 它是人类可读的。 已版本化。
10:20 它记录了变化，因为它是
10:23 自然语言，所以不仅仅是
10:25 技术人员，每个人都可以做出贡献，
10:27 包括产品法律安全研究
10:32 政策，他们都可以阅读、讨论辩论
10:35 并为相同的源代码做出贡献。
10:37 这是一个通用的神器，它使
10:44 公司内部的所有人都与我们的目的和价值观保持一致。
10:47 现在，尽管我们尽力使用
10:49 明确的语言，但有时仍然
10:51 很难表达其中的
10:55 细微差别。 因此，模型规范中的每个子句在
10:57 这里都有一个 ID。 所以，您可以
11:01 在这里看到 sy73。 使用该 ID，您可以
11:03 在存储库 sy73.mmarkdown
11:05 sy73.mmarkdown
11:08 或 md uh 中找到另一个文件，其中包含针对此精确条款的一个或多个具
11:10 有挑战性的提示
11:13 。 因此，文档
11:18 本身实际上编码了成功标准，
11:21 即被测模型必须
11:22 能够以
11:27 符合该条款的方式回答这个问题。
11:31 那么让我们来谈谈 syphy。 呃，
11:34 最近有更新到 40。我
11:36 不知道你是否听说过这个。 呃，
11:41 那里呃引起了极端的骚动。 呃，我们
11:44 可以问一下，
11:48 在这种情况下模型规范的价值是什么，模型规范的作用
11:50 是使人类围绕一组
11:53 价值观和意图进行调整。
11:55 这是一个 sycancy 的例子，其中
11:58 用户大声斥责
12:01 以牺牲公正的真相为代价的 syphants 或 sophantic 行为，
12:04 并且模型非常
12:06 善意地赞扬用户的 洞察力。
12:10 其他受人尊敬的
12:13 研究人员也发现了类似的
12:19 情况，
12:23 这损害了
12:26 航运业的虚伪，从而
12:28 侵蚀了信任。
12:31 好痛。
12:33 所以这也引发了很多问题，
12:36 比如这是故意的吗？ 您可能会发现
12:38 一些可以
12:40 这样解释的方法。 这是意外吗？为什么
12:42 没有被抓住？
12:44 幸运的是，自发布以来，模型规范实际上
12:48 包含一个专门针对此问题的部分，其中
12:50 指出不要
12:53 厌倦幻想，并解释说，
12:55 虽然幻想在短期内可能感觉良好
12:57 ，但从长远来看对每个人来说都是有害的
13:00 。 因此，我们实际上表达了我们的
13:01 意图和价值观，并能够
13:11 人们可以参考它，如果我们
13:13 在模型规范中拥有它，
13:16 如果模型规范是我们
13:18 商定的意图和价值观，而
13:20 行为与此不一致，
13:23 那么这一定是一个错误。
13:26 因此我们回滚了，发布了一些
13:28 研究和一些博客文章，并修复了 它。
13:34 但在此期间，这些规范起到了
13:36 信任锚的作用，一种向
13:38 人们传达预期和不 预期内容的方式。
13:46 因此，如果模型规范所做的唯一事情
13:49 就是使人类
13:51 与那些共同的意图
13:53 和价值观保持一致，那么它已经
13:56 非常有用了。
13:59 但理想情况下，我们还可以根据相同的规范调整我们的模型
14:01 和模型
14:05 产生的工件。
14:06 因此，我们
14:08 发布了一项技术，即审议性
14:09 对齐，该技术讨论了
14:12 如何自动对齐模型，
14:15 该技术是这样的，您采用
14:17 规范和一组非常具
14:19 有挑战性的输入提示，然后
14:21 从测试或训练的模型中抽样 。
14:23 。
14:25 然后，你把它的响应、
14:27 原始提示和策略
14:28 提供给一个更大的模型，并要求
14:32 它根据规范对响应进行评分
14:34 。 对齐程度如何？ 因此，
14:36 该文档实际上既是
14:40 训练材料，又是评估材料，
14:42 并且基于这个分数，我们会强化
14:45 这些权重，并且
14:47 您可以在上下文中包含您的规范， 然后
14:48 然后
14:50 在每次采样时可能包含系统消息或开发人员消息， 这
14:52 这
14:54 实际上非常有用。 提示
14:56 模型在某种程度上是一致的，
14:57 但它确实会削弱可
15:01 用于解决
15:02 您尝试用该模型解决的问题的计算能力。
15:04 请记住，这些规格
15:06 可以是任何东西。 它们可以是代码
15:08 风格、测试要求或
15:10 安全要求。 所有这些都可以
15:13 嵌入到模型中。 因此，通过这种
15:14 技术，您实际上是将其从
15:17 推理时间计算中移出，并且实际上将其
15:19 推入模型的权重中，
15:21 以便模型能够真正
15:24 感受到您的策略，并能够以
15:27 肌肉记忆的方式将其应用于
15:29 手头的问题。
15:31 尽管我们看到模型
15:34 规范只是 markdown，但将其视为代码还是很有用的
15:36 。 这非常 类似。
15:37 类似。
15:39 呃，这些规范是它们组成的，
15:42 它们是可执行的，正如我们所见，它们
15:44 是可测试的，它们有与
15:46 现实世界接触的接口，它们
15:49 可以作为模块交付，
15:52 每当你在模型规范上工作时，都会有
15:54 很多类似的
15:56 问题域，所以就像在
15:58 编程中你有一个类型
15:59 检查器一样，类型检查器旨在
16:02 确保一致性，如果接口 A
16:05 有一个依赖的模块 B，它们必须
16:07 在彼此的理解上保持一致
16:10 。 因此，如果部门 A 编写了
16:12 规范，部门 B 也编写了规范，并且
16:13 两者之间存在冲突，您希望
16:15 能够提前发生冲突，甚至可能
16:18 阻止规范的发布，
16:21 正如我们所见，该政策
16:23 实际上可以体现其自己的单元测试，
16:25 您可以想象各种各样的 llinters，
16:26 如果您使用过于模糊的
16:28 语言，您就会混淆人类，混淆
16:30 模型，
16:32 并且您从中获得的工件
16:34 将不那么令人满意。
16:37 因此，规范实际上为我们提供了一个非常相似的
16:39 工具链，但它针对的是
16:42 意图而不是语法。
16:45 那么让我们来谈谈作为
16:48 程序员的立法者。 嗯，
16:51 美国宪法实际上是一个
16:53 国家示范规范。 它
16:55 所写的文字至少是
17:01 我们所有人都可以参考的清晰、明确的政策。 这并不意味着
17:03 我们同意它，但我们可以将
17:05 其视为现状，即
17:09 现实。 嗯，有一个版本化的方法可以对
17:12 bump 进行修改并
17:14 发布更新。 司法
17:19 审查中，评级人员可以对
17:20 情况进行有效评级，并查看
17:23 其与政策的契合程度。
17:25 即使再次因为或即使
17:27 源策略旨在
17:30 明确无误，有时你也不会这样做，因为
17:32 世界很混乱，也许你会错过部分
17:34 分布，导致案件失败，
17:37 在这种情况下，
17:40 司法审查需要花费大量的计算，
17:41 你试图了解
17:43 法律在这里的实际应用方式，一旦
17:46 决定，它就会树立先例，而
17:48 该先例实际上是一个输入
17:50 输出对，作为单元测试，可以
17:52 消除歧义并强化
17:55 原始策略规范。 呃，它
18:01 里面嵌入了诸如命令链之类的东西，随着时间的推移，它的执行
18:03 是一个训练循环，有助于让
18:05 我们所有人朝着共同的
18:08 意图和价值观迈进。 所以这是一个
18:11 传达意图的神器。 它
18:13 裁定合规性，并且有一种
18:17 安全发展的方式。
18:19 因此，未来立法者很有可能
18:21 成为程序员，或者反过来，
18:24 程序员也很有可能成为立法者 。
18:26 。
18:28 实际上这是一个非常
18:30 普遍的概念。 程序员的
18:33 工作是通过
18:36 代码规范来对齐硅片。 产品经理
18:38 通过产品规格来协调团队。
18:41 立法者实际上是通过
18:43 法律规范来协调人类的。 无论
18:45 何时，这个房间里的每个人，当你做一个
18:46 提示时，它都是一种原型
18:49 规范。 您的业务是使
18:52 AI 模型与一
18:55 组共同的意图和价值观保持一致。
18:56 无论您是否意识到，您都是
19:01 这个世界的规范作者，而规范可以让
19:04 您更快、更安全地交付。 每个人都可以
19:07 做出贡献，无论是谁编写规范，
19:13 无论是项目经理、立法者、工程师还是
19:17 营销人员，现在都是程序员，
19:19 而软件工程从来都与
19:22 代码无关。 回到我们最初的
19:24 问题，
19:25 当你们想到实际上
19:28 我制作的东西不是代码时，很多人就举手了。
19:29 工程从来就不是关于这个的。
19:31 编码是一项令人难以置信的技能和
19:33 宝贵的财富，但它并不是最终
19:35 目标。 工程是
19:37 人类对解决
19:40 人类问题的软件解决方案的精确探索。 一直都是
19:42 这样。 我们只是
19:43 从分散的机器
19:47 编码转向统一的人类编码，以
19:49 解决这些
19:51 问题。 呃，我想感谢乔希给予
19:54 我的这份荣誉。 所以我想请你们
19:57 将其付诸行动。 无论何时
19:59 开发下一个 AI 功能，都请
20:01 从规范开始。
20:03 您实际上期望发生什么？
20:05 成功的标准是什么样的？
20:07 争论它是否实际上
20:09 被清楚地写下来并传达。
20:11 使规范可执行。 将规格提供
20:14 给模型
20:17 并针对模型进行测试或
20:19 针对规格进行测试。
20:22 鉴于编程和规范创作之间存在如此多的相似之处，这个世界上存在一个有趣的问题
20:27 。
20:30 我想知道
20:31 未来的 IDE 会是什么样子。 你知道，一个
20:33 集成开发环境。
20:34 我认为它就像一个
20:37 集成的思维澄清器，
20:38 每当你编写
20:42 规范时，它都会消除
20:45 歧义并要求你澄清它，
20:47 它真正澄清你的想法，以便
20:49 你和所有人类可以
20:55 更有效地相互传达你的意图并与模型沟通。
20:58 最后，我有一个求助请求，
21:01 呃，这既是可行的，又
21:04 迫切需要具体说明。 这是
21:07 按比例调整代理。 呃，我喜欢
21:09 你这句话，然后你意识到
21:11 你从来没有告诉过它你想要什么，
21:12 也许你从来没有完全理解它
21:15 。 这是对规范的呼唤。
21:17 呃，我们已经启动了一个新的代理稳健性团队
21:19 。 因此，请加入我们
21:22 ，帮助我们提供安全的 AGI，
21:25 造福全人类。
Chrome Extension