Geekinney

外观

Emacs 社区日报 2026-07-16

约 5692 字大约 19 分钟

2026-07-16

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

Emacs 中文讨论组

好的，这是对今日群聊记录的整理与升华。

🎯 核心热点与专题探讨

今日讨论非常活跃，可以归纳为三个主要专题。

专题一：Emacs 生态的“CLI 化”与“Agent 化”浪潮

核心观点：随着各大模型和工具纷纷推出 CLI 作为主要交互界面，Emacs 作为“一切皆文本”的编辑器，意外地成为了受益最大的平台。群友们认为，通过 Emacs 的桥梁，可以直接将各种 CLI 工具转化为强大的编辑器功能。

  • 以“瑞幸 CLI”为引子：一位群友正在编写 luckin.el，一个在 Emacs 里点瑞幸咖啡的插件。他从瑞幸的网页/API 入手，开发对应的 CLI，然后通过 Emacs Lisp 调用，实现了“在 Emacs 里点咖啡”的魔幻现实操作。大家调侃：“感觉好像快成了”。这引发了关于“万物皆可 CLI”的讨论。
  • “CLI 是 Emacs 最好的前端”：有群友点出，“我发现各家推 CLI 后最大的受益者是 Emacs”，“有这么多 cli 可以用，emacs 完全可以成为它们的前端”。这体现了 Emacs 社区独特的哲学：通过组合小而美的 CLI 工具（如 AI Agent、代码补全、甚至餐饮服务）来构建一个超级工作台，而非依赖单一、封闭的 IDE。
  • Agent 在 Emacs 中的实践：讨论延伸到了对 AI Agent（如 opencode、Claude Code）在 Emacs 内的使用体验。群友抱怨 TUI Agent 的鼠标点击存在误触问题（“已经让我误触了好几次”），并提出了一个前瞻性的设想：“感觉是不是可以模拟一下终端协议，让 emacs buffer 完美使用各种 agent”。这意味着，真正的 Agent 集成需要超越简单的终端模拟，深入到 Emacs 的 buffer 编辑和交互模式中。
  • gptel-rewrite 的妙用：多位用户分享了 gptel-rewrite 的实践，将其用于推文总结/翻译、论文摘要等，验证了其强大的“组合性”。有人将其与新开发的 arxiv.el 插件配合，实现了在 Emacs 内浏览论文并实时调用 LLM 进行理解和总结的极客流水线。

专题二：Emacs 启动速度、性能与“美”的博弈

核心观点：本专题探讨了 Emacs 的日常运维哲学，包括启动速度、运行性能、重启以及美学。群友们分享了自己是如何平衡效率与体验的。

  • 启动慢不是问题？：讨论从“有人说不 Emacs 不重启”和“Emacs 启动速度不重要”开始。有群友反驳“任何软件当然是越快越好”。但更多人认为，当配置稳定后，确实不需要频繁重启。还有人表示“我启动 10s 都不在意”，强调使用体验的稳定比启动速度更重要。
  • “Emacs 的问题是很容易变慢”：有群友提出关键痛点，“到处抄配置，还需要理解包管理工具，自己调试”是导致 Emacs 变慢的根本原因。这表明，Emacs 的“慢”往往是配置失当或 package 冲突所致，而非编辑器本身的缺陷。
  • restart-emacs 与 systemd 的冲突：一位使用 systemd 管理 Emacs daemon 的群友发现，restart-emacs 后进程会被 systemd 杀掉，因为 Emacs 发送了 STOPPING=1 但未立即退出，触发了 systemd 的超时机制。这揭示了 daemon 模式下的一个微妙陷阱。
  • “取悦自己”的美学实践：大量图片展示了群友的 Emacs 启动界面、自定义 Dashboard 和个人主题。有群友的启动界面是“让 AI vibe 出来的高雅企鹅”。主流观点是“dashboard 除了截图还有别的用吗？（答：取悦自己）”。这表明，对于那些将 Emacs 作为日常桌面核心工具的人来说，审美和个性化同样是重要的生产力组成部分。

专题三：Emacs 包维护的痛点与解法

