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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 跨平台下划线渲染的改进与 patch 融合

群内持续围绕 Emacs 的 wave/line underline 缩放行为展开讨论，并涉及 X11、PGTK、Haiku 等平台的代码实现差异。

• 背景：不同 face 的大小可能不同，传统 line underline 会随字体加粗而加粗，但 wave underline 不随字体缩放而缩放，造成视觉不一致。有开发者认为 wave underline 也应随字体缩放，但实现上遇到平台差异。
• 关键进展：群友表示已成功为 PGTK 和 X 写了 patch，但 X 的 patch 存在缩进问题（Get underline thickness 下的 if else 少缩进了一个空格），准备发邮件讨论一个 flag 变量并默认关闭，期望合并入 master。有群友指出 Windows 上的代码疑似直接从 X 拷贝而来（“换了一个前缀”），暗示跨平台代码复用困难。
• 痛点：代码复用性差，无法统一定义一个 flag 变量控制行为；字体缩放下，wave underline 在不同平台表现不一致，尤其在 LSP 场景下细线几乎不可见。
• 观点分歧：有人坚持“underline 应随字体缩放”，也有人认为“一致大小的 underline 更实用”。最终讨论集中在实现细节与合并策略上。

主题：被动式 spam checker 成效显著

• 群友分享其开发的被动式 spam checker（机器人 @meat_inspector_bot）已成功处理 115 条广告消息，并自评“本群 spam 问题已彻底解决”。但随后出现多次 /top@meat_inspector_bot 指令，疑似进行积分/排名查询，暗示该机器人可能还有活跃度统计功能。
• 命名吐槽：有人觉得 meat inspector bot 这个 ID 有点土，但“土一点也挺好玩儿”。

主题：Mac 上的诡异卡顿排查（Web Slop 与系统资源耗尽）

• 群友抱怨在 Mac 上 Emacs 操作卡顿，连带 Firefox 也卡，内存占用仅 1/3，CPU 空闲，但重启后一切恢复。
• 群友分析：这可能是 web slop（页面或网页脚本突然高资源占用）所致，很多应用（如 Slack、浏览器）会在某时间点异常消耗资源，且不一定持续高 CPU。建议用 btop 监控 CPU，并检查 /tmp 磁盘 IO、node 进程、显卡硬解导致的降频等。
• 有人指出风扇不转（无风扇设备），因此温度降频的可能性较低；也有群友吐槽“vibe coding 魅力时刻”形容这类问题难以定位原理。

主题：Haiku 操作系统与 Emacs 支持

• 群聊从 Emacs patch 延伸到 Haiku 操作系统的讨论：Haiku 仍在更新，最近获得硬件图形加速，Emacs 近期也新增了对 Haiku 的支持。
• 群友评价：Haiku“自成一派”，比 ReactOS 更好；但代码复用问题让开发者头疼，例如无法统一 flag 变量。

主题：dired 删除/打开大目录的慢速问题

• 群友吐槽 dired 删除大目录很慢，打开大目录也慢，怀疑与回收站 flag 有关；有人类比 Finder 也慢，可能为系统级文件操作瓶颈。

🔑 关键概念与技术解析

• PGTK：Emacs 的纯 GTK 图形后端（Portable Graphics Toolkit），用于跨平台 UI，在讨论中指代 Linux 下的 GTK 版本实现。
• Wave underline / Line underline：Emacs 中用于标记错误/警告的波浪下划线与直线下划线。Line underline 读取字体自带的下划线厚度，加粗时随之加粗；Wave underline 目前不随字体缩放，导致在不同字体大小下粗细不均。
• Slop page：指浏览器或应用中突然出现的高资源消耗页面/脚本（web slop），通常表现为 CPU 或内存峰值，但难以定位具体来源。
• Spam checker（被动式）：一种机器人机制，被动监听群消息并识别广告/垃圾消息，而非主动触发命令。本例中已处理 115 条广告消息。
• Haiku：开源操作系统，继承 BeOS 设计理念，近年加入硬件图形加速，Emacs 已提供支持。

💎 碎片知识与金句拾遗

