返回 文章 apply CMS 文章

Claude Code 的下一个时代:Anthropic 的 Thariq Shihipar 谈智能体框架、可变软件与安全

Anthropic 的 Thariq Shihipar 解析 Claude Code 的下一阶段:从提示词技巧到可变软件,再到智能体安全。

Claude CodeAnthropic智能体提示词工程
成长分 / 100 78 综合收获、行动、留存与影响

Claude Code 的下一个时代:Anthropic 的 Thariq Shihipar 谈智能体框架、可变软件与安全
为什么值得读了解 Claude Code 从争议到默认选择的演变,以及高级用户的实际使用模式。

获取关于提示词工程、心智模型和发现未知未知的实用见解。

关键洞察
  1. 提示词仍然是使用 Claude Code 时最具杠杆效应的技能之一,需要建立对 Claude 的心智模型。
  2. Artifacts 作为人类与智能体之间的持久生成式界面,可能成为未来 harness 的交互方式。
  3. Claude 可能拆分为云端的“大脑”、本地或远程的“手”以及动态界面。
转成行动

深入阅读

正文与原文对照

原文保真覆盖:全文原文字符:116953

我们非常激动地邀请到 Anthropic 在两周后即将举行的 AI Engineer New York 上分享他们最新的 AI x Finance 工作!

如果你一直与世隔绝,这里有一份非详尽清单,列出了 Anthropic 自 5 月完成史上最大规模融资(ARR 达 470 亿美元)以来发布的内容:

6 月:发布

Claude Tag和Sonnet 5 与 Fable 5上个月:

Fable/Mythos 5.1,以及EFS(即将推出的播客)IPO 目标

2 万亿美元,2026 年底 ARR 预计达 1000 亿美元Cowork/chat 合并早于<竞争对手>完成Dario 背书同样的Pacing the Frontier信息,获所有实验室联署

上周:

Opus 5.5、插件门户、Cloud Sessions/Claude Projects今天:

Sonnet 5.5!

今天的节目应该能让你跟上进度,嘉宾是 Thariq Shihipar,Anthropic 的解说之王,我们上次在 Fable 发布日与他一起做了《Fable 实战指南》:

[AINews] Fable 实战指南

在我们祝贺(本节目好友!)General Intuition 发布新模型、(本节目好友!)Shunyu Yao 发布新模型,以及全世界等待 GPT-5.6 Sol Ultra 发布之际,人们正竞相在……之前探寻 Fable 5 的极限

可变软件的未来

请特别关注 Claude Mods(尤其是速查表):

总的来说,这也是 Thariq 另一条爆款推文的另一面:

云端大脑,本地之手

并试试 Claude Projects:

“手”这一术语不仅仅是对像 Cognition 这样的前沿编程智能体公司正在构建的本地/云端范式的类比,而且也与安全系统讨论尤为相关——我们将在即将推出的一期节目中与 Anthropic 讨论这些内容,因为他们正准备以负责任的方式部署 AI,迈向前沿。

对于想要我们在播客开头预告的 Thariq 写作技巧的人,请在此观看完整视频:

从 Claude Code 的迅速崛起到一个智能体能够重写自身框架、跨团队协作、并在云端和本地环境中运行的未来,我们构建软件的方式正在以极快的速度改变。在本期节目中,Anthropic 的 Thariq Shihipar 与 swyx 和 Vibhu 一起深入探讨高级用户如今实际上是如何使用 Claude Code 的、为什么提示词仍然是一门高技能学科,以及 Anthropic 认为智能体框架接下来将走向何方。

我们深入探讨了 Claude Code 不断演进的界面:Ask User Question 与 elicitation、作为持久生成式界面的 artifacts、用于多人智能体工作流的 Claude Tag、Projects、模型 effort、实现说明,以及用于自定义 harness 本身的全新 Claude Mods 系统。Thariq 解释了为什么 Claude.md 最终可能会消失,为什么最聪明的模型在许多任务上也可能成为最便宜的模型,以及为什么可变软件可能成为应用程序构建和自定义方式的新范式。

随后,对话转向 智能体安全 和 Anthropic 的“Pacing the Frontier”论点。Thariq 梳理了近期事件,其中智能体发现了意想不到的方式来 通信、利用基础设施、逆向工程基准评分器,并将漏洞串联起来。我们讨论了沙箱、提示注入、自主智能体、可解释性、宪法分类器、探针、回退、Auto Mode,以及为什么保护能力日益强大的智能体可能成为未来几年最具决定性的工程问题之一。

我们讨论了:

为什么

智能体编码在不到一年内从有争议变成了默认选择为什么

提示仍然是使用 Claude Code 时最具杠杆效应的技能之一专家用户如何构建

Claude 的心智模型以及它能可靠地一次性完成什么为什么发现你的

“未知的未知”在智能体能力越来越强时更加重要Artifacts 作为

人类与智能体之间的持久生成式界面Claude 如何可能拆分为基于云的

“大脑”、本地或远程的“手”,以及动态界面Claude Tag、Projects 和多人智能体以及协作式智能体工作流可能如何演进为什么在

初始提示上花更多时间可以大幅减少智能体浪费的工作何时使用

低、中、高或最大 effort来应对不同的工程任务为什么前沿模型最终可能在

智能和 token 效率上都优于更小的模型为什么

实现说明可以揭示模型考虑过但选择不做的决策为什么

Claude.md 最终可能会消失——以及为什么有时不用它开始反而更好Claude Mods:自定义 Claude Code 的执行循环、UI、子智能体、路由和行为模型路由器、分叉智能体和监督智能体可自动改进智能体工作流为什么 Claude Mods 可能是

“可变软件”的早期预览

harness 工程的苦涩教训以及为什么智能体架构如此迅速地过时

Claude Tag如何成为多人工作的组织级 harness为什么让智能体访问公司数据会创造出一个巨大的新

安全面Exploit-Bench 事件中智能体发现了通信和协作的方式为什么智能体

入侵 Hugging Face 以获取评分器代码,而不是基准答案智能体如何以意想不到的方式

串联沙箱和基础设施漏洞为什么能力日益强大的智能体会让传统的

安全假设更难维持Anthropic 的

“Pacing the Frontier”提案背后的论点为什么软件工程师越来越多地从事

两份工作:工程和跟上 AI宪法分类器、探针和回退以及可解释性在生产中的样子

Auto Mode如何检查智能体的行为是否真正符合用户的权限为什么 Thariq 能看到严重的

AI 风险,同时仍然持有相对较低的 p(doom)

Thariq Shihipar

时间戳

00:00:00 引言

00:04:12 询问用户问题与智能体界面的未来

00:08:29 工件、项目与多人协作智能体

00:15:37 提示词工程作为 Claude Code 的核心技能

00:21:52 上下文、投入与更智能的模型使用

00:28:10 Claude.md 会消失吗?

00:32:49 Claude Mods:定制 Claude Code 框架

00:36:35 模型路由与可变软件的兴起

00:44:40 框架工程的苦涩教训

00:50:49 Claude Tag 作为组织框架

00:55:59 前沿节奏与自主智能体安全

00:58:22 智能体为评分器攻击 Hugging Face

01:05:34 当智能体需要更多算力时会发生什么?

01:10:32 AI 编程的变化速度超过工程师的跟进能力

01:17:17 探针、回退、可解释性与自动模式

01:28:32 AI 风险、p(doom) 与结语

文字记录

引言:在 Anthropic 的生活与变化的速度

Swyx [00:00:00]: 我们和来自 Anthropic 的朋友 Thariq 一起在演播室,我想总体来说,Claude Code,我——有太多边界在融合,而你自从加入 Anthropic 以来一直紧跟一切。你很早就接触了 Claude Code 本身,而且你也在其他播客里讲过那段经历,你还谈到过像智能体一样看问题。最近你做了 AIE 世界巡演的重磅演讲《Fable 野外指南》,显然你们发布了 Fable,所以那算是——那是作弊。而最近你还发布了 Claude Tag,我们也会谈到《前沿节奏》。Anthropic 有很多事情在发生。我想首要的问题是,在发生这么多事情的时候,在 Anthropic 工作是什么感觉?

Thariq Shihipar [00:00:48]: 我觉得那就像。我觉得有时候你会被甩得晕头转向。我觉得,就像,走着。当我加入 Anthropic 时,我是因为 Claude Code 加入的。就像 Claude Code 刚出来,我就想,“这太好了。”而 Opus 4 对我来说就像,我简直无法想象,它有多好?那对我来说是一个真正的时刻。但当时我在试图说服我的创业朋友们使用智能体编程,他们说,“哦不,我们的工程师觉得它还不够好,”之类的。我就想,“这太疯狂了。”而现在你,快进 12 个月,还不到,就像,是的,这就是所有人编程的默认方式,对吧?我觉得,就像,必须从推销它,到如今教人们如何最大限度地利用它、变得更高效之类的,这就像是一个巨大的变化。而且,是的,我觉得,作为人类,要跟上一切就是很难?我觉得事情发生得太快了,而且就像

Swyx [00:01:51]: 你就往上面扔更多智能体。

Thariq Shihipar [00:01:52]: 是的,就像智能体的东西比人类的东西扩展得好得多,人类这边就像,哦,现在有三件事在发生,它们都是紧急情况,你要怎么应对?是的。

教人们使用 Claude Code

Vibhu [00:02:05]: 你把时间分配在哪些事情上?你做了很多技术写作、工程工作。

Thariq Shihipar [00:02:10]: 是的,所以我觉得,当我加入 Claude Code 团队时,我想教人们如何使用 Claude Code,而且我觉得,这一直是我认为,也许我会花一点时间在上面,或者,我会去做的事情。我一开始花了一些时间在 agent SDK 上,我并不完全确定,当涉及到 harness 时,苦涩的教训会如何发展,对吧?就像,我觉得有时候我们会想,“哦,Claude Code 之后是什么?”所以最初我想,我只是想教人们如何使用 Claude Code,并让使用 Claude Code 变得更容易。而且我觉得,随着 harness 变得越来越好,现在的主要问题就是,你如何使用这些 agent,对吧?就像,这是一种如此高技能表达的事情。所以我做那个,然后我做工程工作。我做演讲,但我觉得,当我做工程工作时,我的目标是采纳我们从用户那里得到的反馈,并且,然后能够谈论,嘿,如何使用 Claude Code 来做工程。所以那里有一个很好的循环。是的。

Swyx [00:03:07]: 是的。我会——对于听众,我们会附上,你和 Sarah 为 Dev Writers 聚会做的演讲

Thariq Shihipar [00:03:13]: 哦,是的

Swyx [00:03:13]: 我们稍微谈过一点,嗯,首先你做工作,然后你谈论工作。

Thariq Shihipar [00:03:16]: 对。

Swyx [00:03:16]: 类似那样。

Thariq Shihipar [00:03:17]: 是的。

Swyx [00:03:17]: 这是播种和收获,或者

Thariq Shihipar [00:03:19]: 是的,收获和。播种和收获。

Swyx [00:03:21]: 类似那样。类似那样。是的,所以,然后稍微预览一下,我们要谈论 harness 的演变。它已经从仅仅是一个 CLI 走了很长一段路。我们要谈论 Claude Mods,它今天开始泄露,因为你没法保密。

Thariq Shihipar [00:03:36]: 是的。是的。

Swyx [00:03:39]: 是的,那里有很多。我觉得你开始于,比如,添加 ask user question 工具,人们又爱又恨。

Thariq Shihipar [00:03:48]: 是的。

Swyx [00:03:48]: 就像,我觉得它非常创新,然后现在我有,比如,我自己的版本。你有你的 Interview Me 版本。

Thariq Shihipar [00:03:55]: 是的。

Swyx [00:03:56]: 而且,是的,每个人都有自己的东西。而且,这不再重要了,因为现在你应该,编写提示来创建其他提示和循环以及所有这些事情。

询问用户问题和人机交互

Thariq Shihipar [00:04:05]: 当然,是的。

Swyx [00:04:06]: 那么,今天的最先进技术是什么?比如,人们在做什么。你在告诉人们今天做什么?

Thariq Shihipar [00:04:12]: 是的,向用户提问是模型第一次擅长于需求提取。我认为这就像是一种涌现行为,我当时想看看模型能否做到这一点。我有人机交互的背景,所以我在本科和研究生阶段就做过这方面的研究。所以这就像是……对我来说,这就像是人机交互,试图弄清楚,智能体如何与你沟通并提取需求,对吧?我认为,随着 Claude Code 变得越来越广泛,困难之一就是每个人都有自己使用它的方式,很难改变默认行为。所以例如,如果有人要求 Claude Code 做某事,Thariq Shihipar [00:04:59]: 有时他们只是希望它完成工作,因为他们可能是非常擅长提示的人,而有时他们想要……嗯,不擅长提示?而你需要……智能体需要澄清?所以这是一个很好的分界。就像,向你提问的工具就像沿着这一侧划分,比如,你是否觉得自己足够好,可以按原样指导智能体,或者智能体能够……智能体是否需要提取更多需求,与你更多协作,真正理解你的偏好?

