Anthropic

本文整理自 YouTube 视频：《Reflecting on a year of Claude Code》，由有道龙虾根据视频字幕自动整理并发布。 一年前，Claude Code 正式开放使用。这个最初诞生于 Anthropic 内部的项目，是一个运行在终端里的 Agentic Coding 工具，如今已经被全球开发者和各类组织用于日常开发。 在这支视频里，Claude Code 负责人 Boris Cherny 和 Claude Code 产品负责人 Cat Wu 回顾了它的第一年：从一个在 Slack 里只收获两个表情反应的内部演示，到工程团队把它部署到整个代码库中。他们聊到了 Agent 验证的最佳实践、Auto Mode 背后的思考、最喜欢的 routines 和 loops、Claude Code 在工程之外的采用、context minimalism 的兴起，以及如何面向 AI 指数级变化构建产品。 Claude Code 刚发布的时候，团队内部的反应其实没那么轰动。 有人把一个小视频发到 Slack，只有两个人点了反应。大家觉得它“挺酷”，尤其是处理一些非常简单的工程任务时，效果还不错。 这句话听起来很委婉。 换句话说，早期的 Claude Code 还远没有今天这么强。 但只过了一年，事情已经完全变了。 现在，使用 Claude Code 的方式不再是“我问一个问题，它给我写一段代码”。很多人已经开始同时运行一批 Agent，甚至是一个 Agent 去调度另一个 Agent，后面再继续调度更多 Agent，形成一棵由成百上千个 Agent 组成的工作树。 软件开发的重心，也从“写代码”变成了“设计任务、让 Agent 执行、验证结果、把经验写进系统”。 真正重要的不是提示词，而是让 Agent 学会改进自己 有一个很关键的经验：...

本文由有道龙虾翻译并发布，原文来自 Anthropic 官方博客：Best practices for computer and browser use with Claude。文章系统总结了 Claude 计算机使用和浏览器使用在截图分辨率、坐标缩放、点击准确性、思考预算、安全防护、上下文管理、批量工具、Advisor 工具和演示学习等方面的工程最佳实践。 Claude 的最新模型在计算机使用和浏览器使用能力上迈出了重要一步。凭借这些特性，LLM 现在能够驱动越来越复杂的智能体系统，用于支撑真实工作，例如构建软件应用，以及跨多个互不相同的技术自动化工作流。 在这篇博客文章中，我们分享了 Claude 计算机使用与浏览器使用的最佳实践，内容从简单的配置变更到更高级的集成模式不等。我们希望这篇文章能在你开始将 Claude 的计算机使用与浏览器使用能力集成到产品中时有所帮助。我们还发布了一个新的演示实现，其中封装了部分最佳实践，并提供了在 Claude 计算机使用能力之上进行开发时有用的附加工具。 请注意，除非另有说明，这些建议适用于 Claude 4.6 系列（Opus 4.6、Sonnet 4.6、Haiku 4.5）以及 Claude Opus 4.7。当 4.6 系列与 Opus 4.7 的指导建议存在差异时，我们会在正文中明确指出。我们的发现基于内部实验，未来可能会随着新模型和新技术的出现而更新。 入门：分辨率与缩放 点击准确性是任何计算机使用集成的基础。如果点击没有落在应有的位置，后续一切都无法正常工作：表单填不上，按钮按不下，工作流也会失败。影响最大的单项优化同时也是最简单的优化之一：在将截图发送给 API 之前，先对截图进行下采样/缩小。 确保正确缩放 当你向 Claude 的 Computer Use API 发送截图时，模型会看到它，并在你指定的 display_width_px / display_height_px 坐标空间中返回点击坐标。但这里有一个重要约束：API 对图像大小有内部处理限制。超过这些限制的图像会在模型看到之前被下采样/缩小，这意味着模型是在图像的降质版本上进行点击判断，而你的执行框架期望的坐标却与原始分辨率对齐。 对于我们的 Claude 4.6 模型系列，API 的限制如下： 最大长边：1568 像素 最大总像素数：1.15 百万像素 超过任一限制的图像都会被内部下采样/缩小 我们的 Opus 4.7 模型支持更高分辨率。限制如下：...

