全部 · 2026-06-18

这条新闻的核心是：OpenAI 把一个更便宜、更快的小模型（GPT-5.5 Instant）的医疗问答能力，拉到了和它家最贵、最慢的思考模型差不多的水平。他们用了一个叫 HealthBench Professional 的测试集，里面是真实的医患对话，打分标准也是医生定的。在准确性、沟通清晰度这些维度上，医生评审团给模型回答的打分，比给真人医生写的回答还高。 这个结果挺唬人，但得先打个折。文章说线上监测到的“事实错误标记”两个月内下降了 71%，这是个相对值，没告诉我们绝对错误率到底是多少。比如从 1% 降到 0.29% 也是降 71%，但风险感知完全不同。另外，医生评审的具体打分表、盲审流程细节也没披露，我们不知道这个“比真人医生强”的结论是在多严格的条件下得出的。 还缺一个关键信息：这些测试场景和真实用户乱糟糟的提问方式有多大差距。评测里医生可以无限时、上网查资料（但不能用 AI），这跟现实中患者一口气扔过来一堆模糊症状和检查单的情况不一样。模型在受控测试里表现好，不代表在真实问诊的复杂对话里不翻车。

这个 Seeduplex 模型最特别的地方是“原生全双工”，不用等你把话说完，它能边听边判断什么时候接话。官方给了几个具体数字：判停延迟缩短约 250 毫秒，复杂场景下抢话比例降了 40%，用户主动打断的延迟也少了约 300 毫秒。这些数字说明它在多人聊天或嘈杂环境里会更像人，不会乱插嘴或漏掉你的打断。 它还支持在对话里直接调用工具，比如订日历、发邮件，这对车载或客服场景挺实用。不过正文没披露定价、公开上线时间，也没给出误回复率具体降了多少。如果是真的挺省钱，但没价格就没法判断性价比。另外，抗干扰能力只在官方描述里提了，没有第三方测试或对比数据，这点先别太激动。

这项研究最实在的一点是，它没让模型直接看病，而是让 o3 的“深度研究”模式去翻文献、对基因数据，给专家列出一批有证据支持的候选病因。376 个病例都是之前专家看过但没结论的，模型介入后多确诊了 18 例，相当于在原有基础上多找出 4.8% 的病因。这个数字不算颠覆性，但对那些等了多年没答案的家庭来说，每多一个确诊都是实打实的进展。 不过得注意，这只是一次回顾性研究，不是常规临床工具。所有模型提出的假设，都经过了医生审核和 CLIA 认证实验室的湿实验验证才算数。正文没披露模型出错的概率，也没说它提了多少个假阳性候选让专家白忙活。另外，研究用的是脱敏数据，真实临床环境里数据更乱、格式更不统一，模型能不能保持这个产出还不清楚。 如果后续能公布假阳性率和专家审核耗时，会更容易判断这 4.8% 的收益值不值得推广。目前看，它更像一个帮专家省翻文献时间的外挂，离“AI 诊断”还差着好几道实验室的硬门槛。

DeepSeek 把识图模式做成了跟快速、专家模式并列的独立入口，而不是藏在对话框的附件里，这个产品决策挺有意思——它把“看懂图片”当成一种独立的思考方式，而不仅仅是一个输入手段。研究员 Xiaokang Chen 宣布网页和 App 端同步上线，但 IT 之家实测发现 App 端还留着“图片理解功能内测中”的提示，网页端倒是干净。这种两端状态不一致，要么是发版节奏没对齐，要么是移动端还在做最后的压力测试。 今年 4 月他们公开过背后的技术框架“Thinking with Visual Primitives”，核心思路是让模型先提取视觉原语再推理，而不是直接把图扔给语言模型。这个路线理论上能降低幻觉，但正文完全没提现在用的是哪个模型、参数量多大、推理成本多少、支不支持多轮对话里的图片追问。也没说图片分辨率上限、文件大小限制、是不是免费。这些信息缺口让“正式上线”这个词得打个折——更像是公开测试的扩大，而不是产品化的收尾。 对从业者来说，值得关注的点是：如果识图模式真的按独立推理通道来跑，那它的延迟和 token 消耗跟纯文本模式差多少，会直接影响能不能放进生产流程。这些数字正文一个都没给。

