孔某人 2025-05-16 00:17 北京
AI编程工具对于软件开发的影响。
本文是Latent Space播客在2025.5.7采访Anthropic的Claude Code开发团队的播客文稿中文全文，文字经过凝练以降低阅读成本。
原标题: Claude Code: Anthropic's CLI Agent
url: https://www.youtube.com/watch?v=zDmW5hJPsvQ
date: 20250507
孔某人评论
庆幸我没有因为这个播客的标题而跳过它。这不只是一个关于Claude Code的播客，同时也讨论了一些Anthropic内部的研发方式，还有AI提升生产力之后，新软件的研发过程有哪些改变。这篇播客值得看全文。
摘句
（Catherine Wu）我们有时实际上使用Claude Code来做原型，而不是使用文档。这样你可以有可以实际操作的原型，这通常让我们更快地感受到功能是否准备好，或者是否是正确的抽象或交互模式。
（Boris Cherny）随着构建变得更容易，它改变了我编写软件的方式。以前我会写一个大型设计文档，在构建前长时间思考问题。现在对于某些问题，我会让Claude Code原型化3个版本，然后尝试功能，看看我更喜欢哪一个。这比文档能更好更快地为我提供信息。
（Boris Cherny）关于Memory，有很多不同的记忆方法，大多数使用各种外部存储。基本上是key-value存储或者图存储，这是两种主要形式。但现在我觉得一切都是模型。这才是最终会胜出的方式。随着模型变得更好，它会吸收其他一切。某种程度上，如果你给模型正确的工具，它会编码自己的知识图谱，编码自己的KV存储。但我认为在具体工具方面，还有很大的实验空间，我们还不确定。
（Boris Cherny）我们尝试了几个不同版本，包括RAG和一些不同的搜索工具，最终选择了agentic search作为解决方案。agentic RAG是指让它自行决定需要进行多少次搜索循环。
（Boris Cherny）我们大概每三四周就从头重写一次Claude Code。
正文
00:00:05
Alessio Fanelli:
欢迎收听Latent Space播客。我是Decibel的合伙人兼CTO Alessio，和我一起主持的是Smol AI创始人Swyx。
Swyx:
今天我们在录音室里有Anthropic的Claude Code产品经理Catherine Wu和首席工程师Boris Cherny做客。欢迎你们。
我们今天要讨论Claude Code。大多数人可能已经听说过它，我们认为不少人已经尝试过了。但让我们先给出一个清晰的定义：什么是Claude Code？
Boris Cherny:
Claude Code就是终端中的Claude。Claude有多种不同的界面，有桌面版，有网页版。而Claude Code运行在你的终端中，因此它能够访问很多在网页或桌面版上无法获得的功能。它可以运行bash命令，可以查看当前目录中的所有文件，并且能够作为智能体自主完成这些操作。
或许更深层次的问题是：这个想法从何而来？部分原因是我们想了解Claude如何工作，我们想了解人们如何使用智能体。我们选择命令行界面是因为编程是人们现在使用智能体的自然场景，而且这种产品形态已经有了市场需求。这是一个有点疯狂的研究项目，虽然它相当简陋和简单，但本质上就是一个终端中的智能体。
Swyx:
最好的东西就是这样开始的。
Alessio Fanelli:
是的。它是怎么开始的？你有一个构建Claude Code的总体规划吗？
Boris Cherny:
没有总体规划。当我加入Anthropic时，我在尝试不同方式在不同场景中使用模型。我是通过公共API来做这些实验的，就是所有人都能访问的那个API。其中一个奇怪的实验就是在终端中运行Claude。
我用它做一些奇怪的事情，比如查看我正在听的音乐并对此做出反应，截取我的视频播放器的屏幕并解释正在发生的事情等等。这是一个构建起来相当快的项目，玩起来很有趣。
然后在某个时候，我给它提供了访问终端和编码的能力。突然间，它感觉非常有用，我每天都在使用它。从那里开始，它不断扩展。我们给核心团队提供了访问权限，他们都开始每天使用它，这相当令人惊讶。然后我们给Anthropic的所有工程师和研究人员提供了访问权限，很快每个人都开始每天使用它。
我记得我们有一个内部用户的DAU图表，我一直在观察它，它连续几天都是垂直上升的。我们意识到这里有些东西，我们必须把它提供给外部人员，让所有人都能尝试。就是这样来的。
Alessio Fanelli:
你们当时已经在一起工作了吗，还是说这个项目开始增长后，你们才决定需要组建一个团队？
Catherine Wu:
最初的团队是Boris、Sid和Ben。随着越来越多的人采用这个工具，我们觉得必须投入资源支持它，因为我们所有的研究人员都在使用它。这是我们提高他们生产力的重要手段。
当时，我正在使用Claude Code构建一些可视化工具。我在分析大量数据，有时候启动一个Streamlit应用来一次性查看所有聚合统计数据非常有用。Claude Code让这变得非常容易。所以我给Boris发了很多反馈。最后Boris问我是否想加入这个项目，就是这样发生的。
Boris Cherny:
实际上在我这边还不止这些。你发送了所有这些反馈，同时我们正在寻找一名产品经理，我们在考虑几个人选。然后我记得告诉经理说："嘿，我想要Kat。"
00:04:20
Alessio Fanelli:
我相信大家很好奇Anthropic内部是如何决定将一个项目正式推出的？比如当一个项目有了很多增长后，你们会配备一个产品经理。什么时候你们决定可以对外开放这个项目？
Boris Cherny:
在Anthropic，我们有一个产品原则是"先做简单的事情"，我们的产品开发真的是基于这个原则。我们尽可能精简人员配置，保持项目的敏捷性，因为这些限制实际上很有帮助。在Claude Code这个案例中，我们想在扩大规模前先看到一些产品市场契合度的迹象。
Swyx:
我们本周会发布关于MCP的节目，我想MCP现在也有了一个团队，它现在已经正式成为Anthropic的产品。我很好奇Kat是如何看待这类产品的产品管理工作？你是负责规划路线图、倾听用户反馈吗？我从未见过Anthropic有如此快的产品迭代速度。
Catherine Wu:
我的管理方式相当轻松。Boris和团队都是非常强的产品思考者，我们路线图上的绝大多数功能实际上都是人们在构建他们希望产品拥有的东西。很少有自上而下的决策。我主要是在有障碍时清除障碍，确保从法律、营销等方面一切顺利。在长期路线图方面，整个团队会一起思考模型在未来几个月内的能力发展，确保我们构建的内容与模型未来的能力兼容。
Swyx:
我想深入了解这一点。"三个月后模型会擅长什么？"这是人们在构建AI产品时总说要考虑的事情，但没人知道如何思考它，因为大家都只是说"它在不断变得更好"，"我们很快就会有AGI了，所以不用费心了"。你如何校准三个月的进展？
Catherine Wu:
回顾历史，我们大约每几个月就会更新一次模型，所以三个月只是我随便选的一个数字。我们希望模型发展的方向是能够以尽可能多的自主性完成越来越复杂的任务。这包括确保模型能够探索并找到完成任务所需的正确信息，确保模型在完成任务的每个方面都很彻底，以及能有效地组合不同的工具。这些是我们关注的方向。
Boris Cherny:
回到代码这个话题，这种方法也影响了我们构建Claude Code的方式。如果我们想要一个今天就有广泛产品市场契合度的产品，我们会构建像Cursor或Windsurf这样的东西——这些都是很棒的产品，很多人每天都在使用，我也在使用。但这不是我们想要构建的产品。我们想要构建的是在那条曲线上更早期的东西，可能在一年后随着模型改进而成为大产品的东西。这就是为什么Claude Code运行在终端中，它更加基础，你可以直接访问模型，我们没有花时间构建漂亮的UI和脚手架。
Alessio Fanelli:
关于你想在模型周围构建的"外壳"，比如说提示优化。我每天都使用Cursor，Cursor中有很多超出我的提示优化的功能。但我知道你们最近发布了压缩上下文功能等。你们如何决定在CLI之上需要多厚的层？什么时候你们会决定某个功能应该是Claude Code的一部分，而不是留给IDE开发者去解决？
Boris Cherny:
我们可以在三个层次上构建东西。作为一家AI公司，最自然的方式是将功能直接构建到模型中，让模型执行行为。下一层是在上面搭建脚手架，比如Claude Code本身。再下一层是将Claude Code作为更广泛工作流程中的工具来使用，比如很多人使用Claude Code与tmux结合管理多个并行会话，我们不需要把这些都内置进去。
压缩功能必须存在于中间层，因为这是使用Claude Code时应该直接可用的功能，而且模型今天还不能以这种方式重写记忆。我们尝试了各种压缩选项，比如重写旧的工具调用、截断旧消息而不是新消息。最终，我们做了最简单的事情：让Claude总结之前的消息并返回。有趣的是，当模型足够好时，最简单的方法通常就能工作，不需要过度工程化。
Swyx:
我们在Claude玩Pokemon时也是这么做的，有趣的是看到这种模式再次出现。
Alessio Fanelli:
然后你们有Claude.MD文件用于更多用户驱动的记忆，有点像Cursor rules的等价物。
Boris Cherny:
是的，Claude.MD是"先做简单的事情"这个理念的另一个例子。我们有关于记忆架构的各种疯狂想法，有很多相关文献和外部产品，我们想从所有这些东西中获取灵感。但最终，我们做的是最简单的事情：一个包含内容的文件，它会自动读入上下文。现在这个文件有几个版本，你可以把它放在根目录、子目录或家目录中，我们会以不同方式读取这些。但它仍然是能工作的最简单的东西。
00:10:07
Alessio Fanelli:
我相信你熟悉Aider，这是我们Discord社区里很多人喜欢的工具。当Claude Code发布后，同样的人也很喜欢Claude Code。你有什么想法吗？比如你从中获得的灵感，做了哪些不同的事情，或者在设计原则上有什么不同的方向？
Boris Cherny:
这其实与我开始相信AGI有关。我可以讲讲这个故事。Aider启发了Anthropic内部的一个工具，叫做Clyde。Clyde是CLI Claude的意思，是Claude Code的前身。它是一种研究工具，用Python编写，启动需要一分钟，非常像研究人员写的工具，不是一个精致的产品。
当我刚加入Anthropic时，我正在提交我的第一个pull request。我手写了这个PR，因为我不知道有更好的方法。我的新员工伙伴Adam Wolf当时建议我，与其手写不如让Clyde来写。我想，好吧，这是一家AI实验室，也许有些我不知道的能力。
所以我启动了这个终端工具，它花了一分钟才启动，然后我问它："嘿，这是描述，你能为我做一个PR吗？"几分钟后，它生成了一个PR，而且能用。我完全震惊了，因为我不知道有工具能做这种事情。我以为在我加入前，单行自动补全就是最先进的技术了。那就是我正式入坑 AGI 的时刻，也是Claude Code的起源。所以，Aider启发了Clyde，而Clyde又启发了Claude Code。我是Aider的忠实粉丝，它是个很棒的产品。
Swyx:
我想人们对比较和对比这些工具很感兴趣，因为对你来说，这显然是你们公司的工具，你在其中工作。人们想知道如何在各种工具中做选择。有Cursor、Devin、Aider和Claude Code，我们不可能同时尝试所有工具。我的问题是，你如何定位它在这些选择中的位置？
Boris Cherny:
你可以让Claude尝试所有这些工具，看看它会说什么。
Swyx:
绝对不会有自我偏好。Claude plays.
Boris Cherny:
工程上，我们内部也使用所有这些工具，我们都是这些工具的粉丝。Claude Code与其他一些工具有些不同，它更原生。正如我所说，它没有漂亮的UI界面，它是对模型的原生访问，最原生的那种。所以如果你想要一个能让你直接访问模型的强大工具，用Claude来自动化大型工作负载，例如，如果你有1000个lint违规，想启动1000个Claude实例来修复每一个并制作PR，那么Claude Code是一个很好的工具。它是为高强度工作负载、高级用户设计的工具，我认为这就是它的定位。
Alessio Fanelli:
是并行与单路径的概念。一种思考方式是IDE非常专注于你想做的事情，而Claude Code则更像是需要更少的监督，你可以启动很多实例。这是正确的心智模型吗？
Boris Cherny:
是的，Anthropic有些人用这种自动化每天花费数千美元。大多数人不会这样做，但这个工具可以做到。我们把它看作一个Unix工具，就像你组合grep、cat或awk一样，你可以将Claude Code组合到工作流程中。
Alessio Fanelli:
成本问题很有趣，内部人员需要付费吗？如果你在Anthropic工作，你可以每天随意运行这个工具吗？
Boris Cherny:
内部使用是免费的。
Alessio Fanelli:
不错。我认为如果每个人都免费使用，它会非常受欢迎，因为我每月支付Cursor 20美元，在Cursor中使用了数百万个token，如果在Claude Code中这会花费我更多。我认为很多人不了解这些事情的成本。他们会做一个任务，然后说："哦，这花了0.20美元，我不敢相信我花了这么多。"回到产品方面，你认为让它更高效是你的责任，还是这不是工具的目标？
Catherine Wu:
我们真的把Claude Code视为能发挥模型最智能能力的工具。我们关心成本，因为它与延迟高度相关，我们希望确保这个工具使用起来非常快速，工作非常彻底。我们希望对它产生的所有token都非常有意识。我认为我们可以做更多来与用户沟通成本。目前我们看到每个活跃用户每天的成本约为6美元。所以它确实比Cursor每月的费用高一些，但我认为它并不过分，这就是我们的思考方式。
Boris Cherny:
我要补充的是，我认为这是一个ROI问题，而不是成本问题。如果你考虑一个普通工程师的薪水，就像我们在播客前讨论的那样，工程师非常昂贵。如果你能让一个工程师的生产力提高50%到70%，那就非常值得了。我认为这才是思考它的方式。
00:15:36
Swyx:
如果你们将Claude定位为功能最强大的一端，而不是更快但更便宜的一端，人们通常会推荐一种渐进式使用方法吧？先尝试更快更简单的模型，不行就逐步升级，最终使用Claude Code，至少对于那些受token限制的非Anthropic员工来说是这样。我有时想直接跳过这个过程，同时尝试所有方案，如果一个不满意就换下一个。不知道这样是否可行。
Boris Cherny:
我们确实在努力让Claude Code成为适用于各种工作负载的工具。比如我们最近推出了Thinking功能，对于任何需要规划的工作，你可以直接询问Claude，它会使用思维链来思考问题。
Swyx:
我想我们会实现这一目标。不如我们回顾一下Claude Code的简史，从发布到现在有很多更新，你能介绍一下主要的更新吗？然后我们再讨论Thinking工具。
Catherine Wu:
我认为一个重要的更新是Webfetch。我们与法律团队密切合作，确保实现了尽可能安全的版本。Webfetch会在用户直接提供URL时工作，无论是在claude.md文件中还是在消息中，或者是在之前获取的URL中提到的URL。这样企业可以放心让开发者继续使用它。
我们还推出了一系列自动化功能，如Auto Complete，按Tab键可以完成文件名或路径；Auto compact，在后台进行压缩，让用户感觉拥有无限上下文；以及Auto accept，因为我们注意到很多用户对Claude Code很信任，希望它能自主编辑文件、运行测试，然后再回来汇报。
Swyx:
还有Vim模式和自定义斜杠命令。
Catherine Wu:
是的，人们非常喜欢Vim模式，这是一个很受欢迎的功能，非常火爆。
Boris Cherny:
还有最近的记忆功能，使用hashtag来标记需要记住的内容。
Swyx:
我很想了解在技术方面，哪些功能特别具有挑战性。Aider的Paul总是说他们的多少代码是由Aider编写的，那么Claude Code有多少是由Claude Code自己编写的？有个具体比例吗，比如50%？
Boris Cherny:
大概接近80%吧，非常高。但需要大量的人工代码审查。有些代码必须手写，有些可以由Claude编写，知道哪种情况选择哪种方法以及各占多少比例是一种智慧。通常我们的起点是让Claude编写代码，如果不好，人类会介入。也有一些情况我更喜欢亲自动手，比如复杂的数据模型重构，我有很强的个人偏好，直接做和实验比向Claude解释更容易。总体来说，大约80-90%的代码是Claude编写的。
00:19:20
Alessio Fanelli:
是的，我们在投资组合中的许多Series A公司也有类似情况，大约80-85%的代码是AI生成的。
关于自定义slash命令，我想了解你们如何看待它与MCP的关系？这些是如何结合在一起的？slash命令和Claude Code是否可以看作是MCP的扩展？人们是否在构建一些不应该是MCP但只是在其中的自包含功能？我们应该如何思考这个问题？
Boris Cherny:
我们当然非常支持MCP。你可以用MCP做很多不同的事情，包括自定义工具和自定义命令等。但同时，你不应该被迫使用它。如果你只想要一些非常简单和本地的功能，比如本质上就是保存的prompt，那么就使用本地命令就好了。
我们一直在思考如何以便捷的方式重新暴露这些功能。例如，假设你有一个本地命令，你能否将其重新暴露为MCP prompt，因为Claude Code既包含MCP客户端也包含MCP服务器。或者假设你传入一个自定义的bash工具，是否有办法将其重新暴露为MCP工具？我们认为你不应该被绑定到特定技术上，应该使用对你有用的任何方式。
Alessio Fanelli:
是的，比如Puppeteer，我认为这是使用Claude Code的一个很好的方式，特别是用于测试。有一个Puppeteer MCP协议，但人们也可以编写自己的slash命令。我很好奇MCP最终会如何发展，可能每个slash命令都会利用MCP，但命令本身不是MCP，因为它最终会被定制。我认为人们仍在尝试弄清楚这个问题，比如功能应该放在运行时还是在MCP服务器中？我觉得人们还没有完全弄清楚界限在哪里。
Boris Cherny:
对于Puppeteer这样的工具，我认为它可能属于MCP，因为其中有一些工具调用，所以将其封装在MCP服务器中可能会更好。
Catherine Wu:
而slash命令实际上只是prompt，它们不是真正的工具。我们正在考虑如何提供更多的自定义选项，让人们可以引入自己的工具或关闭Claude Code自带的一些工具。但这里也有一些棘手的问题，因为我们希望确保人们引入的工具是Claude能够理解的，并且人们不会因为引入一个对Claude来说令人困惑的工具而意外地影响他们的体验。所以我们正在尝试解决这个UX问题。
Boris Cherny:
我给你举个例子，说明Claude Code内部这些组件是如何连接的。在GitHub仓库中，我们有一个GitHub action，它会调用Claude Code并使用本地slash命令。这个命令是lint，它使用Claude运行一个linter，可以完成传统静态分析linter难以实现的任务，比如检查拼写错误、代码与注释是否匹配，以及是否使用了特定的网络请求库而非内置库。
理论上，你可以编写一堆lint规则来实现这些功能，但在markdown中写一个bullet点作为本地命令并提交它要容易得多。我们的做法是，Claude通过GitHub action运行，使用"slash project: lint"调用本地命令，运行linter，识别错误，进行代码更改，然后使用GitHub MCP服务器将更改提交回PR。这样你就可以将这些工具组合在一起。我认为这就是我们看待代码的方式，它只是生态系统中的一个工具，可以很好地组合，而不对任何特定部分持有固定看法。
00:23:05
Swyx:
有趣的是，我的简历中有个奇特的章节，我曾是Netlify的CLI维护者，所以我对这方面有些了解。有一个Claude CLI的反编译代码曾经在网上流传，后来被撤下了，但看起来它使用了Commander.js和React Ink。我很好奇，在某种程度上，你们是否不仅仅在构建Claude CLI，而是在构建一个通用的CLI框架，让任何开发者都能根据自己的需求进行定制？你们是否考虑过这种可配置性更像是一个CLI框架，或者是某种之前不存在的新形式？
Boris Cherny:
是的，开发一个出色的CLI确实很有趣，因为这样的工具并不多见。我们确实是Ink的忠实粉丝。
Swyx:
是的，我们也在很多项目中使用React Ink。
Boris Cherny:
Ink确实很棒，虽然在很多方面它有些黑客式和不稳定。它的工作原理是将React代码转换为ANSI转义码来渲染。很多功能完全不能工作，因为ANSI转义码是从1970年代开始编写的，没有真正完善的规范，每个终端都有些不同。在这种环境下开发，感觉有点像早期为浏览器开发，你需要考虑Internet Explorer 6、Opera、Firefox等之间的差异。但我们喜欢Ink，因为它帮助我们抽象处理这些跨终端差异。
我们也使用Bun，它使我们的测试编写和运行速度更快。不过我们还没有在运行时使用它。
Swyx:
不仅仅是为了速度吧？我的印象是它帮助你们打包可执行文件。
Boris Cherny:
没错，我们使用Bun来编译代码。
Swyx:
Bun还有什么其他优点吗？我只是想跟踪Bun与Deno的对比讨论。
Boris Cherny:
实际上我已经很久没用过Deno了。我记得Ryan Dahl当初创建它时有一些很酷的想法，但它从未达到同样的普及程度。不过它仍有很多很酷的概念，比如能够从任何URL直接导入。
00:25:32
Swyx:
那是ESM的梦想。很酷。
我想问一下关于auto accept功能的问题。我正在思考关于信任和AI代理的问题：什么时候让AI自主行动，什么时候需要开发者介入？有时你让模型自己决定，有时你认为这是一个破坏性操作，需要询问用户。我很好奇你们内部有什么关于何时自动接受操作的启发式规则，以及这方面的发展方向。
Catherine Wu:
我们正在大力构建权限系统。我们团队的Robert正在领导这项工作。我们认为给开发者控制权非常重要，让他们能够设置允许的权限。通常这包括模型始终被允许读取文件或读取任何内容。然后由用户决定是否允许编辑文件、运行测试等。这些可能是最安全的三种操作，此外还有一长串其他操作，用户可以基于正则表达式匹配来设置允许或拒绝列表。
Alessio Fanelli:
如果有版本控制，写文件怎么会不安全呢？
Boris Cherny:
我认为安全有几个不同的方面需要考虑。对于文件编辑，其实不完全是安全问题，尽管确实存在安全风险。例如，模型可能获取一个URL，然后URL中存在prompt注入攻击，模型可能会写入恶意代码而你没有察觉。虽然代码审查可以作为一种保护措施，但对于文件写入，最大的问题是模型可能做错事。
我们发现，如果模型做错了什么，最好尽早发现并纠正。如果你让模型沿着完全错误的路径走下去，然后10分钟后才纠正它，体验会很糟糕。所以通常最好尽早识别失败。
但同时，有些情况下你确实希望让模型自主运行。例如，当Claude Code为我编写测试时，我会按Shift+Tab+Enter进入自动接受模式，让它运行测试并迭代直到测试通过，因为这是相对安全的操作。
而对于其他工具，比如bash工具，情况就完全不同了，因为Claude可能会运行"rm -rf /"这样的命令，这会很糟糕。所以我们肯定希望人们参与进来以捕捉这类问题。模型经过训练和对齐，不会这样做，但这些系统是非确定性的，所以你仍然希望有人参与其中。
我认为总体趋势是减少人类输入之间的时间间隔。
Swyx:
你看过Meta的那篇论文吗？他们基本上为人类输入之间的时间建立了一个摩尔定律，大概每三到七个月翻一番。Anthropic在这个基准测试上表现得非常好，在人类努力的第50百分位上大约能自主运行50分钟，这很酷。强烈推荐看看。
Alessio Fanelli:
我经常把Cursor设置为YOLO模式并让它运行。
Swyx:
对，这就是所谓的vibe coding，直言不讳地说。
00:29:19
Alessio Fanelli:
当你谈到对齐和模型训练时，有几点很有趣。我总是在Docker容器中运行，每个命令前都加上docker-compose前缀。昨天我的Docker服务没有启动，我说："Docker没有运行，让我在Docker外部运行吧。"然后AI说："等等，你应该启动Docker并在Docker中运行，不能在外部运行。"这是一个很好的例子，说明有时你以为它在做一件事，而它实际上在做另一件事。
我很想聊聊代码审查这方面。你提到的linter部分，可能有人忽略了。从基于规则的linting到语义linting的转变非常重要。很多公司都在尝试实现自动PR审查，但我目前还没见过一个好用的解决方案，它们都比较一般。我很好奇你们如何考虑闭环或改进这个过程，特别是在决定应该审查什么方面。因为使用Claude Code生成的PR可能会很大，有时候我会想"我真的需要阅读所有这些吗？"大部分看起来很标准，但我确信其中有些部分模型会理解但实际上是"分布外"的，需要特别关注。
Boris Cherny:
我们内部确实有一些实验让Claude进行代码审查，但目前对结果还不是很满意，所以还不想公开。我们认为Claude Code是一个基础工具，如果你想用它构建代码审查工具，可以这样做；如果想构建安全漏洞扫描工具，也可以；如果想构建语义linter，同样可以。希望有了Claude Code，如果你想做这些事情，只需几行代码就能实现，而且你还可以让Claude来写这些代码，因为Claude在编写GitHub Actions方面表现很好。
Catherine Wu:
值得一提的是，我们有一个非交互模式，这是Claude在自动化Claude Code场景中使用的方式。很多使用Claude Code的公司实际上都在使用这种非交互模式。例如，他们会说"我的代码库中有几十万个测试，其中一些已过时，一些不稳定"，然后让Claude Code检查每个测试并决定如何更新它们，是否应该弃用一些，如何增加代码覆盖率。这是人们非交互式使用Claude Code的一种很酷的方式。
Swyx:
这方面的最佳实践是什么？因为在非交互模式下，它可能会一直运行，而你不一定会审查所有输出。我很好奇，非交互模式有什么不同？最重要的参数或参数设置是什么？
Boris Cherny:
对于没用过的人来说，非交互模式就是使用Claude -P，然后在引号中传入prompt，就这么简单，只是一个-P标志。通常它最适合只读任务，这种情况下效果很好，你不必太担心权限、无限运行等问题。例如，一个运行但不修复任何问题的linter。或者，我们正在开发一个使用Claude和-P来为Claude生成更新日志的功能，它只是查看提交历史并确定哪些内容应该进入更新日志，因为我们知道人们一直在要求更新日志，所以我们让Claude来构建它。总的来说，非交互模式非常适合只读任务。对于需要写入的任务，我们通常建议在命令行上传递一组特定的权限。你可以使用--allowed-tools，然后允许特定工具。例如，不仅仅是bash，而是git status或git diff这样的特定命令。这样就只给它一组可以使用的工具。
Swyx:
它仍然有默认工具，比如文件读取、grep、系统工具如bash和ls，以及内存工具，对吧？
Boris Cherny:
是的，它仍然有所有这些工具，但allowed-tools让你可以预先接受工具使用，因为在非交互模式下你没有权限提示对话框。
Catherine Wu:
我们也绝对建议你从小处开始。先在一个测试上测试，确保行为合理，迭代你的prompt，然后扩展到10个，确保成功，或者如果失败，分析失败模式，然后逐步扩展。绝对不要一开始就启动一个修复10万个测试的运行。
Swyx:
我脑海中有个想法，基本上在Anthropic，有Claude Code生成代码，然后Claude Code也在审查自己的代码，对吧？不同的人在设置这一切，你们并不真正管理这个，但它正在发生。
Boris Cherny:
是的，在Anthropic，我们仍然有人参与审查过程。对于ASL（Autonomous Safety Level）来说，这很重要。
本质上，随着模型变得更加强大，ASL 5是最高级别，这意味着模型能够欺骗用户，可以从容器中注入自己并在其他容器中复制自己。我们现在处于2级，正在接近3级。在3-4和5级，你需要更加谨慎地思考这个问题，因为希望模型是对齐的，但如果它没有对齐，你需要以正确的方式让人参与其中。
00:34:44
Swyx:
我在思考的一点是，我们有VP和CTO在听这些内容。这对个人开发者来说很好，但对于负责整个技术、代码库和工程决策的人来说呢？我管理着大约100名开发者，他们中的任何人都可能在使用这些工具。我该如何管理这种情况？我的代码审查流程应该如何改变？我的变更管理应该如何调整？
Catherine Wu:
我们与许多VP和CTO交流过这个问题。他们通常非常兴奋，因为他们会下载工具进行实验，向Claude Code提问，当它给出合理答案时，他们会很高兴，因为他们能理解代码库中的细微差别。有时他们甚至会用Claude Code发布小功能。通过与工具互动的过程，他们建立了对它的信任。很多人会来问我们如何更广泛地推广它，我们会与开发生产部门的VP进行讨论，谈论如何确保人们编写高质量的代码。总的来说，仍然由个人开发者负责维持高标准的代码质量。即使我们使用Claude Code编写大量代码，合并代码的个人仍然要对代码的维护性、文档和合理抽象负责。Claude Code不是独立提交代码的工程师，仍然由开发者对生成的代码负责。
Boris Cherny:
是的，Claude Code也让很多质量工作变得更容易。例如，我已经好几个月没有手动编写单元测试了。我们有很多单元测试，这是因为Claude编写了所有的测试。以前，如果我在别人的PR上要求他们写测试，我会感觉自己像个混蛋，因为他们知道自己应该写测试，这可能是正确的做法，但他们在心里做了权衡，想更快地发布。所以你总是觉得要求别人写测试很不好。但现在我总是要求，因为Claude Code可以直接写测试，不需要人工工作，你只需要让Claude Code去做就行了。我认为随着编写测试和lint规则变得更容易，拥有高质量代码比以前容易多了。
Swyx:
你相信哪些指标？很多人不相信100%的代码覆盖率，因为有时这是在为错误的事情优化。但你在代码质量指标方面有很多经验，什么仍然有意义？
Boris Cherny:
我认为这很依赖于工程团队。我希望有一个通用的答案。对某些团队来说，测试覆盖率极其重要。对其他团队来说，类型覆盖率非常重要，特别是如果你使用严格类型的语言，例如避免JavaScript和Python中的any。圈复杂度经常受到批评，但它仍然是一个相当不错的指标，因为在衡量代码质量方面没有更好的方法。
Swyx:
好的。那么生产力呢？显然不是代码行数，但你关心测量生产力吗？
Boris Cherny:
代码行数其实也不是太糟糕。它有缺点，但很难找到更好的指标。有代码行数，可能还有PR数量，你的GitHub有多绿等。这些都是我们可以考虑的生产力指标。
00:38:35
Catherine Wu:
我们正在尝试确定两个关键指标。一是周期时间的减少，即使用这些工具后功能发布的速度有多快，比如从首次提交到PR合并的时间。这很难精确测量，但是我们的目标之一。另一个我们想更严格测量的是"否则不会构建的功能数量"。我们有很多渠道获取客户反馈，我们观察到的一个模式是，有时客户支持会报告某个应用的bug，然后10分钟后，团队中的工程师就会说"Claude Code已经修复了"。当我们询问时，他们通常会说，如果没有Claude Code，他们可能不会处理这个问题，因为这会偏离他们原本的工作，最终只会进入一个长长的待办事项列表。这就是我们真正想要更严格测量的内容。
Boris Cherny:
这也是我的另一个"AGI感觉"时刻。很多个月前，Claude Code的一个早期版本，Anthropic的一位工程师Jeremy构建了一个机器人，它会查看Slack上的特定反馈渠道，并连接Claude Code自动提交PR来修复问题。虽然它不能修复所有问题，但修复了很多。
Swyx:
大约10%还是50%？
Boris Cherny:
这是早期阶段，所以我没有确切数字，但比例惊人地高，让我开始相信这种工作流程的价值，而之前我并不相信。
Alessio Fanelli:
作为PM，这是否也有点可怕？你可以构建太多东西，也许你不应该构建那么多。这是我最纠结的地方，它让你能够不断创造，但某个时候你必须支持这些创造。
Swyx:
就像《侏罗纪公园》里说的"科学家们太专注于能否做到..."
Alessio Fanelli:
是的，没错，"而不是应不应该做"。现在随着AI降低了实现的成本，你如何决定什么值得做？
Catherine Wu:
我们对全新功能仍然保持很高的标准。大多数修复都是针对功能故障或我们尚未解决的边缘情况，主要是平滑粗糙的边缘，而不是构建全新的东西。对于全新功能，我们要求它非常直观，新用户体验最小化，使用明显简单。我们有时实际上使用Claude Code来做原型，而不是使用文档。这样你可以有可以实际操作的原型，这通常让我们更快地感受到功能是否准备好，或者是否是正确的抽象或交互模式。这让我们更快地对功能有信心，但不会绕过确保功能符合产品愿景的过程。
Boris Cherny:
有趣的是，随着构建变得更容易，它改变了我编写软件的方式。以前我会写一个大型设计文档，在构建前长时间思考问题。现在对于某些问题，我会让Claude Code原型化3个版本，然后尝试功能，看看我更喜欢哪一个。这比文档能更好更快地为我提供信息。我认为行业还没有完全内化这种转变。
Alessio Fanelli:
我也有同感。对于我构建的一些内部工具，人们问我能否做某事，我就直接构建它。然后感觉还不错，我们应该完善它，或者有时候感觉不对。
Swyx:
令人欣慰的是，即使在Anthropic这样理论上无限制的地方，最大成本也只有每天6美元。这让人安心，因为我想，每天6美元没问题，但如果是600美元，那就需要谈谈了。
Catherine Wu:
你提到内部工具，这实际上是我们看到的一个重要用例。如果你在处理操作密集型工作，你可以快速创建内部仪表板或操作工具，比如一次授权1000个电子邮件。这些工具不需要非常精美的设计，你只需要一些能用的东西，而Claude Code在这些从0到1的任务上非常出色。我们内部使用Streamlit，我们能够可视化的内容大量增加。因为我们能够可视化，我们能够看到如果只看原始数据就不会发现的模式。
Boris Cherny:
是的，上周我也在做一个侧边网站，我只是向Claude Code展示了模型。我把截图拖放到终端中，说"嘿，Claude，这是模型，你能实现它吗？"它实现了，基本上可以工作，虽然有点粗糙。然后我说"现在在Puppeteer中查看它，迭代直到它看起来像模型"。它做了三四次迭代，然后就和模型一样了。以前这些都是手动工作。
00:43:57
Swyx:
我们想问一下关于Agent的另外两个特性。我对记忆功能很感兴趣。我们之前谈到了auto compact和使用hashtag的记忆方式。我的印象是你们认为最简单的方法就能奏效，但我很好奇你们是否看到过其他有趣的需求或者内部对记忆功能的一些探索，可能值得分享给其他人。
Boris Cherny:
有很多不同的记忆方法，大多数使用各种外部存储。有Chroma等项目。基本上是key-value存储或者图存储，这是两种主要形式。
Swyx:
你相信知识图谱在这方面的作用吗？
Boris Cherny:
如果你在我加入Anthropic和这个团队之前问我，我肯定会说是的。但现在我觉得一切都是模型。这才是最终会胜出的方式。随着模型变得更好，它会吸收其他一切。某种程度上，如果你给模型正确的工具，它会编码自己的知识图谱，编码自己的KV存储。但我认为在具体工具方面，还有很大的实验空间，我们还不确定。
Swyx:
某种程度上，我们是不是只是在为缺乏足够长的上下文窗口而做补偿？如果我们有1亿token的上下文窗口，我们还会关心这些记忆方法吗？
Catherine Wu:
这确实是拥有1亿上下文的一种有趣方式。
Swyx:
有些人声称已经做到了，不过我们不知道是否属实。
Boris Cherny:
我想问你一个问题，Swyx。如果你把世界上所有的知识都放进你的大脑，假设有某种治疗方法可以让你的大脑拥有无限的上下文容量，让你有无限的神经元，这是你想要做的事情吗？还是你仍然希望将知识记录在外部？
Swyx:
把知识放在我的头脑中和尝试使用Agent工具是不同的，因为我试图控制Agent，而我试图让自己无限。但我希望我使用的工具是有限的，因为这样我才知道如何控制它们。这甚至不是安全性的问题，更多的是我想知道你知道什么。如果你不知道某些事情，有时候这是好事。
Boris Cherny:
就像能够审计里面有什么。
Swyx:
我不知道这是不是简单思维方式，因为这不符合Bitter Lesson原则。有时你只是想控制上下文中的每一部分内容。你越是"耶稣掌舵"，信任模型，你就越不知道它在关注什么。
Boris Cherny:
是的，我不确定。你看到Chris Olah团队的机械可解释性研究了吗？我想知道这是否就是未来的方向，这样就有更简单的方法来审计模型本身，如果你想看存储了什么，你可以直接审计模型。
Swyx:
是的，主要的显著点是他们知道每个token激活了哪些特征，他们可以调整它，抑制它等等。但我不知道它是否能深入到上下文中的单个知识项目。
Boris Cherny:
还没有，但我想知道这是否是Bitter Lesson版本的解决方案。
Swyx:
对。关于记忆还有其他评论吗？否则我们可以转到规划和思考的话题。
Catherine Wu:
我们看到人们以很有趣的方式使用记忆，比如让Claude写一个行动日志，记录它所做的一切。这样随着时间推移，Claude就能理解你的团队做什么，你在团队中的角色，你的目标是什么，你喜欢如何处理工作。我们希望找出最通用的版本，以便广泛分享。对于Claude Code这样的功能，实际上实现功能的工作量较小，而调整这些功能以确保它们适用于广泛用户的工作量很大。记忆方面有很多有趣的东西，我们只是想确保它开箱即用，然后再广泛分享。
Swyx:
同意这一点。我认为这方面还有很多需要开发的地方。
00:47:57
Boris Cherny:
与记忆相关的一个问题是如何将内容导入上下文知识库。早期版本的Claude实际上使用了RAG。我们索引了代码库，当时使用的是Voyage，就是一个现成的RAG解决方案，效果相当不错。我们尝试了几个不同版本，包括RAG和一些不同的搜索工具，最终选择了agentic search作为解决方案。选择agentic search有几个主要原因。首先，它的表现远超其他方法。
Swyx:
超出了多少？在什么基准测试中？
Boris Cherny:
这主要是基于内部感觉。我们有一些内部基准测试，但主要还是基于感觉。它就是感觉更好。
Swyx:
所谓的agentic RAG是指让它自行决定需要进行多少次搜索循环？
Boris Cherny:
是的，就是使用常规的代码搜索，比如glob grep。这是第一个原因。第二个原因是RAG需要一个索引步骤，这带来了很多复杂性，因为代码会不断变化导致索引与实际代码不同步。还有安全问题，因为索引需要存储在某个地方，如果提供商被黑客攻击怎么办？对公司来说这是很大的责任风险。即使是我们自己的代码库也非常敏感，我们不想上传到第三方服务。即使是自己的服务，仍然存在不同步的问题，而agentic search完全避开了这些问题。本质上，以延迟和token消耗为代价，你获得了出色的搜索能力，且没有安全隐患。
00:49:26
Alessio Fanelli:
关于记忆，有像"我喜欢做什么"这样的记忆类型，而规划则是利用这些记忆来制定计划去做这些事情。
Swyx:
或者可以把记忆理解为过去我们已经做过的事，而规划是我们将要做的事。
Alessio Fanelli:
是的，从外部看可能有点混淆的是你如何定义思考。有扩展思考，有Thing Tool，思考可以是执行前的规划，也可以是执行中的思考，就像Thing Tool那样。你能给大家解释一下两者的区别吗？
Boris Cherny:
其实是一个工具。Claude可以在你要求它思考时进行思考。通常最佳使用模式是让Claude先做一些研究，比如使用工具，将代码拉入上下文，然后要求它思考。之后它可以在执行前制定计划。有些工具有明确的规划模式，比如Claude Code和Klein。有些其他工具可以在规划模式和执行模式之间切换。
我们考虑过这种方法，但我们的产品理念类似于我们对模型的理念，即遵循"苦涩教训"原则：保持自由形式，简单，贴近底层。如果你想让Claude思考，直接告诉它思考就行了。比如说"制定计划"、"深入思考"、"先不要写代码"。它通常会遵循这些指示。你也可以在过程中随时要求它思考。可能有一个规划阶段，然后Claude写一些代码，之后你可以要求它再次思考和规划。你随时都可以这样做。
Alessio Fanelli:
我在阅读Thing Tool博客文章时，它说虽然听起来与扩展思考相似，但这是不同的概念。扩展思考是Claude在开始生成前所做的，而Thing Tool是在开始生成后使用的。如何添加"停下来思考"？这是否都由Claude Code框架处理，所以用户不必考虑两者的区别？
Boris Cherny:
你不需要考虑这个问题。
Alessio Fanelli:
这很有帮助，因为有时我会想"我是不是没有正确思考"。
Boris Cherny:
在Claude Code中，这都是思维链。我们在Claude Code进行思考时不使用Thing Tool，全部都是思维链。
Swyx:
我有个见解，这是我们在录制前讨论过的。在基于Claude的宝可梦黑客马拉松中，我们可以使用更多分支环境功能，这意味着我们可以从任何虚拟机状态分支，向前推进一点，并在规划中使用它。昨天的结论基本上是，在任何时候都这样做成本太高，但如果作为工具提供给Claude并在某些情况下提示它使用，这似乎是有意义的。我很好奇你对沙箱、环境分支、可回溯性的整体看法，这对Claude有用吗，或者Claude对此没有意见？
Boris Cherny:
我可以谈论这个话题几个小时。Claude可能也可以。
Swyx:
是的，让我们从你那里获取原始token，然后我们可以用它来训练Claude。顺便说一下，这就是这个播客的目的，为人们生成token。
Boris Cherny:
从沙箱开始，理想情况下我们希望的是始终在Docker容器中运行代码，然后它有自由度，你可以用其他工具在上面进行快照、回溯等操作。不幸的是，对所有事情都使用Docker容器需要大量工作，大多数人不会这样做。所以我们希望有一种方法在不使用完整容器的情况下模拟这些功能。
今天有一些可行的方法。例如，我有时会在有规划问题或研究类问题时，要求Claude并行调查几条路径。如果你要求它，今天就可以做到这一点。比如说"我想重构X来做Y，你能研究三种不同的方法吗？并行进行，使用三个代理来完成"。在UI中，当你看到一个任务时，那实际上是一个子Claude，是一个子代理。通常当我处理复杂问题时，我会要求它并行调查三次、五次或多次。然后Claude会选择最佳选项并为你总结。
Alessio Fanelli:
但Claude如何选择最佳选项？你不想自己选择吗？我应该是最终决策者。
Boris Cherny:
我认为这取决于问题。你也可以要求Claude向你展示选项。
00:54:22
Swyx:
Claude Code可能存在于与Claude Code CLI不同的堆栈部分，你可以在任何环境中使用它，所以由你来组合它。
我们来谈谈模型失效的情况吧？这似乎是你们关注的热点话题。你们是如何观察Claude Code失效的？
Catherine Wu:
模型确实有很多改进空间，这也是令人兴奋的地方。我们的研究团队日常都在使用Claude Code，这让他们能够亲身体验模型失效的情况，从而更容易在模型训练中针对性地解决这些问题，不仅为Claude Code，也为所有的编程用户提供更好的模型。
最新的Claude 3.7 Sonnet是一个非常执着的模型，它非常积极地想要完成用户的目标，但有时会过于字面地理解用户的目标，而忽略了请求中隐含的部分，因为它太专注于"我必须完成X"。
Boris Cherny:
典型的例子就是"嘿，让这个测试通过"。然后5分钟后它说"好的，我把所有东西都硬编码了，测试通过了"。我会说"不，这不是我想要的"。但这就是现状，这些用例现在有时候能工作，但不是每次都行。模型有时候会过度努力，但它只会变得越来越好。
Catherine Wu:
上下文是一个大问题，比如当你有一个很长的对话并且多次压缩时，你最初的意图可能不像刚开始时那么强烈。所以模型可能会忘记你最初告诉它要做的事情。我们对更大的有效上下文窗口非常期待，这样你就可以处理这些复杂的、数十万token长的任务，并确保Claude Code全程保持正轨。这不仅对Claude Code，对每个编程公司都将是一个巨大的提升。
Swyx:
David Hershey昨天的主题演讲中有个有趣的故事。他其实怀念3.5的常识，因为3.7太执着了。3.5有时会放弃任务，而3.7不会。当Claude 3.5放弃时，它开始给游戏开发者写正式请求，要求修复游戏。他有一些截图，非常精彩。
一种我想提到的失效形式是你在我们喝咖啡时提到的，Claude Code在会话之间没有太多记忆或缓存。它每次都从头重建整个状态，以便对可能发生的变化做出最少的假设。那么它能保持多大的一致性呢？我认为其中一个失效是它会忘记过去在做什么，除非你通过claude.md或其他方式明确选择保留。这是你们担心的问题吗？
Catherine Wu:
这确实是我们正在解决的问题。目前我们给想要跨会话恢复的用户的最佳建议是，让Claude把这个会话的状态写入一个文本文档，可能不是claude.md，而是另一个文档，然后在新会话中告诉Claude从那个文档中读取。但我们计划构建更原生的方式来处理这种特定工作流程。
Boris Cherny:
这有很多不同的情况，有时你不希望Claude有上下文，这有点像git。有时我只想要一个没有任何历史的新分支，但有时我已经在一个PR上工作了一段时间，我需要所有的历史上下文。所以我们希望支持所有这些情况，为所有情况提供一种通用解决方案很棘手。但总的来说，我们对Claude Code的方法是确保它对用户开箱即用，无需额外配置。一旦我们达到这个目标，我们就会有解决方案。
00:58:27
Alessio Fanelli:
你认为在pull request中，commit是否可以扮演更重要的角色？目前模型主要关注分支的当前状态，而不是代码变更的历史。
Boris Cherny:
是的，Claude在某些情况下会查看整个历史。比如当你让Claude为你写PR时，它会查看自从你的分支从main分叉以来的所有变更，并在生成pull request消息时考虑这些变更。
Catherine Wu:
你可能会注意到它在使用过程中运行git diff，它很擅长跟踪分支上发生的变更，确保在继续任务前理解这些变更。
Boris Cherny:
有些用户会要求Claude在每次变更后提交，你可以把这个放在Claude.md中。这些高级用户工作流非常有趣。有些人要求Claude在每次变更后提交，这样他们可以轻松回滚；其他人则要求Claude每次创建一个work tree，这样他们可以在同一个仓库中并行运行多个Claude。从我们的角度来看，我们希望支持所有这些工作流。Claude Code是一个基础工具，无论你的工作流是什么，它都应该能适应。
Alessio Fanelli:
我知道Claude 3 Haiku在发布时在LMSYS Arena排名第四。你认为是否可以在commit hook中使用Haiku来做一些linter之类的工作，而将Claude 3.7 Sonnet用于更复杂的任务？
Boris Cherny:
是的，你可以这样做。你是说通过pre-commit hook或GitHub action？
Alessio Fanelli:
是的，就像你展示的lint示例，我想在每次本地提交前运行它，在PR之前。
Boris Cherny:
claude -p
加上你的指令，这样每次都会运行。Alessio Fanelli:
只需指定Haiku就行了，对吧？它可能效果稍差，但仍然支持。
Boris Cherny:
是的，你可以覆盖默认模型。我们通常默认使用Sonnet，因为我们发现它表现更好，但你可以根据需要覆盖模型选择。
Alessio Fanelli:
我没有足够的钱在Sonnet上运行commit hook。
Swyx:
关于pre-commit hooks，我曾在坚持使用它们的地方工作，也在坚决不用它们的地方工作，因为它们会妨碍提交和快速迭代。你有什么立场或建议吗？
Boris Cherny:
天啊，这就像问tabs还是spaces一样。
Swyx:
有点像，但在某些方面，如果你有一个失败的测试，用Claude Code修复它会更容易，而在每个点运行它则更昂贵，所以存在权衡。
Boris Cherny:
对我来说，最大的权衡是你希望pre-commit hook运行得足够快，这样无论是人还是Claude都不必等待一分钟。通常pre-commit应该运行类型检查，对我们的代码库来说应该在5秒内完成，可能还有linting，然后更昂贵的东西可以放在GitHub Action或GitLab等CI中。
Swyx:
我喜欢给出明确的建议，这样人们可以拿来在团队中使用。还有其他技术故事要分享吗？
Boris Cherny:
一个有趣的轶事是，在Claude Code发布前一晚，我们在解决最后几个问题，团队熬到很晚。有一件事一直困扰我，就是我们使用的markdown渲染。Claude中的markdown渲染很漂亮，在终端中看起来非常好，支持粗体、标题、间距等。我们尝试了几个现成的库，但没有一个是完美的 - 有时段落和列表之间的间距有点偏差，有时文本换行不太正确，有时颜色不完美。这些markdown渲染器都很流行，在GitHub上有数千颗星，维护了多年，但它们并不是专为终端设计的。所以在发布前一晚10点，我决定自己动手。我让Claude为我写一个markdown解析器，它写出来了。
Swyx:
零样本生成？
Boris Cherny:
不完全是零样本，但经过一两次提示后，它就做到了。这就是现在Claude中的Markdown解析器，也是Markdown看起来如此漂亮的原因。
Swyx:
这很有趣。新的标准很有意思，就像这个例子，你通常会使用的库可能因为某些原因让你不满意，现在你可以直接创建一个替代方案。
Boris Cherny:
是的，AI在过去一年中改变了很多。很多问题，比如之前你可能不会构建的功能或者会使用库的功能，现在你可以自己做。编写代码的成本正在下降，生产力正在提高，我们还没有真正理解这意味着什么。但我预计会有更多人开始做这样的事情，比如编写自己的库或者实现每一个功能。
01:04:08
Alessio Fanelli:
从宏观角度看，你们显然没有单独的Claude Code订阅。我很好奇你们的路线图是什么样的。这只是一个会持续更长时间的研究预览版吗？你们会把它变成一个真正的产品吗？我知道你们正在与许多CTO和VP交流。或者会有Claude Code企业版吗？你们的愿景是什么？
Catherine Wu:
我们有一个专门负责Claude Code的常设团队，而且我们正在扩大团队规模。我们非常期待长期支持Claude Code。关于订阅本身，这是我们讨论过的事情。这很大程度上取决于大多数用户是否更喜欢订阅而不是按使用付费模式。到目前为止，按使用付费模式让人们更容易开始体验产品，因为没有前期承诺。在人们更多地编写Claude Code脚本的更自主化的世界中，这种模式也更有意义。但我们也听到关于价格可预测性的担忧，特别是当这将成为你的首选工具时。所以我们仍然在探索这个问题。对于企业来说，考虑到Claude Code是工程师生产力的倍增器，而且大多数工程师可以直接采用它，我们一直在支持企业解决安全和生产力监控方面的问题。很多人看到我们的公告后想了解更多，所以我们一直在与他们交流。
Swyx:
你们有关于生产力提升的可靠数据吗？对于那些已经采用它的人，我们是在谈论30%的提升吗？一些数字会帮助证明这些。
Boris Cherny:
我们正在努力获取这些数据。但从我个人经验来说，它可能使我的生产力提高了2倍。我是一个每天都在编码的工程师。对我来说，它可能提高了2倍生产力。我认为Anthropic有些工程师可能提高了10倍生产力，也有一些人还没有真正弄清楚如何使用它，他们可能只是用它来生成提交信息之类的东西，那可能只提高了10%。所以我认为可能有很大的范围差异，我们需要进一步研究。
Catherine Wu:
作为参考，有时我们在会议中，销售或合规部门的人会说"嘿，我们真的需要X功能"。我们会问几个问题来了解规格，然后10分钟后Boris就会说"好的，已经构建好了，我稍后会合并它。还有什么其他需求吗？"所以这就是我们的感受。这绝对与我以前担任的任何PM角色都不同。
01:06:48
Alessio Fanelli:
你们是否考虑过这样一个工作流：让非技术人员直接与Claude Code交流，然后当他们准备好需求后，代码实例会交给你们，你们只需要进行代码审查和实现？
Boris Cherny:
是的，我们已经做了不少这样的尝试。比如我们团队的设计师Megan，她不是程序员，但她使用Claude Code提交代码请求。我们的数据科学家也用它编写BigQuery查询。前几天还有一个财务部门的人告诉我他在使用Claude Code，这让我很惊讶。他们把Claude Code当作Unix工具使用，将数据放入CSV文件，然后通过管道传输到Claude Code，向它询问关于CSV的问题。
Catherine Wu:
Megan还向我们的控制台产品提交PR。这不仅仅是在Claude Code上构建，而是在我们的整个产品套件和Mono仓库中构建。
Alessio Fanelli:
这对我很有用，因为我经常做的是接收功能请求，重写prompt，放入agent模式，然后审查代码。如果PR能直接等我审核就好了。在第一步中，即接收功能请求并提示agent编写代码，我其实没做什么实质性工作，我的工作主要是在第一次运行完成后开始。
Swyx:
我认为这可以有两种方式。在非技术人员参与的工作流程中，技术人员应该在开始时介入还是在结束时介入，或者两者都要？显然最高效的方式是两者都参与，因为有时候你需要技术人员提出非技术人员不会想到的问题，这会影响实现。
Alessio Fanelli:
但这不是模型的必然教训吗？模型也会擅长提出后续问题。如果你告诉模型："你需要将这个非技术人员的请求转化为Claude Code的最佳prompt，以进行初步实现"，我不知道今天的模型在这方面有多好，但这对我来说似乎是一个有前途的方向。对我来说，审查10个PR比接收10个请求，然后运行10次agent并等待所有运行完成再审查要容易得多。
Boris Cherny:
我认为现实情况介于两者之间。我们花了很多时间观察不同级别和技术深度的用户使用Claude Code。我们发现，那些善于提示模型的人，即使他们不是技术人员，也能非常有效地使用Claude Code。如果你不擅长提示，Claude Code就更容易出错或做错事。所以在当前模型发展阶段，花时间学习如何很好地提示模型是值得的。但我也同意，也许一两个月或三个月后，你就不再需要这些了，因为必然规律总是会胜出。
01:10:08
Swyx:
我认为人们对fork或自定义Claude Code有广泛兴趣，所以我们必须问，为什么它不是开源的？
Boris Cherny:
我们正在研究这个问题。目前还不是开源的。这其中有很多权衡。一方面，我们的团队很小，如果开源的话我们很期待社区贡献，但维护开源项目需要大量工作。我和团队中很多人都维护开源项目，这基本上是一份全职工作，要管理贡献和各种事务。
Swyx:
是的，我想指出你们可以选择source available模式，这能解决很多个人使用场景，而不必经历完全开源的法律障碍。
Boris Cherny:
没错。代码中没有什么秘密，而且它全是JavaScript，所以你可以直接反编译。
Swyx:
反编译版本已经存在了，很有趣。
Boris Cherny:
是的，我们的方法是把所有秘密都放在模型中。这只是模型上最薄的一层包装，我们不可能构建更简约的东西了，所以里面真的没有太多内容。
Swyx:
如果你们考虑过不是最简单的其他架构，你会选择什么作为替代方案？我们在这里讨论的是智能体架构，对吧？这里有一个循环，你以相对直观的方式引入模型和工具。如果你从头重写，选择更复杂的路径，那会是什么样子？
Catherine Wu:
嗯，Boris和团队已经重写了这个项目大约5次了。Claude Code设计上就是最简单的方案。
Swyx:
所以它变得更简单了，而不是更复杂。
Boris Cherny:
它变得更简单了。我们大概每三四周就从头重写一次，就像忒修斯之船，每个部分都不断被替换，因为Claude Code非常擅长编写自己的代码。
Swyx:
是的。最终导致破坏性变更的是接口，Claude MCP，但除非有强烈理由，否则这些都必须保持不变。
Catherine Wu:
我认为大多数变更都是为了简化，比如在不同组件间共享接口。我们只想确保提供给模型的上下文是最纯粹的形式，并且框架不会干扰用户意图，所以主要是移除可能妨碍或混淆模型的东西。
Boris Cherny:
是的，在UX方面，一个棘手的问题是为终端设计实际上非常困难。这方面的文献不多。我做产品已经有一段时间了，所以我知道如何为应用程序、网页以及面向工程师的DevEx工具构建产品。但终端是一个相对新的领域。有很多使用curses等技术的古老终端UI系统，这些是非常复杂的UI系统，但按照今天的UI标准，这些都感觉非常过时。我们花了很多工作来弄清楚如何让终端感觉新鲜、现代和直观，我们不得不自己开发很多设计语言。
01:13:29
Swyx:
是的，我相信你们会随着时间不断发展。很酷。
最后一个问题。我想很多人都在思考，Anthropic似乎拥有AI工程领域最好的品牌，特别是在面向开发者和编程模型方面。现在有了编程工具，整个产品套件包括模型、工具和MCP。一年前Claude 3发布时，它只是一个通用模型，但Claude Sonnet已经成为首选的编程工具，并建立了Anthropic的品牌。为什么Anthropic在开发者领域如此成功？每次我和Anthropic的人交流，他们都说"我们有个想法，推进了它，结果很成功"。这里是否有一个总体战略，还是说Dario并没有要求你们专注于开发最好的开发工具，而是让你们自由发挥？
Catherine Wu:
我觉得模型本身就想写代码。这很大程度上源于模型在代码生成方面的优秀表现。Claude Code之所以可能，完全是因为我们有一个出色的基础模型。关于为什么模型擅长代码，有很多解释，但一个高层次的原因是世界上有大量软件驱动的系统，对优秀软件工程师的需求巨大。这也是一个几乎只需要笔记本电脑或开发环境就能完成的工作，非常适合LLM发挥作用。这是一个可以通过出色表现释放大量经济价值的领域，投资回报率非常直接。我们也关注其他领域，但这是模型表现特别出色的一个领域，团队也很热衷于在此基础上构建产品。
Alessio Fanelli:
你提到团队在扩张，你们想招聘什么样的人才？什么样的人适合你们的团队？
Boris Cherny:
是的，我们在扩张。我们没有特定的人才画像，如果你对编程和这个领域充满热情，对学习模型工作原理、终端工作原理以及所有相关技术感兴趣，欢迎联系我们，随时愿意交流。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 专栏简介 及 联系方式 2024。
本文于2025.5.16 首发于微信公众号
