Geekinney

外观

Emacs 社区日报 2026-07-21

约 6266 字大约 21 分钟

2026-07-21

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

Emacs 中文讨论组

好的，这是根据您提供的群聊记录生成的结构化知识库。

🎯 核心热点与专题探讨

专题：编辑器环境的边界与操作系统哲学的冲突

本次讨论的核心围绕两个看似独立但内核相通的主题展开：Lem编辑器的跨平台进展与特性，以及一场关于 macOS vs Linux桌面环境/窗口管理器设计哲学 的激烈争论。前者展现了编辑器试图突破自身边界、拥抱AI和跨平台的能力；后者则暴露了不同用户群体对“高效”理解的深刻分歧。

  1. Lem编辑器的新动向

    • 跨平台支持：Lem的开发者近期因主要使用Windows，开始提供原生Windows支持（PR #2261）。群友评价为“作者最近一段时间都会用windows，所以有支持的”。
    • AI辅助开发：群友以Lem的Tramp功能为例，分享了利用AI（DeepSeek）编写代码的经验。他认为AI生成的代码虽然“差一点意思”，但经过与AI的“博弈”和“人肉把关”后，可以接受，并调侃“ai用得太好就看不懂pr”。
    • 固有Bug：发现了Lem的一个小bug（捕捉长按的Super键），但认为“没任何影响使用”。
    • 自带Vim模式：与Emacs自带的viper类似，Lem也内置了vi mode。

  2. 操作系统桌面环境的“圣战”：macOS vs Linux窗口管理器

    • 焦点：窗口与应用的归属关系 (App First-class vs WM First-class)
      • macOS立场：一位用户强调，macOS的核心体验是“app是第一公民”，即所有窗口自动属于其父App，系统能天然区分不同App的窗口。他们认为这种设计认知负担小，切换简单（CMD+Tab/CMD+~）。
      • Linux立场：多位Linux用户认为，Linux（尤其是Hyprland、niri等现代WM）通过配置文件、CLI接口和脚本，可以实现比macOS更强大、更灵活的窗口管理。他们指出“run-or-raise”等行为完全可以通过配置实现，并反驳“App归属关系”的论点，认为Linux下通过app_id、WM_CLASS等机制足以做到精确区分。
    • 痛点与解决方案
      • macOS的痛点：macOS的Workspace设计被认为“根本不适合多workspace使用”，因为点击dock上的App时，其行为（切换工作区 vs 拉取窗口）不可预测。有用户选择在macOS上使用堆叠而非平铺方式。
      • Linux的痛点：难以完美还原macOS的“App切换体验”，因为需要维护“启发式映射和应用生命周期模型”，做不到“天然归属”。此外，KDE被认为“四不像”、“丑”，而美化又是一件费力的事。
    • 共识：习惯与工具之争：最终，讨论回归到个人习惯。一方喜欢“所有app全屏，堆在一起”，认为多Workspace分散注意力；另一方则钟爱“每个Workspace一个app”，享受纯键盘的肌肉记忆。最终，一位用户引用“Worse is better”原则，建议选择结构简单而非功能完善的DE/WM，并推荐了labwc（基于XML配置的干净堆叠式WM）和lxqt/xfce搭配labwc的组合。

专题：Emacs生态包的迭代与选择

  • package-vc vs straight.el：讨论了从package.el + use-package迁移到straight.el的必要性。结论是：如果:vc关键字已能满足需求（如从Git仓库安装），迁移意义不大。package-vc默认拉取的是标记的release而非最新提交，需要通过:rev :newest参数锁定最新版。
  • Hel.el编辑器/模式：一位用户从Vim转向Emacs，并分享了使用hel.el的感受。“Emacs的启动速度少了2秒”，但对其附属的hel-scroll.el（添加滚动动画）评价为“挺傻逼的，脱裤子放屁地加入了动画效果...多花0.5秒看这个动画”。
  • material-icon.el与ghostel：material-icon.el收到了更新。群友关注的ghostel上游（一个Emacs的Telegram客户端telega.el）的Tramp bug得到了解决，并且telega.el新增了批量处理群组申请的功能。

