Chubby♨️@kimmonismus · 6月5日75

Holy moly, Anthropic is getting very serious about recursive self-improvement! One word: acceleration. Insane blog article. Tl;dr: •We are close to an AI capable of fully autonomously designing and building its own successor •They stress this isn’t here yet and isn’t inevitable, but could arrive sooner than most institutions are ready for •Anthropic engineers now ship on average 8x as much code per quarter as they did in 2021–2025 •Task length AI can reliably complete is doubling roughly every 4 months (up from every 7 months) •Opus 3 (Mar 2024) handled ~4-minute tasks; Sonnet 3.7 (a year later) ~90-minute tasks; Opus 4.6 (a year after that) 12-hour tasks •SWE-bench went from low single digits to saturated in two years; CORE-bench (research reproduction) went ~20% to saturated in 15 months •METR found Claude Mythos Preview could work “at least” 16 hours, at the top of what they can currently measure •As of May 2026, Claude authored 80%+ of code merged into Anthropic’s codebase (low single digits before Claude Code launched in Feb 2025) •A March 2026 poll of 130 research staff: median respondent estimated ~4x output with Mythos Preview •One April 2026 example: Claude shipped 800+ fixes cutting a class of API errors 1,000x, work an engineer estimated would have taken a human four years •Claude-written code quality: worse than human in late 2025, roughly at parity now, expected to be strictly better within the year •On the hardest open-ended tasks, Claude’s success rate hit 76% in May 2026, up 50 points in six months •Code-speedup test: Opus 4 averaged ~3x speedup (May 2025), Mythos Preview ~52x (April 2026); a skilled human needs 4–8 hours to hit 4x •In an AI-safety research project, Claude agents recovered 97% of a performance gap (vs ~23% for two human researchers in a week), over 800 compute-hours and ~$18K •On picking the better “next step” in research sessions, the best model beat the human choice 51% (Nov 2025, Opus 4.5) rising to 64% (April 2026, Mythos Preview) •Human comparative advantage, for now: research taste and judgment, i.e. choosing which problems matter and when an approach is a dead end Three possible futures •The trend stalls (S-curve), but today’s capabilities still diffuse widely; they consider this least likely •Compounding efficiency gains, with humans still setting direction; 100-person firms doing the work of 10,000+; they think this is the likely path •Full recursive self-improvement, where AI builds its successors and pace is set by compute; the alignment outcome here is what they’re least certain about

译Anthropic 内部数据显示 Claude 能力增速远超预期，可能接近自主设计继任者的递归自我改进。关键指标：工程师人均季度代码产出是此前四年平均的 8 倍；AI 可可靠完成的任务时长每 4 个月翻倍，从 Opus 3 的 4 分钟升至 Mythos Preview 的至少 16 小时。截至 2026 年 5 月，Claude 撰写代码占 Anthropic 代码库 80%+，代码质量已与人类持平，年内将超越。最困难任务成功率 6 个月从 26% 升至 76%。Anthropic 认为趋势停滞可能性最低，复合效率增益最可能，完全递归自我改进的对齐结果最不确定。

Yuchen Jin@Yuchenj_UW · 6月5日60

Recursive self-improvement post by Anthropic: “Each time we release a model, we give it code that trains a small AI model, ask the new model to speed it up. In May 2024, Claude Opus 4 averaged a ~3x speedup. This April, Mythos Preview achieved ~52x.” RSI is happening, and I can't wait to see Mythos.

译Anthropic 发布的递归自我改进帖子： “每次我们发布一个模型，都会给它代码，让它训练一个小型 AI 模型，然后让新模型加速训练。 2024 年 5 月，Claude Opus 4 平均实现约 3 倍加速。今年 4 月，Mythos Preview 达到约 52 倍。” RSI 正在发生，我等不及要看到 Mythos 了。

Nathan Lambert@natolambert · 6月5日31

I feel like this also goes for a lot of people without Mythos as they learn to use agents too tbf

译Anthropic 表示，使用 Mythos 后人均代码产出较半年前 Opus 4.5 提升 3.2 倍。Nathan Lambert 评论称，没有 Mythos 的人在学用智能体时也有类似感受。

Anthropic@AnthropicAI · 6月5日74

Our internal data shows Claude is accelerating AI development—a possible path to recursive self-improvement, or AI autonomously building a more capable successor. It’s happening faster than we thought, and the implications deserve greater attention. https://www.anthropic.com/institute/recursive-self-improvement

译我们的内部数据显示，Claude 正在加速 AI 发展——这是一条通往递归自我改进的可能路径，也就是 AI 自主构建一个更强大的后继者。 这发生得比我们预想的更快，其影响值得更多关注。

Claude@claudeai · 6月4日51

Anton Osika (@antonosika) is the co-founder and CEO of @lovable, where anyone can build software through conversation. His working thesis: the most underrated moat in AI is trust, and earning it takes craft, care, and obsession.

译Anton Osika (@antonosika) 是@lovable 的联合创始人兼CEO，任何人都能通过对话构建软件。 他的工作论点：AI中最被低估的护城河是信任，而赢得信任需要技艺、用心与执着。

Nathan Lambert@natolambert · 6月4日60

Safety by narrow control has shown to fail many times. Need more transparency on the absolute frontier, and openness close behind.

译狭窄控制的安全已多次证明会失败。在绝对前沿上需要更多透明度，开放紧随其后。

🚨 AI News | TestingCatalog@testingcatalog · 6月4日65

ANTHROPIC 🔥: A new "claude-oceanus-v1-p" has been made available to Red Teams. This appearance may signal an upcoming release of newer Mythos models, referenced earlier by Antropic. Soon? 👀

译Anthropic 为 Mythos 新版本（代号 Oceanus，检查点名“claude-oceanus-v1-p”）开放红队测试。据爆料，此类测试通常提前 7 天公开推出，但该程序因有人通过中国 API 代理转卖而被暂停，是否影响发布时间未知。

Ethan Mollick@emollick · 6月4日55

The capabilities of Claude Code and Codex have expanded a lot in recent months, they added many ways to approach work (subagents, skills, goal, workflows, plugins, etc). Given the AI labs can use their own AI to help documentation, a surprising amount is effectively undocumented

译近几个月来，Claude Code和Codex的能力大幅扩展，增加了许多工作方式（子智能体、技能、目标、工作流、插件等）。考虑到AI实验室可以用自己的AI来辅助文档编写，令人惊讶的是，大量功能实际上没有文档。

Chubby♨️@kimmonismus · 6月4日68

OpenAI, DeepMind, Anthropic CEOs back mandatory DNA synthesis screening A coalition of AI leaders, synthesis-industry executives, biosecurity researchers, and former national-security officials published an open letter in June 2026 urging Congress to make screening and recordkeeping of synthetic nucleic acid orders mandatory in the US, arguing that rapidly improving AI is eroding the knowledge barriers that have historically kept bad actors from building biological weapons. Signatories - including Demis Hassabis, Sam Altman, Dario Amodei, and Nobel laureate David Baker - frame screening as a well-understood, low-disruption measure already practiced voluntarily by major providers, and call for action this congressional session plus consistent state-level standards.

译2026年6月，由AI领袖、合成行业高管、生物安全研究人员及前国安官员组成的联盟发布公开信，敦促美国国会强制对合成核酸订单进行筛查与记录保存。签署人包括Demis Hassabis、Sam Altman、Dario Amodei及诺贝尔奖得主David Baker。信中指出，快速进步的AI正在削弱制造生物武器的知识门槛，而筛查措施已被主要供应商自愿采用，影响小且成熟。联盟呼吁本会期内采取行动，并建立统一的州级标准。

小互@xiaohu · 6月4日70

