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

Emacs 社区日报 2026-10-10 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：AI 写代码的「古法派」与「vibe 派」之争

本次讨论最大焦点，是围绕「AI 辅助编程」的两种截然对立的态度，形成了两条清晰的阵营线：

vibe 派（完全信任 AI 主导编码） 主张让 AI 直接写代码，人类只负责提需求、审结果。有群友分享经验：

• “我纯 vibe 的交易系统都上线跑半年了，赚了”
• 对 AI 工作流的核心技巧是：“不要用问答模式，用工作模式，要求测试，自己会解决”
• “把项目文档直接丢给 AI，Claude 只需要自己读原型和需求文档，结合测试库只读权限、代码阅读，就可以很好完成”
• Claude 返工少，但 codex 会“自作主张做一些需求没要求的东西”

古法派（坚持手写或让 AI 只做辅助） 则列举了大量反面体验：

• “AI 写的代码太屎，不配进入我的代码库”
• “代码就是拉胯，哪怕有规范写的也不行”
• “AI 很容易改一个地方，其他地方出问题，它不知道，我也不知道，然后要再发现这个问题的过程很不确定”
• “人知道改的地方可能会有哪些问题”

痛点共识：AI 改代码时缺乏全局因果意识，容易引入隐藏 bug；代码库一旦交给 AI 维护，后续修复也依赖 AI，形成“AI 依赖循环”。但部分群友指出，这更多是 “差距在人，不在工具”——有人 vibe 交易亏 50%，有人对冲套利赚了。

专题二：Emacs 编译与环境管理难题

群内多位自编译 Emacs 用户反馈了同一个典型痛点：

“工作机 linux+master，时不时更新系统会升级某个 so，导致 emacs 启动不起来，要重新 make && sudo make install”

社区给出的解决方案逐渐收敛：

• 用 nix（nix shell、nix-darwin、社区维护的 Emacs flake）来隔离依赖
• 全静态链接（寻找 .a 静态包）或者放入固定环境容器
• AppImage 打包，每个应用自带 lib，解决 DLL hell
• 用包管理器管理 Emacs，而非手动 make install（因为老版本文件可能不会被清理）
• 有人点出“重新 make 再安装是正常流程”，群友已自适应

核心洞察：Emacs 追新版本，用官方脚本或 nix flake 最省事，手动编译易陷入依赖地狱。

专题三：ETAF / legmacs 框架的发布与后续规划

群主发布了新的 Emacs 框架（ETAF，基于 llm 参与），并在 Reddit 上引发关注，日本用户开始试用。讨论重点：

• 框架性能要求不高，走“直接操作 buffer 的增量更新”
• 先完善文档发布 ETAF 版本，后续计划做游戏框架
• 有人想做“贪吃蛇在 Emacs buffer 里跑，边走边吃 buffer 里的字符”的趣味项目
• 有人质疑 ETAF 是否可用在 eww（Emacs Web Wowser）上，因为 shrface 有问题，但 ETAF 有 llm 参与

🔑 关键概念与技术解析

ETAF（emacs-taf）：一个由群主开发的新 Emacs 框架，有 LLM 参与，底层基于“古法时代”写的代码和思路，采用直接操作 buffer 的增量更新方式，对性能要求低。目前文档完善中，可关注 https://forgejo.vhkd.top/emacs-taf 。

legmacs：群内分享的另一 Emacs 项目（https://github.com/nooga/legmacs），与 ETAF 可能相关或并列，未展开细节。

vibe coding：一种完全依赖 AI 生成代码的开发方式，人类只提供需求并审阅结果。群内有人用此方式开发并上线了交易系统。

ring buffer HFT 系统：基于环形缓冲区的超高频交易系统，被群友用 vibe coding 方式开发中。

gptel rewrite：Emacs 中调用 LLM 重写文本的功能，群友用它修复格式混乱的表格。

nix flake / nix-darwin：用 Nix 包管理器声明式管理 Emacs 构建和环境，避免系统升级导致 so 不兼容的问题。

💎 碎片知识与金句拾遗