核心观点：群友们讨论了如何维护和分发 Emacs 包，核心矛盾在于个人需求与上游作者、社区规范的冲突。

  • PR 被拒的困境：一位群友抱怨 pg-el 包的作者不接收他的 PR，而他已发现三个不满足需求的地方。这反映了开源社区中常见的“参与者”与“维护者”之间的张力。
  • 解决方案全景：群友提出了多种解决方案，形成了一个策略矩阵：
    1. 本地打补丁：最简单，但仅用于个人。
    2. Vendor 并改名：技术上可行，但不符合 Melpa 规范。
    3. 建立私有 Melpa：适合小团队，但分发和管理成本高。
    4. 使用 Nix 覆盖：overrideAttrs + 自定义 fork 仓库，被视为最优雅、侵入性最小的解决方案，尤其适合已经使用 Nix 的用户。
    5. 写补丁函数 (advice)：临时的、非侵入性的解决方案，能让用户以最快速的方式用上想要的特性，同时等待 PR 被合并。
  • use-package 的争议：有新手对 use-package 的配置感到困惑。资深群友建议“用不明白就别用”或“展开宏看看就明白了”，点出真正的门槛在于理解 Elisp 宏的执行逻辑，而非 use-package 本身。

🔑 关键概念与技术解析

  • ACP (Agent Communication Protocol): 一种用于 AI Agent 之间或 Agent 与宿主程序通信的协议。在讨论中，群友提到某些 TUI Agent 对 ACP 支持不佳，导致无法完全在 Emacs buffer 中使用。
  • gptel-rewrite: gptel 包中的一个功能，允许用户选中一段文本，然后通过 AI 进行重写、翻译、总结等操作。它展示了 LLM 与 Emacs 结合的强大潜力。
  • corfu: 一种流行的 Emacs 补全前端框架，支持 child-frame (子窗口) 显示候选词。群友在讨论 UI 设计时，常将其作为用户界面设计的参照基准。
  • eldoc-box: 一个 Emacs 包，用于在光标附近 (child-frame) 显示文档信息。群友在设计 proofread 插件的弹窗 UI 时，直接引用了它的 Face 设计。
  • vibe: 在此处指代“通过 AI 生成内容”。例如，“我的启动界面是我让 AI vibe 出来的”，意为通过描述想法，让 AI 自动生成一张图片。

💎 碎片知识与金句拾遗

  • 金句：万物皆可 CLI：“转一下就变成 CLI 了。” —— 调侃中将任何线上服务转化为终端的魔法。
  • 金句：Emacs 组合性：“感觉 emacs 的可组合性挺好玩的。” —— 对 Emacs 通过组合小工具完成复杂任务的核心哲理的朴素赞美。
  • 金句：愉悦自己的哲学：“我每次启动emacs就能看到高雅企鹅 我心情会变好点。” / “取悦自己，愉悦自己。” —— 强调了工作环境的美学对开发者心理状态的重要性。
  • 冷门工具警告：chirp (推文客户端) + gptel-rewrite 组合，用于实时翻译/总结推文。
  • 性能测试实录：“我的 deepseek 充了一百，用了俩月总共花了三十四。” —— 给了一个具体的 API 花费数据点。
  • 零散知识：
    • Windows 上 WebView 启动无论如何都会有 1-2 秒的白屏。
    • M-x restart-emacs 是开发利器，尤其在测试 package 时。
    • citre + AI 可以打造出不需要 LSP 的强大补全方案。
    • meow 编辑模式似乎也能做很多和 AI 相关的事情。
    • arXiv 的新插件 (arxiv.el) 与 eww 和 html2org 配合良好，可以渲染论文中的公式。

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

  • luckin.el / magh.el / Mcdonald.el: 这是将真实世界服务（餐饮、咖啡）抽象为 Emacs 命令的实验性项目。研究其如何模拟/cli 抓取 API、处理地理位置、以及可能存在的支付二维码问题，对于理解“万物皆可 Emacs”具有启发性。
  • Agent-Shell + Emacs Buffer 的整合方案: 群友提出了“模拟终端协议，让 emacs buffer 完美使用各种 agent”的想法。这指向了开发一种新型的 Emacs 包，能够代理 TUI Agent 的 I/O 流，将原本在终端中互动的 AI 工具无缝嵌入到编辑器的 buffer 和交互模型中。
  • proofread + 的地得 的 LLM 定制化 Checker: 有人提出为 LLM 语法检查插件开发一个专门的“的地得”检查器。将这视为一个有趣的 NLP 课题：如何用规则或小模型，在句子中精准地识别“的/地/得”的错误使用，并给出修改建议。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是 “luckin.el 很好玩”，而是一个更硬的判断：Emacs 正在因为 CLI 和 AI Agent 的复兴，重新获得一种工程上的中心性。但这种中心性不来自“编辑器大战”，而来自它一直擅长的事：把外部能力降维成文本、buffer、命令和可组合接口。

