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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 31.1 发布引发的生态震动

本次群聊最核心的讨论围绕 Emacs 31.1 正式发布展开，持续贯穿全天。以下是各方关注要点：

新版本特性体验与发现

• 群友对 hs-minor-mode 在 Emacs 31 中全面支持 tree-sitter 感到兴奋，认为可以删除冗余包 treesit-fold。
• 有人指出新版 corfu 的 menubar 显示问题，随后发现是 child-frame 变成真实窗口所致，属于升级后的行为变化。
• macOS 平台新增 stipple 支持，群友指出这是 31 才有的能力，此前仅有 emacs-mac 分支支持。Linux、Android、Haiku 则早已支持。
• 有人提到 antinews 功能——用于查看“反新闻”（即已废弃/删除的功能），引发讨论兴趣。

Windows 与 Android 生态更新

• Windows 安装包第一时间发布（emacs-31.1-installer.exe），群友感叹发布速度“很快”。
• Android APK 发布后，一位群友反馈安装即闪退，并追踪到 libemacs.so 的 ELF 文件格式问题。经过排查发现：使用 cp 命令时 copy_file_range 系统调用导致文件从编译目录拷贝至打包位置时内容缺失，与 ZFS 已知问题（openzfs/zfs#17629）类似。维护者连夜定位并计划次日修复，建议先用 API 29 版本。
• 群友讨论了 Termux 被其他 App 调用的签名限制，并分享了自定义签名方案（通过 emacs.keystore 统一签名）及定制教程链接。

开发节奏观察

• 有群友订阅 emacs-diffs 邮件列表后发现“开发速度缓慢”，但另一些人持相反观点，认为近两年大进展很多，指出“90% 的工作其实是在修 lisp 包的 bug”。
• 整体共识：自由软件的迭代需要用户主动参与讨论、提交 patch 并维护后续工作，平台支持不足（如 macOS/Windows）某种程度上是社区参与度的问题。

专题二：Rime 分词技术的实践与边界

围绕 Rime 输入法引擎能否直接用于中文分词，展开了一场持续数小时的技术探讨：

• 有人提出“用 librime 可以直接做分词，不需要依赖其他东西”，并自嘲“我是天才”。
• 有人追问 API 细节，发现公开 API 只能做正向翻译，真正的分词能力来自 LLM 挖掘出的 dictionary API，即间接调用 C++ 侧接口。
• 对比了多种分词方案：
  • Google sentencepiece（基于模型，约 5MB，毫秒级延迟）——适合 TTS 等场景，但群友质疑“谁会为了分词调大模型”。
  • ICU——功能更多，但速度不如专门方案。
  • librime + 词库 + 动态规划——被评价为“有词库之后跑一个动态规划就行了”。
• 实际用途是 org-mode 中的按词跳转（M-f / M-b），比逐个字符移动更高效。
• 此外，有人尝试将 cnws 做成 systemd 服务，但启动太慢。

专题三：Emacs 中文词典与 LLM 辅助学习的争议

• 有人分享用 gptel quick + LLM 当 dictionary 的做法，引发群友对准确性的担忧：“LLM 给我的 etymology 里有错误……有一次发现了明显的错误才意识到不对劲”。
• 讨论了 dictionary.el 接入 dictd 的可行性，以及 mdx/mdd 转换路径。
• 整体结论：LLM 适合辅助学习新领域知识，但用于词源考证等需要严谨的场景时仍需谨慎。

专题四：平台对比与生态选择的“吐槽大会”

• 有人宣布“我要逐渐解绑 mac 了，感觉依赖苹果是坏的，应该多用 emacs 自己的能力”，引发广泛共鸣。
• 反驳观点：mac 在续航、轻薄、生物识别（指纹/人脸）适配、软硬结合体验上仍有优势；Linux 的电源管理和生物指纹适配“依旧很麻烦”。
• Windows 方面：群友吐槽 Win11 索引卡死、体验倒退，有人直言“再烂还能有 Windows 11 烂？”；也有人指出 Win10 EOL（2025-10-14）后，WSLg 等现代开发体验在 Win10 上的支持受限，形成取舍难题。
• 还出现“六边形”价格吐槽：有人 1.1 万买 Mac，半年后加量不加价，再半年后国补，感叹“买都买了，不要在意这些”。
• 印度群友的加入带来了跨文化互动，有人用中文打招呼“各位中國朋友，大家好，我來自印度”，群友热情欢迎。

