7月9日2026 · 星期四

@dotey

两条关于 GPT-5.6 和 GPT-6 的爆料。 先说最劲爆的一条：OpenAI 准备跳过 5.x 系列，直接推 GPT-6。 GPT-5.6 将是 5.x 系列的最后一个模型，GPT-6 大约一个月后发布，甚至可能 7 月底就到。GPT-5.6 刚在 6 月 26 日开始受限预览，明天（美国时间 7 月 9 日）才正式向公众开放，结果下一代已经在路上了。 按照爆料者的说法，GPT-6 将基于一个全新的、规模大得多的预训练底座。此前 GPT-5.5 和 GPT-5.6 共用代号“Spud”的预训练基座（约 4T token），OpenAI 原本打算沿用 Spud 继续做到 GPT-6，但临时改了主意。 改主意的原因：Anthropic 的 Mythos。 GPT-6 是 OpenAI 对 Mythos 的真正回应，Mythos 改变了一切，所有人都在往大了做。 Anthropic 6 月 9 日发布了 Fable 5 和 Mythos 5，其中 Mythos 5 的网络安全能力让美国政府紧张到直接下了出口管制令，要求 Anthropic 三天后就全面停止对外访问。虽然禁令已在 6 月 30 日解除，Fable 5 从 7 月 1 日起恢复使用，但这场风波本身就说明 Mythos 的能力级别确实跨越了新的门槛。 爆料中还提到，Fable 5.1 已进入 Anthropic 内部流程的后期阶段，预计几周内发布。这个时间窗口刚好和 GPT-6 的传闻发布期重叠，OpenAI 显然也意识到了这一点。 另一个值得注意的信号来自马斯克。Andrew Curran 提到 xAI 有一个 10T 参数的 Grok 正在训练中。这个说法和 5 月份马斯克本人透露的信息吻合，当时他确认 Grok V9（1.5T 参数）已完成训练，同时有 6T 和 10T 的版本在 Colossus 2 集群上并行训练。Grok 4.5 已于 6 月 28 日在 SpaceX 和 Tesla 内部开始测试。 中国这边也没闲着。DeepSeek V4 正式版计划 7 月中旬上线（4 月 24 日发布的是预览版），将引入高峰时段双倍定价机制。爆料者称 DeepSeek V4 正式版的能力可能追平甚至超过智谱 6 月 13 日发布的 GLM-5.2。 与此同时，DeepSeek 已经开始研发一个更大的新模型，目标是和 MiniMax 即将推出的 M3 Pro 竞争。据 The Information 报道，M3 Pro 总参数量 2.7T，计划在 Q3 开源，将是中国最大的开源模型。 把这些消息拼在一起看，2026 年下半年的 AI 竞赛格局已经清晰：美国几家头部实验室被 Anthropic 的 Mythos 级能力刺激，全面转向更大规模的预训练；中国实验室则在开源路线上加速追赶，GLM-5.2 和 DeepSeek V4 都在特定任务上逼近闭源前沿。 看起来 Scale Law 还没到头。

@OpenAI

We audited SWE-Bench Pro, one of the most widely used AI coding benchmarks, and found it no longer reliably measures frontier coding capability. We find 30% of SWE-Bench Pro tasks to be broken, and are retracting our previous recommendation that the research community use it as a leading coding eval. https://openai.com/index/separating-signal-from-noise-coding-evaluations/ --- From twitter --- To audit SWE-Bench Pro, we used model-based investigator agents alongside independent reviews from five independent experienced software engineers. That helped us examine tasks at scale while keeping expert judgment at the center.

Separating signal from noise in coding evaluationsopenai.com · 直连原文

@OpenAI

These new models are rolling out to everyone over the next few days, starting today. They’ll be available in ChatGPT across iOS, Android, and web. Coming soon to the API. Just tap the Voice button to talk with ChatGPT, and you’ll feel the magic of GPT-Live. --- From twitter --- GPT-Live is now fully rolled out to all ChatGPT users on Go, Plus, and Pro plans. Free user rollout is in progress. Update to the latest version of the ChatGPT app on iOS or Android to try it out. > 引用 @OpenAI: Introducing GPT-Live, a new generation of voice models for natural human-AI interaction. > > Rolling out in ChatGPT starting today. > > You’ll want to turn the sound on for this one. --- From twitter --- GPT-Live makes talking with AI feel like having a real conversation. It’s also our smartest voice model yet. https://openai.com/index/introducing-gpt-live/ --- From twitter --- The next generation of ChatGPT Voice is here. Livestream starts at 10am PT. https://openai.com/live/ --- From twitter --- Listen up. Livestream at 10am. > 引用 @OpenAI: We know you’re eager for voice updates in ChatGPT. Stay tuned, we’re cooking.

@dotey

