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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 社区的“复古”与“现代化”博弈

本次聊天中，这一主题贯穿始终，涉及多个子议题：

1. 社区文化冲突与“老人”现象：讨论从对某个已退群成员“零秒哥”的回忆切入，引发了对Emacs社区中“不正常”成员的吐槽。核心观点是，这些成员并非真正热爱Emacs，而是希望在社区中“唯我独尊，享受目光”。这反映了社区对早期“高流量、低技术贡献”人物的反感，以及对社区纯洁性的隐忧。有人总结：“最讨厌AI的程序员，都集中在了Emacs...”，暗示Emacs社区存在一种固守传统、抗拒变革的“复古”倾向。

2. AI 在 Emacs 社区中的对立与接纳：这是“现代化”的核心矛盾点。有人提到在emacs-ng仓库提issue时，因提及LLM而被删除，引出了“好多老外都不喜欢LLM”的观察。阵营分化明显：

   • 反对派：观点包括“LLM只是工具，什么都非要弄的没有这个工具不行”、“人被裁破防了”（将反对LLM与经济下行挂钩）、“不符合匠人精神”（日本社区观点）。
   • 支持派：观点包括“你问他们不喜欢llm以后还用kernel吗”、“再不干，emacs社区就真的只剩下老头了”、“emacs需要现代化”、“已经很久没手动写过代码了”。
   • 总结：这场博弈的本质是工具理性与社区精神的冲突。反对者担忧“依赖工具”是人性的弱点，而支持者则视LLM为不可逆的趋势和救亡图存的良药。

专题：AI 驱动的编辑器与协议革命（ACP vs A2A）

1. Zed 的崛起与定位：Zed发布1.0成为讨论热点。其宣传片通过贬低“most editor built on web browser”（暗指VSCode）来突出自身“pure rust and run on gpu”的性能优势，被群友戏称为“AI时代的vscode”。

2. Agent Client Protocol (ACP) 的发明权之争：群内对ACP的原创性进行了辩论。最终核实：ACP确实是Zed创造的（其创始人Max Brunsfeld提交了首个commit）。Google提出的同名协议是另一回事（Agent Communication Protocol，已改名为A2A）。

3. Neomacs 的现状与挑战：eval-exec 大佬的 Neomacs 是“Emacs现代化”方案的直接体现。当前状态是“能编译，能跑，但距离日常使用还需要一些工作量”。

   • 痛点：常见问题是字体渲染模糊（尤其在macOS和分数缩放下）、光标位置计算错误、无法支持.eln原生编译。
   • 进展：elc编译支持，但eln不行。社区成员已成功build并截图反馈。

专题：Emacs 配置管理与环境隔离

1. Org-mode vs Markdown：有用户发起“你们org和md哪个用得多”的投票，结论是分工明确：“工作用md，自己用org”、“个人笔记和待办还是org”。这说明在工作流中，org-mode地位依然稳固，但在与LLM等现代工具交互时不得不采用更为通用的Markdown。

2. Emacs 版本管理与复制性：讨论升级内置Org-mode（从9.7.11到9.8.3）的方法。有人推荐 straight-use-package 进行精细版本控制，有人坚持使用 package.el 配合 custom.el 实现复制，也有人提到 NixOS 和 Guix Home 这种从操作系统层面解决环境一致性的思路。这揭示了高阶用户对确定性、可复现环境的追求。

3. 企业管控下的生存之道：有成员表示公司IT将使用Microsoft Intune管理电脑，Emacs可能被禁。讨论转为如何规避：如使用Portable版、WSL、或不联网模式。这反映了在专有软件管控环境下，开源工具用户面临的现实困境与应对策略。

---

🔑 关键概念与技术解析

