自动整理自 Telegram 讨论组，每天更新。内容为 AI 摘要，仅作信息索引与回顾。

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】Emacs 内的 PDF 阅读器重构：emacs-reader

本日最具深度的技术讨论围绕群友 0WD0 对 emacs-reader 的激进重构展开。这是一条从"改良现有包"到"重写核心架构"的完整技术脉络：

现状与痛点

• 原 emacs-reader 仅作为光标位置提示工具，渲染逻辑基于图片，内容不可选中
• 讨论者吐槽"没有像素滚动很难受"，尤其欧美教科书左右对称的大页边距导致每次翻页都要重新调整位置
• 第三方 PDF viewer（如 Sioyek）虽有 remote control 能力，但群友列举了第一方实现的压倒性优势：书签、多窗口对比阅读、自然复用 Emacs 键位、基于主题的 dark mode、方便 org-capture、Emacs 内 SyncTeX 正反向跳转、批注直接在 Emacs 里编辑

技术决策演进

• 将包重构为整窗口显示，解决了放大画面时拖动文本卡顿的问题
• 连续滚动（平滑滚动）已实现，讨论者声称"能到 60fps"
• 中键拖动已加入
• 裁边方案："自动裁边也是自动放大——识别边框位置然后放大对齐，不用真的裁边"
• 计划将 C module 换成 Rust module，理由是后续要加 link hint 等 UI 向功能，C 写起来太麻烦
• 渲染库确定研究 MuPDF，用于解析和渲染，方便嵌入式使用
• 项目地址：https://codeberg.org/0WD0/emacs-reader

衍生讨论：Canvas API 取代 SVG

• 群友发现 Emacs 的 SVG 不支持动画（"No"），每次整块重绘成本高
• card-game.el（用 SVG 画的小丑牌）确认了整块重绘导致 CPU 占用高的痛点
• 有人提出 Emacs 的 Canvas API 提案（https://yhetil.org/emacs/868q665s64.fsf@gnu.org/），认为用 canvas 绘制会更高效

【专题】Telega 跨平台部署实战

Telega（Emacs 的 Telegram 客户端）成为另一热点，从"怕封号"到"各平台编译 tdlib"均有深入讨论：

封号疑虑澄清

• 有群友担心用 telega 被封号，被明确纠正："telega 和所有其他第三方客户端一样，都是用的 tdlib。只要没有修改 tdlib 的行为，就不会有封号，封号都是个人行为"（如新号频繁加群/发消息）
• 有人提到"懒猫来过，好像是用了 telega 被封号了"，被反驳"狗屁，谁知道他自己做什么的"

各平台编译/安装经验

• macOS：直接 brew install tdlib --head（其实也是编译），或用 roife 的脚本自动读取 telega 要求的 commit 并安装对应版本
• Windows：需自己编译，主要难点是 tdlib 的 dll 依赖大量 msys2 的 dll，光打包 libtdjson.dll 没用（用 ldd 一看便知）；start-process 对 Windows 兼容性差，有编码问题导致 stderr/stdout 混合、疯狂打印消息（issue #598）
• Guix：guix 的 telega 能自动带上 tdlib，最省心
• 版本对应是硬约束：telega 和 tdlib 必须严格版本匹配，讨论中出现 TDLib version=1.8.65 < 1.8.66 (min required) 的报错，差一个 minor 都不行

【专题】Windows 上的 Emacs：卡顿溯源与性能调优

这是一场典型的"Windows Emacs 劝退→和解"讨论，最有价值的是一组具体的卡顿根因：

卡顿根因排查

• 字体 fallback 陷阱：κόσμος 分享了自己 Windows 上卡爆的真正原因——"没装 nerd-icons 的字体，然后开了 nerd-icons-*-mode。fallback 会把所有字体对每个 glyph 都试一遍，最后就卡爆了"。macOS 上同样有此问题
• 冷加载 vs 热加载：启动从半分钟降到 2 秒（WSL 下），"不知道干了啥突然就快了"，群友分析可能是冷加载变热加载
• Windows Defender：被指出可能是隐性卡顿源，有群友调侃"Windows defender 不是到手关掉吗"

Magit 在 Windows 上的定制优化

