http://x.com/i/article/2069928325951401985
BestBlogs 早报 · 06-25｜OpenAI 联手 Broadcom 出芯片，Anthropic 谈人机协作，阿里代码评审 CLI 揽星 5k
在线阅读本期早报
BestBlogs.dev 是 AI 驱动的私人阅读助手。这是面向所有人的每日早报内容，如果你希望它基于你的兴趣和阅读习惯整理，可以体验「我的早报」。
导语
今天的三条精讲分别站在 AI 全栈竞争的三个不同层面：芯片、协作模式、代码质量。
OpenAI 与 Broadcom 联手把推理芯片的研发周期压缩到九个月，AI 行业的竞争正卷入硬件层。
Anthropic 罕见公开内部协作经验，给「人类与多智能体共享工作台」这种新协作模式立了规矩。
另一边，阿里把验证两年的代码评审 CLI 开源即揽星 5k，提醒我们 AI 写代码和 AI 审代码远不是同一种能力。
三条精讲合在一起看，正好勾勒出一条完整的链路：底层算力越来越便宜，协作方式从单人变成多人多智能体，但生产出来的代码质量仍需要专门工具来兜底，每一层都在同步进化，缺一不可。
速览部分还覆盖了 Flutter 渲染机制、Gemini 3.5 Flash 的计算机操作能力、Qwen 的语言世界模型、Cisco 零日漏洞复盘、智能体记忆构建方法，以及一段 Gemini 对抗 DeepSeek 的幕后故事；补充阅读部分则提供了围绕今天三条精讲的更多一线信源和延伸视角。
★ 精讲一：OpenAI 与 Broadcom 发布针对 LLM 优化的推理芯片
背景：过去两年，AI 行业的竞争主线一直是模型能力和应用层产品，芯片更多被当作「买来的基础设施」。OpenAI 这次直接下探到芯片设计层，和 Broadcom（NASDAQ: AVGO）联合发布了 Jalapeño——OpenAI 第一款定制 LLM 推理芯片，也是双方多代计算平台合作的第一颗芯片。芯片由 Broadcom 总裁兼 CEO Hock Tan、总裁 Charlie Kawwas 当面交付给 OpenAI CEO Sam Altman 和总裁 Greg Brockman，象征意义大于一次普通的供应商发布会。
关键事实：Jalapeño 从设计到流片仅用九个月，团队称这是高性能芯片史上最快的 ASIC 研发周期之一，而这个研发过程本身就由 OpenAI 自家模型加速完成——形成了「用模型设计芯片，再用芯片跑模型」的闭环。芯片围绕 OpenAI 对 LLM 推理需求的深度理解从零设计，设计阶段就充分参考了模型路线图、推理 kernel、服务系统和产品需求，并联合 Broadcom、Celestica 在芯片实现、板级与机柜系统集成、高性能网络、可扩展生产系统等环节实现工业化落地。工程样片已经在实验室以量产目标频率和功耗运行真实负载，包括 GPT‑5.3‑Codex‑Spark。早期测试显示，Jalapeño 的能效比（performance per watt）显著优于当前最先进水平，详细技术报告将在未来几个月公布。架构层面的核心思路是减少数据搬运、平衡计算/内存/网络资源，让实际利用率更接近理论峰值；Broadcom 的芯片实现能力和包括 Tomahawk 网络芯片在内的网络技术，则负责把这套平台真正落地到大规模生产环境，并计划从 2026 年起与 Microsoft 等数据中心伙伴一起以吉瓦级规模部署。OpenAI 硬件项目负责人 Richard Ho 提到，团队围绕对前沿模型最重要的 kernel、内存搬运、网络和服务模式优化架构，让 Jalapeño 在执行最重要的负载时能更接近硬件理论极限；Broadcom CEO Hock Tan 则把这次合作定义为面向未来十年 AI 物理基础设施扩张的「多代路线图的开端」。
为什么重要：这标志着 OpenAI 的全栈战略从「模型 + 产品」正式下探到「芯片」这一层，构建出「模型反哺芯片设计、芯片支撑更便宜推理」的飞轮。Brockman 把这称为「计算驱动的经济」——通过自己设计更多层级的技术栈，用更高效率提供更多智能，让先进 AI 的访问成本持续走低，并能被用于解决更重要的问题。对于依赖云端推理成本的开发者和企业来说，这条芯片自研路线如果跑通，意味着未来几年大模型调用价格还有进一步下降空间；而对芯片产业来说，OpenAI 以「模型公司」身份亲自下场定制芯片，本身也是对英伟达等传统芯片供应商话语权的一次结构性挑战。
与今日其他精讲的关系：如果说精讲一是 AI 竞争卷入硬件层的信号，精讲三里阿里开源的代码评审 CLI 则提醒我们，硬件红利最终还是要靠软件工程能力消化——芯片更快不代表代码质量自动变好，AI 写代码与 AI 审代码仍是两种需要分别打磨的能力。
阅读建议：如果你关注 AI 基础设施和芯片产业链，这篇官方发布值得通读，重点看架构设计思路和量产时间线；如果只关心应用层，知道「推理成本可能继续下降」这一个结论即可，不必深究芯片实现细节。
详见：OpenAI 与 Broadcom 发布针对 LLM 优化的推理芯片
★ 精讲二：Anthropic 关于构建高效人机协作团队的经验 | Claude
背景：过去和 AI 协作基本是「一人对一个聊天窗口」的单机模式——一个人面对一个智能体完成单点任务。随着智能体能处理编码、研究、财务分析这类复杂长周期工作，使用形态也在变化，但本质上仍是「单人」体验。Claude Tag 这类工具的发布打破了这个边界：人类和智能体现在可以共处同一个工作空间，为团队共同目标协作，工作形态从「单机游戏」变成了「多人游戏」——人类团队设定策略，Claude 执行具体工作。
关键事实：Anthropic 在文章中把能与多个不同人类同时协作的 AI 模型称为「多智能体（multiplayer agents）」。这类智能体需要三项基础能力：持久记忆（记住目标并据此调整执行）、不绑定个人的独立身份凭证（在安全可预期的边界内运作）、对组织信息的持续广泛访问权限（理解组织运作方式并据此行动）。文中举了一个具体场景：人类团队和智能体在 Slack 同一个频道里一起分析数据集，智能体能跟进对话上下文、调用工具、给出分析结果，整个过程就像团队里多了一名常驻成员，而不是临时被叫来回答一个问题就消失的助手。但 Anthropic 强调，光有技术基础还不够，团队还需要建立新的工作方式和共同规范，文章总结了四条经验：信息默认公开（团队内部尽量公开透明，因为智能体只能从可搜索的文本——Slack、代码、文档、会议记录——构建对世界的理解，私聊和口头沟通对智能体而言「不存在」，与其逐条决定哪份文档能给智能体看，不如直接设定工作空间级别的安全边界，让信息在边界内对人和智能体一视同仁地流动）；人和智能体各有清晰角色分工，避免责任边界模糊导致互相甩锅或重复劳动；由人类设定北极星目标，智能体负责执行细节，团队设定战略方向，Claude 执行具体工作，这种分工让人类可以专注在更高层的判断上；按可验证程度逐步放权，而不是一开始就给智能体完全自主权——风险越低、越容易验证结果的任务，越适合早期放权，高风险决策仍需人类把关。
为什么重要：这是 Anthropic 少见的公开内部协作实践，相当于把「团队级智能体协作」这件事从概念阶段直接给出了一套可复制的治理框架。对正在把 AI 智能体引入团队协作流程的公司来说，这四条经验提供了具体的边界设计参考，而不只是停留在「智能体很强大」的宏观叙事，也回应了很多团队在引入智能体协作时最容易卡住的两个问题——信息要不要全量开放给智能体、放权节奏怎么把控。
与今日其他精讲的关系：精讲一讲的是 AI 全栈竞争卷入硬件层，精讲二则是软件协作范式的进化——两者共同指向同一个趋势：AI 正在从「被使用的工具」变成「被设计进组织结构里的协作者」，无论是芯片层还是团队协作层，都需要重新设计底层架构来适配这种变化。
阅读建议：如果你的团队已经或准备让多个智能体参与协作流程，这四条经验值得逐条对照自己的实践，尤其是「信息默认公开」和「按可验证程度放权」这两条最容易在落地时被简化掉；如果只是单人使用 AI 工具，可以重点看「信息默认公开」这一条，它对个人知识管理同样有参考价值。
详见：Anthropic 关于构建高效人机协作团队的经验 | Claude
★ 精讲三：阿里开源 Open Code Review：一周揽下 5k star，更专业的代码评审 CLI
背景：AI 每天生成的代码量已经远超人工评审的承载上限——以前一天 review 几百行,现在动辄几千甚至几万行，代码评审正在成为研发效率新的质量瓶颈。Open Code Review 的前身是阿里集团内部官方 AI 代码评审助手，过去两年在内部服务了数万开发者、识别了数百万个代码缺陷，经过大规模生产验证后被孵化为开源项目，向社区开放。
关键事实：文章直接点出了用通用 Agent（比如 Claude Code + Skills）做代码评审的三个常见痛点：覆盖不全（变更较大时 Agent 倾向于「偷懒」，选择性评审部分文件，导致遗漏）、位置漂移（报告的问题与实际代码位置经常对不上，出现行号或文件偏移）、效果不稳定（纯自然语言驱动的 Skills 难以调试，评审质量因提示词的细微差异大幅波动）。这些问题的根源在于纯语言驱动的架构缺乏对评审流程的强约束。Open Code Review 的解法是「确定性工程 + Agent」混合架构：精准的文件筛选（明确哪些文件需要评审、哪些应当过滤，确保重要改动一个不漏）、智能文件打包（把关联文件归并为同一评审单元，每个包作为独立 subagent 任务，上下文互相隔离，超大变更场景下更稳定也天然支持并发）、精细化规则匹配（针对不同文件特征匹配对应评审规则，用模板引擎而非语言模型保证规则匹配的稳定性和可预期性）、外挂的定位与反思组件（独立的评论定位模块和反思模块，系统性提升 AI 反馈的位置准确性和内容准确性），这些「不能出错」的环节全部交给工程逻辑负责的强约束环节；Agent 只负责动态决策和上下文召回这类真正需要推理的部分，包括场景化提示词调优和场景化工具集沉淀。
阿里内部数据显示：月活用户 2 万、累计执行 370 万次真实评审任务、用户采纳率超过 30%、有效 AI 评论占比全集团范围内近 80%、评论位置准确率超过 97%。基于 50 个热门开源仓库、200 个真实 PR、覆盖 10 种编程语言、80+ 资深工程师交叉标注的开源评测集显示：Open Code Review 各模型组合准确率在 25%–38% 之间，远高于 Claude Code 的 7%–16%（以 Claude-4.6-Opus 为例，OCR 产出 889 条评论命中 301 个真实问题，准确率 33.90%；Claude Code 产出 5980 条评论命中 435 个真实问题，准确率仅 7.23%）；但 Claude Code 在召回率上更具优势，CC + Claude-4.6-Opus 以 28.90% 的召回率位居所有组合之首，比 OCR 最优组合多发现约 45% 的真实问题，CC + Qwen3.7-Max 和 CC + GLM-5.1 的召回率同样超过 OCR 多数组合，这对安全审计这类「宁可多查、不可遗漏」的场景仍有不可替代的价值。综合 F1 指标，Open Code Review 在准确率与召回率之间取得了更均衡的表现（最优 25.10% vs Claude Code 最优 14.13%），资源消耗也更低（Token 消耗 352K–743K，耗时 1–6 分钟，远低于 Claude Code 的 2,062K–5,664K Token、5–14 分钟）。文章还指出一个有意思的现象：更新的 Claude-4.8-Opus 在两个工具上都表现出「更精确但更保守」的特征，准确率最高但召回率明显低于上一代 Claude-4.6-Opus，说明模型代际升级不一定带来评审效果的全面提升。
为什么重要：这组对比数据揭示了一个容易被忽视的事实——AI 写代码与 AI 审代码是两种截然不同的能力，即便是最强的编码 Agent，也需要专业的评审 Agent 来兜底。Open Code Review 团队甚至用 Claude Code 从零以 Go 语言重写了这个开源项目本身，再用 Open Code Review 反过来评审每一次变更，106 次代码变更中累计发现 145 个有效问题，涵盖严重 Bug、安全问题、错误处理不当、命名错误、代码重复、性能问题等多种类型，这个「自证」过程本身就是对工具能力的真实验证。
与今日其他精讲的关系：精讲一和精讲二分别讲了 AI 在硬件层和团队协作层的进化，精讲三则把视角拉回最基础的软件工程环节——再快的芯片、再高效的人机协作，最终生产出来的代码质量仍然需要专门的工程化方案去把关，这是当前通用 Agent 普遍存在的短板。
阅读建议：如果你的团队已经在用 AI 大量生成代码，这篇文章里「确定性工程 + Agent」的架构思路和评测数据值得细读，尤其是文件打包和定位反思组件的设计可以直接借鉴；如果只是想知道结论，记住一句话即可——通用 Agent 评审代码目前还不如专门工具准，但召回更全，两者可以搭配使用。
详见：阿里开源 Open Code Review：一周揽下 5k star，更专业的代码评审 CLI
速览
说好的艺术家呢？—— AI 时代，内容工业的三次死亡与创作者的重生
这是「屠龙之术」作者在 AEIS-AI 娱乐内容产业峰会上一场 40 分钟演讲的录制版本，围绕当前 AI 多模态领域的发展现状展开。文章深入剖析了 AI 如何从素材生产、生产流程、版权归属三个层面接连冲击传统内容工业，并指出创作者唯有放弃旧有的生产者身份、构建全新的价值愿景，依靠人类独有的直觉、品味与信任关系，才能在技术碾压之下实现真正的「重生」，而不是在旧赛道里继续被替代。演讲本身带有明显的行业一线视角，时间线里穿插了多个具体案例，适合从业者对照自己所在的细分赛道判断冲击程度和应对节奏。
Flutter 底层渲染解析：BuildContext 与 Element Tree 详解
文章从一句常见的报错「Looking up a deactivated widget's ancestor is unsafe」讲起，深入剖析 Flutter 内部的三棵树结构——Widget Tree、Element Tree、RenderObject Tree——以及 BuildContext 究竟是什么、setState 调用之后框架内部到底发生了什么。比起照搬 Stack Overflow 答案，这篇文章更适合想真正理解 Flutter 渲染原理、从根上修复上下文相关错误的开发者。
Google 宣布计算机操作（computer use）现已成为 Gemini 3.5 Flash 的内置工具，此前这项能力只在独立的 Gemini 2.5 computer use 模型中提供。Gemini 在函数调用和搜索/地图等内置工具调用上本就表现不错，这次原生整合计算机操作能力之后，开发者可以直接用主力 Flash 模型构建能与浏览器、移动端、桌面环境交互的智能体，不再需要额外接入专门模型，开发链路更简洁。
Qwen-AgentWorld 开源：让 Agent 学会“先预测，再行动”
通义实验室开源了 Qwen-AgentWorld，号称首个原生语言世界模型——核心思路是让 Agent 不再只在真实环境里反复试错（搭建沙箱成本高、危险操作可能直接搞崩环境），而是先学会「预测环境会发生什么」。环境建模从继续预训练阶段就作为训练目标，贯穿 CPT、SFT、RL 全流程，而不是对通用大语言模型的事后适配；单一模型同时覆盖 MCP、Search、Terminal、SWE 等文本类环境与 Web、OS、Android 等 GUI 类环境，实现跨领域知识迁移，在 AgentWorldBench 上超过了 GPT-5.4 等前沿模型。文章还展示了可控模拟和跨任务泛化两种应用范式，适合关注 Agent 训练方法论演进的读者。
Cisco SD-WAN 管理器零日漏洞遭利用获取 Root 权限全过程
Mandiant 详细复盘了一起真实攻击事件：威胁行为者在拿到某服务商的 SD-WAN 基础设施初始访问权限后，利用 Cisco Catalyst SD-WAN Manager 中的零日权限提升漏洞 CVE-2026-20245，通过文件上传功能缺乏校验的缺陷，把一个受限的管理员账号一路提权到 root 权限。拿到 root 之后，攻击者并未止步于横向移动，而是进行了大量针对性的反取证清理，试图抹去入侵痕迹，这也增加了事后溯源的难度。这篇分析对安全团队理解真实世界的零日利用链条、文件上传类漏洞的危害边界以及事后取证排查很有参考价值，建议运维和安全团队结合自己的 SD-WAN 部署情况核对补丁状态。
LangChain 这篇文章给出了一套构建智能体记忆的结构化方法：通过「捕获、分析、更新」三步循环的闭环，让智能体能从之前的交互中学习，避免用户每次都要重复纠正同样的问题。文章还结合 LangSmith 讲解了具体的可观测性、记忆引擎和上下文管理实现方式，适合正在给自己的 Agent 加记忆能力的开发者参考落地细节。
40 天不睡、5 人死磕：DeepMind 主管爆料 Gemini 大战 DeepSeek 内幕
这篇编译自 Gemini 预训练主管 Vlad Feinberg 的播客访谈，讲述了 Gemini 2.0 Flash 背后只有 5 个人的团队、在硅谷和巴黎两地 24 小时倒班、连续 40 天不眠不休训练模型的真实故事，揭开了「顶尖实验室天天搞颠覆性算法」这种想象背后更朴素的工程真相——团队真正的日常是调整编译器和超参数、解决显存溢出、把微调任务硬塞进一堆老旧 TPU 卡里。文章还谈到预训练研究、量化、推理协同设计，以及程序员在 AI 时代应该往哪个方向转型，对关心大模型训练一线工作方式、想了解「干脏活」式工程贡献如何被认可的读者很有意思。
补充阅读
GitHub - BrightbeamAI/chap：协作人机交互协议（CHAP）：一个开放协议，专门用于规范人类与 AI 智能体之间结构化、可审计的协作，把人工覆写行为记录为结构化数据，方便追溯决策过程和持续改进提示词，适合关注人机协作协议标准化的读者。
从表单到 Agent：得物社区活动搭建的 AI 实践之路：得物技术团队分享了把社区活动搭建流程从「填表单」逐步演进到「AI 驱动 + 人工确认」两阶段 Agent 架构的实践过程，包含关键的取舍和架构设计细节，适合做内部工具 Agent 化改造的团队参考。
超越 CLEAN 与 MVP：在 Android 中构建离线优先的响应式数据层：介绍了响应式数据层架构（RDLA），通过强制分离公共 API 数据定义与私有实现数据源，解决响应式 UI 框架与移动端存储限制之间的矛盾，重点是离线优先和去耦同步，适合 Android 架构方向的工程师。
Greg Brockman 宣布 OpenAI 推出全新 LLM 推理芯片 Jalapeño：OpenAI 总裁本人发布 Jalapeño 推理芯片的第一时间动态，可以作为精讲一官方公告的一线信源补充。
OpenAI 发布首款 AI 芯片：Jalapeño：OpenAI 官方账号同步发布的芯片公告，与上面 Brockman 的个人动态相互印证，适合想看官方第一反应的读者。
阿里重磅开源！Open Code Review：一周 5k star，为你的代码保驾护航：另一篇视角介绍 Open Code Review 开源始末，公开了更多评测数据细节和具体使用方式，适合看完精讲三还想了解上手步骤的读者。
今日阅读路径
如果今天时间有限，建议按这个顺序读：
- 精讲三 · Open Code Review —— 信息密度最高，「AI 写代码 vs AI 审代码」的结论对几乎所有用 AI 编程的团队都有直接参考价值。
- 精讲一 · OpenAI 与 Broadcom 推理芯片 —— 了解 AI 行业竞争正在卷入硬件层这个大趋势，判断未来推理成本走向。
- 精讲二 · Anthropic 人机协作经验 —— 如果你的团队已经或即将引入多智能体协作，这四条经验能帮你少踩一些治理上的坑。
其余内容可以按兴趣挑选：关注移动端开发看 Flutter 渲染解析，关注 Agent 工程看 Qwen-AgentWorld 和智能体记忆构建，关注安全看 Cisco 零日漏洞复盘，关注行业幕后故事看 Gemini 对抗 DeepSeek 那篇。
BestBlogs 是 AI 驱动的私人阅读助手，帮助你发现真正适合你的高质量内容，欢迎体验。