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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：telega.el 表情符号补全与版本兼容性之痛

讨论热度： 极高，贯穿全天，涉及多个分支。

1. 表情符号（Emoji）显示与补全问题

   • 痛点： 用户发现 telega.el 中 reaction 使用的 ♥ 符号（symbol）与 ❤️（emoji）不同，且部分 Emoji（如 Exploding Head）在补全列表中缺失。
   • 原因分析： 群友定位到是 etc/emojis.alist 文件未包含这些符号。用户指出此前曾提交过添加 Emoji 17 的 PR。
   • 解决方案： 有群友展示了通过 :advice 形式将 ♥ 替换为 ❤️ 的临时配置。最终计划补充文件并提交 PR（关联 PR #574）。
   • 金句： “你可以加了验证一下，提 pr。”

2. TDLib 的 Breaking Change 与版本锁死

   • 痛点： TDLib 小版本更新频繁出现 breaking change，导致无法发文件等故障。用户需手动回退到特定 commit (23a9997...) 才能正常工作。
   • 解决方案讨论：
     • 坚守旧版本，等 telega.el 适配新版后再升级。
     • 自己在本地编译 TDLib（macOS 下 brew 仍需加 --HEAD 编译）。
     • 使用 Docker 环境编译。
   • 社区智慧： 老用户坦然表示“碰到的时候一怒之下怒了一下，然后默默忍受。” 新手则感叹“tdlib这个breaking change让我很难绷反正”。

专题：Emacs 日常使用技巧与问题诊断

1. Buffer 管理与正则删除

   • 问题： 询问如何用正则表达式批量删除 buffer。
   • 教程向回答：
     • 内置函数：M-x kill-matching-buffers-no-ask / kill-matching-buffers。
     • 更优雅做法：在 ibuffer 中对特定分组（如 elfeed）按正则标记，然后一次性 kill。关键函数为 ibuffer-mark-by-name-regexp。
     • 深度建议：检查 elfeed-show-unique-buffers 选项是否为 t，这可能是导致 buffer 泛滥的根源。

2. 触屏输入与击键次数哲学

   • 观点： 一位用户发出感慨：“我终于知道什么时候需要计较击键次数了——触屏输入的时候。好痛苦，击键越多越容易按错。” 这一观察揭示了 Emacs 快捷键理念在触屏场景下的失效，将极小众但真实的痛点升华成了一条设计原则。

---

🔑 关键概念与技术解析

• layer shell / xwayland 待选框：layer-shell 是 Wayland 下用于管理窗口层级的协议。用户提出用它处理 xwayland（X11 兼容层）下待选框的显示，是一种跨图形栈的创意解决思路。
• telega-ins--msg-reaction-type 与 :advice：advice 是 Emacs Lisp 中修改函数行为的机制（类似 AOP 切面）。此处用于拦截默认的 reaction 显示逻辑，将 symbol 替换为 Emoji。
• chirp-show-avatars / chirp-show-tweet-media：这是 chirp 包（Emacs 的 Twitter 客户端）中的选项，设置 nil 可以关闭头像和媒体预览以加速渲染，常见于低性能设备（如手机）。

---

💎 碎片知识与金句拾遗

• Emacs 截图自动化：有用户分享了博客文章链接，介绍如何利用 Emacs Lisp 自动化截图流程。
• macOS 音乐库操作：有人询问“有没有 Emacs 操作 macOS 音乐库的包”，虽未得到肯定答复，但这是一个有价值的遗珠需求。
• “抄配置”的文化：群内多次出现“抄爽了”、“我是抄的大佬的配置”。这是 Emacs 社区特有的共创共享文化——配置即文化。
• “微信小程序兼容搞好了，但是时不时会漏键出去”：一条关于非 Emacs 项目的调试吐槽，保留以体现群内话题的广度和真实开发状态。
• elfeed-show-unique-buffers 源码指向：建议用户直接阅读 elfeed-show.el 第254行，体现了“源码是最好的文档”的极客精神。

---

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

