跳到正文
10月22日周四
  1. GitHub Blog50

    GitHub 如何为智能体规模的 Git 流量搭建过渡架构

    GitHub 正把最繁忙的仓库迁入 Azure,通过将写入仲裁的串行化范围从整个仓库缩小到单个引用,解决跨区域约 25ms 往返带来的吞吐瓶颈。内部真实流量测试中,对不同引用的写入吞吐量提升 3–4 倍且延迟更低。目前多数仓库的五个副本已有两个位于 Azure,Azure 承担约一半 Git 流量。

10月21日周三
  1. lauren53

    Grok Bot 工程负责人 Lauren Tan 分享一种找 bug 的工作流:先让 Agent 画出用户流程的状态图,再用 pstack 的 /create-formal-verification-skill 生成的技能通过 TLA+ 等方式做验证。她称这样既能更好理解代码和用户流程,也能修复用户原本会看到的问题;被引用的 pstack v0.15.27 更新介绍称该元技能可按需创建形式化验证套件,作者实验中已用它发现多个 bug。

    引用lauren@poteto

    pstack v0.15.27 ships with a new skill /create-formal-verification-skill! it's still in beta, and similar to /create-verification-skill, this is a meta-skill that creates a new skill and formal verification suite based on the characteristics you want to verify. for example, you may want to model state machines and systems with concurrency using TLA+, or use kani in rust to check for undefined behavior. if you're new to formal verification, think of it as mathematically proving properties and invariants (something that must always be true) or "laws" of your system. usually, this means modeling your programs in a separate language like with TLA+ and then running the solver on that spec. newer approaches like with kani and @bendlang take a different approach where there is no separate language: you write kani in rust, and bend in bend (it's also a programming language, and the proofs are written as laws and expressed in its type system). historically formal verification never reached mainstream status because of the difficulty in modeling and writing proofs. it's quite difficult to model your business requirements and keep them in sync! but i expect that we will see more innovation in formal verification in the future as being able to formally verifiy that the code does what you intended gives your agents superpowers in writing correct software. in the meantime though, i've been experimenting with modeling our code with TLA+ and have already found several bugs with the skill created by /create-formal-verification-skill. try it out and let me know how it goes!

  2. Databricks:Blog43

    Hamlet 如何用 Databricks Lakebase Postgres 拿生产数据测试改动

    Hamlet 借助 Databricks Lakebase Postgres 为每个 pull request 建立独立的生产数据分支,让工程师和 AI 编码智能体在不触碰生产环境的情况下用真实数据测试改动,合并仍需人工审批。Hamlet 索引全美超过 7,200 个治理机构的会议,平均每场会议约三个半小时,AI 负责定位值得关注的片段并回链视频原文。

  3. Tessl:产品与工程博客61

    Tessl 团队分享:不再逐行审查 AI 生成代码,改为验证意图

    Tessl 工程师 Ankit Jain 分享团队 PR 量翻四倍、代码几乎全部由 AI 生成后,放弃逐行 diff 审查、改为在代码生成前审查意图并逐条验证验收标准的做法。关键实践包括维护 offer-skill 技能理解代码变更,以及把重复出现最多的审查评论固化成机器自动执行的不变量规则,作者预计第二个月起审查负担明显缩小。

    推荐理由:作者团队 PR 量翻四倍后放弃逐行审代码,改为事前审意图加可验证准则,给出了可直接照搬的做法和时间预期。

10月20日周二
  1. Google Developers Blog70

    Google 发布 TorchTitan TPU 分叉并给出模型优化 Playbook

    Google 推出 TorchTitan TPU 分叉(github.com/google-pytorch/torchtitan),配合 TorchTPU 原生后端在 Cloud TPU 上训练 PyTorch 模型,提供 SimpleFSDP、Graph Trainer、Pallas 内核和优化 Playbook。

    推荐理由:原文给出从基准到编译、内核、内存的完整 TPU 优化顺序,以及 FLUX.1、Qwen3 235B 等实测数字,可迁移到自己的训练工作流。

  2. MiniMax Design (H3)40

    我们的创作者社区总能带来惊喜……💜

    引用aicreataro@aicreataro

    「2Dを3Dに繋ぐ」 生成した動画にアイデアを重ねたらどこまでやれるんだろう、と頑張ってみた軌跡です。 左上が元の生成、右上が完成、下がBlenderの画面。 ■やったこと 1. MidjourneyでKVを作る 2. MiniMax H3で10秒の走りを生成 3. 同じ動きのまま、素材だけ変えて7本に(絵の具/クローム/粉/墨/花/水/糸) 4. 前半の2Dは、Pythonでポーズごとに素材を切り替える 5. 2Dと同じ見え方の3D空間をBlenderに作り、つなぐ 6. 3Dでは、素材の軌跡の中にカメラが入っていく 7. 抜けて引くと、欠片が集まって巨大な走者の絵になる 8. 光の筋や床の映り込みも、Blenderの中で足す ■わかったこと ・生成とツールを組み合わせるとクオリティUP ・2Dを3Dに繋げば多少リッチな表現に AI生成で元からかっこいい素材を出せばいいのかもしれませんが、こういったアプローチもありそうだなと参考まで。

  3. MiniMax Design (H3)41

    🥁💥💃

    引用aicreataro@aicreataro

    「音と動きをビジュアライズ」 Opus 5.5×Blender×Python ■素材 ・人物:MiniMax H3 ・キービジュアル:Midjourney ・音楽:MiniMax Music 3.0 ■Blenderとコードでやらせたこと ・音が大きいほど、絵が立体になって手前に飛び出す ・速く動いた所ほど、粒になって浮く ・打った瞬間に時間が止まり、カメラだけが回り込む ・止まっている間、空間ごと色と照明が切り替わる ■わかったこと ・生成だけでは出ない絵も組み合わせるとできる ・やりすぎるとだめ ・映像の動きにも反応させたら、映像そのものが鳴っているように見えてきた ・飛び出す量は曲の音と、素材の動きに任せた 実験的な映像ではありますが、何かの表現に使えそうだなと思います。AIをより拡張できる方法を探っていきたいです。 音と動きの両方で絵が動くと、なんか面白いですね。

  4. OpenBMB58

    面壁智能 OpenBMB 转发 @aiwithsilly 的演示,用 MiniCPM-V 4.7 35B-A3B 在本机跑自动化报告生成,输入结构化数据与图表,输出含记分卡、分部拆解、利润率驱动与多空观点的长篇 markdown 报告,无需 API 和云端。演示称模型一次读取图表和密集表格并关联数据推导结论,得益于 35B 总参数仅约 3B 激活的 MoE 架构,GitHub 和 Hugging Face 已提供下载。

    引用Sally Stockholm@aiwithsally

    I built an automated report generator that runs entirely on my own machine. Input: structured data + charts. Output: a full long-form report — earnings interpretation, weekly summaries, whatever you need. No API. No cloud. No monthly bill. -> Here's MiniCPM-V 4.7 35B-A3B doing exactly that 👇 It read the charts AND the dense tables in one pass, then streamed out analyst-grade markdown: scorecard, segment breakdown, margin drivers, cash flow, even a bull/bear case. The part that got me: it didn't just OCR numbers. It connected them — input costs → margin pressure → guidance risk. That's the jump from "text extraction" to "actual analysis." Why this works locally: → 35B total params, only ~3B active (MoE) → Efficient visual encoding keeps multi-chart inputs cheap → Structured markdown output — goes straight into your doc pipeline Try it GitHub: http://github.com/OpenBMB/MiniCPM-V Hugging Face: https://huggingface.co/collections/openbmb/minicpm-v-47

  5. 公众号:面壁智能68

    面壁智能解析前瞻专家调度 LES 如何让 35B MoE 在手机端侧实时无损运行

    面壁智能 MiniCPM-V 团队介绍支撑 MiniCPM-V 4.7 端侧运行的前瞻专家调度(LES)技术,称首次实现 35B-A3B 规模 MoE 在端侧实时无损运行,iPhone 18 Pro Max 实测解码超 20 token/s。

    推荐理由:原文拆解了 LES 在调度、存储、计算三层的具体设计,并给出消融数据,方法可迁移到其他 MoE 模型的端侧部署。