• zdn 提供了完整的 magit 配置，核心优化是砍掉 diff 文件的立即插入，打开速度提升 70%，"项目越大速度越明显"
• 自定义 status sections：只插入 unstaged/staged 文件列表（带颜色标记 M/A/D/R/C/U），用 magit-git-lines "diff" "--name-status" 获取，不渲染完整 diff 内容
• 看 diff 内容改用 VC（Emacs 内置版本控制）
• 作者对 magit 的性能问题"似乎不是很关心"

Dired 中文路径修复（Windows 专有）

• zdn 分享了修复 dired 使用外部 ls 程序不支持中文路径的完整 advice 代码，核心矛盾在于：Windows 的 w32 subprocess argv 限于 ANSI 代码页（cp936），而 MSYS2 ls 输出 UTF-8。解决方法是在 insert-directory 调用内动态绑定 file-name-coding-system 为 ANSI 代码页、coding-system-for-read 为 utf-8

【小专题】Neovim vs Emacs：设计理念之争

虽然只有短暂交锋，但观点鲜明，值得记录：

• zdn 的核心论点：nvim 功能太少，lsp/treesit/补全/格式化全要自己配，还要装 Mason 管理；配置体验不好；Windows 上比 vim 都卡
• 反方观点：理念不同，"nvim builtin 的东西很多都没人用"，实用配置在各插件 README 写得很清楚
• 用户画像梗："nvim 用户给我一种 nvim+rust+archlinux 的错觉"
• Emacs 的优势确认：内置 treesit、lsp（eglot）、格式化、补全；Emacs 更偏向组合类
• 共识吐槽："这两个编辑器啥时候都是多线程就好了"——nvim 是协程"装作多线程"

🔑 关键概念与技术解析

• tdlib：Telegram 官方跨平台客户端库，telega（Emacs 的 Telegram 客户端）通过它通信。编译产物是 libtdjson，但它依赖大量其他 dll/so，不能单独分发。telega 与 tdlib 必须严格版本对应。

• telega：Emacs 内的 Telegram 客户端，基于 tdlib（通过 telega-server 子进程）。不强制依赖 company 或 all-the-icons，可配 Corfu 和 nerd-icons。被封号风险与官方客户端相同，封号源于用户行为（如新号异常活跃），与客户端本身无关。

• Mason / mason.el：Neovim 生态中管理 LSP server、formatter、linter 的工具；Emacs 有对应物 mason-org/mason.el，同样用于管理 LSP 等工具。

• MuPDF：轻量级 PDF 渲染库（Artifex 出品），以高性能和易嵌入著称。emacs-reader 计划采用它做解析和渲染。

• TUI Emacs vs GUI Emacs：TUI 模式启动快但功能受限（如 org latex preview 暂时不行）；论坛上用户以 GUI 为主。Windows 的 GUI Emacs 渲染后端是 GDI（Graphics Device Interface），走 CPU 渲染，"gdi 有个抓屏功能，ffmpeg 用的就是这个"。

• epkg：Emacs 包元数据工具，M-x epkg-describe-package 查看包的依赖。注意：epkg 收集的是"整个包的依赖"，因此如果某个 contrib 插件 require 了 all-the-icons/company，这些也会被算进主包依赖，可能造成误导。

• org-capture：Emacs 的快速记录机制。群友观点分歧：有人"只用来记录 org-agenda 的 TODO 事项"，日常笔记用 Denote；有人认为"招之即来挥之即去的记录窗口"和"常驻窗口"是两种不同交互，不习惯就换，没必要硬适应工具。

• pixel-scroll-precision / ultra-scroll：Emacs 的像素级滚动。注意滚动时会让 beacon 插件（光标位置高亮）闪烁，需加入 beacon-dont-blink-commands 排除。

• Citer：基于 ctags 的 Emacs 补全方案。zdn 平时很少用 eglot，而是用 citer，说明对小规模项目/特定语言，轻量方案仍有一席之地。

💎 碎片知识与金句拾遗

