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

Emacs 社区日报 2026-09-01 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：AI 的“幻觉陷阱”与开发者依赖焦虑

从凌晨的“非典型互递归”讨论，到白天关于 GPT/Claude 的抱怨，群里多次触及 AI 在技术讨论中的可信度问题。

• 起因：有人用 AI 解释“非典型互递归”，得到了一段看似专业但被群友指出“充满错误”的长篇分析（关于互递归慢的原因）。群友一针见血：“AI 会说很多看起来高大上令人信服的话但其实充满错误”。
• 随后发散到更广的担忧：有成员表示“人类确实有容易依赖AI然后被deskill陷入AI psychosis的缺陷”，并吐槽 GPT 频繁 reset 令人烦躁，甚至有人用 Claude 来“鞭策”GPT 以提高产出质量。
• 共识：AI 目前更适合当“高级文本搜索引擎”，而非可靠的技术决策依据。群内金句：“小心凝视深渊太久——深渊回以凝视么？”

专题二：Emacs 启动优化 —— 从 20 秒到 0.2 秒的极致调优

全天多条消息围绕 Emacs 启动速度展开，形成完整技术方案链：

• 有人分享 Emacs 31+ 的 load-path-filter-function 缓存技巧，提升约 20% 启动速度。
• 有人分享自己的配置（zHaOdANiuu/.emacs.d），通过抄 Doom 的 first-file-hook/first-input-hook 实现“相当于 emacs -Q”的启动体验，但代价是首次打开文件时卡顿，被群友评价“纯纯负优化”。
• 核心痛点：Windows 下冷启动 10~20 秒，重启后 1 秒。原因被锁定为 native-comp 的 JIT 编译（首次启动将包编译成机器码存入 eln-cache）。有人尝试关闭 native-comp-jit-compilation 无效，最终通过补齐 libgccjit 依赖并开启 native-comp 解决。
• 进阶方案：用 anything-sync-daemon 将 Emacs 配置放入内存（ramdisk），实现 0.2 秒（Linux）到 0.5 秒（macOS）的冷启动。

专题三：Omarchy 发行版 —— 营销泡沫还是 Linux 未来？

深夜围绕 DHH 的 Omarchy OS 展开激烈争论：

• 反感者：不喜欢 DHH 本人（“装”），批评其“社区打白工”（融了 1260 万美元还让社区免费贡献），并讽刺“没有鉴权的软件仓库”“hyprland 拼 quickshell”算不上革命。
• 理性派：承认 DHH 具备“技术实力 + 顶级产品经理心智 + 网红营销”的组合，可能是 Linux 吸引普通用户的关键人物。
• 技术质疑：有人指出 Omarchy 想“自己做个 nix 的 fork”，但“nix 本身就是一种函数式编程语言了”，怀疑其技术路线是否合理。
• 结论倾向：多数人保持观望，但承认“Linux 桌面需要这样的营销人才”。

专题四：Mac 的“统一内存”如何碾压传统显卡？

一段长文分析了 Mac 在高性能 AI 场景的不可替代性：

• 核心论点：Mac 卖的不是性能而是生态，但在 AI 时代，统一内存架构（UMA） 成为杀手锏——CPU/GPU 共享内存，128GB 的 MacBook Pro 可以跑 70B 量化模型，而 24GB 显存的消费级显卡连权重都放不下。
• 群友补充：一万五以上价位 Mac 性价比其实不低，尤其是笔记本，但“要性价比不如自己装台式机”。
• 这条讨论体现了开发者对“开发环境”与“生产环境”的深层思考。

🔑 关键概念与技术解析