🔑 关键概念与技术解析

1. stipple：Emacs 的 face 属性之一，可以叠加渲染纹理/图案，如点阵、网纹、斜线、棋盘格。常见用途是缩进参考线（indentation guides），也可表示纹理、禁用状态、占位或调试信息。Emacs 31 首次在 macOS 平台支持，Linux/Android/Haiku 早已支持。

2. copy_file_range 问题：Linux 核心utils cp 默认使用 copy_file_range 系统调用进行文件复制（而非传统 read+write）。在特定文件系统配置下，该调用可能静默产生不完整拷贝（文件内容缺失），导致 ELF 二进制损坏。群友定位 Emacs 31 Android APK 闪退的根因正是此问题，并引用了 ZFS 上的已知 issue。

3. antinews：Emacs 内置功能，用于查看已废弃/删除功能的“反新闻”，类似于“代码考古”工具。新版发布时可用于对比版本差异。

4. frame-hide-title-bar-when-maximized：Emacs 31 中用于隐藏最大化窗口标题栏的配置项。群友通过 window-size-change-functions hook 解决了最大化时自动恢复 undecorated 状态的问题，并给出了自定义 elisp 片段。

5. dictionary API（librime）：librime 引擎内部用于分词/词典查询的 C++ 侧接口。公开 API 主要做正向翻译，分词能力需通过挖掘内部接口获取。

6. WSLg：Windows Subsystem for Linux 的 GUI 支持特性，允许 Linux GUI 应用直接显示在 Windows 桌面。群友指出该功能要求 Win11，Win10 虽有民间兼容方案但非完整支持。

💎 碎片知识与金句拾遗

• “谁会为了分词调大模型啊（）”——对 sentencepiece 用于简单分词场景的调侃。
• “自由软件就是这样的一种情况——你想要什么功能可以，但是你要参加讨论发 patch、维护后续工作。”——对开源贡献机制的精辟总结。
• “一个人能搞明白一个平台的开发就已经属于很厉害的了”——对多平台维护难度的体认。
• “用多了 Windows 我感觉我什么都能接受了”——对 Windows 生态的无奈吐槽。
• “肉翻”——回答“怎么秒开网络问题”时的戏谑答案。
• “买都买了，不要在意这些”——对电子产品价格波动的释然。
• “我感觉大部分时候 macos 自己都在给我添麻烦”——平台体验的犀利评价。
• “我感觉很多中文的东西都可以走 rime 处理”——Rime 作为中文处理基础设施的设想。
• “LLM 给我的 etymology 里有错误……我都不敢用 LLM 生成了”——对 AI 生成内容严谨性的警惕。
• “这个显示的方式让我有尝试 gnus 的冲动”——某群友被群内 gnus 截图种草。
• “我买了一台 1400 的二手 mac mini”“1600 买的全新的（以旧换新+补贴+教育优惠）”——用旧的别人送的耳机换来千六的 Mac mini，群友调侃“有点意思”。
• 有人分享用 dictionary.el 接入 dictd 的想法，认为“你需要把 mdx 转换成 dictd 支持的格式”，并感叹“我觉得很炫酷”。
• 关于开发节奏的争议：一边是“每天 commit 数可能没有 emacs-devel 里邮件数多”，另一边反驳“这两年大进展好多”，最终结论是“90% 的工作其实是在修 lisp 包的 bug”。
• “居中文本的另一个办法”——有群友分享自定义 Emacs 居中文本配置，并附上截图。
• 关于字体覆盖问题：“你的等宽字体覆盖还不够”，提示需要调整字体 fallback 配置以解决字符对齐问题。

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

1. Emacs 31 新特性系统评测：特别是 macOS stipple 支持、tree-sitter 整合程度、Windows 安装包改进。建议阅读 Mastering Emacs 的 What's New 系列文章，并跟踪 antinews 查看废弃功能。

