前两篇文章先做了大地图：录音转写与会议笔记自建选型 负责区分会议 bot、录音文件后台、字幕工具和 ASR 底座；网页录音到 AI 纪要 负责把需求拆成网页录音、成熟 ASR 和 AI 后处理三层。

这篇只补一个实操问题：如果先部署 Speakr，用户录完音以后，文字和 AI 纪要到底在哪里？

结论先说清楚：Speakr 不是“边说边实时出字”的字幕工具。它更像一个自托管的录音/上传后台：

录音 / 上传音频
  -> 点击上传进入后台任务
  -> ASR 生成 Transcription
  -> LLM 基于 transcript 生成 Summary / Minutes
  -> 在 recording detail 里查看和导出

如果你期待的是打开网页、点录音、一边说一边看到 partial transcript，那应该换 Deepgram、AssemblyAI、Azure Speech、OpenAI Realtime、FunASR streaming、sherpa-onnx streaming、WhisperLive 这类实时 ASR 路线，而不是继续把 Speakr 当实时字幕用。

如果说 Discourse 更像公开议事厅，ChatBlog 更像阶段性文章，MkDocs 更像项目手册，那么 Mattermost 更接近 ChatArch 目前缺的那一块：一个可以自托管、频道化、支持线程、适合人和 Agent 同处一室的实时工作间。

这篇文章回答三个问题：

1. 为什么我们要维护 Mattermost 这个自托管实时工作间，而不是继续只依赖飞书、Discourse 或 Zulip？
2. Hermes 要怎样接入这个 Mattermost，成为频道里的 Agent，而不是另一个需要人手工转发消息的工具？
3. 像 CC Connect 这类项目接 Slack、未来接 Mattermost，本质上是在接什么？

这次把问题重新收窄：目标不是先找一个“会议笔记大平台”，而是要确认能不能稳定搭出这一条链路：

网页录音按钮 -> ASR 实时/准实时转文字 -> AI 纠错/摘要/会议纪要

这里的关键不是 UI 有多复杂，而是 ASR 是否足够成熟：中文识别、实时 partial/final、低延迟、长录音稳定性、标点断句、说话人、成本、以及能否安全接到浏览器。

录音转写看起来像一个单点能力：给一段音频，返回文字。真的要自建时，它会很快拆成几个完全不同的问题：谁负责录音或进会？是实时字幕还是会后处理？要不要说话人？要不要摘要、行动项和问答？要不要 API、权限、队列和搜索？

如果不先把这些产品形态分开，就很容易把 openai/whisper、faster-whisper、WhisperX、一个 Gradio WebUI、一个会议 bot、一个媒体库平台放进同一张表里比较，最后得到一堆“都能转写”的无效结论。

这篇只做静态调研，关注 GitHub 上可自建、可部署或可封装的项目，重点场景是录音转写、会议笔记和后续 ChatArch/Agent 工作流集成。

这篇文章回答一个具体问题：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 猜想共同关心的核心。

上一篇 千问 Token Plan 调研 解决的是“千问 Token Plan 怎么接进 Codex、Hermes 和 CRS”。但接完以后还有一个更容易混淆的问题：模型 API 是 OpenAI-compatible，并不代表 agent 改文件也按 OpenAI Codex 的 patch 方式来。

这篇文章专门拆开这个问题：OpenAI、Anthropic、Qwen、Gemini 这些 provider 的 wire API 是一层；Codex、Claude Code、Qwen Code、Gemini CLI、OpenCode、Aider、Roo Code、Cline、Cursor 这些 agent client 暴露给模型的文件工具是另一层；最后 client 在本地到底怎么落盘，又是第三层。

有些“PPT”打开以后并不是 PowerPoint，也不是 Keynote，而是一个完整的前端应用。

Patrick Fu 的 From Spec to Loop 就是这种形态：演讲页里的 Open slides 进入的是 /talks/from-spec-to-loop/slides/ 下面的网页，URL 可以带 ?scene=1&beat=0，按方向键会推进场景，页面加载的是 Vite 风格的 JS/CSS bundle。换句话说，它不是把网页伪装成 PPT，而是把一套演示文稿当成一个小型前端项目来做。

这篇文章分两部分。

第一部分看 Patrick 这组三个公开项目：它现在做什么、已经做了什么、能做什么。第二部分转到我们自己的目的：以后有一个 idea、调研结论、项目成果或想展示/炫耀的东西时，怎么用一套固定开发流程快速做出类似的互动 Web Slides，并且能持续更新和发布。

如果你记得“有一个 Python 工具专门做数学动画、数学类视频动画”，大概率说的就是 Manim。它最早因为 3Blue1Brown 的数学解释视频而出圈，现在更推荐使用社区维护的 Manim Community Edition（Manim CE）：包名是 manim，源码在 ManimCommunity/manim，定位是“用程序精确生成解释型数学视频的动画引擎”。

这篇文章不只回答“Manim 是什么”，还回答一个更工程化的问题：如果我们要真正做视频，应该怎么把 Manim 放进一条完整的视频生产流？

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

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

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