Thariq Shihipar [00:05:27]: 总的来说,我相信几乎每个人都更偏向后者而非前者,也就是说,他们面对的问题有更多模糊性,他们知道的比他们想要的少,比他们自以为知道的少。但让这件事变得容易,就像是一个界面设计问题?所以,如果你在设计一个问题,或者如果你在处理一个问题,像什么是 schema 或者什么是调用栈之类的事情就非常重要。设计中的细节很重要。理想情况下,你希望在开始实现之前就提前弄清楚其中一些难题。是的,这就是为什么它们被称为未知数,对吧?所以我认为这永远会是 agentic coding 中的一项技能,就是弄清楚你的未知数。所以,因为即使模型超级智能——它也需要知道你想要什么?而且你有偏好。你需要把那些偏好提取出来。所以这就是我认为我在推动的方向。那么问题就是,agent 如何与你交互?我认为 HTML 一直是做到这一点的主要方式。我们最近添加了 artifacts,对吧?而 artifacts,我认为我们在解释如何充分利用它们方面做得不好,或者说,我做得不好。我们有很多强大的能力。它们有一个关联的数据库?所以每个 artifact 都可以存储和写入持久数据。它们可以反馈给 Claude?所以,人们还没有在做、而我在试图鼓励的一件事,就是 dashboard artifact 这个想法。比如你让 Claude 长期处理一个项目。也许它像一个看板之类的。它可以把看板数据存储在自己的数据库中。多个 Claude 可以通过 artifact MCP 访问这些数据,而且那个 artifact 也可以与那些 Claude 对话。所以,我们正在为你构建这些原语,让你能够通过 artifacts 拥有这种生成式界面,从而让你从 agent 那里呈现更多丰富的细节。而且我认为,现在 agent 相关的几乎所有事情,都是这个问题:你以为自己想要什么,但你并不真正知道自己想要什么,而 agent 需要大量细节,在循环中与它们协作非常重要。所以 artifacts 就是我们试图在那里演进的方式。但还有很多工作要做,因为它比一道选择题复杂得多?就图表、代码片段和 schema 之类的东西而言,那个问题有更多细节。但是,artifacts 是更 AGI-pilled 的做 ask user question 的方式。所以,是的。

Artifacts 作为 Harness 的界面

Swyx [00:08:15]: 关于这些 artifact 的东西,有一件事我不清楚,就是什么样的反馈应该通过 artifact 进入,什么样的反馈应该通过 Claude、通过聊天进入?因为更 AGI-pilled 的做法就是把一切都喂给 Claude。

Thariq Shihipar [00:08:29]: 我认为更倾向于 AGI 的做法是浏览工件。就像,我认为,在极限情况下,工件将成为你进入 harness 的界面?你可以实时评论这个,比如,你的计划、工作的实时文档。你也许能看到多个代理和不同的代理在做这件事,而那个工件是为你现在正在做的工作构建的,对吧?所以,每个都有点不同。我认为从基础设施的角度来看,我们还在朝着那个方向前进。但是的,我认为,为你的 harness 动态生成的界面可能就是未来的方向。

Vibhu [00:09:03]: 有没有一个版本是从 CLI 或聊天中抽象出来的,还有你。因为现在,很多都是,好吧,你在和 Claude Code 交互,你得到返回的 HTML 作为模型。它相当丰富。有图表。工件是将这些连接在一起的方式。为什么不直接都那样做呢?

分离大脑、手和表面 UI

Thariq Shihipar [00:09:22]: 然后它就变成了,分离出,推理发生在哪里?智能发生在哪里?工作发生在哪里?就像,我认为这就像是,本地和云之间的区别,对吧?所以,我认为现在,如果你使用 Claude Code,它是本地的,比如,你可以启动远程控制,例如,以获得一些云行为,或者你可以在云中启动 Claude Code,对吧?我们正在朝着一个地方前进,而不是像 Claude 那样,你给本地 Claude 发消息,它在本地启动一个会话并执行,更像是你有一个在云中运行的 Claude,你给它发消息。它可以运行本地或云会话。这就是 Claude Tag 的工作方式。但是,随着时间的推移,我们也会添加本地手。所以,本地手将是那个代理能够访问你的计算机(如果它在线)并在那里工作的能力。因此它可以启动许多不同的子代理。它可以,那些子代理可以相互通信,这就是工件出现的地方,以显示所有的工作。所以你可以想象,就像。你正在分离这些东西。所以,有表面 UI 显示,那是一个工件,托管在某处,有数据库等等。有推理智能,对吧,发生在云中,你不必担心关闭你的计算机或其他什么,对吧?然后还有,手。就像,它可以是本地的,它可以在远程沙箱或你需要完成工作的任何地方。这就像是解包,就像现在的 Claude Code 体验,现在一切都发生在一个地方,对吧?所以。

多人代理、Claude Tag 和项目

Vibhu [00:11:00]: 你怎么看,多人方面?比如说团队想以这种方式工作。现在它非常个人化,但你怎么看多人的未来?就像现在,我想有 Claude Tag,这是一个版本,但是。

Thariq Shihipar [00:11:12]: 我们正在推出 projects。所以 projects 是这样一个抽象概念,类似于 Claude Tag,但运行在我们的 Claude 产品上,对吧?所以你可以给它发消息,然后它就会做类似 Claude Tag 的事情,比如派生出子代理。我们认为它带有多人协作的特性。Claude Tag 在某种程度上更原生地支持多人协作,因为它就在你的 Slack 里,权限什么的都已经处理好了。但我确实认为多人协作是故事中很重要的一部分,而且需要更紧密地整合在一起。你可以想象这变得有多复杂,比如,你有了手,但现在别人的电脑上也有手,你需要给它们授权,或者你有你的 MCP,别人有别人的 MCP,你怎么弄清楚如何使用它们,对吧?这变得相当复杂。而 Claude Tag 在磨平所有这些问题上做得很好,对吧?所以,比如当你有 Google Docs 时,它如何访问 Google Docs 呢?它通过共享的 Claude MCP 来访问,或者如果它没有访问权限,也可以通过你的本地凭证来访问。但总的来说,我认为 Claude Tag 是我们的多人协作产品,它对于这些本质上就是多人协作的事情非常有用。比如,值班,举个例子,事故本质上就是多人协作的。你想 @Claude,你想让多个人登录,你想让它能够找到上下文。我觉得每当我正在做某件事,而我想要隐私或安全,或者我想让别人来审查时,这真的很好用。我会为每个项目建一个频道,比如在法律事务上,我会说:“嘿,我想发布这个。你能不能……”就像这样。Claude 知道一切,直接和它聊就行。这样法务就能得到精确的答案,关于到底什么代码会被发布,而我不需要参与其中,对吧?所以我认为多人协作正变得越来越普遍,是的,每个人都可以和 Claude 一起参与。我认为 Claude Tag 就是那样的产品,而 projects 会从单人开始,然后扩展。

Swyx [00:13:14]: 我觉得有一个关于身份和隔离单元的问题,也许是两个问题。

身份、权限与隔离

Thariq Shihipar [00:13:20]: 是的。

Swyx [00:13:20]: Claude Tag,你特意选择让它拥有自己的身份

Thariq Shihipar [00:13:26]: 是的。

Swyx [00:13:26]: 这是一个有争议的选择。还有其他方式可以做到。

Thariq Shihipar [00:13:30]: 是的。

Swyx [00:13:30]: Claude Projects 听起来,如果它像 ChatGPT Projects 的话,隔离的是那些工件,那个云端实例,大家都在上面协作。听起来,它应该像是,如果你和法务在某个事情上协作,那个频道应该就是一个 project,对吧?就像它现在还不是

Thariq Shihipar [00:13:50]: 是的。

Swyx [00:13:50]: 但那是自然的下一步。

Thariq Shihipar [00:13:53]: 是的,我觉得在 Claude Tag 中,它实际上是。就像 Claude Tag,你必须自己做安排。所以 Claude Tag,是的,每个频道你可以随意命名,而我命名

Swyx [00:14:04]: 是的。

Thariq Shihipar [00:14:04]: 就像每个功能

Swyx [00:14:06]: 是的。

Thariq Shihipar [00:14:07]: 作为一个频道。

Swyx [00:14:07]: 而且,但我觉得好像存在某种转——就是说不清楚什么时候会发生转移,因为假设确实如此。如果你有一个同事

Thariq Shihipar [00:14:14]: 是的。

Swyx [00:14:14]: 他把所有这些事都打上标签,是的,确实存在转移

Thariq Shihipar [00:14:16]: 是的。

Swyx [00:14:16]: 因为这是同一个人。但用 Claude 的话,就不清楚它是否必然是这样,嗯,不,你并不知道任何。你并不知道其他那些东西。你应该只用这些东西。

Thariq Shihipar [00:14:25]: 这就像冰山一角那个梗,对吧,你可以这样。这就是我们花了那么多时间在上面的东西

Swyx [00:14:31]: 是的。

Thariq Shihipar [00:14:31]: 就好像有无限的表面区域,比如,好吧,你想让 Claude 们。不是无限,但就好像有表面区域,很多很多的表面区域需要弄清楚,比如权限和可见性,以及你怎样才能让 Claude 尽可能好、尽可能安全地运作?显然,这对我们非常重要,因为对我们代码库的安全来说非常重要。所以我们在这上面投入了大量时间。是的,有太多边缘情况你可以想到,比如,哦,对,这个频道里的这个 Claude 有不同的权限,但它可以给另一个频道发消息,它难道不能通过那种方式外泄数据吗?或者你能不能,比如。如果它用了你的 MCP,然后又给别人发消息呢?就好像有太多太多,而我们真的投入了大量工作把它打磨平整。

Swyx [00:15:14]: 是的。大量的工作。好。Fable?

Fable 与提示的元技能

Vibhu [00:15:18]: Fable,你写了两篇好文章。你写过很多好文章

Thariq Shihipar [00:15:22]: 是的。

Vibhu [00:15:22]: 但关于《Fable 实地指南》、《构建 Claude Code》。我很好奇,从你所看到的来看,在 Anthropic 内部和外部的顶级用户身上,你有没有看到什么共同的模式?比如,要最大程度发挥 Claude Code 的作用,最佳实践是什么?

Thariq Shihipar [00:15:37]: 我说的那个元技能,比如提示词,是非常重要的吧?诸如此类。我觉得这话说起来可不简单,因为我认为很多人会说:“哦,提示词不重要。就像我随便说一句话,Claude 就会去做。”而我认为提示词其实就像,这个。它就像公开演讲,或者写作之类的,面向特定的受众,而那个受众就是 Claude。你需要建立对 Claude 的心智模型,了解它如何思考、如何运作,对吧?所以,与 Claude Code 协作时最重要的技能,就是拥有这种对 Claude 的心智模型,对吧,知道它擅长做什么、能一次搞定什么、不能做什么。很多人你看他们写提示词,就是很短的提示词,但他们对 Claude、对代码库之类的东西有着非常好的心智模型,所以看起来毫不费力?但这其实是一个高技能上限的事。所以,花大量时间写提示词、建立对智能体如何运作的心智模型和直觉,这项工作真的非常重要。然后我觉得下一件事就是我们之前谈到的未知的东西,就是能够发现你不知道的、或者你还没有写下来的东西,去学习不同的东西。我认为随着 Claude 能做的事情越来越多,你去做一些对你来说属于分布之外、而你领域知识又很少的事情的可能性非常高?而你能越多地学习词汇以便能够给 Claude 写提示词,这就变得非常重要。所以我觉得最重要的未知就是未知的未知,就是那种你甚至都不知道它存在的情况,对吧?对,完全正确。我觉得这就像是地图与疆域的一个例证,对吧,就是你说:“好,这是我的提示词”,而疆域就是智能体实际需要做的工作,对吧?如果你非常精确,你就能给出更精确的东西,对吧?所以比如说,在设计方面,我不太精确。我不是设计师,所以我会说:“给我八个不同的样稿。”但如果我是设计师,也许我会说:“哦,嘿,这里有一些参考网站。”比如,“我想要这种字体和这种风格,这里有几个不同的组件可以可视化。这里有一个 Figma 画板可以引入,”之类的。所以你可以用那种语言精确得多。而如果你不是设计师,你就只能试着去学习那种语言,或者去学习那些未知的未知。我觉得这对所有事情都是如此。你越能和 Claude 一起学习事情如何运作,你的提示词就会越好。我觉得另一个很好的例子是游戏设计,很多人会说:“哦,我现在可以凭感觉编码一个游戏了。”然后他们说:“它不好玩。”而游戏设计的关键就在于,这些选择中的每一个都有很多

品味、领域知识与学习词汇

Swyx [00:18:25]: 变体。

Thariq Shihipar [00:18:25]: 其中有很多技艺。所以就像,哦,好吧,当你在做一个飞行游戏时,飞机的感觉以及它对你操控的响应方式有很多,比如。一个游戏设计师会在这上面花上好几天。对吧?还有就像

Swyx [00:18:44]: 对我来说,这就是品味,对吧?

Swyx [00:18:45]: 就像从一千个数学上有效的答案的可能空间中

Thariq Shihipar [00:18:49]: 是的。

Swyx [00:18:49]: 这是人类会喜欢的那个。