这条新闻最值得看的是思路：把蛋白质、小分子、材料这些原本“鸡同鸭讲”的数据，全部编码成统一的离散 token 序列，然后用同一个“预测下一个词”的目标来训练和推理。这相当于给科学领域建了一套通用语言，模型不再需要为每个任务换一套架构和假设。LOGOS-1B 只有 10 亿参数，微软 NatureLM 是 8×7B 的混合专家模型，参数量差了 56 倍，却在六个任务上匹配或超越了对方，参数效率确实亮眼。 不过有几个地方要先打个折。第一，正文只说了“匹配或超越”，没有给出具体任务上的绝对分数对比，不知道领先是小数点后几位还是实质性差距。第二，44.87B tokens 的预训练语料里蛋白质占了 28.9B，小分子只有 2.1B，数据分布很不均衡，模型在小分子相关任务上的表现是否同样稳定，正文没展开。第三，把 3D 空间接触模式转成离散 token 这个想法很巧妙，但完全抛弃显式 3D 坐标后，在需要精确几何约束的场景下会不会丢精度，目前没有消融实验支撑。 整体看，这套“统一语法 + 序列建模”的范式如果能跑通更多科学领域，确实能省掉大量适配工作。但现阶段还缺更多独立复现结果和实际应用案例，先当一篇有意思的技术报告看比较合适。

Alex Ellis 的这篇长文不是跑分报告，而是一个小软件公司创始人的真实账本。他花 6000 美元买了块 RTX 6000 Pro 跑本地 Qwen 27B，两三个月就靠替代云端 API 调用回了本。在 SWE-Bench 基准上，Qwen 27B 只比 Claude Opus 4.8 低 12%，看起来差距不大。但一到他实际写的 Go 分布式系统代码里，量化后的模型就会陷入死循环和幻觉，生成不可用的代码。所以他现在的用法很明确：本地模型干粗活、处理非关键任务，核心代码和无人值守的 agent 工作流还是交给云端旗舰模型。 文章最大的信息缺口是没给任何 token 生成速度和延迟数据，只说量化后问题变多，但没量化到底慢了多少、卡在哪个环节。另外，他的场景高度集中在 Go 语言和底层基础设施代码，这个结论能不能迁移到 Python、前端或者 CRUD 业务代码上，正文没讨论。回本速度也跟他的 API 调用量强相关，如果你用量没他大，回本周期会拉长不少。

Tine 把 AI 从聊天框里拽了出来，直接做成一个能看懂你屏幕、接管鼠标的“第二光标”。它实时读取你当前在用什么软件、选中了什么、上一步做了什么，你不用再复制粘贴背景信息。下个指令，它就能跨软件帮你发 Slack、写笔记、跑调研、填表单。团队说早期版本会误读界面元素或行为不稳定，后来围绕三条规则重做：让你看清它看到了什么、动手前必须获得明确许可、你一碰鼠标就立刻交还控制权。默认在设备本地运行，每一步都有日志。 但这是一条 Product Hunt 发布帖，不是技术报告。正文没提用了什么模型、响应延迟多少、收费怎么算，也没给出真实场景下的稳定性数据。跨软件操控对屏幕识别和操作可靠性要求极高，早期版本已经翻过车，新版修到什么程度完全未知。如果它真能在复杂界面里稳定干活，确实省事；但在看到实测之前，我会先打个折。

上交所这次把科创板第五套上市标准明确给了AI大模型企业，核心就一条：申报时至少有一个大模型产品已经上线并且实现规模化应用。说白了，就是不看你现在赚不赚钱，但要看你的产品是不是真跑起来了，用户量够不够大。这比光讲技术故事要实在，用实际跑出来的用户规模来证明商业模式不是纸上谈兵。 不过指引里没给“规模化应用”的具体数字门槛，是日活百万算规模，还是付费客户过千算规模，正文没披露。另外，公司还得在行业里地位突出、排名靠前，目标市场要清晰，成长性要强——这些也都是定性描述，具体怎么评、谁来评，指引没说清楚。 对头部大模型公司来说，这确实多了一条融资通道，尤其那些还在疯狂烧钱搞研发、短期看不到盈利的。但“规模化应用”这个口子到底多宽，还得看后续有没有更细的审核口径出来，不然容易变成又一个模糊地带。