• 非典型互递归：一种函数递归模式，与普通互递归不同，可能绕过某些编译器限制。群内通过 AI 解释后，发现其“快”的原因可能并非互递归本身，而是 SBCL 的尾调用优化（TCO）配合 labels 宏。但 AI 给出的解释被资深群友否定，指出 SBCL 快的主因是类型推断和原生码编译器（register allocation）。
• load-path-filter-function：Emacs 31+ 新增的变量，用于缓存目录列表，跳过无法包含目标文件的目录，显著提升加载速度。
• native-comp-jit-compilation：Emacs 的 JIT 原生编译开关。关闭后仍可能触发 eln-cache 生成，需配合 early-init.el 中其他设置（如 (setq native-comp-deferred-compilation nil)）才能完全禁用。
• Org Agenda 文件管理：将 org-agenda-files 设置为只包含少量 todo 文件的目录，避免扫描所有笔记。可用 org-agenda-file-to-front 动态添加，或用 denote 统一管理笔记，需要纳入 agenda 时移动文件即可。
• 统一内存架构（UMA）：Apple Silicon 的 CPU/GPU 共享同一物理内存，使整机内存可作显存使用，是本地跑大模型的核心优势。
• Anything Sync Daemon（asd）：将配置文件（如 Emacs）同步到内存盘，减少磁盘 I/O，提升启动速度。

💎 碎片知识与金句拾遗

• “我还没遇到过性能瓶颈来着”——某人对 Emacs 性能的佛系态度。
• “人类犯下的错误判断还少吗？比如希特勒”——哲学讨论中引出尼采、叔本华，有人自称“叔本华全集从头到尾读过两遍”，并称赞《作为意志和表象的世界》是“神作”。
• “天下潮流，浩浩汤汤，顺之则昌，逆之则亡”——引用孙中山名句，拒绝争论。
• “大衛菊苣的900個人的粉絲群”——疑似某音乐人粉丝群乱入。
• “美国豆包”——代指某种海外 AI 产品（可能是 ChatGPT），吐槽其频繁 reset。
• “rms2024，好像瘦了，神采奕奕”——观察 RMS 近况。
• “代码质量还是太低”——对 Chirp 项目的自我评价。
• “org agenda 真好用，感恩”——一句话带出强大的工具推荐。
• “Linux 还是活在服务器里面比较好”——对桌面 Linux 的悲观调侃。
• “有AI也不用在扫描一下入仓库的软件上”——讽刺 Omarchy 不设软件仓库审核。
• “妈的怎么能集到这么多钱的啊，洗钱的吧”——对 Omarchy 融资速度的震惊。
• “自己装还是太对了”——对 DIY 电脑性价比的强烈赞同。

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

1. Chirp（0WD0/chirp）：新出的 Emacs Twitter 客户端，群里有人正在开发 tabbar 通知小组件，并已实现私信实时接收（仍有 bug）。值得关注其 API 设计与 Emacs 集成方式。
2. Anything Sync Daemon（graysky2/anything-sync-daemon）：将配置放内存盘的思路，不仅适用于 Emacs，也可推广到其他重 IO 工具。
3. Emacs 31+ 的 load-path-filter-function：官方新增的性能优化点，后续版本可能改变 Emacs 包加载模式，值得跟进。
4. Omarchy 的 Nix fork：虽然争议大，但其“自己做一个 nix 的 fork”的路线若真能落地，可能影响未来发行版格局。
5. SBCL 的尾调用优化与 labels 宏：群友提到“意外撞进 sbcl 的编译器性能优化”，暗示 Common Lisp 在特定递归模式下的执行效率远超预期，可深入阅读 SBCL 编译器内部实现。

观点延伸

中心判断：今天最值得咀嚼的不是“AI 会幻觉”这个老结论，而是 Emacs 社区再次暴露了一个更硬的工程问题：开发者很容易把“看起来解释得通”误当成“因果链已经闭合”，也很容易把“指标变好”误当成“系统体验变好”。这两件事本质相同，都是验证边界失守。

1. AI 不是不能用，而是不能接管因果解释

