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

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Windows 下 Emacs 的 C-SPC 冲突问题及解决方案

这是本日最持久的讨论，多位用户分享了在 Windows 上使用 Emacs 时遇到的 C-SPC（设置标记）被系统输入法劫持的问题。

• 痛点: C-SPC 在 Windows 上默认被用于切换中英文输入法（或启用/禁用输入法），导致 Emacs 中 mark set 功能失效。用户 jineuropium 发现 C-SHIFT-Space 可以正常使用，但 C-SPC 无论通过系统设置还是注册表修改都无效。有用户指出 Windows 的设置 UI “改了没效果”，甚至“重启后恢复”。
• 探索与方案:
  • κόσμος 分享了他的 WSL + TUI Emacs 方案：使用英文键盘布局时，C-SPC 会透传给终端。如果需输入中文，则使用 emacs-rime 输入法。
  • 禁用输入法: 有用户指出，切换到“没有输入法的键盘布局”（如纯 US 键盘）可解决问题，关键是让 Windows 不拦截该快捷键。
  • 输入法本身行为: 用户 @fuzy 试过调整输入法设置，但“小狼毫（Weasel）怎么设置都是切换中英文”，无法彻底取消。
  • 群体认知: 大家普遍认同这是 Windows 平台的特有问题，macOS 和 Linux 的 C-SPC 行为一致。用户的无奈感很强，甚至有人考虑“期末考完就把 Win 删掉”。

专题二：Emacs 配置的“包数量”与启动优化

用户 猛男 m n 发起了一个有趣的统计：通过 rg use-package | wc -l 统计配置中引用的包数量（733个），引发了关于 Emacs 配置臃肿度与启动速度的讨论。

• 数据对比: 群内用户包数量从 8 个到 733 个不等，多数集中在 150-300 之间。大家对“多”的定义差异巨大，但普遍认为 Emacs 底子好，扛得住。
• 优化策略: 有人提到“懒加载”（use-package 的 :defer 或 :after），但反对方指出“懒加载的结果就是打字的时候触发一个包就卡半天”。也有用户无任何优化时启动仅需 3.3 秒，但另一个 M5 Pro 用户却在未优化时启动需要近 60 秒，差异巨大。
• 未来预期: 猛男 m n 表示期待未来 neomacs 项目能让“加载 1000 个包也像闪电一样飞快”。
• 统计方法争议: κόσμος 指出 use-package 计数不准（依赖包、内置包、重复配置等因素），建议用 (length package-alist) 更准确，他的结果是 248 个。

专题三：Agent 开发中，如何正确处理 Lisp 代码的括号匹配？

多个用户抱怨与 AI Agent（如 Claude/GPT）协作编写 Elisp 代码时，模型在处理括号上耗费大量上下文，且经常出错。

• 核心痛点: “因为 AI 会耗费非常多上下文在数括号上，尤其是没那么强的”，导致代码生成质量低、逻辑混乱。
• 现有方案讨论:
  • 直接调用 Emacs: 让 Agent 直接运行 emacs -Q --batch -L 或调用 check-parens 函数来验证括号平衡。
  • MCP/Skill: 借鉴 codex-ide 的做法，将括号检查/补全功能封装成 MCP 工具或 Agent Skill，而非依赖模型自身。
  • 结构化数据: 有观点认为，对于这类任务，让 Agent 操作 XML/HTML 等结构化数据比操作纯文本 Markdown 更准确（因为训练数据量大）。
  • “数括号”与“补括号”: 用户指出更优的方案是让 Agent “自己写一个配平括号的 tools” 来检查，但“怎么补括号纯看它”，最后可能还不如让人类来补。
• 延伸思考: 讨论延伸至“Agent 的本质是 AI 何时读取 Markdown 更好”，以及是否应直接让 Agent 操作 HTML（尽管会消耗更多 token）。用户 猛男 m n 表示“AI 操作 HTML/XML 的准确性是最高的”。

🔑 关键概念与技术解析

• Fable: 一个 AI 编码助手项目，被认为是 Aider 的继任者或竞争者。有说法是 Fable 的推理能力是 Opus 的 2 倍，且最高支持 20x 的消耗模式。目前可能只开放 API，不面向套餐供应。
• Neomacs: 一个新兴的、用 Rust 重写的 Emacs 实现（或类似项目），旨在解决传统 Emacs 的性能瓶颈，让加载成百上千个包也能飞快启动。
• Nelisp: 一个用 Rust 实现的 Elisp 解释器，来自项目 anvil.el。这是一个值得关注的底层项目，可能为 Emacs 生态带来性能优化和新可能。
• agent-shell: 一个用于构建 AI Agent 的 Shell 环境，可能支持执行命令、展示图表（SVG 格式）等。
• MCP 与 Skill: 两种为 AI Agent 提供能力的扩展机制。MCP (Model Context Protocol) 是标准的工具调用协议，而 Skill 可能是一种更轻量、更灵活的配置方式。讨论中倾向于在某些场景下 Skill 比 MCP 更方便。

