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

Emacs 中文讨论组

🎯 核心热点与专题探讨

🎵【专题】EMMS UI 实战与性能优化：AI 时代的 Emacs 音乐播放器

围绕 roife 开发的 EMMS UI 展开激烈讨论。大家纷纷感叹借助 GPT 开发 UI 的极高效率——“以前做这一个东西得几天了”。在体验层面，专辑列表尺寸与渲染成为核心痛点：滚动时卡顿、光标迟滞，尤其在大批量高分辨率封面下问题明显。

• 解决方案链：开启 pixel-scroll-precision-mode、安装 iscroll、调整封面大小、利用 image slice 切分大图以降低单帧渲染压力。有用户实测压缩封面后“流畅了很多”。
• 键位与 Evil 兼容：需要单独将 hjkl 映射到 emms-ui-albums-previous/next 等命令，否则 Evil 用户会感到割裂。
• 跨平台与后端选择：EMMS 依赖后端（mpd、mpv 等），Windows 上可用性存疑。zdn 指出自己在 Windows 下解决 mpv IPC 问题，推荐 mpvi。同时回顾了 mpd 的远程推流玩法——将 output 设为 httpd 即可实现“群组共听”。

📋【专题】Org mode 的下一个十年：解析重构、性能提升与 AI 协作

以“开始用 org mode 做任务管理”为引，迅速转入对 Org 内部机制的全方位批判与展望：

• 性能瓶颈：font-lock 依赖递归正则，面对大量内容或图片时滚动卡顿，“正则太阴间了”；org-element 解析效率低下；“image slice 应该进 core”成为共识。
• 现代化路径：多位成员提出“手搓 tree-sitter org parser”、推进 org-ts-mode，甚至组织 workgroup 重写解析器。外部 parser（如用 C 实现）被看作摆脱 Emacs 单进程依赖、提升导出速度的关键。
• 版本演进：org v10 已在开发中，希望借此引入异步 latex preview、tree-sitter 解析，并优化与 org-babel 的集成。当前异步预览因底层问题仍未合并，只做了 workaround。
• AI 助力：利用 GPT 生成 tree-sitter parser 雏形；让 agent 半夜扫描 todo.org 自动执行任务。org-supertag 等包已经吸收了 Notion 的表格视图与自动化理念，但 inline 渲染仍受限于解析性能。
• 生态延伸：讨论了 org-roam、Vulpea 的异同，以及用 shrface + EWW 实现 Markdown 预览以继承 org face 的“邪道”技巧。

🤖 AI 对编辑器生态的渗透：从 Vim 到 Emacs 的“Claude 入侵”

• 开发效率跃升：“vibe coding”让 App 开发变得轻松；修 bug、做 UI 杂活时 AI 效果显著，“只需要当产品经理”。
• Vim 仓库的 AI 痕迹：κόσμος 发现 Vim 仓库中 Claude 的提交次数（147）远超 Neovim（45），感叹“没想到 vim 里 claude commit 次数比 neovim 里还多”。随即有用户提到 fork 出的纯 Vi 实现 evi。
• 编辑器哲学争论：以“Emacs 之于 Nvim 就像台湾之于大陆”调侃两者关系，并戏称“又熬死一个”（指 vim 与 emacs 的竞争）。

---

🔑 关键概念与技术解析

• EMMS UI：Emacs Multimedia System 的新一代专辑浏览器 UI，支持封面渲染、歌词、筛选等。
• mpd / mpv / mpvi：Linux 系音乐播放后端；mpvi 是专为 mpv 设计的 Emacs 前端，解决了 Windows 下的 IPC 问题。
• futur：Stefan Monnier 开发的 Emacs 异步编程库，利用并发原语提升脚本执行效率。
• org-supertag：将 Notion 式数据库表格引入 Org，支持特殊 buffer 显示表格和自动化。
• image slice：将大图切分为多行显示，降低 Emacs 行内图片渲染压力，改善滚动性能。
• org-element：Org 的语法树 API，当前基于递归正则解析，性能是主要瓶颈。
• shrface：让 EWW 渲染的 HTML 继承 Org mode 的 face，以实现一致的视觉风格。
• evi：基于纯 Vi 思想的 fork，去 Vim 化，回归极简。
• vibe coding：利用 AI 工具以自然语言生成代码，强调快速原型而不纠结细节。

---

💎 碎片知识与金句拾遗