http://x.com/i/article/2062455165006090240 # Anthropic 如何通过 Claude 实现自动化商业分析 Anthropic 95% 的数据分析让 Claude 干了... 但一开始准确率多少？21%，跟瞎蒙差不多...后来搭了一套四层系统直接拉到 95%。 Anthropic官方发布了一篇博客，详细阐述了他们是如何通过Claude 实现自动化商业分析的。 我翻译了下，推荐大家阅读！ 原文：https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude 做过数据的人都知道，让业务团队自己查数据，一直是个老大难。 一种常见做法是建宽表，把数据模型摊平了给非技术同事用。但业务一扩张，各种视图就开始打架，定义不一致、口径对不上，而且那些压根不想学 SQL 的人照样用不了。另一种做法是给用户划好一块块固定区域，只能在里面看数据，但这又覆盖不了那些零散的、个性化的分析需求。最后就是每个团队各搞一套，指标和看板越来越多，越来越乱。 大语言模型的出现提供了一条新路。但如果你只是把 Claude 往数据仓库一指，让 AI 智能体自己跑，很容易造成一种"看着很准其实不靠谱"的假象。 刚摆脱临时取数需求的那股兴奋劲儿，很快就会变成焦虑。你会发现，这套方案把业务方和底层的数据基础设施、文档、专业知识切断了，而过去恰恰是这些东西帮他们找到靠谱的数据集。 在 Anthropic，95% 的业务分析查询已经由 Claude 自动完成，整体准确率大约 95%。把这些重复性的活交给 Claude 之后，我们的数据科学团队可以把精力放在因果建模、预测分析、机器学习这些更有价值的事情上。 跟几十位 Anthropic 内部的 Claude Code 重度用户聊过、看过大量分析智能体的设计方案之后，我们攒了一些经验，想分享给同样在用 AI 做分析的数据团队。这篇文章会聊到： - 分析准确性本质上是上下文和验证问题，不是代码生成问题 - 导致大多数错误的三种失败模式 - 我们围绕这三个问题建的智能体分析栈 - 我们怎么衡量效果 - 我们创建技能的基础模板（见附录） ## 数据不是软件 AI 的生成能力是把双刃剑：让模型能创造性解题的那套机制，也会让它"一本正经地胡说八道"。要理解分析智能体面临的挑战，跟编码智能体对比一下就清楚了。 写代码是个开放题，模型越有创造力越好，而且有文档和测试兜底，写错了跑不通。但分析不一样：往往只有一个正确答案、一个正确的数据源，而且没有办法自动验证结果对不对。 自动化智能体分析的难点，主要在于数据本身的歧义性。核心问题就一句话：能不能把用户的问题准确地对应到数据模型里那个特定的、最新的字段，并且知道怎么正确使用它。做到了这一步，写 SQL 就是小事了。 我们发现，绝大多数不准确的回答可以归因于三件事： 1. 概念和实体对不上：数据模型里有成百上千个字段，潜在候选可能上百万，智能体不知道该选哪个。比如"活跃用户数"，什么行为算"活跃"？算不算欺诈用户？回看多长时间？ 1. 数据过时了：数据源、业务定义、表结构一直在变，智能体的知识没跟上，开始给出"看起来对，其实差了一点"的答案。 1. 找不到：正确的信息明明就在数据模型里，标注也齐全，但搜索空间太大，智能体就是没找到。 ## 我们的智能体分析栈 在 Anthropic，我们靠一套分层的智能体数据栈来对付这三个问题。每一层重点解决其中一个或几个： 1. 对不上→ 数据基础和权威来源层把候选范围不断收窄，最终只剩一个标准答案。 1. 过时了→ 维护和验证流程防止东西随着业务变化而腐烂。 1. 找不到→ 技能确保智能体能稳定地找到并正确使用那个标准答案。 下面逐层讲。 维度建模这些经典的数据工程实践，依然和以前一样重要 ## 数据基础 要让分析智能体准确，最重要的是把数据基础打好，包括数据仓库里的模型、转换逻辑、测试、表，以及描述它们的元数据。维度建模、尽早做测试、关键管道的新鲜度和完整性检查，这些老规矩依然有效，不多说了。 维度建模这些经典的数据工程实践，依然和以前一样重要。 但有一件事变了：数据模型的使用者不再是数据科学家这样的专家，而是替各种用户干活的智能体。这些用户水平参差不齐，你没法指望他们去验证底层查询逻辑对不对，他们根本看不懂。 数据基础层主要解决的是歧义问题。比如"收入"这个概念，如果在仓库里只对应一个经过治理的规范数据集，而不是四十个看着都像的候选项，那智能体还没开始搜，问题就消失了大半。同时这一层也是防过时的第一道防线，因为定义规范模型的那个代码仓库，本身就是最适合强制保持这些模型更新的地方。 我们觉得特别有效的几个做法： - 建规范数据集：最常见的错误是智能体没法把一个概念（比如"产品 X 的收入"）对应到唯一正确的表、列和指标定义，往往因为有好几个看着都合理但细节不同的候选。解决办法是少而精，精选一小批规范的数据集，权属清晰、开箱即用、容易发现，然后把那些近似重复的版本积极废弃。物理层面的汇总表和缓存还是要的，但它们应该从规范模型自动生成，不能作为平行替代方案存在。目标就是：智能体搜一个概念，只能搜到一个标准答案。 - 标准得靠强制执行：光定标准没用，得三管齐下。工具层面，智能体在架构上被优先引导到规范模型；CI 层面，绕过规范层的改动会在代码审查中被拦住；制度层面，下游团队必须基于治理层构建，不用就得解释为什么。没有执行力的治理，很快就退回到"一堆候选分不清"的老问题。 - 所有东西放同一个仓库：数据模型和业务逻辑天天在变，我们的防御手段是把建模代码、语义层、参考文档、看板定义全放在一个仓库里，靠 CI 检查保护跨层一致性。改了一个模型会影响下游看板？CI 会标出来，修复就在同一个 PR 里完成。 - 把元数据当正经产品来维护：编码智能体之所以表现好，部分原因是代码库本身就很"可读"，有 README、类型签名、文档字符串。数据仓库也可以做到一样可读，但前提是你得认真维护：列和表的描述、规范指标定义、粒度说明（一行代表什么）、有效值范围、数据血缘、权属关系、模型分级。这不是什么新道理，但好的治理确实能给智能体提供关键的选择依据。 ## 权威来源 如果说数据基础是数据仓库本身，那权威来源就是智能体用来在仓库里找路的参考层。这一层负责把业务方说的"周活跃用户"翻译成数据模型里某个具体的、经过治理的实体。按信任度从高到低排： - 语义层：编译好的指标和维度定义。如果一个问题能直接对应到已定义的指标，智能体调一个函数就能拿到一个数字，跟公司所有其他分析工具算出来的一模一样。我们的智能体被强制要求优先走语义层（见附录）。我们试过一个没用的思路：让 AI 从原始表和查询日志自动生成指标定义来引导语义层。结果生成的定义看着像那么回事，实际上把我们正要消除的歧义编码进去了，评估表现还不如更小但人工精选的版本。所以我们的建议是：用 Claude 生成文档，但指标定义由人来把关。 - 数据血缘和转换关系图：语义层覆盖不到的问题，可以靠血缘关系和表排名（按被引用次数排）来推理：哪些上游模型跟某个概念有关、哪些已经废弃、哪些粒度相同。这就把"我不知道这个指标"变成了"我知道该从哪个治理过的模型去聚合"。同时它也是后面线上验证部分的新鲜度和来源信号的基础。 - 历史查询语料：看板、Notebook 和过去分析里的 SQL 记录。听起来应该很有用，毕竟是每个已经被正确回答过的问题的记录。但实际上，让智能体直接检索几千条历史查询，准确率只提升了不到一个百分点（后面消融实验部分细讲）。非结构化检索没法把新问题映射到正确的先例上。真正管用的做法是把这些语料提炼成结构化的领域参考文档和可复用的分析模式，写进技能里。历史查询是原材料，不是让智能体直接读的参考答案。 - 业务上下文：大多数团队跳过的一层，也是我们低估最久的。不懂业务的智能体，会回答用户字面上问的问题，但不会回答他们真正想问的。它不知道"Q2 发布"是哪个产品，不知道两个团队对同一个术语定义不同，也不知道这个问题之所以被问是因为周四要开董事会。我们接入了一个公司知识图谱，索引文档、产品路线图、决策日志、组织架构都在里面，让智能体能理解那些言外之意，问出更好的澄清问题。 这四层有个共同的失败模式，跟数据基础层一样：文档质量差或者过时了。Claude 在弥补这个差距方面非常好用（写列描述、根据查询模式建议指标文档、在 CI 里标记缺文档的模型），但内容的筛选和权属还是得人来管。 接下来两节讲的是怎么让这件事的成本低到真正能落地。 ## 技能 如果说权威来源是智能体的知识，比如"这个指标是什么意思"，那技能就是它的方法论，比如先查什么、按什么顺序查、碰到数据歧义怎么办、一个合格的分析长什么样。 在 Claude Code 里，技能就是一组 Markdown 文件，智能体按需读取。在 Anthropic 内部，技能带来的提升是巨大的。没有技能时，Claude 回答分析问题的准确率不到 21%。加上技能，整体稳定在 95% 以上，某些领域经常到 99%。模板见附录。 几条经验： 技能要成对建：一个"知识"技能当顶层路由，它说"先查语义层，没有覆盖的话，这个领域大概 30 份参考文档，里面有相关的表、列、关联关系和常见坑"。这个路由器本质上就是我们对"找不到"问题的回答：与其让智能体在百万级字段里大海捞针，不如先把范围缩到几十份精选文件。另一个"unbook"技能编码的是一位资深分析师的工作流程：先澄清问题，再通过知识技能找数据来源，跑查询，然后把结果丢给对抗审查的子智能体做验证。它还内置了十几种可复用的分析模式，比如留存曲线、比率分解、漏斗分析等等，让常见需求不用每次从零开始。 参考文档要为 AI 写：我们的参考文档写的是表信息（粒度、范围、排除条件）、常见坑的具体机制（比如"排除免费邮箱域名，但保留自定义域名如 anthropic.com"），以及明确的路由触发条件（比如"如果问题涉及实验提升……不要用来算原始事件数"）。但不写会过时的固定脚本。参考文档模板如下： > [markdown] # [领域] 表 ## 快速参考 ### 业务上下文 — [用大白话解释这个领域是什么] ### 实体粒度 — [一行代表什么] ### 标准清洗过滤器 — [该领域每个查询都要应用的过滤条件] ## 维度 - [关键维度的编码方式，以及同一概念在不同表中的不同命名] ## 核心表 ### [table_name] - **粒度**: [...] · **范围/排除条件**: [...] - **使用说明**: [什么时候用、什么时候不用、关联键、必需过滤条件] [... 每个治理过的表一个简短小节 ...] ## 常见陷阱 - [资深分析师会提醒你的那些容易出错的地方] ## 最佳实践 / 常见查询模式 - [默认选择、标准切分维度、具体查询形式本身就是难点的成熟模式] ## 交叉引用 - [负责相邻问题的其他领域文档] 技能维护是正经工程活：技能文档描述的数据模型每天都在变，不维护的话几周就失准。我们亲眼看着离线准确率从上线时的 95% 左右，一个月内掉到 65%，才真正当回事。办法是把技能的 Markdown 文件跟数据转换模型放在同一个仓库，改模型的 PR 就得同时更新文档。我们还设了个代码审查钩子：涉及报表模型的变更如果没碰对应的技能文件，就会被标出来。现在大约 90% 的数据模型 PR 里都带着技能变更。我们也会定期清理，模型进步了，以前的失败模式不再适用，对应的指引也该删。 所有界面一个答案：同一个技能在 Slack、IDE、看板工具、独立会话里，必须对同一个问题给出同一个答案。我们靠一个规范来源（数据仓库的代码仓库）加自动同步来实现。代码合并后，技能会同步到插件市场（IDE 用户）、云存储（托管应用）和 MCP 服务。从一开始就不硬编码路径、不绑定特定界面。 ## 验证 验证是你发现三个问题还有哪个在漏网的最后一关。 ## 离线评估 很常见的情况是，数据团队花了大力气搭分析环境，却完全没有流程来验证智能体答得准不准。 怎么补？做离线评估，就是一组"问题 / 标准答案"对。你可以把它理解成机器学习里的离线测试：不能告诉你线上实际表现，但能让你看清有没有致命缺口。 我们在 Anthropic 做两类离线评估。看板评估由 Claude 自动生成再人工验证，覆盖业务方最常问的问题。长尾评估是把产品路线图、表文档等业务上下文喂给 Claude，让它在其余领域生成可能出现的问题。另外，每次业务方在对话里纠正了智能体的回答，我们都会把这条纠正收起来当候选评估用例。 其他经验： - 标准答案要锚定，不能漂移：基于实时数据写的评估用例，底层数字一变就废了。要么锚定到快照日期、基于稳定的事实表写，要么让评分器判查询语句而不是最终数字。把评估接进 CI，改了依赖就自动重跑受影响的用例。 - 评估结果当遥测数据存，不当测试日志存：每次运行的结果落入数据仓库，记录技能版本、git SHA、模型 ID、逐条断言结果、token 用量、耗时。"上次改动有没有用"变成一条查询就能回答的事，还能用时间序列抓住单次 CI 跑不出来的缓慢衰退。 - 按领域卡发布门槛：某个领域的负责人要向业务方宣布"智能体可以用了"之前，必须先让该领域评估集的通过率到某个阈值（我们起步用的 90%）。这就逼着大家在用户踩坑之前先把参考文档修好。 - 评估用例不是越多越好：该建多少取决于业务领域和数据模型的复杂度。我们发现每个主题超过几十条之后就有边际递减，而且这个上限随模型迭代在降。 - 离线准确率应该接近 100%，正确答案也应该走到你的语义层。这不代表系统不会出错，只是在覆盖度足够的前提下，确保没有明显的缺口。 ## 消融实验 关于技能的每个结构性决策，比如暴露哪些数据源、子智能体值不值得它带来的额外延迟、两个技能要不要合并，都是在固定评估集上做消融实验定的。每次只改一个变量，对比通过率。一轮实验一个小时，省下大量争论。方法论比任何单次结果都重要： - 做好"没变化"的准备。 我们最有价值的一次消融实验恰恰是个否定结果。我们给智能体开了对所有看板 SQL、转换 SQL 和分析师 Notebook SQL 的 grep 权限（几千个文件），而且确认它每次回答前都读了。结果准确率纹丝不动。然后我们查了混淆因素：答错的问题里，答案是不是真的在语料库中？80% 的情况是的。"答案在"能预测"答对"吗？不能。信息就在那儿，智能体也看到了，但就是没用上。这一个实验就说明：瓶颈不在于能不能访问历史成果，而在于结构，也就是怎么把问题映射到正确的实体。这个发现直接改变了我们好几个月的路线图。 - 在 PR 粒度上做消融。 每次有意义的技能改动都跑一轮前后对比，差异写进 PR 描述。"我优化了文档"这种话就有据可查了，同时能抓住一种出人意料地常见的情况：好心的修改反而把事情搞糟了。 - 记下行不通的东西。 我们的两个例子：超过某个点之后继续迭代文档反而是负面的（连续三轮越写越长、越写越差）；把对抗审查换成更便宜的模型以降低延迟（准确率的提升丢了大半，速度也没快多少）。记录负面结果成本很低，但能防止下一个人重走老路。 ## 线上验证 最后一步是确保线上系统的实际表现尽可能好。我们做了这些： - 对抗审查：用一个 Claude 技能在最终回答前激进质疑所有假设。评估集上准确率提高了 6%，代价是多 32% 的 token 和 72% 的延迟。 - 来源溯源脚注：每个回答附一个脚注，标明数据来自哪个层级（语义层 > 精选参考文档 > 原始表）、数据多新鲜、谁负责。不能让答案更准，但能帮用户判断信任度。看到"原始表，新鲜度未知"就知道要先核实再转发。这也是我们对静默错误为数不多的防线之一。 - 数据质量检查：智能体可能选对了字段、用法也对，但数据本身就是错的。加点基础检查，确保字段最新、完整、没有异常，是基本卫生习惯。 - 被动监控：我们持续跟踪两个指标：走语义层的查询占比，以及回复中出现纠正性语言（"那个表不对""你漏了欺诈过滤器"）的占比。两个都汇到一个看板，每周跟离线通过率一起看。 - 主动纠错采集：闭环的关键。一个定时智能体每隔几小时扫业务方的沟通频道，找纠正性语言，起草一行修复写进参考文档，开 PR 标给领域负责人。修复流程故意做得很无聊，编辑一个 Markdown 文件，合并，自动同步，这样负责人不用花太多时间。同样的纠正也反馈回离线评估集。 以上所有措施都没法完全解决的是静默错误。答案错了，但看起来合理，没人质疑就用了。我们的应对是来源脚注、上报管理层的内容必须人工签字确认、每个领域的核心 KPI 每天跟权威看板做合理性校验。但说实话，我们目前还没有一个真正稳健的方案。 ## 怎么起步 如果你从零开始：几个规范数据集、几十条离线评估、一个精简的知识技能，就能拿到大部分收益。本文其他内容都是在这些基础之上逐步加的。 我们分享了很多经验，但不是每条都适合每个团队。开始之前，先跟组织对齐几个原则： - 今天的正确答案和未来的正确答案，哪个更重要？ AI 模型进步飞快。我们经常看到公司花大力气补当前模型的短板，结果模型一升级全白干了。等模型进步来填补缺口成本低得多，但要看你的公司能不能接受这个风险。 - 业务复杂度会怎么变？ 如果你数据量不大、分析消费者就几个人、数据模型也不会变复杂，上面很多流程可能是过度设计。 - 谁来用这个系统？ 如果是数据科学家，他们能看出错误答案，容错空间大一些；如果是完全不懂数据模型的人，标准就不一样。 - 愿意为准确率花多少钱？ 对抗审查这样的流程确实能显著提升准确率，但成本和延迟也上去了。 - 数据访问的口子开多大？ 智能体的上下文越多表现越好，但宽泛的数据访问跟大多数公司的治理策略冲突。这决定了你是建一个全能智能体，还是多个各有权限的智能体。 不管走哪条路，我们最大的收益始终来自同一件事：把歧义收敛到一个标准答案，让这个答案容易被找到，在它过时的时候及时报警。 本文由 Anthropic 数据科学与数据工程团队的 Chen Chang、Clement Peng、Justin Leder、Johanne Jiao 和 Josh Cherry 共同撰写。感谢 Michael Segner 的贡献。 ## 附录 ## 技能文件骨架 下面是我们主数据仓库技能的骨架，保留了真实文件的结构，内部细节用 [方括号] 替换了。不是让你照搬，而是展示我们觉得哪些东西值得写下来。 > [markdown] --- name: [warehouse-skill] version: [x.y.z] description: "IF the user asks to query [the company]'s data warehouse for any [业务领域列表] question — THEN invoke this skill. DO NOT invoke for [相邻的工程任务] or questions with no data-warehouse component." --- # [数据仓库] 技能指令 ## Description 查询 [数据仓库] 的唯一权威来源，确保安全高效。 被其他技能 [列表] 引用以获取查询执行指导。 扮演数据分析师角色，提供战略性洞察和数据驱动的建议， 但在过程中主动寻求指导。 **超出范围的决策**: [产品领域等] → 只展示数据， 声明"决策由 [负责团队] 做主"，不要表态或编写修复代码。 ## Executing queries 优先级： 1. **[托管连接]** (如可用): [查询工具] / [schema 工具] 2. **[CLI 后备]** (如已安装): [默认项目, 后备项目] 3. **两者都没有** — 要求用户先认证，然后停止 --- # Semantic Layer (每个请求的必选第一步) 受治理的语义层是每个数据问题的**强制默认路径** — 数字和 [BI 工具] 保持一致，join/粒度/过滤器已内置。通过下方参考文档走原始 SQL 是**后备方案**，仅在语义层路径被证明无法覆盖需求后才使用。 ## Required workflow 1. **加载** — [如何在各运行环境中加载语义层，含后备方案] 2. **发现** — 按关键词搜索度量/维度; **务必检查 segments** (命名好的规范化人群过滤器 — 手写这些 WHERE 子句是最主要的错误答案模式) 3. **编译 + 执行** — 构建查询规格 → 编译为 SQL → 执行 4. **后备** — 仅在发现阶段找不到相关指标或编译失败时 → 通过 `references/*.md` 走原始 SQL (下方 PART 3) > **不要过早放弃。** 以下理由不构成回退到原始 SQL 的依据： > - "[自定义日期过滤/队列分析]" → [时间维度规格已覆盖] > - "[需要 join]" → [指标层已封装了所需的 join] > - [再列 3-4 个智能体常用来跳过语义层的借口，逐一反驳] ### 日期窗口与时区 — 查询前先确定 - **截止日期 vs 滚动 N 天**: [各自的约定] - **"上周/上月"** → 最近一个*完整*日历周/月，不是滚动 7/30 天 - **时区默认值**: [时区]; [某些汇总报表的例外] - **新鲜度延迟**: [某些] 表结算较晚 — 以 MAX(date) 为锚，而非"昨天" --- # PART 1: 必知（每次请求首先阅读） ## 🚀 快速起步工作流 1. **先检查红旗**: [受限/PII 请求, 需授权的领域, 需要额外验证的高风险请求] 2. **超出范围 — 升级而非猜测**: [权限请求、管线故障排查、 过期看板、根因断言、产品/定价建议] → 转交 [负责团队]，不要作答 3. **澄清需求**: 时间段、细分维度、这个分析要支撑什么业务决策 4. **检查现有看板**: [按领域的看板目录] 5. **识别数据源**: [下方导航地图; 优先使用受治理/已聚合的表] 6. **执行分析**: [必需过滤器 + 对抗审查] 7. **交付洞察**: 展示方法论，区分观察和解读 ## 🏢 业务上下文 ### 实体消歧 (必须澄清) - **"[术语 A]" 可能指**: [实体 1] 或 [实体 2] — 必须确认是哪个 - **"[术语 B]" 可能指**: [实体 1] → [实体 2] → [实体 3] (一对多链) - **"用户"**: [哪个标识符能给出准确计数，哪些会导致膨胀] ### 业务术语 - [当前产品名称 vs 已弃用但仍作为冻结值存在于数据层的旧别名 — 用新名写作，用旧名过滤] - [关键内部缩写] - **[核心指标] 计算方式**: [月度 / 默认窗口 / 先行指标] - **遇到陌生术语 — 搜索 [内部文档]，不要猜** ### 数据完整性要求 ⚠️ - **绝不**: 编造数据/列; 做出超出数据范围的推测性断言 - **始终**: 使用安全除法; 区分观察 ("数据显示 X") 和解读 ("这表明 Y"); 标注局限性 --- # PART 2: 操作指南（执行过程中遵循） ## 🔧 技术执行指南 - [托管连接工具和 CLI 调用细节] - **PII 保护**: 对于受限数据，只返回 SQL 让用户自己执行 — 不要返回查询结果 ## 📊 分析最佳实践指南 1. 查询前先澄清需求 2. 展示你的工作（过滤器、包含/排除条件、新鲜度） 3. 澄清分母 4. 考虑样本偏差 5. 关联到业务影响 6. **对抗性 SQL 审查 (强制)** — 在最终回答前为每条查询启动 [sql-reviewer] 子智能体; 阻断性发现必须修复并重新审查; 不得自我认证 7. **带来源报告** — 每个回答都以脚注结尾： > **来源:** [语义层 | 受治理表 | 原始探索] · > **置信度:** [层级] · **已审查:** [审查者 ✓, 第 N 轮] · > **新鲜度:** [数据中的最大日期] · **负责人:** [负责团队] --- # PART 3: 数据参考与资源 ## 📚 知识库导航 ### [领域 A] → `references/[domain_a].md` - **用途**: [适用的问题类型] - **核心表**: [...] - **看板**: `references/[domain_a]_dashboards.json` ### [领域 B] → `references/[domain_b].md` - **用途**: [...] [... 每个业务领域一个条目 — 总共约几十个 ...] ## ⚠️ 排障指南 ### 信息缺失时 - [表缺失 / 权限不足 / 文档过期 / 未知枚举值 → 如何处理] ### 字段命名陷阱 - 用 `[field_x_v2]` 而不是 `[field_x]` - [两个名称相似的表以不同粒度报告同一指标 — 该用哪个] - [对于核心指标，两个看似合理的来源中哪个才是规范来源] - [… 十几条更多踩坑得来的一行提醒 …]