1. telega.el 的 etc/emojis.alist 文件维护：这是一个有明确提交历史的协作项目。如果你在 Emacs 下用 Telegram，可关注并参与更新 Emoji 18+ 的支持。
2. sunshine 与 touchdeck 的搭配方案：有群友在开发自己的 sunshine fork 项目。sunshine 是开源的低延迟串流方案，配合 touchdeck（触屏虚拟键盘）可构建移动端远程控制方案，值得游戏或远程开发爱好者关注。
3. chirp 包的手机端使用优化：有人分享使用 chirp 关闭媒体预览的配置，暗示其在手机设备上使用。这提示 Emacs 可以作为一个精简的 Twitter 客户端运行于低功耗设备上，是 Emacs 跨平台轻量化的一个有趣用例。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“telega 又坏了”，而是 Emacs 生态里一个长期张力：可塑性给了用户逃生通道，但也把用户推成了半个维护者。advice、本地 patch、读源码、锁 TDLib commit，这些都很 Emacs；问题是，它们同时说明边界契约并不牢。

1. 本地可修，不等于工程上健康

♥ 和 ❤️ 的差异、etc/emojis.alist 缺项、通过 :advice 临时替换显示，这是一条很典型的 Emacs 路径：先用配置绕过去，再验证，再提 PR。它的优点是反馈链极短，用户不是只能等官方发布。

但工程判断要更冷一点：如果一个用户可见功能依赖一份静态数据表，而缺项会直接表现为补全缺失，那么这不是“配置问题”，而是数据维护流程问题。真正可靠的改进不是每次缺 emoji 都靠群友补，而是让数据生成、版本标注、回归验证变成可重复流程。

2. TDLib breaking change 暴露的是依赖边界失守

“telega 不支持新版本就坚决不升 tdlib”这句话非常实用。它背后是一个朴素但硬的工程原则：插件层和底层库之间如果没有稳定兼容矩阵，升级就不是升级，而是赌博。

小版本 breaking change 尤其糟糕，因为它破坏的是用户对风险的直觉。不能发文件这种故障，最后靠回退特定 commit 解决，说明当前最有效的策略不是追新，而是版本冻结：记录已验证组合，只有当 telega 明确适配后再动 TDLib。对于个人知识系统和日常通讯工具，稳定性优先级应该高于新鲜感。

3. 触屏击键次数提醒我们：经典效率模型有适用边界

“击键越多越容易按错”这句看似吐槽，其实很锋利。Emacs 的很多效率哲学默认了物理键盘、肌肉记忆和可纠错输入；到了触屏，击键次数从“速度成本”变成“错误率成本”。这会反过来要求命令设计更偏向粗粒度、可撤销、低频确认，而不是继续堆快捷键。

可继续实践

可以把这一天抽象成一个小实验：为 telega/TDLib 建一份“已验证版本矩阵 + 最小回归清单”，再为移动/触屏 Emacs 场景列出高频操作，统计哪些命令应该从多击键快捷键改成菜单、Hydra、Transient 或触屏按钮。这比继续抄配置更接近可验证的工程改进。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI Codex/Plus 生态的“军备竞赛”与“蚂蚁雄兵”

本次讨论最核心的议题围绕如何获取和充分利用 OpenAI 的 Codex/Plus/Pro 额度展开。群友们的讨论呈现出一种“军备竞赛”的态势：

1. 额度焦虑与多号策略：普遍反映单个 Plus（$20 月费）远远不够，尤其是使用 Codex 时，经常出现“刚写完 spec，问了 12 个问题就干没了”或“一周额度几天就用完”的情况。解决方案是采用多号策略：“6 个 plus 我才够用”，“再来个 Pro”。
2. 黑产号与中转站的博弈：讨论了大量关于“黑产 Plus”（通过非正规渠道订阅的账号）的稳定性问题，如“有三个过期了”，并分享了各种中转服务（如 crossmux.com, codexcn.com）的体验。群友们对“黑产”一词的定义、风险和性价比进行了探讨，部分人认为其性价比极高（如 58.88 元/月），但面临突然失效和无法报销的风险。
3. Pro 与 Team 的性价比之选：部分用户倾向于直接购买 Pro（$200 月费）以获得更大的上下文和容量。“感觉不如买个 Pro 5x 的，context 还大”。也有用户采用“25 刀订阅 gpt team”的方案，但感觉“两个 team 没有两个 plus 多”。
4. 工具链与使用技巧：围绕如何高效、经济地使用 Codex 展开了深入讨论，推荐了不同的“架子”（SDD 框架）如 superpowers、grill-me、jj run。用户 Andrew 通过主动“叼 AI”和引导问题，来减少无效的对话轮次，从而节约额度，并指出“要主动引导而非只是回答”。

