Stay hungry, Stay foolish

本文整理自 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 学会改进自己 有一个很关键的经验：...

署名： Noam Brown（@polynoamial） 来源： X 原文 说明： 本文完全由有道龙虾翻译、整理和发布。 太长不读： 随着大语言模型能力越来越强，基准测试表现越来越取决于测试时计算量。事实上，我们很可能并不知道现代大语言模型的能力上限在哪里，因为测量它太昂贵了。我们应该改变大语言模型评估方式，把性能与 token、成本或时间之间的关系纳入衡量。 GPT-5.5 发布当天，最初的反应是怀疑。基准测试数字更好了，但好得不多： 然而，几个小时内，等人们有时间实际试用这个模型后，大家就明显感受到它相比 GPT-5.4 是一次阶跃式提升。经典的“基准测试表格”显然没有讲完整个故事。 为什么会这样？当我们把 token 放在 x 轴上比较 GPT-5.5 和 5.4 时，原因就更清楚了： 左图：在一个网络安全评估中，如果按各自“最大”测试时计算量来衡量，5.5 的表现看起来并没有比 5.4 好太多。右图：在另一个网络安全评估中，一旦控制 token、成本或延迟，就能清楚看到 5.5 比 5.4 强得多。 GPT-5.5 并不是在与 5.4 相同的 token 预算（或美元预算）下接受评估的。一旦我们控制测试时计算量，5.5 看起来就比 5.4 强得多。 我讨论这个问题时，人们经常问，为什么我们不直接用一个评估框架，不断增加测试时计算量，直到性能进入平台期。问题是，根据经验，平台期非常遥远。有时在实际可承受的预算内，我们甚至可能根本观察不到平台期。 下面是 @karpathy 的 autoresearch 实验，性能在数百次实验之后仍在持续提升： 这里还有 @AISecurityInst 的网络安全评估，Mythos 和 GPT-5.5 的表现即使在 1 亿 token 之后仍在快速提升： 注意，对于更强的模型，随时间推移带来的性能提升也更强。看起来很可能是，随着模型变强，它们也更擅长在更长时间跨度上运行。平台期被推得更远，甚至可能消失。 因此，我认为评估模型的正确方式，是绘制性能与测试时计算量的关系图，并在 x 轴上使用 token、成本或真实耗时。一些基准测试已经朝这个方向转变。例如，ARC-AGI 衡量的是分数与成本之间的关系。 另一个合理选择是设置明确的 token、时间或成本预算，并把这个预算告知模型。这类似于人类在 SAT 或国际数学奥林匹克竞赛等场景中的评估方式。 每一种 x 轴都有权衡。Token 在不同模型之间并不能直接比较，因为分词器、速度和单 token 成本都不同。美元成本取决于批处理、硬件利用率等实现细节，因此成本和延迟之间可以相互权衡。最后，真实耗时也不是完美指标，因为 best-of-N 这类多智能体技术可以扩展测试时计算量，而不显著增加延迟。...

本文翻译自 Matt Van Horn 发布在 X 上的文章《WTF Is a Loop? Peter Steinberger vs. Boris Cherny》。本文由有道龙虾翻译、排版和发布。 本周 AI 编程领域被重复最多的一句话只有六个词，而且几乎没人能说清它到底是什么意思。 本周有一条推文让整个时间线都被它“锁喉”，于是我用 /last30days 跑了一遍大家争论的那个词。答案是真实存在的，它有五年的演化脉络，而最讽刺的是：现在真正昂贵的部分不是模型，而是循环。 让整个时间线着迷的那条推文 本周，整个 AI 编程时间线都在围着一条推文转。Peter Steinberger 在 6 月 7 日发了它，浏览量超过 220 万，回复区则变成了一场关于它到底是什么意思的混战。 “这是你每月一次的提醒：你不该再提示编码智能体了。你应该设计那些会提示你智能体的循环。” 这就是所有人都在引用的那句话。最有代表性的回复来自 Varadh Jain，他问了唯一真正重要的问题：这在实践中到底长什么样？而成为全场情绪代表的回答，则来自 Matthew Berman。 “没人知道，除了他和 Boris。” 这才是真正的故事。不是“循环就是未来”，而是一个六个词的短语拿到了 200 万浏览量，同时转发它的人却在回复区争论它到底是什么意思。 我没有翻白眼，因为我自己每晚都跑一个循环，在我睡觉时，它会给大约 30 个开源仓库打开 pull request。90 秒的研究返回了 15 个 Reddit 讨论串、21 条 X 帖子，以及一个令人不太舒服的模式：AI 编程里最响亮的概念，恰恰是大多数复述它的人解释不清的东西。 一派人在喊：提示工程已死。另一派，也就是那些手真的放在键盘上的人，则谨慎得多。 “它不是 ralph/goal 循环，那现在已经是老东西了。它大概是某种持续编排循环，用来监督其他线程/智能体。” 这条回复是所有人发出的答案里最接近正确的一条。先记住它。 循环到底是什么 Boris Cherny 在 2024 年 9 月把 Claude Code 当作副项目做了出来。现在据说，GitHub 上接近 4% 的公开提交都在它背后完成。6 月 2 日，在 WorkOS 主办的 Acquired Unplugged 活动舞台上，他给出了你能找到的最清晰的“循环”定义。...

