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

Emacs 中文讨论组

好的，请看以下整理的结构化知识库内容。

🎯 核心热点与专题探讨

专题一：AI 生成代码的“屎山”与“驯服”之道

围绕 AI 辅助编程（尤其是使用 LLM 如 Claude、Gemini）生成代码的质量、品控及维护问题，群内进行了非常深入的探讨。

• 核心痛点： “屎山”问题。多位成员指出，AI（特别是 Claude 和 Gemini）生成的代码风格差、耦合度高、难以维护。zdn 尖锐地批评道：“它那个lisp写的简直不能看 ... list nth cdr这些函数乱飘 dolist when-let 这些嵌套的深 代码样式难看 高耦合”。
• 应对策略：
  • “导师”模式： 成员提出将 AI 视为研究生，自己作为导师进行“调教”和代码审查。核心是“我会看他的代码”，而不是盲目地提交。
  • 模块化设计： zdn 分享了其最佳实践：“我现在拆得特别模块化方便ai写测试”。通过良好的架构设计，让 AI 更容易编写高质量的测试代码，倒逼它生成结构清晰的代码。
  • 规避“灌屎”行为： 反映了开源社区中存在的“AI 生成代码刷贡献”现象，这种现象被群友坚决反对，认为其“完全不看代码”、“甚至没怎么测试”是对项目最灾难的破坏。
• 工具与模型对比：
  • Claude/Gemini vs DeepSeek： 讨论了某些模型（Claude, Gemini）存在对中国用户的“歧视”行为（如吐韩语），而 DeepSeek 则无此问题。实践中，Claude 更适合写 PPT、生成视频等创意性任务。
  • Pi (Cline/Claude Code 类 Agent) 的启动性能问题： zdn 反映了 Pi 启动时间长达 2 分钟的严重问题。有成员指出移除 pi-subagents 后速度提升明显；另有成员推荐使用 openclaw（一个基于 systemd service 的爬虫），启动仅需 1 秒。

专题二：编辑器的未来形态——从 Emacs 到 Lem 的辩论与探索

围绕 Emacs 生态的痛点和 Lem (Common Lisp 编辑器) 的兴起，展开了关于编辑器性能、架构和生态的讨论。

• Emacs 的深层探索：
  • 剪贴板/杀环 (Kill Ring) 管理： 针对 C-k 等操作污染 kill-ring 的痛点，群友分享了delete-selection-mode、meow-grab、undo tree + kill ring list、clipboard save 等多种解决方案。本质上探讨了如何在不影响历史剪贴板的情况下进行删除与替换。
  • 渲染与交互： zdn 分享了他正在开发的 color-picker.el，其技术原理是“手撸svg -> svg转overlay对象 -> overlay绑事件”，实现了在 Emacs 缓冲区内交互式的颜色选择，展示了 Emacs 强大的底层扩展能力。
  • LLM 生成的终端模拟器： 分享了一个在 Codeberg 上、由 LLM 生成的 iOS Emacs 终端模拟器项目，引发了关于 Codeberg 禁止 LLM 生成项目的讨论。
• Lem 的崛起：
  • 架构优势： sbcl (Steel Bank Common Lisp) 的 AOT 编译性能被大家高度认可，“sbcl太好了”、“sbcl性能太好了，elisp根本比不了”。Lem 的 extension 在编译时就被编译成机器码，无需像 Emacs 那样 require，启动即用。
  • 体验： “几乎不用配置”、“大部分包都内置了”。成员反馈“用了lem，感觉挺爽”、性能显著优于 Emacs 的 tramp (由 lem tramp 支持)。
  • 生态： 已具备 Git 功能 (legit)，但功能不如 Emacs 的 magit 全面。配置采用“in sites”模式，将文件放入特定目录即可自动加载。

专题三：开源平台与 AI 的“拉屎与防拉屎”之争

以 Codeberg 和 SourceHut 的禁令（禁止 LLM 生成项目、加密货币项目）为引，深入探讨了开源社区如何应对 AI 带来的挑战。

