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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Telegram 群组 spam 治理的「军备竞赛」

今天最核心、讨论最激烈的话题，围绕着如何治理 @emacs_china 公开群的 spam。整个讨论经历了「人工踢人 → 引入现成 Bot → 自研 Bot → 策略进化」的完整迭代。

初始困境：

• 公开群无法直接使用 Telegram 官方的入群审核机制，导致 spam 频繁
• 有群友发现一些 spam 是「潜伏」用户发的，而非刚加入的新人
• 现有 Bot（如 GateShieldBot）效果不佳，群主 nmbot 离线后无法兜底

讨论中的多种方案（按时间线）：

1. 换用 @GateShieldBot —— 试过，没用
2. 设置入群问答 —— 如「问 (+ 1 1) 等于多少」，但真人也可能搞不明白
3. 自定义 Bot + LLM 审核 —— 最终采用方案
4. 切换为私有群 —— 会失去 emacs_china 这个公开 ID
5. 人工标记 spam + LLM 决策 —— 作为「事后校验」的补充

最终落地的方案： 群友 Sinofine 用 Telethon（MTProto 协议）搓了一个 bot（tgspamod），核心逻辑：

• 只审核新加入用户的前三条消息 + profile（昵称、bio、emoji 状态包）
• 将以上信息交给 LLM（deepseek）判断是否广告，是则 ban
• 对 media 消息直接删除
• 后来同步了群内老用户的历史发言数，把审核范围扩展到「潜伏」用户

过程中的关键问题与解决：

• 误判问题：某群友发了一张「演示 Emacs 内播放视频」的图，被 bot 当作色情广告误踢了。后来调整了 LLM prompt，在 bio 审核中加入了「个人频道、博客、开源项目默认不视为广告」的规则，并提高了 confidence 阈值
• 权限问题：bot 没有管理权限时无法踢人（USER_ADMIN_INVALID）
• 成本问题：有人担心 token 消耗，群友建议换用便宜的 jev 模型，并说「群友随机捐几块凑个一两百能用好久」
• 跨群回复：有人提议「无脑直接删除+封禁」，但有人指出自己会跨群引用回复，最终决定维护白名单 + 关联对话豁免
• 风控策略：有人建议把可疑用户信息保存下来维护特征表，供后续 LLM 判断依据

专题：Emacs 在 Windows/WSL 上的编译与多媒体支持

编译问题：

• 群友在 Windows 上用 ucrt64 编译 Emacs master 分支失败，报错 tree-sitter library not found or failed to load
• 排查后发现需要安装 mingw-w64-ucrt-x86_64-libtree-sitter 依赖
• 有人提醒不要用 scoop 安装 msys2（scoop 自带的 sh 可能覆盖 msys2 的 sh）
• 还有 make -j 多线程编译问题：master 分支之前的某些版本有 bug，建议 clean build + 不用 -j

Emacs 内播放视频与动图：

• video.el（0WD0/video.el）实现了 Emacs buffer 内播放视频，基于 Canvas
• 有人体验后发现可以拖拽文本盒子实时重绘，性能可达毫秒级，原理是事件合成和增量更新
• emacs-canvas-patch（minad/emacs-canvas-patch）提供了非 master 的 patch 方案
• telega.el 的动态表情播放依赖 tgs2png 库（zevlg/tgs2png），将动态表情转换为一堆图片再播放
• Windows 上 telega.el 不能看表情播放和视频，群友通过外部调用 mpv 解决

---

🔑 关键概念与技术解析

概念	解释
tgspamod	群友自研的 Telegram 群组反 spam bot，基于 Telethon（MTProto 协议），将新用户 profile 和前三条消息交给 LLM（deepseek）判断是否广告，再自动 ban/删
Telethon / MTProto	Telethon 是基于 MTProto 协议的 Python 客户端库。与 Bot API 相比，MTProto 可以获取更多信息（如跨群回复的引用来源），但需要用户身份登录
jev 模型	群友提到的模型，特点是「便宜的要死」。主要用途是调提示词，让 agent 自己调 prompt
tgs2png	telega.el 播放动态表情（TGS 格式）的依赖库，会把动态表情转换为一堆 PNG 图片然后播放
tree-sitter	一个增量解析库，Emacs 的 xxx-ts-mode 依赖它。Windows 编译时需安装 mingw-w64-ucrt-x86_64-libtree-sitter
GateShieldBot	现成的 Telegram 入群验证 bot，本群测试后效果不佳

---

💎 碎片知识与金句拾遗