专题二：AI 生成代码的质量困境与“降本增笑”

由群友分享的博文《我对人类无用论嗤之以鼻，为降本增笑的故事感到悲哀》引发了一场关于 AI 代码质量的反思。

1. 现状与痛点：用户群普遍感受到 AI 生成的代码虽然效率高，但质量堪忧。典型表现包括“上下文压缩后，原来设计的表结构又少字段了”、“干各种事都死循环”。用户 yibiechen 用 Kimi 2.7 时，发现其“比豆包还逆天，干啥都死循环”。
2. 核心观点：大家共识是，当前的软件行业需要被“一大堆无人能理解的 AI 代码轰炸过后，才能知道代码质量的重要性”。其他行业在被自己的 AI 产品“锤”过后，才会对“代码质量”这四个字有重新的理解。这本质上是在探讨技术“降本”背后可能带来的“增笑”风险。
3. Agent 的 Harness 问题：有用户指出，部分模型表现不佳可能不完全是模型本身的问题，而是 agent 的 harness（框架、编排层）没做好导致了一系列问题。这暗示了在 AI 编码工具链中，管理 Agent 行为的架构和调度层还不够成熟。

其他讨论

• 索尼停产生盘：讨论索尼将工厂转做光学微透镜，停止实体游戏光碟生产。核心观点是“光碟的很大作用就是二手流通，索尼觉得二手影响他赚钱了”，并提及了“日本从废旧空调中提取稀土”的宏观背景，认为索尼此举是战略性转向。
• 2026 世界杯趣闻：分享“特朗普游说 FIFA，美国球员巴洛贡停赛暂缓执行”的新闻，并评“演都不演了”。
• 个人项目回顾：群友 roriri 分享其小项目在未明确推广的情况下，两天内增加 100 个 star，引发“可能这就是大佬吧”的感叹。

🔑 关键概念与技术解析

• Codex / Plus / Pro / Team：OpenAI 的不同付费服务。Codex 是增强版的 ChatGPT，Pro 提供无限使用和更大上下文。群友讨论的核心是如何以最低成本获取这些服务的额度。
• 黑产号：通过非官方渠道（如低价礼品卡、盗刷信用卡、共享账户）获取的付费订阅账户。风险在于随时可能被封禁或过期，但价格极低。
• 中转/中转站：本质是二次封装 API，通过整合大量“黑产号”或共享账户，为用户提供一个统一的、按量计费的 API 接口，用户不必自己管理多个 Plus 账号。
• Vibe Coding：一种新兴的编程方法，通过给 AI 模型注入主观的“氛围”描述或设计理念，期望其在生成代码时更能领会开发者的意图和审美。群友分享的相关博文引发了对质量问题的反思。
• Grill-me / Superpowers / Jj run / OpenCode Go：针对 Codex/Agent 的开发框架或工具。它们提供更结构化的交互方式（如自动提问、生成 PRD、流程编排），旨在提高 AI 编码的效率和可控性。
• 5h limited：指 Codex 或 Plus 账户在 5 小时内对话轮次或 token 消耗量受到限制。“希望天堂没有 5h limited”表达了群友对这种限制机制的极度厌恶。

💎 碎片知识与金句拾遗

• 关于效率：“……要主动引导而非只是回答……你可以在 grilling 的过程中，叼 AI，让它不要提那么多无聊的问题。”
• 关于 Agent 质量：“有的时候不一定是模型的问题，agent 的 harness 没做好就是一堆问题。”
• 关于消耗：“我今天一天的用量……等于从 1 点半之后跑到六点……总共是 $150 的额度，我已经用了 69% 了。” — 揭示了资深用户对 AI 工具的极端消耗量。
• 关于工具推荐：“codex $20 真的是完全不够用……用一下 OpenCode Go 吧，节约点。”
• 关于行业趋势：“现在的软件行业需要被一大堆无人能理解的 ai 代码轰炸过后，才能知道代码质量的重要性。”
• 关于生活：“索尼粉丝发起请愿呼吁索尼继续生产实体游戏光盘 但索尼已经将工厂改造另做他用……日本都从废旧空调中提取稀土了，还管你游戏不游戏。”
• 关于个人项目：“很神奇，这个小项目，这 2 天星标增加了 100，但我实在找不到在哪里被推荐了，很神奇。”

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