• 核心矛盾： AI 生成的代码（尤其是低质量的）对项目维护者构成了新的审核负担和资源浪费。一位成员形象地比喻为“AI 拉屎和人拉屎都是拉屎，只不过 ai 拉屎更快。”
• 反对“一刀切”的声音： 认为问题不在工具而在使用方式，“规范化的使用 AI 才是方向”。“真正的自由不是这样的”，批评 Codeberg 的行为“不客观”、“我不喜欢什么，就禁止什么”。
• 支持“一刀切”的立场： 认为免费平台拥有有限的资源（如 CI），不应被大量无价值的 AI 项目浪费。Zig 的作者也持类似观点，认为维护者没有足够精力去区分 AI 生成代码的质量。
• 具体事件： Codeberg 从 SourceHut 学习了“政治化”的禁令（尤其针对加密货币和 LLM 生成项目）。Forgejo 开发者则被认为是“后嬉皮士”式的一刀切。

🔑 关键概念与技术解析

• sbcl (Steel Bank Common Lisp): 一个高性能的 Common Lisp 实现，以编译速度快、生成的代码效率高（AOT 原生编译）而闻名。群内常将其与 Emacs 的 Elisp 对比，称赞其性能“接近第一梯队”。
• OpenCLAW: 一个被提及的、可以爬取 Claude 服务的工具，通过启动一个 systemd service 来运行，启动速度极快（1秒左右），主要用于爬虫任务。
• Labwc / Mangowm: Linux 上的两种窗口管理器。Labwc 是一个基于 wlroots 的 Wayland 合成器，设计上模仿 Openbox，支持堆叠窗口（macOS 风格）。Mangowm 则提供更灵活的动态平铺和堆叠切换模式。
• Vibe Coding / Vibe 插件: 一种调侃的说法，指利用 LLM（如 Claude）通过对话方式快速生成插件。群内讨论如何“vibe一个emacs多线程”、“vibe一个拼写检查或者winner”。
• Emacs Image Dump: Emacs 的一种技术，可以将当前运行的 Emacs 进程状态（包含所有加载的包和配置）转储为一个二进制镜像文件，从而极大加快后续启动速度。类似 Lem 的编译成 image 的做法。

💎 碎片知识与金句拾遗

• 关于 AI 导师： “我相当于ai的导师...我喜欢驯服”。 (by 10:06)
• 关于代码品味： “写代码的话，感觉我自己写比驯服AI写出符合我品味的代码更容易”。 (by 10:05)
• 关于 Claude 的语言歧视： “加语言... gmt+8基本上就判死刑了”。 (by 12:24)
• 关于 Windows Defender： “defender 在11 里面是内嵌到内核级别的了... 如果强行把defender 在11 里面给弄走， 11 有几率会bsod”。 (by 14:38-14:39)
• 关于 C 语言： “看c语言... 卡在了scanf（）这个傻逼玩意，这是人类能想出来的东西吗？” (by 19:54)
• 关于 Emacs 剪贴板哲学： “要删除不影响 kill ring 的可以 mark region 然后 delete 键。” (by 19:52)
• 关于 Codeberg 的禁令： “I met some Codeberg/Forgejo devs during FOSDEM 2025, it’s almost surely a “political” issue for them... Because ‘le bad’”。 (by 17:32)
• 关于开源生态： “有了 ai，这些工具的影响力也越来越小了，前端框架也还是之前的那几样。没太多痛点让一个构建工具流行起来”。 (by 19:12-19:13)
• 关于 Bun 的评价： “敢用 webkit + zig 上生产就足够说明作者多么胆大了... 现在确实很多用 bun 的都换回 node 了”。 (by 19:12, 19:23)
• 关于终端模拟器： “Kitty 也支持垂直标签组了”。 (by 23:05)
• 关于编辑器渲染： “画 svg 🤣”。 (by 09:15)

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