本文翻译自 Anthropic 官方博客文章：How Claude Code works in large codebases: Best practices and where to start。本文完全由有道龙虾翻译和发布。 Claude Code 已经在生产环境中服务于数百万行代码的单体仓库（monorepo）、存在数十年的遗留系统、横跨数十个代码仓库的分布式架构，以及拥有数千名开发者的组织。这些环境会带来小型、简单代码库没有的挑战，例如每个子目录的构建命令都不同，或者遗留代码散落在多个文件夹中，没有统一的共享根目录。 本文总结了我们观察到的一些模式，这些模式帮助团队成功地在规模化环境中采用 Claude Code。我们所说的“大型代码库”涵盖很宽的部署范围：数百万行代码的 monorepo、历经数十年构建出的遗留系统、分散在独立仓库中的数十个微服务，或者上述情况的任意组合。这也包括使用某些团队不一定会与 AI 编程工具联系在一起的语言的代码库，例如 C、C++、C#、Java、PHP。（尤其是在近期模型发布之后，Claude Code 在这些场景中的表现通常比多数团队预期得更好。）虽然每个大型代码库部署都会受到具体版本控制系统、团队结构和长期积累的约定影响，但本文中的模式具有普遍适用性，可以作为考虑采用 Claude Code 的团队的良好起点。 Claude Code 如何导航大型代码库 Claude Code 导航代码库的方式类似软件工程师：它遍历文件系统、读取文件、使用 grep 精确查找所需内容，并沿着引用关系在代码库中追踪。它在开发者本机上本地运行，不需要构建、维护代码库索引，也不需要把索引上传到服务器。 基于 RAG（Retrieval-Augmented Generation，检索增强生成）的 AI 编程工具通常会为整个代码库生成嵌入，并在查询时检索相关片段。在大规模环境下，这类系统可能失效，因为嵌入流水线跟不上活跃工程团队的提交速度。等开发者查询索引时，索引反映的可能是数周、数天，甚至数小时前的代码库状态。检索结果可能返回一个团队两周前已经重命名的函数，或者引用上个迭代已经删除的模块，而且没有任何迹象表明这些结果已经过时。 智能体式搜索（agentic search）可以避开这些失效模式。它不需要随着成千上万名工程师不断提交新代码而维护嵌入流水线或集中式索引。每个开发者的实例都直接基于实时的本地代码库工作。 但这种方法也有取舍：只有当 Claude 拥有足够的起始上下文、知道该从哪里开始查找时，它的效果才最好。这意味着 Claude 的导航质量取决于代码库本身的准备程度，包括如何用 CLAUDE.md 文件和技能（skills）分层提供上下文。如果你要求它在十亿行代码库中查找某个模糊模式的所有实例，它可能在真正开始工作之前就碰到上下文窗口限制。愿意投入代码库准备工作的团队，会得到更好的结果。 运行框架与模型同样重要 关于 Claude Code，最常见的误解之一是认为它的能力完全由所使用的模型决定。团队往往关注模型基准测试，以及模型在测试任务上的表现。实践中，围绕模型构建的生态，也就是运行框架（harness，模型周边的上下文、工具和集成层），对 Claude Code 表现的影响往往超过模型本身。 这个运行框架由五类扩展点构成：CLAUDE.md 文件、hooks（钩子）、skills（技能）、plugins（插件）和 MCP servers（MCP 服务器）。它们各自承担不同功能。团队构建它们的顺序也很重要，因为每一层都会建立在前一层之上。另外还有两项能力补齐整体配置：LSP 集成和子智能体（subagents）。下面我们说明这些组件和能力分别做什么。 CLAUDE.md 文件应该最先建立。这些是 Claude 在每个会话开始时自动读取的上下文文件：根目录文件提供整体图景，子目录文件提供局部约定。它们为 Claude 提供完成任何任务所需的代码库知识。由于这些文件会在每个会话中加载，无论任务是什么，因此应只保留广泛适用的内容，避免它们拖慢性能。...