• “这框架对性能要求高吗？”“不高，走的直接操作 buffer 的增量更新” —— ETAF 的架构特点。
• “AI 写代码大概等于半个高级加一堆初级” —— 对 AI 编码能力的精准概括。
• “读 AI 的输出是最痛苦的。而且不手写代码后很多细节还要专门开 session 去梳理。”
• “手写效率先降 100 倍”—— 对 vibe coding 效率的肯定。
• “我觉得工作就是需要确定的东西，只要什么都确定，就可以越干越轻松。”
• “Claude 完全不懂 emacs 呢，让它帮我化简配置，做出来一坨，正确性都不对”—— 对比之下，“gemini 很懂”。
• “一口气帮我删除了 500 行代码”“真抱歉我删掉了 XX 代码导致你的 Emacs 无法启动”—— 对 AI 改配置事故的幽默吐槽。
• “只要你装在 /usr/local 里的话就不会和包管理器起冲突”—— 手动编译 Emacs 的实操经验。
• “像 Windows 一样每个应用自带 lib 才能根治问题”—— 对 DLL hell 的调侃。
• “日本人玩 Emacs 真厉害，common lisp 的那个 lem 好像也是日本人搞的”—— 日本 Emacs 社区生态观察。
• “他住在 Cyprus 的山里。。”—— 关于知名 Emacs 主播 prot 的八卦。
• “现在谁还古法”“坏了，我还在古法”—— 对自身开发方式的自我调侃。
• “我用 deepseek flash 都没出过问题”“我下次用最便宜豆包看看”—— 平价 LLM 的使用经验。
• “人写代码也不可能无误啊”“那肯定说的是这种情况啊，烂模型接到 agent 里也不会出这种错”—— 对 AI 代码质量的辩证讨论。

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

• ETAF 框架的后续规划：文档完善后的版本发布，以及基于它的游戏框架（如 buffer 贪吃蛇）——值得持续跟进。
• AI 工作模式 vs 问答模式：群友强调“不要用问答模式，用工作模式，要求测试，自己会解决”——这是一种高效的 AI 协作范式，值得整理成方法论。
• nix 管理 Emacs 构建：社区维护的 Emacs flake 方案，以及 nix-darwin 在 macOS 上的应用——适合长期自编译用户采纳。
• 对冲套利策略与 vibe coding 结合：有群友用 AI 开发交易系统并盈利，虽有争议，但其策略和工程实践值得研究。
• prot 的直播内容：提及他讨论“China, China, China”，并住在 Cyprus 山里——可能有关于 Emacs 社区或 AI 的深度观点，可进一步观看视频了解。

观点延伸

当天最值得咀嚼的，不是“Claude、Codex 还是 Gemini 更强”，而是一个更硬的判断：AI 编程真正改变的，不是写代码的速度，而是软件工程中“谁负责维持确定性”。

1. Vibe coding 的分水岭，不是模型能力，而是系统能否把不确定性关在笼子里

群里有人说，纯 vibe 的交易系统已经运行半年并且盈利；也有人说 AI 代码“不配进入代码库”，甚至会删掉配置、workaround，导致 Emacs 无法启动。这两类经验并不矛盾。前者依赖清晰的业务边界、可验证的策略结果和持续运行反馈；后者面对的是隐含依赖密集、局部修改容易破坏全局状态的系统。

因此，“AI 写得好不好”不是第一问题。更关键的是：需求是否可验收，测试是否覆盖关键行为，修改是否可回滚，运行环境是否能自动验证。没有这些约束，模型越主动，破坏面越大；有了这些约束，模型才可能从聊天对象变成执行者。所谓“工作模式”并不是一句提示词，而是一套工程闭环：读上下文、提出计划、实施变更、运行测试、检查差异、失败回退。

2. “人知道可能影响哪里”其实是一种尚未被显式化的领域模型

古法派担心 AI 改一个地方、却在另一个地方制造问题。这个判断的核心不是人类永远比模型可靠，而是老手脑中拥有大量未写进文档的约束：某个 workaround 为什么存在，某个配置不能删，某个接口虽然丑却被其他模块依赖。

这也解释了为什么 AI 读项目文档、原型和测试库后表现会明显变好：文档正在把人的隐性判断转化为机器可消费的上下文。未来最有价值的“AI-ready codebase”，未必是代码最漂亮，而是决策理由、边界条件、不可破坏的行为都被留下来。否则 AI 不是在维护系统，只是在反复猜测系统。

3. Emacs 的环境问题和 AI 的代码问题，本质上是同一种工程债务

手动编译 Emacs 后，系统升级某个动态库就要重新 make && sudo make install；AI 改配置后，删掉旧 workaround 才发现启动失败。两者都说明：系统依赖没有被声明，变化也没有被隔离。Nix、容器、AppImage 解决的是运行环境的可重复性；版本控制、最小变更、启动测试解决的是修改过程的可逆性。它们不是“折腾工具”，而是在给确定性建立边界。

可继续研究的方向是：为 Emacs 配置和 AI coding agent 建立同一套最小安全工作流——每次修改前自动保存快照，要求 agent 先解释将影响的包和入口，修改后在干净环境启动 Emacs、跑字节编译和核心测试，再由人审查 diff。这样才能验证一个具体问题：AI 到底是在提高生产力，还是只是把调试成本推迟到更晚、更难发现的地方。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：“Geekinney 宇宙” —— 基于 Agent 的 Emacs 应用生态构建