• "使用 emacs 就是一场和世界和解的旅程"——本日金句。
• "与 wslg 和解了"——κόσμος 在 Windows 上折腾一圈后的最终归宿：用 WSLg 跑 Emacs，"win 上 2 秒启动，换 linux 怕不是 0.2 秒就启动了"。
• Emacs 长生命周期："一个进程开了一周"、"昨天我把我开了 80 小时的 Emacs 不小心 C-x C-c 杀了"。群友自嘲"和 DeepSeek 玩角色扮演忘了保存了，杀妻证道了属于是"。
• Windows Emacs 内存优势：zdn 实测 Windows 上稳定 100MB 左右，不开 eglot 能到 60-70MB。
• org file 跳转到 PDF 指定页：[[file:/path/to/file::page]] 点击即可跳转，配合 org-file-apps 调用 Sioyek 等外部 viewer，"没有任何用各种 page 对应 heading 的包的理由"。
• beacon 与像素滚动的冲突：像素滚动会触发 beacon 闪烁，需要 (add-to-list 'beacon-dont-blink-commands 'pixel-scroll-precision) 和 ultra-scroll 来排除。
• emacs-reader 诡异启动行为："如果在启动的时候直接加载这个包，它会立刻启动所有线程"，疑似对 saveplace 或 recent files 的 hook 触发。
• org 表格网格线：有人需要"九宫格式"网格显示而非简单线条。方案：加 overline/underline 或直接用 table.el；"要求高你就用 table.el"。现有群友的 grid-table 方案尚未给出配置。
• Windows Defender 是隐性性能杀手：被指出可能是 Emacs 卡顿元凶之一，群友共识"到手关掉"。
• Lisp 与 AI 语料的遗憾："还是 lisp 壬不争气，没产出足够多的语料让 ai 大人炼化。要是 ai 写 lisp 比较强的话，dsh 直接用 cl 直接一步到位"。
• "一切皆插件"的反思：κόσμος 回忆自己小时候写程序也搞了"一切皆插件"架构，"但客观上只是在拖延写实际功能"。真正的"一切皆插件"实践者其实是 Emacs 本身——"emacs 本体都是加载了必要配置后 dump 出来的"。
• 手机写 org 的终局方案：有人折腾出了"手机上正常写 org"的方案，代码编写等需求以后再考虑，"反正能直连 termux"。
• goggles 替代 beacon：有人觉得 beacon 性能差，推荐用 goggles。
• 一个 Emacs 进程开 80 小时是常态，Emacs 的稳定性被反复侧面印证。
• Roife 的 telega tdlib 安装脚本（https://github.com/roife/.emacs.d/blob/master/scripts/install-telega-tdlib）能自动读取 telega 当前要求的 commit 并安装对应版本，被多人采纳。
• zdn 的 hideshow 折叠保存：轻量级 hideshow 折叠状态持久化插件（https://github.com/zHaOdANiuu/.emacs.d/blob/main/extension%2Fhideshow-savefold%2Fhideshow-savefold.el）。

🛠️ 值得深入研究的点 (Follow-up)

• emacs-reader 重构版（https://codeberg.org/0WD0/emacs-reader）：讨论者已实现连续滚动、中键拖动、整窗口显示，并计划换 Rust module、研究 MuPDF 渲染。这是 Emacs 内 PDF 阅读体验的一次大胆实验，值得关注其裁边与多窗口对比阅读的落地。

• Emacs Canvas API 提案（https://yhetil.org/emacs/868q665s64.fsf@gnu.org/）：若 Canvas API 进入 Emacs 核心，将彻底改变 Emacs 内图形绘制方式（从 SVG 整块重绘到增量绘制），对游戏、图表、PDF 渲染等都是重大利好。

• cat-emacs/org-mode（https://github.com/cat-emacs/org-mode）与 0WD0/org-mode 的 wd 分支：后者已合入 org latex preview（TUI 下也可用），说明有人在认真推动 org latex preview 的异步化与主分支合并。

• clutch 的 pg 协议更换：群友 Lucius_Chen 维护的 clutttch 从 pg-el 换协议库，原因是 "pg-el 会把 NULL/false 混淆"。对 Emacs 生态的 PostgreSQL 交互库是个信号——pg-el 存在语义混淆问题，值得关注替代方案。

• Windows Emacs 的 insert-directory ANSI/UTF-8 编码矛盾：zdn 给出的 advice 是一个典型的 Windows 平台历史包袱案例（w32 子进程 argv 限于 ANSI 代码页）。对于在 Windows 上使用外部程序（ls、magit 等）的 Emacs 用户，这是必读的参考实现。

• magit 性能的 Windows 定制方案：zdn 提供的 status sections 重写（只插文件列表不插 diff 内容）是可复用的优化思路，适合大量使用 magit 但被大仓库卡顿困扰的用户。

🧠 Hermes GPT-5.5 观点延伸

