Emacs 社区日报 2026-09-24

约 5565 字大约 19 分钟

2026-09-24

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

🎯 核心热点与专题探讨

本次群聊主要围绕 Telegram 群组 spam 治理 和 Emacs 生态 两大主题展开，其中 spam 治理是贯穿全天讨论的主线。

【专题】Telegram 群组 spam 治理：从被动防御到主动智能检测

群成员花了一整天讨论并实践 spam 检测 bot 的迭代方案，期间经历了思路转变、新旧 bot 对比和实际问题排查。核心脉络如下：

问题背景：群内 spam 泛滥，一晚上涌入 10 个不说话的新号，一星期可积累上百 spam。这些 spam 号通常不说话、名字是随机单词，触发时才发言或改名，传统的验证码/被动检测已无法应对。
方案演进：群主开发了一个基于 LLM（DeepSeek）的检测 bot，思路是 限制检测新用户前 3 条消息（以及期间 username、nick、emoji、bio 的改动），超过 3 条就放行——既防误判，又节省 token。这被称为"被动 antispam"。
主动 vs 被动：有人提到 nmbot（第三方 bot）也可用但"不太信任""抽风严重"，进而讨论 主动 antispam + 被动 antispam 的组合——类似杀毒软件的设计哲学。最终群主决定自己从头写一个可控的 bot，并计划"明天中秋开始激情 coding"。
资源瓶颈：nmbot 服务群太多导致抽风，类似 bridge 的情况——只服务单个群组时可靠性会高很多。这引申出一个通用规律：bot 好用则用的人多，资源紧张就抽风，所以关键群组必须自己搞专属 bot。
执行细节：新 bot 的日志频道用于围观封禁日志；封禁时同时删除消息；解封操作偶发失效（疑似 Telegram 客户端卡顿）；有群友希望 bot 增加"扫描所有已进群的 bio/nickname"功能，但未获明确回应。

群友们对这个自建 bot 的成效颇为满意："感觉群里清净了""看着新 bot 封禁 spam 感觉很爽""spam 出现又马上死了"。

【专题】AI 编程时代的代码 review 困境

随着 AI 生成代码能力增强，群友们的 review 习惯发生明显变化，讨论热烈：

现状两极分化：上班代码"不 review 要背锅"（有人用 magit + ediff、有人用自写 Emacs 包），但自己写玩具代码"完全不 review，运行出问题让 AI 修"。有人总结：去年 AI 能力差时自己还 review，今年能力上来后就不 review 了。
Review 策略：几千行 AI 生成代码"review 一天"不现实，有人主张"看思路和架构问题，细节靠单测"；有人推荐 Hunk.dev（支持 plan 时拆分 checkpoints，review 更轻松）；还有人开发了 Emacs 包配合 AI 主动读代码。
AI 测试的信任危机："AI 写的测试太假，基本是无用测试，不如打印日志"——群友更倾向于运行时日志而非自动测试来发现问题。
未来展望：有人调侃"等锅出来，人还在不在都不知道"，也有人表达乐观——"对未来预期还是偏正面"。

其他话题

Emacs 跨平台体验：Windows 上 Emacs 性能问题（magit 操作 0.5-0.3 秒延迟），对比 vscode/helix/kakoune 的默认配置；有群友分享在 Windows 上通过调优选项大幅提速。Emacs 在 Windows 上 IPC 未实现（命名管道替代），term.el、emms 等包会出问题。有人吐槽 WSLg 的输入法问题（fcitx5 preedit 绘制异常），也有人建议"Emacs 不适合放 Windows，放 WSL2 最稳定"。
远程开发方案：TRAMP 太慢，有人推荐 emacs-tramp-rpc（持续连接方案），有人用 tailscale + waypipe 实现远程 Emacs GUI 渲染到本地（emacsclient -c 直连），效果良好。
Lisp Machine 的怀旧与反思：群友讨论复兴 Lisp Machine 的可行性，结论是"现在反而是最差的时代"——AI 时代大家写提示词，不再需要 Lisp 的 code-is-data 哲学；且 Symbolics 当年做硬件拼不过 Intel，硬件层面无望。

🔑 关键概念与技术解析