• lsp-bridge：一个用于Emacs的、基于C++编写的异步、高性能LSP客户端。优点是速度快，但文档被社群评价为“比较复杂”，这阻碍了它的普及。
• emacs-ng：一个已死亡的Emacs分支，尝试通过嵌入WebKit等现代渲染引擎来革新Emacs界面。它曾是新Emacs（如Neomacs）的灵感来源，但项目已停滞。
• Anvil：在emacs-ng的讨论中提及，是一个复杂的工具/框架。具体为何复杂未明说，但可能与其构建系统或与现代Web技术的交互有关。
• ACP (Agent Client Protocol)：由Zed编辑器提出的协议，旨在规范化客户端（编辑器）与AI代理（Agent）之间的交互，用于代码补全等任务。它定义了编辑器如何调用AI功能。
• Luddite / 卢德派：此处用于形容那些因AI导致失业而强烈排斥新技术的人，带有贬义。原指19世纪英国反对工业革命的工人群体。
• Intune：微软的企业移动管理（EMM）解决方案，用于统一管理企业内的设备和应用，可以远程禁止用户安装或运行特定软件。
• WSL (Windows Subsystem for Linux)：Windows下的Linux子系统。在Intune限制传统开发环境时，WSL被探讨作为一种“曲线救国”的方式运行开发工具。
• Guix Home：GNU Guix的声明式家庭环境管理器，可以将用户的主目录、配置、服务等用函数式思维进行管理，实现极高的可复现性。

---

💎 碎片知识与金句拾遗

• 社区生态观察：”很多老外都不喜欢 LLM“：一个关于西方程序员社群对AI态度的观察性结论。
• 安全预警：”AI发现了一个好像很严重的kernel漏洞“：群内分享了链接 copy.fail，提醒关注一个由AI发现的严重Linux内核漏洞。
• 日本社区印象：”最讨厌AI的估计是日本，不符合匠人精神“ + ”感觉github上日本人的Emacs水平好高“：两个对比强烈的观察，点出了日本开发者社区的技术深度与传统保守并存的矛盾特质。
• 历史回忆与感慨：
  • ”我记得很多年前：我当时我整天在emacs群里发emo文案...零秒哥在出零秒教程...Iammirror哥在探讨哲学和人生。当时气氛多好。”
  • ”他们不是热爱Emacs，他们是希望唯我独尊，享受目光“：一句话点破某些高调社区成员的动机，发人深省。
• 生活与工作的碰撞：”最讨厌AI的估计是日本, 不符合匠人精神“：一个略显刻板但又颇有见地的行业观点。
• 工具哲学：”（Intune来了）Emacs这种可以向外发关东西的，估计是要管控的。但IT又没法知道Emacs到底发送了什么。所以估计是要被禁的”：生动刻画了不确定性环境下，安全与自由之间的灰色地带。
• 开发日常：”排查线上问题也是各种skill了“：一句话道出AI对开发者工作流的深刻改变。
• 编辑器选择的核心标准：”选择编辑器的第一个标准就是能否高度自定义“：Emacs用户最根本的原教旨主义宣言。
• Emacs社区里的Lisp：”Emacs Lisp 也是 Lisp“：当有人询问Lisp中文群时，群友如是回答，点明本群的核心语言根基。

---

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

1. 研究 Neomacs 的现状与未来：

   • 如何研究：按照群友提供的commit 610865c9c 和构建命令 cargo xtask fresh-build --release 自行编译体验。关注其字体渲染（cosmic-text库）、分数缩放支持以及.eln原生编译的兼容性进展。参与其GitHub仓库的Issue讨论。
   • 为什么值得看：它是目前最活跃、最先进的“Rust重写Emacs”项目之一，代表了Emacs现代化、性能优化的未来方向。其成败将深刻影响下一代编辑器的形态。

2. 跟踪 Agent Client Protocol (ACP) 规范的进展：

   • 如何研究：前往其GitHub仓库 agentclientprotocol/agent-client-protocol 查看最新的specification和实现。关注Zed、JetBrains等主流编辑器如何集成该协议。特别是研究其与LSP协议的互补与区别。
   • 为什么值得看：这是AI与编辑器深度整合的“语言”。理解ACP，就理解了未来AI编程工作流的底层范式。它正在定义“AI时代的编辑器”的行为标准。

3. 深入理解 Org-mode 的 “Modern” 版本管理：

   • 如何研究：实践通过 straight-use-package 或 elpaca 锁定Org-mode到最新版本（如9.8.3）。研究官方文档中关于“如何覆盖内置版本”的说明。研究Karthink的 org-latex-preview 是如何依赖新版Org-mode的。
   • 为什么值得看：Org-mode的进化速度极快，许多新功能（如 org-export 改进、更好的性能）只在最新版中可用。学会优雅地管理Org-mode版本，是维持高效工作流的关键技能，也是从“Emacs用户”迈向“Emacs配置大师”的必经之路。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】GitHub 可靠性危机与代码托管大逃亡

