AX 严选 · 2026-05-29

这条更新让 Codex 能自己创建、搜索、整理和固定对话线程，还能为并行任务启动工作树——相当于给 AI 助手加了个自动整理聊天记录和任务面板的功能。来源是 X 上的用户分享，OpenAI 官方没发技术细节，所以准确率、延迟、能同时处理多少线程这些关键指标全是空白。 从实用角度看，这解决了一个真实痛点：用 Codex 干活时对话一多就乱，手动管理线程很烦。但别把它当成模型推理能力的升级，更像界面层的自动化脚本。如果线程搜索是靠语义匹配而不是简单关键词，那还有点意思；如果只是按标题排序，价值就有限。 还缺什么：正文没披露这个功能是本地运行还是依赖云端、会不会在复杂任务树里自己搞混、以及用户能不能纠正它的整理结果。这些缺口决定了它到底是真省事还是多一个需要盯着的半成品。

OpenAI 这次没拿通用大模型硬套翻译，而是专门训了个 gpt-realtime-translate，思路是对的：实时语音翻译对延迟和稳定性要求极高，通用模型往往顾不过来。它支持 70 多种输入语言，但输出只覆盖 13 种，说明目前重点在主流语种上，小语种输出还没跟上。 官方说已经在智能眼镜上跑起来了，这是个关键场景——眼镜是离嘴和耳朵最近的设备，翻译做好了确实顺手。但正文完全没披露端到端延迟、字错率、不同口音下的表现，也没说是哪款眼镜、本地跑还是云端跑。这些数据直接决定它能不能真用，而不是又一个酷炫 demo。 另外，专用模型意味着它可能比通用模型更省算力，但 OpenAI 没给任何成本或推理速度的对比。如果延迟能压在 300 毫秒以内，准确率接近人工同传的 90% 左右，那才算有杀伤力。现在只能说方向对了，落地程度还得等实测。

OpenAI 宣布 Codex 的“计算机使用”功能现在支持 Windows 了。简单说，就是你可以在手机上的 ChatGPT 应用里启动、查看和指挥 Codex，让它在你 Windows 电脑上执行操作。官方举的场景是：工作还在电脑上跑着，你人走开了也能随时接管。 这条更新目前只有一条推文，正文没披露收费方式、具体开放范围，也没给出任何性能或延迟数据。它被标为“早期体验”，意味着大规模验证还没做，权限控制、任务稳定性、跨设备同步这些关键点都是未知数。对从业者来说，这更像一个信号：OpenAI 在把 agent 能力往桌面操作系统里推，但离生产环境可用还有距离。 还缺的信息包括：它支持哪些 Windows 版本、是否需要后台常驻程序、任务失败时怎么回滚，以及和 macOS 版的功能对齐程度。这些没补上之前，建议只拿非关键任务试试水。

OpenRouter 在 Responses API 里加了个 apply_patch 工具，模型可以生成 V4A 格式的 diff 来创建、修改或删除文件。服务器端会先校验 diff 语法，不用客户端自己处理格式问题，这点对开发者来说省了一步脏活。 但正文没披露两个关键信息：一是这个校验到底能拦住什么级别的错误——是只检查格式，还是能发现语义冲突？如果只是格式校验，那模型生成一个语法正确但逻辑错误的补丁照样会炸。二是没提支持哪些模型，是只有特定模型能用，还是所有接入 OpenRouter 的模型都能调这个工具。 另外，V4A diff 格式本身对非代码文件（比如文档、配置）的适用性也没说明。如果模型改的是 YAML 缩进或者 JSON 结构，diff 校验能不能发现破坏性修改，这点先别太激动。

ControlFoley 解决了一个实际痛点：以前的视频配音模型是“看画面自动配”，创作者没法插手。现在它支持三种控制方式——用文字描述想要的音效、用文字强行覆盖画面里原有的声音、或者上传一段参考音频模仿其音色风格，同时还能保证声音和画面动作对得上。 技术上，团队自己训了一个时空音视频编码器 CAV-MAE-ST，专门抓动作节奏和时间同步线索，避免视觉信息太强势把文本控制压死。参考音频那边做了时间-音色解耦，只取音色特征，扔掉节奏信息，防止参考音频的节奏打乱视频本身的同步。训练时用了随机模态 dropout，让一个模型能处理视频、视频+文字、视频+参考音频等多种输入组合。 在多个公开测试集上拿了开源 SOTA，跟闭源的 Kling-Foley 比，在语义对齐、时间同步和声音质量上也有优势。不过正文没披露训练数据规模和具体算力消耗，也没说在长视频或复杂场景下的表现边界。Demo 已经上线，建议自己传段视频试试，看它在你关心的场景里到底灵不灵。

哈萨比斯这次给出的时间判断很激进：AGI 最快三年内到来。他说的 AGI 不是只会干一件活的专用 AI，而是能跨领域学习、推理和创造的系统。他把现在那些能独立干活的 AI 智能体看作 AGI 的预演，这个类比挺实在——相当于说，你今天看到的自动执行任务的模型，就是未来通用智能的雏形。 不过这篇报道缺了几个关键信息。第一，他没给出判断的具体依据，是看到了内部模型的什么能力跃升，还是单纯基于研发投入增速做的外推，正文没披露。第二，“三年”这个数字需要打折：他自己也澄清这不是一个奇点时刻，而是一段持续加速的过程，所以 2029 年更可能是“开始看到苗头”而不是“全面落地”。第三，他警告各国政府和社会准备严重不足，但没说具体缺什么——是算力监管框架、就业缓冲政策，还是安全对齐标准，这些都没展开。 整体看，这话从哈萨比斯嘴里说出来有分量，毕竟他主导过 AlphaGo 和 AlphaFold。但作为一线从业者，我会把这条当作战术信号而非倒计时：大厂在加速推 agent 和多模态能力，方向上值得跟，时间表先别太当真。