🔑 关键概念与技术解析

  • Tramp (Transparent Remote Access, Multiple Protocols)：一个Emacs的核心功能，允许透明地编辑远程文件（如通过SSH、sudo等）。本次讨论中，Lem编辑器开始“通过AI vibed一个初版Tramp”，支持sudo和ssh，目标是接近Emacs的体验。
  • Run-or-Raise：窗口管理的一种行为模式。当快捷键被按下时，如果目标应用已经在运行，则将其窗口提升到前台；如果未运行，则启动它。这是终端用户追求的经典体验，被描述为“hyprland 里面按 win+c 应该是跳到 kitty 窗口，而不是新建一个 kitty 窗口”。
  • App First-class vs WM First-class：这是关于操作系统窗口管理哲学的一个深刻争论点。前者（以macOS为代表）强调操作系统层面天然理解并区分App与其窗口的归属关系，用户交互围绕App展开。后者（许多Linux WM）则从窗口管理器的角度出发，通过脚本和配置实现对窗口的精确控制，App的归属关系需要通过额外的元数据（如app_id）来建立。
  • labwc：一个基于Wayland的轻量级堆叠式窗口管理器。其配置文件为XML格式，被群友称赞为“这个桌面很乾淨”、“配置文件完全透明，换系统方便”。它常被用来作为构建完整桌面环境（如lxqt+labwc, xfce+labwc, noctalia+labwc）的基础组件。
  • SDl2/SDL3：Simple DirectMedia Layer。一个跨平台的多媒体库，常用于游戏和图形应用的开发。在Lem编辑器讨论的上下文中，它指的是前端（界面渲染）实现的可能性。

💎 碎片知识与金句拾遗

  • 关于AI辅助开发的深刻洞察：
    • “感觉用ai没必要用那么好的，就像电脑性能太好就发现不了性能问题，ai用得太好就看不懂pr。” —— 对AI“代笔”导致开发者失去对代码理解的风险的精妙比喻。
    • “自动化测试代码信息熵低，ai学不到什么东西。” —— 直指AI在自动化测试领域的局限性。
    • “光写测试不行...我之前vibe的代码 能跑测试 一review代码 屎的不行，尤其是c++方面的代码。” —— 量化了AI生成代码的“看起来能跑”与“代码质量”之间的巨大鸿沟。
  • 关于编辑器与操作系统关系的感慨：“现代环境下最大的问题是逃离不了浏览器。大大降低了它（Emacs）作为一个统一集成环境的优势。”
  • 关于桌面环境的“圣战”总结：“linux的各种 wm 能把 window 和 workspace 玩出花，macOS一个平铺都要装第三方软件吧。” vs “我不能因为苹果就放弃掉我的GNOME使用习惯” vs “我不能因为Linux放弃我app是第一公民的习惯”
  • 一个冷门的备忘录：ghostel 是 Emacs 的 Telegram 客户端 telega.el 的一个第三方配置项目。其 Issue #531 讨论了上游的Tramp bug。telega.el 的PR #582 合入了，管理员现在可以批量处理手动批准入群的申请。
  • 一个有趣的即兴笑话：有人提到“俄罗斯妹子真漂亮”，然后很快被纠正和忽略。有人发现macOS Phone的返回手势是“app自己实现，体验很不一致...自带app也是（beta）”，引发对苹果产品的调侃：“（iPhone的返回）不敢想象手有多难受”。
  • 关于Emacs配置的讨论：一位用户提到 “Emacs我就感觉...现代环境下最大的问题是逃离不了浏览器...大大降低了它作为一个统一集成环境的优势”。

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

  • Lem编辑器：这个用Common Lisp编写的编辑器正在快速迭代。特别是其通过AI“vibe”初版Tramp功能的做法，以及作者对Windows平台的重视，使其成为一个观察“非主流语言+AI辅助开发+跨平台编辑器”实验的绝佳样本。
  • niri + noctalia：niri（滚动式平铺WM）+ noctalia（基于Tauri的桌面环境）的组合被多次提及，被认为适合笔记本。可以关注这个新兴的、试图提供“开箱即用”体验的Wayland桌面环境组合。
  • labwc作为构建基块：labwc + xfce或lxqt的搭配方式，为用户提供了一种“自己组装”干净、简洁、配置可移植的桌面环境的可能性。其XML配置虽然引入了一些复杂性，但也带来了透明度。可以深入研究其配置文件的颗粒度和社区支持。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“macOS 好还是 Linux 好”，也不是“AI 能不能写 Tramp”，而是同一个工程问题的两种变体：你到底相信“平台替你维护语义”，还是相信“可组合工具让你自己重建语义”。