背景： 群内连续多人在同一天反映 GitHub 服务不稳定，包括 PR 查询错误（疑似ES炸了）、Issues 输入框无法打字、Actions Runner 频繁出问题，甚至某个知名项目的维护者公开撰文吐槽 GitHub 不稳定，已经带项目跑路。

痛点：

• 稳定性反噬生产力： 过去认为是梯子的问题，现在发现是 GitHub 自身状态在恶化。这严重影响了依赖 GitHub CI/CD 的工作流。
• AI 热潮的副作用： 群友普遍认为，GitHub 用户活跃度因大模型热潮激增，而平台维护质量却可能因为内部也在“vibe coding”或过度依赖自动化测试而下滑，导致体验雪崩。

替代方案讨论与对比：

• gitee (被否定)： 被认为“不安全”且玩梗性质。
• codeberg (争议)： 有群友推荐，但立即被反驳“太卡”、“也没稳定到哪里”。
• gitlab (无定论)： 无人深入讨论。
• gitea (硬核首选)： 多位老哥表示个人项目已迁移到自部署的 gitea，承认虽然有迁移成本，但能彻底掌控。
• 极简主义方案 (ssh + bare repo)： 通过 git init --bare 在自己的 VPS 上创建仓库，利用 Git 的分布式特性进行双向备份。版本控制和 diff 与原平台无异，甚至有群友直接用 org babel + curl 管理。

核心结论： 对于硬核开发者，GitHub 的不可靠正在催生“去中心化”回归潮。个人项目不再需要 fancy 的托管平台，一个能 ssh 的 VPS 就是最好的仓库。对于社区项目，则需要更审慎地评估 codeberg 等替代者的稳定性。

---

【专题二】后 Vibe Coding 时代的“软件质量滑坡”

现象： 不止 GitHub，YouTube, X (Twitter) 等大型平台的 BUG 显著增多。例如：YouTube 视频播放两遍、X 视频无声、GitHub Issues 输入框卡死。

深层分析：

• 激励错位： 员工在公司里不会为老板不关注的细节 bug 负责。“当人为组织服务时，最终结果不需要个人承担，而是由组织承担。” 个体的自由裁量权（如手动测试、修复边缘case）被压缩。
• AI 的“劣币驱逐良币”： 自动化测试跑过了，AI 也检查过了，管理层就认为没问题。但 AI 训练时更擅长“快活”的部分（增功能），对“隐晦的体验问题”（偶现 bug、性能退化）不敏感。
• 组织层面的恐惧： “人在组织里……不敢抛出与主流不合的声音。” 当整个公司都押注 AI 提效时，敢于提出“体验变差”的员工面临压力。
• Vibe Coding 的两面性： 多数群友认为 vibe coding 质量堪忧，但有人反驳：“看谁来 vibe。我 vibe 完还花差不多一半的时间测试，质量还可以。” 真正的关键在于 AI 生成的代码后，是否有高质量的人工测试兜底。

结论： 这是“AI 提效”与“软件 craftsmanship”之间的矛盾。AI 催生了大量基础可用但体验粗糙的软件。未来，软件测试（特别是手动和探索性测试）的价值会重新被认识。同时，能写出“无 bug 代码”的 senior 开发者将更加稀缺。

---

🔑 关键概念与技术解析

• agent tree (代理树)： 在讨论 AI 编辑器时提到。一种组织 AI 代理（Agent）执行复杂任务的高级架构。不同于单一的对话流，它通过树状结构划分任务，让不同 AI 代理并行处理不同子任务，手动编排可以更精细地控制 AI 的行为链，但增加了复杂性。

• compact (压缩/沉淀上下文)： 在 AI 编程工具（如Cursor、Claude Code）中使用。当上下文窗过长导致 token 消耗剧增时，通过 AI 自动或手动将历史对话摘要为更简洁的描述或指令，来“压缩”上下文所占用的 token。群友指出，这个操作本身也会消耗 token。

• org babel + curl： 一种极客的 HTTP 请求管理方案。org-babel 是 Emacs 的 Org-mode 中的代码块执行系统，允许在笔记/文档中直接嵌入并执行 curl 命令。这取代了传统的 API 测试工具（如 Postman），将所有请求记录与知识管理融为一体。