2. librime 分词 API 挖掘：有人成功通过 dictionary API 实现中文分词，可用于 org-mode 的 M-f/M-b 词级跳转。思路极具 hack 精神，值得深入探索其边界与稳定性。

3. Emacs Android 定制方案：通过统一 keystore 签名 + 定制 Termux 的方式构建专属 Emacs 移动环境。群友分享了参考教程（marek-g.github.io 的 Emacs on Android 系列），并已发布自定义 release（ShineBreaker/emacs-mobile）。注意追踪即将发布的 libemacs.so 修复版本。

4. copy_file_range 静默损坏问题：该 bug 影响面广（非仅 Emacs），值得关注其在 coreutils 与文件系统层面的修复进展，并思考如何在打包流程中规避此类风险。

5. gnus 邮件/新闻客户端配置：群友展示用内置 gnus 订阅 emacs-diffs 邮件列表的效果，并自制客户端优化展示。gnus 作为 Emacs 内置的联邦网络客户端，仍是值得投入研究的对象。

观点延伸

当天最值得咀嚼的，不是 Emacs 31.1 增加了多少功能，而是成熟软件如何把分散的复杂度逐步收回核心，再把它变成稳定、可替换、可验证的基础设施。hs-minor-mode 接管 tree-sitter 折叠、macOS 获得 stipple 支持、升级后可以删除兼容代码，这些变化的共同价值不是“功能更多”，而是用户以后少装一个包、少维护一段 workaround。

1. 平台支持首先是一条责任链

Android 包闪退的排查很有代表性：问题最终落在 cp 使用 copy_file_range 时造成动态库内容不完整，而不是 Emacs Lisp 或 Android 界面本身。一个普通的复制动作，实际跨过了文件系统、coreutils、构建环境和发布产物几层边界。

这说明“编译成功”与“发布正确”是两件事。二进制发布至少应验证文件大小、哈希、ELF 可加载性，并在目标设备上启动；关键复制步骤还应保留传统读写路径作为 fallback。自由软件用户参与维护，也不只是提需求，而是把一次平台故障沉淀为可复现的测试和构建约束。

2. 能调用，不等于形成了可依赖的接口

Rime 分词的讨论从“librime 可以直接做”追到 dictionary API 和 C++ 内部接口，恰好暴露了 AI 辅助开发的一个陷阱：代码能跑，不代表边界已经稳定。对于 org-mode 的 M-f/M-b，词库加动态规划可能已经足够；真正重要的是延迟稳定、结果可解释，并且失败时还能退回字符级移动。

如果内部接口确实有价值，就应该包成一个小适配层，固定输入输出，写混合中文、英文、符号文本的回归测试，而不是把隐藏接口直接散落在配置里。否则今天的“天才 hack”，很容易变成下一次升级时的隐性债务。

3. LLM 适合探索，不应直接充当事实底座

“用大模型当 dictionary”适合快速获取解释、例句和新领域线索；但 etymology 被发现错误后，边界就清楚了：探索性解释和可核验事实不是同一种数据。词源、同源词、专业定义应优先来自正经词典或可追溯数据库，LLM 负责整理、比较和提出待查问题。

可继续研究/实践： 做一个小型 Emacs 31 实验：为 Android 打包链加入产物完整性检查，把 Rime 分词封装成可替换后端，并将 LLM 词典结果放入“待验证”层。观察的标准不是“能不能跑”，而是版本变化、接口失效或内容出错时，系统能否明确失败并快速恢复。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI Agent 编排与“中间层”架构的深度实践

群内多位成员分享了 AI Agent 编排的实践经验，核心痛点与解决方案非常清晰：

• 痛点：上游大模型（如 GPT-5.6、Sol）token 消耗高、决策效率低，下游子 Agent 无法充分利用上下文。有成员尝试用本地小模型做“中间层”，负责精简上下文而非决策，但“精简本身就会消耗上游 token”，且并发编排时状态管理复杂（“n 个状态，非常混乱”）。
• 解决思路：有成员提出“用协议来抽象复杂度”，而非依赖机械的编排器；也有成员分享用 SQLite 存储上下文 ID 传给下游以降低 token 消耗。Herdr 的杀手级场景被举出——Agent 能自动跨项目传递经验（“把总结好的经验发过去了”），被认为“AI Native 的沟通方式”。此外，成员们对 Apache Maka、Pi Harness V2 等编排框架进行对比，并讨论对抗性审查（多个上游 Agent 互相审查）的可行性。
• 结论：多数人认同“自动编排是不存在的，只能根据项目定制中间层”，且“编排器的终极形态是协议”。这也呼应了成员提出的 spec-agents 方法论——用“本体论”维护组件定义，避免文档污染代码。