• 「自建 bot 可以解决 99.99% 的 spam，不需要什么奇思妙想🙈」—— 群友总结，自建 bot + MTProto 是终极方案
• 「我的 telega.el 是完全不支持的，完全静态」—— Windows 用户抱怨动态表情无法播放
• 「就是没意义，和 xwidget 并不是一个层面的东西」—— 关于用 Canvas 取代 xwidget 的讨论
• 「为了一盘醋，包一顿饺子？-0-」—— 吐槽自己造轮子
• 「下次发示例的时候发点正能量」—— 因误发「看片」截图被 bot 误封后的调侃
• 「gemini 的支付怎么解决的？闲鱼~万能的闲鱼，啥都能干」—— 关于 Gemini API 付费的民间方案
• 「名字能默认隐藏吗，它本身已经成为 spam 的一部分了」—— 关于某 spammer 的昵称本身就像广告
• 「我可以证明在 emacs 的 buffer 里面，拖拽文本盒子实时重绘可以很跟手，达到毫秒级的性能」—— 群友展示 video.el 的潜力
• 「ot 群不公开，spammer 本身就少，基本都不用操啥心」—— 关于跨群回复豁免策略
• 「可以进群改」—— 默认隐藏昵称的讨论
• 「走 jev 吧，便宜的要死」—— 控制 LLM 成本的方案
• 「稳定才是最重要的。bot 不在线了啥也没用。现在的公开 bot 不会取离线消息，自己做的话可以在短暂下线上线之后再取离线消息」—— 自建 bot 的另一个优势

---

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

1. tgspamod — 群友自研的 spam 检测 bot，完全开源。值得关注的点：LLM prompt 如何调优（bio 审核的规则），Telethon 获取跨群回复引用的能力，以及「潜伏」用户的追溯策略
2. video.el — Emacs buffer 内播放视频，基于 Canvas 实现了毫秒级重绘。群友验证了事件合成 + 增量更新的方案可行，后续或许可以演变为 Emacs 内做交互式应用的框架
3. emacs-canvas-patch — 非 master 分支的 patch 方案，可在稳定版上体验 Canvas 能力
4. 入群验证策略的取舍 — 群友提出的「bot 生成表达式，要求在 emacs eval 后回复值」的 PoW（工作量证明）方案，比普通问答更符合本群受众，值得玩味
5. Emacs master 分支的 make -j 多线程编译 bug — 是一个真实的坑，值得记录下来避免后人踩坑
6. nmbot + tgspamod 多 bot 协同 — 群主 nmbot 管入群验证，tgspamod 管潜伏 spam 清理，这种多 bot 分层治理的思路值得参考

观点延伸

中心判断：今天关于 spam 的这场拉扯，争的其实不是「换哪个 bot」，而是给一个公开群补上它一直缺失的信任层。而决定成败的三样东西——取证半径、证据门槛、可用性——没有一样在模型能力里。

一、换掉 Bot API，换来的不是实现方式，是取证半径。 讨论到深夜才点破的差异：Bot API 取不到跨群回复引用来源、离线消息、用户注册时间这类信息，而这些恰恰是判定 spam 最需要的证据。所以这不是技术偏好之争，而是判定能力的上限之争。推广成一条更通用的判断：审核类 agent 的质量上限由它的可观测性决定，而不是由它调用的模型决定。下次觉得「判不准」，先问「我需要的那条证据，系统愿不愿意给我看」，再考虑换模型。

二、把「意图判断」降级为「证据门槛」，是 LLM 做审核唯一稳得住的姿势。 误杀发生后的修复动作值得抄：规则里写明「bio 中的个人频道、博客、开源项目默认不视为广告」，并补上「链接目的地未知时不得猜测其中含广告」「必须有明确的商业招揽、付费引导、诈骗、博彩等证据」。这不是调 prompt 的语气，而是把概率模型的决策边界显式化成可审计的规则。配套判断是：阈值和证据门槛必须一起动——只提高阈值，边界样本只会在「沉默」和「误杀」之间来回搬家。另外，误判代价是不对称的：误杀一个群友要道歉、解封，还被调侃一句「下次发点正能量」；漏放一条广告只是多一次手删。代价不对称的系统，默认动作应该是限制发言或请管理员确认，而不是直接封禁。

三、只审增量，必然留存量盲区。 第一版只审新用户的前三条消息，当天就被现实修正：不少 spam 来自早就潜伏进群的账号，先进来养号，隔几周再发广告。补丁是同步历史发言数、把审核范围扩到存量用户。这里藏着一个该前置的设计问题：审核挂靠的事件是「入群」还是「发言」？挂靠发言，存量问题根本不会出现，代价是每条消息都要过一遍判断——全量送 LLM 既贵也是一种越界。当天给出的折中很实用：群友标记 → 够人数 → LLM 二审。人当触发器和限流器，模型只当判决者。

