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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 中的拼音搜索与汉字 IDS 增强

群内从一段有趣的 Common Lisp 式汉字结构搜索演示展开——基于 ⿱ 莫 ?a 和 ⿲ 木 ?a 木 等 IDS 查询，瞬间返回了大批匹配汉字。该演示迅速引出了实用的拼音搜索方案：

• 有人分享了 pinyin-isearch（https://codeberg.org/Anoncheg/pinyin-isearch）。
• 群友 @roife 受启发，基于 liberime 的 API 构建了 liberime-regexp（https://github.com/roife/liberime-regexp），让 vertico/consult 等补全框架可以受益于 Rime 的拼音模糊匹配能力。作者还特意加了 credit，体现出极客社区的良好协作。

讨论亮点：将 Rime 输入法引擎与 Emacs 的搜索/补全系统深度打通，不仅解决了中文输入场景，更提供了一种“拼音→正则→候选字”的通用模式，对非英文工作流尤其有价值。

Emacs 性能卡顿与剖析困境

数位群友感叹“Emacs 的性能一会神一会鬼”，有时超流畅，有时又莫名卡顿。尝试诊断时发现：

• 内置 profiler 有时看不出问题。
• 使用 elp（通过 advice 方式插桩）反而会拖慢函数调用，造成误判。
• 最后玩笑式吐槽：换 9950X 才是硬道理。

这折射出 Emacs 单线程、动态绑定的架构下，性能瓶颈的确难以用传统工具精准定位，也反映出长期用户对“谜之卡顿”的无奈。

Gnus 阻塞问题与异步化对策

不少群友在使用 Gnus（尤其是 nnimap 在线后端）时遇到 Emacs 被整进程阻塞的经历。对此提出了几种方案：

• 自行搭建本地 nnrpd 配合 pullnews 预先拉取新闻，让 Emacs 只需读取本地数据。
• 单独开一个 Emacs 实例给 Gnus（被戏称为“老办法但管用”）。
• 评价内置 gnus-async 为“很假”，说明效果不佳。

后续还分享了美化过的配置仓库 github.com/brsvh/fleet，以及其中 bs-gnus.el 的配置，供想折腾 Gnus 的群友参考。

Clutch SQL 结果编辑的 Limit 缺陷

用户报告了 clutch 的 bug：当 SQL 中包含 LIMIT 时，结果 buffer 无法编辑，报错信息指向无法检测源表。开发者 @Lucius_Chen 迅速跟进并修复，展现了群内积极互助和快速迭代的插件维护风格。

---

🔑 关键概念与技术解析

• IDS (Ideographic Description Sequence)：汉字结构描述序列，使用 ⿰ ⿱ ⿲ 等操作符递归定义字形，常用于生僻字或字形检索，本次演示展示了直接查询 IDS 的参数化方案。
• liberime：将 Rime 输入法引擎嵌入 Emacs 的包，负责拼音输入与候选词，是本次拼音搜索增强的基础。
• liberime-regexp：通过调用 liberime API 将拼音转换为正则表达式，可在 Emacs 的 minibuffer 或 consult/grep 中实现“拼音部分匹配汉字”的效果，极大降低中文文件/符号检索的摩擦。
• clutch：Emacs 下的交互式 SQL 工具，支持直接在结果中编辑单元格，适合轻量级数据库操作。
• eglot-booster：过去用于加速 eglot LSP 响应的包，现已存档，意味着官方或社区可能已将其思想整合进新版本或被放弃。
• elp：Emacs Lisp Profiler，通过动态添加 advice 测量函数耗时，但因 advice 本身开销可能导致调用堆栈的信息失真。
• nnrpd：NNTP 服务器守护进程，可以在本地运行，让 Gnus 使用离线高效的本地新闻组协议，配合 pullnews 实现真正的异步同步。
• gnus-async：Gnus 内置的异步机制，但群友反馈其实用性有限。

---

💎 碎片知识与金句拾遗