专题二：终端模拟器（Terminal Emulator）的深度对比与配置

群内爆发了一场关于终端模拟器的“争论”，对比了 kitty、foot、ghostty、wezterm 等：

• kitty：功能丰富、光标动画体验佳，但“不支持触屏操作”；有成员指出其“把内容居中显示”的特性可以在配置中关闭。
• foot：原生、简单、响应快，延迟低，但在光标动画和定制性上不如 kitty。有成员吐槽“foot 会显示不足一行的空行”，但被回应“配置里可以关”。
• 下拉式终端：多位成员认可这种交互（quake 风格），并提到在 Hyprland 下可以利用“特殊工作区”让任何 app 实现这种效果。有成员分享自己的用法：“用 kitty 开两个 tab，一个 tmux 日常工作，一个 herdr 做 agent 协作”。
• 核心观点：终端不仅是工具，更是“情绪价值”的来源（光标动画被赞“太帅了”）。有成员坚持用 kitty 而非 ghostty，理由是“自带 UI 的不适合跑在窗口管理器上”。

专题三：AI 编码工具链的“翻车”现场与吐槽

群内对多种 AI 编码工具和模型表达了强烈不满：

• OpenCode-Go 模型：有成员吐槽“没一个好用的”，“全部蠢死了”。具体案例：DeepSeek Flash“思考了 10 分钟，一行代码没写”；GPT-5.6“蠢得要死”；还有 AI 用 omp edit 时误删了 Emacs 的 deftheme 定义，导致主题失效。
• Agent 状态恢复：多位成员遇到 Agent 在打断后“接续到十几个小时前的任务”，GUI 客户端尤其严重（如 goal 需要 /goal resume 手动恢复），有人调侃“敲个‘继续’根本没用”。
• 通用策略：有人分享“准备好一段话时不时发给 Sol 提醒它”，以此对抗模型“堆砌测试、脱离原生自我实现”的倾向。

🔑 关键概念与技术解析

1. 中间层（Middleware/Orchestrator）：在 AI Agent 编排中，负责精简上下文、调度下游子 Agent，而非决策。其核心挑战是“精简本身就会消耗上游 token”，且“编排器需要实时”，否则会堵塞流程。
2. 对抗性审查（Adversarial Review）：让多个上游 Agent 互相审查对方的输出，以发现问题和错误。类似 Claude 为每个 subagent 配备审查员的做法。
3. 下拉式终端（Quake-style Terminal）：按快捷键呼出/隐藏的终端窗口，适合快速调用，可通过特殊工作区在任何 app 上实现。
4. 本体论（Ontology）：在 spec-agents 方法论中，用于维护“组件”的定义，确保文档与实践绑定，避免文档污染代码。
5. Composition vs Hook：成员提出用 Ruby 编写类似 Borg 的子模块包管理时，认为“组合（composition）比钩子（hook）好得多”，因为它能更好地支持并行和自定义工作流。
6. Herdr：一款 AI Native 的 Agent 协作工具，支持跨项目传递经验（Agent 自动查找并发送消息），但被吐槽“更耗 token”。
7. Telega-server 与 Emacs 版本绑定：Telega-server 的编译与 Emacs 版本绑定，升级到 Emacs 31 release 后可能不兼容，需要重新编译。

💎 碎片知识与金句拾遗

