EPISODE· generated 2026-11-06 16:49:48· 34 min
Stop Prompting — Head of Claude Code Uses Opus 5.5 + Graphs + Harness
本次访谈强调了人工智能能力的指数级增长，指出模型正从简单的代码补全演变为能够构建整个企业的自主智能体，这一转变由缩放定律以及 Opus 5 等进步所推动。文章详细阐述了 Anthropic 如何重构工作流程，让 Claude Code 编排任务而非遵循确定性步骤，这反映了公司更广泛的文化：Claude 处于每个业务流程的核心，涵盖从入职、工程到营销的各个环节。
aianthropicclaude codeopus 5.5harness
ready · seed-vc · qwen3-tts
0:00/0:00
⚠ The Chinese audio is an AI-generated dub (speech synthesis / voice conversion), not a real recording and may contain errors. Based on the original English interview; all rights remain with the original creator.
original lang
EN
dubbed into
中文 (ZH)
pipeline
Plan C · voice conversion
voice model
seed-vc · qwen3-tts
001
Speaker 1
我记得我第一次使用这些产品时，感觉简直太棒了。嗯，我们觉得很快模型就会发展到比我们强大得多的程度。所以在编程方面，这不仅仅是补全单行代码的问题。
002
Speaker 1
模型将能够编写整个函数、整个文件、整个功能模块，甚至整个项目。现在我认为到今年年底，它们将能够构建完整的商业实体。
003
Speaker 1
所以，你知道的，我们看到了这种趋势，我们称之为指数级增长，这就是模型发展的方式。存在一些缩放定律描述了模型智能随时间提升的方式。不知为何这些定律仍在持续，而且实际上正在加速。
004
Speaker 1
你知道，这是一种经验性的观察。并不明显为什么它会一直发生。但它似乎确实在持续发生。所以我们所做的就是追踪这条曲线，心想，好吧，现在模型在这里，它将会到达那里。
005
Speaker 1
现有的产品不足以让人们体验模型的力量。因此我们想要一种纯粹基于智能体的解决方案。老实说，Claude Code 在前六个月对你来说效果并不好。
006
Speaker 1
它确实需要时间。赶上进度需要时间。直到我说 2025 年 5 月的 Opus 5它才开始真正发挥作用。而且，你知道的，从那时起，产品的增长也是指数级的。
007
Speaker 1
起初并不是这样，但那就是它开始呈指数级增长的时候。嗯，我们一直在发现越来越多使用它的方法。随着模型变得更为复杂，我们想出了更多在产品中解锁其潜力的方法。
008
Speaker 1
我们推出了 Claude Code，这算是这一领域的最新迭代版本。它是一个长时间运行的异步智能体，你可以像与同事互动那样与它交互。它拥有出色的常识。
009
Speaker 1
它非常清楚何时该介入，何时不该介入。而且，你知道的，这种情况将会持续发生。我们将不断颠覆自己。
010
Speaker 2
所以我们会继续探索下一个形态是什么。你知道，你可以谈论预测这条进步轨迹。
011
Speaker 2
但对我来说，你是如何思考架构设计的？特别是多智能体系统，以及运行这些多个智能体如何让我们重新思考工作流的实现方式。
012
Speaker 2
我的意思是，令我震惊的是，我们实际上有机会重新架构、重新工程设计我们每个人完成工作的方式。我不得不想知道，这是在设计开发时就内置进去的，还是你们所开发的能力自然产生的结果？
013
Speaker 1
我认为两者兼有。如果我回想几年前，我们是如何使用模型的？你知道，它们就像做单行自动补全那样。我们有智能体工作流，至少是我们称之为智能体工作流的东西。
014
Speaker 1
但本质上这些是确定性系统，其中某一步可能会调用大语言模型（LLM）进行一些计算，但根本上工作流是确定性的。
015
Speaker 1
我认为，随着模型变得更具智能，发生的变化是，我们意识到实际上让模型充当此工作流的协调员要好得多。因此，你做的是由模型来驱动，并赋予它工具以拉取上下文。
016
Speaker 1
你赋予它与外部世界交互的工具。你让它做某事，然后放手让它自己跑去编排这些步骤。
017
Speaker 1
你不再告诉它，“好的，你先做第一步，然后第二步，如果没做到第二步，你知道的，就做这个，否则做那个”，这已经不再是它的工作方式了。你给它一个目标。
018
Speaker 1
你给它一个起点。你赋予它使用工具的权限，然后它会自行搞定。我认为，这种情况的发生是因为模型变得更具智能。这绝对是主要原因。但我在 Claude Code 中也学到了这一点。
019
Speaker 1
在最初阶段，我们基本上是把上下文喂给模型。然后随着模型变得更加复杂，我们意识到，好吧，也许这样做并不对。于是我们稍微远离了这种做法。比如，我们有一个名为 claw.md 的文件。
020
Speaker 1
它在每个会话中都会加载。我认为，我们在客户身上看到的趋势是，他们实际上正更多地转向 skills（技能）。他们更多地转向工具和 MCPs，因为这样模型能更好地控制如何加载这些内容。
021
Speaker 1
好吧，我必须问一句。我的意思是，你们在 Anthropic 的各位每天都在使用 Claude。我是说，所以你们是头号客户。就像在我们其他人看到它之前。
022
Speaker 1
呃，你知道，你们在确保它能满足你们的需求。给我们讲讲你们典型的一天是怎样的。
023
Speaker 2
我的意思是，它……它是……它是 Claude 就像你身体的一部分延伸一样，在你创作工作成果的过程中？是的，这有点奇怪，关于 Anthropic 是如何运作的。
024
Speaker 2
在 Anthropic，Claude 处于我们所做一切的核心。它是每一个业务流程，是每个人整天所做的每一件事的每一个部分。Claude 就处在这一切的中心。
025
Speaker 2
嗯，我有时这样描述它：嗯，假设你是一名新员工，正在 Anthropic 入职。
026
Speaker 1
在 Anthropic，Claude 处于我们所做一切的核心。它是每一个业务流程，是每个人整天所做的每一件事的每一个部分。Claude 就处在这一切的中心。
027
Speaker 1
嗯，我有时这样描述它：嗯，假设你是一名新员工，正在 Anthropic 入职。通常，如果你有一个问题，比如，你知道，办公室在哪里？地址是什么？
028
Speaker 1
你知道，在大多数公司，你会去搜索维基或者问同事。在 Anthropic，你问 Claude。如果你有一个问题，比如，代码库在哪里，我如何获取访问权限？
029
Speaker 1
呃，再说一遍，你不会去查维基百科，你会去找 Claude，向 Claude 提问。如果你的问题像是，你知道的，比如我出差了，有一份差旅报销单，我该怎么提交这份报销？
030
Speaker 1
这就是开始的方式。但随后，当你更深入地投入工作时，Claude 始终处于一切的核心。所以，你知道的，Claude 编写代码，进行代码审查，进行安全审查，头脑风暴并提出新产品创意。
031
Speaker 1
它汇总用户反馈，处理事故分诊。在工程 SDLC（软件开发生命周期）的每一个环节，Claude 都处于核心位置。而且你知道，现在这种情况不仅仅发生在工程领域。
032
Speaker 1
它正在产品、设计、营销以及 GTM（市场拓展）等各个职能中发生。这就是我们看到的现状，工具看起来略有不同。你可能不是在终端里使用 Claude Code。
033
Speaker 1
它可能是像 Coda 这样的工具。嗯，但核心依然是 Claude。我认为，在我所见的 Claude 最成功的采用者身上，真正发生的事情就是将其置于每个流程的核心。
034
Speaker 1
我们之前稍微聊到了我最喜欢的 90 年代《哈佛商业评论》文章，那篇文章大概是 92 年或 96 年的，标题大概是“计算机已经来了，为什么我们没看到生产力提升的好处？”
035
Speaker 1
你知道的，这是当时人们争论的一个大问题。那篇文章的核心论点基本上是说有两种类型的公司。有一种公司，他们买台电脑放在办公室角落的某个地方，
036
Speaker 1
然后保留所有的纸质笔头流程和文件柜，一切照旧，只是角落里多了台电脑。这些公司并没有看到生产力的提升。然后还有一些公司，你懂的，把档案柜里的文件全扔了。
037
Speaker 1
他们把纸和笔都烧了。没错。现在每个流程的核心都有计算机，这些公司才释放出了生产力的提升。
038
Speaker 1
你知道，从今年年初开始，在 Anthropic 我们看到了每位工程师的代码产出增加了 8 倍。这在行业内简直是闻所未闻。
039
Speaker 1
通常公司每年只能看到百分之几的增长，而现在，使用 Claude Code 的最大客户也开始看到类似的效果。他们看到了大约 50%、100%、150% 的提升。
040
Speaker 1
为了实现这 8 倍的增长，我们系统地一次解决一个瓶颈。所以，首先编码是瓶颈。我们用 Claude 来处理，Claude 负责编码。下一个瓶颈是代码审查。
041
Speaker 1
然后我们让 Claude 来做这个。嗯，下一个瓶颈是生成 GTM（市场推广）材料。也许我们也用 Claude 来处理。就这样，一步一步地，我们消除了流程中的每一个瓶颈。
042
Speaker 2
我喜欢这一点，因为你是根据自身的实际需求来推动开发的。这是一个自我强化的循环，以确保你资源投入的价值。作为一家 AI 原生公司，你以惊人的速度采纳这些变化。
043
Speaker 2
但我非常想听听你的经验，你是如何看待领导者和工程师的角色？我只是觉得你比我们要早一步看到这种现象，并且看到你如何带着大家一起前行。
044
Speaker 1
退一步看，工程领域一直处在不断变化之中。你们知道，作为工程师，我们对这种变化并不陌生。你知道，我祖父当年在苏联实际上是用打孔卡编程的。
045
Speaker 1
嗯，你知道，我成长过程中学过 BASIC 和汇编语言，然后随着时间推移，我又逐渐学会了更高级的语言。
046
Speaker 1
我曾有一段时间使用 JavaScript，而在 JavaScript 领域，每位工程师都知道框架几乎每个月都在变。总有一套新的框架出现，每个人都必须学习新技能。
047
Speaker 1
所以，我认为对于工程师来说，变化一直是常态。编程语言一直在变。框架也一直在变。而现在发生的是，这种变化正在加速。因此，我们提升了一个抽象层级。
048
Speaker 1
我们从硬件到打孔卡，再从打孔卡过渡到源代码。现在，我们从操作源代码转向了智能体。而现在，我们又要再提升一个层级，从管理智能体转向管理循环和例行流程。
049
Speaker 1
令人震惊的是，这两大步跨越仅仅发生在两年之内。速度比以往更快，而且我认为这种加速趋势还会持续。所以，当我思考工程师以及那些真正成功的人时，我认为他们是具备实证精神和好奇心的人。
050
Speaker 1
因此，你能够审视数据，并且你能够调整方法策略。你不能总是假设他们过去一直有效的方法将来也会继续奏效。你需要能够从工作中获取反馈。因此，如果出现新数据，你可以采取不同的方法。
051
Speaker 1
嗯，这是指那些具有自主性的人。因为随着工程不再成为瓶颈，我们现在实际上受限于产生好想法并将其推向市场的速度，并且要确保安全地做到这一点。
052
Speaker 1
而在这方面真正高效的人，并不是那些需要有一套庞大流程才能将想法推向市场、并需要与大约十个其他团队进行协作的人。他们更像是单人军队。最有效率的人往往符合这种 CEO 的原型。
053
Speaker 1
你能提出想法，能与用户沟通，能查看数据来构建、迭代并将产品推向市场。而且我们实际上看到这种现象不仅来自工程师，还来自各种职能背景的人。
054
Speaker 1
嗯，我认为拥有工程背景在今天有所帮助，但实际上我认为这对于做这类事情来说已经不再是必不可少的了。
055
Speaker 2
但这确实改变了我们需要强调的技能类型。你需要具备适应能力。你需要对变化无所畏惧。我很喜欢你刚才说的话。你必须保持好奇心。你必须去，你知道的，真正地去进行实验。
056
Speaker 2
我的意思是，这就是我认为这些新的智能体工作流的一部分含义，新意义，就像我们字面上在最近说的：你该如何保持好奇心？你现在可以用以前根本无法尝试的方式进行实验。
057
Speaker 2
我的意思是，你的学习周期大大加快了，不是吗？是的，完全正确。我认为关键在于领导者要腾出空间。
058
Speaker 1
如果你不为此做出调整，不创造空间，大家就会继续用老方法做事，你某种程度上必须迫使每个人采用新方法。但事实上，对很多人来说，能尝试所有这些工具、进行实验本身就非常令人兴奋。
059
Speaker 1
因此，我实际上将自己的很大一部分角色视为为人们创造空间去尝试新事物，让他们感到这样做是安全的。你知道，如果他们实验一个新想法却失败了，不会得到糟糕的绩效评估，因为这可能真的会奏效。
060
Speaker 1
嗯，我的另一项工作就是为人们提供背景信息。也就是说，提供业务背景和产品背景，以便他们能做出更好的决策。
061
Speaker 2
但对于那些非 AI 原生的公司来说，这些都是需要吸取的教训。就像你所经历的那样，这需要展示最佳实践。这将涉及对员工进行教育，并真正推动文化变革，正如你所描述的那样。
062
Speaker 1
是的。没错，你说得对。而我们的工作是在这一过程中协助公司。你知道，我见过公司经历的一种自然转变是：从不使用 AI，到每位工程师运行一个智能体，再到每位工程师运行 10 个智能体。
063
Speaker 1
然后是 100 个智能体，接着是 1,000 个智能体。而且每种类型都伴随着一些特定的特征。所以，你知道的，对于其中一个智能体，工程师们使用它来编写代码，而你则专注于此。
064
Speaker 1
你仍然处于单线程状态，只处理一项任务。然后在某个时刻，你开始信任这个智能体。你会想，“好吧”，也许它确实做对了。也许在它运行的时候，我可以启动第二个。
065
Speaker 1
工程师们自然会摸索出这一点。比如，你可能会同时检出同一个仓库的多个副本，或者查看同一代码的多个视图。所以，当智能体在运行时，你可以去做别的事情。
066
Speaker 1
通过这种方式，你或许可以扩展到同时运行 10 个智能体。你实际上是在各个智能体之间进行轮询切换。你在第一个上开始工作，然后转到第二个。在那里完成工作后，再转到第三个。
067
Speaker 1
这种工作流程现在在我们的桌面应用中得到了很好的支持。嗯，所以对于 Quad Code 和 Cowork，你启动一个会话，然后再启动第二个会话。
068
Speaker 1
你可以继续前进。你可以并行运行多个任务。但当你进一步扩展规模时，事情就变得非常有趣了。我认为当我观察大多数公司时，他们仍然处于第一步和第二步之间的某个阶段。
069
Speaker 1
嗯，当我看 Anthropic 时，我们平均大概处于第三步左右。所以，大多数工程师正在运行数十个甚至数百个智能体。而这样做的方式是让一个智能体去运行另一个智能体。
070
Speaker 1
我们为此提供了很多工具。嗯，所以，例如，如果你在做 子智能体（Sub-agency）。
071
Speaker 2
你有智能体在运行基本上算是子智能体的东西。你是这样理解的吗？还是说这是我们创造的这个短语。如果我不知道这是否是行业标准。
072
Speaker 1
不，不，正是如此。所以，你有子智能体，而子智能体可以启动更多的子智能体。所以，它实际上可以变得相当深入。对于 Claude Code，我们现在支持多达五层
073
Speaker 1
的这种嵌套结构。在产品层面支持这种方式有不同的方法。所以，你知道，我们一直在尝试例如云执行。所以，智能体不再在本地电脑上运行，而是在云端运行。
074
Speaker 1
你可以从桌面应用或移动应用启动智能体。我现在实际上很多编码工作都是用手机完成的。我很喜欢这一点。而且它直接在云端运行。而这正是你进行规模化扩展的方式。
075
Speaker 1
然后，你知道的，我们一直在对此进行迭代，使其更加原生，并扩展到数千个智能体。而我们实现这一目标的方式是通过动态工作流。并且
076
Speaker 1
这本质上是在利用云端来编排庞大的智能体团队，以完成最复杂的工作。比如大型代码库的迁移。
077
Speaker 1
比如我认为 Stripe 最近就用这个来迁移……嗯，你用的那种东西，原本可能需要几个月，结果只用了四天就完成了大约一万行的 Scala 到 Java 的迁移。
078
Speaker 1
嗯，有很多公司正在利用这一点进行大型迁移。比如我们刚刚把 Bun 从 Zig 迁移到了 Rust。这是一个 JavaScript 前端。代码量非常大。
079
Speaker 1
嗯，所以对于这类原本需要几周、几个月甚至几年的超大型工作流，本质上的一种解决方式是分而治之：你给模型分配大量智能体，然后告诉它去搞定它。模型和大量智能体，你只需告诉它去搞定它。
080
Speaker 2
完成这个大任务。所以，这回到了我们之前说的观点。嗯，这将是一段旅程。这需要……这需要教育。嗯，而且它将需要文化变革。嗯，当你做对的时候，我们实际上有一些与你刚才描述的类似的例子。
081
Speaker 2
我们……我们创建了一个基于 Rust 的应用程序。我们的 AI 软件开发负责人在一个周末内就完成了它。嗯，对于一个我们需要开发的应用程序，我们认为这会是一个竞争优势的差距。
082
Speaker 2
嗯，现在在一个周末之后，我们必须验证它并通过所有的测试回归等流程，以便它可以发布。但这是以前闻所未闻的。我我的意思是，多智能体能够做到这一点真是令人惊叹。
083
Speaker 2
再次回到你之前的预测。听起来这正是你所预期的。虽然如此。对吧？我认为这就是我们所期望的。
084
Speaker 1
是的。你知道，你永远无法确切知道它会如何扩展。但如果你知道，出于某种原因，这还在继续。
085
Speaker 1
而且，对于这些传统的扩展定律来说，有趣的是，撰写扩展定律论文的人，比如前几位作者，后来去创立了 Anthropic。因为我认为他们知道未来的方向。
086
Speaker 1
他们知道安全性和安全性变得非常重要。嗯，所以，传统上，扩展定律表明我们的扩展是网络规模、数据量和计算量的函数。而我们目前看到的情况是，这也取决于测试时的计算量。
087
Speaker 1
你知道，这本质上是一种更花哨的说法，指的是你向模型投入了多少 token。
088
Speaker 1
因此，从产品设计以及某种程度上从模型训练的角度来看，我们希望让用户能够更高效地向问题投入更多 token，从而获得更好的结果。
089
Speaker 1
因为如果你只是简单地增加投入，虽然花费了更多 token，但并不会得到更好的结果。所以，举一个例子就是努力程度（effort levels）。
090
Speaker 1
也就是说，在模型中你可以配置努力程度。嗯努力程度越高，模型愿意在该问题上花费的最大 token 数量就越多。
091
Speaker 1
因此，关于多智能体和动态工作流的理念，我实际上将其视为测试时计算的另一种形式。
092
Speaker 1
你向系统投入更多 token，并通过编排智能体、让模型来协调这一过程，你可以高效地利用这些 token 来获得更好的结果。
093
Speaker 2
Boris，我听说你曾提到，向模型投入那些 token 非常重要，否则你甚至不知道性能上限在哪里。
094
Speaker 1
也许你可以向我们的听众解释一下这是什么意思。是的，我认为目前有很多公司都在考虑投资回报率（ROI）。以及如何衡量这一点。
095
Speaker 1
我认为有些公司的想法其实是错误的，因为他们只关注了 ROI 中的 'I'（投入）部分。所以他们想的是，好吧，这是我的投入。我该如何减少它？我该如何削减成本？
096
Speaker 1
显然这很重要，你应该这么做，而且有很多工具可以帮助实现这一点。你可以使用 Opus 的规划模式（plan mode）。你可以使用顾问模型。你可以使用较低的努力程度设置。
097
Speaker 1
你可以使用更便宜的模型。所以，也许并非所有场景都需要 Opus 或者你知道的，也许你可以使用 Haiku。也许你可以使用 Sonnet。当然，你会编写评估脚本来大致弄清楚这一点。
098
Speaker 1
但我认为实际上更重要的是 R（回报）。那么，如何提高你从模型中看到的回报？我认为我们从成功客户那里学到的最大教训是，你要给工程师自由实验的空间。
099
Speaker 1
你要给每个人自由实验的空间，这样他们才能提出新的用例。你希望人们去实验，并希望营造一种让人们感到安全地进行实验的文化，他们会给你带来惊喜。提出绝妙主意的不一定是你最资深的工程师。
100
Speaker 1
那可能是一个应届毕业生。你知道，这不会是由某个工程师想出来的如何自动化这个营销流程？
101
Speaker 1
它可能来自组织角落里一个你从未见过的市场人员，他们提出了一个绝妙的主意，而这正是因为他们进行了实验。因此，你最需要在前端鼓励的就是这种实验精神。
102
Speaker 1
如果有一个内部用例并取得了成功，或者有一个产品并取得了成功，并且消耗了大量的 token。但它很成功。那就是你介入并进行优化的时候。但如果你不做第一步，你就永远找不到机会。
103
Speaker 1
然后一旦你找到了机会，你就可以像任何其他工程问题一样对其进行优化。
104
Speaker 2
Boris，我喜欢这个描述，因为你还强调了机会的民主化。我们实际上曾让初级工程师去解决一个芯片设计问题，那是一个 bug。呃，我们的工程团队已经工作了几周，都无法解决这个 bug。
105
Speaker 2
其中一位初级工程师说："我觉得我能解决这个问题。"呃，他应用了一组遗传算法流程，最终解决了这个问题——这是一个极其罕见的案例，需要 20 个条件同时发生才会触发这个芯片 bug。
106
Speaker 2
这显然是在我们发布产品之前。那时我们还处于调试和测试阶段。这件事从核心层面震撼了许多我们的资深工程师，这也实际上推动了 AMD 内部对这些方法的采用，因为每
107
Speaker 2
当你真正亲身体验到时。呃，你可以空谈。你可以嘴上说说。但一旦你真正遇到一个无法解决的问题，或者实际上体验到了巨大的生产力提升，我看到一位又一位领导者当场就被转化成了信徒。
108
Speaker 1
没错。然后你还需要具备一定的谦逊态度。我觉得这是我必须一遍又一遍、反复学习的一课。我试图按自己的方式做事，也就是在我最终放弃并让 Claude 主导之前。
109
Speaker 1
我当时不得不手动操作。你知道，例如，也许这是一年前的事了。这就像是在调试一个 bug。嗯，我记得有一次我在调试某个问题，当时团队里刚加入了一个新人，而我正在手动进行调试。
110
Speaker 1
我运行着你知道的，一个性能分析器（profiler）来搞清楚到底发生了什么。而他们只是，你知道的，让 Claude 去做同样的事情。
111
Speaker 1
我当时心想：“不不不，Claude 绝对不可能搞定。”连你当时都这么说。
112
Speaker 1
连我都这么说了，因为你知道，在某种程度上我带有偏见，毕竟我经历了 Claude 所有模型代际的迭代，一直与之合作。
113
Speaker 1
所以，我的脑海里仍然停留在那些较旧的模型代际上，那时候模型的能力确实还没达到现在的水平，因为模型一直在改进。嗯，结果他们在 20 分钟内就找到了解决方案，而我没找到。
114
Speaker 1
哇。而且他们找到的方案是正确的。我一次又一次地吸取了这个教训。我认为，随着模型变得越来越先进，我与模型的互动关系也在发生变化。
115
Speaker 1
我不再需要手把手地引导它，也不再需要微观管理它的每一步。这更像是与一位高级工程师合作。我信任他们，提供背景信息，设定目标，然后定期跟进检查。
116
Speaker 1
如果我对他们的信任度较低，或者他们对该问题比较陌生，我就会更频繁地跟进检查。嗯，但核心在于设置好正确的护栏，然后让模型去干活。
117
Speaker 2
Boris，我有一个问题想问你。我的意思是，这实现了团队能力的民主化。因此，我们还看到人们会并行运行多个方案，我们将有五种不同的方式来从工作流中推动改进。
118
Speaker 2
你是怎么看待这个问题的？你是如何思考衡量标准的，以及，你知道的，在那些情况下，你们在 Anthropic 是如何选择要采用的解决方案的？
119
Speaker 2
我的意思是，在这个巨大的领域里做出决策并避免最终陷入各种方法的大规模分裂，基准测试和衡量的作用是什么，你知道的，当我们都在努力解决问题时。
120
Speaker 1
是的，所以我认为正是如此。实际上有两种工具。一种是评估（evals），也就是基准测试，另一种是直觉感受（vibes）。我认为两者都有其适用场景。
121
Speaker 1
嗯，对于某种工作流，如果你可能要重复执行数千次、数万次、数十万次甚至数百万次，你绝对需要评估，因为当新模型发布时，评估能让你将其替换到harness中，并确保性能有所提升。
122
Speaker 1
这为你提供了一种衡量方式。对于其他事情，比如产品体验，直觉感受其实也能走得很远，因为编写评估是有成本的。你不想为每件事都写评估。所以你需要有所取舍。
123
Speaker 1
什么时候可以让直觉来指导你？什么时候它能告诉你一些信息，而什么时候你又真正需要评估来告诉你结果？
124
Speaker 1
当你面临这种分裂以及所有这些不同的产品时，我认为拥有一个模型的一个好处是，迁移和合并代码实际上非常容易。
125
Speaker 1
所以，当你选择了想要的方法后，通常只需让 Claude 将所有其他调用点迁移到这个工作流中即可，这就是全部。
126
Speaker 2
我要再次转换话题。我想谈谈我们所有人都必须关注的事情，我认为这实际上集中在 Anthropic 所采取的方法上，那就是信任和验证这个广泛的话题。
127
Speaker 2
我在之前的一期节目中采访过在哈佛授课的 Kathy Pham，我们讨论了治理以及如何将这一过程构建进去。
128
Speaker 2
所以一方面有确保 AI 安全的治理，另一方面有验证，比如你如何确保你获得了所需的准确性 因为这两者结合起来才能为 AI 的部署提供信任。
129
Speaker 2
我知道这对你很重要，你在我们的聊天中从外部视角提到过这一点，但也许我们可以花一分钟时间思考一下，你是如何将其构建进去的？比如它是一份检查清单，还是实际上内置在你每天运行的工作流中？
130
Speaker 1
是的，我的意思是这涉及许多层面，正如你所说，对于 Anthropic 来说，这正是我们工作的核心。
131
Speaker 1
随着模型变得越来越强大，并且越来越成为业务流程的核心，你需要它安全、可靠且值得信赖。你需要它与使用模型的人的意图保持一致。所以，你知道，我们在不同层面以多种方式处理这个问题。
132
Speaker 1
最基本的是模型对齐。你知道，我们有一个非常大的团队在这方面工作。我们发表了很多相关的研究，也有很多博客文章介绍我们的学习成果。这背后投入了多年的研究工作。
133
Speaker 1
基本上，你知道，对齐涉及很多方面，但例如，对齐的一个要素是真实性。所以，你知道，模型会说对的话。另一个要素是不谄媚。因为模型的一个失败模式是同意用户说的每一句话。
134
Speaker 1
但实际上，一个我喜欢与之合作的好模型会提出反对意见。嗯。我认为在我们的一些后期模型中，比如 Opus 4.7、Opus 4.8，我们在这方面取得了很大进展。
135
Speaker 1
所以，如果我们把模型训练得很好，那么如果我提出一个建议而它是个坏主意，模型会提出反对意见。这让我对它的信任度稍微高了一些。还有其他层面的考量。
136
Speaker 1
所以，你知道，当我们谈论信任时，这其中还包含另一个要素，信任涵盖了很多内容，但另一个关键要素是安全性。因此，训练过程中的另一个要素是，例如，反提示注入训练。
137
Speaker 1
在我们发布的每个模型中，都有一张系统卡片，说明该模型对诸如提示注入等常见攻击的抵御能力如何。
138
Speaker 1
Opus 4.7、Opus 4.8、Fable，这些在行业内几乎是最难被提示注入攻击的模型，优势幅度我认为大概是五到十倍。这是一个非常大的优势差距。
139
Speaker 1
所以，你是将其设计进去的。我的意思是，你们是怎么做到的？这需要大量的训练工作。所以，你知道，这只是模型训练过程的一部分。我们训练模型以抵御这类攻击。
140
Speaker 1
特别是当你结合运行时提示注入分类器时——我们实际上也这样做——在实际应用中，攻击成功率现在接近于零。
141
Speaker 1
显然这很重要，因为随着模型承担更多任务、与更多系统交互，抵御这些非常常见的攻击变得至关重要。随着模型能力增强，我们需要一种方法让模型在更长时间内安全运行。
142
Speaker 1
你知道，现在有些工作流会连续运行几天、几周甚至几个月。显然这意味着不可能一直有个人坐在那里盯着屏幕。
143
Speaker 1
与此同时我们意识到的是，如果每次都需要人来决定是或否，最终那个人实际上就会停止仔细阅读。他们只是不停地点“是”、“是”、“是”，因为他们厌倦了不断点击确认。
144
Speaker 1
我也注意到自己会这样做。你知道，我基本上不再仔细阅读 bash 命令了。我只是直接点‘是’。我们的安全团队也意识到了这一点。
145
Speaker 1
嗯，所以他们开始着手研究的是，有没有办法将这些请求路由到一个分类器，由分类器来做决定。你知道，他们开始了这项工作。花了数月时间才让它达到成熟的状态。
146
Speaker 1
最终，通过评估、红队测试和渗透测试，我们证明了这实际上要安全得多。所以，你知道，在 Anthropic 我们运行的是自动模式。
147
Speaker 2
我们也向所有客户推荐这样做。但是 Boris，我必须问你一个问题。我的意思是，你在每个阶段都在消除瓶颈。但你如何看待未来的规模扩张？
148
Speaker 2
我的意思是，你在 Anthropic 承担的工作复杂度，正如你所说，每次发布都在急剧增长。
149
Speaker 1
嗯，你是如何思考管理规模的，实际上是如何维持这种节奏的？我认为这很大程度上取决于遵循缩放定律，并在规模扩大时不断重塑产品。
150
Speaker 1
嗯，其中很大一部分在于寻找优秀的合作伙伴来支持这种规模和计算能力。嗯，我认为另一大部分在于找出合适的护栏，以确保安全性，因为你知道，随着模型在我们工作中变得越来越核心。
151
Speaker 1
嗯，我们必须确保它做出正确的行为。但我其实是 Mark，我很好奇你是怎么想的。你对扩展性并不陌生，而且你在 CPU 和 GPU 的多代演进中都见证过这一点。
152
Speaker 2
你是怎么看待这个问题的？嗯，对我们 AMD 来说，扩展性实际上至关重要，因为旧的摩尔定律——摩尔定律指出你可以将晶体管密度翻倍、性能翻倍，但保持在
153
Speaker 2
相同的功率包和成本包，那在很长一段时间里都非常棒。但大约是在10年前，这种情况开始逐渐减少。
154
Speaker 2
并不是说随着每一个新的半导体工艺节点，我们不再获得更高的生产力和密度，但成本确实在上升，而且正如你所见，功耗也在增加。因此，我们不得不重新构想优化方式，以确保持续运营。
155
Speaker 2
我们基本上需要维持旧版摩尔定律的增长速度，但半导体物理特性已无法支撑这种旧版摩尔定律的速度。
156
Speaker 2
所以这是一个巨大的挑战，但我们已经准备好迎接它。坦白说，这些 AI 智能体流程被证明对我们扩展规模有着极大的帮助，因为它们帮助我们管理
157
Speaker 2
在一个更大的，我称之为状态空间的环境中，变量更多，我们更多的芯片设计可以得到优化。我认为如果没有这些 AI 工作流，我们无法继续扩展规模。这简直是在最完美的时机出现的。
158
Speaker 2
这就像是一个完美的契机，让我们能够继续扩大规模。你谈到了合作伙伴关系。
159
Speaker 2
我的意思是，这正是我们作为 AMD 的核心所在，比如你知道的，我们与你的合作，以及我们在整个行业中的合作伙伴关系。
160
Speaker 2
这从根本上对我们至关重要，以便我们能够实现规模化增长，因为我们倾向于建立深度合作伙伴关系，以确保我们采用最佳实践，正如你刚才在这里分享的那些案例一样。
161
Speaker 2
我们希望成为首批采用者。你在 Anthropic 实施的那些最佳实践。所以，这对我们 AMD 以及整个芯片行业来说都是一个至关重要的问题：如何通过创新来维持规模化发展。
162
Speaker 2
我必须问这个问题。我的意思是，你谈到我们确实取得了进展，符合你当初描绘的发展轨迹。所以我必须问，在未来两到三年里——在 AI 的时间尺度上这简直像永恒那么长——你预见会发生什么？
163
Speaker 2
两到三年真的是一段很长的时间。
164
Speaker 1
也许我们换个思路，考虑六个月吧。六个月。否则我的预测肯定会偏差很大。当然。我认为在六个月内，我们会看到智能体平均运行时间变得更长。我们会看到人们平均使用更多的智能体。
165
Speaker 1
我们会看到它们与你的意图对齐得更好。所以会有更少的方向修正，更少的手把手指导。自主性会大大增强。
166
Speaker 1
因此我认为，对大多数人——尤其是工程师，并希望不止于此——来说，连续几天甚至几周运行智能体将会变得相当平常。这将成为一种常态，而不是少数工程师在做的事情。
167
Speaker 1
我认为到今年年底，我们会开始看到 Claude 构建越来越大的项目。所以它将不仅仅是功能特性。它将是完整的产品。我们可能会开始看到整个初创公司由 Claude 构建。
168
Speaker 1
嗯，所以，是的，进步在持续向前，而且你知道，我们很兴奋能使其变得安全，并让它成为人们乐于使用的体验。
169
Speaker 2
鲍里斯，非常感谢你。感谢你分享你的见解。呃，感谢你的愿景以及你对行业产生的影响。呃，天哪，未来令人兴奋。
170
Speaker 1
非常感谢。
171
Speaker 2
谢谢你，马克。我非常享受与鲍里斯的聊天。我认为鲍里斯真的为我们预览了在 AI 智能体时代，工作方式将如何发生变化。有几个要点特别突出。
172
Speaker 2
雇佣拥有非传统背景的人才的价值，以带来新的视角和热情。此外，在 Anthropic，Claude 是员工体验的核心。智能体 AI 使任何人、在任何层级都有机会产生深远的影响。
173
Speaker 2
最后，在思考投资回报率时，不要只关注投入，要关注回报。这种实验自由所带来的将是最大的胜利。感谢你今天加入我们。
174
Speaker 2
我期待为你带来 更多关于技术前沿、行业见解以及来自行业内一些最杰出头脑的远见卓识的深度对话。
175
Speaker 2
你可以在 AMD 的 YouTube 频道观看视频节目，或者在仅限音频的平台收听， 包括 Spotify、Amazon Music 和 YouTube Music。
176
Speaker 2
技术总是在进步，我迫不及待想在下一次与你分享更多见解。
Comments
Sign in (top right) to comment.
Loading…