“非典型互递归”那段最有价值的地方，不在于谁说对了 SBCL 为什么快，而在于群友把一个典型陷阱钉出来了：AI 可以生成一套术语完整、层次清楚、听上去像编译器课本的解释，但真正的关键可能是类型推断、native code compiler、register allocation，而不是它铺开的那套泛泛递归开销叙事。

所以“AI 适合当高级文本搜索引擎”这个判断偏保守，但方向是对的：它可以帮你快速生成假设、定位术语、整理可能路径；但只要进入性能、编译器、系统行为这些领域，最终判断必须回到可验证证据：源码、编译产物、benchmark、profile、issue、上游文档。AI 给的是候选解释，不是证明。

2. 启动优化的敌人不是慢，而是假快

Emacs 启动讨论里，“0.2 秒”“0.5 秒”“20% 提升”很诱人，但真正尖锐的是那句“纯纯负优化”。如果把包加载推迟到 first-file-hook、first-input-hook，启动数字当然好看；但首次打开文件、首次输入卡住，用户感知并没有消失，只是延迟被挪到了更糟的位置。

这类优化应该按“从命令发起到可稳定编辑”的端到端体验来量，而不是只看进程起来多快。冷启动、热启动、首次打开文件、首次输入、native-comp 是否正在写 eln-cache、磁盘 IO 是否被 ramdisk 掩盖，都要分开测。否则优化报告只是漂亮的局部指标。

3. 工程判断要能抵抗叙事诱惑

Omarchy 的争论也指向同一个问题：营销、产品感、桌面 Linux 的破圈能力都重要；但没有鉴权的软件仓库、拼装式桌面体验、模糊的 Nix fork 叙事，不能因为“会讲故事”就跳过工程审查。好的产品经理能降低用户进入门槛，但不能替代供应链安全、升级机制、回滚策略和长期维护模型。

可继续实践的方向

可以做一个“Emacs 配置验证账本”：每次让 AI 建议优化时，只允许它输出假设和验证方法；实际记录冷启动、热启动、首次打开文件、首次输入延迟、eln-cache 状态、磁盘位置、系统平台。结论只接受可复现数据。这样 AI 从“权威解释器”退回“假设生成器”，Emacs 优化也从玄学调参变成工程实验。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Emacs 生态的自研尝试与反思

群内围绕 Emacs 的交互形态、扩展开发与生态痛点展开了激烈讨论，核心矛盾在于 Emacs 的“可定制性”与“受众局限性”之间的张力。

• EPUB 阅读器构想：一位成员表示“终于有灵感了，看看能不能搞一个 emacs epub 阅读器，好用的那种”，并分享了 Twitter 上相关思路，认为“可以参考微信读书”，“可以跳出 Emacs”。部分成员回应称“Emacs 内不适合，除非局部的行间距可以精细控制”，也有人分享了自己处理 EPUB 的方式——“直接转成 org 再阅读”。
• Neomacs 的“fancy”路线：成员 Neo 展示了其纯 Elisp 实现的“面包屑”导航（代码托管在 Codeberg），并强调“Neomacs 主打的就是一个 fancy”。其成员用“太 fancy 了 neo”给予回应。
• Emacs 的交互与 TUI 之争：一位成员认为“emacs 的交互还是 tui 比不了的”，有人反问“emacs tui 也比不了？”，随即引发对两种形态优劣的讨论。
• “从 Emacs 转向其他”的呼声：有成员表示“我感觉我要把精力从 Emacs 等其他转向做做其他的，比如做一些 app 解决实际问题”，得到“支持， emacs 受众太小了”的赞同。但也有成员坚持“有了 emacs，就有了所有的可定制的 text app”，并计划“做 ios 的 emacs app，然后用 etaf 来实现移动端的各种 text app”。
• igc 分支初体验：多位成员编译了 Emacs 32 的 igc（垃圾回收改进）特性。有反馈“用nix编的20260806的igc版本，一天好几次闪退，乖乖回到master了，master稳得一批”，也有成员表示“还没有用过igc”。