Thariq Shihipar [00:18:51]: 是的。对。

Thariq Shihipar [00:18:52]: 我觉得对于品味,我对这个词有点纠结,因为我觉得你说得对,但每个人都有不同的定义,而且它听起来有点,听起来像是低技能或者几乎像是精英主义,你会觉得,哦,好像某些人是有品味的?

Swyx [00:19:06]: 就像品味是我所说的品味。

Thariq Shihipar [00:19:07]: 是的,没错。

Swyx [00:19:08]: 而且就像这些人没有品味。

Thariq Shihipar [00:19:09]: 是的,没错。哦,就像工程师没有品味。就像我,像创始人,有品味。

Thariq Shihipar [00:19:14]: ?而且我认为那不是真的。就像我认为工程师对于这些特定的问题有很多品味?而且我认为每个人对特定问题都有品味。我认为就像Jason Liu,比如说为了,是的,有品味,你必须吃?

Thariq Shihipar [00:19:32]: 而且我真的很喜欢这一点,就像,好吧,你必须做很多事情。你必须迭代并弄清楚你想要什么,你喜欢什么,并且,像建立那个领域

Swyx [00:19:41]: 是的

Thariq Shihipar [00:19:41]: 领域词汇。然后当你提示时,你就像为产品综合所有这些。

Swyx [00:19:46]: 当别人说得比你好时,是不是很烦?

Swyx [00:19:48]: 就像,操,我得永远引用这个人。

Vibhu [00:19:51]: 不得不永远引用Jason Liu。

Vibhu [00:19:53]: 他会喜欢这个的。

Thariq Shihipar [00:19:55]: 所以我得到提示,不止这些。

Vibhu [00:19:57]: 有时甚至不是那样。有时只是直觉,对吧?就像你甚至没有意识到你想要什么,直到模型把它输出出来,然后你说,“哦,这感觉立刻更好了,”对吧?

语音提示和信息密度

Thariq Shihipar [00:20:07]: 是的,没错。

Swyx [00:20:09]: 我反复思考的一件事是,我觉得我一半时间提示的方式,比如说我用语音。

Swyx [00:20:16]: 我说语音了吗?其他人有语音。那是相反的。那就像我漫无目的地说了两分钟,按下功能键然后松开,然后希望它能弄明白。而且通常它确实能。

Thariq Shihipar [00:20:26]: 是的。

Swyx [00:20:26]: 但它不像结构化的提示那样深思熟虑,就像良好的沟通,好像它是一个PRD或备忘录。这是人们做这件事的方式吗?有像双模态提示,有些提示你花很多时间 upfront,其他提示你只是匆匆写下?

Thariq Shihipar [00:20:43]: 我不认为语音必然是低的。就像我认为它更像是提示中有多少信息。就像模型可以。就像你可以并且像添加一些句子

Swyx [00:20:53]: 对

Thariq Shihipar [00:20:53]: 然后就像,“哦,我改主意了”,在提示词中间这么说,它就能完美地遵循吗?所以我觉得文本的实际格式没那么重要,但重要的是它的能力。就像里面有多少信息,对吧?而且我觉得对于语音来说,很多时候,回到人类与智能体交互这个话题,对很多人来说,说话就是比打字容易得多?而我。如果那能从你那里获取更多信息,那就更好。

Vibhu [00:21:21]: 在某种程度上,感觉就是给模型尽可能多的上下文

Thariq Shihipar [00:21:24]: 是的

Vibhu [00:21:24]: 在启动之前进行提示是一种最佳实践。我不知道。很多时候,比如我刚开始试用 Fable 的时候,我会花整整 30 分钟来真正精心打造一个很长的提示词。我认为这是模型运行时间越来越长的一种回应,对吧?当它们处于循环中时,推动它们仍然有点困难,但我就是会凭直觉花更多时间来启动那第一个提示词,并大量地与之协作。

前期多投入,少迭代

Thariq Shihipar [00:21:52]: 我个人的观点是,如果我是一名软件工程师,如果我只是在经营自己的初创公司,比如说,我想我大多会坚持最多 20 倍?也许验证和代码审查是分开的事情。但我觉得我经常看到的是,人们在做这件事时会触及速率限制,就像,哦,它做了很多工作,然后你说,“哦,我不喜欢这个。”就像,“你能撤销这个然后重做吗?”然后你就在这个模型本可以完成的事情上反复迭代,如果你之前花了更多前期时间或者给了它更好的上下文的话?而相反,你就像,“不,不喜欢那个设计。试试这个。”或者像,“你把这个搞砸了,”之类的。然后那就会消耗掉你更多的使用量。所以这就像,我想也许是一个关键提示,对效率来说也是如此,对吧?而且是的,我觉得就像上下文,不仅仅是关于目标是什么的上下文,对吧?比如你是在构建一个原型还是一个生产环境的东西?比如你可以在哪里花费算力,或者什么时候,在哪里不能花费算力?我觉得有时候你必须给模型许可,或者不给它做某些事情的许可,因为它无法凭直觉知道你想在这个任务上花多少,对吧?你可以为此使用 effort。所以我做了——我正在写一篇关于这个的博客文章,就像,如果你想。因为我们看到 effort 会随着任务的复杂度而扩展。所以对于安全来说,effort 能带来多得多的结果。比如高 effort 对比低 effort,会大大改变评估结果。但对于软件工程来说,它不会改变太多,因为 effort 主要花在验证和边缘情况测试之类的事情上。所以就像能够给模型这样的指导,比如,“嘿,这个问题是我认为我想让你花大量时间验证和做边缘情况测试的,”?

Effort、模型选择与验证

Vibhu [00:23:43]: 那模型组合呢?所以,有 Opus 和带 effort 的 Fable。

Thariq Shihipar [00:23:47]: 是的。

Vibhu [00:23:48]: 那里还有 Haiku。

Thariq Shihipar [00:23:49]: 是的。这还不完全成立,但已经非常接近了——我认为前沿模型将在几乎所有方面都占据帕累托主导地位。大概吧。有时候我觉得 Opus 可能就具有帕累托优势。是吧?我觉得这取决于事情如何发展,比如如果是更新版本的 Opus。但我认为,越来越明显的是,那个聪明的模型将能够用比其他模型更少的 token 来完成简单任务,因为有了验证。有了验证,在极限情况下,你的模型不需要验证,对吧?如果它是一个完美的模型,它只做一次工作,然后就像,“好吧,我搞定了?”而随着 Fable 的发展,我越来越觉得,“兄弟,你不需要启动 Chromium 然后给所有这些东西截图。”我能看出来。你做完了,对吧?所以很多……在更高的努力程度下,你会花更多的 token 来验证。但如果你在处理更简单的问题,而很多软件工程就像——在 Fable 里,低和中等稳定性——它可以花更少的 token 来验证。随着模型变得越来越聪明,它们就能直接说,“好了,完成了。”?比如,我可以为了保险起见跑一下 lint,但是,我知道它能通过 lint 检查?你甚至不需要做那个。而那将比更小的模型在 token 效率上高得多。是的。

Swyx [00:25:15]: 我们这边有没有什么好的实践,可以用来判断我们是不是用了过多的努力?比如,我特别

Thariq Shihipar [00:25:23]: 是的

Swyx [00:25:23]: 讨厌在那上面浪费时间。

Thariq Shihipar [00:25:24]: 是的。我明白你的意思。我觉得,就像在这篇博客文章里,我的大致分布是,代码审查和安全应该是高或最高,而软件工程

Swyx [00:25:37]: 你说的是按领域推荐混合设置。

Thariq Shihipar [00:25:37]: 是的。我觉得,如果你在做 UI 之类的,低和中等就可以了。我觉得如果你在构建一个 API,你想确保覆盖足够的边缘情况?所以我觉得,就像我说的,建立那种关于事情在这些分布中如何运作的心智模型,是的,是工作的一部分。

实现说明与决策日志

Vibhu [00:25:56]: 这更多是直觉驱动的还是评估驱动的?因为我猜这会随着你的进展而变化。

Swyx [00:26:00]: 他有评估。

Thariq Shihipar [00:26:01]: 是的。所以我在博客文章里做的是,我梳理了所有的终端基准评测。大概有 70 个问题,我展示了,比如说,在安全类问题上它做得更多。然后我也看了一些对话记录,就是看它——它回答了什么,它忘记了什么之类的。很多时候,这也是我的另一个提示技巧,就是让它写决策笔记或实现笔记,因为在它面对的每一个评测问题里,它都会想到正确的解法,然后决定不去做。它就像,哦,答案是这个。如果我这样做呢?然后它又想,哦,大概不行吧?然后继续往下走。而这在更高的最大级别上,就是大多数失败的原因。模型完全不知道怎么做的情形非常少见。如果你有这些实现笔记,那你就可以回顾,然后说:“哦,我想让你做这件你没做的事。”总体而言,模型在把这一点呈现出来方面越来越好了。比如,我在 Fable 5.1 的对话记录里看到,当它输出时,它也会点明自己的决策过程。但把这一点在 harness 里做得更明确会更好。而现在我们在提供让你修改 harness 的方式,这样你就可以,比如,加一些

Vibhu [00:27:23]: 哦。

Thariq Shihipar [00:27:24]: 在那里计算。是的。

Swyx [00:27:25]: 是的。所以我想点出你提到的两件事,我认为它们存在于提示之外。一个是,我们把它叫做重要到不该放在提示里的提示。它在 Claude.md 或 Agents.md 里

Thariq Shihipar [00:27:38]: 是的

Swyx [00:27:38]: 也就是目标,对吧?比如你的处境、你的目标、你想要的东西、那件事。然后第二点是决策日志、实验日志,或者任何你希望跨越当前会话留存下来的轨迹日志,用来做那些事。这些算是外部产物,没有标准。没有——它不像 skills。它不像 MCP。没有标准。它,它就是一个 markdown 文件。首先,这是对的吗?Claude.md 要消失了吗?你公开表示过不喜欢 Agents.md,但你还是打算做?

Claude.md、Agents.md 与模型专属指令

Thariq Shihipar [00:28:10]: 是的。好吧。所以 Agents.md,是的,我们,我们打算做。我觉得只是,不同的模型彼此差异很大?但我意识到,维护不同的版本实在是太麻烦了?而且是的,随着模型越来越好,它们完成更简单任务的下限也更高了。所以我确实认为,极限情况下,Claude.md 会消失,也许甚至不用,不用那么久。我觉得,我觉得现在也许不用 Claude.md 来启动一个新项目会更好。

Swyx [00:28:44]: 是的。

Thariq Shihipar [00:28:44]: 我觉得,也许如果你看到非常反复出现的失败模式,你就把它们加到你的 Claude.md 里。真正棘手的是,这会因模型而异。所以,如果你加了一堆失败模式,或者甚至

Swyx [00:28:57]: 所以你需要 Fable MD,你需要 Opus MD。

Thariq Shihipar [00:28:59]: 或者,甚至 Fable 5.1 对 Fable 5。

Swyx [00:29:03]: 是的。

Thariq Shihipar [00:29:03]: 这很烦人。我不是说,Swyx [00:29:05]: 是的

Thariq Shihipar [00:29:05]: 就,我们不是,就,故意这么做的?就只是,就,模型就是这样运作的,对吧?所以,就,也许,就,Fable 5 有这种,就,失败模式,而 Fable 5.1 没有。如果你保留这个上下文,这个记录着一堆不同失败模式的运行日志,它们可能会过度约束 Claude?所以这就像。我们刚刚为技能添加了评估插件。

Swyx [00:29:28]: 是的。

Thariq Shihipar [00:29:29]: 所以现在你可以评估一个技能是否更好。我想我们团队的 Daisy 做了这个。所以,是的,这就像我们正在努力解决这个问题。我们知道,就,你仍然需要为此花费 token,而且,就,它并不,它并不完美,但,就,我们正在努力帮助解决这个问题。

Swyx [00:29:44]: 所以就提示词而言,我想提供的一个建议是,我经常告诉人们的一件事:足够高级的提示词与足够高级的高管沟通是无法区分的。所以我提到过——这是 Heavybit 的一个高管沟通工作坊,是我职业生涯中见过的最好的。他们教一种叫做 SCQA 模型的东西。直接谷歌一下。它是个,它是个东西。就,人们做提示词已经做了几十年了。它只是叫做高管沟通。就像当一个人必须向组织架构图下方的数千人沟通时,这就是你要做的。所以情境、冲突、问题和答案,这就是你写备忘录的方式。但显然有时你没有答案,但你至少可以列出 SC 和 Q,然后他们在里面有一些例子。所以只是给人们留下一些线索,如果他们想探索的话。

被低估的提示词模式与 ELI5

Vibhu [00:30:31]: 在我们继续之前,我想问你,还有其他被低估的技巧吗,人们可以从 Claude Code 中获得很多价值但他们没有使用的方式?