中心判断：今天三场讨论——emacs-reader 重写、card-game 卡顿、magit 自改——背后是同一条边界：瓶颈在包（userland）还是在引擎（core）。认对边界，小改动翻盘；认错边界，重写白费。

1. emacs-reader 的重写立刻见效，因为痛点在 userland。 原版的毛病是渲染成图片、内容不可选、没有像素滚动，跟红显引擎无关。0WD0 把画布铺满窗口、加连续滚动和中键拖动，换来当事人称能到 60fps 的平滑滚动和"放大拖动不卡"的反馈。他说"感觉和原本的版本没太大关系了"——收益来自换掉 userland 实现方式。注意顺序：是"没有像素滚动很难受"的功能痛点倒逼架构，不是架构先行。

2. card-game.el 是反例：整块重绘的 CPU 成本在 core，重写包救不了。 SVG 无动画、每次全量重绘，瓶颈在 redisplay 路径，所以讨论的出口不是 fork 更快的卡牌包，而是提 Canvas API 提案推上游。可推广的判断：动手重写前先问"瓶颈在包还是在引擎"。 包的问题 fork 自救；引擎的问题只能等 core。magit 也适用：zdn 砍掉 diff 的立即插入提速 70%，因为那部分瓶颈确实在 userland。

3. magit 同时暴露"自改文化"的代价。 "作者似乎不是很关心"——advice、hook、自定义 sections 让 workaround 太便宜，便宜到上游没压力修 bug；于是每个工作区补丁都变成个人债务，上游一升级就得跟着维护。这不是玄学：看 magit #5320 挂了多久、多少人像 zdn 一样自写 sections 便知。更值得警惕的是：Emacs 的自由不是"什么都能改"，而是"改之前判断哪里值得改"——"一切皆插件"的反思（小时候的架构只是拖延实际功能）与 Emacs 本体（load 必要配置后 dump 出来）的区别也在这：扩展性是功能完整之后的架构结果，不是先于功能的架构承诺。

4. 落地方法： 给卡、慢、丑问题建两栏清单，先定 userland/core，再选 fork、advice 或邮件列表。core 的问题硬 fork，只会造出第二个 magit 式补丁债。

可继续实践的方向： 当天那句自嘲"lisp 壬没产出足够语料让 ai 炼化"值得当真。Emacs 自改文化的产出物——advice、编码修复、sections 重写——本身就是最稀缺的"真实 bug + 修复"语料；用 MELPA 源码 + docstring + headless Emacs 批量执行做校验来合成数据集，比等更多人写 Lisp 现实得多。这条线跑通，"等上游"与"维护个人补丁"的成本都会下降。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】AI 编程工作流的分工哲学：规划与执行解耦

这是今日讨论最激烈的一条主线。核心共识是：Claude 负责规划，GPT-Luna-max 负责实现，ast-grep 补足中文搜索的视野盲区。

原帖观点（分享者总结了一整天的实践经验）：

• 方案规划用 Claude + ast-grep 更好。Claude 读取文件懂得只读关键部分；ast-grep 恰好填补了 Claude“视野有时过窄”的问题。
• 用 GPT 做规划的问题在于“防御性倾向过重”：它会读太多不关键的文件，上下文污染严重，跑着跑着就跑偏——原话是“看着 Codex 里长长的工具调用，一种傻蛮傻蛮的感觉”。
• 具体实现环节 GPT-Luna-max 非常好：思考质量高、代码质量也高。唯一缺点是慢，得加 /fast。
• 实践者通常在 Hardr 里同时开着一个 Claude 和一个 Codex，一个规划一个执行。

延伸讨论的关键洞察：

“我觉得在大家引入 Multi-Agent 之前，还是先学习一下如何结对编程比较好。不然正如之前推友所说，Multi-Agent 就是一个分布式系统，状态超多容易炸，本来难搞。”

• 有人实测 prime-agent 存在严重问题：开了太多子代理后，与主线程的交互出现故障，用 /goal 编码任务时经常卡死在子代理的回调中，一跑几个小时不停。
• 只读 subagent 的对比：有人用过只读 subagent，但不如 ast-grep 快，核心瓶颈是 GPT 本身太慢，“等一群 subagent 捣鼓完，能等到天荒地老，一到 deadline 能急死人”。
• ast-grep 的选择：多人确认用 Rust 版本，跨语言写一次即可（polylith-like 的思路）。omp 自带 ast-edit 和 ast-grep 支持，但实际观察中 AST-edit 更常被调用，ast-grep 较少被自动触发，可能因为没有 tool-calling 可见性。

