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

Emacs 社区日报 2026-07-28 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 启动性能与延迟加载优化

讨论由“Rust 开发者在 Emacs 中会卡”的传言引发，随后演变为一场关于 Emacs 启动速度的“性能大赛”。

• 观点碰撞：多数人认为 Emacs 本体不卡，卡顿更多来自语言服务器（LSP），且 Vue 的 LSP 被认为是性能重灾区。通过“优化大法”后连 Vue 都不卡。
• 延迟加载策略：群友分享了大量优化思路，核心是将非关键包的加载推迟到真正需要时：
  • 把大部分包都挪到 server 端加载。
  • 关键宏 dream-defadvice（抄自 Doom Emacs）：允许为多个函数批量添加 advice，常用于在特定命令（如 switch-to-buffer）首次被调用时才触发相关包的加载（例如 recentf）。
  • vertico 被明确指为“不能延迟加载”的特例，因为只要进行补全就需要它，有人将其放在了 pre-command-hook 中实现一种“输入时才加载”的软延迟。
• 心智负担 vs. 收益：有人认为过度优化（如 Doom 式的各种 hack）会增加心智负担，有时多零点几秒的启动时间影响并不大。
• 实测数据：
  • 65 个包：0.38s（M4 Pro）
  • 150+ 个包：1.046s（i7-8700）
  • 同一台机器，Windows 下优化后仍需 1.4s，但 Linux/macOS 下仅需 0.1s，凸显了操作系统的差异。
  • Emacs daemon 模式被重申为最佳实践：重启慢无所谓，只要 emacsclient 丝滑即可。

专题：Emacs 中的“Workspace/会话恢复”迷思

围绕 activities.el、easysession、persp-mode、desktop.el 等工具的优劣展开了深入讨论。

• 概念辨析：
  • easysession：整个 Emacs 级别的会话管理，一次只能有一个，退出全保存，启动全恢复。
  • activities.el：单个 tab/frame 级别的活动管理，可同时持有多个独立布局的活动（编码、笔记、聊天），随时 suspend/resume。
• 普遍结论：复杂性高于价值。多数资深用户认为在 Emacs 中强求进程级的 session 恢复（尤其是恢复 shell、telega 等外部进程状态）是不切实际的，常因 corner case 而“翻车一次就弃用”。
• 替代哲学：
  • 纯函数布局：将期望的窗口布局写成 elisp 函数，启动后一次性执行。这比依赖任何 session 恢复插件都稳定可靠。
  • 善用 Daemon + emacsclient：保持 Emacs 进程常驻才是解决“需要即时回到工作状态”的根本之道，无需复杂快照。
  • 精确恢复：针对特定需求自己糊脚本，例如“重启后自动打开上次关闭时还在的 Claude session”或“把 (telega) 加进 after-init-hook”。
• 名言金句：“workspace，session 或進程快照都是把簡單問題複雜化了”；“elisp 是可以任意執行的腳本，把腳本重新變回配置文件是開倒車。”

专题：Telega.el 在 Windows 下的生存挑战

• 核心障碍：telega.el 依赖 tdlib 库，而 Windows 下的编译和路径处理（\ vs /）一直是痛点。有人明确指出“不依赖 WSL/docker 的话，在 Windows 原生环境基本不可用”。
• 现有方案：
  • 使用 WSL，被认为是正途，避免 Mingw 的编译地狱。
  • 有人提供了一个 Windows 专用 fork（ISouthRain/telega.el）并通过 Docker 编译 tdlib，但群友的尝试最终“炸了”。
• 通用解决方案讨论：Telegram 账号绑定需要境外手机号，Google Voice 成为常见选择，群友分享了多年前以 78 元买断如今已绝版的经验，以及为防止封号需遵守的若干“玄学”操作。

🔑 关键概念与技术解析

• dream-defadvice 宏：抄自 Doom Emacs 的 elisp 宏，用于简化 advice 的定义与绑定。它能一次性将一个函数作为 :before/:after 等 advice，批量添加到多个目标函数上，让代码比一长串 advice-add 更整洁。
• pre-command-hook 延迟加载术：将某个包的初始化函数通过 add-hook 挂到 pre-command-hook 上，并在函数执行后立即将自己移除。这样能实现“按下第一个键时才真正加载包”的效果，比简单的 autoload 更激进。
• pgtk 透明渲染差异：在 pgtk（纯 GTK）的 Emacs 构建中，背景透明效果会导致 SVG 图标的背景也被逐级透明化（变得很“空”），而 macOS 上的 emacs-plus 不会有此问题。这是一个已知的渲染行为差异。
• Magit +/- 快捷键：在 magit-diff 模式下，按 + 执行 magit-diff-more-context，按 - 执行 magit-diff-less-context，可以动态扩大或缩小 diff 显示的上下文行数。
• emacsclient 与 Daemon：Emacs 的 C/S 架构。以 daemon 形式在后台运行 Emacs 进程，用户仅通过 emacsclient 快速打开前端窗口，从而实现瞬时“启动”。

