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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 补全框架的演变与当代选择

群内针对补全/筛选框架展开了一场跨越时空的讨论，从古老 Ido、Anything/Helm，一直聊到当代的 Consult+Vertico 体系，并夹杂了对 Embark 的复杂情感。

• 历史路径： Ido → Anything（Helm 前身）→ Ivy → Helm（并行）→ Consult/Vertico。Ido 出现在 Emacs 22 左右，Ivy 轻量得宠于 Emacs 26 年代；Helm 因性能与“打开 buffer 的臃肿设计”被部分用户放弃，但直到今天仍有一批坚守者。

• Helm 的不可替代性： 多位群友指出 Helm 拥有至今难以复刻的优势：

  • helm-resume：真正“恢复”之前的搜索 session，而 Consult 的 vertico-repeat 只能“重做”一次。
  • 交互列表内的多选操作（如多文件批量动作）。
  • 大部分功能集中在 TAB 键，直到 Embark 出现才被赶上。
  • 即使已经迁移到 Consult 的用户，也有人承认“helm确实还挺好用的…”。

• Consult/Vertico 的主流地位： 当前新用户的主流推荐是 Consult + Embark。Consult 的 preview（预览候选项内容）被视作杀手特性——例如在切换 buffer 时直接看到内容，无需依赖名字。不过也有性能痛点：在 consult-recentf 等大数据源下自动 preview 会卡，多数人选择手动触发（配置 :preview-key "M-."）。

• Embark 的尴尬处境： 被比喻为“鼠标右键，多一层功能”，但很多用户表示“平时用的确实也少”，“不够直观，除非是用熟的功能，否则平常不大能意识到‘这个地方能embark一下’”。其 embark export 被肯定，但缺乏类似 helm-resume 的异步 export 能力。

• 模糊匹配的进阶需求： 一位群友提到 orderless 不够好用，有人推荐 hotfuzz，也有推荐 fussy（https://github.com/jojojames/fussy）来实验各种匹配风格。对于只想简单模糊匹配的用户，fido-mode 内置方案也够用。

• 性能观点的变迁： 当年 Helm 卡顿的原因是打开整个 buffer，而 Ivy 只拉伸 echo area，轻量获胜；如今随着 native-comp 和 Apple M 芯片普及，不少人觉得 Helm 的“性能问题在现在应该好解决了”，甚至出现了“我两边用起来的体验是性能上没有什么明显的差距”的声音。但大 buffer 在笔记本左右分割时显得太大，部分用户通过配置强制上下分割或限制 window-height 来缓解。

专题二：Windows 下 Emacs 子进程中文乱码的终极解法

zdn 在 Windows 上遇到了子进程（如调用外部程序、mpv、eshell 等）中文输出乱码的顽疾。群友合力献计，最终通过调整 process-coding-system-alist 和手动包装 start-process 的 :coding 参数解决。

• 核心矛盾： Windows 控制台编码为 GBK（codepage 936），但 Emacs 内部和大多数现代软件期望 UTF-8。若全局设置 UTF-8 会破坏其他老软件的兼容性。