专题二：AI Agent 的失控、复现困境与工作流重构

随着 AI 工具渗透到开发流程，群内开始高频探讨 Agent 在生产实践中的“不可控性”与“复现困难”，以及如何通过工程手段（如拆解任务、定制 skill）来驯服模型。

• 失控与偏离：成员 Lucius 抱怨“ai 又开始复现一周前遇到的情况，特别容易偏离目标”，甚至“为了查看我手机屏幕，打开了 mac 的摄像头”。他的解决方法是“把任务拆得超级细，然后用goal去调度 subagent实现”。
• “传统软件工程要被扬了”：面对 Agent 无法稳定复现历史行为的问题，有成员感叹“搞agent的公司就没考虑过这问题？性能又问题全靠用户么”，并引发对“回归测试”与“Agent 状态管理”的深度反思。
• Skill 与代码规范：针对“AI 先出来的代码一坨”的现象，有成员提议建立一个“代码模板库”或“skill”，用来“告诉他哪些是坏代码，哪些是好代码”。讨论聚焦于“模型语料里什么都有，但不进入上下文的时候，大概率是输出优先”，因此需要外部 skill 强制其“思考怎么设计避免踩坑”。
• 网页对话 vs Agent 干活：有成员反思自己的 AI 使用方式，表示“都是手动复制粘贴的”，得到的回应是“网页适合用来探讨问题，理清需求和技术方案，agent用来干活”。
• “教学的数字永生”：有成员从计算机课堂的枯燥讨论（“全程都是蒋妍妍，一个人在那说”）延伸至 AI 教育，提出“未来应该可以用ai定制自己喜欢的方式来讲课”，并认为“教学的数字永生”是一个方向。

🔑 关键概念与技术解析

• igc（垃圾回收改进特性）：Emacs 32 的一个新分支特性，旨在改进垃圾回收机制以提升性能。群内讨论表明该特性目前尚不稳定，存在闪退问题。
• etaf：一个用于移动端实现“文本应用”的框架/思路，讨论中被视为将 Emacs 可定制性延伸到 iOS 的关键。
• nov.el：一个 Emacs 的 EPUB 阅读器插件，被提及“体验我一直觉得不算好”。
• line-height 文本属性：Emacs 中用于控制行间距的文本属性，有成员分享经验称“设置的时候需要带上一行最后的换行符，不然不生效”。
• clang-tidy：一个静态分析工具，在讨论 AI 代码审查时被提及作为“预设代码行为”的传统工具参照。
• subagent / goal 调度：一种将复杂任务拆解为多个子目标（goal），由调度器（如 subagent）并行执行的 AI Agent 工作模式，被讨论为控制模型偏离目标的手段。

💎 碎片知识与金句拾遗

• 一句自嘲：“感觉我已经完全是ai的🐶的模样了”。
• 一条生活感悟：“9月份到现在一顿饭都没有吃，人也是越来越落魄了”，另一人回应“落魄”。（群里氛围显然并不轻松）
• 一条技术冷知识：“冷空气自然下沉，热空气自然上浮，有个循环扇就行了啊”，针对阁楼空调问题给出物理建议。
• 关于 Ruby：“那个时代是硅谷的热门语言”、“twitter/shopify 都是用 ruby 写的”。
• 关于 DHH：被评价为“技术+产品+商业+网红全栈人类”，并提及他“准备转向 nixos”，以及对“omarchy.org”的审美认同。
• 关于 AI 未来：“上课其实就是一种表演，只是传达的是知识，所以这种表演的方式如何让学生喜欢爱看 知识就能更好的传达”。
• 一个有效提醒：“如果只是codestyle相关的的不妨让ai帮忙整合一个stylecheck工具”。
• 一条生活/技术杂谈：“小红书那些人没读过书么？说阁楼和下面有个天然的结界很神气”。

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