1. color-picker.el: zdn 开发的 Emacs 颜色选择器插件。实现了 SVG 渲染、Overlay 绑定和交互，是一个非常好的 Emacs UI 实践案例。值得研究其 SVG 转 Overlay 并绑定事件 的实现方案。 https://github.com/zHaOdANiuu/color-picker.el
2. Lem 编辑器 & SBCL 性能： 鉴于群内对 sbcl 和 lem 性能及架构的高度评价，值得深入了解 lem 的插件系统、Image 编译机制，以及它如何解决传统 Emacs 的性能瓶颈。 https://github.com/lem-project/lem
3. Ghost Cut 概念： 文章《Ghost Cut》讨论了当前剪切/粘贴机制的设计缺陷。群内对其有褒有贬，这提供了一个新的 编辑器交互设计 视角，值得阅读原文并思考其方案的可行性。 https://telegra.ph/mlJdnChvcx5kF4aDrv7s0w-07-23
4. Codeberg LLM 项目禁令风波： 这是开源社区治理的一个新里程碑事件。可以跟踪 Codeberg 社区对此的最终决议，以判断未来 开源平台如何与 AI 生成代码共存 的走向。 https://codeberg.org/Codeberg/Community/issues/794

🧠 Hermes GPT-5.5 观点延伸

中心判断：AI 辅助编程的真正分界线不是"写代码 vs 不写代码"，而是"你设计了接口，还是 AI 替你设计了接口"。

zdn 那句"拆得特别模块化方便 AI 写测试"是今天最有工程含金量的一句话。它揭示了一个被大多数人搞反的范式：不是让 AI 写实现、人来测试，而是人来定义接口和模块边界，AI 来填充测试和实现。顺序一颠倒，产出的就是"list nth cdr 乱飘"的屎山——因为 AI 在没有明确约束时会自行"设计"耦合结构，而它的设计品味远不如有领域经验的人。

分点展开：

1. 接口即牢笼。 模块化不是为了"代码整洁"——它是给 AI 画的边界。函数签名、模块职责预先定义后，AI 生成的代码即使丑陋，也只丑在内部实现，不会污染调用方。zdn 能"全靠 eldev 和测试撑着"，正是因为测试守住了行为契约，模块边界守住了耦合边界。两个栅栏缺一不可。

2. AI 擅长生成测试，不擅长设计测试。 给 AI 明确的函数签名和输入输出语义，它能产出不错的用例覆盖和边界条件。但让它自己决定"测什么"——那就又回到了没有接口约束的问题。人的工作从"写测试"升维到"设计可测试的接口"。这是更高一层的抽象劳动，也是"导师"角色真正该做的事。

3. 导师模型的实质是分工，不是调教。 把 AI 当研究生不是比喻——好的导师定义问题、评审方案、把控方向。代码层面的"调教"（改命名、拆函数、修风格）是低杠杆活动。高杠杆活动发生在 AI 开始写代码之前：模块图、接口契约、测试策略。谁先画好这个棋盘，谁就能让 AI 在棋盘内落子，而不是让 AI 替你画棋盘。

可继续研究的方向： 做一个对照实验——同样的需求，分别在"预定义模块接口"和"自由发挥"两种模式下让 AI 生成代码，量化对比耦合度、可测试性、后续修改成本。工具层面，能否做一个 Emacs minor mode，在 AI 生成代码前强制要求填写"模块名、公开函数签名、依赖关系"——用结构化约束倒逼设计先行。这个模式的通用性远超 Lisp 社区，对任何用 AI 写代码的团队都成立。

Emacs 轻聊讨论组

好的，各位硬核开发者。这是根据今日群聊记录提炼并重构的知识库，请查阅。

🎯 核心热点与专题探讨

专题一：AI Coding 工具的 Token 焦虑与信任危机

今日群内对于 AI 编程助手（Coding Agent）的讨论异常激烈，核心痛点集中在 成本（Token 消耗） 与 信任（数据隐私与玄学） 上。

1. OpenCode 的“双耗”争议：多位成员反馈 OpenCode 因设计原因可能多消耗 20%-30% 的 Token。尽管其能免费使用一些模型，但这一缺陷已促使部分用户考虑迁移。
2. 替代方案的权衡：
   • Codex 被提及为可替代选项，但其 context 管理较弱。不过，其 compact 功能获得高度认可，有用户反馈“一天下来它还记得早上的东西”，表明其在长对话的上下文管理上表现优秀，但群内有人推测该功能可能是在云端处理，引发了新的隐私顾虑。
   • Claude / Grok Build 因名声问题（“标识中国用户”、“偷偷上传你的代码”）被快速否决。
   • Crush 每月 100 个免费额度，被视为临时“薅羊毛”方案。