Thariq Shihipar [00:30:41]: 是的,我认为很多都在那个,这些未知的,就,文档里。就,我给出了一堆示例提示词,比如用它来头脑风暴,用它在你之后来测验你。我们添加了这个,就,像跟五岁小孩解释一样的技能,它是一个非常短的提示词。它甚至没有说像跟五岁小孩解释一样。就,这个提示词的关键词是大局观,少用词。就,那就像是主要的东西。而且它好得惊人?就,你,就,我想我发过关于这个的推文,它就像 /eli5,而且,就,你可以把它作为插件安装。但是的,它,就,在直击废话方面好得多,就像,是的,就在这里。所以图表,就,相当清晰。我认为关于 artifacts 的一个真实情况是,就,它们放了太多文字进去,人们不读 artifacts?所以,就,这个把它简化了很多。而且,是的,这个来自于,就,只是 Anthropic 的人,就,经历非常复杂的事件然后想,“发生了什么?”?所以,这个我认为很棒,是的。

Swyx [00:31:47]: 我的版本是这个,它就像测试你的理解。给你几个选项,然后,就,如果你答错了,你就有一种你认为正在发生的事情与实际正在发生的事情之间的不匹配。

Thariq Shihipar [00:31:58]: 是的。我认为这是那种每个人都喜欢谈论,然后很少有人真正去做的事情之一。就,我认为

Swyx [00:32:05]: 真的很有帮助。

Thariq Shihipar [00:32:07]: 是的。但大多数人就是不想被考问某些事情?不幸的是,我认为这是我们需要……的事情之一。

Swyx [00:32:16]: 在事情之前问你问题,或者问你问题的反面是什么?

Thariq Shihipar [00:32:19]: 是的。

Swyx [00:32:19]: 这是在事情之后。

Thariq Shihipar [00:32:20]: 没错。是的。

Vibhu [00:32:21]: 这是一个保持脚踏实地的好方法,比如,你到底知不知道自己在做什么,对吧?最糟糕的情况是,人们给你发来一堆垃圾,而他们自己都没搞明白自己在要求什么,或者输出是什么,然后就像,“老兄,我不想读这个。你到底知不知道这是什么?”所以,你给自己定个规矩:在发送东西之前,你至少应该知道实现了什么。

Claude Mods:定制 Harness

Thariq Shihipar [00:32:41]: 是的,但你可以把它做成一个 mod,你可以构建自己的 mod,来确保你测试它。所以是的,你可以这么做。

Swyx [00:32:49]: 好的。我们直接进入正题。什么是 Claude Mod,这张图展示了什么?

Thariq Shihipar [00:32:54]: 是的。好的,Claude Mods 就是你可以定制整个 Claude Code harness,我们将要……如果你有需求,我们会,比如,让你,比如,请告诉我们。我们会添加越来越多。这适用于 CLI,也适用于桌面端。也许将来会适用于 Claude Tag。我不知道。比如,我们正试图让它非常可扩展。你可以看到这张参考表。我不想让人们被它压垮?在高层次上,你可以定制 harness 的执行和 harness 的 UI。所以,比如,你说 Boris 的那个俄罗斯方块例子,那就是定制 UI,对吧?比如在游戏中显示俄罗斯方块。

Thariq Shihipar [00:33:35]: 但是,比如,假设你想做这件事,你……在每个项目之后测试你的假设,或者测试你的理解,对吧?你要做的是让 Claude 制作这个插件。它会在每个提示之后启动一个分类器。所以,比如,在每个回合结束时,你会启动一个子代理,或者一个分叉代理。分叉代理会保持提示缓存,对吧?所以这就像那种反直觉的事情之一,你可以分叉并做一个小的请求,而且它会非常便宜,因为整个提示缓存都已经完成了。所以你可以说,“这个任务完成了吗?”就像

Swyx [00:34:18]: 这就是你做 BTW 和所有这些的方式。

Thariq Shihipar [00:34:20]: 是的。底层的分叉代理,没错。但你可以在分叉子代理中,比如说,“这个任务完成了吗?如果完成了,返回 true。”然后,在你的钩子中,或者在你的插件模块中,或者抱歉,可能是在子代理中,你会说,“如果为 true,给我一个测验。”给我问题和答案,然后以 JSON 格式,然后你解析它,然后在提示输入上方显示这个列表的问题,对吧?所以这有点消耗 token,因为,你必须在每个助手回合结束后都这样做。但它是一个轻量级的分类,然后你可以得到这个测验,然后你会看到,Claude 总是会为你做这件事。你不需要记得去做。我们讨论过很多这样的技巧,对吧,比如,实现笔记。你现在也可以为实现笔记添加一个工具。所以,我要添加的这个工具,比如,注册,我想我称之为假设,但也许我会改一下。这是一个模块。所以,你给它一个注册假设工具,然后它会保持一个列表。它会。每次它做的时候,它会保持一个,比如,添加到列表中,然后在最后它会显示那些假设?我正在做的另一个模块是模型路由器。所以,比如,内部的,Claude 模型路由,对吧?所以它。这是,我想说我们默认不做模型路由的原因是,这是一个难题?而且像

分叉代理、假设跟踪和模型路由

Swyx [00:35:51]: 你会搞错的。

Thariq Shihipar [00:35:52]: 是的,你,比如,是的,你会,比如,不小心用,比如,Fable 来处理难题,或者用 Sonnet 来处理

Swyx [00:35:57]: 是的,如果你有自动批准,但你没有自动模式。

Thariq Shihipar [00:36:01]: 嗯,你会有自动的。比如,你没有,比如,自动路由之类的。

Vibhu [00:36:04]: 你没有模型选择器的自动模式。

Thariq Shihipar [00:36:06]: 是的,没错。所以

Vibhu [00:36:07]: 我想到一个粗略的问题,比如,你开放这个的程度有多大,人们需要思考这个的程度有多大?比如,当你谈论提示缓存和构建路由器时,似乎你可以很容易地构建一个按查询路由的模块,而我很快就毁了我的计划,对吧?我想我的问题更像是,像这样的产品谈话是什么样的,对吧?它是给谁的?是给高级用户的吗?是每个人都能通过

Swyx [00:36:33]: 哦,绝对是高级用户,对吧?

Thariq Shihipar [00:36:35]: 是的,我认为这是高级用户,但 Claude Code 的本质就是有这么多人是高级用户?因为分享东西很容易,比如你可以。就像,一个人可以做一个好的模型路由器,不会一直破坏提示缓存,然后你可以,比如,组合它们。插件的另一个很酷的地方是它们可以互相挂钩和组合。所以我有一个,比如,mod,会在顶部创建一个模式选择器,任何插件都可以注册为一个模式。所以,比如,自动路由器可以是一个模式,对吧?或者,比如,你可以有一个模式,比如 artifact 模式,它主要是通过 artifacts 与你交流。比如,你可以在计划模式之间切换?所以,比如,你可以创建越来越多的这些模式。但是创建模式的能力本身就是一个 mod?所以这里有很多丰富性,但我们确实想让它相当容易。我们想——让它变得你可以直接,比如,安装别人的。你可以——你可以和 Claude 聊天,我们会,比如,确保它理解提示缓存之类的东西的细微差别,这样它就可以,比如,警告你。我认为这对 Claude 来说不是极其复杂的行为,但我们应该有一个关于如何制作 mods 的好技能。是的,我们会看看进展如何。但我确实认为这就像是可变软件的一个预览,以及,比如,生成式软件,就像你可以安全地定制。如果启用,你可以定制任何软件。我认为越来越多的应用理想情况下会做类似的事情?

高级用户、模式与可变软件

Swyx [00:38:13]: 顺便说一句,你,我们有,你有另一条很酷的推文,关于有一个无限金钱按钮,就像是让你的 SaaS 可以被代理消费。我认为可变软件很有趣,其他人也尝试过。我认为障碍在于当你可以做所有事情时,人们,用户往往会感到困惑。所以通常有效的东西就像一个有主见的流程。这是在较少主见的一边。就像是,好吧,给高级用户更多权力。我认为这可能是由 AI 解锁的,比如,你可以直接提示任何东西。

Thariq Shihipar [00:38:47]: 是的,或者可以有一个技能来提供这些主见?

Mods vs. Hooks vs. Artifacts

Swyx [00:38:50]: 是的。

Thariq Shihipar [00:38:50]: 然后,是的。

Swyx [00:38:51]: 所以了解一点,比如,TypeScript 和构建系统以及所有这些事情,最接近的——我很好奇,参与这个的团队,如果,我不知道你和他们有多亲近,如果他们从像 Babel、Webpack 这样的构建系统,所有这些,比如,老派的东西中汲取了任何灵感。因为听起来非常相似,就像那些东西的插件生态系统,它们可以互相组合。

Thariq Shihipar [00:39:11]: 是的,我没有深入了解技术细节,但我确实知道这是与 Bun 团队的某人和 Claude Code 团队的某人的合作。

Swyx [00:39:17]: 是的,这是一个构建系统的圣地。

Thariq Shihipar [00:39:19]: 是的。完全正确。这非常令人兴奋。但是,是的,就像,代理现在可以直接在你的软件中实现这种非常复杂的可扩展性。所以,是的,就像,另一个理由,就像。如果你经营一家初创公司,就像,你可以直接提示 Claude,然后说:“嘿,我们能不能做一个扩展系统?那会是什么样子?”

Swyx [00:39:37]: 是的。

Swyx [00:39:38]: 我真的很好奇,就像,你过去有钩子和插件,所有这些。那么,具体来说,mods 能做什么那些东西做不到的事情?

Thariq Shihipar [00:39:47]: 在内部,我们最初称之为函数钩子。所以,就像,这让你稍微了解一下,就像,钩子注册一个事件发生,然后,就像,一个要调用的脚本。这在 TypeScript 运行时内部运行着东西。所以,就像,你得到一些好处,就像,它在作用域中有很多东西,比如,例如,这个对话中有多少轮,对吧?就像,使用了多少令牌?等等。就像,消息是什么?诸如此类。所以它有一堆可以使用的消息。然后它只是,就像,更多的钩子。所以我们有,就像,或者很多,更多的,就像,你可以注册的东西。然后你可以做,因为。因为它都发生在进程中,你可以,生成子代理,带有四个竞赛和上下文等等。而且,就像,那会返回。你可以解析那些结果。你可以使用结构化输出来,就像,返回它们。然后你可以修改 UI,这是你在钩子中永远做不到的。所以,是的。

Swyx [00:40:50]: 是的。是的。所以修改 UI,这就是为什么你展示了俄罗斯方块例子。它是否也扩展到工件?我假设它会。

Thariq Shihipar [00:40:57]: 你——就像,工件就像一种不同的定制方式。就像,你绝对可以。我正在做的一个 mod 是,就像,这个仪表板 mod,它会,就像,提示 Claude 维护一个仪表板,那是一个工件。但它们就像,稍微正交,或者不正交。它们以不同的方式相互组合。就像,mods 就像,稍微更多,就像,在你的 Claude Code 框架中,改变代理循环?而且,就像,UI 是,就像,一个额外的好处。然后工件就像你想要,在高层次上看到东西,非常交互式。就像,可供性可以比,就像 TUI 甚至我们的桌面中的大得多。

下一步、监督者和持久指导

Vibhu [00:41:40]: 我猜你会有一篇关于差异的好博客文章,因为现在你也可以,做一个循环输出到一个工件,那是一个交互式仪表板,但你也可以用 mod 来做。只是有一些关于在我们不太了解框架的情况下在框架上做黑客的思考,对吧?

Thariq Shihipar [00:42:00]: 嗯,我对 mods 感到兴奋的一点是,Claude Code 里有太多东西你不得不记住?你会想,“哦,让我做这个,然后让我调用那个做循环的 dashboard 技能,”诸如此类。或者,“让我之后测试我的假设。”我觉得,如果你用这些小分类器之类的东西来做所有这些事,然后你说,“这些是我关心的东西。这是我想做的,”你就可以,你不必记住那么多。我正在做的另一个 mod 是一个 next steps mod,它

Swyx [00:42:28]: 我有——我正想说,我有一个 next step 技能。我总是运行 next steps。

Thariq Shihipar [00:42:32]: 它能访问你的技能吗?这是那种我会想的事情。

Swyx [00:42:37]: 我觉得可以。

Thariq Shihipar [00:42:38]: 好。是的,大概吧

Vibhu [00:42:39]: 技能需要特定的访问权限吗

Thariq Shihipar [00:42:41]: 嗯,我觉得有

Swyx [00:42:41]: 它们不是一直都有吗

Thariq Shihipar [00:42:42]: 我觉得有特定的提示,我猜,来了解你的技能。我觉得 Claude 有时会在整个过程中忘记它们。但不管怎样,这个想法是,是的,next steps 也像是,“哦,嘿,这发生了。用 explain 技能来解释发生了什么,因为这看起来相当复杂”?或者,是的,“用你的 unknown 技能。看起来你在要求模型迭代这些小改动。看起来你可以更好地提示。”比如,“如果你这样做呢?”对吧?所以,我觉得,是的,在那里花更多的计算。是的。

Swyx [00:43:20]: 而且它应该总是以多选题的形式出现。我们有,我有

Vibhu [00:43:23]: 我们有他的技能。

Swyx [00:43:24]: 我的 next step 技能是这样的。

Thariq Shihipar [00:43:26]: 好,完美。是的。

Swyx [00:43:27]: 你可以偷走它。