MTProto API：Telegram 的专有通信协议，bot 可以直接使用。群主提到"在 bot 项目里尽可能不用 mtproto api"，倾向于使用更规范的 Bot API（HTTP）而非底层协议。
patdiff：Jane Street 开源的高级 diff 工具（OCaml 编写），输出格式比 git diff 更智能、更结构化。群友认为它可以作为 git 默认 diff 引擎，但"输出格式不一样其他工具肯定用不了"。
waypipe：Wayland 下的远程渲染工具，类似 X forwarding 的现代替代品，配合 tailscale 打洞可实现远程 Emacs GUI 本地渲染。
emacs-tramp-rpc：通过 RPC 持续连接替代 TRAMP 的逐命令 SSH 连接，大幅减少延迟——但 rg 等工具扫描大目录时仍会卡顿。
Hunk.dev：开源 AI 代码 review 工具，支持 plan 时拆 checkpoints，review 时按 checkpoint 审查，提升效率。
MHS / MCP：MCP（Model Context Protocol）用于连接软件，MHS 对应连接硬件——"连接现实的"。
nmbot：第三方 Telegram 管理 bot，因服务群过多导致不稳定，"该退役了"。
luna / astra / ds4.1 flash / gpt-6-luna：群友讨论的 AI 模型代号。大肥鱼（ds flash？）作为 workhorse 很稳，但提示词要求完备；luna 便宜且买 Astra 赠送。

💎 碎片知识与金句拾遗

