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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】Telega —— 将 Telegram 完全带入 Emacs

Telega 成为今日讨论的绝对焦点，群友从惊艳于其体验，深入到探索高级配置、提交 Bug 和贡献代码，完成了一次从用户到准贡献者的升级。

1. 初体验与视觉进化 群友 Aiser 惊叹于 Telega 的流畅度，称其“完全不像一个插件”。在解决了头像显示问题后，讨论转向如何让外观更美观。有群友分享了自己的界面效果，仿制了 Fantastical 日历样式，并指出 Telega 的优秀渲染得益于其对 SVG 的充分利用，这为后续深入定制提供了方向。

2. Bug 定位、修复与社区协作 一位群友展现了硬核的调查能力，利用 GPT 分析并定位了两个关键问题：

• Bot 命令补全残缺：telega-completions.el 中因错误使用 mapcar 而非 mapcan，导致只显示每个 Bot 的第一条命令，/convert@... 等子命令在补全中消失。
• Telegraph Instant View 正文为空：TDLib 已将字段名从 :page_blocks 改为 :blocks，但 telega-webpage.el 仍读取旧字段，导致 IV 页面内容无法渲染。

针对补全问题，维护者回应“不展开”是出于安全考虑的设计。而针对 Instant View 的 PR，群友在开会间隙提了一半，体现了极高的行动力。

3. 交互痛点与优化（Sticker 预览） 用户提出了一个典型交互痛点：使用 vertico 垂直补全框架选择 Sticker 时，预览界面的缩略图不会跟随选择项实时切换，必须按 Tab 确认后才能看到，体验割裂。群友现场使用 GPT 生成了一段 defadvice 代码，通过临时修改 completion-all-sorted-completions 函数的行为，强行让 vertico 下的选择即时触发预览。这一探索性修复引发了对 Telega 与第三方补全框架适配的讨论。随后，群友为 sticker-set 预览贡献的 PR 被迅速合入，展示了社区的高效。

深度改造：Noctilia 桌面环境的诱惑

一场关于 Hyprland 生态下桌面环境的讨论悄然展开。群友从 DMS 迁移到 Noctilia，理由是 v5 版本性能更好且更省电。讨论聚焦于：

• 壁纸颜色同步：DMS 采用侵入式、暴力的 matugen 集成，而 Noctilia 更优雅，可在设置里启用。
• 状态栏 (Bar) 定制：群友互相分享和调整 Bar 的长度、日期显示格式，有人喜欢更短小的 Bar，有人则模仿 Fantastical 制作了独特的日历显示。
• Session Lock 体验：noctalia-greeter 被发现存在输入密码后 tty 会输出字符的 bug，相关 issue 已被提出。
• 自给自足的壁纸美学：群友 zdn 提出壁纸应自己画，以便更好地控制图层和配合配色方案，并分享了自己用 Adobe 软件绘制的作品。

Gnus 的奇妙可能性：在 Emacs 中统一信息流

一位群友通过“vibe coding”快速实现了一个新后端——nndiscourse，让 Gnus 能像访问邮件列表一样访问 Discourse 论坛。这个实验引发了关于信息流 All-in-One 的探讨：

• 当前能力：已支持浏览、回复、点赞和删除帖子。
• 核心理念：Gnus 被赞“真奇妙啊”，理论上任何类似邮件列表的资源（论坛、RSS、GitHub Issue、Reddit）都可被抽象为 nntp 后端。
• 未来展望：有群友表示，将来可能考虑“all in gnus”，替换掉 elfeed 等 RSS 阅读器。

🔑 关键概念与技术解析