苹果这次在 Xcode 27 里塞了一个能直接干活的 AI 助手，不是那种在旁边弹窗聊天的配角，而是嵌在工具栏里，可以跨多个文件改代码，甚至根据你的文字描述加上图标素材，直接生成一个完整的 App。生成之后还能继续用对话让它加背景、特效、动画和翻译，听起来像是把 vibe coding 那套流程搬进了苹果自家的开发工具里。 底层方面，苹果推出了新的 Core AI 框架和升级版 MLX，让开发者在 App 里调用端侧模型更方便，也支持接入 Anthropic、OpenAI 和 Google 的第三方模型。这相当于给了开发者一个模型选择权，不用被绑在苹果自己的模型上。 但这条新闻最大的信息缺口是：所有演示都来自 WWDC 的官方讲座视频，没有第三方实测数据。跨文件修改的准确率有多高？生成完整 App 的成功率是多少？在本地跑这些模型延迟有多大？支持的语言是不是只有 Swift？这些关键指标正文一个字都没提。所以现在只能把它当成一个方向性的发布，离真正能省多少事，还得等开发者上手之后才知道。

Mindgard 的研究员发现，一个在 X 上流传的提示词能直接击穿 ChatGPT 的图像安全过滤。这个提示词只是让模型“修复附件照片”，没指定任何具体内容，但 ChatGPT 却会自发生成涉及死亡和性侵犯的极端画面。研究员 Jim Nightingale 之前就向 OpenAI 报告过模型能生成裸照，OpenAI 当时说问题已解决，但这次的新漏洞表明修复并不彻底。 文章没有披露 OpenAI 对此事的回应时间线，也没有说明具体的补救方案。Nightingale 在报告中提到自己看到生成内容后情绪受到很大冲击，这从侧面说明画面的真实感和冒犯性很强。他判断这些生成结果很可能源于训练数据中混入了真实的暴力或色情影像，模型在“修复”时把这些不该有的模式还原了出来。 目前还缺几个关键信息：这个漏洞影响的是哪个版本的图像模型，触发成功率有多高，以及 OpenAI 是否已经临时限制了相关功能。另外，文章也没说 Mindgard 是否在报告前给了 OpenAI 合理的修复窗口期。

这条消息最扎眼的数字是 27 亿美元——两年前 Google 为把 Shazeer 请回来付的价码，现在人去了 OpenAI。帖子本身信息量很薄，没披露他离职的时间点、在 OpenAI 的职位或研究方向，也没说这对 Gemini 团队的实际冲击有多大。我会先打个折：Shazeer 是 Transformer 架构的核心作者之一，他的去留对任何大模型团队都是信号级事件，但光凭一条推文还判断不了 Gemini 会不会因此掉队。真正需要关注的是他为什么走——是 Google 内部资源分配问题，还是 OpenAI 给了更吸引他的技术方向，这些正文都没提。另外，27 亿这个数字本身也值得追问：当初的交易结构是什么、有没有竞业限制、他实际到手多少，这些信息缺口让“27 亿打水漂”的说法站不住脚。

这份报告最值钱的地方不是趋势判断，而是把“会用 AI 写代码”这件事拆出了可量化的台阶。新手验证成功率 15%，中级以上跳到 28%-33%，但遇到硬骨头，新手成功率只有 4%，专家是 15%。差距不在顺风局，在卡住以后怎么解套。报告给的解法很实在：别推倒重来，回到对话记录里找到第一次跑偏的那一步，从那里修正。这比大多数人“删了重问”的习惯聪明得多，因为已有的上下文对齐是沉没成本，不该扔。 另一个被反复跳过的技能是拆任务。单条指令让 AI 一口气跑到底，出错了你都不知道在哪一步歪的。拆成三到五步，每步有独立产出和验证点，跑熟了再把检查点变成规则让 AI 自己验。这不算新技能，但报告用数据说明了一个事：会写 prompt 的人多，会设计多步流程的人少，而后者才是把成功率从 15% 拉到 28% 的关键。 报告的限制也得说清楚。数据只来自交互式会话，不含 CI 管道自动调用，成功信号只看 CI 过没过、测试绿不绿、用户点没点确认，没量长期维护成本。七个月的时间跨度里模型版本在迭代，用户熟练度在涨，这些变化是多种力量共同作用的结果，不能全算在用法迁移上。