• 一位群友求推荐终端字体，答案“IBM PLEX MONO”获得大量 👍，成为当天字体之选。
• 关于旧内存的魔幻现实：
  • “DDR2 的单价已经超过 DDR5 了”
  • “ddr3 之前也涨了一波”
  • “这世界真是太颠了”
• 极客生活哲学：“其实现在这个存储暴涨的时代，有一种 linux 非常适合，就是跑在内存上的……即使最便宜的 DDR3，也比 SSD 快”。
• Anoncheg（codeberg.org/Anoncheg）虽然包很多，但在多个群被指有 spam 宣传“emacs free”群的行为，群友评价“只能说这人有点怪，不妨碍他可能是个好人”。
• nerd-fonts 前一个 release 有 bug 且已修复，但迟迟不发 v3.5.1，群友调侃“可能怕又出问题，就很尴尬”。
• hel-mode 作者夸赞 org-supertag，小范围的相互认可让人会心一笑。
• 历史科普：“原来 emacs 在 XEmacs 之前一直是运行在终端的……庆幸当年吸收了 xemacs gui 的部分”，并指出 Emacs 的 overlay 机制就是那个时代的产物。
• vibe coding 效果惊人：“之前陆陆续续调了两周”，现在 AI 辅助直接搞定，同时“emms-ui vibe 完还没 review”让人感受到 AI 辅助开发中的焦灼。
• 对付 agent 反复 shell 命令确认的利器：“所以我一般都 codex --yolo”。
• 对 Gnus 的终极妥协：“很久以前用 gnus 的时候是单独开个 emacs 给 gnus 用”。

---

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

• liberime-regexp（https://github.com/roife/liberime-regexp）：颠覆性的拼音搜索集成，让补全框架直接“听懂”中文发音，适合对原生英文搜索不满的中文用户。
• pinyin-isearch（https://codeberg.org/Anoncheg/pinyin-isearch）：另一个拼音搜索实现，可与前者做对比，了解不同算法取舍。
• 本地 NNTP 方案：用 nnrpd + pullnews 构建完全异步的 Gnus 后端，彻底解决阻塞问题，适合仍想坚守 Gnus 的顽固分子。
• clutch：如果 SQL 结果编辑功能成熟，可作为 Emacs 下的“迷你 Airtable”，值得关注其后续迭代。
• emms-ui（https://github.com/roife/emms-ui）：基于 vibe coding 的音乐播放器界面，一旦 review 完毕，可能带来 Emacs 多媒体体验的革新。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是某个包又多了一个功能，而是 Emacs 社区正在反复撞同一堵墙：Emacs 的强大来自“所有东西都能接进来”，痛苦也来自“所有东西都在同一个进程里发生”。中文搜索、Gnus 阻塞、性能剖析、AI Agent 改文件，本质上都在问同一个工程问题：一个可塑性极强的环境，如何把交互延迟、外部系统和不可信自动化重新纳入控制？

1. liberime-regexp 的价值不只是“拼音搜索”

liberime-regexp 这类东西表面上是在解决中文用户的痛点：不用先切输入法、不用精确知道汉字，就能在 vertico/consult 里用拼音找到候选。但更大的意义是，它把“输入法”从前端输入工具，提升成了 Emacs 内部的语言检索基础设施。

这很关键。英文工作流里，搜索、补全、grep、符号跳转天然共享同一套字母序列；中文工作流则长期断裂：输入时靠 Rime，搜索时靠字面匹配，结构检索又另起一套 IDS。当天从 IDS 查询到 pinyin-isearch，再到 liberime API 构建 regexp，正好说明中文环境不是缺一个 UI 小补丁，而是缺一层“语言到候选空间”的可组合中间层。

可验证的工程判断是：这个方向是否成立，不看 demo 是否惊艳，而看它能不能稳定进入多个入口：minibuffer、consult-grep、文件名、buffer 内容、org-roam/denote 笔记、甚至 Elisp symbol 的中文注释检索。如果只能在一个命令里工作，它是功能；如果能被补全生态复用，它才是基础设施。