• telega：Emacs 中一个功能完备的 Telegram 客户端。它不是一个简单的“插件”，而是深度集成，体验流畅，广泛使用了 SVG 进行渲染和显示。
• TDLib：Telegram Database Library，官方推出的跨平台库，用于构建 Telegram 客户端。telega 正是基于此库（如 telega-server）实现核心功能。
• Noctilia：一个基于 Hyprland 的 Wayland 桌面环境配置集合（或称“元发行版”），注重美观、性能和开箱即用的体验，v5 版本因其性能提升而受到关注。
• matugen：一个利用 Rust 编写的工具，能从壁纸中提取颜色并生成 Material Design 风格的主题，用于同步桌面各组件的配色。
• nndiscourse：一个全新的、由群友“vibe”出的 Gnus 后端。它让 Emacs 用户可以用 Gnus 的邮件/新闻组阅读方式去浏览和交互 Discourse 论坛。
• vertico：Emacs 中一个现代、垂直化的补全框架，与默认的补全方式不同。聊天中提到它与 telega 的交互存在一些需要适配的地方。
• vibe coding：群友口语化的表达，指利用 AI（特别是 GPT）辅助，快速地从零生成一个程序或组件的代码（如 nndiscourse 后端的创建），开发过程类似“跟着感觉走”。

💎 碎片知识与金句拾遗

• Emacs 输入法崩溃：有群友报告 emacs-rime 常导致 Emacs 崩溃。解决方法之一是切换到另一个 Rime 前端 rimel，或者直接使用其 Git 版本而非发布包，有时能神奇地解决稳定性问题。
• Telegram 注册门槛：有群友发现 Telegram 现在对部分地区的注册要求 付费订阅会员，特别是 +86 的手机号，引发了 Tele-gram 是否开始“堕落”的感慨。群友对此展开了关于接码平台、地区风控等讨论。
• Emacs 中收发邮件的不同体验：讨论对比了 gnus 和 mu4e，认为 gnus 并非很难用，而 mu4e 不好用。但 Emacs 对富文本邮件的渲染（展示处理）普遍较差，写纯文本邮件很舒服。有人对 Emacs 聊天的体验评价很高，认为“比其他客户端都好用”。
• 编译搜索技巧：针对如何在不重新输入全部参数的情况下，于 grep 结果 buffer 里换关键词搜索的提问，多个解决方案被提出。一是 C-u g 快捷键可直接带出上次的命令供编辑；二是通过配置 compile 包，在其 compilation-mode-map 中绑定 r 键为 compile，实现一键重输命令。
• 窗口管理器的小工具：有群友推荐了 way-edges，一个在 Wayland 下实现屏幕边缘热点/动作的工具，类似 Hyprland 或 Niri 里的效果，需要 hover 触发。
• Emacs 的 IME 魔改尝试：某群友在魔改 Emacs IME 体验时，发现通过 Emacs 内部 my_post_msg 方法来绘制 preedit（输入法预编辑字符串）的效率，竟然不如自己写的动态模块通过 Windows 命名管道（Named Pipe）传递数据。这揭示了 Emacs 内部某些消息处理路径可能存在性能瓶颈。
• Lucius 的配置：有群友开始参考 Lucius 大佬的 Emacs 配置，并感叹其 modeline 有股“neo里vim气”的，非常像用 heirline.nvim 搓出来的效果。

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

• nndiscourse 项目：这是本周最具潜力的新星。建议 Follow 这个项目，观察其如何将 Discourse 生态（如 Flarum、NodeBB 等论坛）抽象为 Gnus 的新闻组概念。这可能是继 elfeed 之后，Emacs 信息管理一体化的下一个重要方向。
• Telega 与 Vertico 的深度补全适配：虽然群友用 defadvice 解决了 Sticker 预览问题，但这并非长久之计。理想的解决方案应是在 Vertico 或 Telega 的代码层面进行优雅的适配。值得关注相关 Issue 或 PR 的进展，这是一个高质量的贡献点。
• Emacs 预编辑字符串的性能优化：群友发现内部消息传递处理 IME preedit 效率低于外部命名管道，这暗示了一个可能被忽略的性能瓶颈。对于在 Windows 上重度使用 Emacs 且依赖 IME 的用户，这是一个值得深入 trace 和优化的技术点，或许能向 Emacs 核心提交补丁。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“telega 很强”，而是一个更硬的判断：Emacs 的生命力不在于它能不能复刻现代 App，而在于它能把外部系统降维成可编程对象。一旦 Telegram、Discourse、RSS、邮件列表都被拉进同一个编辑/补全/搜索/回复模型里，客户端就不再是客户端，而是个人信息操作系统的一组后端。

