我们做 ChatBlog，是因为经常需要临时弄懂一个东西。

可能是一个新概念，也可能是一项工具、一篇论文，或者一个需要尽快拿出方案的问题。调研结束后，资料散在链接、聊天和笔记里，下一次再遇到，往往还得重新翻找。ChatBlog 想把这些过程留下来：把零散信息整理成可以看懂的内容，帮助我们消化，也方便以后找到、继续使用。

AI 让这件事有机会做得更快。查找、整理、解释和制作页面的成本降低了，一次临时探索也能留下一个可阅读的结果。但文章生成得快，不代表知识已经被理解。我们真正需要的是有人看完以后，能比之前更清楚一点。

想用一个低延迟模型玩游戏，最省事的起点是找一套已经能运行、还能看清决策过程的项目。画面动起来只是第一步：还要知道模型看到了什么、返回了什么，以及代码有没有替它改动作。

这次筛选了十个现成项目，重点读了三套实现：PlayJev、本地 Laya 与 Jev 的对战 Arena，以及社区 Playground 里的 MicroDuck。它们分别代表画面输入、游戏状态输入和传感器输入三条路线。本文整理源码与启动方式，没有把作者报告的速度和得分当作自己的复现实测。

我用同一个火山引擎账号，把 Coding Plan 和 Agent Plan 分别接到了 Python。两套配置各调用一次 Chat Completions、一次 Responses，四次请求都返回了 PLAN_OK。

这篇文章保留完成这件事所需的步骤：在哪里拿 Key、AK/SK 如何参与密钥管理、两个地址怎样区分，以及代码究竟返回了什么。示例里的凭据均为占位符；完整密钥不进入文章、仓库或下载包。

一张快速排序图，至少要把三件事画清楚：哪个数是基准，分区后哪些数在左边、哪些在右边，以及递归排序改变了什么。只给模型一句“画一张快速排序图”，这些决定就都交给了它。

下面这张图来自一次实际的 CRS 图像生成请求。输入数组、基准和分区结果先写进提示词，再让模型安排数字方块、颜色和箭头。

Remotion（github.com/remotion-dev/remotion，约 5.7 万 star）是一个用 React 写代码来制作视频的框架。它的核心心智模型是：React 代码就是视频的"源文件"——你写一个 React 组件，Remotion 会按时间轴把它一帧一帧渲染出来，最终编码成真正的 MP4 视频。

这篇文章不追求大片质感，只走一遍最小闭环：脚手架 → 理解代码 → 真实渲染 → 分享 MP4 → 嵌入博客。

我们要回答的不是“能不能点网页发一篇 B站内容”，而是 ChatPost 这种发文/投稿编排层应该接哪条稳定边界：官方 API、浏览器插件、还是第三方 CLI。

结论先说：B站官方开放平台已经有视频稿件管理和专栏稿件管理 API；插件路线当前看到的是专栏图文草稿，不是视频投稿；官方没有发现可直接投稿的 CLI，第三方 CLI 以 biliup 系列为代表，但它们不等于官方接入路径。[1][5][8][14]

前两篇文章已经把 Mattermost 放进了 ChatArch 的版图：它是一个自托管实时 Agent 工作间，也是一个和 Slack、飞书心智都不完全一样的 channel / post / thread 系统。接下来真正会遇到的问题是：如果一个 Mattermost thread 里同时有多个 Agent，它们到底共享什么历史？谁能唤醒谁？命令边界在哪里？ChatRSS 又应该接在哪一层？

这篇文章只写成一篇，不拆成系列。全文分成三个大节：第一节讲已经跑通的双账号接入和命令边界；第二节讲 thread、session、history 与 Agent 互相 @ 的规则；第三节讲 ChatRSS 在 TriggerEvent、Router、Action 和 Ledger 层应该承担什么角色。

这篇文章回答一个具体问题：Codex 里的 Computer Use / bundled skill / plugin 在做什么，Hermes 有没有同类能力，社区有没有正在把这些东西打通的 PR 或 issue？

结论很直接：Hermes 已经把 Computer Use 做成了一个模型无关的 computer_use toolset，底层通过 MCP stdio 连接 cua-driver；Codex 也已经出现了 computer_use feature requirement、bundled plugin / skill 发现路径和桌面端问题单，但它现在更像是围绕 Codex Desktop 与 bundled plugins 演进的一套能力。CUA 社区正在推进一条更通用的路线：让 cua-driver 作为 MCP 层进入 Codex、Claude SDK 和其他 agent harness。

2026 年 ICM 公布菲尔兹奖名单时，Hong Wang（王虹）的官方 citation 看起来像一串专业名词：harmonic analysis、geometric measure theory、multiscale、decoupling、local smoothing、Fourier restriction、Falconer distance sets、Furstenberg sets、Kakeya problem。

如果只把它翻译成“调和分析与几何测度论”，读者很难知道她到底做了什么。

更好的理解方式是：王虹的工作解释了波、频率、分形和细长管子之间隐藏的同一套几何结构。一个函数的频率如果集中在曲面附近，它在空间里会像很多细长的波包或管子一样传播；而这些管子如何相交、如何覆盖空间、如何在不同尺度上聚集，正是 Fourier restriction、波方程 local smoothing、Falconer 距离问题、Furstenberg 集和 Kakeya 猜想共同关心的核心。

上一篇文章讲了 Manim 的定位：它是一个 Python-first 的数学动画生产工具，但完整视频生产并不是 pure Python-only，还会涉及 LaTeX、Cairo/Pango、FFmpeg/PyAV、素材、旁白、字幕和发布。

这篇换成一个更落地的问题：如果今天只想从零生成一条“能看的小视频”，最小闭环应该怎么走？

我们用一个 14 秒左右的“水滴入水后的圆形波纹”来演示。它不追求大片质感，只追求流程完整：先想清楚解释目标，再写代码，再真实渲染，再把 MP4 放到文章里。