1. “App 是第一公民”不是审美问题，是状态模型问题

macOS 用户说的“app 是第一公民”，核心不是窗口能不能重叠，也不是 CMD+Tab/CMD+~ 多顺手，而是系统替用户维护了一层稳定的应用语义：窗口属于哪个 App、切换 App 后如何循环窗口、Dock 点击该拉起还是切换。这层模型一旦工作，用户就不用在脑中维护 workspace、窗口 ID、启动状态、焦点历史。

Linux WM 用户反驳“Hyprland/niri 可以通过 app_id、WM_CLASS、CLI、脚本实现 run-or-raise”，也成立。但这里的差别不是能力，而是责任边界。macOS 把一部分复杂性封进平台；Linux 把复杂性暴露成可编程接口。前者牺牲可解释性和可定制性，换默认一致；后者牺牲开箱语义，换可验证、可迁移、可审查。

工程判断很简单：如果你的窗口管理需求能写成配置、脚本和状态查询，Linux WM 往往更强；如果你的需求依赖“所有应用自然遵守同一套生命周期语义”，macOS 的封闭平台反而更稳。

2. AI Agent 会放大 Linux 这类系统的优势，也会放大它的坑

群里一句“Linux 定制现在也不是问题了，Agent 可以干活”，其实很关键。过去 Linux 桌面的问题是：可配置性太强，但配置成本由人承担。现在 Agent 能读 wiki、改配置、写 run-or-raise 脚本、生成 NixOS/Guix 声明式配置，复杂性开始被外包。

但这不等于“折腾成本消失”。Agent 最擅长处理显式文本系统：配置文件、CLI 输出、日志、可回滚声明。它最怕的是隐式状态：XFCE 那种通知、窗口位置、运行时状态混进 XML；或者某个 DE/WM 的行为靠约定、插件和隐藏数据库拼起来。于是“实现结构简单”不再只是极客洁癖，而是 Agent 可维护性的前提。

未来适合 Agent 管理的桌面，不一定是功能最多的桌面，而是状态最透明、接口最稳定、配置最可 diff 的桌面。

3. AI 写代码的风险不在测试不过，而在你失去代码所有权

Lem Tramp 初版“vibe 出来”、能支持 sudo/ssh，看起来很爽；但群里马上有人指出“能跑测试，一 review 代码屎的不行”。这比“AI 会不会取代程序员”更具体：AI 生成代码的最低验收线不是测试绿，而是维护者能否解释设计、边界和失败模式。

“AI 用得太好就看不懂 PR”这句话很准。模型越强，越容易生成一坨表面完整、局部合理、整体难审的代码。尤其是 Tramp、窗口管理、C++ 这类和外部系统强耦合的领域，自动化测试覆盖不了真实用户路径，用户侧测试和人工 review 仍是最后防线。