1. telega 的惊艳，来自“不是插件”的工程边界

群友说 telega “完全不像一个插件”，这个评价很准确。普通插件是在宿主里加功能；telega 更像把 Telegram 的状态、消息、媒体、补全、SVG 渲染和 TDLib 对接成一套 Emacs-native 的交互层。

但今天暴露的几个点也说明：这种深集成的代价是边界极厚。TDLib 字段从 :page_blocks 变成 :blocks，Instant View 就空了；补全里是否展开 Bot 命令，不只是“mapcar/mapcan”的代码问题，还牵涉维护者的安全判断；sticker set 预览在默认补全与 vertico 下行为不同，也不是一句“加个 advice”能彻底解决。

所以 telega 的工程价值不在“能在 Emacs 里聊天”，而在它把一个高频社交系统接进了 Emacs 的可塑层。可塑性越强，适配面越大，维护判断就越重要。

2. vibe coding 真正改变的是“后端实验”的成本

晚上群友 vibe 出 nndiscourse，支持浏览、回复、点赞、删除帖子，然后自然引出“all in gnus”。这比单纯写个玩具更有意思：Gnus 的抽象足够老，但也足够稳定，任何“像邮件列表”的东西都可以被投影成 group/article/reply 这套模型。

AI 在这里的作用不是替代工程设计，而是把“写一个后端试试看”的启动成本打下来。以前这种想法会卡在协议细节、样板代码、函数名查找；现在几句话能跑出雏形，于是问题从“能不能做”变成“这个抽象值不值得长期维护”。

这也是今天 telega 和 nndiscourse 的共同点：AI 可以加速定位 bug、生成 advice、vibe 后端，但它不能替你决定边界。比如 Bot 命令展开是否安全、vertico 适配应写进代码还是文档、Discourse 到 Gnus 的映射能否覆盖真实使用场景，这些都还是工程判断。

3. All-in-One 不是把所有东西塞进 Emacs，而是统一操作语义

“all in gnus”很诱人，但危险在于误读成“所有信息源都要搬家”。更可靠的标准应该是：这个信息源是否能被统一成可搜索、可回复、可归档、可脚本化、可批处理的对象。

Telegram 适合 telega，不是因为它在 Emacs 里更漂亮，而是因为聊天记录、链接、补全、贴纸、Bot 命令都可以被纳入同一工作流。Discourse 适合 Gnus，不是因为论坛像邮件，而是因为 topic/reply/read-state 与 Gnus 的文章模型足够接近。反过来，富文本邮件在 Emacs 里展示很怪，就说明不是所有信息都天然适合文本中心系统。

可继续实践的方向：挑一个真实高频信息源，不要先追求“全功能客户端”，而是验证三件事：数据模型能否稳定映射到 Emacs 对象；核心操作是否比原客户端更快或更可组合；第三方框架如 vertico/corfu/evil 的适配是否有明确边界。能过这三关，才值得从 vibe 原型变成长期工具。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

1. Claude Code "蹬车" 狂潮与账号风控对抗

今日讨论热烈围绕 Claude Code 的滥用与 Anthropic 的反制措施展开，形成了一场围绕"用多久、怎么封、如何复活"的完整博弈链条。

• "蹬车"（疯狂使用）现状：群友普遍高强度使用 Claude Code Max 配额，单账号"5小时冷却/周限额"的模式催生了多账号循环使用的策略。有人明确表示使用 3 个 Max 账号在线以"缓解焦虑、正常睡眠"。
• 大规模封号与风控升级：
  • 封禁类型：非简单的账号级封禁，而是基于设备指纹/IP 的风控。表现形式包括直接提示 Your account has been disabled，或悄无声息地将 Pro/Max 套餐降级为 Free 套餐。
  • 欧盟税号注册通道关闭：此前通过欧盟税号 "白嫖" 注册的大量 Max 账号被集中清理。
  • 触发时机推测：有群友推测是因前一天 Max 注册量异常激增（"一天内增加十几万个 Max 账号"）触发风控模型。
