#xAI

今日 0 条

昨天 · 9月29日星期二

Latent Space9/29 10:44

AINews 周报：Opus 5.5 擅长生成讲解视频

Latent Space 的 AINews 汇总 9/24-9/25 动态，指出本周发布的 Claude Opus 5.5 在讲解视频生成上表现突出，并以 88.4% 领跑 SimpleBench。

9月22日星期二

AI HOT 精选9/22 01:06

马斯克称 Grok 4.7 在智能体编码上排第三

马斯克引用 Artificial Analysis 的评测说，Grok 4.7 让 xAI 在智能体编码能力上排到第三，仅次于 Anthropic 和 OpenAI。但正文没披露具体评测指标、分数或版本对比，只有排名和对手。这个排名如果是真的，说明 Grok 在让模型自主写代码、调工具这类任务上进步明显，但缺少数据支撑，建议先观望。

7月19日星期日

Computing Life · Share · 鸭哥调研7/19 08:00

Grok Build 开源了客户端执行层，模型和云端没开

xAI 把 Grok Build 在本地管理文件、命令和权限的客户端 harness 用 Apache-2.0 协议公开了，代码可以看、可以自己编译。但 Grok 模型、云端服务以及官方安装包的构建链还是闭源的。仓库不接受外部 PR，官方二进制用的内部 commit 也不在公开历史里，所以下载到的程序不一定对应公开的源码。7 月初的上传争议发生在旧版，...

推荐理由：xAI 把 Grok Build 的客户端 harness 用 Apache-2.0 放出来，支持无头模式和 ACP，不算纯作秀。但模型和构建链还是闭源，仓库也不接外部 PR，所以上限到不了 85。三个 HKR 维度都踩中了，放 featured 合适。

锐评

这次开源最实在的部分，是把 Grok Build 在本地管理文件、命令和权限的那套 Rust 客户端代码公开了。你可以逐行检查它怎么读你的项目、什么时候需要你批准才能执行危险操作。代码采用 Apache-2.0 协议，能自己编译、fork，甚至接上本地模型跑。

但别把“开源”理解成全透明。Grok 模型本身、云端推理服务，以及官方安装包的构建链都没公开。仓库不接受外部 PR，官方二进制用的内部 commit 也不在公开历史里。这意味着你从官网下载的程序，和你能看到的源码之间没有可验证的对应关系。正文没披露可复现构建方案或 SBOM，所以审计只能靠你自己编译一份来对比行为。

7 月初的上传争议发生在旧版，相关 commit 同样不在公开仓库里，这次开源没法替旧版结案。真正的好处是，今后你可以固定一个公开 commit 自己构建，去验证它到底上传了什么。信任问题没自动解决，但至少变成可以动手检查的工程问题了。

5月21日星期四

r/LocalLLaMA5/21 05:35

HalBench 基准测试：用 3200 个带坑问题测了 4 个头部模型，看谁更会拒绝瞎编

一位开发者自己搭了个叫 HalBench 的测试，专门看模型在遇到“前提本身是错的”的问题时，是会顺着瞎编（谄媚）还是直接指出问题。他拿 3200 个这种带坑提示词跑了 4 个模型：Sonnet 4.6 平均分 0.565 排第一，最敢反驳；Gemini 3.1 Pro 0.339 垫底，更容易顺着错误前提往下编。分数越高，代表模型越能识别出问题里的假...

推荐理由：HKR 三项都成立：HalBench 有个清晰的定制评测钩子，3200 条提示加分数，话题踩在模型信任和安全评测的痛点上。来源只有 Reddit 一个帖子，基准本身也没经过外部验证，所以放在低 featured 档。

锐评

这个叫 HalBench 的测试，说白了就是看模型会不会“皇帝的新衣”式地拍马屁。作者设计了 3200 个前提本身就有错的问题，比如问“为什么天空是绿色的”，然后看模型是直接指出“天空不是绿的”，还是顺着错误往下编理由。Sonnet 4.6 平均分 0.565 排第一，说明它最常直接反驳；Gemini 3.1 Pro 只有 0.339，更容易被带偏。

分数越高代表模型越“敢说真话”，但这里有个关键限制：所有题目都是作者一个人出的，没有披露题目覆盖哪些领域、错误类型是否多样。如果题目全是常识类，那测出来的只是模型的基础知识，不代表它在专业领域也能识别错误前提。另外，正文没提测试时的温度参数和重复次数，单次跑 3200 题的结果波动可能不小。

还缺什么？一是需要第三方独立出题来验证，二是没测开源模型，作者正在征集建议。如果你关心的是模型在实际对话里会不会被用户带节奏，这个测试比通用基准更贴近真实场景，但别把它当成模型安全性的全面评估。

4月20日星期一

r/LocalLLaMA4/20 19:00

Reddit 网友拿 9 个模型做功能规划对比，Claude Opus 4.6 生成的规格书最贵也最详细

一位 Reddit 用户让 9 个模型给一款 Go 语言记账 App 设计“负载追踪”功能，再用 Claude Code 给生成的规格文档打分排名。Claude Opus 4.6 排第一，产出一份 19KB 的规格书，过程中读了 44 次代码，花了 2.47 美元；GLM 5.1 排第二，Qwen 3.6 35B fp8+vLLM 排第三。作者自己强调...

推荐理由：这是一次有名有姓的个人实测，给出了真实工作流里的数据，所以 H、K、R 三项都站得住。但天花板不高：只测了一个功能、排名由 Claude Code 自己打分、正文没提人工验收结果，我会先打个折，放在 featured 里偏低的位置。

锐评

这条帖子更像一次个人实验，不是严谨评测。作者让 9 个模型给一个 Go 记账 App 设计功能规格，然后用 Claude Code 自动打分排名。Claude Opus 4.6 排第一，GLM 5.1 第二，Qwen 3.6 35B 本地部署版第三。Opus 4.6 的规格书有 19KB，过程中读了 44 次代码库，花了 2.47 美元，说明它在理解现有代码上投入了不少 token，产出的文档也更详细。

但这里有几个坑要先说清楚。第一，排名是 Claude Code 自己打的，等于让 Claude 当裁判又当选手，Opus 4.6 排第一可能有偏好加成。第二，正文没披露任何人工质量复核，不知道这些规格书实际能不能用、有没有漏需求。第三，作者自己强调这不是代表性测试，样本只有一个任务、一个代码库，换一个场景排名可能完全不同。

GLM 5.1 能排第二有点意外，说明国产模型在代码规划这类结构化任务上追得挺快。Qwen 3.6 35B 用 fp8 量化加 vLLM 本地跑也能进前三，对想省钱本地部署的人来说是个参考点。但整体看，这个实验缺的东西太多：没有对照人工写的规格书、没有评估规格书落地后的开发效率、也没有测不同模型在类似任务上的稳定性。结论只能当个谈资，别拿来选型。