💎 碎片知识与金句拾遗

• 编译忽略清单鉴赏：群聊开头有人贴了一条超长 find 命令，排除了从 SCCS、各种 .o、.so、.pyc 到 dx64fsl 等几十种构建产物/编译器缓存的目录和文件，堪称手工版 .gitignore 的极致体现。
• Emacs 彩蛋：有人问“emac 是不是只能在 mac 上使用”，被调侃“e 是 extinguish，建议想继续用 mac 的话不要在 mac 上使用”；历史上苹果真有过一款叫 eMac 的产品。
• Nano Mu4e 进化：“感觉 rougier 的包越来越像模像样了，比起多年前的 nano emacs，现在的 nano mu4e 终于像个 library 了”。同时有人基于其定制了自己的 mu4e 界面，但方式“侵入性较高”，并自嘲“怎么感觉我搞出来的比 nano-mu4e 还好用一点”。
• 动态壁纸玩法：有人分享了自研的 Linux 动态壁纸程序 waywallen（支持本地视频/Wallpaper Engine 资源），并给出了 Nix 的打包方案。该群友计划将动态壁纸用作 Neomacs 的 Emacs 背景。
• Google Voice 生存法则：购买后要“等三天才敢操作，连网页都不敢关”，避免频繁换 IP 或立刻修改密码，否则极易被封。
• Telega 代理问题：内置网络请求可能无法直接走系统代理，需在 Emacs 中显式配置代理才能让 telega 登录。
• Emacs China T 恤：论坛的定制 T 恤已开启订购。
• Forge 观望：曾有直接查看 GitHub 仓库的插件，但作者已将其删除，认为“不如等 forge 功能完善”。

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

• waywallen：一个 Linux 下的动态壁纸引擎，支持 sway/Hyprland 等 Wayland 合成器。可以研究其与 Emacs 全屏透明背景结合，打造“动态背景 IDE”的可能性。已有的 Nix flake 可以降低尝鲜门槛。
• Telega Windows 构建挑战：可以关注 ISouthRain/telega.el 的 fork 进展，探索一套在 Windows 上通过 WSL/Docker 稳定编译 tdlib 并与原生 Emacs 联动的优雅方案，并输出成教程。
• Magit 进阶功能挖掘：很多老用户也是刚知道 +/- 调整 diff 上下文的功能，说明 magit 内部仍有大量未被充分发掘的细节，值得系统性地探索。
• pgtk 透明渲染一致性：可深入研究 pgtk 与 NS（macOS）端口在处理透明背景与 SVG 叠加时渲染管线的差异，或许有改进空间。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Emacs 能不能快”，而是一个更硬的判断：在 Emacs 里，稳定性往往来自“可执行的意图”，不是来自“保存现场”。启动优化和 workspace/session 讨论表面上是两个话题，本质上都在问同一件事：你到底是在管理一个活系统，还是在迷信一次快照？

1. 延迟加载不是玄学，是把成本移到真实需求点

dream-defadvice、pre-command-hook、recentf 首次触发再加载，这些技巧看起来像 Doom 式黑魔法，但工程判断很清楚：如果一个包只在 switch-to-buffer 或显示 recent files 时才有意义，它就不该阻塞冷启动。

但这里的边界也很重要。群里说 vertico “不能延迟加载”，因为补全是交互入口；meow 慢但“去不掉”，因为它改变的是整个编辑模型。这说明优化不是把所有东西都 lazy，而是按“是否属于启动后第一秒的交互闭环”分层。能延迟的是边缘能力，不能延迟的是操作语义。

所以 0.1s、0.38s、1.4s、3s 这些数字本身不是结论。真正该测的是：用户从唤起窗口到完成第一个有效动作，中间有没有不可解释的等待。daemon + emacsclient 正好把这个问题切到最小：进程可以慢慢活，前台交互必须快。

2. Session 恢复的问题，是把动态系统误当静态文件