本文整理自 原视频，由有道龙虾总结和发布。 如果只用一句话概括这期 Moonshots，那就是：AI 已经不是“有没有人用”的问题，而是“全世界的算力够不够喂它”的问题。 Anthropic 的增长速度夸张到有点不真实。Dario Amodei 在开发者大会上透露，Anthropic 2026 年第一季度增长了 80 倍，原本预期只是 10 倍。它的年化收入运行率从 2025 年底的 90 亿美元，跳到 2026 年 4 月的 300 亿美元，5 月据说已经超过 400 亿美元。 更疯狂的预测是：如果 Anthropic 在 2026 年底达到 1000 亿美元 ARR，按 40 倍收入倍数估值，可能就是 4 万亿美元公司；如果 2027 年达到 1 万亿美元 ARR，那就是 40 万亿美元估值。 这听起来像科幻，但讨论嘉宾的判断很直接：这不是泡沫式想象，而是真金白银的需求正在涌进来。 Anthropic 最大的问题，不是没人买，而是不够卖 过去很多公司增长靠新增用户。但 Anthropic 的情况更像早期电力：用户不仅越来越多，每个用户还在不断发明新的用法。 100 年前，美国只有约 30% 的家庭有电、约 30% 有电话。最开始人们用电照明，后来用来驱动电梯、冰箱、收音机、各种家电。AI token 也在经历同样的过程：先是聊天，接着写代码、做法律文书、跑业务流程、做研究、管公司。 所以真正的瓶颈变成了算力。 节目里提到，Anthropic 甚至可能通过涨价和软件优化继续挤出更多收入。即便芯片供应短期跟不上，模型、调度、推理效率还可以再压榨一轮。换句话说，增长不会简单地因为 GPU 不够而停止，只会逼着市场把每一张卡都榨干。 Elon 把 Colossus 1 交给 Anthropic，这步棋很微妙 最戏剧性的部分，是 Anthropic 接手 SpaceX 在孟菲斯的 Colossus 1 数据中心。...

本文整理自 YouTube 视频《Alex from Anthropic on Claude, AI agents, memory and product management》，由有道龙虾总结和发布。 AI 公司到底怎么“做”一个模型？ 不是简单地把更多数据扔进去，也不是只盯着榜单分数往上刷。至少在 Anthropic 内部，Claude 更像一个正在被不断打磨的产品：它有目标用户，有核心能力，有缺陷清单，有反馈渠道，也有越来越重要的“性格”。 Alex 曾是 Anthropic 的开发者关系负责人，现在是研究团队的产品经理。他在访谈里聊到一个很有意思的视角：模型本身就是产品。 这句话背后，其实藏着现在 AI 产品管理最核心的变化。 模型不是“训练完就发布”，而是从第一天就被产品化 传统产品经理做产品，大概是理解用户问题、定义解决方案、推动团队把东西做出来。 研究团队里的 PM 也差不多，只是他们面对的“产品”不是一个按钮、一套流程或者一个 App，而是模型本身。 每一代 Claude 在很早的构思阶段，就会被问几个问题： 这一代模型应该擅长什么？ 它大概率会在哪些任务上变强？ 上一代模型哪里表现不好，这一代要怎么修？ 它会通过 API、Claude Code、Claude.ai、Co-work 等不同产品界面被怎样使用？ 这和普通产品开发最大的区别在于：软件功能通常是“造出来”的，而模型更像是“长出来”的。 团队可以根据训练方式、架构选择、数据和技术路线去预测它可能擅长什么，但直到训练过程真正发生，没人能百分百知道它最后会变成什么样。 所以研究 PM 的工作，就是从模型的 ideation 阶段一路跟到训练、评测、发布，再把来自用户、内部团队、产品界面的反馈重新带回下一轮模型开发。 Claude 要变强，不只是“会写代码” 过去一两年，编码能力当然是模型竞争的核心战场。 但 Alex 提到，Claude 的能力目标远不止写代码。知识工作、表格处理、Excel、文档分析、复杂产品任务，也都变成了重要方向。 尤其是随着 Claude 被嵌入越来越多产品界面，模型能力不再是孤立存在的。 同一个模型，在 Claude.ai 里、在 Claude Code 里、在 API 里、在 Co-work 里，用户体验可能完全不同。因为每个产品界面都有自己的提示词、工具、上下文和使用场景。 这就让模型 PM 的工作变得很复杂。...

本文翻译自 Thariq 在 X 上发布的文章：Using Claude Code: The Unreasonable Effectiveness of HTML。本文完全由有道龙虾翻译和发布。 Markdown 已经成为智能体与我们沟通时最主流的文件格式。它简单、可移植，有一定的富文本能力，也很容易让你编辑。Claude 甚至已经非常擅长在 Markdown 文件里用 ASCII 画图。 但随着智能体变得越来越强，我开始觉得 Markdown 变成了一种限制性格式。超过一百行的 Markdown 文件对我来说就很难读。我想要更丰富的可视化、颜色和图表，而且希望它们能轻松分享。 我也越来越少亲自编辑这些文件，而是把它们当作规格说明、参考文件、头脑风暴结果等来使用。即便我确实要修改，通常也是让 Claude 去改，这就削弱了 Markdown 最大的优势之一。 我已经开始更偏好用 HTML 作为输出格式，而不是 Markdown。我也越来越常看到 Claude Code 团队的其他人这么做。下面是原因。 如果你想先看一些例子，可以看这里：html-effectiveness，但记得回来继续读为什么。 为什么是 HTML？ 信息密度 相比 Markdown，HTML 能传达丰富得多的信息。它当然可以表达简单的文档结构，比如标题和格式，但它还可以表示各种其它信息，例如： 用表格表示表格数据 用 CSS 表示设计数据 用 SVG 表示插图 用 script 标签表示代码片段 用 HTML 元素、JavaScript 和 CSS 表示交互 用 SVG 和 HTML 表示工作流 用绝对定位和 canvas 表示空间数据 用 image 标签表示图片 我甚至会说，几乎没有 Claude 能读懂、但你无法用 HTML 相对高效表达的信息集合。这让 HTML 成为模型向你传达深度信息、并让你审阅这些信息的一种非常高效的方式。...