Mitchell 的评测，这个比喻很有画面感： “GPT 5.6 Sol 就像一个魅力十足、高效能干、才华横溢的同事，让你有点嫉妒。Fable 则是个天才隐士，它在自己的痴迷领域里无比出色，但不爱出门、不谈恋爱，你也不太想和它多相处！” 另外这点总结很重要： Fable 在高度针对性的调试/安全/性能目标上最强，其他方面 Sol 更好或者差不多。

@dotey

视频中举的宝可梦的那个例子，说大语言模型找不出哪些宝可梦的名字以 aw 结尾，然后有网友就像挑战一下通过提示词让大模型推导出来。 但这个例子的重点不是说如何改进提示词，而是要让模型学会调用工具。 就好比你问模型现在几点了，无论你怎么优化提示词，模型也不可能答出来，但是你给它工具可以获取当前时间，它就能正确回复。

@dotey

Claude Code 诞生记 BEN MANN Anthropic 联合创始人兼 Labs 团队负责人 当我们创立 Anthropic 并最终决定开发一款产品时（在当时，做产品这个决定本身就备受争议），我们做的第一件东西是一个编程助手。 那是一个 VS Code 的扩展插件。你可以和它聊天，对于你输入的每一个提示词，它都会给出四种不同的操作建议。 SHAUNA KRAVEC Anthropic 强化学习(RL)负责人 早在 2022 年初，我们就已经在构思编程助手了，并尝试构建能够进行自主软件工程开发的模型。我们搭建了最初的强化学习代码库，并摸索出了训练 AI 智能体(AI Agent)的全套方法。 我们之所以对写代码这么感兴趣，是因为我们坚信：==通往变革性 AI 的必经之路，就在于能够将大量的软件工程工作自动化。== DAWN DRAIN Anthropic 研究工程师 从 2021 年开始，我在 Anthropic 前三年的主要工作，就是试图打造一个写代码能力尽可能强的模型——==至少得和我一样厉害。== SHAUNA KRAVEC 借助我们的强化学习训练，我们从简单的任务开始测试。模型能写一个简单的函数吗？接着挑战升级：我们能不能让模型写一个函数，然后再测试它写得对不对？刚开始的时候，模型在这方面的表现简直糟透了。 BEN MANN 2022 年的春天，我们早期开发的编程助手(coding assistant)还挺受大家欢迎的。那时，我们大约已经拥有了 100 位外部用户。 SHAUNA KRAVEC 搞智能体编程所需要的基础架构，比做个简单的聊天机器人要复杂得多。特别是当你考虑到代码执行的时候；你必须仔细斟酌代码到底要在什么环境中运行，以及如何安全、高效地管理这个环境。如今 [2026年] 人们在开发 AI 智能体时面临的许多挑战，和我们当年遇到的困难简直一模一样。 DAWN DRAIN 2022 年我们遇到的另一个棘手问题是 Harness 设计——就是围绕模型搭建的那套能让它真正采取行动的脚手架（为 AI 智能体提供运行和交互环境的底层支撑系统）。我和强化学习团队的一位同事合作，在容器（一种轻量级的虚拟化运行环境）内实现了一个持久运行的 shell（命令行解释器），这样模型就可以执行代码、处理数据流的输入输出，并能很好地处理超时问题。 BEN MANN 我回来后帮忙发布了第一版的 API（应用程序接口），之后我们基本上就把编程助手这事儿给抛到脑后了。 DAWN DRAIN 但在研究团队这边，我们一直在默默努力，想方设法让模型在智能体编程方面变得更强。 SHAUNA KRAVEC 到了 2022 年底，我们开始将工作重心转移到开发更具开放性的 AI 智能体上，致力于让它们真正派上用场。到了 2023 年，我们的模型已经能完成基础的函数调用(function calling)、一些搜索操作，以及一些零碎的小任务了。 BEN MANN Shauna 的团队取得了突破性的进展。他们找到了赋予模型 bash 工具（让模型具备使用命令行操作系统的能力）的方法，让它具备了四处搜索信息的能力——这些正是让智能体编程能够真正运转起来的关键拼图。 DAWN DRAIN 我花了一段长得让人不好意思的时间，试图教会 Claude 写 diffs（代码差异文件，用于展示代码修改前后的对比），因为在纯文本中表达修改，这似乎是最自然的方式。最终我们做出了一个叫 `clide` 的东西，这个名字是我们同事 Eli Tran-Johnson 之前给一个早期版本起的。说白了，它就是一个内部的命令行工具，你可以通过它和 Claude 聊天，让它帮你改代码、干些开发的活儿。 SHAUNA KRAVEC 它当时还挺不稳定的——==但它的理念非常、非常超前。== BEN MANN 我一有空就会鼓捣 `clide`。我太喜欢它了。我觉得它真的很棒，但它明明可以做得更好。 DAWN DRAIN 我们在 `clide` 里开发了一个超酷的功能：它可以并发启动一百个 Claude Haiku（Anthropic 推出的一种快速且轻量级的大语言模型）。这样一来，即使整个文件夹的代码量大到根本塞不进上下文窗口，你也能直接向它提问。在好几次结对编程（两名程序员坐在一起共同写代码）时，我都会得意地掏出 `clide` 来解决问题，大家总是惊讶地问我，是怎么知道这些炫酷工具的。 SID BIDASARIA Anthropic Labs 团队技术人员，Claude Code 项目的二号工程师 大家都在谈论 `clide`，但它用起来很笨重，启动速度也慢得要命。 ADAM WOLFF Anthropic Claude Code 团队的首任经理 在我去 Labs 团队工作之前，`clide` 智能体是我给它添加的最后几个功能之一。当时的 `clide` 还没有 bash 工具，所以它的能力很受限。我给它做了一些设置，让它能根据一部分代码的修改，推断出你到底想干什么。所以它算是==婴儿期的智能体(baby agentic)。== 当它第一次成功运行的时候，我激动得在厨房里手舞足蹈。我简直不敢相信这是真的。 BEN MANN 2024 年 1 月，我创立了 Labs 团队。我敏锐地察觉到了智能体编程在市场上的空白。那年 9 月 Boris 加入 Labs 时，他想做一个代码检查工具(linter)（用于分析代码以发现潜在错误和风格问题的工具）。他只想在智能体编程这块大蛋糕上咬下小小的一口。我当时就说：“不，不，不，不，你得干票大的。” BORIS CHERNY Anthropic Claude Code 负责人 那时候，你得念各种各样的“咒语”（复杂的提示词或指令）才能让 `clide` 跑起来。尽管它算不上什么出色的软件，但从某种程度上说，它依然令人惊叹、充满魔力，因为它让人看到了未来。 有一次，我纯手工写好了一个拉取请求(pull request)（开发者提交代码修改的一种方式），结果 Adam 把我给拒了。但他对我说：“其实这活儿你应该用 `clide` 来干。”于是我敲下了 `--string-edit` 之类的命令。我只是把需求单的内容复制粘贴进 `clide`，它就自动帮我写完了整个拉取请求。那是个大概五到十行的代码提交。我以前从未见过这种操作。太震撼了。感觉就像未来已来。 BEN MANN 他当时的反应就是：==“卧槽，太牛了。”== 我们已经凑齐了所有的组件——缺的只是把它们拼装在一起。 RAPHAEL LEE Anthropic Labs 团队的首任工程经理 Boris 被指派负责智能体编程这一块。对于自己想要采取的路线，他有着非常清晰的规划。 BORIS CHERNY 我的上手项目是“让编程自动化”。所以我想，“好吧，首先我得学学怎么用咱们的 API，”因为我之前压根没用过。我开始瞎捣鼓，但其实我完全不知道我们到底想造个什么东西出来。 我就这么随便玩着，然后做出了这个被我称为 Claude CLI（命令行界面）的东西。 没人看得懂那个 Claude CLI 的演示是干嘛的。说实话，连我自己都没弄明白。但现在回过头来看，你会发现最初的那些核心元素都已经在那儿了。我当时让它去看看我正在听什么音乐。它居然直接给 Apple Music 截了个图，然后读取了上面的信息。感觉挺神奇的——它就这么直接*把事儿给办了*。 那大概花了我两天的时间。如果要用今天的 Claude Code 重新实现这个功能，大概只需要两分钟。 我把这个演示发到了 Slack（团队沟通软件）上。我估计也就拿到了两三个赞吧。 IGOR KOFMAN Anthropic Labs 团队技术人员 在我看来，这条路子显然是对的。 BORIS CHERNY 发完帖子第二天，我走进办公室看到 Robert 正在工作，我一眼就认出了屏幕上那些红红绿绿的代码行，那些界面现在已经成了标志性元素。他随口说了句：==“是啊，它正在帮我写代码呢。”== 这简直太疯狂了——它居然真的管用。 ROBERT BOYCE Anthropic Labs 团队技术人员 我不记得当时具体在干什么了；大概是在弄 Claude 的桌面应用吧。那时的应用非常简陋，无非就是一个循环里的工具定义，加上一个简单的交互式界面。 BORIS CHERNY 当然了，它当时离“好用”还差了十万八千里。但我心里突然涌起一种强烈的紧迫感，我觉得必须立刻着手去完善它。我开始每个周末都在加班。我的朋友们都懵了：“你怎么回事？出来玩啊！”但我就是满脑子都是这玩意儿，停不下来。直到今天，那种紧迫感依然存在。 IGOR KOFMAN 刚加入 Anthropic 的时候，我想致力于让非工程师也能用上 AI 的力量。帮人写代码这事儿，看起来太显而易见了，我们迟早会解决。我想做点不那么显而易见的事。但大概过了三个月，我顿悟了：编程绝对是我们必须优先攻克的阵地，因为它是通向其他一切可能性的关键路径。 3 团队 3 ADAM WOLFF 我大学学的不是计算机科学。我是学电影的。但我一直很喜欢用电脑捣鼓点东西。1993 年我读到了第一期《连线》杂志，当时的感觉就是：“我的天，我必须参与到这股浪潮中去。”于是我搬去了旧金山湾区。我职业生涯的前半段是做游戏设计，后来转行做了程序员。最终，我参与了一个叫 React 的大项目，它现在是一个非常火的网页框架。 BORIS CHERNY 我请 Adam 来做我们的经理。一开始他拒绝了好几次，因为他想重新做回一名独立贡献者(IC)（指不带团队、专注于具体业务执行的专业技术人员），但在我死缠烂打，又请他喝了几次啤酒之后，他终于答应了。 IGOR KOFMAN 我大概七岁就开始用 BASIC 语言写代码了。我写的第一个软件是个教数学的小游戏，为了教我五岁的弟弟。“二加二等于几？”如果你答对了，电脑就会放音乐。当时我们住在乌克兰，用的很可能是一台从西方进口的电脑。你得往里面塞一盒磁带。 FIONA FUNG Anthropic Claude Code 与 Cowork 部门负责人 以前有一种叫 Turing（图灵）的编程语言，是多伦多大学发明的。我就是用它写出了我的第一个游戏。那感觉就像在创作艺术品一样。==编程，就是一种让你讲述故事、创造世界的方式。== CAT WU Anthropic Claude Code 产品负责人 我是 2024 年夏天加入 Anthropic 的。当 Boris 发布他的 Claude CLI 演示时，我就开始用它来搭建强化学习环境了。它带来的效率提升让我大为震撼。 我给 Boris 发了一大段一大段的反馈。而 Boris 响应的速度同样快得惊人，他很快就告诉我，很多需求他已经加上了新功能或者修复了问题。在那个时候，我可能是最活跃的用户之一了。于是他问我：“你想加入我们吗？” MEAGHAN CHOI Anthropic 产品设计师 我第一次和这个团队打交道大概是在 2024 年 12 月。为这类工具做设计可不常见。但我记得当时看到 Claude CLI 时，我心里想：“我们可以把它变成一个非常酷的产品，它只是缺了一点点设计的关怀。”所以我就问，我能不能花两周时间做个快速的突击尝试。 SID BIDASARIA 我是 2024 年 8 月加入 Labs 团队的。当时 Boris 正在搞这个很酷的命令行工具，我就顺势加入了。在我的职业生涯中，我从来没有哪一项特定的专长，以前也从未开发过开发者工具或编程工具。这对我来说是完全陌生的领域。 4 构建 4 BORIS CHERNY 2024 年 10 月，我拼了命地干。每个星期我都会跑去诉苦：“Raph，求你了，多给我几个工程师吧！” RAPHAEL LEE 我们几乎把整个 Anthropic Labs 团队的人都倾注到了 Claude Code 上。剩下的人则组成了 MCP 团队。要是能招人快点就好了！在早期，团队的扩张主要依赖于内部调岗，以及缓慢但高质量的外部招聘。 ADAM WOLFF 团队扩张是一把典型的双刃剑。Boris 极力主张快速扩张。我却想要相反的结果，并尽可能地压着不扩招。有更多的人手固然好，但==团队规模一旦变大，流程、文化、愿景等方方面面的事情都会变得更加困难。== 我也把它看作是一场早期的实验，想看看 Claude Code 将如何改变工程团队的工作方式，以及我们对生产力的预期。即使团队规模相对较小，我们开发新功能和修复程序错误(Bug) 的速度也是我前所未见的，简直像是在飞。 BORIS CHERNY 事后看来，保持一个小规模的团队实际上是我们成功的关键因素。这迫使我们在资源利用上极具创造力，也防止了我们过度工程化（把简单问题复杂化）。更重要的是，它逼着我们更加依赖和使用 Claude。不然的话，我们的开发速度根本跟不上。 SID BIDASARIA 直到 2024 年 12 月，都只有我、Boris，再加上一点点 Ben 的协助，在鼓捣这个项目。等我们拿到许可后，Labs 团队和其他几个团队的六七个小伙伴加入了进来，我们开启了最后两周的冲刺。==你今天看到的很多核心功能都是在那两周里赶出来的，== 比如错误报告和登录流程。正是那次冲刺让我觉得，“好了，这玩意儿正在变成一个真正的产品。” ADAM WOLFF 在开发 React 的时候，为了让它能在内部普及，我们所做的一切努力，最终也促使了外部开发者开始接受它。这让我们更深刻地理解了它的优势在哪里，坑在什么地方，以及未来的路该怎么走。对于 Claude Code 来说，情况也是一样。 SID BIDASARIA 当时我们的代码库没有任何限制，也没有任何代码审查的门槛。出了问题我们就直接发布修复补丁。Boris 在早期做的一件不可思议的事情是，他内置了自动更新功能和非常棒的用户指标监控。所以，一旦有人跑来跟我们抱怨：“这个地方好难用”，我们可以立刻推送修复，五分钟后他们就能用上新版本了。 RAPHAEL LEE 反馈如雪片般涌来。Boris 和 Sid 总是会在几分钟内回复每一条评论，并且经常在当天甚至同一个小时内就提交修复，因为用 Claude Code 撸代码实在太快了。 SID BIDASARIA BEN MANN 对于那些没做过大语言模型(LLM)产品化的人来说，有一个道理可能不那么明显：你现在就得去造一个成功率只有 20% 到 30% 的东西，这样等到下一代模型发布时，它的成功率就能达到 80%。这已经足以在市场上站稳脚跟了。再等到下下代模型，成功率就能达到百分之九十多，到那时你就真的取得了实质性的进展。而且==你的痛苦承受能力必须非常高，因为在这个过程中，你会一遍又一遍地失败。== 你必须脚踏实地立足当下，但同时也要高瞻远瞩放眼未来。 5 发布 5 CAT WU 在正式发布前的抢先体验阶段，我们得到的反响不温不火。有些人觉得这个点子很酷，但满天飞的 Bug 实在让人抓狂。尽管如此，我们还是在 2025 年 2 月冒险迈出了发布这一步。 就在那时，我们正式将 Claude CLI 更名为 Claude Code。这个名字是产品营销部门的 Alex Isken 提出来的。我们都喜欢它的简单纯粹。 IGOR KOFMAN 在发布前夕的一个深夜，我突然灵光一闪：“如果我们搞一个 ASCII（一种由字符拼成的艺术图案）的 Logo，岂不是很酷？”我让 Claude 帮忙生成了一些字符画字体，然后我们把它变成了那个标志性的图案。它成了大家登录时的一个小惊喜。 MEAGHAN CHOI 我最喜欢的一点就是往终端里加了那个小小的角色图案。Sam McAllister 最初为了发布 Claude 3.5 Sonnet 专门设计了这个吉祥物。在产品开发中，你其实很少有机会能做这种好玩的事情。 AUSTIN RAY Ramp 公司 AI 开发者体验负责人兼主任软件工程师 在我的整个职业生涯里，我一直是个死忠的命令行粉。所以只要有可能，我都会泡在终端里。[2025 年 2 月] Claude Code 作为研究预览版发布后，有人发帖提到了它，我就顺藤摸瓜找到了。刚上手用了不到五分钟，我就断定：“没错，这玩意儿将从根本上颠覆一切。” KYLE EASTERLY Delve Group 首席执行官兼 Claude 社区大使 我大概八九岁的时候，有一次和爷爷奶奶开房车旅行，就在那时我学会了编程。我爷爷有一台笔记本电脑，里面有一本早期操作系统的帮助手册。我仅仅用条件判断语句，就敲出了一个小小的侦探调查游戏。 时间快进到 2025 年，我当时正在为一个名为“阿拉斯加州独立生活委员会”的非营利组织担任软件项目顾问——他们主要为年轻人提供残障服务。他们会把一群高中生召集起来，帮他们设定毕业后的人生目标。以前他们都是用纸和笔来举办这些研讨会，结果只有十分之一的孩子能坚持完成。 当我开始为他们开发一个应用程序时，我已经在使用 Claude 了。我会用工作台来回切换，把一堆文件复制粘贴到剪贴板，再手动给它们加上标签。就在那个项目期间，Claude Code 发布了，我半路切换了工具——结果*瞬间起飞*。 AUSTIN RAY 第一次用的时候，我激动得起了一身鸡皮疙瘩。如果它能读取、编辑还能运行 bash 命令，那它就无所不能了。它能够自动执行步骤，而这些底层的基础能力，正是构建其他所有东西所必需的基石。 我立刻开始在公司内部疯狂安利它。我在公司所有的频道里发消息，问还有谁在用这玩意儿。然后我直接跑到同事的工位旁对他们说：“听着，你得相信我。你要是不试，我就不走了。装上 Claude Code，在终端里启动它，咱们来试试。你现在在忙什么？你直接告诉它试试？然后咱们看看会发生什么。” Boris、Cat 和我每周都会开会交流反馈。我们就这样自然而然地建立起了开发者和用户之间的纽带。 我一直喜欢瞎捣鼓，对自动化、滚雪球式的积累，以及反复递归优化自己的工作环境有一种近乎狂热的追求。[Claude Code] 简直是发挥我这些技能的完美土壤。 JARRED SUMNER Bun 创始人 当我尝试使用 Claude Code 时，我让它在 Bun 里实现网络通信压缩功能，我把相关的技术规范文档喂给它，然后它就自己搞懂了该怎么写代码。虽然一开始它写得有点烂，但在我给了一堆提示词引导之后，它自己就把代码修好了。之后，我甚至改变了我们团队排定优先级的策略，就是为了能更好地配合 Claude Code 一起开发。 相比于它当时产生的影响力，我可能对它有点过于走火入魔了。 TRISTAN HUME Anthropic 性能工程团队技术人员 我的大部分任务都需要大量的上下文信息。我当时正在为硬件加速器编写底层的内核代码，这些东西在互联网上通常是找不到公开文档的。那时的 Claude Code 还不太擅长自己写工具，也不太会为了现学现卖去做大量的深度调查。所以，除了非常有限的几项任务外，它当时真的没啥用。 JARRED SUMNER 大约在 [2025 年] 8 月或 9 月的时候，内部有场讨论，有人提议要禁用 Claude Code。但我绝不容许这种事情发生。 MEAGHAN CHOI 直到 Claude 4 模型横空出世，属于我们的高光时刻才真正降临。在那之前，我们在用户体验设计上其实做不了太多文章。==因为那时的模型，还撑不起我们想要打造的那款产品。但后来，它终于可以了。== BORIS CHERNY 我们顺势推出了订阅服务。所以，促成 Claude Code 腾飞的有两个关键因素：商业模式的创新，加上底层模型的飞跃。 DAWN DRAIN 说实话，我不觉得 Claude Code 能有今天是因为沾了多少 `clide` 的光。一旦跨越了模型能力那个临界点，产品该长什么样，自然而然就浮现出来了。 KYLE EASTERLY 这彻底改变了我们的工作方式。回想 2022 年我刚开始玩 AI 的时候，我脑子里根本想象不出 Claude Code 现在的样子。但我能预见到，只要它能凭空生成一个能跑起来的应用，我就可以在此基础上无限扩展。 SID BIDASARIA 我从来没想过它会变成一个这么庞大的产品——这完全出乎我的意料。直到今天，想起来我还是觉得很不可思议。 BORIS CHERNY 2025 年 2 月那会儿，Claude Code 大概能帮我写 10% 的代码。到了 5 月，这个比例上升到了 30% 到 40%。我记得 Sonnet 4 发布的时候，我正在参加 [Code with Claude](https://www.anthropic.com/events/code-with-claude-2025) 开发者大会，我坐在后台写着代码，心里暗叹：“哇，这玩意儿真的越来越厉害了。”模型变强了太多，智能体能力大幅提升，写代码更是行家里手。到了 2025 年冬天，==我 100% 的代码都是用 Claude Code 写的。== 一行手敲的代码都没有了。 KYLE EASTERLY 这世上有两种开发者。一种非常享受写代码的过程——代码就像是他们精心打理的枯山水庭院。在心流状态中，感觉很美妙。另一种开发者——当然这两者之间有重合，并非非黑即白——他们的巅峰成就感来源于：现实世界中有人在使用这块软件，并且觉得它很好用。我就属于这第二大阵营。 SHAUNA KRAVEC 我是个彻头彻尾的 Claude Code 重度用户。我手下有一整支由十二个不同的 Claude 组成的智能体群跑来跑去——读文档、更新数据、从聊天工具里拉取信息。作为一名研究主管，我这几年其实已经很少亲自写代码了。但现在我写的代码反而更多了，因为这事实在太轻松了。 IGOR KOFMAN 随着大语言模型和 Claude Code 变得越来越强大，我们将迈向下一层抽象：到那时，你不再需要去管理一大群 Claude 了——你只需管理那个指挥 Claude 的“经理”。 TRISTAN HUME 我看着同事们获得了巨大的效率杠杆，让 Claude 在后台帮他们处理任务，而我却没有好办法做到这一点。我甚至不得不放下手头的活儿，花整整一个星期的时间来重新配置一个新的开发环境。但有一点很明确：如果你想把生产力发挥到极致，你写代码的方式必须改变了。 BORIS CHERNY 昨天我在用 Claude Code 敲了一整天的代码，我的妻子和家人就在沙发上闲坐。我一天提交了 88 次代码。 CAT WU 刚发布那会儿，Claude Code 每次请求权限时，大家都会逐字逐句地仔细审核。但现在，一大半的用户直接选了“全部自动同意”。我觉得这个转变足以说明，Claude 已经赢得了他们的信任。 ADAM WOLFF React 让我看到了一个成功的项目所面临的局限。它最初源自一个非常纯粹的计算机科学理念：用函数式编程来表示用户界面状态，比用消息传递更好。当它的日活跃用户(DAU)（衡量软件每日活跃用户数量的指标）突破一百万时，它就已经演变成了完全不同的东西。它成了一个标志、一个品牌、一种情怀，早就超出了计算机科学概念的范畴。一个普通 React 用户喜欢它的理由，可能根本追溯不到它最初的核心洞察。 我敢肯定，Claude Code 也会走上同样的演变之路：不管你现在觉得 Claude Code 到底是什么，觉得它是那个终端界面也好，是 Claude 的个性也罢，或者是你正在用的某套特定提示词技巧，走到最后，这些外在的东西都不重要了。 AUSTIN RAY 当我在内部最初推动大家使用 Claude Code 时，我刻意打造了一个社区，培育了一种勇于试错的文化。我们分享失败的教训，讨论什么是管用的、什么是坑，并且把这些讨论公开化。不断积累这种团队内部的“部落智慧”，才是关键所在。 FIONA FUNG 软件工程的角色必将发生翻天覆地的变化。我在开发者工具领域干了十一年半，但==我绝不敢大言不惭地说，我知道下个月会变成什么样。== 我们必须保持强烈的好奇心，并且极度虚心地向我们的内部和外部用户学习。 TRISTAN HUME 我试着把它的潜力榨干到了极致。我让 Claude 从零开始写一个数据分析笔记本的替代品——我不看任何代码，就放任它自己去写，甚至让它自己用浏览器去测试用户界面。它还真做出了一个能跑的东西。但我试用了一下，发现我不喜欢。我得等一个有“品味”的 Claude 出现——它必须懂我所有的需求，并且能在后台默默把事情干得漂亮。 AUSTIN RAY “我能不能让它跑得更快？能不能做得更好？”——这种对极致的痴迷，就是我们的文化。这绝对是一种“拥抱前沿，勇于尝试”的劲头。只要对客户有帮助，我们什么都愿意试。 KYLE EASTERLY 像这样的非营利组织，以前根本不可能负担得起定制软件。因为压根没有那么多项目专款。现在，一整块以前不敢想的事情，突然都变得可能了。 我们现在甚至能处理极寒地区手写的燃油配送日志，把它们转录出来，整理进 CSV 数据表里。我们刚刚就为那个客户发布了一款平板应用。 我们总是告诉客户，你得亲眼看看，光听别人说 AI 能怎么帮你是不够的。 SHAUNA KRAVEC 自主软件工程 AI 智能体的愿景，现在多多少少已经变成了现实。 我认为，大家对 AI 能为人类做出的*积极*贡献抱有很多幻想，这些幻想最终都落脚于：AI 必须能以一种开放的姿态发挥效能，去解决人类自己解决不了的问题。我们谈论加速科研、治愈癌症、登陆月球——如果一个模型只会答题，那你是无法实现这些宏图伟业的。==你需要一个能真正走向世界、采取行动的模型。== MEAGHAN CHOI 从历史上看，写代码一直是个门槛极高的事情。现在，我们把这种能力交到了无数人的手中。看着大家在内部和外部创造出的那些惊人成果，我真的觉得一切都值了。 SHAUNA KRAVEC 我原本是学理论物理出身的。有些科学难题，人们已经埋头苦干了几个世纪。那个领域的进展速度比 AI 慢得多，而且常常被一些极其困难、极其昂贵的障碍卡住脖子。毕竟你能建的粒子对撞机也就那么多。 我觉得在 2026 年和 2027 年的大部分时间里，可能短短三个月内就会发生翻天覆地的变化。如果是放在 2024 年，三个月的进展顶多算是一次小提升，绝对没这么戏剧化。这种让人找不着北的加速才是最令人晕眩的，而且==我不确定是否有人已经为此做好了准备。== IGOR KOFMAN 我妈妈是一位科学家，她当年是用打孔卡片来写代码的。我会帮她排查打孔卡片里的程序错误。我爸爸是一位工程师，但他起初并不懂编程，直到有人捐赠了一台早期的家用电脑。他找来一本关于编程的书，我们在家就凑在一起读。我就是这样误打误撞走进软件开发这个世界的。 从 2025 年冬开始，我就再也没有亲手敲过一行代码了。 BORIS CHERNY 这就好像——和我爷爷当年在苏联用的编程工具很像。而早期文本编辑器，直到现在每台 Mac 电脑里都还装着它。然后技术不断演进，演进，演进，并且永不止步。最终，在这条进化图谱的某个坐标上，诞生了 ==Claude Code==。 --- 来源: https://www.anthropic.com/features/making-of-claude-code

Code with Claude — Anthropic's Developer Conferenceclaude.com · 直连原文

@AnthropicAI

We’re pleased to have collaborated with AE Studio on this research. Read more here: https://www.anthropic.com/research/off-switch-dual-use

An off switch for dual use knowledge in AI modelsanthropic.com · 直连原文

@AEStudioLA

New research! Some AI capabilities are both helpful and dangerous. E.g., knowledge of virology can be used to create life-saving vaccines or deadly pathogens. We introduce GRAM, a training method that puts dual-use capabilities (like virology) into removable modules.

@dotey 转推了

@dotey

这篇关于如何写出好的 Skill 的文章，大部分还是不错的，也有些不严谨之处。 1. 不要让模型自己写自己的 Skill ❓ 文章意思是人类专家写的技能比 AI 写的更好，应该人来写技能而不是让 AI 写 Skill。 > 让智能体自己给自己写 Skill，这个想法非常诱人。SkillsBench 专门测试了这一点：每个任务都在三种条件下运行，无 Skill、专家策划的 Skill、模型自生成的 Skill。专家策划的 Skill 显著提升了通过率。模型自生成的 Skill 完全没有帮助，平均还比无 Skill 基线低 1.3 个点。作者的结论是：模型无法可靠地产出那些它在使用时会受益的流程性知识。 这条其实不够严谨，AI 是能写 Skill 的，只要人提供好上下文就可以，而不是简单的说别让模型写 Skill。而且就算是 AI 训练过的知识，让 AI 把一些操作路径、输出风格格式固化下来都是有价值的。 也不是说是错的，完全指望 Agent 帮你写 Skill、进化 Skill 还是不太够，还是需要人去引导会更好。 最佳组合是人指挥 AI 写 Skill。 2. 面面俱到，反而糟糕 ✅ 聚焦于核心内容、仅包含两三个文件的技能，其表现要远好于一大堆文件的集合，也胜过长篇大论的文档。那些试图把所有东西都写进去的“全面型技能”，反而会把任务通过率拉低到不如不用技能的水平。“细节丰富且范围明确”的做法，每次都能完胜“百科全书式”的做法。 确实如此，Skill 不要追求大而全，小而精更好。 3. 加载的技能越多，智能体反而越笨 ✅ 技能虽然是按需加载，但也是占用上下文的。不是越多越好。 4. 必须在要支持的每个 Harness 中进行测试 ✅ Skill 虽然是通用，但是不同 Agent 或模型还是有差异，比如 Codex 有自带画图工具，Claude Code 没有；比如 Claude 是多模态的能看图片，GLM 不能看图；这些都需要测试，并且针对性的写一些兼容性的说明。 5. 瞄准模型最薄弱的领域出击 ✅ > SkillsBench 按照不同领域测量了技能带来的提升效果。结果差异巨大：在软件工程领域只提升了 4.5 分，而在医疗保健领域则飙升了 51.9 分，制造业紧随其后。技能对软件开发领域的帮助最小，因为模型早就被海量的代码预训练数据“喂饱”了；而技能帮助最大的，恰恰是那些训练数据覆盖薄弱的领域。 说的挺对的，我几乎不用软件工程相关的 Skill 正是因为这个原因，像 superpower 这种 skill 对于好的模型真的提升很有限。 6. 不测试，你永远不知道技能好不好用 ✅ > 找一组任务，运行两次：一次加载技能，一次不加载，保持其他所有变量绝对一致。用同一种标准给两次结果打分，然后看看差异。 技能是需要测试的，但有些技能的测试结果是不好量化的，这时候还是需要依赖专业人士的判断。

@dotey

模型现在已经聪明到足够懂你，表达可以很随意，几段碎片文字，随手涂鸦几笔，找个葫芦（参照），都能让模型理解，实在不行还能让模型提问你。 难的是有了 Fable 5 这样的模型，却不知道用来做点什么，就像你开了个公司，雇了一群天才员工，这公司却不赚钱，还得发工资。 另一个难的就是对结果的验证和后续的维护，vibe 出来很容易，但结果对不对，有没有安全问题，这些事还不能完全依赖模型，总还是要人工去审查一下，哪怕借助模型审查。 运气好一点 Vibe 出来上线没问题，功能越堆越多，后续维护又是新的问题，完全依赖模型还是很难。 这些问题都解决后，以前只差牛逼程序员能做出来的产品，现在大家都可以用牛逼模型 Vibe 出来了，怎么卖出去又成新的问题了。

@OpenAI

For questions that require web search, deeper reasoning, or more complex work, GPT-Live can delegate to our latest frontier model behind the scenes, and brings the result back into the conversation when it's ready.

@dotey 转推了