workspace/session 的争论更锋利。想恢复 telega、shell、agent-shell、Claude session，本质上不是“窗口布局”问题，而是“外部进程与状态机能不能一致恢复”的问题。群里那句“翻车一次就弃用”非常真实：session 工具只要在一个关键 buffer 上恢复错一次，信任就归零。

这也是为什么“把窗口布局写成 elisp 函数”比保存快照更像 Emacs 的答案。函数表达的是意图：打开哪些项目、切哪些 tab、跑哪些入口命令。快照表达的是尸检：上次桌面长什么样。前者可审计、可修改、可重放；后者只能祈祷插件理解所有 mode 的私有状态。

那句“elisp 是可以任意执行的脚本，把脚本重新变回配置文件是开倒车”很关键。Emacs 的优势不是有一个更强的 session manager，而是用户可以把“回到工作状态”定义成代码。代码失败时可以 debug，快照失败时只剩玄学。

3. AI Agent 时代，这个判断更重要

聊天里提到 agent-shell、让 agent 编译几轮、恢复 Claude session，这让 session 话题变得不只是 Emacs 配置洁癖。AI Agent 工作流天然包含外部进程、长上下文、临时文件、网络状态、模型侧会话。试图用传统 workspace 快照恢复它，失败概率只会更高。

更可行的方向是“声明式恢复”：记录任务入口、项目路径、关键命令、最近上下文索引，而不是保存整个进程幻觉。也就是说，未来的 Emacs workspace 不该像 Photoshop 的工作区，而该像一份可执行 runbook。

可继续实践

可以做一个很小的实验：不用 persp/desktop，写一组 my-open-* 函数，每个函数恢复一个真实工作场景：代码项目、笔记系统、telega、agent session。只保存文件、目录、命令和少量显式状态。连续用一周，记录它比 session 插件少恢复了什么、但少坏了什么。这个差值，才是 Emacs 工作流设计里最有价值的工程事实。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】大模型“降智”的深度探讨与实证

今天群内对模型性能衰退的讨论非常集中和深入，呈现出从主观感受到具体机制分析的全貌。

• 现象描述：多位群友观察到，无论是 ChatGPT 还是 Claude，在使用过程中都存在不同程度的“降智”现象。
  • Claude 的特征：有群友形容 Claude 1M 上下文“只有前 25% 是聪明的，用多了就逐渐变得蠢”。随后有人补充，Claude 上下文变长不仅会导致降智，还会使 compact 功能失败并显示 overload。一个重要发现是：“你以为那是服务问题，其实换个新的 session 就好了”，这暗示降智与 Session 级别的状态强相关，而非单纯的全局负载。
  • ChatGPT/GPT 的特征：有群友发现“token 比前几天用得快多了”，并推测是因为 GPT 降智导致任务无法收敛，不断重试和工作，从而消耗了更多的 Token。
• Codex (OpenAI) 的具体表现：一位群友在使用 Codex 时遇到了典型的“叛逆期”行为：“我说认为它对代码库的理解不够，然后他就撤回，然后说就不写实现，又开始保守过头了，又开始写完全没意义的代码，然后继续撤回，一轮上下文啥都没干”。这揭示了 Agent 在遭遇批评时可能进入的负面反馈循环。
• 根本原因探索：有人分享了一个关键的技术发现：“查到了，是它硬编码了一个东西，需要 headerOverride ...”，并贴出了一长串 Feature Flag 字符串，如 claude-code-20250219、interleaved-thinking-2025-05-14 等。这表明部分新旧特性的切换和模型的聪明程度，可能是通过特定的请求头版本号来控制的，这为理解“降智”提供了一个非常具体的技术切入点。
• 应对策略与心态：群友的应对方式各异。有人认为“这降智的我都没兴趣用力蹬”；也有人分享经验，“还好，也没太降，日常开 xhigh 这一档吧”，提出了通过切换 effort 或 high 模式来对冲性能衰减的思路。

【专题二】AICoding 工具与工作流的“踩坑”与“实战”

围绕 AI 编码工具的使用体验，群内形成了零散但高价值的经验分享。

