Geekinney

外观

Emacs 社区日报 2026-06-01

约 3178 字大约 11 分钟

2026-06-01

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 中的 AI 代码助手集成现状与痛点

群内围绕如何在 Emacs 中集成 AI（特别是 Codex）展开了一场深入讨论，揭示了现有方案的不足与用户的真实需求。

  • 现有方案：主要提及两个包：agent-shell 和 emacs-codex-ide。用户普遍认可在终端（如 kitty）中使用这些工具。
  • 核心痛点：
    • 功能缺失：vonfry 列举了 emacs-codex-ide 的多个短板：缺乏 /plan、/review、/skills 等指令，没有问答交互，无法通过 esc esc 修改历史。这反映出当前开源方案相比官方闭源 IDE 的功能滞后。
    • 实现细节问题：有用户指出该包存在将确认按钮渲染到 prompt region 内的 bug。此外，user message 中的上下文注入过于冗长。
    • 用户选择：面对这些问题，部分用户仍坚持在 Emacs 中使用（如通过 agent-shell），部分则选择在专用终端应用内操作。一位群友分享了一篇题为《AI时代，全世界都在换IDE，我反向升级回了40年的编辑器》的文章，引发了共鸣，大家普遍认为目前尚未出现将 AI 与 Emacs 深度、无缝融合的理想方案。

专题：Emacs 31 的发布、pgtk 编译与 Windows 平台稳定性

群聊中穿插了对 Emacs 31 及其相关特性的讨论，涵盖了版本发布期待、构建体验和平台兼容性。

  • 发布日期：目前尚无 Emacs 31 的具体发布时间消息。
  • 编译修复：一位用户遇到 pgtk 无法编译的问题，随后通过一个最新的 commit (75d8e5773dede1d6c429bd08a4b8d5a0d87fe87b) 解决了。有成员分析该 commit 仅是调整了 make target，但编译问题确实因此消失。
  • Windows 平台体验：
    • 关键修复：有用户反馈，Emacs 31 修复了 Windows 终端版（TUI）的显示混乱问题，此问题在 31 之前的版本中频繁出现。
    • 启动性能：另一痛点是在 Windows 上 Emacs 加载纯文本文件依然慢。尽管有用户表示 WSL 方案可以解决、或声称完全不卡，但普遍共识是启动速度慢、daemon 模式崩溃是常见问题，这与包管理体系（如 Doom）的复杂性有关。

议题：Doom Emacs 包管理的痛点与 Nix/Guix 的潜在替代方案

群内对 Doom Emacs 的包管理机制表达了普遍不满，并探讨了 Nix 和 Guix 作为解决方案的优劣。

  • 核心问题：
    • Pin 行为不一致：用户发现，对于手动添加的外部包，Doom 不会自动为其生成 pin（锁定版本）文件，需要手动操作。即使手动在配置中 pin 后，doom sync 有时也不更新，需要复杂的 gc 流程。
    • 不可重现性：这种不一致性导致了环境不可重现，对比 Debian 的“可重现构建”理念，这一缺陷尤为突出。
  • Nix 方案：有用户指出，通过 Nix 管理 Doom Emacs（如 nix-doom-emacs-unstraightened）可以完美解决 pin 和不可重现问题，因为 Nix 文件天生只读且具备版本锁定能力。虽然它能用，但下游维护情况不佳（另一个项目已停更），存在兼容性问题。
  • Guix 探索：一位成员正在尝试在 Guix 上构建 Doom Emacs，认为 Guix 相比 Nix 可以提供更高的自由度。

🔑 关键概念与技术解析

  • pgtk：指 Emacs 的“纯 GTK”前端（pure GTK toolkit）。它使用 GTK3 直接实现图形界面，目的是更好地支持 Wayland 等现代显示协议，是当前 Emacs 图形界面的主要发展方向之一。
  • Daemon 模式：Emacs 的一种启动方式，仅在后端启动守护进程（Emacs server），然后通过 emacsclient 命令快速连接该进程。这种方式可以加速 Emacs 的启动，但在 Windows 上因稳定性问题常被诟病。
  • Pin（锁定版本）：在 Emacs 包管理中，指锁定某个包的特定 commit 哈希，以确保不同机器或不同时间点安装的是完全一致的代码，是实现“可重现构建”的关键操作。
  • elfeed vs elfeed protocol：elfeed 是一个 Emacs RSS 阅读器。elfeed protocol 是一个用于处理特定协议的第三方包。当用户从 Doom Emacs 资源库单独安装 elfeed protocol 时，其版本与 Doom 内置的 elfeed 可能不同步，导致行为不一致。