这条研究给了一个很直白的工程建议：写提示词或准备微调数据时，别追求生僻或“专业”的表达，尽量用模型在预训练语料里见得多的词。FaceMind 在 100 种语言和四类任务上验证了这个规律，结论是高频表达能让模型在它最熟悉的概率空间里干活，输出更稳。 不过正文没披露具体提升幅度有多大，也没说“高频”的阈值怎么定。这点先别太激动，因为不同基座模型的预训练语料分布不一样，一个模型里的高频词换到另一个模型可能就不是了。另外，实验覆盖的四类核心任务具体是什么也没说清楚，没法判断这个规律在推理、代码等复杂场景下是否依然成立。 还缺一个关键信息：强行把专业术语替换成高频日常词，会不会导致语义精度下降。如果为了迁就频率而牺牲准确性，那这个 trade-off 就需要量化。

这份报告最值得看的是两个变化方向：一是开发者每周写的代码量翻了一倍多，从约 3.6K 行跳到 8.6K 行，千行以上的大 PR 占比也在涨，说明 AI 不只是补补小函数，而是开始撑起更大块的开发任务。二是 AI 智能体单次会话里调工具的次数多了约 30%，这意味着它接的活变复杂了，不再是一问一答，而是多步骤、多工具协作。 被采纳的 AI 代码 60 分钟后还在代码库里的比例从 76% 提到 81%，留存确实在变好，但 81% 这个数本身不算惊艳——还有近两成代码在一小时内就被删了。更关键的是，正文完全没披露样本量、统计口径，也没说是否排除了自动生成代码或模板代码。没有这些信息，代码量翻倍到底是真效率提升还是统计膨胀，没法判断。 还缺一个维度：代码质量。行数涨了，bug 率、回滚率、代码审查通过率有没有跟着变？这些才是衡量 AI 是否在帮倒忙的核心指标，报告一个字没提。

特斯拉“比人类安全10倍”的说法，核心问题出在对比基准上。它拿自己车辆气囊弹出的严重事故数据，去跟联邦统计里包含所有轻微事故的全美车辆平均数据比，相当于用自己最重的一拳去打别人轻轻一推。卡内基梅隆教授的话很直白：新车本来就比12年老车安全，这种比较说明不了FSD本身有多强。 更让人打折扣的是内部员工的证词。9名前数据标注员和1名前工程师说，FSD至今连校车停车、避让紧急车辆这些基础场景都常出错。而为奥斯汀自动驾驶出租车演示做准备时，员工得提前对路线做地图标注、针对特定危险训练软件，这种靠人工堆出来的安全表现，根本没法大规模复制。 文章没拿到特斯拉对统计方法的正式回应，也缺少FSD在真实开放道路上的第三方独立事故率数据。光靠公司自己选口径的报告，说服力有限。

阶跃星辰这次放出的 Step 3.7 Flash，核心卖点是“大模型的身子，小模型的饭量”——198B 参数的 MoE 架构，实际干活只激活约 11B 参数，意味着推理成本比同体量模型低不少。256K 上下文窗口加上能看图、读文档、调工具，定位很明确：让模型直接进业务流程干活，而不是只聊天。 ClawEval-1.1 拿 67.1 分、SimpleVQA Search 拿 79.2 分，两个榜都排第一，但正文没披露对比了哪些模型、差距有多大。τ2-bench 工具调用可靠性超过 98% 这个数字看着漂亮，同样缺具体测试条件和对手数据。模型兼容 Claude Code 和 MCP 协议，对已有工具链的团队来说接入成本低，Mac Studio M4 Max 能本地跑也是个加分项。 目前缺的信息：推理延迟、实际吞吐量、多模态任务的具体表现边界，以及除了这几个榜之外更通用的评测成绩。开源用 Apache 2.0 许可，商用友好，但能不能在生产环境稳定跑起来，还得看社区后续的实测反馈。

Tomasz Tunguz 分享了一套个人工作流自动化方案，核心是“技能提炼”：让 Opus 4.7、GPT-5.1 这类大模型把处理邮件、管投资 pipeline 等任务写成标准化的 SKILL.md 步骤文件，然后由本地运行的 Qwen 35B 或 Gemma 26B 一步步执行。这套系统基于 Pi 框架，底层用 QMD 知识库存放约 80 个工作流文件，中间层是技能文件，上层是模型调用 17 个 Rust API 的代理循环。 这个做法的好处是省钱和可解释——小模型本地跑，不用反复调大模型 API，技能文件是纯文本，能直接看、能改、能版本管理。但正文没披露任何量化结果，比如任务成功率、执行延迟、大模型写技能文件的准确率，也没说这套系统在复杂或意外输入下表现如何。Tunguz 自己也承认，小模型不需要“懂”怎么评估一家公司，只要会跟步骤走，这意味着泛化能力可能很弱，换个场景就得重新写技能文件。 目前这更像一个资深从业者的个人实验，思路有参考价值，但离可复用的产品还有距离。缺的是横向对比和失败案例分析，光靠自述很难判断这套流程的可靠性。