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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 终端改进与 Ghostel 的崛起

群内对终端模拟器“ghostel”的讨论极为热烈，几乎一致认为其在用户体验上优于老牌的 vterm。

• 核心优势:
  • 安全性与交互优化: 例如，与 vterm 不同，ghostel 在输入密码时，Emacs 不会接收到按键事件，从而避免了密码泄露风险。它还支持接入密码管理器。
  • 模式设计: “完全接管按键的模式”允许用户在 ghostel 内部模拟一个完整的 Emacs 体验，被视为设计上的重大进步。
• 争议与痛点:
  • 主题继承问题: 有用户指出，ghostel 不继承 Emacs 的 named face（如 bold face），而是动态拼出 face plist。这导致用户无法通过 elisp 直接修改 ghostel 内部的具体字体样式（如自定义 :weight），这是一个需要关注的细节。

专题二：Emacs 编译与平台兼容性现状

• Windows 编译修复: 近期 Emacs 的 master 分支已能正常编译。一个关键修复（id=689448a0）解决了 Windows 上的编译问题，具体与 msys2 的 gcc 更新导致的 ABI 变动有关。
• Pgtk 与 Wayland: pgtk 分支已经可以编译。关于 Wayland 下高分屏的卡顿问题，群友表示这通常与显卡驱动（尤指NVIDIA）强相关，而非 Emacs 本身的问题。
• Emacs 30+ 新特性:
  • IGC（增量垃圾回收）: 确认尚未合并入主分支，尽管有过相关讨论。
  • Native Comp (JIT): 默认开启，目前无明显问题或关闭需求。

🔑 关键概念与技术解析

• Ghostel: 一个新型 Emacs 终端模拟器，旨在提供高度安全、模式设计更先进的终端体验。它通过更精细的按键事件控制，解决了 vterm 中密码输入等安全痛点。
• Native Comp (JIT): Emacs 28+ 引入的功能，将 Elisp 字节码即时编译为机器码，大幅提升性能。现已默认启用。
• IGC (Incremental Garbage Collector): 一种旨在减少 Emacs 垃圾回收卡顿的技术，尚未合并到 Emacs 主干。

💎 碎片知识与金句拾遗

• 冷门工具推荐: ghostel 被多位群友高度推荐，认为其交互模式设计“更合理”，尤其在密码检测和完全接管按键方面优势显著。
• 特定配置细节: 有用户提到，由于 ghostel 不继承 named face，其界面字体全靠“就地拼出来的 face plist”，导致 :weight light 等自定义配置无法直接生效，是一个有待开发者跟进的问题。
• 真实 Bug 报告: 有人反馈在 Windows 的 igc3 分支无法编译，但 master 分支一切正常。
• Rime 输入法集成: 确认在 ghostel 内部可以使用 Rime 输入法。
• 外部依赖故障: 近期 liberime（Rime 输入法的 Emacs 接口）在 Windows 上无法加载 librime.dll，最终锁定原因为 5月2日 msys2 更新 GCC 导致的 ABI 变动。更新后即可正常使用，并启用了脚本与 octagram 支持。
• 群管理经验: 有用 /sban 指令配合用户 ID 来高效自动清空并禁止特定用户的发言记录。

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

• Ghostel: 建议深入研究其模式接管机制和密码检测功能。其 #password-prompt-detection 文档值得仔细阅读，以了解其安全模型。
• Emacs 的 Terminal 模式演进: 对比 vterm 和 ghostel 的设计哲学，尤其是如何处理按键事件和外部程序交互，对于任何做 Emacs 插件或终端工具的开发者都有启发意义。
• Windows 下 Emacs 的 ABI 兼容性: msys2 与 GCC 的升级对 Emacs 外部库（如 Rime、tree-sitter）的影响是一个持续存在的痛点，值得关注上游工具链的变更。特别是 librime.dll 的加载问题，是一个典型的环境兼容性案例。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：大模型能力大逃杀——DeepSeek vs. GPT/Claude 的“信任危机”