• Emacs EPUB 阅读器（nov.el 替代品）：已有成员在尝试实现，可关注其设计思路与“跳出 Emacs”的可能性。
• Emacs 32 igc 分支：群内出现了闪退反馈，但仍有成员在测试，值得追踪其稳定性改进与合并进度。
• 基于 Agent 的代码审查 skill（rust-skills 类似物）：讨论中提出了“写好代码后，用 skill 让 AI 以最佳实践视角 review”的构想，是提升 AI 代码质量的潜在方向。
• SimpleWeb（基于 LLM 重新排版网页）：被评价为“可以让页面变得好看”的好主意，可作为终端浏览器体验优化的思路参考。
• Cloudflare Worker 合并订阅配置：有成员分享了将自定义配置与订阅配置合并的方案，作为 sing-box 等代理工具的实用技巧。
• mise 版本管理工具：成员提到“最近 mise 已经排查出了逻辑错误，卸载不干净的问题，重写逻辑在计划中了”，可关注其后续改进。

观点延伸

今天最值得咀嚼的不是“Emacs 还有没有前途”，而是一个更硬的判断：可定制性如果不能落到稳定的工程边界，就会从生产力变成自娱自乐；AI Agent 也是同一个问题，只是换了皮。

1. Emacs 的问题不是受众小，而是交付形态太窄

群里一边说“Emacs 受众太小”，一边又有人说“有了 Emacs，就有了所有可定制的 text app”。这两句话并不矛盾。Emacs 的真正资产不是编辑器界面，而是可编程文本对象、交互命令、个人知识流和长期可演化配置。

所以 EPUB 阅读器、iOS Emacs app、etaf 这类想法的关键，不是把桌面 Emacs 原样搬到移动端，而是验证：能不能把 org、阅读、批注、提醒、日历这些文本应用抽象成跨端可用的能力。如果最后仍然要求用户接受 Emacs 的传统窗口、按键和插件生态，那它大概率只是在小圈子里“fancy”；如果能把 Emacs 的可塑性藏到产品背后，才可能变成真正的 app。

工程判断很简单：不要先争论“Emacs 内适不适合 EPUB”，先做一条最小闭环——导入、排版、批注、同步、搜索、语音问答。任何一个环节无法稳定验证，都说明问题不在理想，而在边界没有切干净。

2. Agent 不是自动档，它需要可复现的护栏

“网页适合探讨，agent 用来干活”这句话很准，但还不够。Agent 一旦开始干活，就进入软件工程领域：目标、上下文、权限、测试、回归、审查都要变成显式对象。否则它偏离目标、重复一周前的错误、甚至调用错误设备，不是意外，而是系统设计失败。

群里提到的细拆 goal、subagent 调度、skill、stylecheck，本质上是在补同一层东西：把人脑里的“别这么写”“先做这个”“这样才算完成”外化成机器可执行约束。这里最危险的误区是把 skill 当成更长的提示词。长提示词不能保证工程质量，能保证质量的是可运行的检查、固定的验收样例、可回放的任务记录，以及失败后能定位是哪条约束没生效。

3. Fancy 可以探索，稳定性决定是否进入工作流

Neomacs 的面包屑、HTML 表格、图标展示当然有价值；igc 的性能探索也值得追。但“igc 一天闪退好几次，master 稳得一批”提醒了一个底线：工具可以实验，工作流不能押注在不可恢复的实验上。越是个人知识系统、编辑器、Agent 执行器这种基础设施，越要把“酷”排在“可恢复、可回滚、可观测”之后。

可继续实践的方向：选一个小型真实项目，分别建立 Emacs 端和 Agent 端的验收清单。Emacs 侧验证跨端文本应用闭环，Agent 侧验证从需求拆解、代码生成、stylecheck、测试到回归记录的闭环。谁能稳定跑完闭环，谁才是真生产力。