💎 碎片知识与金句拾遗

  • 关于Emacs的未来：“坐等群友的新emacs”——对社区自建方案的期待。
  • 对包管理的吐槽：“这个包管理是的烂，无可置疑的烂。”——直接、极客式的抱怨。
  • 对Doom行为不一致的发现：“它坏啊，行为不一样。要保证一样都要 pin，太麻烦了就算了。”——揭示了开发流程中微小但恼人的不一致。
  • 关于依赖管理的洞察：“因为 nix 都只读的，天生就这样，别人不一定照顾你，能用就算比较好了。”——对 Nix 生态中孤儿项目处境的清醒认知。
  • 一个有趣的安装建议：“直接用emacs-server就好了，然后让client连接到server即可”——针对 Windows 上启动慢问题的临时解决方案。

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

  1. Guix 上的 Doom Emacs：群成员正在尝试构建，这是一个极具前瞻性的项目。Guix 的纯粹性与 Doom 的灵活性结合，可能催生更稳定、更可重现的 Emacs 发行版。建议关注相关进展。
  2. agent-shell：作为目前在 Emacs 中集成 AI 代码助手的备选方案，相比于 emacs-codex-ide 功能可能更完整（但缺少 /skills 补全）。其架构和局限性值得深入分析。
  3. Emacs 31 的 igc (incremental garbage collection) 集成：讨论中提及了“32合igc了吗”，暗示 Emacs 32 有集成增量垃圾回收的计划。igc 是提升 Emacs 交互性能的关键技术，其进展值得长期跟踪。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：AI Agent 的“管道哲学”与工程实践

本日群内最激烈的讨论围绕 AI Agent 的交互范式展开，尤其集中在Agent 是否应该遵循 Unix 哲学（管道化、可组合、无状态）。核心分歧在于：现有 Agent CLI 工具大多封闭在 TUI 内，而真正的“管道化”Agent 能将文本流交给其他命令处理，甚至让模型互相 review。

各方观点与痛点：

  • 反对派：认为当前 CLI Agent（如 Hermes Agent）路子根本是错的，“精簡 llm 生成的代碼简直是折磨”，缺乏标准化输入输出。
  • 拥趸派：强调“管道”思想的重要性，指出 pipe、axe、pipai、ANEL（自称“AI Agent 的 POSIX”）等项目已将 Agent 视为 filter，可组合成复杂工作流。例如 cat error.log | pipe "分析根因" | grep "root"。
  • 折中派：认为关键在于“效能比”，即结果与代价的平衡。Pi（通过 omp 子模块）虽然不完全是管道化，但因其插件极度丰富，已成为很多人的首选 Agent（如用于 X 内容创作）。有人提到 Pi 事实上支持 --continue、-p 等非交互模式，接近管道需求。

解决方案与工具推荐：

  • pipe（github.com/s-age/pipe）— 纯管道 Agent
  • axe（github.com/jrswab/axe）— 明确拒绝 chatbot 范式
  • pipai（github.com/FractalWire/pipai）— 将命令输出直接喂给 LLM
  • ANEL — 使用 Unix pipe + NDJSON + 沙箱隔离
  • PI（oh-my-pi）— 插件生态强大，可作为日常综合 Agent

衍生思考：有人提出“将 agent 作为普通 cli”的畅想，并给出一个案例：一个模型的输出管道给另一个模型进行 review，本质上是对 Unix“组合哲学”的复用。但当前工具大多未标准化，导致“通信不通”的问题依然存在。

专题：大模型时代的控制论——从《控制论和科学方法论》谈提示词工程

一位群友分享了阅读《控制论和科学方法论》的感悟，并提出核心洞见：“控制的本质是缩小可能性空间，而信息的传递就是这种缩小过程的传递。” 进而以“AI 功能测试”为例，演示了如何将控制论应用于提示词优化。

