外观
Emacs 社区日报 2026-04-22
约 4162 字大约 14 分钟
2026-04-22
自动整理自 Telegram 讨论组,每天更新。内容为 AI 摘要,仅作信息索引与回顾。
Emacs 中文讨论组
🎯 核心热点与专题探讨
【专题】输入法:效率、健康与未来
群内围绕输入法的选择展开了激烈讨论,核心矛盾在于极致效率与健康/易用性之间的权衡,并延伸至AI语音输入的未来。
效率派:追求极致输入速度与盲打体验。
- 痛点:全拼重码率高,依赖选字,影响思维流暢性。
- 解决方案:
- 字根输入法(五笔、仓颉):重码率极低,可实现精准盲打。但学习曲线陡峭,需要记忆大量字根和拆字规则。
- 双拼+形码(小鹤音形、自然码+墨奇码):在双拼(声母+韵母各一键)基础上,增加字形编码(形码)以区分同音字,兼顾了拼音的易学性和低重码率。被认为是当前效率与学习成本平衡较好的方案。
- 顶功输入法:被提及为“很爽”的极客选择,通过特定规则(如两笔)进一步压缩码长,实现超高输入速度,尤其适合方言或拼音不标准用户。
健康/易用派:关注输入行为对身体的长期影响及跨平台无痛使用。
- 痛点:长时间编码导致手部劳损(如RSI);不同设备间输入法体验割裂。
- 解决方案:
- 为健康换输入法:有成员因手痛从全拼换用五笔,因击键次数减少而缓解症状。双拼也被认为是减少击键的选项。
- 推荐户外活动:“Emacser就应该多爬山,健康点,多活几年,才能看到Emacs的终局。” 强调身体是革命的本钱。
- 推崇跨平台方案:高度推荐 Rime(中州韵输入法引擎)及其衍生版本(如 macOS 的
weasel,Linux 的fcitx5-rime)。因其开源、可深度定制、词库纯净且配置可跨平台同步,能实现“全端无折腾无痛使用”。
未来派:看好AI驱动的交互方式。
- 观点:认为“这个时代该入坑AI支持的语音输入”。讨论了基于 Whisper 模型的语音输入法以及 豆包输入法 的语音转文字功能,指出其准确率高,且能与AI对话形成纠错闭环,代表了输入方式的演进方向。
🔑 关键概念与技术解析
- Rime(中州韵):一个开源、跨平台的输入法算法框架。用户可通过编写配置文件自由定制输入方案(如双拼、五笔)、词库和外观,是极客和隐私意识用户的挚爱。
- 双拼:一种拼音输入方案,将汉语拼音的声母和韵母分别映射到单个按键上,任何音节只需两次击键即可输入。
- 形码:在音码(如拼音)基础上,根据汉字的字形结构(偏旁、笔画)提取的辅助编码,用于区分同音字,显著降低重码率。
- 顶功输入法:一类高效的形码输入法,通过巧妙的编码设计,使得输入时无需额外按键确认(顶格上屏),从而提升速度。“两笔”是其中一种方案。
- Fcitx5:Linux 系统下一代输入法框架,模块化设计,对非 QWERTY 键盘布局(如 Dvorak)支持更好,常与 Rime 搭配使用。
- Karabiner Elements:macOS 上强大的键盘键位重映射工具,可用于解决系统级输入法切换的 Bug。
- Whisper:OpenAI 开源的自动语音识别(ASR)模型,以其高准确率和多语言支持著称,常被用于构建本地语音输入工具。
💎 碎片知识与金句拾遗
- “打游戏跟人对骂你发三句对面才发一句” —— 形象地说明了掌握高效输入法的“实战”优势。
- “雾凇拼音的作者居然 24 年还去跑滴滴了” —— 揭示了即使做出优秀开源工具(Rime 的流行配置方案之一)的开发者也难以靠此维生的现实。
- “输入法这个本来也没什么经济价值” —— 一句略显无奈的行业洞察。
- “每天多念几遍黑椒牛柳” —— 针对平翘舌不分用户的实用(且有趣)发音练习建议。
- “gboard 任何輸入法都是 qwerty, 這個非 qwerty 用戶很不友好” —— 指出了 Gboard 对使用 Dvorak、Colemak 等键盘布局用户的不友好性。
- “我就特别不爱用 npm 安装,除非是没办法。环境稍微有点变化就可能出错” —— 道出了许多开发者对 Node.js 生态依赖管理复杂性的共同吐槽。
- “人生一场,手嘴都要兼顾,岂能厚此薄彼。都体验过,才不枉来人间一趟。” —— 将技术讨论升华到了生活哲学。
🛠️ 值得深入研究的点 (Follow-up)
探索基于 Whisper 的本地化语音输入工作流
- 研究什么:如何利用 Whisper(或类似开源 ASR 模型)搭建一个低延迟、高准确率、完全本地的语音输入环境,并与编辑器(如 Emacs/VSCode)深度集成。
- 怎么研究:从
whisper.cpp等高效推理项目入手,研究其 API 和流式处理能力。尝试结合voice2json或自定义脚本,实现“语音 -> 文本 -> 插入编辑器”的自动化管道。
深度定制 Rime 以实现“终极”输入方案
- 研究什么:针对个人方言习惯(如 n/l 不分)和特定领域词汇(编程、学术),定制一套融合双拼、顶功形码、英文混输、符号快速输入的无缝方案。
- 怎么研究:仔细阅读 Rime 官方文档(
librime),研究default.custom.yaml和*.schema.yaml的配置语法。参考“雾凇拼音”、“小狼毫”等社区配置,学习其模块化设计思想,最终构建自己的私有配置仓库。
评测新兴的、与编辑器深度集成的工具
- 研究什么:聊天中提到的原生支持 Emacs 跳转的 PDF 阅读器 Galley。对比其与
sioyek、okular在学术阅读、批注、与参考文献管理工具(如 Zotero)联动方面的体验差异。 - 怎么研究:实际安装并使用 Galley,测试其反向搜索(从 PDF 跳回 Emacs 中对应的 LaTeX/Org 源码)的稳定性和便捷性。尝试编写或寻找现成的 Emacs 插件,以扩展其与 Org-mode noter 等插件的协作能力。
- 研究什么:聊天中提到的原生支持 Emacs 跳转的 PDF 阅读器 Galley。对比其与
Emacs 轻聊讨论组
🎯 核心热点与专题探讨
专题一:Kimi K2.6 vs. 第一梯队模型(Claude 4.7, GPT 5.4)——国产大模型的逆袭?
本群对国产模型Kimi 2.6进行了深入、多维度的实战评测,引发了关于“模型能力 vs. 实际体验 vs. 性价比”的激烈辩论。
- 支持派观点(Kimi 2.6更好用):
- 代码能力实测“比5.3 Codex强”,甚至“代码能力比肩GPT 5.4”。
- 写Scheme代码不再胡编乱造函数,准确性显著提升。
- “出活”效率高:如果给出了完整方向,Kimi参考执行的效果甚至优于GPT 5.4。
- 综合体验“真的好用了”,有人甚至表示因此放弃使用Claude。
- 冷静派/反对派观点(不如第一梯队):
- “思考时间太长”,和GPT的X-High模式在一个时间量级,“效果却和High/Medium差不多”。
- 跑分只能“打4.6 Opus”,实际能力与跑分脱节,“并没有追上”顶尖模型。
- 同样是“出活”,比Opus 4.6 Max慢20%。
- 讨论中暴露出对国产模型“跑分强、实际拉”的普遍不信任感。
- 情感与价格因素:
- Kimi的价格是讨论焦点,159元档位被评价“耐烧”,但用户普遍认为“耐烧没用,模型能力没追上”。
- 部分用户因Kimi是“唯一用的起的”而选择,尤其其API被认为最便宜。
- 与咸鱼上的GPT Plus等渠道进行了对比,性价比成为重要考量。
痛点:用户渴望一个“出活快、准、便宜”的模型。当前顶尖模型(Claude, GPT)价格上涨或服务收紧(Pro套餐去除Claude Code,GPT Pro涨价),用户充满被“收割”的焦虑。
结论:Kimi K2.6被群友认为是在特定场景(如遵循完整方向执行)下的强力竞争者,但在交互速度和复杂推理上与顶级模型存在差距,形成了“够用,但不惊艳”的共识。
专题二:Agent工具链的“内卷”与选择困境 —— pi-mono, opencode, claude code
群内围绕多个开源的AI编程Agent工具(pi-mono, opencode, ohmyopencode等)展开了一场深度对比和吐槽大会,反映了当下“AI coding assistant”生态的混乱与机遇。
- 讨论焦点:谁是“最好”的底层框架?
- pi-mono: 被视为“最好的感觉”,但“看完不能立马上工”。API变化快,不尊重XDG规范(往
~里塞垃圾文件),插件生态配置硬编码,拒绝支持XDG,让多个用户感到恼火。 - opencode/ohmyopencode: 完成度高,接本地模型比claude code好用。其命名和机制似乎有躲避审核的“奇技淫巧”(修改关键词如“μ”)。
- claude code: 官方版本强大但商业限制多。开源版 (
instructkr/claude-code) 被视为值得研究的对象,是“接下来可以用的编排器和runtime”的基础。
- pi-mono: 被视为“最好的感觉”,但“看完不能立马上工”。API变化快,不尊重XDG规范(往
- 痛点分析:
- 配置与兼容性地狱:用户需要理解多套配置系统(~/.pi、ccs、local settings等),使用和切换成本极高。
- 更新引发的“过拟合”:任何开源工具的更新都可能引入新的Bug,修复缓慢,导致用户不得不维护自己的fork。
- “封号”的阴影:讨论中穿插大量关于账号被封、反向代理、审核规避的“地下斗争”。Cliproxy相关项目被发律师函、GPT账号大量被封,反映了厂商对代理行为的打压。
- 衍生的路径选择:用户苦于在“用起来麻烦但强大”(如makefile)和“功能少但配置简单”(如just)之间做选择。Makefile被普遍认为是“一步到位的选项”,但语法麻烦。
结论:当前AI Agent工具链正处于快速发展期,但伴随着设计理念冲突(如XDG vs 硬编码)、商业化与开源的博弈,以及严重的学习和配置成本。
🔑 关键概念与技术解析
Kimi K2.6 / Claude 4.7 / GPT 5.4 / Codex:讨论中频繁出现的模型代号。Kimi是北京月之暗面公司的模型,K2.6是其最新版本。Opus 4.7和Codex 5.4分属Anthropic和OpenAI。这些是当前AI编程Agent背后最顶级的“大脑”。
XDG Base Directory Specification:一个规范Linux/Unix系统下配置文件存放位置的约定(如
~/.config)。不遵守此规范的软件(如pi-mono)会把大量.开头的文件直接塞进用户的家目录(~),被硬核用户深恶痛绝。pi-mono / opencode / oh-my-pi:都是开源的AI代码助手项目,旨在提供比官方Claude Code或Cursor等更多控制权的编程代理。它们的功能和设计哲学各异,代表了当前开源Agent项目的不同流派。
ACP / MCP:Agent Communication Protocol(代理通信协议)和Model Context Protocol(模型上下文协议)。这是讨论中提到的Agent之间以及Agent与外部工具交互的标准协议,类似于AI世界的“HTTP”,用于实现Agent之间的编排和工具调用。
mu(μ):在讨论中被用作“Pi”(π)的替代词,用于命名开源项目(如pi-mono -> μ-mono)。这是一个代码层面的“小把戏”,旨在规避厂商(如OpenAI)对“pi”或特定关键词的API审核或限制。
Claude Code SDK / Agent-shell:前者是官方提供可编程化调用Claude Code的接口,后者是一个Emacs插件,允许在Emacs中使用各种Agent(通过ACP协议),代表了一种“集成所有Agent”的终极IDE愿景。
ccs:一个切换不同AI模型配置的命令行工具。讨论中提到,claude code对ccs的支持切换“成功了一次”,体现了当前工具间整合的不稳定和脆弱。
💎 碎片知识与金句拾遗
关于模型体验的对比:
- “我的评判标准是【出活否】。” —— 一句极简但极其务实的工程美学。
- “gpt 5.4 xhigh 喜欢直接删文件重写...” —— 来自高手的尖锐吐槽,点出前沿AI模型的“暴力”倾向。
- “4.7 真的让我恶心到了。我已经放弃了。” —— 对Claude 4.7的失望溢于言表。
关于Agent工具链的“日常”:
- “啊?你看了项目版本号和变更日志。” —— 当用户抱怨变化太快时,另一人直接给出了最硬核的“解决方案”,充满了极客式的幽默。
- “你的情绪价值够够的。要不你看看claude 或者 codex 的 sdk ?” —— 讽刺中带着务实,用“情绪价值”调侃抱怨,然后直接给出最佳研究方向。
- “我恨任何往我
~里塞垃圾 dotfile dir 的软件。” —— 一位 “XDG纯血论”者的呐喊。
关于行业生态与省钱之道:
- “还不如咸鱼买gpt plus” —— 揭示了地下“API共享”经济的普遍性,体现了AI定价的矛盾。
- “a➗ 真把自己当回事了。” —— 对Cursor新定价策略的蔑称,充满江湖气。
- “...讨论一下,然后把 pi 关键词改成 μ,讨论完毕自动修改就可以躲过审核了...” —— 一种非常“聪明”的对抗式编程思路,展示了开发者如何与AI厂商的审查机制“斗智斗勇”。
- “Ai太坏了 导致了是个人就能写代码。” —— 对开源项目质量参差不齐的精准嘲讽。
冷门工具推荐:
just:比Makefile更简单的Task Runner。makefile + guile: 指出Makefile中可以内嵌Scheme语言(Guile),展示了GNU系统的深厚功力。oh-my-pi: 一位用户针对pi-mono的改良分支,旨在增加XDG支持,但维护者合并缓慢。
🛠️ 值得深入研究的点 (Follow-up)
1. 研究 instructkr/claude-code(开源版Claude Code)
- 为什么值得研究:它是官方Claude Code的去商业化版本,设计上更注重可定制性和开发者控制。其SDK的实现是实现“自定义编排器”和“Agent运行时”的绝佳起点。
- 如何研究:
- Fork仓库,阅读其核心架构和系统提示词生成的逻辑。
- 尝试将其作为依赖集成到自己的IDE或工作流中,而非直接使用其CLI。
- 关注其ACP/MCP协议的实现,看它如何与外部工具(如本地LLM)交互。
- 跟踪其更新日志,理解其设计演进,特别是关于“配置管理”(如XDG支持)的变更。
2. 实验 agent-shell 的 “Agent-to-Agent” 编排
- 为什么值得研究:这代表了“终局方案”的雏形——在一个统一界面(Emacs)内,通过标准协议编排不同能力的AI Agent。讨论中提到了状态机和Org Agenda的集成,极具想象力。
- 如何研究:
- 搭建Emacs环境,安装并配置
agent-shell。 - 尝试其内置插件,特别是
meta-agent-shell,理解它的编排模型。 - 提出问题:如何将不同的AI模型(Kimi, Claude, GPT)作为不同的“Agent”接入,并设置它们之间的任务依赖关系?
- 看看社区中关于为
agent-shell编写pi-mono或opencode接口插件的讨论,这是连接不同生态的关键。
- 搭建Emacs环境,安装并配置
3. 探索 Makefile + Guile 的高级用法
- 为什么值得研究:所有讨论最终都回归到
Makefile作为最强大、最通用的构建和任务编排工具。很多人因为“语法难受”而逃离,而事实上其中的Guile集成(用Scheme语言写Makefile逻辑)则是一个被严重低估的顶级能力。 - 如何研究:
- 阅读GNU Make手册中关于Guile集成的章节。
- 尝试用Guile写一个能自动处理依赖、并行执行、甚至内置测试框架的Makefile。
- 将AI生成的复杂Makefile逻辑(如条件编译、动态目标)用Guile重写,使其可维护。
- 思考:如何将
just的简洁性与Makefile的宏能力结合?这可能是终极的构建解决方案。