凌晨时分，群内围绕 ETAF（Emacs TAF?） 生态展开了热烈的讨论。这并非一个简单插件，而是一个由 AI Agent（如 dsh）驱动的、围绕 Emacs 构建的应用宇宙，涵盖 Telegram (telega)、网易云音乐 (etaf-ncm)、RSS 阅读器 (etaf-rss)、视频播放器 等。创始人Law𝕏ence𝕏分享了代码仓库（forgejo.vhkd.top/emacs-taf），并演示了如何用自然语言让 Agent 直接修改配置、修复 bug。

• 核心观点：群友普遍认为这是比 EAF 更“魔幻”的架构，因为它将 AI 编程能力深度嵌入到 Emacs 配置与插件开发流中。用户不再需要手动排查依赖或写配置，而是直接“让 agent 搞”。
• 痛点与讨论：出现了 emacs-rime 输入法无法激活的 bug 报告；对 etaf-rss 是否可复用 elfeed feed 的疑问（答复：独立 app，不推荐跨 app 共享配置）；以及 ebook-parse-cli 工具发布后立刻被群友安装使用的场景。
• 生态扩展：从 etaf-telega 到 pi-hub（技能库）再到 ebook-parse-cli，显示出围绕个人工作流的“AI 辅助工具链”正在快速膨胀，形成“Geekinney 宇宙大爆炸”之势。

专题二：Windows 环境下 Emacs 配置的“地狱”排查

从凌晨 00:29 到下午 14:47，多位群友深陷 Windows 上 Emacs 配置无法启动、找不到包的泥潭。这不仅仅是简单的环境变量问题，而是涉及到 Windows 权限模型、HOME 环境变量与 Emacs 默认路径的冲突、msys2 工具链的干扰 等深层次问题。

• 关键转折点：群友zdn_q发现核心矛盾在于 Emacs 在 Windows 上默认将 ~ 解析为 appdata 目录，而手动设置 HOME 环境变量又会导致其他软件异常。最终诊断方向转向 文件权限（takeown / icacls）以及 不同发行版构建的差异。
• 衍生讨论：由此引发了对 Windows 小文件 IO 性能的吐槽（删除 node_modules 慢、写小文件慢），以及对微软“被三哥占领”的调侃。
• 解决方案尝试：群友建议用 visual-fill-column-mode 解决排版问题，但核心的启动问题似乎最终未能统一解决，有人建议“让 AI 帮你解决”，也有人感叹 Windows 上启动 10 秒 vs Linux 1 秒的巨大差距。

专题三：键盘交互设计的理念交锋 —— 下意识 vs 视觉定位

在讨论 Telega 界面优化时，爆发了一场关于键盘交互哲学的小型辩论。有人提议将界面做成类似浏览器插件（vimium）的模式，按 f 键显示所有可聚焦元素标签进行跳转。但这一方案遭到反对：

• 反对观点：avy 这类“先看位置再跳转”的交互“很费眼睛”，因为视觉定位不是下意识行为。真正高效的是 n、p 这种固定语义的快捷键，可以让手指形成肌肉记忆，无需看屏幕。
• 支持观点：现有 tab 切换、Workspace 切换都需要“看”，而全键盘操作与布局无关，关键在于提供固定的快捷键。
• 最终共识：Emacs 的 UX 设计应坚持键盘优先，类似浏览器插件的交互虽直观但不符合 Emacs 哲学，更像是一种“GUI 思维的妥协”。

🔑 关键概念与技术解析

• ETAF / Geekinney 宇宙：一个基于 Forgejo 托管、由 AI Agent（dsh）驱动的 Emacs 应用生态集合，旨在为 Emacs 提供现代 GUI 应用（如 Telegram、网易云音乐）的完整替代方案。
• dsh：群友zdn_y使用的命令行 AI 辅助工具，用于自动生成配置、修复代码，被视作“Geekinney 宇宙”的引擎。
• magit-fast：一个对 magit 的 hack 优化方案，通过加速 git 进程调用提升性能，有群友实测提升约 20%（4 秒 -> 3 秒），但存在中文路径/文件名显示乱码的问题。
• strata-mlx：参考 strata 设计、面向 macOS 的优化版本，据称性能提升最高接近 3 倍。这暗示着一种通过特定配置或原生代码实现加速的通用思路。
• omdrop-owl：群内分享的一个 GitHub 项目（https://github.com/t4t5/omdrop-owl），虽然未被详细解释，但从分享语气推测是一个值得关注的工具/项目。

💎 碎片知识与金句拾遗