今日群内对 AI 编程助手的能力展开了激烈且充满情绪的讨论，核心矛盾集中在 “模型本身的能力” 与 “Harness/工具的调度能力” 之间的耦合。

1. DeepSeek 的“两幅面孔”

   • 痛点爆发（用户A）： 多人强烈吐槽 DeepSeek 在复杂编程任务上表现“弱智”。核心抱怨在于：它缺乏上下文回溯能力（告知修改错误后不会自动回退）、逻辑连贯性差（明确告知修改位置仍会跑偏），以及中文理解在特定任务上（如从文章提取PPT）表现极差。用户A情绪崩溃：“好久没感受到这么气愤了”。
   • 冷静分析（用户B、C）： 有人指出，DeepSeek 的表现 “和 Harness 有很大关系”。在 Claude Code 的 Harness 里使用会聪明很多。逻辑是：这么便宜的价格，如果模型不行，一定是 Harness 的调度问题，而不是模型本身潜力不行。
   • 价值发现（用户D）： 尽管复杂任务拉胯，但 DeepSeek 在 “文本总结”和“网络搜索/技术诊断” 方面表现极佳，且“关键还便宜”。有人分享实例：DeepSeek 能准确指出 Linux 蓝牙驱动特定内核版本的 bug，而其他模型只会给出通用修复建议。
   • 产业猜想： 众人猜测 DeepSeek 多模态迟迟未出的原因与华为芯片限制有关，或者梁文峰仍在优化纯文本模型。
   • 结论： 社区形成共识：DeepSeek 是极佳的低成本文本处理与精准搜索工具，但在需要长程逻辑、复杂重构的编程任务中，当前的 Harness 与模型配合存在明显短板。

2. GPT-5（Codex）的“降智/重置”危机

   • 现象： 多人报告 GPT 近期“很慢”、“话都听不明白”、“回复速度变快，背后切了模型”。推测因高峰期资源不足，OpenAI 可能将 Pro/Plus 用户悄然切换到低性能模型。
   • 根源与反应： 官方 X 帖子承认是自身问题，暗示 Codex 额度（5小时限制）即将重置。社区反应两极：一部分人欢呼“快点重置，账号快用完了”，另一部分人无奈：“别重置了，来不及用了，蹬冒烟了”。

3. AI 写前端的“噩梦”与“正确姿势”

   • 场景： Codex 被要求画“三根对不齐的线”的简单 SVG/WebGL 图形，但耗费 5 小时 token 仍无法精确对齐，触发群友暴怒。
   • 深层分析：
     • UI/UX 是 AI 的软肋： AI 对 padding、margin 的感性理解极差。截图反馈和测试又慢又耗 token。直接丢任务给 AI 写前端（尤其是 Codex）是“噩梦”。
     • 正确工作流：
       1. 先做人肉原型： 用 Kimi 或其他工具生成一个 HTML 原型，再让 Codex 在此基础上修改逻辑。
       2. 任务极度细分： 必须明确约束绘图公式、定位样式、变量范围。“不分细了乱发挥”。
       3. 语言选择： AI 适合处理 “笨重、啰嗦” 的语言（如 TypeScript），而对于像 ClojureScript 这样表达力强、代码精简的语言，人写比 AI 更快更好。

专题二：Agent 工作流与 Harness 的进阶艺术

1. 并行执行（Subagent）的认知跃迁： 有人分享了解到 Matt（某群友/知名开发者） 的做法后，才意识到可以用 Subagent 并行处理无依赖任务，之前只知道串行输入。这代表从“单线程对话”到“多线程项目管理”的认知提升。
2. /goal + /steer 命令的神效： 群里高频推荐这两个命令。/goal 据说比多 Agent 对话省 Token 很多。/steer 提供了精确引导模型行为的能力。这两者结合被视为维持模型长期任务稳定性的关键。
3. 重构规则的魔力： 有人分享通过在项目中添加重构相关规则（Commit），AI 在添加新功能时会主动考虑“膨胀缩减”和先行重构，实现了“欣慰”的自主优化循环。这表明 Prompt Engineering 的核心在于构建足够精良的系统级规则。