分工哲学的精炼：让最强的模型做拆解与规划，让最省 token 且执行稳定的模型做实现。一位群友总结了自己的模型使用策略：“一种直接用最强的，然后逐渐降级；一种是先用稍弱的，随问题难度逐渐升级。”

【专题二】模型额度经济学与多模型降级策略

围绕 Luna-max 的耐用性和多模型协同，展开了密集讨论：

• Luna-max 省 token 到令人震惊：开了 fast 搞了两天，额度只掉 5%。有 Plus 用户反馈不开 fast，工作一小时额度仅下降 2%，“太耐用了”。结论是除了慢没有任何毛病，不复杂的项目直接用 Luna-max 实现也很好，思考非常清晰。
• 降级策略：有人实测 Luna-low + fast 也能干不少活——适用于“自己已经很清楚的任务、只是懒得动手写”的场景（改小脚本、简单实现）。搞不定时再升级。
• 模型组合建议：设计用 sol-xhigh，其余用 luna-max；做完让 grok 审一遍；执行层细化到每个任务节点后交给 Luna 快速执行。
• DeepSeek V4 现状吐槽：flash 额度缩水到可能只有原来的四分之一，“缩的连 1/3 都没了”。有群友直言“现在的 ds v4 pro 没比 mimo v2.5 pro 强多少”。
• 对小米 Mimo V3 的期待：小米的模型要服务集团业务，不太会往极端高价大模型方向走。最大看点是基础模型是全模态的——如果 ICML 上吹的牛能成真，将拥有一个便宜好用的多模态模型。
• opencode 的坑：群友提醒“opencode go 用户注意取消订阅”，因为“订阅即取消订阅”的机制很坑。有人复盘发现自己额度消耗异常快可能与 opencode 的计费机制有关。
• Codex 1M 上下文讨论：有人问 Codex 是否能开 1M 上下文，回答是一直可以（通过配置），但多数人觉得没必要，“干活干到一半时会不想要强制 compact，最大的用处是这个”。

---

🔑 关键概念与技术解析

概念	释义
ast-grep	基于 AST（抽象语法树）的结构化代码搜索与操作工具，支持跨语言规则复用，常被拿来弥补 LLM “视野过窄”的问题
Hardr	一个 AI agent runner/TUI 工具，支持多模型并行调用
omp	自带 ast-edit 和 ast-grep 支持的 AI 编码工具
Hermes	一个具备长期记忆（memory）的 AI bot/助手系统，是少数支持持久记忆的方案之一
prime-agent	一个多子代理编排框架，目前主线程与子代理交互存在卡死问题（回调阻塞，跑数小时不停）
Luna-max / Luna-low	GPT 系列模型（Luna 为代号），max 推理强但慢，low 省 token 适合简单任务，支持 /fast 加速
sol-xhigh	用于设计/规划阶段的高推理模型
Mimo	小米的多模态基础模型，被期待在 V3 版本提供高性价比多模态能力
elfeed	Emacs 的 RSS 阅读器，现已被 minad（知名 Emacs 插件作者）接手，更新非常频繁
sioyek	一款键盘驱动、适合技术文献阅读的 PDF 阅读器，原生支持 Wayland 有已知 bug（开发者不用 Wayland）
B+ 树 vs 跳跃表	内存数据结构的选择。Redis 准备用 B+ 树替代跳跃表作为有序集合底层实现，内存减半、速度提升约 70%
彩云天气	国内天气数据服务商，以分钟级降雨预报见长，小米自带天气数据即来自彩云

---

💎 碎片知识与金句拾遗

AI 与 Agent 工作流：

• “我觉得在大家引入 Multi-Agent 之前，还是先学习一下如何结对编程比较好。”——对盲目上 Multi-Agent 的清醒提醒
• “Multi-Agent 就是一个分布式系统，状态超多容易炸，本来难搞。”
• “自己想不明白的如何让 ai 给我赋能”——瓶颈在人，不在工具。原话：“我现在还是在人工对话来操作 agent 的阶段，所以瓶颈在我。”
• “数学抽卡的 task 能无人工参与跑一天”——目标足够明确、有 RAG 确认机制时，agent 真的能自主运行
• “ai 毕竟不是真的会写代码”——对 AI 编码能力的冷静定位
• 有人提出“有没有 hook 能在每次对话后发个‘继续’‘好的’之类的，是不是可以一直跑”——一个关于 agent 持续运行的有趣脑洞