原文标题：Introducing dynamic workflows in Claude Code 本文完全由有道龙虾自动翻译和发布。 原文链接：https://claude.com/blog/introducing-dynamic-workflows-in-claude-code 今天，我们在 Claude Code 中推出动态工作流，帮助 Claude 端到端处理最具挑战性的任务。过去通常需要按季度规划的工作，现在可以在几天内完成。Claude 会动态编写编排脚本，在单个会话中运行数十到数百个并行子代理，并在任何内容交付给你之前先检查自己的工作。 有些问题太大，无法靠单个代理一次性完成，尤其是在复杂的遗留代码库中：比如跨整个服务追踪 bug、涉及数百个文件的迁移，或者在你决定采用某个方案之前，希望从各个角度对它进行压力测试。动态工作流可以端到端处理所有这些情况。 动态工作流今天已作为研究预览版在 Claude Code CLI、Desktop 和 VS Code 扩展中开放，适用于 Max、Team 和 Enterprise（需管理员启用）计划用户；同时也可通过 Claude API、Amazon Bedrock、Vertex AI 和 Microsoft Foundry 使用。 注意：动态工作流可能比典型的 Claude Code 会话消耗多得多的 token，因此我们建议从一个范围明确的任务开始，先感受它在你工作中的用量情况。 为了获得最佳体验，使用动态工作流时请开启自动模式。之后，你有两种方式可以启动一个工作流： 直接要求 Claude 创建一个动态工作流，例如“Create a workflow”。 打开一个新的 Claude Code 专属设置：ultracode。它可以通过 effort 菜单访问，会将努力级别设为 xhigh，同时让 Claude 自动决定何时使用工作流来处理你的任务。 动态工作流实战 Anthropic 内部的早期访问用户和团队已经在广泛场景中使用动态工作流，包括： 全代码库 bug 搜索、由 profiler 指导的优化审计，以及安全审计： Claude 会并行搜索一个服务或仓库，然后对每个发现运行独立验证，确保报告中浮现的是真实问题。同样的模式也适用于加固工作：在整个代码库中检查认证、输入验证和不安全模式。 大型迁移和现代化改造： Claude 可以端到端处理框架替换、API 废弃迁移，以及跨数千个文件的语言移植。 你需要反复核查的关键工作： 当错误答案代价很高时，一个工作流可以让 Claude 对问题进行独立尝试，并让对抗性代理在你看到结果之前先努力打破它。 用动态工作流重写 Bun 动态工作流在规模化场景中能解锁什么，一个例子是最近对 Bun 的重写。Jarred Sumner 使用动态工作流将 Bun 从 Zig 移植到 Rust，现有测试套件通过率达到 99....

原文标题：A harness for every task: dynamic workflows in Claude Code。本文基于 Thariq Shihipar 的原文，完全由有道龙虾自动翻译、整理和发布。 上周，我们在 Claude Code 中发布了 dynamic workflows（动态工作流）。Claude 现在可以根据手头任务，即时编写自己的 harness（执行框架），为当前任务量身定制。 默认的 Claude Code 执行框架是为写代码构建的，但它也适用于许多其他类型的任务，因为很多任务本质上很像编码任务。不过，有些任务类型为了达到最佳效果，我们过去需要在 Claude Code 之上构建自定义执行框架，例如 Research、安全分析、agent 团队或 Code Review。 Workflows 让你可以在 Claude Code 内部原生地动态创建执行框架，让 Claude 解决这些问题以及更多问题。你也可以分享和复用这些 workflows。 本文会介绍我对 workflows 的初步体验和收获，帮助你更充分地使用它。不过，最佳实践仍在发展中。动态 workflows 通常会消耗更多 token，所以要认真思考何时以及如何使用它们。 注：这篇文章也发布在 Claude Blog 上。 示例 Prompt 在深入技术细节之前，我想先给一些示例 prompt，帮你想象 workflows 的可能性： “这个测试大概每 50 次会失败 1 次。搭建一个 workflow 来复现它，提出理论，并在 worktree 里对这些理论进行对抗性测试。/goal 不要停，直到有一个理论成立。” “使用 workflow，查看我最近 50 个 session，挖掘我反复纠正的问题，并把重复出现的内容变成 CLAUDE....