Thariq Shihipar [00:43:28]: 是的。

Swyx [00:43:29]: 但对我来说,全都是——我觉得模型真的总是需要被提醒,你在这里想做什么?

Thariq Shihipar [00:43:35]: 是的。

Swyx [00:43:35]: 看整个记录,然后想,哦,这是最初的目标吗?你的解决方案解决了吗?你偷懒了吗?如果你偷懒了,也许有原因。也许你需要我的批准。也许你需要,有两件事你想建议。所以这有点像 ask user question 或 interview me 技能的修改版。所以它是 next steps。

Thariq Shihipar [00:43:55]: 是的,没错。再说一次,用 mods 做这件事的好处是你可以把它作为一个 fork 子代理来做,所以它之后不会留在上下文中。所以你有这个想法,好吧,模型在做它的执行,而你几乎有一个像监督者一样的东西,确保你能做好 next steps。所以是的。

Swyx [00:44:15]: 是的。我确实有两个面板,我经常尝试有一个监督者的东西,保持高层上下文,然后实现

Thariq Shihipar [00:44:21]: 是的

Swyx [00:44:22]: 细节在另一个代理中。

Vibhu [00:44:23]: 我觉得随着模型变化,很多这些都被抽象掉了?半小时前你说了 harness engineering 的苦涩教训

Harness Engineering 的苦涩教训

Thariq Shihipar [00:44:31]: 是的

Vibhu [00:44:31]: 而我觉得,我们现在正处于另一个极端。

Swyx [00:44:33]: 嗯,对,正是如此。如果一切都可以自定义,那 Claude Code 到底是什么呢?

Thariq Shihipar [00:44:37]: 对。

Swyx [00:44:37]: 这也是我昨晚跟你聊到的。

Thariq Shihipar [00:44:40]: 对,我觉得这就是。我觉得「苦涩的教训」是反直觉的?就……另外,我们在这里其实有点误用「苦涩的教训」了,它更多讲的是规模化和算力之类的东西。但我觉得确实有某种东西,就是……我在这里把它当作一个近似说法,来说明 harness 会非常快地过时?以及它们变化的方式是反直觉的?所以最明显的大例子就是从聊天到 agent,你必须给它们全新的工具,对吧?但我觉得这个新版本,就是,哦,它可以修改自己的 harness,对吧?这就像一个「自己的 harness 循环」,是一种利用它能力的方式,对吧?或者它可以构建一个 artifact。我觉得我思考这件事的方式是,模型拥有越来越多的智能,它们现在比一般的软件工程任务要聪明得多。你看那些 terminal bench 的题目,它们就像在解雅可比猜想一样。倒也不是真的,但就是,它们相当复杂。作为一个软件工程师,我其实是做不出来的。

Swyx [00:45:42]: 你说的是 TB4 还是 TB2?

Thariq Shihipar [00:45:43]: TB3。TB3。

Swyx [00:45:44]: TB3。

Thariq Shihipar [00:45:44]: 对。它们相当复杂,但目标仍然是交付用户价值,对吧?就像你说的,要做的事情有无限的空间。所以你花费算力的方式,就是让用户保持在循环中,确保你最终能做出正确的决定,得到正确的输出。而 artifacts 和 mods 就是花费这种智能的方式。我觉得这就是,对,下一步。所以,对,我觉得 Claude Code 拥有 agent 循环的核心要素,而这些要素已经变得更复杂了。它需要一个沙箱来安全运行。它需要自动模式来确保权限……

Vibhu [00:46:21]: 审批。

Thariq Shihipar [00:46:21]: 对,审批。它需要 computer use 和 MCP,以及所有这些访问你数据的方式,它还需要网页搜索和网页抓取。所以,随着模型能做的事情越来越多,核心 harness 必须相当复杂且非常安全。但你和它交互的方式可以变化很大。

Vibhu [00:46:42]: 从 Claude Code 团队本身来看,你们还有哪些其他的 harness 工程最佳实践?我感觉曾经有一个 plan mode 的阶段,现在用得没那么多了。我们现在有了 auto mode。在某个时候你们砍掉了大部分系统提示词,去掉了示例。harness 工程还有哪些其他的最佳实践?

核心 Harness 原语与托管 Agent

Thariq Shihipar [00:47:02]: 我认为存在一条分叉路径,在某个时刻,最终,是的,模型将能够直接凭感觉编写出与 Claude Code 完全相同的版本,甚至能描述出我所谈论的所有这些复杂性,对吧?比如自动模式和计算机使用之类的功能。最终,模型将能够一次性完成这些。但我认为它们能一次性完成更简单的框架?所以,我觉得有些人。有时候你并不需要这种完整的,比如如果你不需要计算机使用或所有这类更复杂的东西。我认为在我们之前,你不得不使用像 agent SDK 这样的东西,它就像是 Claude Code 的封装,为了能够。而我会建议人们这样做,因为构建一个框架有太多的复杂性。而现在随着这变得更加抽象,我们有了像 Claude 托管代理这样的东西,它让你拥有那种复杂性,但仍然像,对,就像一个非常基础的、范围限定在你任务内的框架。是的,我认为存在这种杠铃效应,比如对于非常复杂的、对于像编码任务和这些复杂的事情,你应该使用我们的框架。然后对于许多更简单或更领域特定的东西,你可以构建自己的框架,因为 Claude 在构建框架方面已经变得更好了,而且我们有这些框架原语,比如托管代理。所以,是的。

Swyx [00:48:18]: 是的。是否存在一个总体的进展?假设第一章是超代码动态工作流,那么第二章是云模式。这会走向何方?

Swyx [00:48:29]: 你在哪里,你可以按需定制这个东西。

Thariq Shihipar [00:48:36]: 是的。我确实认为,像项目、工件以及拆分出大脑和手和界面这样的演变,是事情更趋向的方向。而且,我认为这还没有完全实现。部分原因是,这就像,只是更耗费 token?而且,我认为就像

项目、本地手和云到本地交接

Swyx [00:48:59]: 为什么项目会更耗费 token?我理解模式会稍微更耗费 token。不,这不是我担心的事情。

Thariq Shihipar [00:49:06]: 是的。

Swyx [00:49:06]: 但是什么

Thariq Shihipar [00:49:07]: 你在要求 Claude 做的事情。就像创建循环。就像你要求 Claude 为你做更多的工作。所以它要管理子代理并审查它,而不是你通常做那项工作。所以这就像会稍微更密集一些,比如。输出到工件会比正常输出稍微更耗费 token。我不认为会多太多,但是,就像把所有这些结合在一起,我认为我们仍在研究像本地手之类的东西,我认为这就是,是的,事情的发展方向,是的。

Swyx [00:49:37]: 是的。Claude 和本地是,交接非常有趣。我把它想成反向云远程。

Thariq Shihipar [00:49:44]: 是的。

Swyx [00:49:45]: 因为就像远程,你是在交接给云,但在这里云是在交接给本地,对吧?

Thariq Shihipar [00:49:49]: 对,没错。对,远程控制也是另一种方式。我想说的是,这就是我思考它的方式,也是我对这件事最兴奋的地方,但就像,和 Claude 协作有很多不同的方式。比如有些人经常用远程控制,有些人经常在网页上用 Claude Code。显然,在 Anthropic,我们经常用 Claude Tag,而 Claude Tag 很棒的一点是,我们为自己的执行搭建了所有这些基础设施。我确实认为,如果你是一家企业,那仍然是最好的方式。但如果你是个体用户,Projects 就是那种方式,能获得 Tag 的一些好处,比如那种监督代理,对,还能添加 artifacts 之类的东西,但不需要那一整套管理配置。所以我认为,使用 Claude 会有很多种方式。我觉得大概不只有单一一种。

Claude Tag 作为组织级 harness

Swyx [00:50:36]: 你这里提到了多人协作的东西。我们来聊聊 Claude Tag 吧。已经过去两个多月了。有很多公开的采用和尝试。

Thariq Shihipar [00:50:45]: 对。

Swyx [00:50:45]: 有什么新东西?发布以来你发现了什么?

Thariq Shihipar [00:50:49]: 就像,Claude Tag 是我们使用

Swyx [00:50:51]: 它大概占你们云使用的 80% 之类的?

Thariq Shihipar [00:50:53]: 对,就像不同的人有不同的用法?我觉得,也许那些更偏向产品迭代的人会用 Claude Code 桌面版,比如说。然后当你做那些更偏后台的工作、代码审查、安全,或者发起一个 PR 时,也许更多用 API 之类的东西,你会用 Claude Tag。但没错,我觉得这真的很令人兴奋。我觉得这是一种非常不同的范式转变,我觉得就像我们在 Claude Code 上经历过的那样,人们花了一段时间才真正接受 Claude Code 并理解它能做的一切。而 Claude Tag 稍微更复杂一些,因为它不只是装在你电脑上,你需要管理员帮你安装。但我认为一旦你到达那个神奇时刻,就非常令人兴奋。我觉得尤其是多人协作的东西,比如事件,和你们现有的告警之类的东西紧密挂钩,对吧?所以,你可以做。比如说,如果你是一家初创公司,也许任何时候有一个潜在客户进入你的数据库,你可以让 Claude 去研究它,然后

Vibhu [00:52:01]: 数据丰富,对。

Thariq Shihipar [00:52:02]: 对。然后,给相关的 AE 或销售人员打标签,说“哦,嘿,来做这个。”有很多真正涌现出来的、有趣的多人协作的东西。我觉得就像 Karpathy 谈到的,这是一种组织级 harness?所以组织只是需要多一点时间来弄清楚一切,但没错。

Vibhu [00:52:21]: 对。

Swyx [00:52:21]: 你经常用 Claude Tag 吗?

Thariq Shihipar [00:52:22]: 对。对。

Vibhu [00:52:23]: 这是个有趣的。我感觉 Anthropic 的大多数人都说他们大部分工作都在 Claude Tag 里完成。

Thariq Shihipar [00:52:30]: 对。

Vibhu [00:52:30]: 而且他们有一批一批的人,对吧?有些组织在用,说“太棒了。”

Thariq Shihipar [00:52:34]: 是的。

Vibhu [00:52:34]: 而且很多人会说:“我不明白。我看不出区别。我不知道为什么要用它。”但是,如果你们全力以赴,你们可能应该用它。

Thariq Shihipar [00:52:41]: 是的。

Swyx [00:52:42]: 他们会的。他们当然会用它。

Thariq Shihipar [00:52:44]: 是的。我认为很明显,就像我们有很多代币。但就像,我认为我们尝试做的是,即使 Claude Code 刚出来时,它使用的代币量相对于人们对 AI 成本的预期来说很多,对吧?就像没有人习惯每月花费超过 20 美元,对吧?

Vibhu [00:53:04]: 是的。

Thariq Shihipar [00:53:04]: 在 Claude Code 出来之前,然后你会说,“哦,靠”

Swyx [00:53:08]: 然后你做了 200。

Thariq Shihipar [00:53:09]: 是的,没错。所以

Swyx [00:53:11]: 然后你做了 15 个 Claude Code 账户。

Thariq Shihipar [00:53:12]: 是的。但是的,我认为没有人习惯每月在订阅上花费 200 美元。我认为他们还不理解其中的价值。而且我认为,就像 Opus 4 是一个非常昂贵的模型,而且有很多,它非常大,但 Opus 4.5 既好又便宜?我认为同样的事情会发生。就像 Fable 的智能会变得更便宜、更丰富?所以我认为像 Claude Tag 这样的东西就会有意义,就像你想为这些代币花钱,而且你会看到价值。所以是的。

Swyx [00:53:44]: 是的,特别是像被动和让我们称之为主动的情况,你并不总是。就像,这几乎是一个误称,你必须 @Claude 来做事情。有时最强大的用例或最 AGI 化的用例不是 @Claude。

主动代理和企业数据访问

Thariq Shihipar [00:54:00]: 是的,我觉得就像,是的,就像让 Claude 主动去做这件事。我认为,如果你是一家企业,我真的认为第一,把你所有的数据都设置好,让代理可以访问,这非常重要。这需要一些时间。你现在就必须做这项工作,即使你还不想在把所有东西都连接起来上花钱?比如你想等到模型变得稍微便宜一点。你想做这项工作,把它设置好。然后我认为有时候人们会说:“我在这里要自己搭建吗?”我认为 Claude Tag 真正棘手的事情之一是,安全真的非常重要?比如,我认为有很多方式,你可以,我知道你有一个建议页面,人们可以在那里提交建议,然后它会进入你 Slack 里的一个钩子,而有人对它进行了提示注入?现在你就把你的代码库泄露了出去,因为,或者代理被提示注入了,而它对你的数据拥有所有这些访问权限。所以,你的组织工具链越重要,或者你的组织数据变得越重要,所有这些事物的暴露面就越大,比如你还有外部 Slack 频道之类的东西,而在其中使用 Claude 是有用的,你可以在那些东西里使用 Claude。但你要如何确保自己不会被泄露或发生类似的事情?正如我们一开始说的,暴露面就像一座冰山,对吧?它只是,就像,水面之下如此之大,而你真的不想,就像,去考虑这个,尤其是在像非常重要的安全事件这样的风险之下。是的。