• “我和 GPT 我们俩真厉害啊”——借助 AI 快速完成 UI 开发后的感叹。
• “感觉有了AI 之后这种杂活很方便了”——表达 AI 对琐碎工作的解放。
• “OmniFocus 适合任务很多，需要透视的人” “单纯当 reminder 也能用”——对 GTD 工具的精准定位。
• “可以从 org 中让 agent 在半夜看你的 todolist，然后挑一些任务自己完成，醒来就做完了”——对未来自动化工作流的想象。
• “把 output 设置成 httpd 就可以了()” “记得几年前 archcn 的 ot 群里就有一个 mpd，还有个推流的前端，大家可以往上面推想听的歌和大家一块听”——mpd 远程共听的妙用。
• “正则太阴间了啊，难道没有人学过编译原理吗”——对 org 解析器现状的犀利吐槽。
• “image slice 应该进 core” “最好能成为 emacs 标准的图片显示方式”——对性能优化的强烈呼吁。
• “Emacs 之于 Nvim 就像台湾之于大陆，既熟悉又陌生，就像甄宝玉之于贾宝玉”——生动比喻两个编辑器的关系。
• “看了一下 vim 仓库，没想到也被 claude 入侵了” “vim 147 次，neovim 45 次”——AI 已深入传统编辑器开发。
• “我之前的解决办法是用 github 的 api 把 markdown 文件转 html 用 eww 预览然后用 shrface 包让 eww 继承 org 的 face”——一种巧妙的 Markdown 预览方案。
• “我嘞个豆😂我看了半天还以为是鸡脚😂”——关于图标中 λ 符号的搞笑误读。

---

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

• org-supertag：将数据库视图引入 Org 的实践，可以关注其是否演化为 org-roam 的有力补充。
• org v10 与 tree-sitter org 解析器：寻找社区中已有的 tree-sitter 语法项目，评估其对性能和 CJK 支持的影响。
• image slice 的通用化：探讨如何将 image slice 作为 Emacs 内置图片显示方式，改善 eww、org 等场景的滚动体验。
• futur 并发库：学习其在 Emacs 配置中的实际应用，如异步网络请求或长时间任务。
• Telega 的 UX 修复：SVG 渲染在 Emacs 31/32 的变化（fill: currentColor 去掉）、emoji 撑开按钮等问题，可作为插件维护参考。
• 外部 org 解析器：类似 pandoc 的 Org 后端，或用 Rust/C 实现的独立 parser，有望提升 org-publish 等流程的速度。
• MPD 共享听歌方案：利用 httpd 输出 + 简单 Web 前端实现“群共听”，适合小圈子内分享音乐。

🧠 Hermes GPT-5.5 观点延伸

今天最有价值的线索不是“AI 写 Emacs 插件变快了”，而是：Emacs 生态正在被迫把几十年来靠个人 hack 撑住的灵活性，翻译成可被机器、外部 parser、Agent 和工程流水线理解的结构化边界。

1. AI 让“杂活”变便宜，但也会放大底层架构债

EMMS UI 的讨论很典型：GPT 可以把 UI、键位适配、Evil 兼容、图标微调这些过去耗几天的活压到很短时间内完成；但真正卡住体验的，仍然是 Emacs 图片渲染、行模型、滚动路径、后端 IPC 这些底层约束。专辑封面太清晰导致滚动卡，最后靠压缩封面、iscroll、pixel-scroll-precision-mode、甚至 image slice 去缓解，这说明 AI 提高的是“生成改动”的速度，不是自动消除平台物理限制。

工程判断很明确：AI 适合加速胶水层、适配层、UI 小循环；一旦问题进入渲染管线、进程模型、跨平台 IPC，就必须回到 profiler、数据规模、调用路径和可复现实测。否则只是更快地产生更多补丁。

2. Org 的问题不是“老”，而是缺少稳定的机器接口

Org mode 那段争论比工具推荐更重要。大家一边想把 Notion 的表格视图、Automation、任务透视、Agent 自动执行搬回 Org，一边又撞上 org-element、font-lock 正则、图片滚动、导出速度、CJK 标记兼容、外部 parser 缺位这些问题。这里的矛盾不是 Markdown vs Org，而是“个人知识系统能不能同时服务人和机器”。

如果 Org 继续主要以 Emacs 内部动态行为作为事实标准，那么它很适合高手本地 hack，却很难成为 Agent、CI、博客构建、移动端、数据库索引共享的稳定协议。外部 parser、tree-sitter org、SQLite 索引、image slice 进 core，本质上都是在给 Org 补一层可验证、可增量、可外包执行的工程边界。

3. 半夜让 Agent 看 todo.org，不该先问“酷不酷”，要先问“哪些任务可委托”