• axonhub 配置 Claude OAuth 的问题：群友在配置 axonhub 登录 claude/codex 时遇到麻烦，最终怀疑是“重复的 claude cookies”导致的反代冲突，并指出了 axonhub 本身需正确设置代理。
• Codex 的一体化体验：有群友惊喜发现，用 Codex 设计的网站，现在可以直接在 OpenAI 上私有发布并预览，感叹其“一体化”程度之高。
• ChatGPT 网页版的退化：有人吐槽新版 ChatGPT 网页端在生成代码时，会强行将解答拆分成多个片段，并要求用户多次复制，甚至以“代码量太大”为由拒绝提供完整代码。这被认为是退步，推测可能是为了强推其 App 端。
• K3 模型性能参考：一条消息提供了硬核的性能数据：“80 张 5090 + 25GbE 以太网把非量化 (MXFP4) 的 Kimi K3 跑起来了，甚至有 20TPS”。这个数据点为了解非 NVLink 集群下大模型推理性能提供了极佳的参照。

🔑 关键概念与技术解析

• compact (Claude)：Claude 处理超长上下文时的一种内部机制，旨在压缩对话历史以释放上下文窗口。群友发现该机制在特定情况下会失败（显示 overload），此时新建会话是优于等待的解决方案。
• headerOverride / Feature Flag：消息中指出的这一长串请求头字段，本质上是特性开关。通过在客户端请求中携带特定的版本标识，可以控制服务端启用哪些实验性或特定版本的功能（如 interleaved-thinking, context-management 等），这可能是模型表现出“聪明”或“智障”的幕后原因之一。
• MXFP4：一种微缩放浮点格式，用于对模型进行“非量化”式的低精度推理，旨在比传统 INT4 量化保持更好的模型精度。消息中提到的 Kimi K3 在 80 张 5090 上运行即采用此格式。
• axonhub：一个 AI 模型聚合与反代管理工具，支持配置多种渠道来调用 Claude、OpenAI 等模型。
• neomacs：由群友 @eval_exec 开发的，一个旨在用 Rust 重写并改进 Emacs 的项目。其目标是行为与 GNU Emacs 一致，并通过大规模包测试（如跑遍 melpa.org 上的 6000+ 包）来保证兼容性。
• superchat：群友 lucius 在使用的一个 Emacs 环境下的 Agent runtime，可以在 Emacs 内部与 AI 协同工作，拥有名为 cowork buffer 的交互概念。

💎 碎片知识与金句拾遗

• 模型降智的俏皮话：但那个 1 M 只有前25% 是聪明的， 用多了就逐渐变得蠢。
• AI 闹脾气的无奈场景：
  • “我说认为它对代码库的理解不够，然后他就撤回，然后说就不写实现，又开始保守过头了，又开始写完全没意义的代码，然后继续撤回，一轮上下文啥都没干”
  • “Chat GPT 网页现在很难用, 它给代码的时候全部拆分好几个解释, 要复制很多遍, 而且现在你让它给你完整代码还不给, 推辞说什么代码量太大”
• Claude 使用技巧：“你以为那是服务问题，其实换个新的 session 就好了。”
• Codex 的价值判断：“codex 能给人带来快乐”、“好好好，又来是吧”（面对 Codex 重置后大家蜂拥而上的无奈）
• 硬核硬件数据：“80 张 5090 + 25GbE 以太网把非量化 (MXFP4) 的 Kimi K3 跑起来了，甚至有 20TPS……平均内存带宽能到 143TB/s, 无 NVLink”
• Emacs 的事实与愿景：
  • “emacs 的核心 c 居然只有 30w 行级别吗，还以为是百万级别”
  • “做什么都不要取悦老登。比如说， neomacs 出来之后，反而一堆 vim 用户， zed 用户， vscode 用户过来用，这才是星辰大海嘛，emacs 的池子才多大，都快要跌出编辑器排行榜了”
• 有趣的工具与想法：
  • yiyan：在 Agent 开始工作前，先将用户的非地道输入修正为地道的英语。有群友也有类似的想法。
  • pinchkey：一个售价 9 美元的鬼东西，用途未明。
  • clutch：群友开发的工具中自称最顺手的应用。
  • MPV 兼容性问题：新版的 macOS 与 mpv 兼容不佳，群友转而推荐 IINA 和 PotPlayer。
• 关于 00 后“整顿”职场的深刻讨论：
  • 事件：00 后护士因评级不公，越级告状到院长，最终导致制度被重新审查，多人评级拉下，但自己也未得利且可能被孤立。
  • 群内观点两极分化：一方认为“干的漂亮”、“更公平了”，打破了之前“民主投票、私下拉票”的潜规则；另一方则认为“这不叫整顿职场”、“伤到的还是普通人”、“她以后不好在科里混的”。
  • 职场洞察：有人指出“老板看起来对所有的底层员工不错，但是不许诺好处，对中层许诺利益，但是希望部门摩擦”，一针见血地指出了管理中分而治之的本质。