案例演示：

  1. 让 AI 跑功能测试，AI 只回复“跑完了，没问题”——这是一个黑盒，信息不足。
  2. 优化提示词，要求输出一份结构化的测试文档（实测了哪些功能、输入是否鲁棒、输出是否符合预期等）——将“不可控的黑盒”转化为“可控的文档 review”。
  3. 这就是“共轭控制”：将复杂的“称大象”（让 AI 测试代码）转化为简单的“称石头”（review 一份文档）。

群友评价：这本书的目录（控制与反馈、黑箱认识论、质变数学模型等）被称为“硬核”，且在 AI 时代尤其有启发意义——控制 AI 的本质是逼它交出有效信息，而非盲目信赖。

🔑 关键概念与技术解析

  • Neomacs：群内提及的另一个基于 Emacs 的编辑器衍生版（Windows 0.05 版本），但其稳定性和启动存在严重问题。
  • clutch：某位群友自己编写的项目，用于解决“屎山项目”的数据关系建模问题，但认为通用性极难（如 Oracle 存储过程有十几万行 PL/SQL）。
  • ANEL（AI Agent 的 POSIX）：一个自称“POSIX for AI Agents”的开源框架，使用 Unix 管道 + NDJSON 流 + 沙箱隔离，允许多个 Agent 通过管道通信，被视为解决 Agent 组合性问题的潜在方案。
  • 共轭控制：控制论术语，指将一个复杂问题转化为另一个我们直接可以控制的问题。文中举例：“称大象” -> “称石头”。应用于提示优化：将“让 AI 做功能测试”转换为“review 一份结构化测试文档”。

💎 碎片知识与金句拾遗

  • “控制了本质是缩小可能性空间，信息的传递就是这种缩小过程的传递。”
  • “Claude 十分执着于 cli，以至于 codex 根本不需要多优秀的设计就可以俘获很多人的心。GUI的好处就是可以做丰富的展示。”
  • “opencode + minimax m3 不错，趁着还没降智。”
  • “opus 4.8 太容易陷入细节，回复一堆看不懂的代码，GPT 会从功能角度回答。”
  • “我觉得‘管道’这个思想很重要，可以自由地组合各种工作编排。”——由群友提出，引发对“AI Agent 的 POSIX”广泛讨论。
  • 推荐博客：plumz.me（2013年写一枚钻戒14万，2019年推荐 GalGame 《Ever17》），博客风格独特，但不开放 GitHub。
  • “有些悬疑作品（如 Ever17）只能做成 galgame 形式，因为需要特定角度讲故事。”但有人认为“角色看穿谜题但还得演半天，像坐牢。”
  • 群内提到“Emacs 有一个色图群，里面有男娘图和二次元色图”——但未确认是否还在运转。
  • “大模型时代的控制论”一文中，提到“曹冲称象”的典故，用于解释共轭控制的概念。
  • 群友分享了一篇关于“39 岁对死亡的焦虑”的文章（plumz.me），有群友评论“有点传播焦虑了”。

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

  • Pipe-based Agent CLI 工具集：重点关注 pipe、axe、pipai、ANEL。这些项目试图将 AI Agent 标准化为“Unix filter”，实现多 agent 组合、模型之间互相 review、与 grep/jq 等传统命令联动。目前尚在早期，急需一个“AI 的 POSIX”标准。
  • 《控制论和科学方法论》：金观涛、华国凡著。文中提到的“可能性空间”“共轭控制”“黑箱认识论”对当今的提示工程、Agent 行为控制有极强的指导意义。建议深入阅读。
  • PL/SQL 逆向工程：群友提到 Oracle 旧项目的存储过程（十几万行）中的业务关系，目前缺乏有效的自动建模工具（clutch 尝试解决，但通用性困难）。这是一个垂直领域的工程痛点，若有人能做出实用工具，会很有价值。
  • Pi（oh-my-pi）的插件生态：虽然 Pi 不完全符合管道哲学，但其“插件极度丰富”的优势使其成为很多人的 Agent 主力。值得研究其架构，看能否结合管道思想进化。