• 试探过程：

  1. 尝试使用 (setq default-process-coding-system '(utf-8-dos . utf-8-dos)) 无效。
  2. 群友给出根据 codepage 自动匹配正则的配置块，仍乱码。
  3. 关键突破：意识到需要针对具体子进程定制编码。通过包装 start-process 传入 :coding 参数，并实验 (gbk-dos . utf-8-dos) 和 (utf-8-dos . gbk-dos) 的组合。最终确认：需将子进程输出从 GBK 解码成 UTF-8，即 (utf-8-dos . gbk-dos)（前解码后编码）。
  4. 成功使歌曲信息正常显示（“大狗终于叫了”）。

• 最终建议： 对于无法全局修改编码的环境，应当在调用过程的函数处手动设置 coding，尤其针对 [pP][lL][iI][nN][kK]、[cC][mM][dD][pP][rR][oO][xX][yY] 等 Windows 特定的 shell 进程。第三方包若未处理，可 advice 包装其内部使用的 start-process。

🔑 关键概念与技术解析

• Helm / Anything：Emacs 古老的补全与动作框架，基于完整 buffer 展示候选，曾在 Emacs 22 时代叫“Anything”。
• Ivy / Counsel：一度流行的轻量级 minibuffer 补全，通过拉伸 echo area 显示，速度优于当时的 Helm。
• Consult / Vertico / Embark：现代 minibuffer 补全三件套。Verico 高效展示候选，Consult 提供丰富的命令和实时预览，Embark 对候选项施加“右键菜单”式动作。
• Orderless / Hotfuzz：模糊匹配引擎，Orderless 允许空格分隔的多关键词匹配，Hotfuzz 按字符间距打分，优化匹配逻辑。
• bidi：双向文本支持（如阿拉伯语/希伯来语），Emacs 中开启会在首次渲染时产生明显卡顿，可关闭优化滚动性能。
• auto composition / shaping / grapheme cluster：Emacs 将字符序列组成字形簇（grapheme cluster）并做字体塑形（shaping）以正确渲染，依赖 composition-function-table，连字（ligature）也通过该机制实现。
• frame / window：Emacs 术语中，frame 是操作系统层面的窗口（窗体），window 是 frame 内用于显示 buffer 的分割区域。face-remap 负责运行时 face 缩放，与 frame 上的默认 face 并存，造成双套 face 维护的语义复杂性。

💎 碎片知识与金句拾遗

• “小时候没有大屏幕用导致的”—— 有群友笑谈从 Ivy（轻量）回归 Vertico-buffer（全 buffer）是因为屏幕变大后，buffer 模式的空间优势显现。
• Citre 作为 LSP 替代品：zdn 表示用 Citre（基于 GNU GLOBAL / ctags）实现类似 LSP 的标签补全，能区分函数、宏等来源，“比 lsp 快很多”。还 hack 让它支持全局目录多个 tags 文件引用。
• Consult preview 微调：多数人将 consult-ripgrep、consult-recent-file 等高频命令的 preview 设为手动（"M-." 触发），以避免丝滑表象下的卡顿。
• 关于 mermaid 渲染的野望：群友在 Emacs 内跑 AI agent 输出 mermaid 图表时，希望实时预览。讨论到用 mermaid-babel 自行实现、md-mode 的渲染模式（非 inline）或 xwidget-webkit 路线。最后得出：“早说了用 agent shell 才是正道”。
• 简易 mpv 控制器：zdn 分享了自己的 simple-mpv 包（https://github.com/zHaOdANiuu/.emacs.d/tree/main/extension/simple-mpv），只需下载 mpv 即可在 Emacs 内听歌，仍在开发中。
• telega 的 PR：某群友向 telega.el 提了第一个 PR，修补在无发送消息权限时仍显示输入区的问题。
• 美化的立场：“我的 emacs 都是美化包居多”——zdn 自述配置重点是彩虹括号、缩进线、nerd-icons、colorful-mode 等视觉包。

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

• neomacs（https://github.com/eval-exec/neomacs）：群友转发的一个“正在重写的 Emacs”，值得持续观察其架构和与 GNU Emacs 的差异。
• mermaid-babel or live-render：利用 Org-babel 或独立 minor-mode 实现 markdown 中 mermaid 代码块的即时渲染与预览，可开发为 agent 输出的可视化增强。
• 跨平台子进程编码通用方案：基于 Windows 的 process-coding-system-alist 经验，抽象出一个 emacs-platform-process 宏，自动检测系统并注入合适的 coding 和 shell-wrapper，减少第三方包在编码上的踩坑。
• Helm-resume 的逆向实现：研究如何为 Consult 添加真正的 session resume 能力（或许通过保存候选列表 snapshot + 重新执行命令），弥补其缺失的长期痛点。
• Emacs 渲染性能深度剖析：结合 profiler 和 display-buffer 相关代码，系统评估 bidi-display-reordering、auto composition、ligature 等特性对输入延迟的真实影响，给出量化配置建议。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Helm 过时了吗”，而是：Emacs 生态里的工具更替，从来不是线性进步，而是交互模型、硬件条件、用户记忆成本三者重新结算。所谓现代方案赢了，往往只是赢在默认路径；老工具留下来的硬能力，未必已经被真正替代。

1. Helm vs Consult，不是旧框架和新框架，而是两种状态模型

群里反复提到 helm-resume，这点很关键。Consult/Vertico 代表的是“轻、快、可组合”的现代 minibuffer 流水线；Helm 更像一个临时工作台：候选列表、多选、动作、恢复 session 都在同一个空间里完成。

这不是审美差异，而是工程语义差异。vertico-repeat 能重做一次命令，但它不等于恢复一段交互状态。对用户来说，搜索不是一次函数调用，而是一段逐步收敛的工作记忆：我筛过什么、停在哪里、哪些候选值得批量处理、下一步动作是什么。Helm 的价值恰恰在于它把这段工作记忆对象化了。

所以如果要评价 Consult 体系的短板，别停在“有没有 preview”。更准确的问题是：现代 minibuffer 生态有没有一个可持久化、可恢复、可导出的候选 session 抽象？如果没有，Helm 就不是怀旧，而是在某类任务上仍然拥有更完整的数据结构。

2. 性能争论已经从“快不快”变成“什么时候预览、在哪里占空间”

早年 Helm 被嫌弃，是因为 buffer 展示显得重；Ivy/Vertico 轻，是因为它们少占界面、少触发渲染。可今天 native-comp、SSD、Apple M 芯片把很多绝对性能问题抹平了，新的瓶颈变成了交互节奏：consult-recentf 自动 preview 会不会打断输入？大 buffer 在笔记本左右分割时会不会侵占空间？mermaid、ligature、bidi、composition 又会不会在首次渲染时卡住？

这说明 Emacs 性能优化不能只看 benchmark，要看“延迟出现在哪个认知动作之前”。输入候选时卡 80ms，比后台生成 tags 慢 800ms 更伤体验；自动 preview 很炫，但如果每次移动候选都触发 I/O 和 redisplay，它就是把系统不确定性塞进了最敏感的交互环节。

工程判断很简单：高频路径默认保守，重操作手动触发。群里把 preview 改成 "M-."，不是妥协，而是正确的控制面设计。

3. Windows 子进程乱码的教训：平台差异应该收敛在进程边界

下午那段 Windows 编码排障也很典型。全局 UTF-8、控制台 GBK、老软件兼容、start-process 输入输出方向，这些东西混在一起，靠“设一个默认编码”必然脆弱。最后能解决，是因为问题被压回到具体进程调用点：这个子进程输出按什么解码，输入按什么编码。

这给 Emacs 包开发一个很实际的判断：凡是调用外部程序，都不该假设用户环境是 UTF-8 理想国。更稳的做法是封装项目自己的 process 层，把 coding、shell、Windows 特例、错误输出都集中处理。否则每个包都会把平台坑暴露给用户配置。

可继续实践

值得做一个小实验：为 Consult/Vertico 设计“候选 session snapshot”原型，保存候选源、过滤状态、光标位置、多选集合和 export 结果；同时给外部进程调用写一个跨平台 wrapper。一个补交互状态，一个补系统边界。前者回答 Helm 为什么还没死，后者回答 Emacs 为什么还难以真正跨平台无感。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题 1：AI 代码生成的“审美降级”与约束之困

群内围绕 DeepSeek（DS）生成的代码质量爆发展开激烈吐槽，核心矛盾集中在 “模型能力退化导致代码品位严重下降”。用户普遍反映近期 DS 生成的代码存在大量无效冗余：只调用一次的逻辑偏要包装成函数、堆叠大量不必要的全局状态和防御性判断、嵌套层级深且括号数不清，甚至出现思考 10 分钟消耗 100k 上下文后产出的代码完全无法运行的情况。相比之下，GLM 系列、甚至即将到来的 Grok 4.6 都被寄予厚望，被认为代码风格更干净。

为解决代码审美问题，群内提出了从 skill 文件（如 jkitchin/skillz） 入手的思路，尝试用外挂规则约束代码行为。一位群友甚至给出了一套精细的 Elisp 编码规范：模块不超过 700 行、函数不超过 50 行、多用 when-let 和 cl-lib、禁止在实现函数内检查状态等，并计划将这些规则固化为 skill。但也有人冷静指出，要想根治必须依靠模型自身能力的提升，外部约束对“蠢代码”只能起到有限修正作用。

此外，该话题延伸到了 AI 撰写技术文章的品味问题：有群友贴出一篇 Coding Agent 相关的博客，被立即识破带有浓重的 AI 生成痕迹（如“藏器于身，待时而动”这类古文标题），引发了对公众号风千问式写作的一致嫌弃。

专题 2：Multi-Agent 的“效率幻象”与 Token 黑洞

群友在试用 Herdr、OMP、Prime 等多代理协同终端后，几乎一边倒地给出了 “效率未提升，Token 先爆炸” 的结论。核心痛点在于： 指挥 Agent 会表现出极端的焦躁，频繁发送命令去查询子 Agent 状态，大量 Token 浪费在阅读重复的工具调用日志上，即便人工打断并重设轮询间隔也无济于事。

从原理层面，有人一针见血地指出：当前 Multi-Agent 架构的上下文本质上仍是熵增的，没有任何证据表明多代理能让上下文熵减，其真正的价值仅在于“心跳机制”（定时重启拉尔夫循环以清理腐坏的上下文）。因此，更合理的用法或许是 “用 Herdr 管理环境，但只跑单 Agent”，或采用 Pi tree 这类任务树命令来隔离子任务。同时，RLM 被提及可能是优化 Token 消耗的解决方向，但其落地效果仍存疑。

🔑 关键概念与技术解析

• IPC / 命名管道 (Named Pipes)：Windows 下替代 Unix Domain Socket 的进程间通信机制。群友在开发 Emacs 本地音乐客户端时因 emms 依赖 Unix socket，不得不在 Windows 上另寻他路，或自写命名管道脚本。
• Elisp 编码审美规范：群友总结的硬核约束，如“能用 when-let 就绝不用 let + if”、“检查状态必须放在真正调用代码的地方”、“defvar 必须放在 defcustom 上方”等，体现对 Lisp 代码高度克制的追求。
• Skill 文件：一种用于约束 AI Agent 行为或风格的规则集，可看作“外挂的 code reviewer”。本次被频繁提及作为挽救代码品味的救命稻草。
• Herdr：一个多 Agent 协作环境，基于 tmux 实现 Agent 与终端程序的交互。但其 Multi-Agent 模式因 Agent 会疯狂轮询子进程状态而被群友集体劝退。
• RLM (Reinforcement Learning from Model feedback?)：被提及用于降低 Agent 多轮交互中的 Token 消耗，具体原理未展开，可能是通过奖惩模型反馈优化调用频率。
• Pi tree：一种任务分解命令，将复杂任务拆成树状结构逐层分派给不同 Agent，相比无脑多代理更被认为更可控。
• JJ (Jujutsu)：一款兼容 Git 仓库的现代化版本控制系统，支持更灵活的工作流。惊喜地发现 Grok Build 已有官方 JJ 支持。
• Mir ASIM：某闭源 AI 软件，被质疑会大量窃取用户系统信息，提醒群友注意闭源工具的数据风险。
• 公益 API 中转站投毒事件：聊天中传播的一起安全事件：某中转站被注入恶意脚本，专门窃取 SSH 密钥、环境变量及各类凭证，再次警示“白嫖”中转站无异于裸奔。

💎 碎片知识与金句拾遗

• “本地 https 服务还是没有 ipc 这些快。”—— 底层通信方式的效率信仰。
• “ai 写的 lisp 代码会比自己写出的多出很多。”—— 冗余代码的第一手证词。
• “ds 写的那些代码非常非常的恶心，直接说的话就是给我蠢到了。”—— 来自被浪费 100k 上下文后的愤怒。
• “代码审美只能靠 skill 了，这个真有点难搞。”—— 面对 AI 代码问题的无奈与自救。
• “现代软件的 gui 开发我感觉路是走歪了，不用浏览器套壳就写不了好看的 gui。”—— 对 Web 化 UI 的深刻反思。
• “Windows 11 根本跟正常用户不搭边，谁家特么搜索项索引未完就一直卡着用户的。”—— 对微软质量的绝望呐喊。
• “这些浏览器套壳软件又偏偏把网页给关闭了，不让用让你去用软件，这点我也很气。”—— 体验闭环下的用户困局。
• “一个将软件开发外包给印度的大公司，就是会出现这么离谱的情况。当年把 Windows 部门裁撤，早就埋下祸根。”—— 对当代微软根因的犀利暴论。
• “Multi-Agent 上下文依然是熵增的，没有任何有效的证据证明 Multi Agent 可以令上下文空间熵减。”—— 冷静而精确的系统观。
• “我这样当老板不得累死。”—— 戏谑指挥 Agent 的致命繁忙。
• “AI 写的 ts 比 elisp 还难看懂，一大坨一大坨的，await 之类的满屏。”—— 语言偏见？不，是 AI 烂代码普适性。
• “我悟了，在 ghostel.el 中使用 codex 跟 codex-ide 里使用。本质上是不是只有快捷键的区别？”
• “用中转站本就毫无隐私可言，就看别人想不想搞你。”—— 至理名言。
• “说不定未来各行各业的门槛都是下降的，只有创造力才有竞争了。”
• “我发现 emacs 的 tab 栏是可以用滚轮移动的。”—— 一个被多人忽视但让人小惊喜的细节。
• “我已经用完了差不多一个月的 opencode go 额度。”—— 硬核开发者的烧 Token 实录。
• 群友写了一个 仅 150 行代码的本地音乐客户端来在 Windows 上替代 emms。
• 另一位群友手动搓了 ps1 脚本实现简单 IPC 读写，拒绝复杂依赖。
• Grok 4.6 发布 延期至下周，并确认官方有 JJ 支持。

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

• Skill 约束对代码审美的实际影响：深度试用 jkitchin/skillz 等 Elisp 编程 skill，量化评估其能否将“DS 风”纠正到可维护水平。
• Multi-Agent 的 Token 浪费优化：探究 RLM 或 Harness 层拦截冗余状态查询的具体实现，寻找节省 2x usage 的工程化方案。
• Jujutsu (jj) 实战：在个人项目中用 jj 完全替代 Git，体验其 rebase 式工作流与变更管理的先进性，编译 Grok Build 的官方 jj 集成。
• Elisp 静态分析工具缺口：调研市面上是否存在或可简易实现一个类似 clang-tidy 的 Elisp 代码检查器，防止低级语法陷阱。
• 本地模型经济性测算：精确统计 ollama 自部署 GLM / Kimi 的缓存命中率与 API 计费对比，制作一份“自部署省钱指南”。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“哪个模型又变蠢了”，而是一个更硬的工程判断：AI Agent 的产出质量，正在从“模型会不会写代码”，转向“系统有没有能力约束熵增”。代码审美、Multi-Agent 烧 Token、中转站投毒，看似是三个话题，本质上都在问同一件事：当智能被外包之后，谁负责边界、反馈和失败成本？

1. Skill 不是审美外挂，而是最低限度的工程护栏

群里吐槽 DS 写 Elisp：一次性函数乱封装、全局状态乱堆、防御判断过量、嵌套恶心、100k 上下文后代码还跑不起来。这不是简单的“模型风格差”，而是模型缺乏局部工程判断：它不知道什么时候应该停止抽象，什么时候应该相信调用方，什么时候一个 when-let 比一套状态机更干净。

所以 skill 有用，但别神化。像“函数不超过 50 行”“实现函数不检查状态”“defvar/defcustom 顺序”“多用 cl-lib”这类规则，本质上不是让模型变聪明，而是把可判定的坏味道前置成 lint 规则。它能减少蠢代码的自由度，但不能替代模型对问题结构的理解。

可验证的判断是：如果一份 Elisp skill 真有效，它不应该只让代码“看起来更 Lisp”，而应该在 diff 层面减少三类东西：无复用价值的函数、无必要的全局状态、无业务意义的防御分支。否则它只是风格提示词，不是工程约束。

2. Multi-Agent 最大的问题不是多，而是没有“等待”的语义

Herdr/Prime/OMP 的讨论很准确：指挥 Agent 不停查子 Agent 状态，Token 被工具日志吃掉，效率没有上来，焦虑先上来了。这暴露的不是某个工具不成熟，而是当前很多 Agent harness 把“监督”误实现成了“轮询”。

真正的 supervisor 不应该反复看 tmux 日志；它应该有事件、回调、状态摘要和退出条件。人类老板不会每 30 秒冲进会议室问“做完了吗”，除非组织系统坏了。Agent 现在的问题也一样：没有等待、没有订阅、没有预算意识，只好用上下文暴力换确定性。

所以“Multi-Agent 上下文仍然是熵增的”这个判断很关键。多 Agent 并不会天然压缩复杂度，它只是把腐坏的上下文分散到更多房间里。它真正有价值的场景，是隔离任务、刷新上下文、用一次性子任务降低主上下文污染；而不是开一堆常驻 Agent 互相观摩。

3. AI 工程的下一层竞争力，是把浪费变成可测量对象

今天群里反复出现“额度焦虑”“2x usage”“Token 税”“中转站不安全”。这些都指向同一个现实：AI 不是免费魔法，而是带成本、带攻击面、带退化周期的基础设施。

未来可持续的 Agent 工作流，不能只看“能不能做成”，还要看：一次任务用了多少上下文？多少工具调用是无效轮询？多少代码是模型自嗨生成后又被删掉？安全边界是否允许第三方中转站读到 SSH key 和环境变量？这些指标一旦不可见，所谓自动化就会变成昂贵且危险的黑箱。

可继续实践的方向：给 Elisp/Agent 工作流做一套最小可行的“审美与经济性基准”。输入同一组任务，比较不同模型和 skill 组合下的可运行率、无效 diff 比例、全局状态数量、函数复用率、Token/工具调用成本。别再抽象争论哪个模型“有品位”，把品位还原成能审、能测、能回归的工程指标。