可继续实践的方向：拿 labwc / niri / Hyprland 的 run-or-raise 当样本，做一套“Agent 友好桌面配置”实验：所有窗口规则、快捷键、启动状态查询、回滚方式都声明式化；再让 AI 修改配置并生成变更说明。能不能长期稳定，比争论 macOS/Linux 谁更高级更有说服力。

Emacs 轻聊讨论组

好的，各位硬核开发者，这是今日份的群聊精华与知识沉淀。经过梳理，我将这些高速信息流整理成了以下结构化的知识库。

🎯 核心热点与专题探讨

今日群内讨论呈现明显的“双轨并行”态势：一是对国内大模型生态的激烈辩论与期待，二是对本地 AI 部署与 Agent 开发实践的深度探索。

【专题一】大模型国产替代“仰望星空”与“脚踏实地”

核心讨论： 围绕 Kimi K3、DeepSeek V4 Pro、智谱 GLM 的新动向，群友展开了关于国产模型实力、商业策略与未来格局的高热度讨论。

  • Kimi K3 的“破圈”效应与“缺货”焦虑： Kimi K3 成为焦点，部分群友表示“想体验竟然还缺货”，侧面印证其火爆。更重磅的是，有消息称微软正在评估 K3 替代部分 Copilot 功能，预计年省 6 亿美元推理成本。这被解读为国产模型在性价比和技术实力上的双重突破，群友评论：“追得挺快的”。
  • DeepSeek V4 Pro 的“全能”期待： 关于其传闻，群内出现了“综合能力对标 Opus-4.8”、“代码生成接近 5.6-sol”等极高评价。群友普遍关注其价格策略，希望“保持原价，就起飞了”。这反映了社区对高性价比、高性能基础模型的渴望。
  • “万恶之源”的算力与商业之争： 讨论延伸至中美 AI 竞争。有观点认为中国公司“用少于美国 2 个数量级的显卡，训练出差不多的效果”，让老外“内心恐慌”。但也有人指出“国内没算力是硬伤”，并担忧“BAT任何一家在这个赛道赢”的“寡头主义”。梁文锋（DeepSeek）因其“着眼于研究、坚持本心”被寄予厚望，被誉为“梁圣”。
  • Grok 与 OpenAI 的“小插曲”： 部分用户发现 Grok 和 OpenAI 的周用量无故“归零”，猜测与模型训练或用户行为追踪有关，引发对平台策略的讨论。同时，OpenAI 高管声称“中国开源权重模型是倾销”的言论，被群友视为“真不要脸”的急眼表现。

核心痛点： 对国产模型崛起的乐观，与对算力掣肘、巨头垄断、模型稳定性和政策风险的担忧交织在一起。

【专题二】本地 AI 部署：理想丰满，现实骨感

核心讨论： 由“懒猫微服”系列设备引发的关于本地推理显存需求、模型选择以及实际体验的硬核吐槽。

  • “小内存跑大模型”是骗局？ 一位群友分享其 128G 统一内存的 DGX Spark 跑 Qwen 3.6 27B 模型“体验较好”，引发对“24G 就能跑 27B”观点的反驳。核心争议在于 上下文长度 是决定显存占用的关键。通用任务需要 128k 上下文，这导致显存需求远超模型参数本身。群友直言：“好多帖子吹多小内存就能跑多大模型的，根本就没实际用过”。
  • MoE 模型的“真香”定律： 针对稠密模型慢的问题，有经验者指出 MoE (Mixture of Experts) 模型是出路。“实际跑起来只激活很小的参数，速度会快很多”，并举例 Qwen 3.6 35B A3B “速度快得飞起”。
  • Agent 是本地模型的“试金石”： 讨论认为本地模型在复杂任务上（尤其是代码和工具调用）体验不佳。“连 ds pro 写代码都不行，何况本地模型了”，痛点在于上下文不足导致工具调用很快被打断。结论是本地模型目前“给非专业人士玩玩的水平”，真正可用的 Agent 仍需依赖云服务。