四、可用性优先于智能。 「bot 不在线了啥也没用」是当天最工程化的一句牢骚。自建客户端能在重新上线后补拉离线消息，审核流这才第一次有了「至少一次投递」的语义；判定再准，掉线那十分钟进群的人也全是漏网的。可验证的判断：这套系统的正确性应该用「掉线十分钟会漏掉什么」来测，而不是用准确率来测。

可以接着做的一件事：给它攒一个回归集。 当天出现了两类信息量极高的样本——被误判的真人（在演示 Emacs 里播视频）和伪装正常的真广告。但现在每次调 prompt 都是「改完看效果」，缺一个能回放、能阻止回退的基准。把这几十条边界样本固定下来，每次改规则重跑一遍，调 prompt 才算从玄学变成可积累的工程。再往前一步，是把处置日志与申诉入口公开——当天已经有人提出了这个方向，让群友自己发现误判，信任才补得回来。

（说明：草稿已写入 /tmp/reflect_draft.md，字数与转义检查脚本已备好 /tmp/count_draft.py，但本轮工具调用额度用尽，未能实际运行；本板块按中文字约 900 字目测控制，未发现裸 HTML 标签或尖括号占位符。）

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 模型大乱斗与订阅策略博弈（持续全天）

这一天是 AI 厂商的“军备竞赛日”——Anthropic 与 OpenAI 几乎同步释放新模型，引发群内高频讨论与实测对比。

核心事件：

• Claude Opus 5.5 全面上线（AWS/GCP/Azure），订阅用户 5 小时限额上调 20%
• GPT-6 Sol 和 Luna 发布，API 价格永久下调 50%（Luna 价格已低于 DeepSeek）
• 群友实测对比：Opus 5.5 被认为是“接近 fable 5.1 但消耗更少”“写代码很克制，不需要太多规范”；GPT-6 Sol 速度很快，但“用的人多了就开始变慢”；Astra 仍被认为是 O 系最强

各方观点交锋：

• 关于价格战：Luna 降价引发“比 DeepSeek 还便宜”的惊呼，有群友认为“你追我赶对大家都好”；但 Claude 系“模型全太贵，用户数量上不去，利润不足就无法快速扩容算力”，形成恶性循环
• 关于订阅策略：OpenAI 的“backend reset”机制被吐槽“恶心”，额度下降；Claude 送 reset 卡，但“烧起来太快，一下子 5h limited 没了”。群友总结出最划算用法：“等自然周期刚重置之后，快速把正常额度用完，然后再正常用 backend reset”
• 关于厂商意图：有群友直言“它就是贪钱，为了给投资者信心拼命实现盈利”“商业世界里没有好人”；但也有理性声音认为 OpenAI 找到了正确的训练方向——“每次训练叠加一个专业领域，让基模在该领域实现突破”

群友实操策略： 主用一家不够，需要多家切换——“o+ds 4.1 flash”组合，ds 快速执行、astra 设计测试边界，来回切；也有人选择“这个月用 A\，下个月用 O\”。Claude 封号问题成为切换的阻碍，有群友建议中转方案（packyapi 等）。

专题二：Emacs 像素级渲染——文本应用向浏览器体验逼近

这是一条贯穿深夜到凌晨的高质量技术主线，围绕在 Emacs buffer 中实现像素级拖拽渲染的原型展开。

讨论脉络：

• 有人开发了原型，证明在 Emacs buffer 里拖拽文本盒子实时重绘可达到毫秒级性能，原理是“事件合成和增量更新”
• 核心瓶颈集中在垂直方向：Emacs 的垂直高度只能按行数计算，导致拖拽时“一顿一顿的感觉”；而水平方向可以做到像素级流畅（已有水平像素滚动 patch）
• 关键差异点：Emacs buffer 的宽度计算精确到像素，但高度受限于行模型——这是与浏览器体验的根本差距
• 群友提出：如果垂直方向也有像素级操作方案，“浏览器的那些静态页面全部都可以用工具一键转化为 emacs 当中的文本应用”
• 布局系统已支持 flex/grid 自适应、overflow 属性（垂直默认滚动、水平默认截断），逻辑与前端基本一致