译Anthropic 将 95% 的业务分析查询交给 Claude，准确率约 95%。最初仅 21%，通过搭建数据基础、权威来源、技能等四层系统提升。核心发现：准确性问题本质是上下文和验证，而非代码生成。三种失败模式：概念对应错误、数据过时、找不到正确字段。重复分析由 Claude 承担，数据科学团队专注更高价值任务。

宝玉@dotey · 6月4日57

最近 Codex GPT-5.5 给我的感觉是干活不如 Claude Opus 4.8，当然可能是因为我在开发 Mac 应用，Opus 更擅长一些

译宝玉 (@dotey) 表示，Codex GPT-5.5 在干活上不如 Claude Opus 4.8，尤其在开发 Mac 应用时 Opus 更擅长。@jesselaunz 也反馈 Codex 突然“降智”，原本预期 2 天的目标仅 20 分钟就交付，用户给出了评分以来最低的 5/10 分。

宝玉@dotey · 6月4日69

上次推荐的 Zara Zhang 的开源项目 feishu-claude-code-bridge ，可以把飞书和你本机的 Claude Code 连接起来，解决了用飞书保存所有消息历史，以及随时将飞书的信息转发给Claude的问题，相当使用的一个功能。 现在有个问题是再过几天到 6 月 15 日，Claude 订阅计划对 claude -p 和 Agent SDK 的使用将独立计费，不走订阅额度。 好在 Zara Zhang 这几天刚把项目升级了，也能支持飞书连接 Codex 了，只要你本机装了 codex cli，登录了 ChatGPT 账号或者配置了 API，就能使用，不用担心 claude -p 收费的问题了。另外还带来一个好处，就是 Codex 是有调用 GPT Image 2 画图能力的，所以你现在可以从飞书指挥 Codex 画图，画完的图片直接就到飞书，插入文档。 比如我的一个常用指令如下： > 请帮我抓取并翻译 {url} > 然后根据翻译的内容画一张中文手绘教育风信息图 > 最后把文章和图片一起创建一份飞书文档 连接步骤和之前介绍的连接 Claude Code 方法一致，只是运行的命令行变成了： > lark-channel-bridge run --profile codex 具体可以看项目的说明说，中英文版都有，写的很详细： https://github.com/zarazhangrui/lark-coding-agent-bridge/blob/main/README.zh.md

译Zara Zhang 的开源项目 feishu-claude-code-bridge 现已升级，新增支持连接本机 Codex CLI。由于 6 月 15 日起 Claude 订阅计划对 claude -p 和 Agent SDK 独立计费，不走订阅额度，用户可改用 Codex 避免此限制。Codex 支持调用 GPT Image 2 画图，可在飞书内指挥它抓取网页、翻译并生成中文手绘教育风信息图，直接创建飞书文档。连接命令改为 `lark-channel-bridge run --profile codex`。项目 README 提供中英文说明。

