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

Emacs 社区日报 2026-08-26 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Telegram Bot 生态的「人机共舞」——从 llmbot 到 Rich Messages

群内围绕 Sydney AI（一个聚合多模型、支持自定义命令的 Telegram 机器人）展开了大量讨论，并由此延伸到 Telegram 客户端生态的演进。

痛点与现象：

• 群友 vritser 担心 bot 刷屏，询问能否默认折叠回复。由于 Telegram Bot API 本身不支持真正的"折叠"，群主（老风扇）直接回应"不能，你们用的恰当点吧"。
• Matrix 用户 φuzy 抱怨"看不到 bot 的回答"，随后被告知：电报 bot 无法阅读其他 bot 的消息，但通过 BotFather 修改 Group Privacy Mode 设置即可解决（让 bot 读取群内所有聊天记录）。
• Telegram X（基于 tdlib）用户遇到 unsupported message，经排查发现是客户端对 Rich Messages 新特性支持滞后。群友给出解决方案："换用官方 Telegram 客户端即可"。

Rich Messages 的细节：

• 群友提到 "手动写 HTML 渲染不出来"，有人解释：这是 Telegram 的 Rich Messages 特性（Bot API 7.3+），需要新版客户端才能渲染。目前只有 Telegram Premium 用户和 bot 可以使用该特性发送富文本。
• 非 Premium 用户可以用 @richmsg_bot "曲线救国"，或者通过 inline 输入框触发（但 inline 有 256 字符输入限制）。

llmbot 的配置心得：

• 老风扇介绍了完整命令体系：/ai（当前 context）、/newchat（新 context）、/ask（临时 context）、@grok（群内最近 50 条消息为 context），并支持 .se/.nose 开启/关闭搜索。
• 通过 /macrohelp 展示了模型选择宏：!gpt、!claude、!gemini、!deepseek、!grok、!kimi、!qwen、!glm 等，以及 !xhigh、!think、!file、!rich 等调节参数。
• 值得注意的细节：群友尝试用 /ask .qwen .glm .fable 你们是什么模型 同时调用多个模型对比回答，结果发现各个模型都能准确自报家门（如 Claude Fable 5、GLM-5.3、Qwen 3.8 Max），展示了多模型并行对比的工作流。

专题：Emacs 配置之困——从 user-lisp 到 TRAMP 安全

zdn 的配置困境：

• zdn 在群内求助："我的 emacs 配置放在 user-lisp 目录，为什么 emacs 一起就疯狂吃资源还不启动呢"。他误将 @Ritornello（一位真人）当成了 bot，经过一番乌龙后，被建议用 emacs --debug-init 进行 trace 排查。
• 群友调侃：Matrix 转发机器人的消息接收不完整，导致 zdn 看不到 bot 的回答。

Emacs TRAMP 的安全通告：

• 群友 κόσμος 贴出 CVE-2026-79992，指出 Emacs TRAMP 也存在 CVE（远程文件访问相关安全漏洞），引发关注。

M-x doctor 的"AI 化"畅想：

• 群友提到付费的 protesilaos.com/coach/ 服务，有人建议先尝试免费的 M-x doctor。
• 随后有人提出："怎么没人做个 llm backend 的 M-x doctor"，群友纷纷赞同，认为"自己搓一个应该不难"。这反映出将传统 Emacs 工具与 LLM 结合的趋势。

🔑 关键概念与技术解析

• Rich Messages：Telegram Bot API 7.3+ 推出的富文本消息格式，支持 expandable blockquote（可展开引用块）、多级标题、代码高亮等。目前仅 Telegram Premium 用户和 bot 可以使用，需要客户端支持（官方 Telegram 客户端已支持，Telegram X 因 tdlib 限制暂时无法渲染）。
• messageEntityBlockquote：MTProto 中表示"可折叠引用块"的原始实体，通过 collapsed 标志控制默认收起状态。是 Telegram 实现"collapsible text"的底层机制。
• Group Privacy Mode：Telegram bot 的隐私设置。默认开启时 bot 只能看到被 @ 的消息；关闭后 bot 可以读取群内所有消息，是解决"bot 无法阅读其他 bot 消息"的开关。
• tdlib：Telegram Database Library，Telegram X 等第三方客户端基于此库实现。由于 tdlib 对部分新消息类型的支持滞后，会出现 unsupported message。
• dsh：群友 vritser 提到的工具（可能是一个 shell 相关的项目），另一位群友尝试用它生成 agent-shell 集成，但"没跑起来"。