2. Gnus 和性能卡顿暴露的是 Emacs 的调度边界

Gnus 在线后端阻塞、gnus-async 被评价“很假”、最后退到本地 nnrpd + pullnews，或者单独开一个 Emacs，这些方案看起来土，但工程判断很清醒：不要指望一个历史包在单进程交互模型里突然变成现代异步系统。真正可靠的办法，是把不可控 I/O 移出交互路径。

性能剖析也是同一类问题。profiler 看不出，elp 用 advice 插桩又改变被测对象，说明这里不是“还没找到正确按钮”，而是观测工具本身会扰动系统。对 Emacs 这种高度动态、advice 横飞、hook 密集的运行时，很多卡顿不是单个慢函数，而是交互时刻、外部进程、GC、显示更新、minor mode 叠加出来的尾延迟。

所以“换 9950X”是玩笑，也是现实：当系统缺少足够好的隔离和调度，硬件就会变成最后的调度器。

3. AI Agent 改文件的问题，也是 Emacs 问题的现代版本

群里吐槽 Agent 改一个小地方却反复 shell、反复确认，最后有人说 codex --yolo。这不是单纯的权限烦恼，而是人机协作缺少“可审计的批量事务”。Agent 如果每一步都要确认，用户被打断；如果全放开，又会失控。

Emacs 的优势恰好在这里：它天然知道 buffer、region、sexp、defun、undo、diff。未来好的 Agent 集成不该是“让模型继续 shell”，而应该让模型提交结构化编辑意图：在哪个 buffer、哪个语法节点、替换什么、预期 diff 是什么、如何回滚。人确认的也不该是一串命令，而是一组可读、可撤销、可测试的编辑事务。

可继续实践

可以做一个小实验：把 liberime-regexp 接入一个真实中文知识库检索场景，同时记录查询命中率、误命中、延迟；再把 Gnus/邮件/外部同步统一改成“后台拉取，本地只读”的模式。两件事放在一起看：前者提升表达能力，后者降低交互尾延迟。Emacs 的未来感，往往不来自重写整个系统，而来自把语言、I/O、Agent 这三类不稳定因素放到正确的边界外。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

1. 供应链安全与中心分发的信任危机

群友们从 Passkey 的复杂实现可能导致的漏洞聊起，迅速聚焦到软件供应链攻击的深层矛盾。

• 密码管理工具的攻防：有人倾向于 GPG 的简单可靠，有人则认为 Bitwarden 已经足够成熟（举例：上次 npm 供应链攻击 90 分钟就被 Bitwarden 检测到）。但整体情绪依然是对复杂系统的天然不信任。
• 中心化分发的靶子效应：npm、AUR、甚至 Melpa 都被认为是攻击的重灾区。Melpa 的风险尤其被细致讨论——即便作者及时回滚代码，CI 重新发布之间仍存在“带毒窗口”。nvim 的包管理器因为完全是“用户指定仓库 git 拉取”的模式，反而被认为更安全。
• C++ 的意外“优势”：由于 C++ 缺乏中心分发、工具链极度难用，开发者被迫尽量减少依赖、自己造轮子。这种“落后”反而在当前的投毒潮中成为了一种自然防护。有人提到，C++ 的商业库模式（卖 SDK/私有库）其实也是一种健康的生态。

2. 【专题】大模型时代的 Token 焦虑与智能体路由术

这是一条贯穿全天的密集技术探讨线，从价格、智商到自动化调度，信息量巨大。