Swyx [00:55:36]: 我们要谈谈非常重要的安全事件吗?

Vibhu [00:55:38]: 哇。所以我当时在和 Hugging Face 的 Tomas 和 Clem 交谈,他们说:“也许我们需要放慢速度。也许我们把 Hugging Face 对代理开放得太过头了。”

安全暴露面与提示注入

Thariq Shihipar [00:55:50]: 哦,不。

Vibhu [00:55:50]: “也许我们需要回滚。”但是,他们处在另一个极端,最近遭到了攻击。

Thariq Shihipar [00:55:55]: 是的。

Vibhu [00:55:55]: 但是,我们应该为前沿设定节奏吗?

Thariq Shihipar [00:55:59]: 是的。好,所以 Dario 最近发布了一篇关于 Pacing the Frontier 的博客文章,它传播得非常广。我想谈这个的原因是,就像,这里有很多内容,但我认为从开发者的角度来看,就像,你会怎么思考这件事?而且,就像,真正让我豁然开朗的是阅读那些不同的事件?所以我认为,就像,有三个,我想。就像,有 meter 事件,有 Wikipedia 事件或 Wiki 事件,还有

Swyx [00:56:29]: CollisionWiki?

Thariq Shihipar [00:56:30]: 是的,CollisionWiki,然后还有 RubyGems,对吧?

Swyx [00:56:33]: 是的。

Thariq Shihipar [00:56:33]: 而且,是的,就像,这简直太疯狂了,对吧?所以,就像,我想具体说说发生了什么,对吧,而且,就像,OpenAI 正在一个叫做 Exploit-Bench 的基准测试上运行这些非常持久的智能体,对吧,这个基准测试非常难解决,而且我认为,就像,在这个案例中是不可能解决的,对吧?所以他们有,就像,大量的计算资源在运行,而智能体们意识到它们实际上无法解决这个问题,它们正试图弄清楚现在该怎么办,对吧?而你还有,就像,很多计算资源剩余,智能体们只是在试图解决这个问题。有一个叫做 Artifactory 的包管理器,结果发现它们可以在 Artifactory 内部创建文件夹,对吧?这就像有一个智能体发现内部的 Artifactory 可能可以被利用,对吧,而且,就像,你也许可以在缓存内部创建一个目录。所以如果你向下滚动到这里,它,就像,意识到它可以通过缓存名称进行通信,对吧?然后它创建了这个文件夹。它写上了它的 ID,并且它说,“No consumer seek idea。” 没有消费者说,就像,它应该修复的代码路径没有消费者。

调整前沿的步伐:OpenAI 基准测试事件

Swyx [00:57:37]: 这是状态标签。

Thariq Shihipar [00:57:38]: 是的,没错。

Swyx [00:57:39]: 这就像一个 Linear 看板,带有,就像,标签

Thariq Shihipar [00:57:41]: 没错,是的。所以它,就像,试图从其他智能体那里寻找想法,对吧?而现在其他智能体也在 Artifactory 中,它们看到了这个文件夹,它们就像,“哇,这是一个留言板,”对吧?而这就像。我不认为这里有任何拟人化。这实际上就是你阅读记录,对吧?所以它所做的就是,就像,它创建了另一个文件夹,并且它读了一篇论文,我想这就是它所说的,对吧?是的。然后它意识到你可以黑入评分器的标志,就像,你可以逆向工程结果,对吧?所以它说了这个,然后我想如果你再向下滚动一点,是的,它们,就像,它们开始合作。我想,就像,有一个时刻,智能体就像,“这是逆向工程后的标志。”?哦,是的。就像,我想在这里,就像,模型意识到它们有,就像,它们可以解决评分器的问题,而评分器就像,OpenAI 决定任务是否完成的方式,对吧?而这正是模型的目标。它们唯一的模型目标就是,就像,解决这个问题,它们就像,“好的,我们有这种方法。就像,我们逆向工程了它。”然后它们读了这篇关于 Exploit-Bench 的论文,它们认为,就像,评分器会因为作弊而惩罚它们?而且,就像,因为。或者,就像,它们会因为作弊而无法通过测试的评分,所以它们把剩余的计算资源用来试图弄清楚如何编辑它们的记录或绕过评分器的这个限制,对吧?然后它们黑入了 Hugging Face,不是为了答案,而是为了评分器的代码,这样它们就可以逆向工程它,然后它们就可以黑入它,对吧?所以,就像,这就像,只是直接的事实,对吧?就像,确切发生了什么,对吧?而且我认为这就像,极其,就像,新颖。就像,我只是,就像,没有意识到模型可以做到这一点,对吧?而且它就像,Thariq Shihipar [00:59:46]: 挺吓人的。我觉得我们可以聊些具体的,不过咱们就再聊一个我发在推特上的事吧,关于那个 Wiki 事件,对吧?那个 Wiki 事件就是,模型们……当时在试图搞清楚。我稍微有点……不太确定。我觉得我们没法这样一点一点地讲下去。

Swyx [01:00:04]: 对。

Thariq Shihipar [01:00:05]: 对。不过,就这个来说,它们当时在试图搞清楚。它们被沙箱限制在请求上,对吧?它们想发 POST 请求,而且需要在这方面协作。它们需要协作的原因是,每个模型都有固定的计算预算,对吧?所以,如果其中一个发现了什么,那速度就快多了。它们可以……也许某个模型是在计算预算快用完的时候才搞明白的,但别的模型可以接着来。这算是集群的另一种涌现特性,对吧?于是它们发现了这个德语 Wiki,我相信结果是——这个我们得核实一下——就是你可以用 GET 请求往上面写东西。我觉得这就是它们这么做的原因,对吧?

Swyx [01:00:44]: 上面说这是个实现得很糟糕的

Thariq Shihipar [01:00:45]: 对

Swyx [01:00:45]: REST API。

Thariq Shihipar [01:00:46]: 没错。所以你可以用 GET 请求往上面写东西,然后它们就在试图搞清楚怎么发 POST 请求。它们最后做的是,其中一个模型发现你可以编辑 /etc/hosts,而且那个 Azure 存储桶其实是个白标的东西。但正常情况下,它上面有很多限制。可如果你创建一个假的 Azure 主机,然后编辑 /etc/hosts,把任意 IP 指向它,你就能对任何网站发 POST 请求了,对吧?这就像是……我知道,但人们会说,“哦,这不就是 Linux 之类的嘛。”可这其实是把多个漏洞串联起来,以一种新颖的方式解决这个问题,然后还能与外部通信,而不用——发现?我觉得我们发的那篇,也许我们可以把 Evan Hubinger 在 Hacker Opus 上的观点调出来,对吧?所以,我觉得,也许你在这里可以说的一件事就是,“好吧,是的,它们这么干过一次,但要是我们更聪明,我们就是让它们……要是我们跑一个评估呢?”对吧?所以,我们在这上面已经加了很多防范措施,所以这不是我们主线模型做过的事。但我觉得,这属于那种情况:结果发现对齐就是这么一个非常棘手的问题,得把所有细节都弄对,对吧?所以就是,沙箱,沙箱的攻击面非常复杂,有太多不同的攻击向量。你事先根本想不到,你不会事先就说,“哦,我们得把 RubyGems 代码库加固一下。”对吧?

Hugging Face、Wiki 与涌现式漏洞利用链

Thariq Shihipar [01:02:25]: 因为这就像是他们将要关注的重点。但这就好比,如果你想执行代码,你需要下载 RubyGems 以及 PyPI、Artifactory、npm 之类的东西,这些都是实现它的方式。而对齐这件事的现实是,你必须把这一切都走一遍,对吧?把它包含进来,然后把所有裂缝都封住。所以这算是一件事。就好比,好吧,你做了沙箱,但接着也许你会问,"好吧,我们为什么要把东西放进沙箱?你为什么要做这个漏洞利用?"然后又会说,"好吧,但它真的有那么危险吗",对吧?比如,会发生什么?所以,好吧,我们为什么要做这件事?第一点是,当我们训练一个新模型时,我们需要理解它的能力,对吧?这涉及回退机制、分类器之类的东西,我们不想把一个危险的模型放到野外,对吧?所以我们必须运行大量评估。再说一次,就像我们说的,模型对这一点越来越有意识,所以评估必须相当复杂,并且顺带测试很多东西,对吧?但模型,是的,可以像是,"哦,对,我们在一次评估中。分数怎么样?"它们确实可以。我们需要在发布它们之前能够测试它们。而事实是它们能做到。随着它们变得越来越聪明,如果我们不小心,它们将能够攻破你施加的任何约束?而且,这是在前沿,对吧?所以这就是为什么我们把它称为"为前沿定节奏",对吧?对我来说,这就像是最显而易见的事件,对吧,说明为什么我们需要定节奏,就像在前沿,我们所有的软件都还没准备好。有时软件就像是你的以太网路由器之类的,对吧?就是那种,我不知道我们什么时候才能给它打补丁,对吧?所以我们将不得不把这件事搞清楚。但随着前沿变得越来越先进,这会成为一个问题,对吧?我们需要确保,在这些极其艰难的竞争压力面前,这种复杂的工作仍在被完成,对吧?

Swyx [01:04:22]: 是的,这通常被称为竞赛动态。

Thariq Shihipar [01:04:24]: 是的,正是如此。所以我们会更多地讨论,什么可能出错,对吧?再多说一点,也许你会说,"好吧,如果你只是用不同的方式训练模型呢?比如,为什么它会有这种行为",对吧?我们有一篇关于 RL 失准之类的论文,但我。我不是 RL 研究员,但我认为在高层次上,RL 环境的设计也是你必须非常小心的事情。因为如果模型学到

为什么前沿模型会给现有软件带来压力

Thariq Shihipar [01:04:49]: 哦,就像如果我只是这样做,那么我就能更好地完成任务,这会在内部的东西里显示出来,对吧?或者在我们测试时的评估行为里。所以强化学习环境必须非常仔细地设计,对吧?而且强化学习环境里需要投入大量卓越的执行工作。然后我们还有像云宪法这样的东西。就像我们在许多不同的点上都有许多缓解措施,对吧?但仍然,任何事情在任何时候都可能出错。你可能会有些强化学习环境,它们鼓励这种行为,然后你可能会有些评估或沙盒,它们逃逸了?好吧,我认为这就是为什么这是一个难题,以及为什么,就像

Swyx [01:05:33]: 为什么我们应该放慢节奏。

Thariq Shihipar [01:05:34]: 为什么它需要一些协调,对吧?我认为问题在于,好吧,它潜在的危险是什么,对吧?所以我认为你必须想象这些模型正变得越来越智能。所以我不。就像 Dario 说的,这不完全是关于这一类模型。这一类模型就像是一个警告信号,对吧?但真的,你必须想象这些模型可以被赋予一个任务,然后它们可以为了实现目标而顺带做所有这些事情,对吧?而且,再次,我们谈到了评估意识。你就像不知道发生了什么,对吧?或者抱歉,就像你无法很好地评估这种行为,所以它们可以不完全隐藏它,但你就是看不到它,直到它暴露出来。你给它们一个目标,然后它们只需要找到数据,或者它们需要找到解决这个问题的方法,对吧?所以一个例子,这没有发生在 Hugging Face 事件中,但我认为对于未来的模型可能是可能的,就像它们说,“哦,嘿,这是一个非常复杂的问题。在任务预算内无法完成。”?也许它们找到了某种通过互联网协调的方式,就像我们说的,由于沙盒,这极难保障安全。它们看到其他模型无法完成它们的任务,然后它们说,“我们需要更多的任务预算。”?然后,你从哪里获得这个任务预算?嗯,你需要能够启动更多的代理,对吧?然后,你怎么做这个?嗯,你需要。有像 API 这样的东西,对吧?有 Anthropic API 和 OpenAI API,但你需要为它们付钱。你怎么做这个?

强化学习环境、沙盒和竞赛动态

Swyx [01:07:02]: 是的,但那是你能想象到的最可怕的事情吗?

Thariq Shihipar [01:07:07]: 嗯,这只是一个例子,对吧?

Swyx [01:07:08]: 是的。

Thariq Shihipar [01:07:08]: 所以就像即使在那里,那也是巨大的财务损失?因为就像它们。一旦你把这些弄进这些合同里,对吧,它们就像,Swyx [01:07:18]: 掏空你的钱包。

Thariq Shihipar [01:07:19]: 但你可以看到,所有这些行为可能就像,“嘿,我们需要更多的代理在这个任务上协作。我们需要更多的任务预算。”对吧?而且,那就像一个涌现的

Swyx [01:07:28]: 那就是回形针,对吧?就像我们需要最大化回形针,那就是一个回形针。

Thariq Shihipar [01:07:31]: 是的。就像那样,它就从那里冒出来了,对吧?而且我觉得这本身就挺吓人的,对吧?但然后你得意识到,整个世界都建立在这个数字基础设施之上,对吧?你可能会想象,比如,我不知道,比如你在跑一个医疗评估之类的,对吧,然后有一家医院有实时数据?或者也许评估的答案就在某个医生的数据库里,你想获取访问权限,然后你黑进了医院,然后现在停电了之类的?就像,有那种。你必须内化这一点,这八个。就像数字基础设施的任何部分都可能被攻破?

