全部 · 2026-05-29

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

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

Glean 把企业 AI 搜索的年收入做到了 3 亿美元，一年翻了三倍，这个增速放在巨头扎堆的赛道里确实能打。但它的新卖点转向了帮客户砍 AI 预算，而不是功能本身有多强，说明市场已经从“试试 AI”进入“算账阶段”。 问题在于，正文只给了收入数字，没披露利润率、客户数量，也没讲清楚具体怎么帮企业省钱——是压缩 token 消耗、减少模型调用次数，还是用更小的模型替代。这些信息缺口让“省钱”这个核心卖点暂时没法验证。 如果 Glean 能证明它帮客户省的钱比收的订阅费多，这个模式就站得住。否则，收入翻倍可能只是早期客户集中采购的结果，后续续费率才是关键。

这个模型的核心卖点是“大模型的身子，小模型的胃口”。196B总参数听着吓人，但混合专家架构让它每次推理只动用11B参数，对显卡和内存的压力小很多。官方说128GB内存就能在本地跑，还内置了1.8B参数的视觉模块，可以直接看图，这对想在本地玩多模态的人来说是个好消息。 不过现在能说的也就这么多。Reddit原帖被网络屏蔽，我们拿不到任何实测数据、跑分对比或者社区反馈。官方宣称的本地运行条件、推理速度、实际显存占用，以及那个视觉模块到底好不好用，正文都没披露。这点先别太激动，等有人真跑起来再说。

这条新闻最值得看的是那个具体数字：一个人，一个月，6030亿Token。按公开费率算价值130万美元，一年就是上亿人民币。就算换成国内最便宜的开源模型，也要两三百万。这个量级把“AI编程很贵”从一个模糊印象变成了可计算的成本。Uber今年头四个月就烧完了全年34亿美元的AI预算，微软也因为费用超标放弃了Claude Code，说明连巨头都在踩刹车。 不过得注意，这个130万美元是按预设费率算的账面价值，不是实际支出。OpenAI员工内部调用不花钱，真实的企业采购价会有折扣，但折扣再大也扛不住这个用量。文章没提他具体用的是什么模型组合、有没有做缓存或批处理优化，这些都会大幅影响最终账单。 对从业者来说，这条信息的实际含义是：公司几乎肯定会限制程序员调用外部模型，要么设额度，要么逼团队用本地部署的开源模型。AI编程替代程序员这件事，在Token费用没降到地板价之前，账根本算不过来。

阶跃星辰这次放出的 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 许可，商用友好，但能不能在生产环境稳定跑起来，还得看社区后续的实测反馈。

这篇文章把 Claude Code 动态工作流的设计逻辑讲得很透。核心判断是：agent 长期跑会忘事、自己验自己不靠谱，所以 Anthropic 把控制流交给不会忘的 JS 脚本，把需要灵活探索的执行交给子 agent，把验证拆成多 agent 交叉检查。这个分工思路比“换更强模型”或“全用代码锁死”都更务实。 文章举了 Bun 从 Zig 迁移到 Rust 的例子：75 万行代码，十一天，靠的就是脚本拆任务、并行执行、多 reviewer 验证。数字本身说明这种分工在代码迁移这类可预先规划的任务上效率很高。但文章也坦诚指出了限制：脚本不能中途改策略，验收标准还是得用自然语言写，agent 可能严格跑完流程但结果不对，因为标准本身就写偏了。而且脚本是 Claude 生成的，如果脚本逻辑有缺陷，整个流程会可靠地执行一个错误计划。 信息缺口在于：正文没给出动态工作流相比纯 agent 模式在任务完成率或错误率上的量化对比，也没说明脚本生成失败或需要人工修正的比例。这些数据会直接影响“把编排交给代码”这个主张的可信度。

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