💎 碎片知识与金句拾遗

• 对 Emacs 极端主义的调侃: “如果你用了 Emacs，却舍弃了优秀的功能，把 Emacs 用的和其他编辑器一样，那为什么不直接用其他编辑器呢？” —— 针对 treemacs 与 dired 的争论。
• 对 AI 编码工具的真实体验: “用 token 就像刚健身一样，喝水吨吨吨地没了。” —— 形容 AI API 调用消耗之快。
• 对 Emacs 生态的黑色幽默: “有了 AI 算好了，以前上网问（Emacs问题）可要被网暴的。” —— 关于社区曾经可能存在的压力。
• 极简主义者的炫耀: 用户 jineuropium 称自己只装了“8 个包”，引发众人惊讶。
• 对 Emacs 本质的清醒认知: “Emacs 本质上是一个纯文本编辑器，不是富文本编辑器，不是 Word。” —— 当用户 jineuropium 想在 Org-mode 里实现鼠标拖拽裁剪图片时，群友的回应。
• 运维小贴士: 升级 macOS 27 后遇到 Homebrew 问题，需要安装对应版本的 Xcode beta 才能解决。
• 工作流推荐: “我觉得 language server 很大程度上还是和编辑器集成用的，让 agent 用 CLI 就好了。” —— 对于 AI 是否需要 LSP 的讨论。
• 统计学上的发现: 有人统计自己的配置中有 733 个 use-package，但通过 package-alist 实际安装的包只有 362 个，说明大量使用了内置包或重复配置。

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

• Nelisp (Rust Elisp Interpreter): 这是一个由社区发起的、用 Rust 实现的 Elisp 运行时。它将对 Emacs 社区产生何种影响？能否实现“加载 1000 个包也飞快”？
• Neomacs (Rust Emacs): 同样是一个雄心勃勃的 Rust 重写计划，有用户已在体验其 v0.0.6 版本。值得关注其性能和兼容性进展。
• clutch 项目对 MongoDB 的支持: 该项目正在开发数据库客户端功能，这是一个 Emacs 内原生数据库工具的新探索。
• Fable 与传统 AI 编码工具的对比: 其独特的消耗模式和开放 API 策略，是否会对 Aider 和 Claude Code 的生态构成冲击？
• Windows 上 C-SPC 的终极解决方案: 虽暂无万能解，但“切换到无输入法的英文键盘布局”和“WSL + TUI Emacs + emacs-rime”的组合方案值得尝试和总结。

Emacs 轻聊讨论组

好的，这是根据您提供的聊天记录整理出的结构化知识库。

🎯 核心热点与专题探讨

专题：大型语言模型（LLM）的军备竞赛与应用焦虑

群内热烈讨论了Anthropic最新发布的模型 Fable5，以及围绕它产生的“烧钱”体验、模型横向对比和底层Agent框架的生态演变。

1. Fable5 登场：性能怪兽与成本黑洞

   • 发布与定价：Fable5 于当日发布，定价为每百万输入10美元，每百万输出50美元。群友迅速将其与之前的旗舰模型 Opus 对比，形容为“Opus 的10x”，而 Token 消耗速度更是“20x 的一大半”，甚至一个复杂问题就能“干满 pro 的5小时限制”。
   • 实际体验与争议：有群友反馈，用它“扫了一下项目代码，写了一份300行的文档”就提示无余额。另一个群友则故意用它“读一下 emacs 的配置”并“effort 开到最大”来测试其消耗能力，引发“我滴乖乖”、“浪费啊”的围观。这种极强的推理能力与极高的 Token 成本形成了鲜明对比，引发了关于“价值”与“浪费”的讨论。

2. Agent 框架的轻量化追求：从“大而全”到“裸框架”

   • 痛点驱动：群友普遍对现有 Agent 框架（如 Pi、Hermes）的复杂性和启动速度感到不满。具体表现为“操作感觉都不是说那么顺畅”、“打开 Pi 要等”、“架构一复杂就慢”。尤其提到 Pi 的 resume 功能和“700个session显示出来之前要等6秒”。
   • 新框架 Bub 的引介：为解决上述痛点，一位群友分享了 Bub 这个“比 Pi 还精简的 Agent 框架”。其核心优势在于“几乎全裸”，让开发者可以直接实验 Agent 开发思路，而不是被复杂的封装困住。群友已向该项目提交 PR 并加入官方组织。
   • 对“更快”语言的渴望：为了追求更快的启动速度（“至少打开能秒进”），群友表达了对 非 TypeScript/Python 的 Agent 框架 的渴望，指出 TS 本身“慢”，而 Go 语言被戏称为“用 go 写，又小又快”的理想选择。Kimi CLI 转 TS 之前打开很快的例子也被引用作为对比。
   • 总结：这一趋势反映了 Agent 框架正从满足通用、复杂的自动化需求，转向满足资深开发者对“裸金属”级别、可精细控制的轻量级实验环境的需求。