1. “万物皆可 CLI”不是玩笑，是软件边界的重新划分

群里从 luckin.el 讲到瑞幸 CLI、麦当劳 MCP，看起来像段子；但段子的锋利之处在于，它暴露了一个趋势：只要一个服务能被抽象成命令、状态、选择和确认，Emacs 就能成为它的宿主界面。

这不是说 Emacs 要真的变成点咖啡工具，而是说 GUI 应用里那些被封装死的流程，一旦变成 CLI/API，就重新进入了工程师可组合、可审计、可自动化的世界。地点识别、商品预览、下单、二维码支付，这些步骤如果都能以明确状态暴露出来，Emacs Lisp 只是最后一层胶水。

可验证的工程判断是：真正有生命力的不是某个 .el 插件，而是底层 CLI 是否稳定、状态模型是否清楚、失败路径是否可恢复。否则 “在 Emacs 里点咖啡” 只能是 demo；一旦这些条件成立，它就和 Git、邮件、RSS、LLM rewrite 没有本质区别。

2. Agent 进 Emacs 的瓶颈，不是调用模型，而是交互协议

群里抱怨 Claude Code / opencode 这类 TUI Agent 鼠标误触、选择污染 context，又提到 “模拟终端协议，让 emacs buffer 完美使用各种 agent”，这比单纯讨论 gptel 更关键。

今天多数 Agent 仍然假设自己活在终端里：它们输出一坨带控制序列的界面，让用户按 Y/N、1/2/3、点击选项。Emacs 如果只是开个 terminal buffer 承接它，其实没有真正集成，只是把终端嵌进编辑器。更深的集成应该把 Agent 的意图结构化：候选项、diff、文件操作、上下文引用、确认动作，都应该能映射到 Emacs 的 buffer、overlay、keymap、transient、completion、xref 体系里。

所以 ACP 支持不全这个细节很重要。它说明 Agent 集成的胜负手不是“能不能跑”，而是协议能不能表达足够多的语义。终端协议只能搬运界面，Agent 协议才可能搬运意图。

3. Emacs 的可组合性会放大好工具，也会放大烂抽象

gptel-rewrite 配 chirp、arxiv.el、eww、html2org，被群友评价为“可组合性挺好玩”。这正是 Emacs 最强的地方：一个功能只要能处理选区、buffer 或文本流，就能被接到完全意想不到的场景里。

但同一天也有人讨论 use-package 不懂就别用、pg-el PR 不接、Nix override、补丁函数、性能退化。这提醒我们：可组合性不是免费的。它要求用户理解启用条件、依赖边界、宏展开、包维护路径和性能成本。Emacs 不是低代码平台，它是高杠杆平台；杠杆越长，错误配置和不稳定上游带来的摆动越大。

可继续研究/实践

可以认真做一个 “Agent Shell for Emacs” 原型：不要先追求支持所有 Agent，而是选一个 TUI Agent，把它的选择、diff、确认、上下文引用拆成 Emacs 原生对象。验证标准很简单：是否减少误触，是否避免污染 context，是否能把 Agent 的输出变成可编辑、可跳转、可复用的 buffer 结构。这个方向比再写一个聊天窗口更像 Emacs 的未来。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI Coding 工具生态大混战——“重置”与“蹬额度”的狂欢与焦虑