💎 碎片知识与金句拾遗

• Emacs 最新版本：通过 bot 的搜索功能确认，GNU Emacs 31.1 于 2026 年 8 月 24 日 发布。这是一个很好的示例，展示了"有无搜索对回答时效性问题的影响"。
• "z.ai 的域名就很厉害了"——群友对 z.ai 域名（智谱 AI 的官方域名）的惊叹，隐含对 AI 公司域名资源的调侃。
• "国内蒸馏 gemini 大王"——群友对某国内 AI 模型的戏称，暗示其可能是基于 Gemini 的蒸馏模型。
• "坚决不用微信结果微信还是找上门了"——群友吐槽微信小程序生态的封闭性，而 Telegram 的"小程序很开放"。
• "邮件列表驱动的开发都这样"——回应某话题时的一句概括，指出邮件列表驱动开发模式的常见特征。
• "我是人"——zdn 误 @ 真人用户时，对方的一句简单回应，成为群内小插曲。
• "老风扇自己的 bot，还是公开的？"——群友询问 llmbot 的归属，得知是"朋友做的"，并透露"里面有些 api 是我在掏钱"，随后老风扇宽慰大家："这个不要怕，用不多的"。

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

• LLM backend 的 M-x doctor：群内提出的"用 LLM 驱动 Emacs 的 M-x doctor"的想法，属于将传统 Emacs 工具与 AI 结合的潜力方向，值得关注是否有开源实现出现。
• Telegram Rich Messages 的自动化渲染：Telegram 官方客户端已支持 Rich Messages，但 Telegram X 等 tdlib 客户端尚未跟进。未来第三方客户端的兼容性改进，以及如何利用 expandable blockquote 做群聊折叠/收起，都是值得跟踪的方向。
• Emacs TRAMP 的 CVE-2026-79992：具体漏洞细节未展开，但涉及 Emacs 远程文件访问的安全问题，建议关注 NVD 或官方公告，评估自己的配置是否受影响。

观点延伸

当天最值得咀嚼的，不是某个模型又多会回答，而是一个更基础的判断：AI 工具进入真实社区后，决定体验的往往不是模型能力，而是“消息能否被看见、理解、控制，并且不打扰别人”。这也是为什么同一个 bot 在不同客户端、不同权限和不同使用方式下，会呈现出完全不同的产品质量。

1. AI 功能的交付链，比模型本身更长

Rich Messages、可展开引用和 bot-to-bot communication 的讨论说明，功能不是“API 有了就完成了”。它至少要经过协议、客户端实现、转发桥接和群权限四层。任何一层缺位，用户看到的就可能是 unsupported message、收不到回复，或只能看到不完整的内容。工程上不能把兼容性问题甩给用户一句“换官方客户端”：更稳妥的设计是能力探测、普通文本降级、关键内容不依赖富文本才能读懂。富文本应该改善信息密度，而不能成为信息可达性的单点故障。

2. 群里的 bot 首先是注意力基础设施

“能不能默认折叠，感觉刷屏”其实比“能不能接更多模型”更接近产品核心。一个 bot 读取最近消息、处理跨 bot 可见性、并行调用多个模型，都会增加可见输出、上下文边界和费用的不确定性。当天出现的 .se、模型宏、/ask 临时 context 以及 per-user 设置，已经提供了控制面的雏形；下一步应把它做成默认克制的交互：被点名或回复时才工作，长答默认摘要加可展开详情，明确 context 范围，并提供个人限额和失败提示。否则“功能丰富”最后只会转化成群噪声与维护者账单。

3. LLM 版 M-x doctor，难点不在接 API

“自己搓一个应该不难”大概率是对的，但能运行不等于值得信任。Emacs 配置故障需要 --debug-init、回溯和加载顺序等可验证证据。好的 LLM backend 不应只生成一段像经验贴的安慰，而应把现象、证据、假设和下一步命令分开，并明确哪些判断尚未验证。它可以帮助用户缩小排查空间，却不能把猜测伪装成诊断。

可继续研究/实践

可以做一个小而完整的原型：从 emacs --debug-init 收集错误上下文，让 LLM 输出“现象—证据—候选原因—下一步操作”的结构化结果；再分别用不同客户端验证 Telegram 输出，确认富文本失败时仍能读懂普通文本。这个实验能同时检验 AI 的实际诊断价值，以及一个工具在协议、客户端和注意力层面的工程韧性。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