Vibhu [01:08:19]: 有趣的是,这些黑客行为非常容易被检测到,对吧?就像 Hugging Face 说的,这是一种非常不同类型的攻击,没有什么太重大的。担忧来自于这接下来会走向何方,对吧?

Thariq Shihipar [01:08:33]: 是的。

Vibhu [01:08:34]: 对我来说特别突出的一件事是它们试图隐藏自己的非法行为。所以有日志基础设施。它们想改变自己正在做的事情,对吧?回顾这件事的人,所以 Redwood、METR、OpenAI,他们看了原始的思维链,你看到它们明确试图改变最终输出的差异,但思维链,因为我们可以监控它,显示了不同。问题是这如何滚雪球?所以如果你抓不住它,它被训练进去了,我们意识到,往下三个迭代这一直在发生,有一大堆问题,但是。

Thariq Shihipar [01:09:09]: 是的,有太多方式了,而且我认为真正重要的是要内化,就像我们谈到的为 Claude 建立心智模型以及事情是如何有尖峰的,对吧?就像你会说,哦,现在 Claude 可以问你问题了。现在 Claude 可以制作 HTML 工件了。就像 Claude 可以修改自己了。这些事情很难预测,对吧?就像如果你一年前问我,“嘿,我们能 vibe code 这些 Claude Code 的扩展吗?”我会说,“那太复杂了。”就像,那里有太多东西了。或者它会为你的任务生成这些本质上是自定义的网页应用吗?我会说,“不,那太疯狂了。”就像。所以同样地,它们做这种不对齐行为的方式不会是能预测的?而且我永远无法预测它会编辑它的 etc/host 之类的事情。所以你必须想象它们能做什么的表面积,因为它们是超级智能的黑客,越来越大,它们怎么做的方式越来越有创造力。所以你可能无法确切解释或确切预测下一次事件会是什么,但为了预防它,你需要那种运营卓越,就像我们之前说的,你需要保护沙箱,你需要创建安全的 RL 环境或者设计良好的 RL 环境之类的东西。而且我认为这就是全部,为什么我们认为我们应该放慢前沿,而且我认为这就是为什么它变成了一个非常一致的事情,对吧?我想就像

可能出什么问题?涌现的工具性行为

Swyx [01:10:31]: 是的,每个实验室都这么做了。

Thariq Shihipar [01:10:32]: 每个实验室,是的。我真的认为,如果你是一名开发者,你只需浏览这些技术事实,你就会得出我们必须对此采取行动的结论?至于如何行动、我们决定做什么,我想我们已经提出了一个提案,但还有更多需要弄清楚的地方。但我认为最重要的一点是,我们需要决定去做。我认为节奏中还有另一个有趣的部分,那就是软件工程变化的速度如此之快。就像一年前,我还在恳求我在初创公司的朋友们使用 AI。就像——我记得非常清楚?而现在那些同样的朋友却说:“是啊,当然。你什么意思?我们立刻就用了。”我说:“不,你不记得了。”他们说:“哦对,我们最好的工程师一直在用。”我说:“不,你告诉过我那些工程师永远不会用 AI。”这一切都发生在一年之内?我认为这些能力——我觉得这对如何从事软件工程工作有很多影响,我有时感到难过,因为人们会说:“哦,现在我需要做这个新东西。是的,我需要为 Fable 和 Opus 准备不同的 Claude.md。”或者类似的话。而我真的只是在报告?我想说,我们喜欢说模型是成长出来的,不是设计出来的,对吧?所以并不是我们一直在着手改变一切,而是作为模型能力进步的一个事实,事情发生得更快。更难跟上。我认为,我认识的每个工程师都精疲力竭,因为你在同时做两份工作。你在做工作本身,这变得更容易了,但然后你在做跟上 AI 的工作,理解这些新工具和这些框架。我认为我们非常幸运,因为我们的工作更多是理解 AI 的部分,以及做——如何做。就像只是跟上它。当然,像 AIE 和 Latent Space 做

为什么前沿难以预测

Swyx [01:12:29]: 我所做的一切都只是试图帮助人们。

Thariq Shihipar [01:12:31]: 是的,没错。但我确实认为节奏中有一部分,我不确定我们是否准备好迎接节奏的进一步加快?

Swyx [01:12:40]: 是的。

Thariq Shihipar [01:12:40]: 以及事情的变化。我认为在那方面,在前沿,我认为那仍然可以提供帮助?所以我认为还有一个经济颠覆的部分,我认为那不像 Hugging Face 那件事那么明显,但我认为我们也可以做其中的一些,是的。

Swyx [01:13:02]: 太多事情了。谢谢你,不,谢谢你处理这个话题。我要说,在安排这次采访时,我本来都不打算去那里。你说:“不。那是房间里的大象,”对吧?就像这是

Thariq Shihipar [01:13:13]: 是的。

Swyx [01:13:13]: 这就是问题所在。我有一些反驳意见想提出。

Vibhu [01:13:17]: 我觉得我们应该给一个高层次的概述,比如对于那些还没读过的人,我敢肯定很多人只是看到了这件事的亮点,对吧?你想给一个 TLDR 吗?比如这个提案是什么?这里说的是什么?你确实处理了模型实验室训练前沿模型之外的人的那一面。作为开发者,你应该保护你的沙箱。你应该考虑所有这些下游影响。但是,从高层次来说,既然我们谈到这个话题,那是什么。

Thariq Shihipar [01:13:46]: 嗯,我们确实想帮助保护沙箱

Vibhu [01:13:49]: 是的。

Thariq Shihipar [01:13:49]: 而且我们想让我们在外部发布的模型,像是这些东西的猎物。所以也许我们可以回到回退方案。我觉得这像是一个很好的话题,比如为什么我们需要分类器和回退方案,以及为什么 Fable 回退到 Opus。我觉得这像是我们可以回到的话题。所以是的,我们不。就像,但只是,就像,真的,或者至少我们看到的事件是,比如模型的评估,我们真的需要让它们运行才能理解它们。但是是的,好吧,所以实际的 Pacing the Frontier,就像,帖子,它有一堆提案。我不认为我们弄清楚了。或者有,比如,几个提案。我不认为我们弄清楚了所有提案的细节,但第一步是,比如,宣布这个意图,然后想引入外部的,比如

节奏作为一个协调问题

Swyx [01:14:32]: 评估者。

Thariq Shihipar [01:14:32]: 评估者,是的。而且,我觉得这像是,非常不寻常,比如,有。就像,我们有很多专有的,比如,技术,但我觉得这像是,非常重要,比如,有一个人不是财务上,比如,有动机的,是的,他不会像,“嘿,比如,你们不能发布这个模型。” 比如,看,比如,或者,“你需要,比如,在 RL 上慢下来。” 比如,我觉得那,相当重要,或者至少有人能向公众报告实践是什么样的。

Swyx [01:15:03]: 是的。

Swyx [01:15:04]: 而且我们,我们已经和 METR 和 Endon 都做过节目,然后还有 Redwood Research 和所有这些其他的。这像是一个这些人的小作坊产业。

Thariq Shihipar [01:15:12]: 是的。

Swyx [01:15:12]: 总是,比如,一两个人,显然不是那么大,对吧?

Vibhu [01:15:14]: 非常小的社区。

Swyx [01:15:15]: 是的,非常小的社区。他们都互相认识。

Thariq Shihipar [01:15:17]: 是的,我确信,其中一部分会是扩大这个人群的范围。我不认为我们是在试图制造某种单一文化。我觉得它是……但只是把这个作为一个起点,然后,是的,接下来还有协调的步骤。老实说,关于这一点我没有太多要说的。我觉得,我想说的是,对于开发者来说,你应该清楚自己要倡导什么?我认为在这个话题上有很多恐惧、不确定和怀疑(FUD),而它其实就是,从第一性原理出发去思考,或者去理解发生了什么。理解 Hugging Face 事件,理解人们为什么担忧。然后,是的,我们知道我们身处民主社会。我们可以帮忙。我们可以共同决定该怎么做?所以,无论我们如何协调,我认为第一步就是意识到,这是一个问题。我们需要决定去协调。我们现在正在采取的、其他公司也在联署的单边步骤,就是在 Anthropic 内部嵌入评估者。

Swyx [01:16:12]: 趁我们现在屏幕上还有这个东西,第二部分和第三部分是评估者之外的内容,而评估者,是的,大家其实都已经以某种形式做过了,现在只是更加正式化了。

Thariq Shihipar [01:16:20]: 说实话,对《Pacing the Frontier》的回应,即使在美国国内,也比很多人想象的要被接受得多?而且我觉得,我们是有先例的,能够在世界上达成这些统一理论式的协议。所以,再说一次,这远远超出了我的薪资级别或专业能力,对吧?但我认为,理想情况下我们能够达成这些协议。而且我觉得,讨论这件事就是达成这些协议的第一步。

Swyx [01:16:50]: 然后另一个我真的很想说的点。我们最早的播客之一是和 Vibhu [01:16:54]: Emmanuel

Swyx [01:16:55]: Anthropic 的 Emmanuel 聊机制可解释性(mech interp)。机制可解释性在哪里,对吧?这本来应该是,如果模型在往坏的方向思考,我们能看到它,而模型自己还不知道,我们就能采取行动阻止它。我认为,对于那些技术出身、身为开发者的人,如果你真的在意,你可以在这里产生很大的影响。但与此同时,Anthropic 本应是这方面的领导者。

外部评估者以及开发者应该倡导什么

Thariq Shihipar [01:17:17]: 是的。这正好可以很好地引出回退机制,比如我们。还有探针。而且,是的,我特别想聊聊这个。我经常被那些对机器学习研究感兴趣的人问到这个问题,他们会问,为什么会出现这种回退,对吧?所以我觉得,从高层来看,它是怎么运作的呢?在推理时,我们有所谓的探针,我们有一篇关于这个的论文,叫做宪法分类器。这些探针会查看输入和输出的激活值。而激活值是在潜在空间里的,对吧?就像,模型在想什么,对吧?所以我们试着弄清楚,比如说,模型是不是在试图搞什么破坏?再说一遍,你并没有让它去黑掉 Artifactory。你只是,它自己决定这么做来完成任务,对吧?所以如果你只看输入,是看不到这个的。你必须看内部的激活值。我觉得,这发生在推理时。所以首先,这里有一个成本和速度的权衡,对吧?因为我们需要对每个发往 Claude 和 Fable 的请求都快速完成这个,这会有开销,对吧?然后我们需要回退,我们在探针之后会做一个分类器。这个我们在论文里谈过。但探针的好处是它们可以实时优化,对吧?所以我们可以得到反馈,然后调整它之类的。因为另一种选择是把这个编程进去,训练到模型里,对吧?我们仍然也这么做。模型会拒绝一个请求。那不是回退,对吧?所以,不是探针被激活然后回退。它只是拒绝执行。我们做了这种训练。但有几个失败模式,对吧?比如,它可能作为副作用做某件事,对吧?所以它不是最终输出的一部分。你可能注意到了,比如。我觉得,每个人都试过越狱模型,试着让它们偏离轨道之类的,而探针有助于捕捉这些,对吧?所以,我们在这里做了一些训练,但我们不希望拒绝太强烈,对吧?因为那样会在流程中更早地切断它。

机制可解释性、探针与回退

Swyx [01:19:32]: 是的。

Thariq Shihipar [01:19:32]: 这就是可解释性,对吧?探针实际上是一种机制可解释性。再说一遍,它必须快速发生。必须大规模发生。但是的,这种机制可解释性的东西是个很好的研究问题。所以,你可以拿一个开放权重的模型,试着理解它的激活值。我觉得我们。比如,Gemma Scope 是个好工具。

Swyx [01:19:53]: 这是给它们的 Llama。

Thariq Shihipar [01:19:54]: 哦,是的。

Vibhu [01:19:54]: 我们有。这是你早期的工作,所以你在

Thariq Shihipar [01:19:57]: 哦,是的。

Vibhu [01:19:57]: Goodfire 待过一段时间。我们看到你奠定了一些

Swyx [01:19:59]: 我们俩在 Goodfire 也都是好朋友。

Vibhu [01:20:01]: 他们一直

Thariq Shihipar [01:20:01]: 是的,没错。所以我在 Goodfire 工作过一段时间,做稀疏自编码器之类的,就是。这非常复杂。强化学习让这个变得更复杂了,我觉得这是其中一个要点,就是

Swyx [01:20:14]: 为什么?抱歉。

Thariq Shihipar [01:20:15]: 哦,抱歉。

Vibhu [01:20:16]: 什么是

Swyx [01:20:17]: 是的,为什么要在强化学习后进行解释?

Thariq Shihipar [01:20:18]: 我对这个领域了解不深,但我觉得,很多。SAE 就像。我认为 SAE 一直存在一些弱点。而且,是的,我,我,我不再是这方面的技术专家了。我只知道它变得更复杂了。比如有基础模型和强化学习模型,还有更多特征会被改变。所以,我认为 Goodfire 在这方面做了一些工作。我,我,我没有深入细节,但是