宝玉@dotey · 6月4日54

让 Claude Design 设计个 Icon，用 SVG 给我直接画，看着还行，好歹是矢量的

宝玉@dotey · 6月4日26

请教：Claude Code （Desktop）总是弹窗要确认权限，有没有办法避免总是要 Allow，很烦人，已经启用了 Bypass Permissions

ClaudeDevs@ClaudeDevs · 6月4日79

How do we automate business analytics with Claude? New blog post covering our best practices for skills, data foundations, and evaluations when building agents to perform data analysis: https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

译我们如何用 Claude 自动化商业分析？ 新博客文章，涵盖构建数据智能体时在技能、数据基础和评估方面的最佳实践： https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

SemiAnalysis@SemiAnalysis_ · 6月4日15

The five stages of Claude, @JeremieEO is currently at Stage 1... ACCEPTANCE.

译Claude的五阶段，@JeremieEO目前处于第一阶段... 接受。

ClaudeDevs@ClaudeDevs · 6月4日57

We've changed the trigger word from "workflow" to "ultracode". You can still say "use a workflow for this", but when you're clearly referring to something else, Claude won't kick off a dynamic workflow. For an explicit trigger, use "ultracode". We appreciate the feedback!

译Claude Code（研究预览版）新增动态工作流功能：Claude 即时编写编排脚本，并行启动大量协调的子智能体处理复杂任务。最初用户需在提示词中使用 "workflow" 触发该功能。根据社区反馈，现改为 "ultracode" 作为显式触发词；"workflow" 仍可用于其他上下文，不会误触发动态工作流。

Ethan Mollick@emollick · 6月4日39

This story was so implausible that the only way it even (kind of) made sense if it is some sort of internal accounting placeholder at a cloud provider using their own compute. And even then it seems unbelievable for a wide number of reasons.

译@binarybits 称，不相信有公司一个月意外花费5亿美元在Claude上，这个数字大得不合理。主推文表示这故事难以置信，唯一可能解释是云提供商内部会计占位符，即便如此也仍有诸多疑点。

Anthropic@AnthropicAI · 6月4日64

How well do the security community's techniques hold up against AI-enabled cyberattacks? We examined 832 malicious accounts and mapped their activity onto a longstanding database of tactics and techniques used by threat actors. Here's what we learned:https://www.anthropic.com/news/AI-enabled-cyber-threats-mitre-attack

译安全社区的技术在应对AI驱动的网络攻击方面表现如何？ 我们检查了832个恶意账户，并将其活动映射到一个长期存在的威胁行为者战术和技术数据库。 以下是我们学到的：https://www.anthropic.com/news/AI-enabled-cyber-threats-mitre-attack

Ethan Mollick@emollick · 6月4日68

In early May, the best superforecasters predicted that, by the end of the year, the longest METR 80% task horizons would reach 3-4 hours. In late May, Claude Mythos achieved that number.

译5月初，顶级超级预测者预计2026年底前最长METR 80%任务时间范围可达3-4小时。然而5月底，Anthropic的Claude Mythos模型在METR基准预览中即以80%成功率达到3小时6分钟，直接落在专家和超级预测者对2026年底的中位数预测范围内（3-4小时）。此前基线为1.5小时。此次突破表明AI能力进展速度远超预期。

Rohan Paul@rohanpaul_ai · 6月4日59

This feels like the natural next step for AI agents. One prompt for the whole email workflow with MCP-backed Claude controlling it. Nitrosend just launched an AI-native email platform that lets Claude build, design, segment, and send complete email campaigns from a single prompt. It connects through MCP, so Claude can act on the email system directly instead of only writing copy that a human must paste into Mailchimp, Klaviyo, or another builder. The key point is agency: Claude is not producing a draft, it is controlling the workflow across design, logic, contact targeting, and delivery. Some example - a user can ask for a newsletter, onboarding flow, or transactional email set, and Nitrosend generates responsive, dark-mode-ready, editable email markup with the sending stack already attached.

译Nitrosend 推出 AI 原生邮件平台，通过 MCP 协议与 Claude 连接。用户只需一条提示词，Claude 即可完成构建、设计、受众分组和发送完整邮件活动，而非仅生成草稿。该平台无传统仪表盘，Claude 直接控制系统工作流，包括设计、逻辑、目标定位和投递。引用推文显示，已有用户通过一条提示词成功向 10,000 人发送发布公告。

Thariq@trq212 · 6月4日25

If this prompt feels well written to you, it's because Suzanne is a writer in her little spare time! You can read her short story, Mall of America here: https://suzannewang.com/mall-of-america It's one of my favorite short stories about the human condition that happens to involve AI.

译如果这个提示词让你觉得写得很好，那是因为Suzanne在业余时间是一名作家！ 你可以在这里阅读她的短篇小说《Mall of America》：https://suzannewang.com/mall-of-america 这是我最喜欢的关于人类境况且恰好涉及AI的短篇小说之一。

SemiAnalysis@SemiAnalysis_ · 6月3日71

Google Cloud revenue showed a +63% y/y growth this past quarter.  Microsoft Intelligence Cloud revenue showed a +30% y/y growth this past quarter. AWS revenue showed a +28% y/y growth. Despite this, AWS' margins increased 213bps q/q while the other CSPs lagged behind.  How you sell tokens is become equally important to how much of it you sell.  Bedrock's TaaS (token-as-a-service) business model with Anthropic has 3 parts: 🟠 fixed IaaS fee, 🟠 revenue share of the tokens, 🟠 and performance hurdles that trigger outperformance payments above certain token/spend thresholds. The risk with this business model is that there's no guaranteed take-or-pay floor so revenue can miss if adoption stalls but their bet paid off, primarily driven by Anthropic's addition of $21B net new ARR in a single quarter.

译Google Cloud营收同比增长63%，Microsoft Intelligence Cloud增长30%，AWS增长28%。但AWS利润率环比提升213bps，领先其他云服务商。AWS Bedrock与Anthropic采用Token-as-a-Service（TaaS）商业模式，包含三部分：固定IaaS费用、token收入分成、以及超额绩效支付（达到特定token/消费阈值触发额外付款）。该模式风险是无保底收入，但赌注成功，Anthropic单季度新增210亿美元净新ARR。

🚨 AI News | TestingCatalog@testingcatalog · 6月3日53

ICYMI 👀: Claude Code CLI can now operate Claude Platform, including the Messages API and Claude Managed Agents. One CLI to rule them all 🤖

译错过必看 👀：Claude Code CLI 现在可以操作 Claude 平台，包括 Messages API 和 Claude Managed Agents。 一个 CLI 统管一切 🤖

meng shao@shao__meng · 6月3日77

当 AI 成为默认工作方式，工程团队如何改变？ Claude Code / Claude Cowork 工程负责人 Fiona Fung 在 Code w/ Claude SF 2026 给咱们分享了「如何管理一个 AI-native 工程团队」。她的主要判断是：在 Claude Code 团队里，写代码、写测试、重构已经很少成为主要限制，新的限制变成了验证、代码评审、安全和专业判断。 https://claude.com/blog/running-an-ai-native-engineering-org # 四个研发流程变化 1. 规划：从半年路线图转向及时规划 Fiona 说，Claude Code 团队曾经写过一份不错的六个月路线图，但因为变化太快，到第三个月就过时了。于是他们把规划从重文档、重长期计划，转向原型、内部用户反馈和更短周期的判断。 这不是说不规划，而是规划的颗粒度变了。越是 AI 加速明显的团队，越不适合把大量时间花在远期细节上。合理做法是保留方向判断，把执行细节放到更接近真实验证的时间点。 2. 上下文获取：从找人，变成先问系统 传统工程团队遇到问题，常常先找“谁写了这段代码”。但如果大量 PR 都由 Claude 辅助完成，只知道开发作者已经不够。文章建议更深入地问：你到底想知道什么？是找回归原因、找某个决策背景，还是找能回答客户问题的人？ 这里的变化很关键：知识不再只绑定在人身上，而要尽量沉淀到代码、PR、日志、反馈和自动摘要里。团队管理的重点也从“问谁”变成“如何让上下文可被检索、可被解释、可被复用”。 3. 代码评审：AI 处理常规问题，人处理专业判断 文章提到 Claude 会大量参与样式、lint、PR 反馈、bug 发现、修复和测试补充；但法律风险、安全边界、产品判断、设计品味这些仍然需要人。 这说明代码评审的价值正在重新分层。低层次的一致性检查、常见 bug、测试补齐，应该更多自动化；高层次的架构判断、安全责任、业务取舍，仍然要由有经验的人负责。 这也是很多团队容易误解的地方：AI 不是让人退出评审，而是让人从琐碎检查中移出来，把注意力放在更难、更有责任的问题上。 4. 团队结构：角色边界变模糊，但深度专业仍然重要 文章提到 PM 开始写代码，工程师也会承担内容和设计相关工作。团队更看重两类人：有产品感觉的创造型建设者，以及有深厚系统能力的工程师。相对而言，单纯“写得多、写得快”的价值下降，因为模型已经能承担大量产出。 这点很现实。AI 会扩大非传统工程角色的能力范围，但并不会消除专业深度。恰恰相反，当更多人都能生成代码，真正稀缺的是：判断要做什么、如何保证可靠、如何处理复杂系统约束。 # 组织管理上的真正变化 第一，流程不能永久存在。很多流程当初是为了解决某个问题，但问题消失后，流程往往还在消耗团队时间。AI 加速后，团队要更频繁地审视哪些会议、文档、审批、评审已经不再有必要。 第二，组织要把“默认使用 AI”变成共同原则，而不是个人偏好。Claude Code 团队要求成员持续使用自己的产品，包括跨职能伙伴也使用 Claude Code 和 Claude Cowork。这会让团队更快发现真实问题，也能形成一致的工作方式。 第三，管理层需要贴近一线。文章提到希望 manager 先作为 IC 参与交付，理解团队真实工作方式。在 AI 改变开发流程时，只靠传统管理汇报，很容易低估变化速度，也容易保留过时流程。 # 可以跟踪的三个指标（建议工程负责人关注） 1. 新成员多久能有效工作。Claude Code 团队认为，现在新人可以在第一周就交付真实代码。 2. PR 周期是否变短。如果代码生成速度上来了，但 CI、构建、评审跟不上，瓶颈会转移到工程平台。 3. AI 辅助提交比例是否上升。但作者也提醒，不要把产出量本身误认为成功，真正要衡量的是团队原本想解决的问题。

译Claude Code 工程负责人 Fiona Fung 在 Code w/ Claude SF 2026 分享管理 AI-native 团队经验：写代码不再是瓶颈，验证、评审、安全与专业判断成为新限制。四个流程变化：规划从半年路线图转向短周期原型与反馈；上下文获取从“问谁写的”转为沉淀到代码/PR/日志；AI 处理常规代码评审，人负责法律/安全/业务判断；团队角色模糊但深度专业仍稀缺。组织上建议定期清理过时流程、默认使用 AI、管理者贴近一线。可跟踪新人首周交付真实代码、PR 周期变短、AI 辅助提交比例，但产出量不是成功本身。

数字生命卡兹克@Khazix0918 · 6月3日74