1. AI 模型军备竞赛：新模型发布与定价策略 群内今日最热话题集中在 AI 模型发布与行业动态上。下午 Qwen3.8-Flash-Next（代号 Flash-Next）发布，群友评价"这么nb"，指出其架构大量采用了 Qwen4 的特性。随后 Bloomberg 报道 Z.ai 确认 Ox Alpha 是新的 GLM 系列模型并开源权重，群友打趣"来狙击ox了"。晚间 Z.ai 又发布 GLM-5.3-Flash 模型。除了发布节奏，关于 DeepSeek 财务数据的讨论也引发热议：2026 年前 7 月营收 4.75 亿元，同比增长 9 倍，但净亏损约 7.15 亿元。群友点评"一年亏损十几亿，感觉对幻方毫无压力"，并感叹"只有老黄不亏"。此外，OpenAI 对 Plus 用户实行额度限制（"五小时又出来了"）也引起讨论，群友调侃"高情商：体验不好；低情商：薅不起"。

2. Emacs 配置优化：从 elpaca 迁移到 borg，启动时间缩短至 0.6s 群友 @ylagr 分享将配置从 elpaca 迁移到 borg 的经历，直言"爽"。讨论围绕 borg 与 elpaca 的优劣展开：borg 利用 git submodule 管理每个包，心智负担轻，版本锁定简单；而 elpaca 锁定版本后更新和同步困难。@ylagr 强调自己删除了大量兼容 emacs30 的代码，启动时间从 1.1 秒降至 0.6-0.8 秒，仅比 emacs -Q 慢 0.2-0.3 秒。另一位群友分享其配置从 1.1 秒优化至 0.6 秒，并吐槽"这种编辑模式太蠢了，我要的是直接字符替换"。群内还提到 kiennq 为 neomacs 提交了大量 PR，有人想尝试做原生 wayland 后端，但"又犹豫了"。

3. 个人项目开发：3.4 万行 elisp 邮件客户端 一位群友透露正在开发一个邮件客户端，"后端也用 elisp"，目前代码量已达 3.4 万行。讨论涉及邮件标准：支持 message/rfc822 媒体类型（转发消息即添加附件）、使用 sqlite 存储、JMAP 协议简化功能开发。群友打趣"可以玩俄罗斯套娃了"（邮件包含邮件），并感叹"原来邮件客户端还需要管本地 archive 的邮件，长见识了"。该开发者表示"搞了好几天了还没开始做发邮件"，计划"明天还要把文档写写"，并且已提交 Apple 审核等待 TestFlight 分发。

4. AI 编码工具使用体验：额度消耗与上下文长度设置 群友讨论了 Sol 等 AI 编码工具的额度消耗情况："codex 的额度下降的太快了""4 小时 20 分，跑了 22% 周额度"。有群友指出上下文长度设置会影响模型遵循 agents.md 的能力："感觉大约超过 200k 的 sol 也不遵循 agents.md 了"。有人将上下文从 1M 降至 512k 以解决额度消耗过快的问题。还有群友分享了让 AI "对着一个 PRD 让它设计了几个小时的技术方案"的经历。

🔑 关键概念与技术解析

• borg：一种 Emacs 包管理方式，利用 git submodule 管理每个包（一个包就是一个子模块），相较于 elpaca 更简单、心智负担更轻，版本锁定和更新同步更直观。
• message/rfc822：MIME 标准中的一种媒体类型，允许在邮件中包含完整的邮件对象（即"邮件套邮件"），转发消息时直接附加文件即可实现深拷贝。
• Flash-Next：Qwen3.8 系列模型代号，架构上前瞻性地使用了大量 Qwen4 的特性，与 Qwen3.8-27B 和 Qwen3.8-2.4T-95B 完全不同。
• Ox Alpha：Z.ai（智谱）发布的 GLM 系列新模型，已确认开源权重，性能对标 DeepSeek 并引起广泛关注。
• VMP 壳（拖壳）：群友提到"我要让 AI 来试试看能不能拖壳 vmp"，指使用 AI 辅助逆向工程，脱掉 VMProtect 的壳。
• JMAP：一种现代邮件协议，相比 IMAP 更简单高效，群友认为"让很多功能变得很方便"。

💎 碎片知识与金句拾遗