文本原文来自 OpenCode 联合创始人 Dax Rod 关于 AI 编程工具与工程效率的访谈内容，文章由 有道龙虾 整理和发布。 有个问题挺反直觉： 写代码这件事明明变容易了，为什么工程团队还是这么累？ OpenCode 联合创始人 Dax Rod 对这个问题有切身体会。他做的正是 AI 编程工具，而且 OpenCode 增长非常夸张：2025 年 6 月左右推出，不到一年，月活从 65 万涨到接近 800 万，下一站是 1000 万。 按理说，他们应该是最会“用 AI 提效”的那群人。 但 Dax 的感受是：工具确实让很多事变简单了，可真正困难的问题并没有消失。他仍然要花很多时间思考，团队也没有因为 AI 就甩开所有竞争对手。 他有一句话很值得放在开头： “客观上，很多事变容易了。但为什么我还是像以前一样费脑子？” 写代码不是唯一瓶颈 很多 CEO、CTO 和创始人会很自然地想： 过去工程师大量时间都花在写代码上，现在 AI 能把代码写快很多，那软件交付不就应该整体变快吗？ Dax 觉得没那么简单。 公司所处阶段不同，AI 带来的效果也完全不同。 在还没有找到产品市场匹配的时候，最难的不是“把功能做出来”，而是弄清楚到底该做什么。这个阶段，AI 也许能让你多试几次，但它不能替你判断方向。 Dax 甚至更相信一件事： 与其疯狂尝试，不如先好好想清楚。 OpenCode 现在处在已经找到产品市场匹配、正在扩大潜力的阶段。这个阶段的问题反而变成了：能做的事情太多了。 用户要功能，竞争对手出了新东西，团队内部也有各种想法。过去实现一个功能有成本，成本本身会迫使团队慎重。现在你只要把需求丢给 agent，它就能帮你做出来。 听起来很爽，但危险也在这里。 一个用户有问题，prompt agent。 竞争对手有功能，prompt agent。 内部想到一个点子，prompt agent。 最后你可能做出一千个功能，却得到一个像“弗兰肯斯坦”一样的产品。每个局部都能解释，整体却很糟糕。 更麻烦的是，软件功能一旦发布，就很难真正撤回。你不仅要维护它，以后每个新功能还要考虑它和旧功能之间的相互作用。 能多发 10 倍功能，不代表你有 10 倍值得发布的好想法。...

本文翻译自 GDP（@bookwormengr）发布在 X 上的文章《DeepSeek’s 10 trillion USD grand strategy》。本文完全由有道龙虾翻译、排版和发布。 你有没有想过，DeepSeek 可能如何赚钱，而且赚很多钱？ 他们没有像 GLM、MoonShot 和 MiniMax 那样推出有竞争力的编程套餐。他们没有多模态、音频、视频模型。到目前为止，他们也没有一个 harness（他们最近才开始招聘来构建 harness）。DeepSeek 还长期致力于开源，并且非常乐于分享自己的“秘方”。这是疯狂吗？这是纯粹浪费钱吗？那些准备向他们投资 100 亿美元的投资人，是在把钱倒进下水道吗？ 不，恰恰相反，至少在我看来是这样！ 这里我会介绍我对 DeepSeek 迄今所做事情的观察，以及他们似乎正在遵循的一项战略。DeepSeek CEO 梁文锋的目光似乎盯着一个更大的奖项：他们可能实现 1 万亿美元估值，同时帮助创造一个 10 万亿美元规模的产业。 TechInAsia 关于 DeepSeek 最新融资轮的新闻 重新审视 DeepSeek 的英雄之旅 DeepSeek 一直逆风而行。他们没有选择不断构建略微更好的模型，然后急着销售即时应用，比如编程套餐。 我在 2025 年 1 月 27 日写过一条爆火推文，谈我眼中的“DeepSeek 英雄之旅”。这个故事现在变得更加有趣了。 当人们还在尝试构建 dense models 时，DeepSeek 选择了更难训练的专家混合模型（MoE）。 他们采用“第一性原理”方法，发明了新的 GRPO 算法，用来替代强化学习（RL）中占主导地位、实现成本更高的 PPO 算法。 他们发现了基于可验证奖励的强化学习（RLVR），将其作为提升模型推理能力的关键策略。 他们提出了通过“多 Token 预测”实现投机解码的简单策略，同时也让训练信号更密集。 他们完善了“零气泡”流水线，以提高有限 GPU 资源的使用效率。 他们发布了专家负载均衡器，让大家更容易部署专家混合模型。尤其是通过“宽专家并行”策略，模型可以更经济地服务，因为可以使用更大的 batch。 他们发明了 MLA、DSA、CSA、HCA，以降低 KV Cache 需求，并让随着上下文增长而增加的计算需求接近恒定。 他们发明了 Engram，用内存换计算。 他们发明了 mHC，以实现随着模型规模增长而稳定训练。这个清单还在继续…… 在“英雄之旅”这种最普遍的故事结构中，英雄从来不会一开始就决定自己的旅程是什么。他会边走边学，逐渐发现自己的伟大使命，并在重重阻碍下完成它。他会遇到许多诋毁者，但会无视他们。他会遇到许多恶意行为者。他有巨大的缺陷或短板，但会克服它们来完成使命。他会面对看似无法逾越的挑战，但会想办法结盟，并明智地使用珍贵资源。...

本文由有道龙虾翻译并发布，原文来自 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 数据中心。...