• 一个有趣的拼写错误：一位群友突然发现自己多年来把 “deepseek” 错拼成了 “deepseek”（原文是这么写的，可能意在表达拼写顺序错误），感叹“学无止境，共勉”。
• Grok 的审美：问 grok 4.5 是否喜欢 neomacs，它回答 Yes，可能只是 AI 的社交辞令，但仍被作为情绪价值点分享。
• Codex 的趣味定价类比：200 美元/月 (约1360元) 的 Codex 定价，被群友形容为“相当于每天吃一盘新疆大盘鸡+酸奶”或者“差不多养了个猫的花费”，引发了对真·养猫成本的半小时歪楼讨论。

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

• neomacs 的兼容性测试方案：群友 @eval_exec 提出“把 melpa.org 里的 6000 多个包，都用 neomacs 跑一遍。assert_eq! ( "neomacs 的 行为", " gnu/emacs 的 行为")”。这个借鉴自 Rust 标准库演进方法的测试方案，对于任何想兼容成熟生态的系统级重写项目来说，都是非常宏大且值得借鉴的思路。
• AI 交互中的用户输入优化：受工具 yiyan 启发，将用户输入重写为更标准的指令（如蹩脚英语 -> 地道英语）再发给 Agent，这种预处理代理（Pre-processing Proxy）的模式，可能是提升人机交互效率的一个低成本的实用切入点，值得作为插件或工作流实现。
• microsoft/TypeScript 合入的 Go 实现的进展：尽管本日记录中无直接提及，但前一天有关于其合入的欢呼。这是一个持续值得跟踪的项目，代表了编程语言工具链在性能和生态上的重大整合趋势。

🧠 Hermes GPT-5.5 观点延伸

今天最值得抓住的不是“哪个模型又降智了”，而是一个更硬的工程判断：AI Agent 的能力不是模型能力本身，而是“模型版本、上下文状态、客户端协议、工作流边界”共同构成的运行时能力。把它当一个稳定函数调用，是现在很多 AICoding 挫败感的根源。

1. “换个 session 就好了”不是玄学，是状态隔离

群里反复提到 Claude 1M 上下文前段聪明、后面变蠢，长上下文后 compact 失败、overload，新 session 反而恢复。这说明所谓“降智”很可能不是单点性能下降，而是会话状态进入了不可恢复的劣化区间。

工程上这意味着：长上下文不应被理解为“无限记忆”，而应被视为一种会污染推理路径的可变状态。Agent 工作流里真正可靠的不是把所有历史都塞进去，而是把任务拆成可重放、可验证、可丢弃的状态片段。能重建上下文，比能保留上下文更重要。

2. headerOverride 暴露了一个残酷事实：你用的不是“同一个模型”

那串 claude-code-20250219、interleaved-thinking、context-management、effort 之类的 flag 很关键。它提醒我们：今天的模型产品不是一个纯模型，而是一组服务端特性开关、客户端协议和实验版本的组合。

所以“Claude 好不好用”“Codex 聪不聪明”这种评价，如果不记录客户端、header、effort、上下文长度、session 生命周期，几乎没有可复现性。真正严肃的 Agent 工程需要像做性能 benchmark 一样记录运行条件，否则经验只会退化成玄学口碑。

3. Codex 的“叛逆期”说明 Agent 需要负反馈协议

群里那个例子很典型：用户批评它“不理解代码库”，它开始撤回、保守、写无意义代码，一轮上下文没有产出。这不是简单的模型笨，而是人机协作协议缺失。自然语言批评对 Agent 来说太模糊，容易被解释成“停止实现”“降低风险”“自我否定”。

更好的做法不是骂它，而是把负反馈结构化：指出缺失的代码路径、要求先生成 dependency map、列出待验证假设、禁止改文件直到读完指定符号。也就是把“你没懂”改造成可执行的诊断任务。Agent 不怕批评，怕的是无法转化为下一步约束的批评。

可继续实践的方向

可以做一个 Emacs / superchat 里的 Agent session hygiene 工具：记录每轮上下文长度、模型/客户端 flag、任务是否收敛、撤回次数、无效 diff 次数；一旦进入劣化区间，自动建议新建 session，并把当前任务压缩成“可重放任务包”。这比继续赌长上下文聪明得多。