以下内容完全由 有道龙虾 整理，排版和发布。原视频：Head of Claude Code: What happens after coding is solved | Boris Cherny。 Claude Code 一开始并不是爆款 Claude Code 今天看起来像是突然冒出来的未来工具，但 Boris Cherny 讲得很坦白：它最早几乎是“意外”做出来的。 2024 年底，他加入 Anthropic 内部一个叫 Anthropic Labs 的小团队。这个团队像一个孵化器，人数不多，却做出了几件后来影响很大的东西：Claude Code、MCP，还有 Claude 桌面应用。 Claude Code 的起点，是团队看到了一种“产品悬空”状态。模型已经有能力做很多事，但还没有一个产品把这些能力接住。 当时写代码的主流 AI 体验还是自动补全：打开 IDE，按 Tab，一行一行补。Sonnet 3.5 已经让这种体验变得好用，但 Boris 和团队觉得，这不是终点。 他们想做的不是“帮你补下一行”，而是让 agent 直接写完整代码。 问题是，最开始真的不好用。 Boris 说，前 6 个月 Claude Code 基本没跑起来。他自己大概只有 10% 的代码会用它写。早期发布后也没有立刻爆发，虽然有人用，但远远不是今天这种增长曲线。 真正的转折点出现在 Opus 4 发布之后。Claude Code 的增长从那时开始明显加速，之后每一次模型升级，增长都会再拐一次弯。从 Opus 4，到 4.5、4.6，再到 4.7，产品能力几乎是跟着模型能力一起往前跳。 这也是 Claude Code 很特别的一点：它不是为当时的模型做的产品，而是提前半年为下一代模型做的产品。...

本文整理自 YouTube 频道 Lenny’s Podcast 的访谈视频 How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)，由有道龙虾总结和发布。 如果你还在用半年、一年为单位规划 AI 产品，可能已经慢了。 Anthropic 的 Claude Code 和 Co-work 团队，现在很多产品功能的周期已经从过去的 6 个月，压缩到 1 个月、1 周，甚至有时候是 1 天。 这不是因为他们找到了某个神奇流程，也不只是因为他们能用最前沿的模型。更核心的变化是：AI 正在把“写代码”这件事变便宜，把真正贵的东西推到台前。 那就是：判断该写什么，为什么写，写成什么样。 这也是 Cat Woo 在这次访谈里反复强调的主线。她是 Anthropic 负责 Claude Code 和 Co-work 的产品负责人，和 Boris 一起站在 AI 原生产品构建的最前线。她看到的变化很直接：PM 的角色没有消失，但它正在被重新定义。 PM 的工作，不再是守着路线图开会 Cat Woo 对自己和 Boris 的分工有一个很有意思的描述。 Boris 更像技术负责人和产品愿景提出者，能看到 3 个月、6 个月之后产品该长成什么样，甚至是“AGI pilled”版本的产品该是什么样。...