🔑 关键概念与技术解析

• Harness： 文中多次提及。指的是调用大模型底层的工程框架或工具链（如 Claude Code 的 Harness）。同一个模型（如 DeepSeek）在不同 Harness 中表现差异巨大，说明 AI 的最终能力不仅取决于模型权重，还高度依赖于任务调度、上下文管理、错误处理等外围工程架构。
• Codex 限额/重置： 特指 OpenAI Codex 或 Cursor 等编程工具中基于时间（如5小时）的高强度使用额度。当额度耗尽后，工具会降级使用较慢或较弱的模型。官方定期“重置”额度，常被视为模型能力或规则的重要变更窗口。
• Subagent： 指在 Agent 架构下，主 Agent 可以派生出多个子 Agent 去并行处理可拆分的、无依赖关系的子任务。这是提升 AI 执行复杂工程效率的关键模式。
• Heavy/Low Effort： 特指 GPT 模型推理时的“思考深度”参数。使用 Low 级别会显著降低推理成本，在某些简单任务上（如文本改写、简单逻辑判断）效果足够好，是一种性价比极高的用法。

💎 碎片知识与金句拾遗

• “烧了才知道啊。” —— 对“怕白烧 Token”心态的回应，体现了 Geek 们敢于试错、数据驱动决策的务实精神。
• “人写 ai 比 ui 写的要好，而且快。但是语言很重要，ts 的话就不行。” —— 精准点出 AI 的强项是处理笨重、啰嗦的语言，而表达力强的语言（如 Clojure）依然是人类手工编程的优势区。
• “我这个 [Clojure] 可以写一个代码同时在两边 [CLJ/CLJS] 编译成对应的。可以用 JVM 的 GC 管理 Python 的对象。” —— 展示了一种极致的跨语言互操作性理想。Clojure 通过 Libpython-clj 实现了在 JVM 上直接调用 Python 函数，并用 JVM 内存管理 Python 对象，堪称“缝合怪”的优雅巅峰。
• “我就喜欢用 kimi 生成 html 原型，然后再让 codex 改。” —— 一种低成本、高成功率的 AI 编程前端的实用工作流分享。
• “大模型成本比人工只高不低。” —— 大厂开始意识到的残酷现实，也预示着 AI 应用必须找到比“无脑替代人力”更高效的场景。
• “这终端有点好看……中文霞鹜，英文 PragmataPro。” —— 一场关于字体美学和回忆“视网膜屏幕”时代的短暂闲聊，但也侧面反映了开发者在工具选择上的品味。
• “别重置了，来不及用了。蹬冒烟了。” —— 生动描述了对 GPT Codex 高强度使用的状态，以及对额度重置的复杂情感。
• “我老婆选择干活，我也选择写代码，看来是人就不会喜欢做 ppt。” —— 对某种生产活动普世痛点的幽默调侃。

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

• Sidekick: keep using neovim while a dozen agents rewrite your code (GitHub, NishantJoshi00/sidekick): 一个非常前瞻性的工具理念：在多个 AI Agent 并行重写代码时，稳定住 Neovim 用户的编辑光标，解决“地面持续移动”的痛点。值得研究其实现原理和 “解决 Agent 与人类并行编辑冲突” 的通用框架。
• Clojure 跨语言互操作体系 (Libpython-clj): 文中提及的 Clojure 直接调用 Python 并用 JVM GC 管理对象的特性，是异构系统整合的高阶玩法。值得深入研究 Clojure 的 Java Interop 和 Libpython-clj，探索其在实际工程中的落地能力与性能表现。
• /goal 与 /steer 命令的具体实现原理： 虽然文中未具体展开，但这两个命令被多次推崇，尤其是 /goal 在节省 Token 和并行任务上的能力。值得追踪其设计哲学和实现细节（可能来自于某个特定 Agent 框架）。