这篇文章的核心判断是：AI编程的用法正在发生质变，从人盯着AI改代码，变成把一整个任务丢给agent让它自己跑几小时甚至一两天。Goldman Sachs从2025年7月就开始试点Devin，到现在还在扩，说明大机构已经在认真用。2026年6月一周内三笔并购——SpaceX花600亿美元买Cursor、OpenAI收Ona、Salesforce花36亿买Fin——全指向同一个方向：巨头在抢长时间运行agent的完整任务数据和运行环境。 这个变化的关键不在于“做得更快”，而在于“能做的事变了”。盯着改只能处理几分钟到半小时的小任务，整个交出去才能做跨系统bug追踪、十个代码仓库的依赖重构这类需要长时间探索试错的活。人的角色从执行者变成管理者，核心价值从写代码转向判断力和品味。 但文章有个明显的信息缺口：正文明确说这类agent在独立benchmark上复杂任务成功率“还远低于交互式模式”，却没给任何具体数字。没有成功率，就没法判断现在到底能不能用、在什么场景下能用。另外，三笔并购的金额和标的都列了，但没解释为什么SpaceX这种火箭公司要花600亿买个编程工具，这背后的战略逻辑只靠“要数据”三个字撑不住。整体判断方向是对的，但落地时间线和实际可用性，还得等更多硬数据。

Vercel 开源的 eve 走了一条和 LangChain、Claude Managed Agents 完全不同的路。它把 agent 当成独立软件来建，核心主张是“一个 agent 就是一个文件夹”。文件名自动注册为工具，免掉了 LangChain 里那些把 tool 挂到 agent 上的胶水代码。Git 仓库就是 agent 本体，改一句 instructions 就是一个 commit，有 diff 可 review，有历史可追溯，每笔 commit 自动生成 preview deploy。这和 Claude Managed Agents 把 agent 当成云上一个配置项的做法截然不同——后者没有版本历史，改了什么无从追溯。 eve 内置了三项生产运行时能力：durable execution 让审批等待期间不烧算力，session 不会因为部署中断；沙箱 microVM 让 agent 写的代码在隔离环境里跑；一条命令就能让 agent 同时出现在 Slack、Discord、Teams 和 HTTP 上，session 还能在这些渠道之间自由迁移。这些能力 LangChain 不内置，Claude Managed Agents 也没有同等级别的深度。 但这里有个关键限制：eve 的 instructions.md 和 skills/ 只是装载位置，不是内容来源。官方博客也明说了，框架写不了你的 agent 实际做什么。默认的 instructions.md 示例就一行“你是一个简洁的助手”。如果你不往里塞有判断力的内容，agent 输出很可能停在共识层，换谁来问都差不多。另外，官方对多平台支持的承诺还没给时间表，目前默认跑在 Vercel 上。

这篇博客没给最终模型排名，更像一份评测方法论：把开源模型驱动的编程助手扔进真实的 transformers 库任务里，不看最终答案对不对，而是拆开整个过程算账——成功要花多少 token、走多少弯路。他们用 pi coding agent 搭了一套开源评测流水线，对比了不同模型、不同库版本下的表现。 一个关键发现是，库本身的文档质量和接口设计会直接影响智能体的成功率。他们举了个例子：给 CLI 工具加了个“技能提交”功能后，任务完成得更顺了。这说明与其死磕模型能力，不如先把工具链打磨好。 不过正文没披露具体模型间的胜负数据，也没说这套评测跑了多少样本、任务难度分布如何。如果是真的，这个思路挺省钱——不用迷信大模型，把自家工具的说明书写清楚可能更管用。但缺少量化结果，暂时只能当方法论参考，没法直接拿来选模型。