• “用这个来搞开发想必很风味（”——疑似对某工具/配置的调侃，无上下文。
• “土一点也挺好玩儿的”——对 meat_inspector_bot 命名的态度。
• “这个功能是我最讨厌的 vscode功能”——针对 GitHub 上的 preview-tab 项目，群友吐槽预览标签页功能。
• “代码复用不了这个太难受了”——开发者对跨平台 Emacs patch 维护的感慨。
• “我觉得对于浏览器来说，找出 slop page 是一个很有用的 feature”——针对 Web 页面资源消耗的痛点。
• “哪有什麼原理，vibe coding 魅力時刻”——形容某些难以排查的卡顿问题，源于“随性编码”带来的隐患。
• “估计不如reactOS😈”——对 Haiku 质量的半开玩笑质疑。

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

• Emacs wave underline 缩放 patch：已有 PGTK 和 X 的初步实现，但尚未统一 flag 变量。可关注后续合并情况，以及 Haiku 平台是否同步支持。
• 被动式 spam checker：设计思路值得参考（如监听消息频率、关键词匹配、自动处置），虽未公开细节，但 115 条处理记录表明有实用价值。
• Haiku 上的 Emacs 质量：随着硬件图形加速推进，Haiku 平台可能成为 Emacs 的轻量级跨平台选项，但代码复用仍是痛点。可关注未来 patch 动态。

观点延伸

今天群里三条线——Mac 上的诡异卡顿、被动式 spam checker 的"彻底解决"、wave underline 的跨平台 patch——其实共用同一个坑：度量面选错了，就会同时得出"一切正常"和"问题已解决"这两句假话。

一、内存只占 1/3、CPU 空着，却连敲 cmd+space 都要等几秒，说明监视器看错了地方。 卡顿发生在延迟维度，而内存和 CPU 是容量维度，两者本来就不该用来否证卡顿。群里顺手给的三条排查方向——临时目录的磁盘 IO、常驻的 node 进程、独显硬解导致显卡过热降频——恰好全是默认监视器的盲区。所以"系统本身没有问题"这句判断，在缺少等待时间数据的时候根本推不出来。下次卡的时候别先看用量，先抓一次磁盘等待与进程快照，证明到底哪一维真的异常。

二、"处理了 115 条广告"是处理量，不是解决量。 要支撑"彻底解决"，至少需要一天的"广告进入数"前后对比；处理量高既可以说明问题严重，也可以只说明检出能力强，单看这个数字分不开。更值得记下的是紧接着发生的事：同一批人开始刷积分排名——当一个治理工具自带积分激励，它就不只是过滤器，还会改变发言动机，而这份副作用不在那个 115 里。工具的成功声明和它的真实效果之间，通常差的是一条时间序列。

三、wave underline 的 patch 撞上"代码复用不了"，是抽象欠账到期的账单。 同一套下划线语义要在多个后端各实现一遍，连一个统一的开关变量都放不下；而两个平台的实现几乎一模一样、只换了前缀（连缩进少一个空格都跟着复制过去），说明问题不在平台差异，而在当年是复制而非抽象。作者选择的路径是"加一个默认关闭的 flag，先合入 master"，工程上这是对的：先让行为可配置、可回退，语义统一放到第二步。别把"先合并"看成妥协，它是把一次性正确压成可持续迭代的正确。

可继续研究/实践的方向： 给这三件事各立一个最小可测基线——卡顿当下抓一次磁盘等待与常驻进程快照；用"每日广告进入数"而非"处理数"评估反垃圾效果；用同一段文字在多种字号下渲染四种下划线并截图对比粗细是否随缩放变化。三件都不用读源码，但都能把"我觉得"换成"测出来"。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：AI 模型混战——Opus 5.5 的登顶与 GPT-6 的失意