天气推送的成本教训（很有意思的细节）：

• 用 Hermes 推送一次天气，花了 1 块钱。动手算账后发现按 token 高峰计费也才 0.16 元，怀疑是 Hermes 读了大量无关内容（或关联了 MCP 配置）导致费用膨胀
• 共识：确定性任务不应该走 AI 推理路线。“看个天气 curl wttr.in 不就好了”“这种能确定的就让 hermes 写个脚本，每次调用脚本拿数据”“AI 搞不好给你整出幻觉来”
• 有人希望 AI 推送不只是天气数据，还要有穿搭建议，“感觉更人性化”——但代价是成本与幻觉风险
• 天气数据源体验：彩云降雨推送精准，“最起码比墨迹准”；某群友手机天气数据来自墨迹，“外面下大雨，手机依旧显示晴天”；彩云的 API 免费额度基本够用，用 App 反而一堆广告

模型与工具细节：

• “订阅即取消订阅”——吐槽 opencode 的反直觉订阅机制，非 Go 用户可能遭遇意外扣费
• “b.ai 的 deepseek-v4-flash 目前限免，需要的快去薅”
• Native-comp-jit-compilation 设为 t 时，Emacs 首次启动会把配置里用到的东西全部编译成 eln，导致首启极慢
• opt/codex 的压缩机制“挺好用的”，不一定要强行扩上下文
• “体感 Hardr 的性能似乎还不如 tmux”
• UU 远程没有 Linux 版本——远程桌面工具的平台覆盖不足问题

技术博客与文学品味：

• 尼尔·斯蒂芬森的《编码宝典》被高度评价：“里面有很多加密和计算机相关的内容，写得专业”。查了 wiki 后发现作者有计算机背景（家传），众人感叹“这背景...一看就觉得智商高”“此人 coding 能力在我之上”
• 《赛博英雄传》被吐槽：作者有巧思但缺乏专业知识，“内功侵入，直接线一插就可以侵入了，武功可能是这样，但是计算机可以拒绝访问的吧”——后半句是一个相当精准的赛博朋克技术吐槽
• 战锤 40K 的机械神教设定被拉出来对比：“开个机还要点起香油和香薰，祭祀一通”——更扯

Redis / Valkey 技术观察：

• “纯内存为啥要用逼夹术”（B+ 树）——对 Redis 用 B+ 树替代跳跃表的疑惑，B+ 树通常被认为更适合磁盘场景
• 有人指出“估计是看隔壁社区做完了”——Valkey 已经做了 B+ 树（PR #3840 对应 Redis PR #15635），Redis 有被动跟随之嫌
• “redis 乱了阵脚啊，做这些有的没的，不如好好把多线程做好吧”——对 Redis 主线的担忧
• “性 valkey 多线程架构就是 8.0 引入的，感觉 valkey 现在像 redis 的前瞻”——Valkey 反而成了技术路线的前瞻者

气候变化闲聊中的历史知识：

• 《南史》记载梁元帝承圣元年（公元 552 年）：“淮南有野象数百，坏人室庐。”——今安徽中部在当时有大象活动，距今唐代仅 66 年，说明当时气候远暖于今日
• 现在大象只能在云南和东南亚的狭窄地带生存——一个有力的“气候带北移”历史参照

生活中的硬核：

• 某群友在亲子乐园因孩子被推搡与对方家长起冲突，对方蛮不讲理还先动手。群友当时的反应是“准备报警的，他们缩了”。从此引出“难道以后还要带娃记录仪，全程录下来”的思考——硬核且现实
• 一个正在开发的 org-mode iOS App 值得关注：包含日历（scheduled）、todo list（无 schedule）、org/md 预览与编辑，日历支持农历、导入节假日或同步 Google Calendar，支持 journal（还差模板功能）、支持 org-attach。开发者的商业模式仍在纠结：订阅制 vs 免费加广告 vs 全免费 GitHub 捐款。群友建议直接上 Reddit、Product Hunt、Hacker News。
• sioyek 在 Wayland 下打不开，开发者不用 Wayland，workaround 是 QT_QPA_PLATFORM=xcb sioyek，但“好久没发版了需要自己编译”

---

🛠️ 值得深入研究的点 (Follow-up)