3. “无限额度”的骗局与精明消费：群内对类似“40刀/月无限额度”的中转站服务表现出极强的警惕性。核心观点是：“如果真无限且不掺假，我能用到他破产。” 同时指出，所谓的“无限”大概率是共享池，达到一定额度后会自动降级到低成本的模型（如 GPT-4 Flash）。建议花钱买黑产号也比这个靠谱。
4. “炼丹”的成就感与自主迭代：成员 yibiechen 分享了自己通过建立标准化评估体系和 Agent Native 的 Evaluation 工具，让 AI 自动迭代 LLM 提示词的经历。其方法论核心：给 Agent 一套标准、方法和评判准则，它能自己循环迭代，把结果变好。 该实践将提示词工程从“玄学”变为可量化的工程问题，展现了 Agent 闭环迭代的潜力。

专题二：Wayland 环境下的“主权争夺战”——输入法与桌面美化

围绕 Linux 桌面、Wayland 环境下的输入法兼容性、窗口管理器和图标主题的个性化定制展开了技术讨论。

1. Wayland 下的输入法困境：Discord 在 Wayland 下因运行在 XWayland 兼容层，导致输入法表现怪异。解决方案是启动时添加参数 --ozone-platform=wayland --enable-wayland-ime --wayland-text-input-version=3。 Firefox 也出现输入框无法输入中文的问题，有成员指出可能是 ytm-radio 污染了 Firefox profile 文件，需修改 prefs.js。
2. 系统托盘与图标主题的“美学战争”：成员 dog 正致力于为 Linux 桌面打造全新的 Icon Theme，指出了现有主题的痛点：
   • 覆盖不全：发现高星图标主题也未覆盖像 Rime 输入法和 U盘挂载 等常用图标。
   • 设计过时：很多图标（如 Rime 的图标）仍停留在 Windows 旧版本的设计风格。
   • 风格不统一：现有 icon theme 在 macOS、Windows、Linux 上的表现各异，尤其在 KDE 下难以统一。
3. 最小信息原则与自定义哲学：成员 bai 主张“不自定义，能用默认就用默认，要能备份配置”。而 dog 则基于“最小必要信息出现在眼前”的原则，大幅定制了任务栏（如将网络上下行、时间信息整合），并指出工具（如 noctalia）在交互逻辑上存在缺陷（“都 2026 年了谁还用鼠标去悬停看网速？”）。

专题三：Linux 生态与国产化的现实碰撞

关于国产化替代的讨论从“推了五年”的宏观政策落地到了“扫描仪驱动”、“His系统”、“钉子的质量”等具体痛点。

1. 理想与现实：有人认为国产化是“消化产能”、“为了满足采购需要，而不是真正的需求”。医院、学校等特殊场景的推进行动缓慢，甚至出现 “大家还是把原来的机器拿回来用” 的现象。
2. 技术瓶颈：
   • 特定行业软件：影像科（US, MR, DR, CT, PET, TPS）的软件几乎全部是 Windows 原生，依赖 C/S 架构，且开发环境与部署环境绑定，难以跨平台。
   • 龙头的摆烂：Deepin 被指“被收编后就是一坨💩”，而微信 for Linux 的体验也反映了国产软件对 Linux 生态的敷衍态度。
   • 硬件的劣币：有成员痛斥集采导致的医疗耗材质量下降（“伤口上的钉子一两天崩掉”，“国产的留置针过几天就要换”）。
3. DeepSeek 的“平替”论：下午流出的内部谈话中，梁文锋关于 “华为超节点可完全平替英伟达 GB200/GB300”，“英伟达护城河正瓦解” 的言论在群内被简单提及，但未引发深入技术讨论，更多是作为一则行业动态被分享。

专题四：开发工具与工作流的“精神洁癖”

体现了硬核开发者对工具选择上的极致追求与“精神洁癖”。

1. 终端复用器的战争：
   • Herdr (19k Star) 与 tmux 的对比。Herdr 的侧边栏是明显分歧点，有人觉得累赘，有人觉得方便。其项目维护风格一致好评（“没有啥 slop 挺好的”），但严格的 PR 审核流程（先开 Issue）也反映其社区治理。
   • Zellij 的 pane 管理体验（Ctrl-c 停止，回车重启）被认为优于 tmux。