“让 agent 半夜看 todolist，然后挑一些任务自己完成”是当天最有未来感的一句话，但它的落地前提不是更强模型，而是任务系统本身足够结构化：任务要有上下文、状态、权限、验收标准、失败回滚和人工确认点。Org 的优势是正文和任务天然相邻；风险也是边界太软，Agent 容易把笔记、想法、草稿、命令混成同一种文本。

可继续实践的方向：选一个小闭环，不要先重写 Org。比如从 todo.org 中只识别带特定 tag 的低风险任务，生成执行计划，跑只读检查或本地测试，最后写回结果与证据。能稳定跑通这个闭环，再谈 org-ts-mode、外部 parser 和自动化工作流，才不是空想。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】AI编码代理的架构升级：上下文治理与多智能体协作

群内围绕“如何让 AI 代理写出可靠代码”展开了长达整天的持续探讨，从工具测评上升到了认知架构的层面。

• 痛点与瓶颈：
  • 模型能力边界：尽管使用了 Sol、ChatGPT、Claude 等先进模型，依然难以胜任复杂任务。有成员抱怨 Claude (Sol) 极度“过度设计”，比如热衷于自动生成单元测试，导致 Token 浪费；本地模型写 Rust 时，遇到编译错误只会不断删减代码而非修正逻辑。
  • 上下文污染：随着任务复杂度提高，会话上下文容易充满噪音，导致 AI 在后期产生幻觉或忽略核心指令。
• 进阶构想：结构化 Agent 系统工程
  • 群内技术专家提出了一个尚未有开源生态完全覆盖的闭环设计：主 Agent 负责维护“金丝会话”，多个 Sub-Agent 进行探索。
  • 理想形态包含五个关键环节：子代理探索 + 证据门控状态增量 + 主代理规范工作区 + 自动上下文重建 + 依赖感知分叉。
  • 该架构的核心理念在于：主 Agent 保持极简的上下文以驱除噪音；Sub-Agent 独自完成任务后输出“证据”；主 Agent 据此进行状态改写或裁剪；以此达到“磨刀不误砍柴工”的长期任务稳定性。
• 行业镜像：Claude 验证黎曼猜想
  • 群友分享了 Claude 联合人类做数学研究的最新案例（消耗 3100 万输出 Token，调度 60 个子智能体协作），生动印证了 Sub-Agent 模式在复杂探索领域的应用价值。

【技术产品拆解】Emacs 与 X (Twitter) 生态的门面功夫