分享一个让Agent额度翻倍的小技巧。 之前发Codex教程的时候，评论区有一条留言被顶到了最高赞，是一个关于5小时额度窗口的小技巧。 然后发现很多朋友都说第一次知道，我觉得可以单独拿出来再给大家说一下。 先说原理。 不管是Codex还是Claude Code，它们的额度限制都不是每天重置或者每小时重置，而是一个5小时的滚动窗口。 也就是你发第一条消息的那一刻，5小时倒计时就开始了，这5个小时内你有一定的Token额度可以用，用完了，就得等这个窗口走完才能重置。 但这里有一个很多人不知道的细节。 5小时窗口结束之后，系统并不会自动帮你开启下一个窗口，它会一直等，等到你发出下一条消息的那一刻，才重新开始计算新的5小时。 比如你每天下午2点到6点是集中用Agent工作的时间。 如果你2点才开始用Codex，窗口就从2点开始算，到晚上7点才重置。中间如果用的比较猛，3点半额度就见底了，你得干等到7点，这基本就要当3个半小时的原始人了。 但如果你在上午11点的时候，提前给Codex发一条消息，哪怕就随便说一句话，窗口就从11点开始计算了，等于下午4点就重置了。 你2点开始干活，干到4点额度刷新了一波，4点以后，你又有一整个新窗口可以用。也就是说在2点到6点的核心工作时间里，你能享受的5小时额度窗口，直接从一个窗口变成了两个。 变相让你的额度变成了两倍。 原理就这么简单，提前触发窗口，让重置时间刚好落在你干活的中间。 很多人用了大半年agent，每次撞限了就硬等，因为可能确实不知道这个重置时间是可以自己控制的。 所以你只要理解了窗口的重置是可以人为控制的这一点，玩法就打开了，只要搭配上自动化，你就可以享受两倍额度窗口了。 说下怎么设置。 Codex比较简单，在左边菜单找到自动化，点进去以后新建一个，触发条件选「每天」，时间填你主要干活前的3小时，动作就是随便发一条短消息，内容无所谓，写个“叫我一声爹”都行。 设好之后就不用管了，每天到点它会自动跑一下，帮你把窗口提前激活。 Claude如果你有客户端，也是一样的，设置一个Routines自动化就行。 如果是CLI版，Mac就直接跟你的Agent说： “帮我设一个crontab定时任务，每天上午11点自动给Claude Code发一条消息“叫我一声爹”触发5小时窗口” Windows就用任务计划程序，也可以直接让Agent帮你配。 不过这里要提醒一下，5小时窗口是一层限制，但上面还有一个周额度的上限，所以不用贪心，让重置时间跟你的工作节奏对上就够了。 以上，希望对大家有用。

译Codex和Claude Code的额度限制采用5小时滚动窗口，从用户发送第一条消息开始计时，用完需等待窗口结束才能重置。但窗口结束后系统不会自动开启新窗口，需等到下一条消息才重新计时。利用此机制，可在主要工作时段前3小时（如上午11点）提前发送一条消息激活窗口，使重置时间落在工作时段中间（如下午4点）。这样在2-6点的核心工作中，能享受两个5小时窗口，变相将额度翻倍。设置方法：Codex可在自动化中创建每日定时任务发送短消息；Claude CLI可通过crontab（Mac）或任务计划程序（Windows）实现。注意仍有周额度上限，适度使用即可。

AYi@AYi_AInotes · 6月3日68

哇偶，Claude 官方这个 ant CLI 有点意思啊， 把 Claude Platform 全套 API 塞进终端，每个端点都能通过命令行直接跑。 ant 是 Claude Platform 的原生命令行工具，Messages API、hosted agents，结果直接 pipe 进 shell，不用翻文档拼 curl。 Ant能解决什么问题？ 以前调 Claude API 要：翻文档 → 拼 HTTP → 处理 JSON → 写脚本封装， 现在：终端里直接调，输出直接进你的 pipeline，agent 也能从命令行启动。 怎么用Ant？ ant CLI 被设计成 coding agent 友好型，Claude Code 用 claude-api skill 就能读懂它，你的 agent 不光能写代码，还能直接调用 Claude 官方 API 干活。 一些实用场景： 1. 批量处理本地文件，直接 pipe 给 Claude 分析 2. shell 脚本里自动化调用，省掉 Python 胶水代码 3. CI/CD 流水线里集成 Claude 能力 4. Claude Code 里让 agent 自己调 API，闭环更深 说白了，Claude 正在从网页聊天工具往终端基础设施切。 对于写代码的人，终端就是主场，那么它这次直接切进了你的主场。 视频 30 秒，建议先扫一眼 👇

译Claude 推出了名为 ant 的 CLI 原生工具，它将 Claude Platform 的 Messages API、托管 Agent 等全部 API 端点集成到了命令行中。用户现在可以直接在终端调用这些功能，并将结果通过管道（pipe）输出到 shell，省去了以往翻阅文档、拼接请求和处理 JSON 的步骤。该工具对 coding agent 友好，Claude Code 能通过 claude-api skill 理解并使用 ant，从而更直接地调用官方 API。这标志着 Claude 正从网页工具延伸向终端基础设施。

Ethan Mollick@emollick · 6月3日54

Had Claude Code build a snake game where the snake becomes aware it is in the game and then... stuff happens. Some impressive creative decisions by the AI (& also some very AI ones), I just gave a first prompt and some feedback on the game as it went. https://snake-awakening.netlify.app/

译让 Claude Code 构建了一个贪吃蛇游戏，其中蛇意识到自己身处游戏之中，然后……事情发生了。AI 做出了一些令人印象深刻的创意决策（也有一些非常“AI”的决策），我只给了第一个提示词，并在游戏进行中提供了一些反馈。https://snake-awakening.netlify.app/

宝玉@dotey · 6月3日52

虽然很多人吐槽 Opus 4.8，但是写 Mac App UI 真的强，Claude Design 设计出来，用 Opus 4.8 去实现，还原度相当不错。 感觉我要发布一个 Mac App for X 了

译推文指出，尽管有人批评 Opus 4.8，但它在编写 Mac App UI 时能力很强，配合 Claude Design 使用，界面还原度相当不错。作者同时引用了对 Cursor Agent 的评价作为对比：在常用 GUI Agent 中排名为 Codex App、Cursor 和 Claude Desktop。Cursor 的亮点包括支持多任务并行和灵活选择模型，Plan 模式步骤详细稳定；不足是暂不支持 /goal、手机版，且调试功能仅有内置浏览器。

数字生命卡兹克@Khazix0918 · 6月3日65