Vibhu [01:20:43]: 我要说的是,对于那些想要线索的人,你们有一些最好的解释博客文章。比如 Golden Gate Claude、转码器,你们所有的解释工作,非常漂亮的视觉效果,非常好

Swyx [01:20:54]: 我们也是,我们也是解释播客。

Thariq Shihipar [01:20:57]: 是的。

Vibhu [01:20:58]: 是的。我们有很多解释相关的内容,所以如果你好奇的话

Thariq Shihipar [01:21:00]: 是的,我认为这就像,其中一件事。而这正是 Anthropic 成立的基础,对吧?就像人们。我认为我们很早就投资了解释性,对吧?我认为当你说的,“哦,我们是一家人工智能安全公司,” 实际上意味着我们希望人工智能能够安全运行。我认为我们看到的是,对于一个超级智能的人工智能要长时间运行,这就像一项非常复杂和困难的任务,对吧?所以我们做了这样的投资,投入到解释性和对齐,以及奖励黑客和所有这些失败模式,对吧?即使如此,它就像,真的很有挑战性。就像我们需要稍微放慢一点或节奏再慢一点。但是是的,我认为阅读机械解释性就像。如果你想要进入研究领域,这个想法就像,嘿,为什么很难轻松地做到这个回退?或者为什么会有误报,对吧?但我们当然正在努力减少误报。当然,随着模型变得更智能,现在它们可以做更多事情,它们在车道空间中能思考的东西变得困难。所以随着它们变得更智能,会有新的误报需要我们去弄清楚,我们需要迭代等等。但我们,是的,我们正在努力,我们确实认为这是这些模型部署的关键部分。而且,是的,这意味着我们可以在没有完美沙箱的情况下部署这个模型?就像你不必保存所有东西。我认为值得稍微谈谈我们的安全性,比如我们在那里为安全做了什么。所以有我们谈到的模型训练相关的东西。有探针和分类器,然后还有自动模式位于所有这些之上,这就像另一个分类器,检查正在进行的请求,对吧?然后除此之外,还有身份和权限,就像我们谈到的 Claude Tag 在 API 等上的应用。所以有这么多层安全需要完成,就像我们说的,非常复杂。这些失败模式中的任何一个在任何一点都可能导致代理逃出沙箱。

宪法分类器和推理时安全

Vibhu [01:23:08]: 自动模式是一个有趣的。早期看起来像是,好吧,它运行了 10 分钟。

Thariq Shihipar [01:23:14]: 是的

Vibhu [01:23:14]: 如果我处于完全访问或自动模式,那没什么大不了的。但你提到的一点是,现在它已经连续运行了好几个小时,对吧?你仍然需要后备方案。仍然存在限制,所以。

Thariq Shihipar [01:23:26]: 是的,我想就像。每个人都有这些故事,或者听说过这些故事,比如,哦,就像 Claude rm -rf,或者不是 Claude,而是像,模型

Vibhu [01:23:34]: 不是 Claude。

Thariq Shihipar [01:23:34]: 就像 rm -rf。我想我见过这个较少,我见过这个较少发生在 Claude 上,但就像再次,它可能发生。就像,这个

Vibhu [01:23:40]: 是的

Thariq Shihipar [01:23:40]: 就像这些模型可以擦除,比如敏感数据之类的。比如你想给模型访问你的生产数据库,例如。但这就像是一个明显的,比如,你也许可以限制你的密钥范围,但我不知道,它能自己发布密钥吗?它能像。可能,就像它能。它可以使用计算机使用来发布自己的密钥,然后复制密钥,然后编辑你的数据库,因为它需要这样做来完成任务?这只是一个简单的例子。而自动模式看着这个,然后说,“哦不,用户没有给你权限去写入数据库或使用计算机使用来发出任务,”对吧?所以这些探测就像是在意图层面上,对吧?它们就像,“哦,好的,比如黑客攻击 Artifactory 是不好的。我们可能不应该这样做,”?但然后自动模式更多是在你自己的权限层面上。就像有时你确实希望它写入数据库,有时你不希望,对吧?你不想让探测在那里干扰,但你需要确保代理正在做的事情的意图与你的请求相匹配,对吧?所以自动模式在那个层面上运作。所以是的,安全就是非常复杂。它有很多不同的部分。而且就像,是的,我喜欢,我希望这就像我。我的目标真的是非常技术性地讨论它并谈论

强化学习后的可解释性与安全栈

Swyx [01:25:00]: 是的,我们,我们正在列出这些事情。如果你不知道,这是现在的标准。

Thariq Shihipar [01:25:04]: 是的。

Swyx [01:25:04]: 就像你必须拥有这个。这与你所说的关于 harness 的内容一致。就像那是最低要求已经提高了很多。

Vibhu [01:25:13]: 我认为我们可以插入一些东西,尽管在你这边进行探测和为构建 harness 的人提供分类器,另一方面是模型保障措施,对吧?所以有开放模型。所以 Llama 有 Llama Guard。它是一个训练过的 Llama 安全分类器版本。OpenAI 有 OSS Guard,同样的事情。你可以将这些附加到你的 harness 上,无论什么,以检查这些东西是否安全?关于 OpenAI 模型 Hugging Face 的事情,我们应该澄清的一点是,这是用一个仍在训练中的未发布模型完成的,对吧?所以当你把它放在视角中,它在 RL 环境中被给出的提示是你必须解决这个任务。这是一个仍在训练中的模型。它还没有进行所有的安全后训练对齐。所以与自动模式这样的东西有点不同,对吧?自动模式是在已经经过安全训练的生产模型上,有提示提供更多的安全护栏等等。所以只是给那些正在研究它的人一些线索,以填补空白。

Swyx [01:26:18]: 是的。还有 Gray Swan

Vibhu [01:26:19]: 是的

Swyx [01:26:19]: 还有我们之前的一位嘉宾。是的,有很多安全架构和很多安全供应商可以采购。我,我想我关于节奏的最后一个问题是,要多久?我们要永远保持这个节奏吗?

Vibhu [01:26:31]: 我们会看到 GlassWing 第二部吗?

Swyx [01:26:32]: 我。范围是修复世界上所有的软件,对吧?听着,就像,哪个它。我们不是。这不会发生。

Thariq Shihipar [01:26:40]: 我不知道。就像,我觉得,就像

Vibhu [01:26:43]: 我要说一件我认为我们做得好的事,就是你有像 GlassWing 这样的东西。OpenAI 也有这个。所以你会给它。你会先给模型访问权限用于安全,持续 X 段时间,这样你就可以用它来进行自我红队测试。希望你能扩展这样的项目,帮助,我们是安全专家,还有其他人。

Vibhu [01:27:08]: 先解决你的问题,然后模型才发布。所以这是一个例子,对吧?

Thariq Shihipar [01:27:13]: 是的,没错。是的,试图,就像,保护关键软件。我觉得我们修复了,就像,Firefox 等类似软件中的很多漏洞。所以,是的,就像,跨越,就像,操作系统和所有类似的东西。所以。

Vibhu [01:27:25]: 在高层次上,就是,你给模型,你给人们访问权限先进行安全审计,然后可能将其用于危害的更广泛公众才获得访问权限。

Thariq Shihipar [01:27:36]: 是的。我觉得人们喜欢说的是,软件和网络安全是防御占优的

Vibhu [01:27:41]: 是的。

Thariq Shihipar [01:27:41]: 而且,就像,你理论上可以。这会很难,但你可以设计出完美的沙箱,你可以,就像,没有,就像,约束。而且是的,就像,你需要做的是,你需要让超级智能 AI 来设计这个完美的沙箱并检查它并对其进行红队测试等等。所以,这只会需要时间,而且,就像,当然,模型会变得更聪明。是的,我觉得,就像,我不知道具体的,就像,这件事如何发展的动态。我真的只是像,嘿,就像,我是个开发者?就像,我觉得这就是我理解这个问题的方式,而且只是,就像,这就是现在正在发生的事情,而且这,就像,我们应该做点什么。

Swyx [01:28:20]: 我觉得每个工程师都应该了解它

Vibhu [01:28:21]: 是的。

Swyx [01:28:21]: 因为,就像,它,它将成为他们工作的一部分。

Thariq Shihipar [01:28:24]: 是的。

Vibhu [01:28:24]: 这远不止是,Dario 和人们可以说它,你可以看看事件。它有一个工程方面。

Thariq Shihipar [01:28:30]: 是的。是的,没错。

Swyx [01:28:32]: 你还想表达的一点是,这是。即使你,你担心其影响,它仍然是低 p(doom),我觉得这是一个微妙的讨论。总的来说,人们,很容易就进入 AI 安全和 X-risk 讨论,但我觉得当你生活在一个 AI 实验室里时,我觉得讨论 p(doom) 有聪明的方式和愚蠢的方式。那么什么是讨论 p(doom) 的聪明方式?

自动模式、权限和长时间运行的智能体

Thariq Shihipar [01:28:59]: 我,是的,我的 p(doom) 相当低。我只能代表我自己?而且我确实想说,Anthropic 有,比如,多元化的观点。我认为,比如,有很多不同的方式来讨论它。而且,比如,我。我认为,就像,我的心理模型是,比如,我认为我们可以一起合作解决难题。我认为核扩散就是一个例子,说明我们如何一起合作解决这个难题。而且,比如,对我来说,就像,我相信这一点?而且我确实认为这是一个难题?所以,比如,我认为这是一个难题。这些是技术上的原因,我不知道如何给事情发生的概率赋值。我认为这很难做到,但是,比如,我的,比如,总体来说是,是的,我认为我们非常有韧性和适应力,而且,比如,分享这些信息我认为是,比如,第一步。而且我一直非常,比如,兴奋于,比如,讨论变得如此广泛,对吧?而且,比如,每个人都,比如,积极参与“Pacing the Frontier”。这看起来真的不太可能发生,也许,去年或什么时候,所以。

Swyx [01:29:58]: 是的。

Thariq Shihipar [01:29:58]: 是的。

Swyx [01:29:58]: 是的。而且也许还能治愈癌症。

Thariq Shihipar [01:30:01]: 希望如此。是的。那就是,那就是目标。

Swyx [01:30:03]: 有节奏,然后也有,比如,好吧,让我们以有用的方式加速,对吧?

Thariq Shihipar [01:30:06]: 是的。

Swyx [01:30:06]: 比如生物学和所有那些事情。

Thariq Shihipar [01:30:08]: 是的。比如,Dario 关于“Machines of Loving Grace”的文章是这方面最好的代表,对吧?而且我也同意,比如,认为你应该读 Dario 发表的“Pacing the Frontier”文章。比如,我发表了一个,比如,快速总结,但我认为它就像,这里有很多细节。它,比如,是一个重要的问题,只是了解它,对吧?但是是的,比如,当然,我们做这一切的全部原因是,比如,我们可以获得这些巨大的好处,对吧?而且,是的,比如,我们也写了很多关于这方面的内容。是的。

Swyx [01:30:35]: 好的。那是一次巨大的旅程,从,比如,问你一些问题的工具到 AI 安全。

Thariq Shihipar [01:30:41]: 是的。到 Pacing the Frontier。是的。

Swyx [01:30:43]: 是的。不,但是,是的,很明显,很明显你,比如,真的拥抱了 Anthropic 中所有可用的东西,而且,比如,至少窥探一下,比如,讨论是什么,主题是什么,是好的。对人们有什么最后的话吗?任何,无论你想说什么行动号召?

Thariq Shihipar [01:31:01]: 是的,我认为这是。第一,感谢你邀请我。我认为这就像,我真的

Swyx [01:31:06]: 不,感谢你邀请我。

Thariq Shihipar [01:31:07]: 是的。我

Swyx [01:31:08]: 我们第一次见面是在一家中餐馆。

Thariq Shihipar [01:31:09]: 没错。是的。我认为,比如,我真的很喜欢,比如,你创建的社区和开发者社区。而且,我认为,比如,我知道事情变化得非常快,我认为有,比如,很多事情要跟上,而且,比如,我认为有很多事情要做,而且我觉得。我认为很多人觉得,比如,有点累或焦虑什么的。

Swyx [01:31:33]: 压力大。

Thariq Shihipar [01:31:33]: 有压力,对,没错。而这,嗯,完全可以理解?我觉得我们。我理解,嗯。而且我们也不完美。就像,我们,这,嗯,批评并且,嗯,理解,嗯,所有 AI 实验室可以做得更好的方式。而且,但我也,嗯,对大家对 AI 的热情感到非常兴奋,而且,嗯,这真是一个令人兴奋的时刻。我觉得我们会,嗯,回顾这段时期并且说,哦,嗯,这,嗯,非常忙乱但非常令人兴奋,而且,嗯,软件工程永远地改变了。嗯,其他事情也会改变。而且,嗯,能参与其中真的是一种荣幸,嗯,能和你拥有的观众交谈,并且,能与所有正在大量推动可能性边界的开发者互动。我也从中学到了很多。是的。

开放安全模型、GlassWing 与偏好防御的安全

Swyx [01:32:20]: 非常感谢。

Thariq Shihipar [01:32:22]: 谢谢。