• 绕过与重生策略：
  • 隔离指纹：群友 laosb 开发的 agentc 工具受到推荐，其核心价值是隔离 Claude Code 内置的指纹跟踪，避免大号和小号 session 关联。
  • IP 变换：被 Ban 后通过更换 IP 并使用匿名窗口认证可复活。
  • 退款流（薅羊毛）：核心玩法是利用 App Store/Google Play 的退款机制。在 7 月 19 日前全额退款，19 日后改为按比例退款使用天数，一个 Pro 升 Max 再被封的操作甚至可能导致亏损部分天数。有用户声称已累计申请 100 多个 Max 账号并全额退款。

2. Emacs 与 AI 深度集成探索

该话题从对 telega 作者的讨论延伸至 AI Agent 在 Emacs 中的原生展现形式。

• telega 作者与俄罗斯开发者文化：群友深入探讨了著名 Emacs Telegram 客户端 telega 的俄罗斯作者 Evgeny Zajcev，赞誉其代码"丝滑"，生活状态良好（"有城堡"、"有钱有闲"且带娃技术强）。进而延伸至对俄罗斯（Nginx）、德国、日本开发者产出的"安全感"认同。
• 原生 Buffer 交互与 Vibe Coding：
  • 现状痛点：在终端（ghostel）中使用 AI 不够原生。
  • 解决方案：群友 manateelazycat 展示了 codex-ide（acp-el）利用原生 Emacs buffer 实现 vibe agent ide，并加入了 sidebar 功能。
  • 新方案构想：探讨利用 emacsclient 让外部 Agent 直接操控并展示在 Emacs buffer 中，实现低延迟的原生集成体验。

---

🔑 关键概念与技术解析

• agentc：由 laosb 开发的工具，用于代理 Claude Code 的请求，主要目的是隔离设备指纹，避免 Anthropic 通过 websocket 等手段追踪同一设备下的多账号滥用行为。
• run0：Linux 系统中对标 sudo 的新式提权工具，基于 polkit。在 AI Agent 场景下优势明显，可在终端直接弹出图形化密码/生物识别验证弹窗，比配置复杂的 sudo 在自动化脚本中更具可用性。
• alint：群友 moeru-ai 推出的项目，旨在自动化进行代码"熵减"，主要用于清理 AI 生成代码中的"slop"（指冗余、低质量、啰嗦的无效代码）。
• Co-Authored-By 污染：指 AI (如 Claude) 在自动生成的 git commit 中默认添加了机器人的 Co-Authored-By 签名。本次讨论发现甚至污染到了 Emacs Master 分支，引发了大片抱怨，被认为是 AI 编码工具（harness 行为）引入的"恶心"默认设置。
• agent-shell：在 Emacs 中通过终端模式运行 AI 原生 Agent 的思路。
• diff-hl：Emacs 阅读代码变更的插件，在左侧 fringe 高亮显示文件修改行，便于在使用 AI 改代码后 review。

---

💎 碎片知识与金句拾遗

• 松下的技术品味：群友分享松下新款迷你剃须刀（ES-P690U），全金属机身、无线充电、六刀头，称其"把自家能用的科技全用上了"。双持用户体验对比结论是徕芬虽便宜但使用体验一般。
• 健康警示：由日本推理小说家东野圭吾（68岁）因肠癌去世引发。群友建议 "30 岁后尽可能隔一两年做一次胃肠镜"，全麻可大幅减轻痛苦。
• SIM 卡清退预警：英国运营商 giffgaff 被曝于 7 月 27 日开始清退长期/永久在英国境外漫游的用户，直接终止服务。这对依赖该卡保号的中国用户影响巨大。
• 华为被传建 DRAM 厂：传言华为与昇维旭合作建 12 英寸厂，月产能 14 万片，主要为保障昇腾 AI 芯片内存供应，不过华为已否认。
• Emacs 原生键位优越感：有用户在使用复杂配置后反思："我现在开始觉得 emacs 原生键位更好按了..."
• "散帅"：群内生造的网络用语，源于 sunshine 谐音，形容像阳光一样让人感到温暖、洒脱、极具魅力的 Emacs 爱好者。
• Claude vs. Codex 分工："Claude 在审美和图形上比 codex 高出一大截"，现阶段最佳实践变为：Claude 负责编写/Review 起审美把关作用，Codex 负责强逻辑实现。