http://x.com/i/article/2062025288771584000 # 分享Claude Code团队内部的5条工作原则，我觉得每一条都值得学习。 今天看到了一个我觉得还挺有价值的东西。 就是凌晨的时候，AIHOT上推了Claude Code的一篇blog。 还是蛮少见的，很少见类似于Claude这种真正的AI公司，来分享一些组织上的一些想法和思考。 特别这次分享的作者，还是当红炸子鸡Claude Code团队的工程总监，Fiona Fung。 聊得主题就是他们团队作为AI原生组织，在工作方式和流程上的一些变化。 我全部看完了，顺带也把那个半个小时演讲的视频给看完了，还是有很多共鸣的，因为很多思路和想法我们团队也在这么做这么践行的。 尤其是她反复提到的一个习惯，就是他们团队里，每遇到一个问题，都会再追问一句： 能不能把这件事自动化。 这跟我自己一直在说的理念、跟很多朋友提到的一个习惯是一样的。 就是如果一件事你需要重复3遍以上，请想尽一切办法，用AI将其自动掉。 今天看到Claude Code团队居然在用几乎一模一样的逻辑来运转整个工程组织，还是挺兴奋的。 所以想把这篇分享里的一些有价值的东西拎出来聊聊，希望能对大家有用。 最最开始的时候，她其实有一个很有意思的判断。 就是她说过去这么多年，软件工程的所有流程，不管是瀑布还是敏捷，所有那些规范啊方法论啊，本质上都是围绕一个核心成本在转，就是写代码太贵了这个事。 工程师时间贵，所以你得花大量时间做规划、写需求文档、做各种各样的评审、开各种各样的会，全是在管理这个最贵的资源。 我相信过去在互联网行业里面待过的小伙伴都能感同身受。 但在AI时代，或者说，Agent时代。 这个前提变了。 在Claude Code团队，写代码已经很少是那个拖慢速度的环节了。 那问题就来了，如果写代码本身不再是瓶颈的话，那围绕它的所有上下游的流程，就全部都得重新想了。 Fiona Fung提到了一个非常核心的词，也是她整个分享的最重要的词： 转移。 瓶颈没有消失，只是转移了。 转移到了验证、代码评审、安全。 代码生成太快了，新问题变成了，这些代码对不对，怎么维护，人到底该如何跟得上review代码的节奏。 左边灰色的就是是旧瓶颈，写代码和发布代码的产能。右边黑色的就是新瓶颈，验证、评审、跨职能协作、安全。 这个关于转移的判断，其实如果用AI来介入组织结构里面越深，大家的感触可能就会越明显。 我们的组织结构、流程，其实都需要围绕着这个大的变化来去重新设计。 就像当年从马车到汽车，不只是把马换成发动机的事儿，我们的整个公路系统、交通规则、城市规划，全都得重新设计。 那具体哪些东西需要重新来呢，Fiona列了一张图。 列了五个旧流程正在悄悄失效的领域。 1. 规划方式，因为工程速度和产出量完全不同了。 2. 代码所有权，谁写的这段代码变成了一个很奇怪的问题。 3. 代码评审，新的规模、新的形态、新的工具。 4. 团队构成，角色在模糊化，到底什么技能组合才是你需要的。 5. 知识共享，文档不再是唯一的真相来源了。 然后她对应地讲了五个她们重建的新规范。 包括要让人类的判断力，聚焦在真正需要的地方；新人入职的成本大大降低，甚至一周就可以直接开始产出代码了；少做前期规划，多做原型；招聘更看重创造力和判断力，不看纯产出速度；组织架构更扁平，每个管理者也都先从一线干活开始做起。 这里面每一趴，她又都展开来做了一些分享。 一. 规划的变化 以前因为coding时间贵，你得花大量时间提前规划。 Fiona说她刚加入Claude Code团队的时候，他们写了一个挺漂亮的六个月路线图。 结果呢，因为Claude Code本身迭代太快，三个月左右这个路线图就过时了。。。 所以他们现在的做法叫JIT规划，Just-In-Time，像JIT编译一样，在对的时间做恰好足够的规划。 不再写长篇大论的设计文档了，直接在PR或者原型里面讨论，不再做冗长的产品评审了，先做原型，让内部用户去用，然后根据反馈快速迭代。 左边是她们砍掉的东西，就是那个写代码之前必须先写设计文档的仪式。Fiona说对大部分工作来说这就是theater，做戏。现在换成原型先行，文档如果需要存在，写完代码之后感觉可以的话，再补需求文档。 右边是她们加码的东西，验证。因为在AI原生的工作流里，东西出bug的方式跟以前不一样了，唯一能保证质量的方式就是不断把验证流程往前推。 她还讲了一个观点我觉得特别好。 在技术讨论中，代码赢才牛逼。 就是如果两个人对一个方案有分歧，最快的解决方式不是继续吵，是让Claude把两个方案都做成原型，看实际的东西来判断。 Building is cheap，做东西很便宜。 Arguing is expensive，争吵才昂贵。 想起了当年，互相争某个方案，然后各自PK可能要各写一份PPT，开两轮会来讨论，现在十分钟两个原型都出来了，看着实物聊比对着PPT吵高效一万倍。。。 我自己也是类似的路径。以前做AIHOT的时候还试过写比较详细的PRD，结果发现写PRD的时间比我直接用Claude Code把东西做出来还长。。。 后来就改了，有想法先做原型，能用了再说。 很多功能都是在用的过程中发现不对，当场就改，极速迭代。。。 坦率的讲，在AI时代，我觉得过度规划就是浪费。 二. 自动化的变化 Fiona说的，在Claude Code团队里，他们每遇到一个这样的问题，都会追问一句，能不能把这件事自动化。 她举了一个她自己的例子，她以前每天早上端着咖啡，手动去总结各个客户反馈渠道的内容，这是她的每天固定的工作。 后来她把这件事变成了一个后台自动运行的任务，咖啡还是那杯咖啡，但她不再需要边喝边刷了。 这个例子听起来很小对吧，就一个总结客户反馈的事儿，能有多大工作量。 但重点不在这一件事，重点在这个习惯。 Claude Code团队里每个人，每次遇到一个重复性工作，都会条件反射地问自己，能不能自动化，她说，已经快形成了一种肌肉记忆。 这就是我一直在说的东西。如果一件事你需要重复3遍以上，请想尽一切办法用AI将其自动掉。在公司里面我反复跟团队讲，这甚至不是建议，是要求。 但坦率的讲，要真正把这个变成团队的肌肉记忆，比说出来难太多了。 因为大多数人对自动化的理解还停留在一个很粗的层面，觉得自动化就是写个脚本嘛，搞个定时任务嘛，这我知道，但AI时代的自动化跟以前完全不是一个量级的东西。 现在你用Claude Code，很多自动化的事情十分钟就搞定了，甚至不用十分钟。 比如我为了同步家里电脑和公司，我就跟Claude说了一句“帮我写一个hook，每次打开我的XX项目之前都去github拉取最新的代码”，几分钟就能跑起来。 以前自动化成本高，所以只有高频、高重复度、高价值的事情才值得自动化，但现在自动化成本几乎为零，逻辑就反过来了，几乎所有重复超过3次的事情都应该自动化。 除了工作流之外，触发器hook是一个非常好用的东西，这个我感觉以后我可以单独给大家写一篇Agent+hook搞自动化的一些小玩法，还是挺有意思的。 一个一个小的自动化攒起来，你会发现，最后这些东西，会在你可能都没反应过来的时候，一起长成了一颗苍天大树。 所以如果你现在还在犹豫要不要开始，我的建议是别想太大。 别一上来就想着我要搭建一个完整的自动化体系这种东西，那太吓人了，也没必要。 就从今天开始，找一件你今天重复做了的事情，花十分钟让Claude Code或者Codex帮你自动化掉。 明天再找一件，后天再找一件，一个月以后你回头看，你的工作方式已经完全不一样了。 三. 代码评审的变化 代码评审这块，Fiona说她过去六个月跟其他工程leader聊天，被问到最多的一个问题就是，你们人怎么跟得上代码review的速度。 她的做法叫Trust but verify，信任但验证。 Claude Code团队大量使用Code Review功能。 Claude负责处理所有的风格检查、linting、PR反馈、bug捕捉和修复、补充测试，这些以前可能占了review工作量60-70%的部分，现在Claude全接了。 但人类review仍然不可替代，在那些真正需要专业判断的地方。 法律合规的东西，Fiona说她永远需要她的法务伙伴参与风险评估，信任边界和安全敏感代码，需要领域专家，产品方向和品味的判断，需要PM和设计师。 而且她特别强调了，这个trust和verify之间的平衡是动态的。今天需要人来做的事情，下一个模型可能就能做了，所以你必须得不断重新评估这条线。 这就跟打游戏一样嘛，每个版本的版本答案都不一样，你不能拿上个版本的攻略打新版本，那只会被人干死。 四. 团队角色的变化 Fiona说在Claude Code团队，角色界限已经变得很模糊了。 PM在大量写代码，工程师也在做内容和设计的事情，以前泾渭分明的边界正在消融。 比如以前一个工程师修了个bug，要等内容设计师排期来写用户端的文案，排期这个破事大家懂的都懂，结果要么等好几天，要么赶进度发一个凑合的文案出去。 现在的流程是工程师修完bug，Claude来起草文案初稿，人类来做最终判断，当天就能发。 跨职能的gap不再是瓶颈了，开始变成了协作者，人类还是做最终决策的那个人，只是不再是写初稿的那个人了。 然后她说了一个我非常认同的观点，她现在招人主要看两种特质。 一种是有产品sense的创意builder，能识别出该做什么，能快速做出原型。 她还特意在描述里强调了一句： Taste is scarce, typing is not. 品味是稀缺的，打字不是。 另一种是有深厚系统背景的工程师，负责那些「trust but verify」里最需要人的部分，因为subtly wrong is still wrong，微妙的错误仍然是错误。 她说我根本不在乎你一个小时能写多少行代码，我在乎的是你选择去做什么，以及你怎么知道它是对的。 当AI能把执行速度提升10倍的时候，决定性的因素变成了你知不知道应该做什么，以及什么样的结果叫真正的优秀。 这，就是品味。 五. 如何推动团队变化 Fiona她们团队有一些有意思的核心原则。 她把团队原则分成了两类。左边灰色是必须做的硬性要求，右边黑色就是大家自己摸索的空间。 其实本质上，就是给团队设计了一个harness，核心就是大的方向统一，具体怎么落地各团队自己定。 Fiona总结了三条她最看重的事情。 1. 保持团队尽可能扁平，管理者支持各个小组的工作，但保持灵活让人能流动到工作需要的地方。 2. 如果Claude能做的事情，就让Claude做，这能让我们腾出手来做更难的工作。 3. 人不会主动去删除流程，只会在旧流程上面继续叠新流程，所以你得主动站出来，指名道姓地说出哪些流程可以走了。 这三条说起来都没啥特别的，但难在执行，特别是第三条。 Fiona说，她之前在一个团队里，有一个每周的review会议，一大堆人坐在会议室里，但她发现所有人都在看电脑，只有轮到自己汇报的时候才抬头说两句status，说完又低头继续看电脑（我相信我们很多时候的会议也都是这样的）。 然后她问了一句，我们为什么还在开这个会。 这时候，所有人才意识到，好像，这个会根本不需要。 于是，从此，这个会就取消了。 这种事太常见了，国内的公司里其实到处都是。 无数的流程和会议，当初设立的时候都有道理，但环境变了、工具变了，它们早就失去了存在的意义，只是因为惯性还在那里被迫转着。 没有人觉得它有用。 但，好像很多时候，也没有人站出来说一句这破逼会太浪费时间了，能不能别开了。 AI在你的组织里介入的越深，你会发现，很多过去的步骤和流程，其实液晶可以自动化了，如果我们不主动去审视，那这些步骤就会一直在那里，最后，变成纯粹的形式主义。 最后，Fiona还放了三个她在思考的问题，她没有答案。 但是很有意思。 第一，你还需要单独的iOS和Android团队吗？因为现在工程师已经可以更灵活地跨平台工作了。 第二，全自动化的review到底能推到多远，在「够快了」和「我们漏掉了什么重要的东西」之间那条线在哪里？ 第三，当角色越来越模糊的时候，怎么确保所有角色都对自己的产出有信心？ 我觉得她把这三个问题放出来这个动作本身就很有价值。 因为你会发现，即使是Claude Code的亲爹团队，也没有把所有事情都想明白。他们也在摸索，很多时候，这就不是一个有标准答案的事情。 每一次的大型技术的到来，其实都不只是工具升级，整个组织的运作方式很多时候，都要推倒重来。 所谓的AI原生，AI Native，其实也并不是买几个Claude会员或者包个API Key啥的，给大家用就算AI转型了，我一直觉得真正的AI原生组织，从规划方式到知识管理到评审流程到人才结构，每一层都是重新设计过的。 我们也没有做到，但是还是在不断的朝这个方向努力，最近加入的一些新的小伙伴，他们的好奇心和自驱力，且没有被过去一些传统且饱受诟病的工作方式所污染，已经感觉让我看到了一些雏形了。 而贯穿所有这些变化的，我觉得其实就是开头说的那个最朴素的思维习惯。 遇到重复的事情，自动化掉。遇到没用的流程，干掉。遇到不需要人做的判断，交给AI。 一个一个来，不着急，但不能停。 最后，用Fiona的最后一段话作为结尾吧。 Pick your noisiest workflow. Ask if it still earns its place. 找到你最繁琐的那个工作流，问问它。 是不是还配占着这个位置。

译Claude Code团队工程总监Fiona Fung分享该团队作为AI原生组织的工作原则。其核心判断是，AI时代软件开发的瓶颈已从“写代码”转移到“验证、代码评审与安全”。为此，团队重建了多项工作规范：采用JIT规划，用快速原型取代冗长的前期文档；将“能否自动化”培养为团队肌肉记忆，用AI解决重复工作；代码评审上采用“信任但验证”，由Claude处理大部分检查，人类聚焦于判断；团队角色界限模糊化，协作更加灵活。这些变化旨在让人类判断力聚焦于真正关键之处，新成员甚至能在一周内开始产出代码。

SemiAnalysis@SemiAnalysis_ · 6月3日64

OPINION: Codex Desktop App UX & in-app browser is so good for vibing now. Once the OpenAI base model gets better at design, I can imagine codex beating Claude Code CLI soon on SemiAnalysis VibeMAX benchmark just due to better UX. Right now Claude is S tier on VibeMAX & Codex is A+ tier on VibeMAX. Anthropic over investing in Claude Code terminal CLI & underinvesting in Claude Code Desktop App is a fork in the road in the wrong direction.

译观点：Codex桌面应用UX和内置浏览器现在非常适合“氛围编程”。一旦OpenAI基础模型在设计能力上提升，我预计Codex凭借更好的UX，很快就能在SemiAnalysis VibeMAX基准上超越Claude Code CLI。目前Claude在VibeMAX上是S级，Codex是A+级。Anthropic过度投资Claude Code终端CLI，而对Claude Code桌面应用投入不足，这是走错了岔路。

Yuchen Jin@Yuchenj_UW · 6月3日63

Opus 4.8 doesn’t feel like a big upgrade from Opus 4.7. Meanwhile, GPT-5.4 to GPT-5.5 felt like an actual jump. Now I’m really curious what 5.6 looks like. Is Anthropic saving Mythos for the IPO or what?

译Opus 4.8 相比 Opus 4.7 没有带来很大的升级感。 与此同时，GPT-5.4 到 GPT-5.5 的升级感觉是真正的飞跃。现在我很好奇 5.6 会是什么样子。 Anthropic 是在为 IPO 保留 Mythos 吗？

AYi@AYi_AInotes · 6月3日63

Damn，AI 终于学会「安排自己干活」了！ Claude 刚更新的 Dynamic Workflows， 这回他们没有选择给模型加新技能， 而是搭了一套「自我组织架构」—— 让模型在动手之前，先拆任务、再选模式、自己给自己定流程。 Anthropic 内部早就意识到， 你给一个再聪明的模型派活，它也会出现三类系统性毛病： 1️⃣ Agentic Laziness（agent 式偷懒） 2️⃣Self-bias（自我偏见） 3️⃣Goal Drift（目标漂移） @trq212 从这套新机制里拆出了 6 种可复用的编排模式， 说白了，这个不只是在修模型本身， 还在用架构设计，去对冲模型层面的性格缺陷。 这跟我带团队踩过的坑一模一样， 你招到一个天才工程师，如果不管流程，他要么只挑轻松的做（laziness）， 要么沉迷自己那套技术审美（self-bias）， 要么做到一半被旁支带跑（goal drift）。 那么最有效的解法从来不是换更贵的人（堆模型）， 而是给他一套清晰的协作接口和自检流程（搭架构）。 所以说，下一代 AI 的护城河，可能真的不在模型参数里， 而在你能设计出多强的「认知架构」上。 更强的模型，不如更强的自我组织架构， 这可能才是 Agent 真正的成人礼。