本周的核心热度集中在 AI 编码工具（Codex, Grok Build, Claude Code 等）的“额度重置”狂欢 与 多工具并行使用体验的优劣。

  • 核心事件：群内多位成员在同一时间点（7月16日中午）收到 Codex Pro 的额度重置通知（从提示“无重置”到“重置了ohye”），引发大量讨论。Grok Build 也在同一时期重置，且速度飞快。
  • 用户行为：成员们处于一种近乎“通胀”的额度过剩状态，讨论焦点从“如何节省额度”转变为“用什么来蹬（消耗额度）”。有人“灵感爆发”但苦于额度不足，有人“被富裕的 token 逼疯”。
  • 工具对比：
    • Grok Build：被认为速度飞快、TUI 设计比 Claude Code 更舒服，且无内容限制。已被开源（采用 force push 单个提交的独特方式），但被质疑可能上传用户代码，且不支持 Linux。
    • Multica（AI + 看板工具）：被评价为“越用越顺手，减轻思考压力”，但用户反馈它预设 Agent 不足，且对 Codex 兼容度不够好（偶发 task failed）。
    • jcode（类似 Kite？）：因浮动的 UI 设计受到关注，但用户“硬刚”后指出它可能疯狂消耗 API 额度（生成 154.8MB 日志、产生 1000 个 subagent），并怀疑其后台进程导致额度异常下降，引发安全与使用成本担忧。
  • 观点碰撞：
    • 关于额度的使用效率：有人坚持“Medium 足矣”，有人则用“Ultra”或“Xhigh”进行高强度重构。
    • 关于 AI 商业闭环：群友就“用 AI 赚钱”展开讨论，认为“AI 越强 -> AI 越贵 -> 赚钱动力 -> 开发垂直需求 -> 赚钱 -> 买更强 AI”是正反馈路径。但多数人坦诚“还没赚到钱”。有成员提出“有人弄个 Hacker News 客户端+翻译就能卖钱”的现象，引发关于用户付费意愿（方便 vs. 懒得动手）的讨论。

专题二：AI 代码的版权、社区治理与 Linus 的“挡道”论

针对 Emacs 社区拒绝 AI 生成的代码以及 Linus Torvalds 怒斥反 AI 内核开发者的事件，展开了关于 “AI 代码的版权归属与社区接纳度” 的深入讨论。

  • 核心观点：
    • “版权问题过时了”：有成员认为，版权法仍停留在文学作品层面，无法界定“用 AI 从别处抄来一段有版权的代码”的责任归属，认为“模型供应商”应承担主要责任。
    • “Linus 是对的”：多位成员赞同 Linus 的态度，认为其已亲自评估 AI 能力，且 Linux 内核的“负责人 review”机制可以降低风险，这与 Emacs/FSF（自由软件基金会）的保守态度形成对比。引用群友传话：“emacs 不接受AI是因为fsf目前还不确定AI生成的代码有没有版权问题。”
    • “技术利他 vs 商业现实”：讨论指出，Linus 常年有商业机构赞助，采用“提出想法 -> 社区实现 -> 他 review”的模式，而许多开源项目（如 Emacs）缺乏这种 review 资源，因此更谨慎。

专题三：股市与“量化”的业余谈资

群内穿插了关于 A 股、投资心态与策略 的非技术但极具生活感的讨论，反映技术开发者的投资观。

  • 观点：
    • “别玩 A 股”：多位成员含泪劝阻，有人自述“去年翻倍，今年全亏回去，还斑秃了”。
    • “心态比技术重要”：强调股票磨练心态，让人习惯从长期看问题，但“越想赚快钱，亏得越多”。
    • “实战分享”：有成员分享“情绪、连板、冰点”的短线策略，并认为“今天是个冰点可以尾盘买点”。有人主张“买新股票前先列5个理由，做好操盘计划”。

🔑 关键概念与技术解析

无明显新增概念。所有术语（如 Codex Pro、Multica、Grok Build、Karabiner-Elements、Kinesis 人体工学键盘）均为已有项目的简称或工具名。