本日讨论围绕多个 AI 模型展开激烈对比，核心战场集中在 Claude Opus 5.5 与 GPT-6 (astra) 的较量上。群友普遍认为 Opus 5.5 在代码生成、重构和克制性上表现突出，而 GPT-6 则“食之无味，弃之可惜”。有群友指出，Claude 官方社交账号下被大量评论与 Opus 5.5 对比，批评 GPT-6“不行”，这种舆论压力主要源于用户从 Anthropic（A/）迁移过来的核心原因是“降智”。Opus 5.5 的额度耐用性也获好评，“5x”的消耗速度（对比 codex 的一天耗尽）成为亮点。

另一条线索是 Gemini 与 DeepSeek 的实战体验。有群友分享用 Gemini 3.8 改 Rime 方案“一把过”，但多数人吐槽 Gemini“每次拍彩虹屁”，适合当 Wiki 或教学工具。DeepSeek 4.1 Flash 则在自动化任务和 Emacs 配置上表现超出预期，甚至有群友将发布流程（从规划、录屏、控制终端到发布 Telegram）全权交给 DS 实现，并固化为技能，一句话即可完成全链路。

专题：Emacs 生态的“野性”创新——excal-mode 与海洋模拟引擎

本日最具技术亮点的自研项目是 excal-mode——将 Excalidraw（流行白板工具）移植到 Emacs。开发者 @yibie 采用手搓 SVG 方式而非依赖原版 Node 服务，以规避繁琐的运行时依赖。该模式支持光标形状变化，但仍有瑕疵（光标形状切换不灵敏），且需要做 evil 适配。群友 @lyraile 被邀请内测，并积极反馈问题（如左右滚轮方向、多窗口 buffer 状态同步）。

另一个令人惊艳的项目是 海洋模拟引擎——基于 Three.js（非 Rust）构建，实现了云层、天空色彩自然过渡和水体反光效果，被群友评价为“很真”。这两项创新展示了群内开发者“多搓自己会用的软件”的极客精神。

🔑 关键概念与技术解析

• Opus 5.5：Claude 的最新模型版本，被群内多数开发者视为代码生成和重构的“神”，强调克制性和省心程度，额度消耗远低于 GPT 系列。
• GPT-6 (astra)：当前 GPT 旗舰模型，但在本群口碑不佳，被认为是“降智”产物。仅 Astra Max 级别“才有点用”，额度消耗极快（“一天就能用完”）。
• Gemini：谷歌模型，被群友吐槽“每次拍彩虹屁”，适合作为 Wiki 或教学工具，而非严肃的代码助手。部分人利用教育优惠薅免费额度。
• DeepSeek (DS) 4.1 Flash：国产模型，性价比高，擅长自动化任务和配置修改（如 Emacs、Rime），但“说人话”能力弱于 GPT，需配合动态上下文压缩使用。
• treesitter：Neovim 的语法解析引擎，每次升级都可能导致插件损坏，需自行编译——群友吐槽“每个版本都要自己编译”。
• excal-mode：Excalidraw 的 Emacs 移植版，通过手搓 SVG 绕过 Node 服务依赖，实现无限白板绘制。
• omarchy：群友热议的“智能路由系统”概念，一刷推全是相关讨论，甚至朋友圈已有卖课者。部分群友反感该词，想屏蔽。
• computational arts（程序绘图）：区别于手绘，通过分形杂色、特效插件等方式生成图像，群友认为 AI 是更通用的程序绘制工具。

💎 碎片知识与金句拾遗

• “没有一丝想用 astra 的欲望🙁”——对 GPT 新模型的直接失望。
• “claude 的最大的问题是它敌视中国，这意味着即使你现在没被封，未来它一收缩口径之后，你就被封了”——群友对 Claude 地区政策的警惕。
• “gemini 每一次都拍彩虹屁”——对其对话风格的精准吐槽。
• “deepseek 跟 sol-6 差不多，性价比高点，但是要控制上下文，弄动态压缩”——实用的 DS 使用技巧。
• “我天天用手指打字，为什么我的手指没有变得很强壮？”——引发群友关于肌肉锻炼与关节磨损的趣味讨论，结论是打字强度主要损耗关节而非肌肉。
• “跑步伤膝盖，打字也是关节磨损”——类比到位。
• “画图这种，我现在都懒得画图，都是 AI 搞”——反映 AI 对设计流程的渗透。
• “我的高雅 emacs logo 就是我画的”——群友展示自己的程序绘图作品。
• “obsidian canvas 已经解决 99% 画图问题，没用过的可以试试。”——白板工具推荐。
• “朋友圈已经有卖课的了，基于 jev 的智能路由系统”——透露热点项目已出现商业包装。
• “是时候再次拿出这张图了”——疑似吐槽某个重复性讨论或模型对比。
• “这个画出来的手绘风思维图很好看”——对 excal-mode 的实际体验反馈。
• “一个 buffer 显示在多个窗口里需要考虑一下，设置多个 view 分窗口渲染”——excal-mode 开发中的技术难点。

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