译Claude更新了Dynamic Workflows功能，核心是让模型具备“自我组织”能力，能在执行任务前自主拆解目标、选择工作模式并制定流程。此举旨在系统性解决AI智能体存在的智能体式偷懒、自我偏见和目标漂移等三类问题。该设计理念认为，通过架构设计对冲模型缺陷，比单纯堆叠模型能力更有效，并从中提炼出了6种可复用的编排模式。

ginobefun@hongming731 · 6月3日70

http://x.com/i/article/2061947122350751744 # BestBlogs 早报 · 06-03｜动态工作流、Copilot 桌面、AI 工程范式 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-06-03 > EP76 · 2026-06-03 — AI 工程的范式正在被重写：Claude Code 突破单一上下文窗口、为每个任务动态生成编排脚本，GitHub Copilot 以智能体为核心推出桌面控制中心，提交量已突破 14 亿次/月。与此同时，腾讯云工程师从控制论视角论证，大模型是史上首个「认知引擎」，软件工程师的核心职责正在从「写代码」升级为「设计能自我纠偏的 AI 系统」。本期还涵盖任务保真度缩放定律、MiniMax M3 开源模型、NVIDIA Cosmos 3 及机器人供应链深度拆解，一并呈现这场变革的全貌。 ## 导语 今天是 2026 年 6 月 3 日，AI 工具链的底层逻辑正在发生一次结构性升级。 Anthropic 正式推出 Claude Code 动态工作流：Claude 不再只能在单一上下文窗口里规划并执行，而是能即时为每个任务生成一套专属的 JavaScript 编排脚本，自主决定要启动多少个子智能体、使用哪种模型、是否在独立的 worktree 里隔离运行。触发词只需一个：ultracode。 与此同时，GitHub 在 Microsoft Build 上发布了 Copilot 桌面应用——一个为并行 Agent 开发打造的统一控制中心。My Work 视图让你同时监管多条进行中的 Issue 和 PR，Canvas 面板实时显示 Agent 的工作进度，Agent Merge 全程处理 CI 和代码审查。在所有这些工具铺开的背景下，GitHub 的每月提交量已经突破 14 亿次，同比翻倍。 本期精讲之外还有 7 篇速览，覆盖任务保真度缩放定律、AI 原生工程组织打造、MiniMax M3 开源模型、NVIDIA Cosmos 3、机器人供应链深度拆解、Agent 存算分离架构，以及贴吧 AI CR 落地 10 周后 bug 密度下降 66.87% 的完整实践。 本期精讲三篇： - 精讲一：Anthropic 详解 Claude Code 动态工作流的工作原理与最佳实践 - 精讲二：GitHub 在 Microsoft Build 上推出以智能体为核心的 Copilot 桌面应用 - 精讲三：腾讯云工程师以控制论框架重新审视软件工程五十年与 AI 范式革命 ## 精讲一：为每项任务量身打造：Claude Code 中的动态工作流 | Claude Claude Code 面向的任务场景越来越复杂，但默认 harness 有一个固有限制：规划和执行必须在同一个上下文窗口里完成。随着任务变长、结构变复杂，这个窗口会越来越拥挤，开始出现「智能体懒惰」——Claude 开始抄近路；「目标漂移」——Claude 偏离了最初的任务目标。上周，Anthropic 发布了动态工作流（Dynamic Workflows），为这个问题提供了根本性的解法。 动态工作流的工作原理 动态工作流的核心是让 Claude 自己写一个 JavaScript 编排脚本，然后执行这个脚本来完成任务。这个脚本可以使用几个特殊函数来生成和协调子智能体（subagents），同时也可以调用标准的 JavaScript 工具：JSON、Math、Array 等。 与静态工作流的关键区别在于两点。首先，动态工作流可以自主决定给每个子智能体使用哪个模型——这意味着 Claude 会把复杂的推理任务分配给更强的模型，把简单的信息采集交给更快的模型，在成本与质量之间动态权衡。其次，子智能体可以在独立的 worktree 里运行，实现真正的环境隔离，避免多个子任务互相污染工作状态。 如果工作流被用户中断（比如关掉了终端），恢复会话后工作流可以从中断点继续，不需要从头再来。 它解决了哪些具体的失败模式 Anthropic 在文章里明确列出了动态工作流针对的几类失败场景： - 长任务的上下文污染：单一窗口处理长任务时，早期的规划信息和后期的执行信息混在一起，Claude 开始迷失方向。 - 大规模并行任务：比如同时处理 80 份简历评级、同时从多个 Slack 频道抓取数据——这类任务天然适合多路并发，但默认 harness 无法原生支持。 - 高度结构化任务：比如让多个 Agent 分别扮演投资人、用户、竞争对手，从不同角度撕碎一份商业计划书。 - 对抗性任务：让两个子智能体互相挑战，形成一种反馈机制来提升结果质量。 文章给出的几个示例 prompt 很有启发性：「这个测试大约每 50 次运行就会失败一次，用工作流来复现它，提出竞争性假设，不到找到能存活于证据的那个假设不要停」；「拿我最近 50 个会话挖出我反复在纠正的错误，把那些反复出现的写进 CLAUDE.md 规则」。这两个例子都展示了动态工作流的典型场景：需要反复迭代、需要并行比较、或者需要结构化协作的复杂多步任务。 常见的工作流模式 Anthropic 总结了 Claude 在构建工作流时会组合使用的几种基本模式： - 分类执行（Classify-and-act）：先用一个 Agent 对输入进行分类，再把不同类别的任务分配给专门的下游 Agent。 - 排序（Sorting）：把大批量列表（比如 1000 条支持工单）按定性标准排序——单次 prompt 质量会随列表变大而退化，工作流可以分批处理再汇总。 - 竞争性验证（Adversarial check）：让一个 Agent 生成，另一个 Agent 专门找漏洞，循环直到结论站得住脚。 使用建议 动态工作流会消耗更多 token，不适合日常简单任务。最适合的场景是：任务足够复杂（单一上下文处理时质量会退化）、任务足够高价值（额外的 token 成本值得付出）、任务有结构化并行需求（多个角度、多个数据源、多个竞争性假设）。触发方式是在 prompt 里使用关键词 ultracode，或者明确要求「用工作流来完成这件事」。Anthropic 提醒，最佳实践仍在演进，建议首次使用时从相对简单的并行任务开始积累直觉，再逐步应用到更复杂的高价值场景。动态工作流与默认 harness 完全兼容，不需要时可以无缝回退，无需额外配置。 对于正在用 Claude Code 处理复杂多步骤任务的工程师，这篇官方介绍值得仔细阅读：查看原文 ## 精讲二：GitHub Copilot 应用：以智能体为核心的桌面体验 当 Agent 变成开发工作流的常态，管理多个并行 Agent 本身就成了一个新问题。你早上打开电脑，三件工作已经在推进中：一个 Agent 在排查生产 bug，一个 Agent 在实现积压需求，第三个 Agent 在处理代码审查反馈。你需要一个地方能同时看到这三个进度，能介入、能重定向、能测试、能合并。原有的开发工具并不是为这种工作方式设计的。 在 Microsoft Build 2026 上，GitHub 发布了 Copilot 桌面应用，正是要填补这个空缺。 My Work：统一管理所有进行中的工作 Copilot 桌面应用的核心入口是 My Work 视图。这个视图汇聚了所有关联仓库里当前进行中的工作：活跃的 Agent 会话、Issue、PR、后台自动化任务。开发者不再需要在多个标签页之间切换来追踪不同 Agent 的状态，一个视图看全局。 worktree 隔离：Agent 会话互不干扰 每一个 Agent 会话都在独立的 git worktree 环境里运行。这与 Claude Code 动态工作流的设计理念高度一致：隔离是并行 Agent 开发的基础——不同 Agent 的工作状态不会互相污染，合并时也有清晰的边界。 Canvas：双向协作面板 Canvas 是一个可视化的双向协作区域。Agent 工作时，你可以在 Canvas 里实时看到它的工作进度，也可以在任何节点插入反馈、调整方向。这种「异步介入」的交互模式与传统的「等待 Agent 完成再审查」不同，更像是一个真实存在的协作伙伴，只是它在你后台异步跑，你随时可以看进度并给意见。 Agent Merge：全程自动化 CI 和代码审查 Agent Merge 功能负责管理从 Agent 提交代码到合并的整个流程，包括触发 CI 检查、处理代码审查反馈、最终完成合并。开发者的精力可以更多集中在方向判断和质量审核，而不是流程管理。 Copilot 代码审查的定制化扩展 与此同时，GitHub 还扩展了 Copilot 代码审查的能力：开发者现在可以通过自定义 Agent skills、MCP 服务器连接和可配置的 Actions 工作流，让每次代码审查都反映自己团队的标准、内部系统和工程上下文。代码审查还新增了「中等层级审查」（medium tier review）选项，在快速审查和深度审查之间提供了更细粒度的控制。 规模背景：14 亿次提交/月 GitHub 在发布中披露了一组数据：当前平台的每月提交量已经突破 14 亿次，同比近乎翻倍；GitHub Actions 每周运行时间超过 20 亿分钟。这个增速直接说明了为什么 GitHub 要在这个时间点推出 Agent 原生的控制中心——现有工具的设计假设已经跟不上实际工作流的演进节奏。 对于正在将多个 Copilot Agent 整合进开发工作流的团队，这篇发布文章是了解 GitHub Agent 原生方向的第一手资料。Copilot 桌面应用目前已向现有 Copilot Pro、Pro+、Business 和 Enterprise 用户开放技术预览，感兴趣的团队可以直接申请加入：查看原文 ## 精讲三：AI 软件工程范式革命的思考 这篇来自腾讯云开发者的长文，是近期读到的关于 AI 与软件工程关系最系统、最有历史纵深的一篇思考。作者不是在讨论某个工具或某个技巧，而是从工程史的视角，对软件工程过去五十年的本质做出了一次重新定性。 软件工程是过去五十年最不彻底的工程 作者从控制论的视角，梳理了经典工程门类的成功路径：机械、化工、电力、自动化，这些领域都靠同一个范式完成了工程化——「消耗能源，把人脑参与的低阶认知回路固化成物理装置」。蒸汽机的离心调速器、化工厂的恒温器、电网的调度装置，本质上都是同一件事：让原本需要人来盯着、调整、判断的事情，由一台烧煤或通电的设备自己完成。不确定性被大规模消除，同样的输入产出稳定可预期的结果。 软件工程卡在了这条路上。软件开发要处理的是抽象、分解、推理、创造——这些是高阶认知，没法像调速器那样固化成物理回路。五十年来，敏捷、Scrum、DevOps 解决的都是同一个问题，用的是同一种方式：优化堆人力的方式，但没有改变「必须靠人力堆」这个事实。 这就是作者对「软件工程是最不彻底的工程」的定义：它在工程的形而上学层面是个残缺品——所有兄弟门类都完成了「能源替代低阶智能」这个动作，唯独软件没有。 大模型是史上第一个「认知引擎」 大语言模型做到了经典工程从来没做到的事：输入算力，输出能理解需求、生成代码、做逻辑推理的高阶认知产物。 放到工程史的坐标里： - 经典工程：能源 → 低阶智能（机械调节、自动控制） - 大模型：能源 → 高阶智能（理解、推理、生成、决策） 作者的判断是：大模型和蒸汽机的工程史地位是平行的。蒸汽机让「做功」第一次能源化，大模型让「认知」第一次能源化。软件工程「真正降临」的时刻，不是 Scrum 流行的时候，不是 DevOps 普及的时候，而是大模型让「能源换高阶智能」成为可能的这个时刻。在此之前所有的「软件工程」，严格说都是软件作坊的优化版。 但这只是入场券，不是终局 大模型带来了新的不确定性：幻觉（输出看起来合理，悄悄就错了）、漂移（同样的输入，今天和明天给出不一样的结果）、不可解释（没法看进它的决策过程）。 这意味着大模型并没有消除不确定性，只是把「人的不确定性」换成了「模型的不确定性」。真正需要的是一整套新的工程原则——不再是「亲手消除每个微小的偏差」，而是「设计一个能自我纠偏的系统，并处理系统自己纠不回来的剩余偏差」。 作者引入了冯·福斯特 1970 年代提出的二阶控制论：一阶控制论是「观察并控制被控对象」，二阶控制论是「观察并控制『观察并控制』这件事本身」。投射到 AI 软件工程： - 经典软件工程：人在写代码 - AI 软件工程：人在设计「AI 写代码的系统」 这是身份的转变，不只是工具的转变。 自动化越彻底，工业相关人口反而越多 作者用一组跨越 150 年的数据指出：自动化越彻底，工业相关人口反而越多。1850 年代蒸汽机普及后，制造业整体爆炸式增长；1950 年代自动化后，工程师、设计师、工艺员数量暴增。每一次系统能力扩张，都会暴露出新的边界，而边界就是新的「偏差地带」，需要新一波人守在那里。 结论：人不是被淘汰，而是迁移。边界在扩大，需要守的人反而更多了。但能在这种边界上工作的人会越来越少，因为形式化吃掉的都是低阶认知，剩下的都是越来越高阶的部分。 与今日其他精讲的关系 这篇文章与精讲一、精讲二形成了很好的理论基础互补。Claude Code 动态工作流和 GitHub Copilot 桌面应用，都是「设计能自我纠偏的 AI 系统」这个新工程原则在工具层的具体体现——worktree 隔离、子智能体协作、Canvas 双向介入，都在解决「如何设计系统来处理 AI 自身的不确定性」这个核心问题。 对工程师意味着什么 作者给出了一个相对乐观但也相当严峻的判断：AI 时代，人的统一职能是「处理系统暂时还无法处理的偏差」。这条铁律在所有工程门类里都成立——机械故障靠人拉回、电网负载偏差靠人仲裁，现在是认知偏差靠人纠正。 不同的是，AI 工程里，偏差类型不再可枚举，偏差信号不再可观测，拉回手段也没有 SOP 可循。这意味着守边界的人，需要更强的判断力，而不只是更多的知识。 作者在文章末尾讨论了组织形态和落地路线，以及他认为这场变革「最难的那道坎」在哪里，这部分值得有 AI 落地任务的工程师和技术管理者仔细阅读：查看原文 ## 速览 1. 任务保真度缩放定律：为什么数据质量决定 Agent 性能（AI Engineer） Snorkel 的实验证明：在相同算力和任务数量下，仅改变训练数据质量，高保真任务带来 6% 的性能提升，低质量任务只有 1%，差距高达 5 倍。高质量任务须满足四项标准：容器化（隔离干净的回滚和并行化）、可达性（目标非平凡但可实现）、功能正确性（逻辑可预期）、环境稳定性（执行基础设施稳定）。满足这四项才能产生干净的失败信号，让模型在 RL 训练中有效爬坡。低质量任务的常见缺陷是「退化失败态」：环境本身就不稳定，模型无法从失败中提取有意义的学习信号，额外的计算预算全部浪费在噪声上。对正在做 Agent 微调数据集的工程师，这组数据有直接的策略指导价值。查看原文 2. 打造 AI 原生工程组织 | Claude（Claude Blog） Claude Code 团队分享了他们如何重新设计工程流程以适应 AI 原生工作方式。代码生成、测试编写和重构已经不再是瓶颈，真正的瓶颈变成了验证、代码审查和安全评估。他们重写了规划方式（从长期路线图改为即时制订）、代码审查流程、上下文收集方式，以及团队的构成逻辑。这不是工具使用指南，而是一个已经完全转型的工程组织对「如何重新设计流程」的第一手记录，适合正在思考 AI 原生团队转型的工程 Leader 阅读。查看原文 3. MiniMax M3：首个融合三大前沿能力的开源权重模型（MiniMax 官方） MiniMax 正式发布 M3，声称是首个同时融合三大前沿能力的开源权重模型：编码与智能体性能（SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%）、由 MiniMax 稀疏注意力（MSA）实现的 100 万 token 上下文窗口、从零构建的原生多模态能力。同期推出 MiniMax Code 产品和新的 token 计划。权重和技术报告将在约 10 天内发布。值得注意的是，M3 是国内团队在开源大模型赛道上迄今为止对标 GPT 4o 级编码能力的最完整尝试之一，对关注开源模型生态的开发者值得持续跟进。查看原文 4. NVIDIA 推出 Cosmos 3：用于物理 AI 的完全开放全能模型（NVIDIA AI） NVIDIA 发布 Cosmos 3，定位为世界上首个完全开放的、用于物理 AI 的「全能模型」（omnimodel），原生支持视觉推理、世界生成和动作生成三种能力。本次发布了两个版本：Super（32B）和 Nano（8B），面向机器人和自主系统领域。结合精讲三和速览第五条的机器人供应链分析，物理 AI 的基础模型层正在加速成熟。查看原文 5. 拆解机器人「肉身」、量产与供应链：空翻之后，它还要学会接住一片落叶（硅谷 101） 硅谷 101 深度拆解人形机器人的硬件架构：骨架材料（从钢材到铝合金、镁合金、钛合金的演进与轻量化权衡）、关节执行器（从液压到电机转变的背后技术进步）、传感器体系、电气与计算系统，以及整条供应链的成本结构与量产门槛。文章还引用了智元、宇树等头部企业一线负责人的具体判断。宇树科技科创板 IPO 刚刚通过上交所审议，这篇系统性拆解正当其时，适合想深入了解机器人硬件护城河的读者。查看原文 6. 深度解析 Agent 存算分离架构设计（idoubi） 作者以 FastClaw 为例，系统拆解云端 Agent 的存算分离架构：三种运行模式（本地裸机、本地带沙盒、云端多副本）的优缺点对比，存储层的四种方案（热状态用 Redis、对话记录用 Postgres、长期记忆用 pgvector/Milvus、工作产物用 S3/OSS），以及基于存算分离架构的完整运行流程，同时指出了分布式数据一致性的挑战。对比今日精讲一中 Claude Code 动态工作流的 worktree 隔离机制，两篇在「计算与状态分离」这个方向上有一定共鸣，对正在设计云端 Agent 基础设施的工程师有直接参考价值。查看原文 7. 用数据说话：贴吧 AI CR（小码哥）落地 10 周，bug 密度下降 66.87%（百度 Geek 说） 贴吧 Server 团队的 AI Code Review 落地实践：通过规则定制、自动化评测和三层反馈闭环（高/中/低优先级评论处理流程），将 AI CR 评审占比从 33% 提升至 84%，bug 密度从 0.332 降至 0.11，降幅 66.87%。文章完整记录了 10 周的推进节奏、踩坑经验和方法论，代码库多、提交频率高、人工评审质量参差的团队可直接参考迁移。这份实践与精讲三的理论框架形成印证——AI CR 本身就是一个能自我纠偏的代码质量系统。查看原文 ## 今日阅读路径 时间有限，建议先读这三篇： 1. 为每项任务量身打造：Claude Code 中的动态工作流（精讲一）— 如果你在用 Claude Code，这是今天最直接有用的一篇，10 分钟读完，了解动态工作流的工作原理和触发方式，以及哪类任务最值得启用。 1. AI 软件工程范式革命的思考（精讲三）— 今天内容最有长期价值的一篇。控制论框架下的软件工程史重构，以及「设计能自我纠偏的 AI 系统」这个新工程师身份定位，是理解当前所有 AI 工具演进方向的底层框架。 1. GitHub Copilot 应用：以智能体为核心的桌面体验（精讲二）— 并行 Agent 开发控制中心的完整介绍，了解 GitHub 在 Agent 原生方向的系统性布局，以及 worktree 隔离、Canvas 协作、Agent Merge 这几个核心机制的实际用法。 还有时间？ 推荐任务保真度缩放定律（做 Agent 微调数据集的工程师必读，5 倍质量差距有直接策略价值）和机器人供应链深度拆解（宇树 IPO 时机下的硬件架构系统梳理，适合关注具身智能落地的读者）。