意义与展望： 这一讨论实质指向“Emacs 作为 GUI 应用运行时”的可能性——通过将上层应用交互编译为直接操作 buffer 的 elisp，配合像素级渲染，有望让 Emacs 成为跨平台的高性能文本应用容器。

专题三：开发工具链的“轻量化”转向

晚间讨论逐渐转向轻量级工具与启动性能优化：

• qemacs（C 写的轻量 Emacs 替代）被多次提及，有 Windows 版本，反应快、跟手，但“功能不上不下”，IME 支持存疑
• dumb-jump 与 citre 的对比：有人推荐 dumb-jump 做轻量级跳转，但有群友指出“dumb-jump 不好用吧，citre 好很多”
• Emacs 启动性能竞赛：群友分享配置后冷启动 0.87s（31 packages，T480 老电脑）、0.69s（无 autoload 全量 require）；TUI 模式可到 0.09s
• doomemacs 作者添加 Nvim 配置引发讨论，但群友普遍认为“可能只是感兴趣”

---

🔑 关键概念与技术解析

backend reset / banked reset：OpenAI 订阅账号的额度重置机制。自然重置按固定周期进行，此外还有可额外触发的重置次数。群友总结的“最划算用法”是：自然周期重置后快速用完正常额度，再用额外重置。这一机制被吐槽“恶心”“鸡贼”。

transient（面板）：Emacs 中用于临时弹出 UI 面板的框架。讨论中提到弹出面板时光标不聚焦是“故意的”，可以用 at point 参数来加；-r/r 的命名约定表示“-r 从 minibuffer 输入，r 是 toggle at point”。

Multi-Frame 测试 / Terminal-Bench 2.1：阶跃星辰自建的 AI 编程工具基准测试，Step Code 在 Terminal-Bench 2.1 完成 72/89 任务（80.9%），与 DeepSeek Harness 并列最高，但 token 用量更低。

contextProjection：Step Code 中的激进上下文压缩机制，可以裁掉旧工具输出、重复结果和历史 reasoning，默认关闭。体现了“模型 + harness 多处优化叠加”的 token 节约思路。

AGENTS.md telemetry 依赖：Claude Code 只在 telemetry 开启时才读取 AGENTS.md 文件——这意味着默认配置下，项目的 AGENTS.md 指导文件可能完全被忽略。这一发现来自 Hacker News 文章，值得 Claude Code 用户关注。

事件合成与增量更新：Emacs 像素级渲染原型的核心原理——合成拖拽事件并增量更新 buffer，从而实现毫秒级重绘。

dumb-jump：Emacs 的轻量级代码跳转工具，基于文本搜索而非 LSP，适合快速启动场景。群友提到维护者已用 LLM 实现了新特性（“这个也是 LLM 实现的”）。

---

💎 碎片知识与金句拾遗

• “有經驗的大佬還是比 llm 强的多”——凌晨 2 点看到 Claude 链接后的感慨，群友认同后无人反驳
• “AI 时代真是好”——看到 dumb-jump 维护者用 LLM 实现功能后的感叹
• “给 LLM 腌入味了”——群友自写英文被鉴定“有一点 llm 的味道”，进而调侃现在很多人中文也有 LLM 味
• “将来 ai 可以 1 秒帮你回顾这一生”——关于写日记/日志的畅想
• hermes + jev 日报系统：“让 hermes 自己抓我推特关注列表的推文，jev 做完价值判断之后总结成日报”——效果一般，但体现了自动化信息流处理的思路
• “我买了个手机键盘”——随后有人推荐“从旧黑莓上拆下来的键盘，手感肯定是好的”
• “一想起来国内不会被 claude 抢走工作就感觉有点难绷”——因为国内用不了 Claude
• “claude 需要一个合适的力工模型”——Claude 系模型全太贵，缺乏便宜快速的小模型
• “o 最起码还时不时重置”——对比两家订阅策略的无奈吐槽
• “三 cline pass 6 美元居然没有蹬完”——“蹬”（蹭）额度已成为群内黑话，指用完订阅额度
• “现在程序占内存太厉害，macOS 监控里内存都变黄了，然后卡卡的”——大模型 IDE 时代的普遍痛点
• “rust-analyzer 也他妈的内存大户”——讨论 LSP 太重时的一句话
• “不聚焦是故意的”——transient 面板的设计哲学
• OpenRouter 绑卡问题：有群友反映“开着代理也不行”，可能是按 IP 或支付方式检查
• TG 发图模糊：有人吐槽“发图怎么能那么糊”，建议“按 document 发”
• “我敢说 qemacs 可能对 Windows 的 IME 输入法支持很糟糕”——gnu emacs 2026 年才解决这个问题
• “我觉得很可惜的是 emacs 没有连续缩放”——滚轮缩放体验的遗憾