• “kitty 真好用啊，感觉以前用 foot 的时候都在过苦日子。” —— 对 kitty 光标动画和定制性的高度评价。
• “情绪价值这一块给的还是非常到位。” —— 谈论光标动画时的生动观点。
• “没想到，色影无忌这个老牌论坛也消失了。” —— 感慨老牌技术社区的消逝。
• “接项目之前必须要有明确的需求文档。” —— 从一次失败项目经历中总结的教训，强调“反复要需求文档，客户一直说没有”。
• “能买到的 SaaS 服务就不要自己重造轮子。” —— 推荐 bugherd 用于线上预览标注，可省去自建轮子的精力。
• “中间层不负责决策，只是编排器而已。” —— 对 AI 编排架构核心原则的精辟概括。
• “文档太多了会污染上下文，测试太多也一样污染上下文。” —— 对 AI 编码上下文管理的反思。
• “omakase，如果你什么都不知道，那就直接用我的精选，如果有能力你就自己替换。” —— 对 DHH 风格的 Omarchy 发行版的调侃式解读。
• “fable 的开销太恐怖了，刚写的 spec 还没 review 完 5h quota 就干了。” —— 吐槽 AI 工具的高配额消耗。
• “Finally Vim got a usable Text Editor.” —— 引用自 Tsoding 的推文，嘲讽 Vim 的文本编辑体验。
• “特斯拉 FSD 入华生变，上海数据中心被曝人去楼空。” —— 分享科技行业动态，感叹“6.4 万白花了”。

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

• Herdr 的跨项目 Agent 协作机制：其如何实现 Agent 之间自动传递经验，以及是否可配置为“省 token”模式。有成员提到“你需要根据自己的项目定制中间层”，值得进一步探究。
• spec-agents 方法论：基于“本体论”维护组件定义，避免文档污染代码的实践。链接：https://github.com/yibie/SPEC-AGENTS.md
• 基于协议的 Agent 编排：有成员提出“用协议抽象复杂度”而非依赖编排器，可关注 Apache Maka（https://github.com/apache/maka）等编排框架的进展。
• 本地小模型做中间层：用于精简上下文、管理 session 的本地模型（如 nowledge 的简化版），以及如何用 SQLite 存储上下文 ID 降低 token 消耗。
• Emacs 31 与 telega-server 的兼容性问题：Windows 10 下 shell-command-to-string 返回空值，疑似与 Emacs 版本绑定有关，可深入排查。

观点延伸

当天最值得咀嚼的判断是：Agent 系统的瓶颈正在从“模型会不会写代码”转向“系统能否让多个不完全可靠的执行者共享同一组可验证状态”。这也是中间层、harness、需求文档和跨项目经验传递看似不同、实则同一类问题。

1. 编排器不该先追求聪明，应该先规定交接格式

群里从“压缩上下文”谈到 SQLite 按 ID 保存，再谈到并发、审核和“终局是协议”，关键不在于是否再加一个模型，而在于下游接收的到底是什么。自然语言摘要往往既贵又不可复用；更稳的交接单位应是任务 ID、目标、输入快照、已知约束、产物位置、验证结果和待审查事项。这样上游不必重复搬运全文，下游也能按需读取原始上下文。协议的价值不是消除复杂度，而是把隐含复杂度变成可观测字段。先做项目内最小协议，再谈通用编排，通常更容易验证。

2. “模型很蠢”往往是恢复和编辑边界没有被系统化

主题定义被误删、Agent 被打断后继续旧任务、模型堆砌测试却脱离原生实现，这些并非单纯的模型智力问题，而是 harness 没有把状态和权限说清楚：当前任务是否仍有效，哪些文件允许改，哪些符号必须保留，什么条件下只能停下来请求确认。工程上可以用硬约束验证：编辑前后检查关键结构，所有变更先看 diff，恢复必须经过明确的状态转换，失败后可回滚。模型不必永远正确，但系统必须让错误短链路、低代价地暴露。

3. 文档不是越少越好，而是要分层、可执行

群里对需求文档、CI/CD、composition 以及 spec-agents 的讨论，说明“文档污染上下文”真正反对的是无差别灌输，不是文档本身。当前契约、验收命令和不可违反的组件定义应靠近执行；历史决策和经验则按需检索。

可继续研究或实践：选一个小项目，对比直接对话、上下文压缩、按 ID 读取工件三种协作方式，记录 token、延迟、返工、错误恢复和审查发现数。只有把这些指标跑出来，才能判断所谓 AI Native 是真的降低了协调成本，还是只是把成本藏进了另一层。