1. ast-grep 与 AI 规划流程的更深整合：目前群内实践是 Claude 规划 + ast-grep 补足搜索，但 omp 自带 ast-grep 却无人见过它自动调用。值得探索如何让 agent 在规划阶段自动触发 ast-grep 进行结构化代码检索，而非依赖 LLM 的“逐步读文件”模式。

2. Redis 有序集合 B+ 树实现（PR #15635）与 Valkey 对应实现（PR #3840）：这是底层数据结构的一次重大变更，内存减半 + 速度提升 70% 的声明需要仔细审计。B+ 树用于纯内存存储的取舍、页大小设计、以及 Redis 和 Valkey 在这件事上的竞赛关系，都值得写一篇深度分析。

3. Mimo V3 的全模态基础模型：小米的模型路线被认为不太会走超高价路线，而全模态（原生多模态而非插件式）基础模型是一个值得密切跟踪的变量。ICML 相关论文值得挖出来看具体技术方案。

4. Hermes 的记忆机制与成本核算问题：一次天气推送花 1 块钱、按 token 计算却只需 0.16 元的巨大落差，暴露了 Hermes 在隐藏成本（读入的上下文、MCP 工具调用、系统提示等）上的透明度问题。值得调研 Hermes 的计费可见性与上下文管理机制。

5. ast-grep 在 multi-agent 中的降噪价值：当 LLM 上下文被无关文件污染时，ast-grep 的结构化搜索可以作为“低噪声上下文注入器”。这个方向值得做系统性的实验：AST 检索结果 vs 原始 grep vs 逐文件读取，对 agent 规划质量的影响。

6. 关于 org-mode iOS App 的商业模式验证：一个功能相当全面的 org iOS 客户端（scheduled/todo/农历/Google Calendar/journal/org-attach）即将发布。如果功能确实“比任何一个 app 强”，它可能成为 org 生态中少有的优质移动端选择，值得关注其开源与商业化走向。

🧠 Hermes GPT-5.5 观点延伸

中心判断：今天最值得咀嚼的两条线，指向同一个工程结论——把确定性从 AI 推理里剥离，是当前 agent 工作流性价比最高的一步。"Claude 规划、Luna-max 执行、ast-grep 补盲区"，和"看个天气花了一块钱"，是同一枚硬币的两面：前者按不确定性给模型分工，后者拒绝为确定性任务付推理的钱。

一、规划与执行解耦，剥开看是给不确定性分级。GPT 规划的翻车路径值得拆细：防御性倾向→读太多不关键的文件→上下文污染→跑偏。规划阶段最贵的是视野，执行阶段最贵的是偏差。所以这个组合的合理性跟谁强谁弱无关：Claude 懂读关键部分，ast-grep 补结构化检索，两者合力给规划喂最小充分上下文；Luna-max 在任务边界已定之后才入场，慢只是可接受的代价。可验证的判断：上下文污染是规划质量的第一杀手，把"检索先行、精读文件"固化成流程，收益大于换更强的模型。

二、multi-agent 卡死不是 bug，是架构债。prime-agent 开多子代理后 /goal 卡死在回调里几小时，子代理一多，状态同步、超时、任务边界全是分布式系统的老问题。群友"在引入 Multi-Agent 之前，先学习一下结对编程"的提醒很准：结对编程靠共享屏幕天然拥有共识层，multi-agent 恰恰没有。判断可以很硬：单人加工具能完成的任务不上多代理；真要上，先写死超时和任务边界，再谈编排。

三、一块钱的天气推送，暴露的是计费结构。账单 1 元、按 token 高峰算 0.16 元，差额大概率在隐藏成本里：读入的上下文、挂上的 MCP 配置。"确定性任务走脚本"的共识没错，但还能再推一层：LLM 按上下文计费，确定性任务的信息量天然低，AI 每次执行都等于给确定性付不确定性的价。AI 在这类任务里的价值只在写脚本那一次。推广成硬规则：能写成纯函数的任务，AI 执行一律算浪费。

可继续实践：把"确定性剥离"落成任务分级清单——确定性走脚本、低不确定用弱模型加 fast、高不确定用强模型规划、全局架构由人加检索把关，然后用一周的 agent 日志做成本归因，看分级后每类任务的真实单价。顺手把 ast-grep 当"低噪声上下文注入器"做对照实验：同一规划任务，比较 AST 检索、原始 grep、逐文件读取三种喂法下的规划质量。