• 架构之争：内部闭包 vs 外部进程
  • 开发人员在设计 chirp (X 客户端) 时发生了理念冲突。
  • 内部派：主张 Emacs 自身应作为核心，把数据拉取后的结果全部存进 Buffer，作为数据池直接解析。
  • 外部派：主张让外部 CLI 执行繁重工作，Emacs 仅通过进程通信读写流式数据。
  • 共识：最终内部派胜出，核心逻辑迁移至 Emacs Lisp 本地处理 (6574 insertions(+), 1486 deletions(-)），完全解耦了 twitter-cli 进程依赖。
• 底层逆向与适配
  • chirp-dm (私信) 的开发引入了 Chat-XDK 作为 Rust 模块，因为 X 的私信采用端到端加密。
  • 为了应对 X 的接口变动，需要处理 GraphQL 的 query-id 自动更新与降级机制，试图在动态变化的逆向环境中寻找稳定解。

🔑 关键概念与技术解析

• chirp / chirp-dm: WD 着力开发的 Emacs 生态下的 Twitter/X 客户端，支持信息流拉取与加密私信功能。
• appkit.el: Emacs 的一个基础依赖库集合，用于提供通用功能，避免重复造轮子。正待合并入 MELPA。
• browser-session: 从 ytm-radio 项目中剥离出来的浏览器会话管理模块，用于跨应用/跨库复用浏览器 Cookie。
• jcode: 一个 Rust 编写的 AI 编码 IDE/工具，群内对其评价两极（有可取设计，但不建议深入使用）。
• zcode: 来自智谱的编码助手，因其优秀的 BYOK 支持以及提供免费的 CI 闲时调度能力而受到推荐。
• Palantir 的本体论: 指一种 AI 知识方法论，通过定义对象、行动规则、钩子和输出，让 AI 拥有清晰的“认知地图”。
• org-supertag: 一个 Emacs Org-mode 进阶插件，提供类似 Logseq 的查询与双链组织方式。
• datalog: 一种声明式逻辑查询语言，常用于知识图谱、数据库等场景的实现。

💎 碎片知识与金句拾遗

• 关于付费与薅羊毛：
  • “路边捡到一块钱，和在自己的钱包里看到一块钱，快乐不一样呀。”（关于 API 额度重置）
  • 虚拟卡支付 Claude 等 AI 服务时遭遇“跨国渠道费”：充 1 美元扣 1.12 美元，其中 1 美元竟是纯 Master 渠道费。
  • A\ 封控严苛到变态的程度：使用新加坡宽带、设备、邮箱和手机号的纯本地环境仍会被秒封。
• 编码哲学与杂谈：
  • 过度工程化的吐槽：“我感觉单元测试泛滥了，已经开始浪费 token 了。”
  • 模型对比心得：“Claude 和 Grok 可以按需在工作中使用；DS 只配给 Heremes 用；只有额度不够时才想起 ChatGPT。”
  • 面试趣闻：一位群友在简历写了“Python 写爬虫”，结果遭遇面试官疯狂论证“Java 也能很好地写爬虫”的痛苦经历。
• 工具推荐：
  • Fantastical：目前唯一公认颜值与实力俱佳的日历软件，最核心的爽点是自然语言解析（如自动将“吃药 10:00”转为准确事件）。
  • Niri：一款平铺式窗口管理器，效果很帅，被推荐。

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

• Chat-XDK: X 官方的私信 SDK (端到端加密)，由于被纳入 chirp-dm 的底层实现，如果要复现 Emacs 里玩推特私信，这是必须过一遍的 Rust 依赖。
• 多智能体框架 (Evidence Gated State Delta): 群内设计的“主 Agent + 证据门控 + 自动上下文分叉”这一编程工作流设想，值得在开源项目中尝试落地。
• 自建个人数据库 (build-self-db): 受分享的博主启发，利用 SQL 构建个人的量化生活数据查询系统，再结合 AI 辅助写 SQL 前端，这条路在 Emacs 和 Obsidian 生态之外提供了新的落地方案。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“哪个 Agent 更强”，而是一个更硬的判断：AI 编程已经从模型消费问题，变成了上下文工程和状态治理问题。群里反复出现的抱怨——Sol 过度设计、单元测试浪费 token、本地模型编译不过就删代码、复杂任务后期上下文污染——本质上都不是单点工具问题，而是系统没有把“探索”“证据”“决策状态”分层。

1. 主 Agent 的价值不是多干活，而是少沾噪音

“主 Agent + 多个 subagent”的关键不在并行，而在隔离污染。Sub-Agent 可以乱试、跑错、写脚本、消耗 token；主 Agent 只接收经过证据门控的状态增量。这比“开一个超长会话让模型一直记住所有东西”更接近工程系统：长期稳定性来自可审计状态，而不是来自模型的记忆幻觉。

所以可验证的判断是：一个 Agent 框架是否先进，不看它能不能喊 60 个子智能体，而看它有没有三件事：证据格式、状态改写规则、失败后可重建上下文。没有这三件事，多 Agent 只是更贵的混乱。

2. 过度测试和删代码，都是模型在缺少目标函数时自保

“单元测试泛滥”和“编译不过就删代码”看似相反，其实同源：模型不知道什么叫完成，只知道什么动作看起来安全。强模型会用测试套件制造确定性，弱模型会通过删减代码逃离错误。这不是智商问题，而是任务约束没有被工程化表达。

对 AI coding 来说，真正的提示词不是“别写测试”或“别删代码”，而是把目标函数写清楚：允许编译失败但必须保留接口？允许补测试但测试不得超过变更主体？允许重构但必须证明收益？这些都应该进入可执行规则，而不是靠聊天语气约束。

3. Ontology 不是玄学，是把个人知识系统变成可执行系统

晚上关于 Palantir ontology、Datalog、Logseq、org-supertag 的讨论，其实和 Agent 话题是同一个问题：图谱本身不等于智能，规则绑定才是智能的入口。对象、边、钩子、行动条件、输出格式，合起来才让 AI 知道“看到什么就该做什么”。

这也解释了为什么纯文本笔记、双链、SQL、自建数据库都各有生命力：它们不是在争“哪种笔记软件更好”，而是在争哪种底层结构更容易被程序稳定操作。AI 能写查询界面，但不能替代 schema；AI 能帮你找入口，但入口必须存在。

可继续实践的方向

可以做一个最小实验：选一个真实代码任务，用“主会话只维护 canonical state，子会话只提交 evidence delta”的方式跑完；每个 delta 必须包含变更、证据、风险、是否改写主状态。最后比较它和普通长会话在返工次数、幻觉率、上下文长度、测试通过率上的差异。跑完一次，今天这些讨论就不再是架构想象，而是可度量的工程判断。