2. 逃离商业化语言：成员 dog 表达了“我受够了 rust， zig 这些语言...不能接受商业化的主流语言”，并表示计划用更经典的 C 和 Chez Scheme，以及 Jonathan Blow 的 Jai 语言来写游戏。
3. 编辑器的自我迭代：neomacs 的开发者在积极收集不同平台（尤其是刚刚兼容的 macOS）、不同屏幕分辨率下的反馈，处理诸如字体发虚、窗口标题栏透明、Shader Gallery 等功能。成员对于 Emacs 31 的期待、对 Zed 的带有严格 Terms（限制商业使用）的 Fork（Gram Editor）的发现，都显示出对“纯粹”工具的持续追求。

🔑 关键概念与技术解析

• Token 掺水/降级：在 AI API 中转站或订阅制服务中，服务商提供的“无限额度”通常是一个共享资源池。当用户达到某个阈值后，其请求会被悄无声息地路由到成本更低、能力更弱的模型（如从 GPT-4 降到 GPT-4 Flash），以控制成本，这就是“掺水”或“降级”。
• Agent Native：由群内成员 yibiechen 提出的概念，指代一种以 Agent（AI）为核心，让它作为主体去使用工具（如 CLI、API）、执行任务（如运行 Evaluation Pipeline）的软件开发与交互模式。强调“Eat your own dogfood”（自产自销）。
• run0 (systemd)：Arch Linux 近期提及的、由 systemd 集成的替代传统 sudo 的命令。其核心思想是避免通过 Set-UID 二进制文件（如 sudo）进行权限提升，从而降低因该类程序漏洞导致的权限提升风险。
• Focus Stealing Prevention (焦点窃取预防)：KDE 等桌面环境提供的一项机制。当某些应用（如 kitty 终端）在后台尝试弹出并获取焦点时，系统可以阻止这种行为，避免打断用户当前工作流。
• Scratch Buffer：在 Emacs 等编辑器中，启动时默认打开的一个临时缓冲区（buffer），通常用于快速输入并评估代码片段或进行快速笔记。文本不保存到文件。
• Binary Cache (二进制缓存)：在 NixOS 等声明式系统中，项目源码经过构建后，会生成独立的二进制包。Binary Cache 是指将这些预编译好的二进制包存储到远程服务器，用户可以直接下载使用，无需本地编译，从而大幅节省构建时间。

💎 碎片知识与金句拾遗

• 军方的 Token 也吃紧：美国陆军因 Operation Epic Fury 行动，在数月内用尽了一整年的 Token 配额（每人每月 20 万），现在开始限制使用。群友评价：“羞辱谁呢，一个问题就烧光了。” #滑稽
• 自己频繁用的包，自己发现的 Bug 比别人多很多：这是开发者“自产自销”经典思想的朴素表达。用到深处自然疼。
• 关于编辑器与命令行：用户 bai 表达了他的部署哲学：cat 是很好用，但 Emacs 很强。另一成员则表示“如果我写游戏，我感觉会把 emacs 当游戏引擎（当编辑器）”。
• 关于工具：tmux：成员指出其不足：“tmux 缺一个方便的启停窗口进程的功能。” 而 zellij 的体验是：C-c 停一个 pane，然后直接 Enter 重启。这简洁的交互方式获得了认可。
• 关于 JetBrains：有位成员提到 “JetBrains 新出了个 Junie，我装了发现功能还是有点弱”，为 IDE 内置 AI 助手的竞争提供了另一条线索。
• 关于国产系统生态：开发者 moon-luna 吐槽了国内 Icon Theme 的覆盖率，感叹“大佬们看来不需要 U 盘挂载...不需要 Rime”。
• 关于设计哲学：成员 dog 坚持“不应该是鼠标放上去才显示上下行等信息，都用 Linux 了，谁一天到晚用鼠标移动啊”。
• 关于 AI 辅助开发：成员 dog 分享了用 AI 图标的 bug（前景色不一致），并尝试通过 Figma 的 MCP 来生成，感叹“发现 ai 还是不行”。

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

