全部 · 2026-06-05

这条新闻讲的是东南大学和北大搞了个叫 MetaFine 的评测框架，专门拆开看机器人在精细操作上的理解、感知和行为三个环节，而不是像以前那样只看最后成没成功。团队说传统只看成功率的评测方式，对精细操作能力的评估会虚高最多 70%，这个数字挺吓人，说明很多机器人可能只是蒙对了结果，实际手活儿并不行。 但问题来了：正文被微信的环境验证挡住了，我根本没看到原文。具体怎么测的、用了哪些任务、测了哪些模型、样本量多大，这些关键信息全缺。70% 这个虚高比例是怎么算出来的，是实验室环境还是真实场景，也没法核实。 对做机器人评测的人来说，这个思路值得关注——把成功拆成多个环节来诊断，比给个及格分有用得多。但在看到完整论文之前，我只能给这条新闻打个折，建议直接去找原论文看。

这篇论文的思路挺直观：人睡觉能巩固记忆，模型处理长文本时也可以。具体做法是，当上下文窗口塞满要清掉旧的 KV 缓存时，不直接扔，而是先让模型离线跑 N 轮循环前向传播，把当前信息压缩更新到 SSM 的快速权重里，再清空。在 GSM-Infinite 这个无限长算术任务上，用 Jet-Nemotron 2B 试，跑 6 轮“睡眠循环”后，6 步算术准确率从 0.742 提到 0.812，涨了 7 个百分点。 不过正文没披露这 N 轮循环具体吃多少算力、延迟增加多少。如果离线跑的成本比直接扩窗口还高，那实用性就得打折扣。另外只在 2B 小模型和单一算术任务上验证过，换到更大模型或真实长文档问答场景效果未知。这点先别太激动，等看到更多消融实验和效率对比再说。

姚顺雨这次露面，核心就一句话：腾讯在补课。混元3把预训练和强化学习的基础设施重做了一遍，数据和评估方式也换了，说明之前那套可能跑不通或者效果不够好。他还提到把最强的后训练人员先调去改进元宝，这个优先级很明确——产品体验先拉起来，模型能力后面再追。 他点名代码agent、多模态和具身智能是接下来的重点方向，但正文没披露任何具体的性能指标、参数量级或者成本数据。没有数字就没法判断混元3到底追到了什么位置。代码agent这块，腾讯有微信生态和云业务做落地场景，理论上比纯模型公司有优势，但能不能做出真正好用的产品，还得看后续放出来的实测结果。 整体来看，这次回应更像是对外界质疑的一次表态，信息量有限。想判断腾讯AI到底落后多少，还得等混元3正式发布后的第三方评测。

汤道生在腾讯云AI大会上抛出一个很猛的判断：今年腾讯大部分代码由AI生成，工程师转向架构设计和指导修正。这个说法本身不意外，大厂内部推AI辅助编程已经两三年了，但“大部分”到底覆盖到什么程度，原文完全没有拆解。是按代码行数算，还是按提交次数、涉及项目占比，这些口径差异会让结论差很多，所以先别把这个数字当实锤。 另外两个数字更实在：去年腾讯在AI新产品上投了180亿元，刘炽平说今年至少翻倍；Q1财报提到他们重构了AI基础设施，搭了Hy3 preview模型。这说明腾讯在AI上的投入确实在猛踩油门，代码生成只是其中一个落地场景。 缺的东西也很明显：没有披露AI生成代码的采纳率、返修率，也没有说这些代码主要用在哪些业务线。如果只是生成大量模板代码或内部工具，和核心产品逻辑由AI主导，完全是两回事。

这篇访问记最有价值的地方，是它把“算力差距”和“模型差距”之间的落差用数字讲清楚了。美国分析师估算，到2025年底美国AI算力大概是中国的8倍，中国公司能拿到的英伟达高端卡数量比美国对手少一个数量级。但中国模型并没有因此落后几年，反而只差几个月。他们给出的解释是单位算力产出的智能是简单堆算力的4到7倍——这个数字来自分析师自己的估算，不是任何一家公司的官方数据，所以我会先打个折来看。 文章还点出了几个平时容易被忽略的结构性问题：中国的算力要同时喂给训练和数亿用户的服务，不像美国可以集中砸向训练；算力池还被十几家公司切得很碎。另外，中国几乎没有成规模的数据产业，很多公司觉得买来的数据质量不行，宁愿自己标注，这其实是一种隐性成本。 正文没披露这些分析师具体是怎么算出“4-7倍效率”的，也没给出任何一家公司的内部验证数据。整篇更像是一群聪明人走马观花后的集体印象，有洞察，但缺少可复现的证据链。

Tomasz Tunguz 把自己日常的 AI 任务拆成两条车道：简单活（邮件分类、日程安排）由 Mac 本地模型处理，复杂活才扔给云端大模型。过去一周，本地模型最高一天扛下了 88% 的任务量。这套分流设计让平均任务耗时从 47 秒降到 19 秒，排队时间从 73 秒暴跌到 4 秒，整体吞吐量提升了约 25%。 这个数据挺实在，核心逻辑就是别让小事在大事后面排队。他用的是之前蒸馏出来的技能模型，相当于把大模型的能力压缩成一个小模型跑在本地，只把真正需要“大算力”的活交给云端。类比 Nucor 的微型钢厂挺贴切：轻资产、贴近需求、只做自己最擅长的那部分。 不过得打个折。这是单人工作流的实验数据，任务类型、并发量、模型精度要求都没披露。78% 这个比例高度依赖他个人的任务结构，换一个人或换一个业务场景，这个数字可能完全不一样。另外，本地模型处理复杂任务时的错误率和回退机制也没提，如果分错类把重要邮件漏了，省下的时间可能不够补窟窿。

Grok Build 0.1 选了一条和 Claude Code 完全不同的路：不拼单个 agent 的深度理解，而是用 8 个并行子 agent 同时开工，靠速度和广度抢活。API 定价 $1/M 输入、$2/M 输出，看着便宜，但用户反馈 tool calls 太多，credits 烧得飞快。 最大的问题是证据缺口。官方公告、模型页、文档里都没有 SWE-Bench Verified 这类标准化 benchmark 的数字。OpenRouter 上甚至因为 coverage 不足被排除在排行榜外。用户实测反馈两极：有人用它重构遗留代码省了两小时站会，也有人抱怨幻觉严重、复杂任务容易死循环。 隐私条款也有坑。走 API 企业路径训练保护更强，但用 SuperGrok 订阅跑 CLI 就落在 consumer 规则下，可以 opt-out 但不是默认零训练暴露。目前它更适合当已有 Claude/Cursor 栈里的第三实验臂，前提是你能接受早期 beta 的粗糙边缘，并在自己代码库上小范围验证效果。xAI 迭代速度很快，但要从"有意思的选项"变成"默认主力"，还缺一份公开可复现的成绩单。