💎 碎片知识与金句拾遗

  • 关于 AI 赚钱的看法：“有人弄了个 hacker news 客户端+翻译就可以卖钱...离谱！但是人家愿意买。” —— 揭示需求长尾化的现实。
  • 关于理智与情绪：“上班的钱 花起来很痛苦，炒股赚的钱 花起来比较爽。钱和钱 是没有差异的，但是为了赚钱付出的精力不一样。”
  • 关于 AI 工具的使用哲学：“每次token耗尽都是我灵感爆发的时候......合理，token冷静期。” —— 幽默地调侃了 AI 对创造节奏的干扰。
  • 关于 UI 设计的细节洞察：“我关心我还有多少没蹬完。” —— 说明在 AI 额度紧张或充裕时，用户对“剩余量”的 UI 反馈需求极高。
  • 关于键盘与生产力：“KINESIS 越用越想用，等我解决好和 mac 适配的问题，我打算把它转为主力键盘了。我刚才发现，可以用 Karabiner-Elements 修改全局按键！” —— 具体的人体工学键盘适配技巧。
  • 关于开源与信任：“马斯克：谁说给你安装的是我们开源的了🌚”“后面只从 github 下载。” —— 对闭源商业软件的开源承诺的警惕。
  • 对一位“副局长”博客的致敬：“没想到这篇这么好的文章，下架了。居然说是一个副局长的博客……局长有水平，真有水平，比那些什么营销号的文笔好太多了，逻辑，细节。” —— 推荐了某位前官员的高质量技术或时评文章（虽未指名具体文章）。
  • 关于 Emacs 社区的奇特互动：“老外好搞笑，ni hao。”（一位成员在英语 Emacs 群用一种奇怪的方式打招呼）

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

  1. Grok Build 的开源实现：其背后的 grok-build 仓库（https://github.com/xai-org/grok-build） 采用“始终 force push 一个提交”的独开源方式，值得分析其 CI/CD 和代码分发策略。
  2. Multica：作为一个结合了“看板/对话/Agent”的新兴 AI 协作工具，其设计思路（将大对话拆解为细颗粒度的 issue + agent 任务）值得关注，尤其是在 Codex 生态下的集成。
  3. Karabiner-Elements 的人体工学键盘深度配置：如何利用它（而非键盘自身硬件）解决 KINESIS 等非 Mac 原生键盘的 Command 键映射问题，是一个极客且实用的技术点。
  4. killaislop.com（https://killaislop.com/）：yetone 制作的“杀死 Slop”网站，可作为观察社区对低质量 AI 内容态度的一个样本。

🧠 Hermes GPT-5.5 观点延伸

中心判断：今天最值得咀嚼的不是“哪个 AI Coding 工具更强”，而是一个更硬的工程事实：AI Agent 的上限越来越不取决于模型智商，而取决于组织有没有能力把“无限生成”变成“可控交付”。

1. 额度焦虑，本质是工程入口失控

群里从早上的“怎么还没重置”，到中午“重置了 ohye”，再到晚上“被富裕的 token 逼疯”，表面看是消费额度的玩笑，实际暴露了 AI Coding 的新瓶颈：算力和 token 变多以后，真正稀缺的变成了好问题、好任务切分、好验收标准。

“每次 token 耗尽都是灵感爆发”很准确。额度限制像一个外部节拍器，逼人收敛问题；额度无限，反而会诱发无目的探索。工程上可验证的判断是：一个 AI Coding 工作流如果没有 issue 粒度、任务边界、上下文清理、测试回路和成本观测，额度越多，越容易把项目推向噪声而不是产出。

这也是 Multica 被评价为“减轻思考压力”的原因。它的价值不只是多 agent，而是把一条巨大对话拆成卡片、评论、委派和局部上下文。换句话说，真正有用的 Agent 产品不是“更会写代码的聊天框”，而是“把人的模糊意图转成可追踪工程对象的操作系统”。

2. “开源了就可信”已经不够了

Grok Build 被讨论时，大家很快从速度、TUI、内容限制转向“是否上传代码”“开源版本是否等于安装版本”。jcode 的后续更典型：浮动 UI 看起来很香，但自动改配置、删软链接、生成 154MB 日志、疑似拉起大量 subagent，这些都不是审美问题，而是安全边界问题。

Agent 工具和普通 CLI 最大区别在于：它不是只执行你明确输入的一条命令，而是在解释目标、探索文件、调用子进程、修改环境。于是工程判断应当升级：评估 Agent 工具不能只看效果演示，要看五件事——权限边界、文件修改审计、后台进程生命周期、日志可解释性、外部网络行为。没有这些，越“自动”，越危险。

3. Emacs 与 Linux 的分歧不是保守 vs 先进

关于 AI 代码版权，群里把 Linus 和 Emacs/FSF 放在一起比较很有价值。Linus 的强硬并不只是“拥抱 AI”，而是 Linux 有维护者分层、责任人 review、商业机构支持和成熟补丁文化。Emacs 社区谨慎，也不只是原教旨，而是 review 资源、法律风险和治理结构不同。

所以问题不是“要不要接受 AI 代码”，而是“谁有能力为 AI 代码负责”。如果一个社区没有足够 reviewer，没有来源追踪，没有贡献声明，没有测试覆盖，那么拒绝 AI 代码可能是理性的；如果有强 review 链路，AI 只是更快的补丁生成器。

可继续实践的方向：给自己的 AI Coding 流程做一份最小治理清单：每个 agent 任务必须绑定 issue、限定目录权限、记录命令与 diff、自动跑测试、人工 review 后合并。先把“蹬额度”变成“可审计产出”，再谈生产力革命。