🔑 关键概念与技术解析

  • MoE (Mixture of Experts / 混合专家模型)： 一种模型架构，它将一个大模型拆分成多个“专家”子网络。推理时，只激活与当前任务最相关的少数专家，而非全部参数。这能有效降低计算和显存开销，是实现大模型高效推理的关键技术之一。
  • 统一内存 (Unified Memory / UM)： 在 Apple Silicon (如 M 系列芯片) 和一些服务器级芯片 (如 NVIDIA Grace Hopper) 上的内存架构。它允许 CPU 和 GPU 直接访问同一个物理内存池，无需进行数据拷贝，极大简化了编程模型并提升了数据密集型应用（如 LLM 推理）的效率。
  • O(N²) 维护成本与知识库腐烂： 群内引用的一篇文章提出的核心模型。随着知识库笔记数量 N 增加，维护新笔记与所有旧笔记关联性的成本（O(N²)）呈二次方增长，而知识库的“可感知价值”增长缓慢（亚线性）。当两者交叉后，维护将成为纯负担，知识库会退化为“只写系统”，即信息“进去但出不来”。这解释了为什么大多数人的知识库在 500-2000 条笔记后开始“腐烂”。
  • Elixir/Erlang (BEAM) 生态的 AI 吸引力： 有群友深入分析指出，Elixir 因其优秀的错误报告结构，可能比 Clojure 更有利于大模型进行代码“局部修改和自我修正”。OpenAI 的 Symphony 项目选择 Elixir，以及一些 Agent 框架用 TypeScript 实现类似 BEAM 模型，都指向了这一趋势。
  • Vibe Coding / Web Coding： 一个社区梗。指程序员通过与 AI 对话、描述想法来生成代码的编程方式。在语音输入场景下，由于“Vibe”和“Web”发音相似，常被语音识别系统错误识别，成为一个有趣的痛点。