• winboat (Windows Boat)： 群友提到的一个允许在 Linux 上容器化运行 Windows 应用的软件。与 Wine/Proton 不同，它通过轻量级的 Windows 虚拟机 + 窗口投射技术，能运行 Adobe 全家桶等 Wine 无法支持的应用。

• vibe coding (氛围编程)： 由 Andrej Karpathy 提出的概念。指完全依赖 AI 生成代码，开发者几乎不读代码，只负责描述需求、复制粘贴和调试，享受编程的“氛围感”。群内讨论认为其产出质量参差不齐，主要看后期人工投入。

💎 碎片知识与金句拾遗

• 关于软件腐烂： “我觉得 vibe coding 可能会创造一波机会……很多主流的软件体验可能会不可逆的下滑。” —— 深刻的行业预见性。
• 关于效率的悖论： “你提升性能的部分，知识是有的，代码量就很小了。” —— 指出 AI 在性能优化领域的短板（训练数据大多是关于“增功能”，而非“改代码”）。
• 关于生命的真实：某群友 (@Lucius_Chen) 分享：“回老家，给 86 岁的奶奶拍照片，留着过世用”。随后引发对“白发人送黑发人”和生命脆弱的沉重讨论，展现了开发者也具备极强的情感。随后有人安慰：“別想那麼多，指不定哪天死的就是我們，我們也都是高危人羣”。
• 关于代码的类比：分享了一则推文截图：“猫的大部分行为都是由屎山代码驱动的……”，引发出“人的喉返神经也是屎山代码”的精妙生物-程序类比。
• 关于 CS 的黑色幽默：群友点评安全领域现状：“进可模型扫漏洞 退可供应链投毒”。
• 冷门工具推荐：courier 项目 (GitHub: LuciusChen/courier) —— 一款被自荐的轻量级工具，能满足基础的 HTTP 请求交互需求。
• 音游车神：推荐了一张 “bpm15q- pachim” 的开车歌单，并附言“包你嗨翻天（”。
• SQL 格式化新思路：群友分享了自己手写 SQL 格式化器（已上传至 pypi）的理念：兼顾 DataGrip 的长 SQL 优雅折叠与短 SQL 的一行显示。这是对现有格式化工具不太满意后的硬核 DIY 行为。

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

1. 项目：winboat (Windows Boat)

   • 为什么值得研究： 这是 Windows 应用兼容性的新方向。相比 Wine (基于 API 模拟) 和全量虚拟机，它走的是一条轻量容器化 + 窗口投射的折中路线。这可能是让 Linux 成为真正桌面生产力的关键一环。
   • 如何研究： 在 GitHub 上搜索项目仓库，重点关注其虚拟化方案（是使用 KVM+LXC 还是其他技术），了解其性能损耗和兼容性列表。对比其与 Proton 在同类应用（如 Adobe 软件）上的表现差异。

2. 概念：compact (AI 编程工具的上下文压缩)

   • 为什么值得研究： 这是使用 Cursor、Claude Code 等长上下文 AI 编程工具的高阶收费瓶颈。理解 compact 的时机、策略和算法，能让你的 AI 辅助编程效率翻倍，并节省大量 token 费用。
   • 如何研究： 在对应工具的官方文档或社区 Issue 中搜索 context compression 或 compact，观察 AI 生成的描述是如何被“提炼”的。尝试在不同场景下手动触发 compact，对比压缩前后输出结果的差异。这是 AI 编程的“玄学”环节，值得掌握。

3. 配置思路：自部署 gitea + act-runner 替代 GitHub Actions

   • 为什么值得研究： 群内已有多人实施，且明确表示 GitHub Actions 不稳定是核心痛点。这不仅是备份方案，更是一种追求极致自主权的开发运维哲学。
   • 如何研究： 1. 部署 gitea，配置反向代理和数据库。 2. 在此基础上安装并配置本地 act-runner。 3. 重点研究群友指出的痛点：“本地的 act runner搞搞包还行，一带上 systemd 就炸了”。你需要去复现并解决这个具体问题，了解 systemd 级任务在 act-runner 中为何会失败（通常是 cgroup 或权限问题），这是一项极佳的 DevOps 实践。