• excal-mode（GitHub: yibie/excal-mode）：Excalidraw 的 Emacs 原生移植，目前处于内测阶段。核心创新在于“手搓 SVG”绕过 Node 服务，若成熟可成为 Emacs 生态中稀缺的轻量白板工具，值得持续追踪其光标状态管理和多窗口渲染解决方案。
• 海洋模拟引擎：基于 Three.js 的实时水体渲染，已实现云层、天空渐变与水体反光，具备“很真”的视觉效果。若后续开源，对前端图形学爱好者将极具参考价值。
• DS 自动化工作流：群友将“发布规划→录屏→控制终端→准备文案→发布 TG”全流程交给 DeepSeek 固化技能，实现一句话自动化。这种“探索一遍固定为技能”的模式值得借鉴，尤其对非技术用户有启发。
• 智能路由系统（omarchy/jev）：群内热议但语焉不详，朋友圈已有卖课者，暗示其商业热度。未来值得关注其底层模型调度逻辑，以及是否与“派发任务给低级模型”的省钱策略有关。

观点延伸

中心判断：模型是耗材，工作流是资产。 这一天群里花口舌最多的是给各家模型打分：好评的维度是“省心”“克制”“额度耐用”，差评的维度是“max 以下没法用”“额度一天就见底”“每次都拍彩虹屁”——全是运行时属性，没有一条在说它更聪明。模型之争已经变成采购题，比的是可预测性、账单和访问权。真正值得细读的，是当天几件不起眼的小事。

其一，把“选最好”换成“随时可换”。 额度上，有人“猛用几天还剩 30%”，有人说“一天就见底”，还有人怀疑用量表本身有 bug；另一条提醒更冷：账号与访问权可能随服务方收紧口径而消失。当额度与政策都是黑箱时，“当前最强”这个判断自带保质期。对策不是再选一次，而是把选择挪到接口层：流程和技能按“换模型只改配置”来写，而不是按某家的脾气来写。

其二，探索一遍就固化，才配叫技能。 当天最有说服力的案例，是一条被固化成技能的发布流水线——规划、录屏、终端操作、文案、发布，一句话全部跑完。它夹带了一条容易漏读的约束：无论是任务路由还是技能固化，都不能反过来增加高级模型的消耗，技能要能被便宜模型稳定重放。这句话可以倒过来当质检标准：一个流程如果只在你和最贵模型的默契里成立，就还不是资产；能被便宜模型跑通，抽象才算过了关。

其三，重写买来的不是复刻，是调试权。 之前还在群里讨论思路的 Excalidraw 移植，今天已经进入内测；作者宁可手搓 SVG，也不愿为原版起一个 Node 服务。这不是倔，是拿重写换运行时主权：能在自己的语言里改，能跟着编辑器一起演化。真正的难点也不在画线，而在状态映射——“一个 buffer 显示在多个窗口、每个窗口一个 viewpoint”，本质是把外部应用的对象模型对齐到 Emacs 的 buffer/window 模型。判断标准很直白：当工具进入每日回路、上游节奏又不归你管时（当天就有人吐槽语法解析引擎一升级就坏、每个版本都要自己编译），自持就是买保险。

可继续研究/实践： 挑一个已有的一键自动化，用当前最便宜的可用模型完整重放一遍，把需要你临场补的上下文逐条记下来——那份清单就是你真实的技术债；把它写回技能，再重放一次。当流程不再需要你临场补位，它才算真正属于你。