💎 碎片知识与金句拾遗

  • 关于语音输入的独特观点： “你用了语音输入法，你就会更有表达欲，能更清晰的把你的需求说给 AI 听，而不是懒得打更多的字。反而，AI不能理解你到底想干嘛。” —— 这不仅是工具推荐，更是对 人机交互效率 的深刻洞察。
  • 关于 Agent 架构的脑洞： “目标是原生与 emacs 整合，以 buffer 作为上下文和状态池，以 eshell 替代其它 agent 里常见的 bash”—— 这是将 Emacs 哲学应用于 Agent 设计的极致想法，体现了高度客制化的硬核精神。
  • 关于大模型竞争的“务实”策略： “我希望可以达到 xhigh，保持原价，就起飞了。”—— 将价格与性能的精确对标，反映了开发者对 API 的经济账有清晰认知。
  • 关于“知识库”的生存哲学： “绝大多数人的知识库在使用几个月后退化成‘只写系统’。他们继续往里写——因为写入给人一种‘我在学习’的满足感——但读取的成功率趋近于零。” —— 直击知识管理中的自我感动式陷阱。
  • 关于开发语言的选择： “开发迭代快。不快，这些产品很容易被直接干死。” —— 解释了为什么 Agent 产品多用 TypeScript 而非 Rust。
  • 一个好玩的工具推荐： transcribe.cpp (https://github.com/handy-computer/transcribe.cpp) —— 专为本地语音 ASR (自动语音识别) 设计的 C++ 框架，被推荐整合到语音输入工具中。
  • NixOS 的“养老”悖论： “我发现，养老的关键，不是用什么系统，而是工作做什么开发。如果开发环境标准，那确实 nixos 可以养老。” —— 一针见血地指出了 NixOS 爱憎分明的生态。
  • 一个有趣的生活事实： “我老婆说元宝比豆包好用， 我一看是姚顺雨训练的， 那没事了。” —— 大模型圈子的“饭圈化”讨论，体现了个人品牌和学术信誉对产品口碑的影响力。

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

  1. deepswe.datacurve.ai (K3 SWE-bench 测试): 关注 Kimi K3 在 SWE-bench（软件工程）测试中的分数、具体方法及定价。它直接反映了其作为 coding agent 的潜力。
  2. slate (RLM / 基于语言模型的推理系统): 群友提到的项目，它结合了 py repl（Python 交互式环境）。可以研究其设计哲学，尤其是如何将 REPL 机制融入 AI Agent 的推理循环。
  3. Amp 的“全局 Agent” 概念： 关注 Amp 发布的新全局 Agent 产品，分析其在 coding agent 领域早期的落地方式，这可能是未来 Agent 能力演进的一个方向。
  4. just-talk-go: 群友自荐的语音输入工具。重点不在于工具本身，而在于其探索的纯终端、无 GUI 的语音交互流程，以及将语音输入与 AI Agent 结合的工作流潜力。
  5. jido (Elixir AI 框架): 如果能深入研究，可以探究其作者为何从 Lisp/Datalog 最终选择 Elixir，以及 Elixir 的 BEAM 虚拟机是如何吸引 AI 应用的。这可能是未来下一代 AI Agent 架构的语言方向。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Kimi/DeepSeek 谁更强”，而是另一条更硬的判断：Agent 的瓶颈正在从“模型会不会”转向“上下文、状态、交互入口能不能被工程化管理”。群里围绕本地模型、Emacs Agent、知识库腐烂、语音输入的几段讨论，其实指向同一个问题：AI 编程不是把模型接进来就完事，真正难的是让人、上下文、工具调用和反馈循环稳定地咬合。

1. 本地模型的真实门槛不是参数量，而是上下文经济学

“24G 能跑 27B”这种说法在演示里成立，在 Agent 里很快露馅。群里反复提到：通用任务、写代码、工具调用需要大上下文；读几个文件、跑几轮工具、压缩几次，体验就崩了。这是很可验证的工程判断：不要只 benchmark tokens/s，要测“完成一个真实任务需要多少有效上下文、压缩后丢了什么、工具调用链能撑几轮”。

所以本地模型当前最适合的不是“替代云端 coding agent”，而是边界清晰的子任务：检索、分类、草稿、局部解释、离线 STT、低风险自动化。MoE 能改善吞吐，但不能自动解决长程状态管理。

2. Emacs 式 Agent 的价值，不在怀旧，而在状态模型

“以 buffer 作为上下文和状态池，以 eshell 替代 bash”这个想法很 Emacs，但不是玩具梗。主流 Agent 往往把 shell、文件、对话历史、任务状态分散在不同抽象里；Emacs 的 buffer 天然是可见、可编辑、可持久化、可组合的状态容器。

如果做得好，Emacs Agent 的优势不是 UI，而是可审计性：上下文在哪里、命令怎么跑、结果如何进入下一步，都能被用户看到并修改。这恰好对冲了长上下文压缩带来的黑箱问题。反过来，如果只是把聊天框嵌进 Emacs，那就没有意义。

3. 知识库腐烂提醒我们：Agent 记忆也会腐烂

那篇“知识库为什么会死”的 O(N²) 维护成本讨论，可以直接迁移到 Agent memory。只写不读的知识库会死，只追加不验证的 Agent 记忆也会死。工程上应该把“能否被成功读取并用于当前任务”当成核心指标，而不是存了多少条。

未来个人知识系统的关键不是更勤奋地整理，而是建立读取闭环：哪些笔记被调用、调用后是否有用、是否过期、是否应该合并或删除。没有这个闭环，LLM 只会把旧知识库的腐烂速度放大。

可继续实践的方向

做一个小实验：选 3 个真实任务，分别用云端 Agent、本地模型、Emacs-buffer 状态化 Agent 跑一遍，记录上下文占用、工具调用轮数、压缩次数、人工纠错点和最终成功率。别看模型排行榜，直接看任务闭环。这个数据比任何“能跑多大模型”的帖子都诚实。