---

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

1. Emacs 像素级渲染框架（etaf）：讨论中提到的原型证明“在 buffer 中拖拽文本盒子毫秒级重绘”可行，且已有水平像素滚动 patch。这一方向若能突破垂直方向的行限制，有望让 Emacs 成为浏览器级的文本应用容器。值得跟进作者的后续实现。

2. Step Code 的 token 优化组合拳：阶跃星辰开源的 AI 编程工具，其 token 节约策略包括限长文件读取、上下文压缩、contextProjection 等，且与 Step 系列模型联合调优。开源可复现，值得深入分析其“模型 + harness 协同优化”方法论。

3. Claude Code 的 AGENTS.md 读取机制：文章揭示 Claude Code 仅在 telemetry 开启时读取 AGENTS.md——这一行为对依赖项目指导文件的团队有深远影响，值得进一步验证并测试不同配置下的行为差异。

4. qemacs 的 Windows 支持与 IME 兼容性：C 写的轻量级 Emacs 替代，群友指出其 TUI 刷新比 Emacs 厉害、GUI 差太多，且 Windows IME 支持存疑。对于“轻量 Emacs 替代”这一需求，qemacs 与 mg、dumb-jump 组合的取舍值得实测对比。

5. GPT-6 系列的训练范式：有群友分析了 OpenAI 的训练方向——“每次训练叠加一个专业领域，让基模在该领域实现突破”，并引用 JYY 课程与 Noam Brown 访谈。这一“领域叠加”假说若成立，对理解大模型能力跃迁路径有重要参考价值。

观点延伸

今天值得记的不是两家又发了什么模型，而是两条看似无关的主线给出了同一个教训：当底层单位和你想要的体验不匹配时，别急着改造底层——把不匹配的部分拿到上层自己承接，往往是唯一能落地的路线。Emacs 这边的底层单位是“行”，订阅制那边是“限额窗口”。

一、Emacs 的水平与垂直之差，是抽象层次之差，不是性能之差。

水平方向能做到像素级，是因为字形自带像素坐标、可以被裁切；垂直方向卡住，是因为重绘以行为单位组织：行高可以被内容撑开，但内容的垂直定位不脱离行边界，拖拽因此被吸附到行上。垂直也不是完全没有像素通路——本机 Emacs 30.2 的 set-window-vscroll 就带 PIXELS-P 参数，pixel-scroll 模式证明视口能按像素滚——但那动的是视口不是布局，而定位类 API（如 vertical-motion）的单位仍是屏幕行：能滚得顺，不等于能排得自由。这个区分直接决定投入方向：把垂直交给文本流（行高、行间距）而不是重绘引擎，成本低得多，除非某个交互真的需要高频的亚行定位。

二、“静态页一键转文本应用”的卡点在渲染之后。

群里已证明布局层能对齐前端（flex、grid、overflow 语义基本一致），说明渲染不再是主要障碍。真正剩下的硬骨头是事件语义（焦点归属、输入法、按键消费）与并发模型（单线程命令循环下，一个长任务会冻结整个“应用”）。验证成本很低：拿一个带表单和异步提交的真实页面转一遍，如果卡在状态机而不是布局，就说明瓶颈已经不在 Emacs 的渲染能力上。

三、订阅额度是被设计出来的资源，用户能赢的只有调度。

backend reset 的“最划算用法”、对重置时机的怀疑（偏偏选在你快要自然重置的时候），指向同一个结构：厂商卖的不是产能，而是一个可以调整开合时机的窗口。用户的对策只剩调度——快模型执行、强模型定边界、按月轮换——但调度有成本，“来回切不了”“时不时封号”就是这份成本的实测。多厂商路由不是免费策略，它本身是需要维护的工程。

四、高价模型必须配一条便宜的力工产线。

“Claude 需要一个合适的力工模型”这句吐槽最值得记：阶梯不完整、只有贵的那一档强，用户就会把贵档压缩到关键决策点，其余工作流向阶梯完整的厂商。Luna 降价能引发“比 DeepSeek 还便宜”的惊呼，正是因为它补的是阶梯底端。

可继续研究/实践的方向：给“另起一层”定一个成本阈值。模型侧记录每次切换的隐性开销（重灌上下文、重跑失败任务）与任务本身消耗的比值；Emacs 侧统计一个交互里真正需要亚行精度的次数。超过阈值才值得改造底层，低于阈值，“上层承接”就是对的答案。