AX 严选 · 2026-06-09

马斯克公布了 SpaceX 的 AI1 轨道 AI 数据中心卫星方案，简单说就是把算力服务器塞进卫星，用 Starship 打上近地轨道。每颗卫星持续算力约 120 kW，相当于一个 NVIDIA GB300 机架，卫星之间用激光互联，带宽 1 Tbps，往返延迟 6-8 毫秒。这个延迟数字比地面光纤跨洲要快，但比本地数据中心还是慢一截。 计划很庞大：2027 年底前量产，远期要部署上百万颗卫星，做到吉瓦甚至太瓦级算力。但正文没提最关键的两件事：一是 120 kW 的功耗在真空里散热到底靠不靠谱，双面散热器标了 1,400 W/m² 的排热能力，但没给实际工作温度和环境假设；二是 Starship 的发射成本和频率能不能撑起百万颗卫星的部署节奏。 我会先打个折。轨道数据中心在延迟敏感型推理任务上可能有场景，比如给地面基站做边缘算力补充，但要替代地面数据中心，供电、散热、维护、退役回收全是硬骨头。正文没披露单颗卫星的成本、寿命和故障率，这些数字不出来，太瓦级算力就还是个概念。

这份通知不是远景规划，而是直接给各省和央企下了任务量：每个省至少找20个真实场景单元，央企至少10个，年底前要看到人形机器人在工业、服务、特种领域里常态部署，目标是凝练出100个以上高价值场景，带动万台级落地。 我会先打个折。通知里“万台级规模落地能力”指的是能力储备，不等于实际卖出或部署了一万台。而且“常态部署”的定义很模糊，是每天干满8小时，还是每周演示一次，正文没给标准。通知要求用户单位出具应用验证报告，但验证指标怎么测、谁出钱做环境改造，都没细说。 值得留意的是，通知鼓励“人形机器人即服务”和按效用付费，这是在尝试降低用户的一次性投入门槛。但整篇没披露专项资金安排，也没说验证失败怎么办。如果成本、安全和可靠性数据不公开，年底的“作业模式”可能还是演示模式。

这个评测的狠劲在于把标准从“跑通测试”拉到了“维护者愿不愿意合入”。Cognition 直接点名 SWE-Bench 这类老评测，说里面超半数通过的代码其实是没法维护的垃圾，这话虽然冲，但点到了现有评测的软肋。150 道题，每道平均花 40 小时以上，配了 3000 多条审核规则，投入量级比多数学术评测大得多。 结果挺惨淡：Claude Opus 4.8 在最高难度档拿到 13.4%，GPT-5.5 只有 6.3%，其余模型在 1% 到 5% 之间。这说明即便最强模型，写出来的代码在真实维护场景下九成过不了关。不过要注意，题目和审核规则都是 Cognition 自己组织维护者做的，评测方和被评方没有利益隔离，这点先别太激动。 还缺什么：正文没披露这 20 多位维护者来自哪些项目、有没有利益冲突声明，也没说题目覆盖的语言和框架范围。如果全是特定生态的题，结论的普适性就得打折。另外，维护者“愿不愿意合入”本身有主观成分，3000 多条规则能压住多少主观偏差，也需要更多信息才能判断。

GitHub 上 122K 星的 Skills 仓库加了个 Teach 技能，思路是把一个普通文件夹变成能记住你学到哪的学习空间。它用四个文件干活：MISSION.md 写目标，lessons/ 放课程，learning-records/ 记你已经掌握的东西，reference/ 自动生成速查手册。五个机制里比较有意思的是 ZPD，会根据你的学习记录动态调整难度，不是死板的线性课程。 安装方式很简单，一行 npx 命令就能跑。适用场景从魔方到软件基础都行，说明设计上没把自己框死在编程教学里。但正文没披露任何关于学习效果、完成率或者用户反馈的数据，122K 星是 Skills 仓库整体的，不是 Teach 这个技能的。 还缺几样东西：learning-records 的格式长什么样、ZPD 调整难度的具体规则、reference 手册的生成质量如何。这些不补上，很难判断它到底是真有用还是概念好看。

这篇博客是一份操作手册，教你怎么把 GitHub Actions 的 CI 流程迁移到 Hugging Face Jobs 上执行。核心思路不复杂：在 HF 这边起一个临时“自托管运行器”，GitHub 把任务派给它，跑完就销毁。他们拿 Trackio 项目试了水，CPU 任务耗时缩短了约 30%，还新增了 GPU 测试套件，可以用 t4-small 或 h200 这类硬件。 对开源项目来说，这解决了两个实际痛点：一是 GitHub 免费 runners 排队慢、偶尔维护，二是 GPU CI 基本用不起。方案把调度权留在 GitHub，执行搬到 HF，等于白嫖了更快的 CPU 和按需 GPU。但正文没披露成本细节——HF Jobs 的 GPU 时长怎么计费、免费额度够不够日常 CI 消耗，这些都没提。另外，这套流程需要自己搭一个 dispatcher Space 并注册 GitHub App，维护成本比原生 Actions 高，小项目不一定划算。 还缺什么：没有和 GitHub 原生 runners、其他 CI 平台做横向对比，也没给出大规模并发下的稳定性数据。如果你仓库的 CI 量不大，迁移收益可能不明显；但如果你缺 GPU 测试环境，这条路值得试试。