---

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

• agentc：在 AI 模型厂商疯狂收紧风控的大背景下，用于反指纹追踪的代理层工具具备极高的研究价值，直接影响下一代 AI 开发工具链的可用性。
• alint：针对 AI 生成代码质量参差不齐的现状，专用于降噪和规范化的 Lint 工具需求巨大。
• codex-ide (acp-el)：manateelazycat 所做的 Emacs 原生 Vibe Coding 尝试（在Buffer内显示 Sidebar），代表了重型编辑器不与 AI 特性解耦的演进方向。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Claude Code 怎么继续蹬”，而是两个更硬的工程现实：AI Agent 已经从“工具使用”进入“资源、身份、界面三者耦合”的阶段。谁还把它当一个普通 CLI 或普通订阅服务看，谁就会在成本、风控和工作流上被反复教育。

1. 账号池不是生产力工程，是脆弱性的症状

群里围绕 Max 账号、IP、指纹、退款、降级的讨论很热闹，但工程判断很简单：如果一个开发流程需要靠账号循环、指纹隔离、退款窗口来维持吞吐，这不是可持续能力，而是把关键生产线架在未定义行为上。

这类玩法短期能换来“不断供”的错觉，长期会把团队带进三个坑：成本不可预测、状态不可复现、责任边界不可审计。尤其是 Agent 编程，一旦 session、上下文、账号身份、设备指纹发生耦合，所谓“继续用”就不再只是认证问题，而会污染工作流本身：哪个 Agent 改了什么、基于哪个上下文、是否能回放，都会变得模糊。

所以 agentc 这类工具真正值得研究的点，不是“反封号”，而是它暴露了 Agent 工具链需要一个正式的隔离层：身份隔离、会话隔离、项目隔离、审计隔离。未来靠谱的 AI 开发环境，不应该默认相信模型厂商 CLI 的本地行为，而要把它当成不可信外部进程来沙箱化。

2. Emacs 原生 buffer 不是情怀，是 Agent IDE 的正确抽象

另一条线是 codex-ide、agent-shell、emacsclient、diff-hl 这些讨论。表面看是“想在 Emacs 里更舒服地用 AI”，本质是大家开始意识到：终端承载不了复杂 Agent 工作流。

终端适合线性文本流，但 Agent 编程不是线性对话。它需要状态栏、变更列表、diff、文件跳转、任务进度、审阅入口、上下文引用。把 Agent 塞在 ghostty/ghostel 里跑，最大问题不是“不够原生”，而是 UI 抽象错了：它把一个多对象协作系统压扁成一条 stdout。

Emacs buffer 的优势不是古典，而是可组合。buffer、window、minor mode、fringe、process、TRAMP、vc/diff，这些老抽象天然适合表达“一个 Agent 正在改哪些文件、产生哪些状态、等待哪些人类判断”。这也是为什么 sidebar、diff-hl、emacsclient 会自然出现在同一天讨论里：大家不是在找一个聊天框，而是在找可审计、可打断、可嵌入日常编辑动作的 Agent 控制台。

3. 下一步该验证什么

可继续实践的方向很明确：做一个最小可用的 Emacs Agent 隔离层。要求不高，但要硬：每个 Agent run 独立 project/session；所有文件变更进专门 buffer；diff-hl/VC 可直接 review；提交前强制过滤 Co-Authored-By 等 harness 污染；高权限命令走 run0 这类可视授权；外部 CLI 只作为后端进程，不直接支配编辑器状态。

判断标准也很简单：不是“能不能聊天”，而是一次 AI 改代码后，人在 30 秒内能否回答三个问题：它改了哪里、为什么改、我如何回滚。能回答，才叫 Agent IDE；不能回答，只是更花哨的蹬车。