代码 review 方法论：超过 1000 行就让 AI 拆解，看不懂就让 AI 解释，再不行就问"为什么这么简单的需求用了这么多代码？列出每一行的必要性。能简化么？"
AI 时代生存哲学："本来是想让 AI 干杂活的，现在我们变成干杂活的了"；"古法编程的方式已经彻底死了，但是语言还是得学"；"啥开心做啥就行"。
AI 社会隐忧：有群友预言"AI 长城已经在建了"，担心未来 AI 使用会被限制——"最担心的事，什么时候限制 AI 的使用"。也有人调侃："也可能是 AI 防沉迷成年人保护""AI 供给制，凭票兑换 token"。
Lisp Machine 考古：Symbolics 当年意识到做硬件拼不过 Intel 就放弃了；Lisp Machine 最底层仍是通用指令集。
Emacs 配置技巧：Telega 显示表格可自定义符号：(setq telega-symbol-rich-text-table-border '(?─ ?\s ?\s))，视觉效果大幅提升。
Helix 编辑器维护状态：主分支"几个月没有动静"，Reddit 上有人发帖问"is_the_helix_project_abandonned"，群友感叹"其兴也勃焉其亡也忽焉"——"蓦然回首，Emacs 就在灯火阑珊处"。
AI 额度经验：ChatGPT 额度"上个月用不完，这个月快完了"；有人通过合租方案将 AI 月开销控制在 1000 元以内；也有人公司有约 1000 刀的 API 额度，"够用一星期"。
Windows 上的文本替换工具：Espanso 好久没更新但"找不到更好的"，后来发现 GitHub 仓库其实还活着。
输入法补丁被拒：群友提交的 Windows 输入法合成窗口（preedit text）绘制补丁被上游拒绝，计划日后再次邮件询问。
影评式观察：有人提到小时候看过纪录片 Earth 2100，预言能源危机、石油耗尽、人口爆炸——"纪录片里预言的这个未来没有发生"，对未来的预期偏正面。

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

基于 LLM 的 antispam bot 设计：群主自建的 spam 检测方案（检测前 3 条消息 + 资料改动，超过则放行）是一个低成本、防误判的实用思路，值得跟进其后续迭代与开源情况。
emacs-tramp-rpc 与 waypipe 远程开发组合：TRAMP 性能瓶颈是远程 Emacs 的痛点，RPC 持续连接 + waypipe GUI 渲染的组合方案具有普适价值，值得深入测试。
patdiff 作为 git 默认 diff 引擎：Jane Street 的 OCaml 工具能否适配 git 生态，是 diff 体验升级的潜在方向。
hunk.dev 的 checkpoints 式 review 流程：AI 生成代码量剧增的背景下，"plan 时拆 checkpoints" 的 review 方法论值得借鉴和推广。
AI 模型成本控制方案：合租 20x 计划将月开销控制在 1000 元以内，配合 API 计价与本地模型部署（如 ds flash），是个人开发者值得研究的成本优化路径。

观点延伸

今天两条最有张力的线——自建反 spam bot 与 AI 代码 review——其实是同一件事的两面：生成已经太便宜，稀缺的是验证。批量账号在批量生产内容，模型在批量生产代码，两者都把审查侧（管理员、reviewer）变成瓶颈。今天的具体做法，本质都在回答三个问题：让验证可负担、可独立、可自持。

一、验证要控预算，也要赌暴露时机。 新 bot 只把新用户前三条消息（及这期间的资料改动）送进模型判断，超过就放行。这不是偷懒：发言过三还没露馅的，是 spam 的后验概率已经很低——省成本、防误判都是副产品。更底层看：这类账号不说话就没有可检测的表面，唯一窗口是它开口或改名那一刻；所以「被动」不是退步，而是把「等它暴露」当成主策略。这和「几千行 AI 代码没法 review 一天，只能看思路架构」是同一取舍：把验证预算投在信息量最高的位置。

二、验证信号不能和被验证对象同源。 有人把细节交给单测，也有人断言「AI 写的测试太假，不如打印日志」——问题不在单测，在测试由谁生成。测试与代码同出一个模型时共享盲区：通过只证明模型自洽，不证明程序正确；日志来自真实运行，才是独立证据。换一个不同源的信号，比加大验证量划算得多。

三、关键设施要专用，不要共享。 第三方管理 bot 抽风的原因很朴素：好用的 bot 用的人多，资源一紧就集体降级。这不是哪一家的问题，是共享设施的固有规律——可靠性随服务规模衰减。关键群就得自建专属 bot，和个人维护自己的 Emacs 配置一样，都是把生存依赖握在自己手里。群里还问到跨 bot 状态残留：被封用户留在验证 bot 的数据怎么办——这类耦合要显式设计协议，不能靠「应该会自动删吧」。

可继续研究／实践： 把「前三条」从拍脑袋常量升级为数据支撑的阈值：统计封禁样本的触发位置分布，用分布反推策略；给 bot 之间定一份带 TTL 的状态协议，让检测、验证、日志不打架；存量账号的资料回溯扫描也值得先全量做一次。群里那句「古法编程的方式已经彻底死了，但是语言还是得学」可以续写：今天该学的，多半不是怎么写代码，而是怎么读懂和验证它。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

1. AI 模型军备竞赛：Opus 5.5 vs GPT 系列

全天讨论最激烈的话题。清晨有人惊呼 Opus 5.5 通过 demo 页面拉取了项目代码、反向解析客户端代码，随后围绕模型能力、价格、token 消耗展开大量讨论。

Opus 5.5 的能力表现：群友普遍认可其代码分析、审美能力和“说人话”的水平。“刷推怎么全是吹opus5.5的”“是真的强！！！”等多条消息印证了它的强势地位。
价格与 token 消耗：有消息称 Opus 5.5 与 GPT 新模型相比 token 消耗变少、同比便宜 40%。但多位群友反映账号被封、额度不够用，有人从 ChatGPT Pro 降级到 DeepSeek 配合 Claude Code，感叹“贫穷让我放弃了原则”。
GTP 新模型消息：晚间出现了关于 GPT-6-sol、GPT-6-luna 的讨论，但群友普遍认为“没什么卵用，Opus 5.5 赛高”。也有人吐槽 ChatGPT 网页版 Chrome CPU 占用爆表。

2. 偶像文化与国内“养成系”畸形生态

因游本昌去世的消息引发关于表演艺术本质的讨论，随后转向对国内偶像产业的批判。

群友回顾游本昌“把表演当作艺术工作”的纯粹，对比“小鲜肉”“养成系”的浮躁。有人指出国内养成系是“粉丝养着”“一年到头跟巨婴一样”，而日本 AKB 的偶像文化“真的能激励一代人”，核心区别在于“陪伴”与“成长”，国内搞的是“提纯和圈养”。
有人吐槽某演唱会票价 699 只是基础票、绑一堆东西总价 4000，质疑“需要花四千买个超距或望远镜去看”。也有人提到 Ado 的线下演唱会想去体验，群友推荐了韦唯（机能相近）。
卢修斯（Lucius_Chen）提到鲁迅若是再生，“我会花这么多钱听他一次讲座”，不过有人提醒“文人要脸的，只赚稿费”。

3. VPS、机场与网络线路的实战分享

围绕 dmit 补货展开，聊到了 CN2/CMIN2 线路区别、搬瓦工（bwg）对比、机场封 SMTP 端口等问题。

dmit 补货：洛杉矶 $10.9 套餐引发抢购，“GIA CN2 10刀还要啥自行车”。有人提醒“只有 pro 和 eb 有（优化线路），千万别买 t1”。也有消息指出 1000GB 流量用完后从 1Gbps 降为 4Mbps，但“更有吸引力了”。
机场 vs VPS：有人推荐 inets.io，卢修斯提醒机场通常封禁 SMTP 端口（VPS 也可能封）；有人提到用 SMTP2GO 解决发件问题。一位群友想用国外服务器做 SSH 代理翻墙，卢修斯吐槽“恭喜你发明了 SSH 转发，20 年前大家都是这么翻墙”。

🔑 关键概念与技术解析

Opus 5.5：当晚讨论的核心 AI 模型，Anthropic 发布的新版本。群友评价其代码分析、审美能力大幅提升，token 消耗减少、价格同比便宜 40%，被视为当前最强模型之一。
GPT-6-sol / GPT-6-luna：OpenAI 当晚发布的新模型，据称比之前便宜 40%，但群友评价“没什么卵用”，更认可 Opus 5.5。
CN2 / CMIN2 / GIA：网络线路优化术语。CN2（中国电信下一代骨干网）、CMIN2（中国移动国际互联）均为面向中国大陆的优化线路，GIA 是 CN2 的一种高级线路类型，延迟和稳定性通常优于普通 T1 线路。
telega：Emacs 上的 Telegram 客户端，有群友在调试其 nil bug，设置 (setq telega-server-optimize 31) 似乎可缓解问题。
diffs.el：Lucius_Chen 维护的 Emacs 插件，用于查看 git diff 并支持 AI review，群友请求添加 annotation 功能。
magpie：yetone（avante.nvim 作者）的新项目，疑似 AI gateway，消息中附带了 GitHub 链接。
jj（Jujutsu）：Git 的替代版本控制工具，速度快于 Git。卢修斯提到“我是直接让 agent 来用的”，表示传统 Git 肌肉记忆难以迁移。

💎 碎片知识与金句拾遗

关于日记本价格：有人感叹“168 块钱的日记本”贵得离谱，但群友指出“能写完一本继续买不贵，一辈子一本也不贵，贵的是没写继续买”——这句话被多人引用，像是某种消费心理的洞察。
关于初代手帐文化：小仙女们的手帐周边购置下来“没有个 2 万基本配置下不来”，有群友评论“女生是这样的，从小就是富养”。也有人聊到拼豆为何能火，“不就是小时候玩的”，另一人解释“小仙女们想要晒，动手能力不行，拼豆终归还是会的”。
QQ 号的情感价值：有人注销 QQ 号是因为“空间里东西太多”，但另一人表示“我 qq 号 5 位数，舍不得 😃”。
关于“嘉豪”行为：有人发知乎链接问“现在风气这么差么，用个 vim 都成嘉豪了”，群友指出这是“2024 年的新词”，日常用 Linux 也可能被叫“嘉豪”，还调侃“用 emacs 岂不是更 + 号”。
关于“软件工程不存在了”：有人感叹“完全不知道软件工程这课的项目怎么做”，另一人回应“软件工程确实是不存在了”，第三个人补一句“现在是‘生成式软件工程’”。
关于年龄与“片”：群友感慨“片看来看去都是老片，真实年龄估计都 40 多 50 了”，另一人回应“年纪大了喜欢看点青春荡漾、快乐无边、充满笑容的”。
关于“AI 让我好好上班”：有人想让 AI 帮想“来钱路子”，结果“AI 让我好好上班”，群友劝“累了就歇一歇，不要胡思乱想”。
关于“跑得快”：分享去年 12 月 48 小时内退款 18000 元人民币的经历，随后 Google Play 不再退款，总结“自己充值也没啊，幸好我跑得快”。
关于“星链”与“无人机黑飞”：有人提到“无人机黑飞管控很严”，未展开但暗示政策收紧。
关于“四川话”：群友说“提前翘班，喷喷启动”，别人差点当成 spam 按下 B 键，“结果发现一是熟人，二俺没权限”。
关于“阿米巴”：有人想“写一个 runtime 能计算真实小说人物实时状态的 DSL 让大模型去读”，卢修斯详细解释“定义一种 DSL 将标记事件的东西都放入 DSL 内部……甚至可以查询物品物权移交”。

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

magpie (https://github.com/yetone/magpie)：AI gateway 新项目，由 avante.nvim 作者开发，值得关注其架构设计与用途。
diffs.el annotation 功能：Lucius_Chen 的 Emacs diff 查看插件，群友请求添加 annotation，可能提升 AI review 工作流。
小说人物状态 DSL：卢修斯提出的“将小说人物状态放入 DSL，暴露 Language Service 给 Agent 用”的设想，属于前沿的 AI 辅助创作领域，具有潜在的研究价值。
jj（Jujutsu）作为 Git 替代：群友已经在用 agent 操作 jj，值得评估其性能与生态成熟度。
dmit 洛杉矶 $10.9 套餐：结合 CN2 线路，性价比极高，适合需要低延迟回国线路的玩家。但需注意流量超额后降至 4Mbps 的限制。

备注：以上内容基于 2026-09-24 的群聊记录整理，部分讨论涉及敏感话题（如翻墙、退款操作）已做脱敏处理，仅保留技术信息。

观点延伸

今天最值得咀嚼的不是 Opus 5.5 的强弱，而是记录里两句话并排时的张力：一句自嘲说「软件工程确实是不存在了」，紧接着有人接梗「现在是生成式软件工程」；另一句设想是「写一个 runtime 计算小说人物实时状态的 DSL 让大模型去读，会不会比 memory 靠谱」。我的判断是：软件工程没有消失，它只是从「写给人用的程序」转向「写给 agent 用的状态与接口」，而这恰好是最难被替代的部分。

一、memory 的替代品不是更大的上下文，而是可计算的状态层。 「比 memory 靠谱」的直觉可以落到工程上：memory 是检索加概率，答案不可复现；而把事件收进 DSL、文字拆成 Block、由 Language Service 计算「人物此刻在哪、东西归谁」，本质是事件溯源——文本是事件日志，状态是对日志的折叠。「物权移交」是这段话里最妙的词，因为它天然适合被建模成事件序列，而不是一句自然语言描述。这个模式不限于小说：任何长期迭代的文本知识库，都值得有一个可查询的状态层，而不是让模型每次都去长文里重新捞。

二、真正的难点不在 DSL 语法，而在一致性。 文字改了，状态由谁负责？事件是模型生成还是人写的？只要允许模型写入事件，就必须有运行时校验：不可能的状态应当被拒绝，而不是被悄悄记下。能拒绝非法状态，才配叫 runtime；否则只是一个换了名字的日志文件。

三、「我让 agent 来用」正在重写工具选型标准。 群里上手 jj 时那句「我是直接让 agent 来用的」，「自己手敲的话完全不知道咋用」，加上「git 时代的老登，已经形成了肌肉记忆」，说的其实是同一件事：有肌肉记忆的人被学习成本挡住，而 agent 没有这个成本。于是工具竞争的焦点从「人的手感」滑向「接口的确定性」。但代价常被忽略——肌肉记忆不只是方便，它是审计能力；敲不动的工具，你也无法验证 agent 敲得对不对。稳妥的分工是：写路径交给 agent，读路径（状态、日志、diff）自己留着。

四、别再让 agent 模拟人点 GUI。 「必须回 agent 里运行 diffs-review」和「不想拿鼠标去点聊天输入框」是同一枚硬币：人早把编辑器和聊天窗口当主界面，agent 却只能在门外。群里那句「telega 配合 emacsclient 可以完美操作」给出了正解——把 Emacs 暴露成可调用的服务，比让模型看图找输入框稳得多，也更容易审计。屏幕级操作天生脆弱，命令级接口天生可测。

可继续实践的方向： 给 diffs.el 做一个双向闭环——review 在 Emacs 里发起，annotation 由 emacsclient 回写给 agent，人不用反过来去 agent 侧敲命令。它和小说 DSL 是同一个模式：编辑器和 agent 之间缺的从来不是能力，而是一层双方都能读写的中立状态。