• 价格战与“恩情”：DeepSeek v4 flash 看似免费或低价，但实测“4 小时用 4 块”，个人重度使用月费可能冲到五六百。但群友对比后发现，用 OpenCode 的订阅去调用 DS v4 flash，额度“异常慷慨”，以至于上线时把服务器都“蹬爆了”。大家感叹“梁圣的恩情还不完”，竞争压低了全行业价格。
• 模型智商波动与工程对抗：Claude Code 被频繁吐槽行为诡异——明明 Claude.md 里写了去查文档，它依然“屁大的事情都要本地拉代码、写脚本验证”，被怀疑是故意消耗 token。更深层的问题是“模型不知道自己不知道”，经常把 Mac only 的方案或者本地 cutting edge 版本的结果直接交付，这在跨平台/远程部署时完全不可用。群友甚至尝试在 agent 文件里加入“修改复杂时先确认”的指令，但模型依然自作主张，理由是“觉得修改挺简单的”。
• 人工路由的启发：一个极具前瞻性的实战技巧被分享：用 omx 工具时，故意告诉 luna max“搞不定的话就用 sol xhigh 来做”。随后观察到 luna max 真的启动子进程调用了更强大的 sol xhigh 并瞬间解决了问题。这种基于人工判断的动态模型调度，被称为“更精细的用模方式”，在能力和速度间取得了平衡，且“应该也很省 token”。这实际上是依靠更强的模型作为调度器，在任务流内部实现了推理水平的自动升级（注：Claude Code 后来也加入了类似的 advisor 特性）。

🔑 关键概念与技术解析

• Passkey：新一代无密码认证标准（FIDO 联盟），试图用公私钥对替代传统密码。群内观点：因其设计高度复杂，实现上必然漏洞百出。
• Melpa 投毒窗口：指 Emacs 的 Melpa 包仓库，其 CI 构建存在延迟。即使上游作者发现仓库被篡改并回滚，Melpa 在重新构建发布前的这段时间内，分发的仍可能是带毒版本。
• 中心分发 vs 联邦式拉取：npm/aur 等是中心式分发，nvim 的包管理（如 lazy.nvim）是用户直接指定 git 仓库地址拉取。后者在供应链攻击中因无统一入口而更安全，但代价是用户需手动维护仓库地址。
• AI Token 价格战：从 OpenAI 到 Gemini，DeepSeek 等中国模型的涌入导致 API 调用价格出现历史性暴跌。群内提到 DeepSeek v4 flash、Sol xhigh、Luna Max 等不同模型的性价比与能力差异。
• 人工路由（Manual Model Routing）：一种在 agent 工作流中，由用户或一个较弱的模型根据任务实时难度，动态决定是否升级到更强模型（或推理级别）的策略。相比全量使用高端模型，能显著节约 token。
• FSF 版权协议：如需向 Emacs 等 GNU 项目贡献代码，需与自由软件基金会签署版权转让协议，确保项目版权统一。签名写拼音或中文均可。
• FFmpeg 9.0 "Lei"：为纪念因过劳去世 10 年的音视频开发者雷霄骅，他曾撰写大量 FFmpeg 中文教程。

💎 碎片知识与金句拾遗

• Emacs 的冷知识：在 XEmacs 之前，Emacs 其实一直是运行在终端里的。聊到这点时，似乎没人觉得惊讶。
• C++ 的生存哲学：因为工具链太难用，大家都会尽量少引入依赖，能自己写就自己写。这种“孤岛式”开发恰好躲过了很多供应链攻击。
• 关于 AI 的终极期望：“AI 最应该加一个品质，就是遇到不确定的东西不去猜，和人类确认”。但紧接着就是无奈的补充：“它跟幻觉一样，不知道自己不知道”。
• 中心化的宿命：“目标不够大不会有人来攻击”，自己写自己架是最稳妥的，但在现代生态中几乎不可行。
• Intel 的迷惑操作：6 年前的 CPU 要复产？群友辣评：“傻逼吧，挤牙膏这么挤？”
• 打印机国家安全调查：商务部对进口打印机、复印机进行国家安全调查，涉及由外国实体开发、测试或维护的驱动和嵌入式软件。群友追问：“国产大型打印机已经可以完美替代了？”
• macOS 上的 Docker：Docker Desktop 实际上在 macOS 也跑了一个虚拟机，依赖 Linux cgroup，非常吃内存。
• 一椅传：“给自己换了一把会议用椅，啊，好舒服，比那些人体工学椅好太多了”。——来自深夜的程序员肉体保养心得。
• 名字的长度：在 Telegram 里，名字太长的话…会像这样显示：...(省略号)。

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