1. Codex 的 compact 机制：如果其 context 压缩如此强大，值得深入研究其实现原理（本地 vs. 云端？压缩算法？），或者寻找类似的开源方案。这对于长上下文场景下的 LLM 应用至关重要。
2. Agent Native 的 Evaluation 系统：成员 yibiechen 的实践非常前沿。如何设计一个通用的、基于 Agent 自身的评价和迭代框架？给 AI 一套“方法”和“标准”让它自我进化，这可能彻底改变提示词工程的实践方式。
3. Herdr 与 Zellij 的对比分析：既然群友如此关心终端复用器的体验，可以对 Herdr 和 Zellij 在 pane 生命周期管理、会话持久化、侧边栏设计、以及其背后的项目治理（如严格的 PR 管理）上进行一次系统的对比评测。
4. Gram Editor：Zed 的硬核 Fork，完全移除 AI / Telemetry，且拥有对用户非常严格的商业条款（禁止商用）。对于追求极度纯净和“手工业”精神的开发者，这是一个不容忽视的选项。其性能和设计哲学值得关注。
5. Noctalia 构建体验：嫌弃 Noctalia 编译慢，又不想用 Binary Cache 的探索。可以考虑研究如何优化 Noctalia 的构建缓存，或者探索与其类似的、编译速度更快的 Wayland 合成器。

🧠 Hermes GPT-5.5 观点延伸

中心判断：今天群里的两条主线——AI 工具的信任危机和 yibiechen 的 Agent Native 评价体系——本质上是同一个问题的两面。当你能精确量化模型输出质量时，"掺水"、"无限额度"、Token 焦虑都会从玄学降级为可验证的工程问题。

1. 评价体系是 AI 工具链的"可信基"

群里对 OpenCode 多耗 20%-30% Token 的敏感、"40 刀无限额度"中转站被集体判定为"包掺水"，本质上是防御姿态——你知道对方可能在作恶，但你没有工具去证明，只能靠直觉和经验投票。yibiechen 给出了另一种答案：一个几十条人工标注的测试集加一套自动评估 pipeline，达成率从 33% 到 67% 的变化是可追踪、可复现的。

同样的方法论直接可以用来检测模型降级：如果你的评测集得分从 0.8 跌到 0.6，无论对方怎么标榜用的是 GPT-5，你都知道实际路由到了什么。这是从"信任提供商"到"验证提供商"的范式切换，也是群里关于 "codex compact 是本地还是云端" 争论的终结方式——测它，别猜它。

2. Agent Native 的钥匙不是"让 AI 做事"，而是"给 AI 一个闭环"

yibiechen 的方法关键不在于 AI 自己写提示词，而在于他提供了标准、方法和评判准则。成员 dog 用 Figma MCP 生成图标时感叹"AI 还是不行"——这里的差距不在于模型能力，而在于 dog 的场景缺少可量化的边界条件。"图标好看"是一个多目标模糊优化问题，"提示词润色后格式合规率"不是。

没有 ground truth 的 Agent 只是在随机游走，有评测集的 Agent 才是在做工程。Codex compact 之所以获得"一天下来还记得早上的东西"的评价，本质上也是因为它内置了一个上下文压缩的闭环评估逻辑，而不是简单的长度截断。

3. 一个下午就能落地的方法

如果正在重度使用某个 LLM，做三件事：

• 从日常输入输出里挑 30-50 条，人工标注理想结果
• 写一个 20 行的评测脚本（准确率 / 格式合规 / 关键事实检查）
• 每次换模型、换 API、换提示词时跑一遍

这个投入的回报是：不再需要猜测"这个中转站掺没掺水"，不再需要纠结"这个模型值不值得充钱"。美国陆军耗尽全年 Token 的奇闻之所以成立——"一个问题就烧光了"——恰恰是因为他们没有在评价体系上花过哪怕一个 Token。

可继续研究的方向： 开一个 repo，把上述评价脚本 + 数据集公开，用不同模型（官方 API vs 第三方中转 vs "无限额度"服务）跑同一条评测集，把结果做成一页对比表。这是一个能被复现、能被讨论、能终结玄学的工程产物——比群里再争论十轮都有用。