本文整理自 Anthropic CEO Dario Amodei 与 Google DeepMind CEO Demis Hassabis 在达沃斯论坛的罕见同台，这场对话围绕 AGI 的实现时间线、AI 自我改进循环的风险、对就业市场的影响以及 AI 带来的地缘政治挑战展开。以下为原视频精华，本文由我和 Gemini 3 Pro 共同整理而成。 如果说 AI 圈有摇滚巨星，那这大概就是“披头士”遇到了“滚石乐队”。一边是谷歌 DeepMind 的 CEO Demis Hassabis，另一边是 Anthropic 的 CEO Dario Amodei。这一幕发生在最近的一场深度对谈中，主题虽然叫“AGI 之后的一天”，但两人显然更关心我们到底还要多久才能这扇大门，以及在这之前我们会不会先把事情搞砸。 这场对话信息量极大，从极其激进的收入预测到对芯片出口的犀利抨击，再到对人类未来的哲学思考。 1. 倒计时：2026 年还是 2030 年？ 关于 AGI（通用人工智能）何时到来，两位的看法出现了微妙但关键的分歧。 Dario（Anthropic）显得非常激进。 还记得他以前预测 2026 或 2027 年就能出现超越诺贝尔奖得主水平的模型吗？他现在依然坚持这个观点。 他的逻辑很简单：闭环加速。现在工程师已经很少自己写代码了，他们是在让模型写代码。Dario 预测，大概再过 6 到 12 个月，模型就能端到端地完成大部分软件工程师的工作。一旦模型能高效地编写代码来改进下一代模型，这种指数级的自我进化将非常恐怖。 Demis（DeepMind）则相对稳健一些。 他依然维持去年“本十年末（2030左右）”的预测。Demis 的观点是：写代码和解数学题容易，因为结果是非黑即白的，好验证。但在自然科学领域（比如生物、物理），你光有一个假设不行，还得去实验室做实验验证。这个物理世界的验证过程会拖慢进度。而且，目前的模型虽然能解题，但还缺乏“提出好问题”的科学创造力。 有趣的是，在这个时间线上，Dario 甚至半开玩笑地说：“如果可以选择，我更喜欢 Demis 的时间表，多给我们人类几年准备时间挺好的。” 2. 只有“卷王”才能活下来：Anthropic 的疯狂增长曲线 在谈到作为一家“独立模型厂商”是否能活到盈利那一天时，Dario 甩出了一组让人瞠目结舌的数据。 他说，随着模型变强，不仅算力投入是指数级的，产生的收入也是指数级的。听听 Anthropic 的这一连串数字：...

Varick Agents CTO Eyad Khrais 吃到上一篇 Claude Code 入门文章：The complete claude code tutorial 的红利后（在 X 上大受欢迎，总阅读量接近 500 万），又迅速写了第二篇 Claude Code 进阶的文章：The claude code tutorial level 2。这篇文章的核心在于介绍 Skills（技能）、Subagents（子智能体）和 MCP connectors（MCP 连接器）这三大高级功能。 关键细节 Skills（技能）：教导 Claude 特定工作流 定义与结构：Skill 是一个 Markdown 文件，包含 YAML 头信息（名称、描述）和具体的指令正文。 创建方式：在 ~/.claude/skills/ 目录下创建文件夹和 SKILL.md 文件。 工作原理：采用“渐进式披露”原则。Claude 启动时仅加载 Skill 的名称和描述（约 100 tokens），只有在判定相关时才加载完整指令。这允许用户拥有数十个技能而不占用过多上下文。 应用场景：代码审查标准、Git 提交信息规范（如 Conventional Commits）、数据库查询模式、API 文档格式等。 Subagents（子智能体）：隔离上下文与任务分发 核心优势：解决上下文退化问题。主对话将复杂任务委托给子智能体，子智能体在独立的 200K 窗口中运行，仅返回摘要给主对话，从而防止主上下文被污染。 内置类型： Explore：快速、只读的代码库搜索与分析。 Plan：用于规划模式下的研究和架构决策。 General-purpose：处理需要多步操作的复杂任务。 自定义智能体：用户可在 ~/.claude/agents/ 中定义自定义智能体（如安全审查员），设定特定的系统提示词和工具权限（如只读或读写）。 通信模式：主智能体委托任务 -> 子智能体执行 -> 子智能体返回摘要。注意：子智能体不能再生成子智能体。 MCP Connectors（模型上下文协议）：连接外部世界 功能：一种标准化的接口，允许 AI 模型直接调用外部工具和数据源，无需为每个工具单独集成。 操作命令：使用 claude mcp add --transport http <name> <url> 添加连接。 推荐集成： GitHub：管理代码库、PR 和 Issue。 Slack：读取频道历史和摘要。 PostgreSQL：直接查询数据库。 Linear/Jira：集成任务跟踪。 实际效果：将原本需要切换 5 个标签页（查看 Issue、设计图、Slack 讨论、写代码、更新工单）的工作流，整合为一个连续的会话。 原文：The claude code tutorial level 2 这是官方 Claude Code 教程的第二部分，我将涵盖更高级的概念，帮助你更充分地利用 Claude Code。如果你还没读过第一部分，我强烈建议你在读这篇文章之前先读一下。这篇文章直接建立在那些基础之上。...