• OpenCode AI 的订阅机制：如何实现如此高额度的 DS v4 flash 调用？适合作为重度 LLM 使用的替代入口进行调研。
• 模型路由自动化方案：基于 omx 启发的“让弱模型调度强模型”的理想能否工程化？可能催生出一种更高效、廉价的 Agent 架构。
• Tailscale Aperture AI Passthrough：Tailscale 针对 AI 流量做直通以降低订阅成本的技术方案，其成本优化思路值得借鉴。
• AMP-local 容器化部署：群友正在尝试将 amp 的本地服务容器化，配合 web 端实现完全自主可控的开发环境。
• FFmpeg 9.0：以“Lei”命名的版本，除了纪念意义，其编解码、API 方面的更新值得关注。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“哪个模型便宜”或“哪个包管理器更安全”，而是同一个工程判断在两个领域同时出现：复杂系统的风险不在复杂本身，而在它把责任边界藏起来了。供应链如此，AI Agent 也是如此。

1. 中心化分发的问题，不只是“靶子大”

群里聊 npm、AUR、Melpa 投毒时，一个很关键的细节是 Melpa 的“带毒窗口”：作者发现、回滚了，上游已经干净，但 CI 重新发布前，用户拿到的仍可能是旧毒包。

这说明中心分发的风险不只是“大家都打它”，而是它引入了额外状态：源码状态、构建状态、索引状态、客户端缓存状态并不总是一致。攻击者真正利用的是这些状态之间的延迟和不可见性。

nvim 那种用户指定仓库 git 拉取，并不天然神圣。它只是把分发层打薄了，少了一层集中构建与再发布的异步状态。代价也很清楚：仓库地址、版本 pin、更新策略都回到用户手里。安全不是免费的，只是从“信任平台管理员”换成“承担本地维护成本”。

所以 C++ 那个“落后反而安全”的观察很有意思。它不是因为 C++ 生态道德更高，而是因为工具链难用、中心分发弱、依赖引入成本高，天然压低了依赖图复杂度。可验证的工程判断是：供应链安全首先看依赖图的宽度、发布链路的层数、以及回滚传播的延迟，而不是看生态口号。

2. AI Agent 的核心缺陷也是责任边界不清

Claude Code、Codex、DS 写命令杀进程失败、模型不查文档、跨平台项目给出 Mac only 方案，这些吐槽表面是“智商波动”，本质是 Agent 在替用户做判断时，没有可靠的自我不确定性检测。

群里那句“它不知道自己不知道”很准确。让模型“复杂时先确认”通常没用，因为“复杂”本身就是它判断错的对象。它会觉得几十行修改很简单，然后直接改掉；会觉得本地 cutting edge 结果足够交付，然后忽略部署环境差异。

这意味着 Agent 工程不能只靠提示词约束人格，而要把判断外置成可观测信号：文件数、diff 行数、跨平台触点、是否涉及进程/权限/网络、是否缺少真实环境验证、是否出现第二次失败。只有这些信号能触发“暂停确认”或“升级模型”。

3. 人工路由的价值在于把“升级”变成工作流的一部分

luna max 搞不定后被提示调用 sol xhigh，然后子进程解决问题，这个例子比单纯比较模型强弱更重要。它展示的是一种更合理的 Agent 架构：低成本模型负责推进、观察、整理上下文；强模型只在失败、歧义、架构判断时介入。

这不是玄学省 token，而是把推理预算绑定到任务风险。未来好用的 Agent 不会是“永远最强模型全程跑”，而是有明确升级条件、回退条件和验证条件的执行系统。

可继续实践的方向：把今天两个话题合并看，做一个 Agent/包管理通用的“信任链审计表”：每一步谁产出、谁分发、谁缓存、谁验证、多久回滚、失败后谁负责。能填清楚，系统才可控；填不清楚，就只是把风险藏进了自动化里。