News Hacker｜极客洞察

🎯 讨论背景

这篇帖子的作者是 Emacs 圈里很有名的 nullprogram 博客作者，也写过 Elfeed（一个在 Emacs 里使用的 RSS 阅读器）。他在一篇博客里说自己正式不再把 Emacs 当主力环境，Linux 上改用 KDE on Wayland（KDE 桌面环境运行在 Wayland 图形协议上），更少依赖终端工具，也不再维护 Mutt（终端邮件客户端）和自建 mail server（邮件服务器）；他把这和自己拥抱 LLM/AI、改变工作方式联系在一起。评论区因此一边讨论 Emacs 在 LLM 时代是否反而更强，另一边争论 AI 编程到底是生产力杠杆还是 vibe coding（靠 LLM 快速拼接、人工打磨较少的写法）带来的质量下降。因为他还推出了 Elfeed2（一个基于 wxWidgets 的 GUI 替代版），话题又延伸到 GUI toolkit、Git UI（magit）替代品以及 Vim/Emacs 的老问题。

📌 讨论焦点

LLM 让 Emacs 更像可编程控制台

不少人不同意“离开 Emacs 才能拥抱 AI”的隐含前提，反而认为 LLM 时代让 Emacs 更像一个活的 Lisp REPL 加编辑器。有人描述把模型放进 Emacs 后，可以在同一个 session 里试代码、看结果，让 agent 直接操控当前实例，甚至用 emacsclient、magit ediff、Tetris 来做测试。常被提到的工具是 gptel 和 ECA：前者适合随时在任何 buffer 里发起提问，后者更适合 coding assistant。评论里反复强调，Emacs 的强项不是单纯编辑文本，而是把浏览器、终端、Slack、Jira 等来源的纯文本吸进一个可编程工作区。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

LLM 控制 Emacs 的安全边界

有人对把 LLM 接到 Emacs 里表达了明显担忧，因为 Emacs 本身可以执行任意代码，若让模型直接操控编辑器，就等于把全系统权限交给它。回应者认为这并不比终端或 Claude Code 更危险，因为这些工具本来就要访问本地文件和 shell，只是需要更谨慎的命令确认与本地沙箱。争论的核心不是模型能不能动手，而是人类愿意把多少执行权交给它。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

放弃重度定制是为了减少摩擦

支持这次转身的人把重点放在摩擦和维护上，而不是工具忠诚度。作者从 Openbox、Tridactyl、Xorg、xterm 之类的重度定制，转到 KDE on Wayland 和更轻的浏览器配置，同时也不再自己跑 Mutt 和 mail server。评论认为，power-user 配置一旦要在不同机器间迁移，就会变成记忆负担和重装成本；有些人甚至因为共享 Windows 机器或公司机器而被迫放弃原本的输入法、键位和编辑器习惯。也有人拿 NixOS 当例子，说 declarative config 能缓解换机器就重来，但 Tridactyl 的 iframe 和复杂网站限制仍然说明这类方案并不总是无摩擦。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]

LLM 编程=不可逆的生产力杠杆

另一派把这次退休看成软件工作方式已经不可逆变化的证据。有人直接说，LLM 不是替代人的判断，而是像一个不太可靠的 junior developer：人负责审查、引导、验证，机器负责铺代码和试错。也有人强调，强开发者加 AI 的组合，能在相同时间里做出远超以前的产出；拒绝工具只是把杠杆让给别人。讨论里还把这种模式写成 chef 指挥助手而不是手工敲每一行，并进一步区分 programming 和 engineering，认为 AI 主要改变的是写代码环节，需求定义和系统分析仍然靠人。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

反对 AI 神话与 vibe coding

反对者认为，把 AI 时代直接等同于软件工程的未来过于夸张。有人指出，真正被消耗的是软件质量：公司在修补 vibe coding 带来的回归、逻辑混乱和不稳定行为，而不是创造更好的工程实践。还有人批评 LLM 不能自我改进，答案常常不简洁，甚至会随着反复迭代而腐烂，所以把它当成通用工程能力并不靠谱。评论里也反复出现对 AI psychosis 这种说法的纠偏：真正的问题不是精神病学，而是把聊天机器人包装成能替代工程判断的幻想。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]

Elfeed、Magit 与替代工具

因为作者还是 Elfeed（一个在 Emacs 里使用的 RSS 阅读器）的开发者，评论里自然担心原版 Elfeed 的维护前景。有人试用他新做的 Elfeed2，发现它还不如原版：不少 feed 读不出来，功能也没到位。讨论进一步扩展到 magit（Emacs 里的 Git UI）的 editor-independent 替代品，像 Lazygit、Stage、gitu 和 jjui 都被提到，但普遍评价是还很难达到 Magit 的 UI 水平。顺带也有人问为什么选 wxWidgets 而不是 Qt，并指出老 wxWidgets 应用常见的 DPI scaling 问题。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]

Vim 与 Emacs 的老争论

一些人从自身切换经历出发，认为 Emacs 和 Vim 并没有绝对胜负。Vim 在 cursor movement、overlays 和局部编辑上更快更直观，而 Emacs 在单一模式下做整套写作和编码流程时更顺手。也有人把两者解释成不同哲学：Vim 的 modal navigation 很容易迁移到 browser、terminal 和 WM，Emacs 则是围绕 Lisp 和可编程环境建立的另一种体系。Spacemacs 和 Evil 被视为给新手的桥梁，但资深用户觉得它们更多是配置 recipe，而不是全新编辑器。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

📚 术语解释

Emacs Lisp: Emacs 的扩展语言，用来把编辑器深度定制成可编程环境。

REPL: Read-Eval-Print Loop，允许在运行中的环境里输入代码并立即观察结果。

gptel: 一个把 LLM 交互嵌入 Emacs buffer 的扩展，可随时发起提问。

Magit: Emacs 里的 Git 界面，以高效键盘操作和细粒度控制著称。

Tridactyl: Firefox 的 Vim 风格扩展，让浏览器也能用键盘驱动。

wxWidgets: 跨平台 C++ GUI toolkit，常用于构建桌面应用。

Wayland: Linux 的现代图形显示协议，用来替代 Xorg。