• roriri.one 的长篇博文与个人项目：该博文《对 Vibe Coding 与代码质量的思考》引发了群内深度讨论，其作者 roriri 的项目在无推广情况下获得了 100+ star，其背后对 AI 编码质量和人类无用论的思考具有前瞻性。
• Codex 的“架子/framework”生态: superpowers, grill-me, jj run, OpenCode Go 等一系列提升 Codex 使用效率和质量的框架工具，代表了开发者在 AI 时代对 IDE 和工作流重构的探索，值得关注其设计模式和理念。
• 无限上下文与 Agent 架构问题：群友反映的“上下文压缩后表结构少字段”和“死循环”问题，指向了当前大模型在长上下文场景下的记忆丢失和 Agent 行为收敛设计上的巨大挑战。深入研究 Agent harness 应该如何解决这些问题，将是未来 AI 工程化的重要方向。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Plus 到底买几个”，而是一个更硬的判断：AI 编程正在从“模型能力竞赛”进入“工程控制能力竞赛”。额度焦虑、黑产号池、中转站、Pro/Team 性价比，看起来是消费问题，本质上是工作流吞吐量问题；而“上下文压缩后表结构少字段”“Agent 死循环”“harness 没做好就是一堆问题”，则说明吞吐量一旦上来，系统边界马上暴露。

1. 额度不是生产力，稳定可控的反馈回路才是

群里反复出现“20 刀不够用”“6 个 Plus 才够”“150 刀额度一天烧掉 69%”，这不是单纯的重度使用炫耀，而是在提示：当 AI Agent 成为日常开发执行器，token/额度就变成一种新的 CI 资源。

但真正的问题不是“怎么买得更多”，而是“每一轮调用是否在推进可验证状态”。如果一个 Agent 连续问 100 多个问题、默认 brainstorm、上下文压缩后丢字段，那更多额度只会放大浪费。Andrew 说“要主动引导而非只是回答”“叼 AI，让它不要提那么多无聊的问题”，这是很朴素但关键的工程判断：人不是 prompt 填表员，人是控制回路里的裁判和调度器。

2. Agent 质量的瓶颈，越来越不像模型问题

“有的时候不一定是模型的问题，agent 的 harness 没做好就是一堆问题”这句话很重要。现在很多人把失败归因于模型智商：Kimi 死循环、上下文超了重复、Codex 压缩后忘字段。但从工程角度看，症状更像系统设计缺陷：状态没有外部化、任务没有分层、上下文压缩没有校验、执行循环缺少收敛条件。

成熟的 Agent harness 至少要能回答四个问题：当前事实源在哪里？关键设计是否已落盘？压缩后如何做一致性检查？什么时候停止追问、转入实现或测试？如果这些都没有，模型越强，越可能生成一堆“看起来在工作”的不可审计动作。

3. “代码质量”会从审美问题变成成本问题

群里那句“软件行业需要被一大堆无人能理解的 AI 代码轰炸过后，才能知道代码质量的重要性”，判断很准。过去代码质量常被当成高级工程师的洁癖；AI 之后，它会变成组织的风险控制手段。因为 AI 最擅长制造局部合理、整体失控的增量代码：字段少一个、边界漏一个、测试假绿、循环不收敛。短期是“降本”，长期就是排障成本、认知成本、迁移成本的集中爆雷。

可继续研究/实践的方向

可以把今天的讨论落到一个小实验：同一个功能需求，分别用“纯聊天式 Codex”和“带外部 PRD/任务拆分/测试门禁/上下文恢复检查的 Agent harness”实现，记录 token 消耗、返工次数、缺陷数量和最终可维护性。别只比模型输出，要比整个工程系统的可控性。