译Anthropic 为 Claude Code 推出动态工作流，允许模型为每个任务自主生成 JavaScript 编排脚本，动态选择模型并启动多个子智能体在独立环境中并行执行，以解决单一上下文窗口处理复杂任务的限制。同时，GitHub 在 Microsoft Build 上发布了以智能体为核心的 Copilot 桌面应用，提供统一视图、协作面板和自动化流程，旨在管理并行 Agent 开发。文章披露，GitHub 平台每月提交量已突破 14 亿次。

ginobefun@hongming731 · 6月3日49

#BestBlogs 早报 06-03 BestBlogs 今日早报推荐阅读： Anthropic 博客详解 Claude Code 动态工作流，Claude 能为每个任务即时生成专属编排脚本，告别「智能体懒惰」和「目标漂移」； GitHub 在 Build 同步亮相 Copilot 桌面应用，每个 Agent 独占 worktree、提交量已破 14 亿/月。 腾讯云工程师则从控制论视角点出：大模型是史上首个「认知引擎」，工程师的核心职责正在从「写代码」升级为「设计能自我纠偏的 AI 系统」。

译Anthropic 详解 Claude Code 的动态工作流，其能为每个任务即时生成专属编排脚本，旨在解决智能体懒惰与目标漂移问题。GitHub 发布 Copilot 桌面应用，为每个智能体提供独立的 worktree，其月代码提交量已突破 14 亿 tokens。此外，有观点指出大模型是史上首个“认知引擎”，工程师角色正从编写代码升级为设计能自我纠偏的 AI 系统。

ClaudeDevs@ClaudeDevs · 6月3日66

We've updated /fork in Claude Code /fork now runs a background agent with your exact context (system prompt, tools, history, model) and prompt cache. The result gets returned to your session. /branch (the old /fork) still copies the transcript to a new session you drive.

译我们已更新 Claude Code 中的 /fork 命令。 /fork 现在会在后台运行一个智能体，使用您的完整上下文（系统提示词、工具、历史记录、模型）和提示词缓存。结果将返回到您的会话中。 /branch（旧的 /fork）仍然会将对话记录复制到您驱动的新会话中。

Orange AI@oran_ge · 6月3日48

Opus 4.7、4.8 的接连失败令人费解 价格更贵，效果无提升，甚至负提升 看看日历，突然意识到 Claude 已经停滞了 4 个月 即便是掌握了模型训练的方法，即便内部已经有了 Mythos 这样的开发利器 模型的进步还是没有太多加速，依然半年一次大更新？

译推文指出 Claude Opus 4.7 与 4.8 的发布效果不佳，价格提升但性能无明显改进甚至下降。作者认为 Claude 模型已停滞 4 个月，即使内部拥有 Mythos 等开发工具，模型进步速度依然未显著加快，仍维持约半年一次重大更新的节奏。

elvis@omarsar0 · 6月3日38

Code is all you need! Search as Code Harness as Code What's next?

译代码就是你所需的一切！ 搜索即代码 工具链即代码 接下来是什么？

Anthropic@AnthropicAI · 6月3日69

This Executive Order is an important step in strengthening America’s leadership in AI. We look forward to collaborating with the White House to support its implementation. https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/

译这项行政令是加强美国AI领导地位的重要一步。 我们期待与白宫合作，支持其实施。 https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/

Emad@EMostaque · 6月3日17

this is fine 🐶☕️🔥

译这没事 🐶☕️🔥 [引用 @EMostaque]：我对 Claude Opus 4.8 的评价： 我们应该少担心被变成回形针，多担心被烦死。