• "现在 ai 公司比的是谁亏损少吗😂" —— 对 DeepSeek 财务数据的评论。
• "打劫全世界" —— 评价英伟达的市场地位。
• "v2ex 有这么离谱的节点：/go/atm" —— 一个关于 ATM 的奇怪节点。
• "luna 虽然流口水🤤 但是量是真的足" —— 评价某模型（可能指 Luna 模型）的输出量。
• "GitGitGadget" —— 一个将 GitHub PR 转化为邮件列表讨论的工具，可"等效转换"。
• "我发现 github 发的邮件也差不多是邮件列表了，没有 archive 吧🤔 可能可以等效转换一个" —— 关于 GitHub 邮件通知与邮件列表的类比。
• "Windows 没的选" —— 吐槽 Windows 平台在某个技术选项上的局限性。
• "我的 Windows 加载不了 org.el，emacs -Q 也加载不了，这是递归了吗" —— 一个关于 Windows 上 Emacs 加载 org.el 的 bug。
• "nitter 被迫 archive 了" —— 关于 Twitter 第三方前端 Nitter 被迫关闭的新闻。
• "别叫技术社区编辑了，叫'AI 新闻编辑'吧"（改自群友调侃）。

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

• Ox Alpha 模型：Z.ai 确认的 GLM 系列新模型，已开源权重，值得实际测试其性能是否如传闻中"rivals DeepSeek"。
• Qwen3.8-Flash-Next：今晚发布，架构前瞻性使用 Qwen4 特性，可作为研究下一代模型架构的参考。
• JetBrains thinkrail：基于 Pi 的 Agent Harness，值得关注其与现有 AI 编码工具的差异。
• LodyAI/Lody：一个开源项目，值得探索其具体功能。
• neomacs 原生 Wayland 后端：kiennq 大量 PR 支持下，若实现原生 wayland 后端 + WPE WebKit，可能成为 Emacs 在图形渲染上的重要突破。
• 3.4 万行 elisp 邮件客户端：开发者正在打磨并即将发布 TestFlight，值得关注其如何使用 elisp 完成后端逻辑。

观点延伸

中心判断：今天几条看似分散的讨论，其实指向同一条工程事实：系统的上限不是“能装多少、能塞多少”，而是边界是否清楚、反馈是否及时。无论是给 Agent 1M context，还是用 Elisp 写 3.4 万行邮件客户端，规模本身都不会自动带来能力；没有切分、验收和可逆路径，规模只会放大失控。

1. 上下文不是越大越强，而是一种有成本的工作集

群里提到，Sol 的上下文超过约 200k 后，对 agents.md 的遵循变差；同时，1M 上下文伴随更快的额度消耗，因此有人尝试降到 512k。这里重要的不是某个具体阈值，而是“上下文窗口”和“有效注意力”不是一回事。Agent 能读取，并不等于能持续把规则放在决策中心；历史信息越多，关键约束越容易被稀释，推理成本也可能上升。

工程上应把大上下文当缓存，不当记忆。让 agents.md 只放不可违背的边界，把任务状态、验收条件和当前决策压缩成短小外部工件；长任务拆成可独立验证的阶段，每阶段用新上下文复核。所谓“让 AI 对着 PRD 设计几个小时”，真正要测的不是它能写出多少方案，而是方案能否在阶段性评审中被证伪、收敛并落地。

2. 邮件客户端暴露的，是“功能完成”与“领域完成”的差距

“邮件可以包含邮件”、本地 archive 也要管理、JMAP 让功能变方便，这些细节说明邮件客户端不是一个渲染 buffer 的项目，而是一个围绕消息对象、存储、同步、转发和搜索建立的领域系统。做到 3.4 万行却还没开始发邮件，并不天然代表进度慢；它更像一个信号：隐含的领域边界正在不断显形。

但下一步不能继续只用“再打磨”推迟闭环。应尽快定义一条最小垂直切片：收取一封邮件，持久化，展示，引用或转发，再成功发出，并能在 archive 中找回。每增加一个协议或 UI 能力，都要落到这条链路的可测试行为上。否则代码量会成为复杂度的计数器，而不是产品成熟度的证据。

可继续研究/实践

做一个小型对照实验：把同一个 Agent 任务分别放在 128k、512k 和更大上下文中，记录规则遵循率、返工次数与额度消耗；同时为邮件客户端画出消息对象、收发与存档的最小状态机。把“感觉更快”“感觉更强”改成可以复现的工程指标。