3. AI 写作的“蒸馏”与“本地记忆”

   • AI 写小说的现状与困境：群友一致认为，让大模型写出好小说“必须不断地蒸馏经验”，目前的生成结果“文笔很差”、“连主角性别都很模糊”。有群友分享了改进后的片段，但被评价为“文笔很差”、“和番茄小说一样”。
   • 技术方案探讨：一位群友分享了其设计的 AI 写作系统，强调通过 本地 Memory 和 Vector 存储 来管理上下文，实现“自循环->写作->审计->打分->用户评分->总结->学习->调整”的闭环。核心思路是避免上下文膨胀，通过压缩和调用关键信息（如伏笔、人物设定）来提升生成质量。该方案使用 DeepSeek v4，群友反馈“做了本地记忆之后，生出来的文字比之前强一个档次”。

🔑 关键概念与技术解析

• Fable5：Anthropic 发布的新一代旗舰模型，推理能力极强，但 Token 消耗速度惊人，是 Opus 的10倍，成本极高。
• Bub：一个新出现的极简 Agent 框架，设计哲学是“全裸”，不包含复杂的 TUI 或封装，让开发者能自由实验 Agent 工作流。目前不支持在配置中同时配置多个 OpenAI compatible 的 provider。
• Hermes Agent / Pi：文中提到的两个较复杂的 Agent 框架，群友认为它们因架构日益复杂导致启动和响应速度变慢。
• SillyTavern (酒馆)：一个开源的 AI 角色扮演框架，用于与各种 LLM 进行沉浸式对话。
• --dangerouslyskip-permissions：一个跳过安装或执行权限确认的命令行参数，通常用于脚本自动化，但被提醒有危险性。
• MacBook Neo：苹果发布的一款入门级笔记本电脑，8GB 内存，售价 599 美元起。因其极高的性价比（在同等价位上性能和便携性突出），在学生和轻量用户群体中需求强劲，成为“唯一指定电脑”。

💎 碎片知识与金句拾遗

• Token 焦虑：“我看不得别人浪费 token”（出现两次，体现资深用户的核心价值观）。
• Vibe Coding 的真谛：“不用交付的 vibe 很快乐” vs “工作的 vibe 很不快乐”。（对编程快乐本质的精准洞察）
• AI 写作的细节缺失：“我改写了下，吸入灰尘应该会咳嗽，ai都没有意识到这一点”。（点明当前模型在物理常识上的不足）
• 硬件洞察：“16都打不了游戏了”、“32g 就不普通了”。（对当前游戏 PC 内存配置趋势的主观判断）
• 产品种草：“立即购入马里奥网球🌚” (因群友讨论网球而引发的冲动消费)。
• 人才流动的警示：“出事了你还能Call，直接失联了”。（讨论一个高风险的缅甸招聘陷阱，强调要警惕）。
• LLM 政治性应用：“中国投入11亿开发AI智能体以推广习近平思想”，群友对此的反应是“我非常期待呢 到时候各种翻车截图对话满天飞”。
• 书简讨论：引用三联书社的文风，认为“虽然文绉绉的，...相对好一些”。
• 关于Neo的思考：“苹果应该是尝到低端市场的甜头了”。
• Emacs 见闻：一位群友在 Emacs 里用 Claude Code 进行代码审查，并分享了相关 PR 链接。还有群友提到由于“万象方案”不稳定，换回了“frost” Emacs 配置。

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

• Agent 框架 Bub：一个轻量、非封装、力求启动快速的 Agent 框架。它代表了 Agent 开发从“开箱即用”到“裸核实验”的趋势。值得研究其设计原理和实现方式。 🔗 [项目地址未在群聊中直接提供，建议搜索]
• AI 写作系统的 Memory 架构：聊天中详细描述的自建本地 Memory + Vector 存储的方案，用于解决 AI 长篇小说写作中上下文丢失、情节熵增问题。可以作为一个有价值的 RAG 应用案例进行深入研究。
• DeepSeek v4 写作能力评测：结合群友反馈和实际测试，对 DeepSeek v4 的中文写作能力进行更深入的评测，尤其是在长上下文和 RAG 配合下的表现。