• 关于配置路径：“Windows 上理论上是没有 home 环境的，配置了会导致很多软件不正常。但很多 package 写的是 ~/，所以最好在 Emacs 加载插件前设置 HOME 变量。”
• 关于 AI 编程体验：“review ai 的代码搞麻了。动不动就搞大动作，别的库没实现的直接 vendor 了改。他奶奶的，不让我加。” —— 生动描述了 AI 编程时“粗鲁”的代码行为习惯。
• 关于 Emacs 启动速度：“以前裸配置启动都要快 1s，emacs32 效率提升非常大。” 以及 “开机第一次启动 Emacs 我甚至要 40 秒，正常用 Emacs”。
• 关于 Stallman 的装备：“斯托曼当时是一个很小屏的 thinkpad 电脑，现在十五英寸的，感觉够呛。” 并有人补充了 Stallman 用背带挂笔记本写代码的著名场景。
• 关于 Windows 的 IO 性能：“1gb 的 10000 个小文件 vs 1gb 的 1 个大文件，前者比后者花的时间是几倍。典型的是删除 node_modules 目录速度特别慢甚至删不动。”
• 关于 Windows 的 Home 目录：“emacs 在 windows 上的默认配置目录是 appdata，不是 userprofile。你用 userprofile 会导致找不到包。”
• 关于 Windows 权限：“因为 Windows 的权限不是金字塔模型，不是管理员就可以访问用户文件夹的，得权限里面有管理员这个账号才行。”
• 关于 Fedora 群：“群主看样子不够勤奋，相比而言，咱 Emacs 群，简直是模范生。”

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

1. ETAF / Geekinney 宇宙：这是当前最具潜力的方向。它代表了“AI 原生 Emacs 配置”的实践，通过 Agent 驱动插件开发与维护，极大降低了用户上手门槛。值得跟进其架构设计（如 dsh 的工作方式、etaf-telega 的实现细节）以及如何扩展到更多应用。
2. strata-mlx：参考 strata 设计，面向 macOS 的性能优化方案，性能提升显著。值得研究其核心优化手段（是否涉及原生代码或配置重组），并对比其在 Linux 上的适用性。
3. magit-fast 中文乱码问题：这是一个典型的本土化 bug，可能源于 git 进程的编码处理。对于中文用户而言，解决此问题比单纯提升性能更有价值，值得探索其根因。
4. Windows Emacs 启动性能优化：群友提到 Linux 启动 1 秒 vs Windows 10 秒的巨大差距，说明 Windows 环境下存在严重的 IO 或配置加载瓶颈。结合 straight.el 或 emacs-flake 等现代配置管理方案，或许能找到更优的解决方案。

观点延伸

当天最值得咀嚼的，不是“AI 能不能替你写 Emacs 配置”，而是：当 Agent 开始成为配置、插件和个人工作流的共同维护者时，Emacs 的核心竞争力会从“可扩展”进一步转向“可被持续改造”。但这也意味着，真正稀缺的能力不再是让 Agent 动手，而是知道哪些边界不能让它随便动。

1. AI 原生生态的瓶颈不是生成，而是约束

ETAF 生态、技能库和命令行工具的快速增加，说明自然语言已经足以把一个想法迅速变成可用功能；群里“直接让 Agent 搞”的轻松感，正来自这种低摩擦。但 Rime 适配、独立应用是否共享配置、AI 擅自 vendor 外部库等讨论，也暴露出同一问题：Agent 很擅长扩大改动面，却不天然理解项目边界。

因此，AI 原生 Emacs 不应只是“让 Agent 修改更多代码”，而应建立更严格的变更协议：默认小补丁、明确允许修改的文件、保留原有抽象、先写复现再修复，并要求每次改动给出可回滚的 diff。否则生态越大，维护成本越会从手写配置转移成审查 Agent 行为。能否让 Agent 在一个稳定的架构约束内持续迭代，才是这类“个人应用宇宙”能否长期存在的判断标准。

2. 键盘优先不是拒绝 GUI，而是拒绝不可预测的注意力成本

关于 Vimium 式定位和 n、p 固定快捷键的争论，本质不是哪种交互更“现代”，而是哪种交互更少打断认知。需要先看屏幕、识别标签、再输入目标的操作，把视觉搜索成本转嫁给用户；固定语义键则把界面结构隐藏起来，让操作依赖状态和习惯。这也是堆叠式 Buffer 切换长期适合 Emacs 的原因。

但这不代表 ETAF 应拒绝 GUI 布局。更好的方向可能是：布局可以像 GUI，焦点移动必须像 Emacs；用 TAB 在语义区域间移动，用固定键执行列表、消息、播放器等领域动作，只有在无法预先编码的对象上才使用定位跳转。判断交互优劣的指标，不是功能是否“全键盘”，而是用户能否在不重新寻找界面的情况下连续完成十次操作。

可继续研究/实践

为 ETAF 设计一套最小交互规范：每个 App 定义语义焦点、固定动作、可发现的帮助入口和 Agent 修改边界；再用同一组任务比较“定位跳转”和“固定快捷键”的完成时间、错误率与视线次数。这样才能把“符合 Emacs 哲学”从偏好争论变成可验证的工程结论。