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

Emacs 中文讨论组

🎯 核心热点与专题探讨

1. Supertag 演示与 Org mode 标签系统之争

• 群友分享了 Supertag（Emacs 包）的演示视频，它在 Org mode 标题中引入 #标签，使笔记可查询、链接、生成时间流。讨论聚焦于其与 org-roam 的差异（"跟 org-roam 好像类似？"），并提及"流"的概念源自 Eric Freeman 的博士论文 Lifestreams。有人吐槽 AI 配音"有点大𥻗子味儿"，群友回应是本地模型生成。
• 技术细节：Supertag 支持嵌套标签、未链接提及、相似笔记（需要本地 Ollama 嵌入服务）、信息面板（实验性，LM 只负责版式）。面板自动生成，时间流与子流可读。
• 潜在痛点：有人怀疑其与 org-roam 的重复，但演示强调"写的时候不用想放哪儿，整理留到需要的时候"这一理念差异。

2. 开源项目收到 AI 垃圾邮件的集体吐槽

• 多位群友表示"以前没有这样的邮件，最近收到好多"，推测是 AI 批量爬取 GitHub 邮箱后发送的定制化广告。有人"再收到就要上推 at 项目的人喷"，群友怂恿"你快喷"。
• 这种邮件伪装成"认真看了项目诚意邀请"，实则批量发送，激起开源维护者的反感。讨论未深挖解决方案，但反映了 AI 营销对开源社区的侵扰。

3. AI/vibe coding 与软件开发的未来（长篇争论）

• 起因：有人提出"中小型商业软件可能慢慢开源，与其被逆向不如放 GitHub"，引发关于 AI 时代产品竞争力的辩论。
• 核心观点碰撞：
  • 逆向"看起来像"容易，但"做成成品之间的才是 80% 工作量"，且 vibe coding 的 20% 会让最后的 80% 极其难做。
  • 反方认为"20% 的差距是用户的反馈"，有人用就能迭代；但正方反驳"以前商业软件有收入保证开发速度，开源不行"，且"用户量没起来就死了"。
  • 最终聚焦到：AI 平等赋予所有人能力，所以"vibe 本身没有价值"，用户不在意软件是否 AI 写的，产品突围逻辑不变（先发优势、流量入口等）。
• 金句："talk is cheap, show me your products"、"你根本不知道自己不知道"、"半成品导致没人用"。
• 特别案例：腾讯的"后发优势"实为流量运作，先发优势如微信无法被撼动。

4. Emacs 开发者的日常经验

• 有人提及收到 FSF 的 PDF 延迟（8 月发邮件至今未收到），群友 φuzy 分享"隔了一个月才收到"，建议"混脸熟"并抄送维护者。讨论中透露 Emacs 开发者（Eli）对签署者已知情，但流程缓慢。
• 有人提到"给 Emacs 写 patch 能感觉到严肃编程"，表达对参与核心开发的向往。
• 技术旁枝：有人发现 enriched-mode（富文本编辑模式）与"隐藏标签"的实现机制相关，引发简短讨论（见碎片）。

🔑 关键概念与技术解析

• Supertag：Emacs 包，将 Org mode 标题中的 #标签 作为一等公民，支持查询、链接、时间流、查询块、自动生成信息面板。设计理念源于 Lifestreams（1997 年 Eric Freeman 博士论文），通过标签组织信息流而非目录结构。
• org-roam：基于 Roam 理念的 Emacs 笔记系统，强调双向链接与结构化图谱；Supertag 与其定位不同（标签流 vs. 链接图）。
• DTD / XSD：XML 的文档类型定义与 XML Schema，用于定义标签的语义，群友借此理解了 XML 的约束机制（"原来XML可以通过DTD，XSD定义标签实际的意义"）。
• enriched-mode：Emacs 的富文本编辑模式，通过文本属性（properties）保存格式信息，可用于隐藏标签（将标签文本用 overlay 或特殊属性隐藏）或实现 buffer 渲染分离。群友感叹"enriched-mode就是"（可能指 XML 编辑的隐藏标签方案）。
• vibe coding：指依赖 AI 生成代码的编程方式，群友对其价值有激烈争论，核心观点为"vibe 本身没有价值"。
• dsh-emacs UI：群友 vritser 分享的自用 Emacs agent UI，支持自动折叠中间任务（类似主流 agent 体验），修复了行高导致的棋盘缺口问题。
• herdr / tuios：Windows 上的 tmux 替代品，支持边侧栏、which-key、通知、动画等现代特性。

💎 碎片知识与金句拾遗

• "开源项目经常能收到 ads 邮件" —— AI 批量爬邮箱的骚扰成为普遍现象。
• "逆向出来个看起来像的东西和做成成品之间的才是 80% 的工作量" —— 对 AI 复刻产品的清醒认知。
• "你根本不知道自己不知道" —— 用户无法评估商业软件全功能，因此"无法做"替代品。
• "腾讯就是典型的有先发优势，你今天再做即时聊天，比微信好用也没用" —— 产品竞争的先发优势不可破。
• "设计克制但实现一点都不克制" —— 评价微信：UI 克制，但技术实现复杂。
• "我混了脸熟， eli那边是知道我签过这个的" —— 与 FSF 沟通的经验：刷存在感很重要。
• "给 Emacs 写 patch 能让感觉到我在严肃编程，不是在写什么玩具脚本" —— 参与核心开发的心理价值。
• "我的 app 已经完美了"（无上下文，可能指个人项目）—— 开发者自满的调侃。
• "一个下午成功移植到安卓了" —— 快速移植某项目（无细节），体现 AI 时代效率。

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

• Supertag：基于标签流的笔记组织范式，与 org-roam 互补。值得关注其"信息面板"实验性功能（LM 生成版式）与本地嵌入服务（Ollama）的集成方式。
• dsh-emacs UI：自动折叠中间任务的 agent 界面设计，可作为 Emacs 中构建类似 Claude/Codex 体验的参考。
• enriched-mode 与 XML 编辑：利用文本属性隐藏标签的机制，可能适用于 eww/shr 的双 buffer 渲染模式（一个显示源码，另一个渲染），是研究 Emacs 渲染管道的好切口。
• Windows 终端替代品：herdr / tuios 等现代 tmux 替代品在 Windows 生态的演进，适合追踪跨平台终端工具的趋势。

观点延伸

中心判断：AI 把“生产”这件事平权之后，被重新定价的不是代码，而是“验收”和“共享动机”。当天那场 vibe coding 争论之所以吵不出结论，是因为双方在用两套不同的成本模型讲话。

一、80/20 的分歧不在比例，在于那 80% 可不可见

“逆向出来像的东西和成品之间才是 80% 工作量”这句话，反方并没有真正反驳，只是把 80% 换成了“用户反馈会填上”。但群里自己给出的最强反驳就是那句“你根本不知道自己不知道”——普通用户列不出 Photoshop 有多少功能，所以既无法提出需求，也无法判断缺了什么。这意味着 80% 的那部分不是靠反馈迭代出来的，它靠的是长期使用中被动暴露的边界情况。反馈能优化已知路径，暴露不了未知路径。这是“半成品导致没人用”成立的真实机制，也是“没人用导致半成品”站不住的地方：没人用，你连暴露未知问题的机会都没有，于是永远停在半成品。这是个正反馈陷阱，不是鸡生蛋问题。

二、AI 平权真正摧毁的是协作激励，不是竞争壁垒

整场讨论里最锋利的一句被轻描淡写带过了：“你 vibe 了一个东西之后，我不满意，为什么我要给你贡献，而不是我自己 vibe 一个。”这才是 AI 对开源的结构性冲击。传统开源的经济学是：复刻成本高、贡献成本低，所以提 issue、发 PR 是理性选择。当复刻成本降到接近零，而理解别人代码库的成本没降（甚至因为 AI 生成的代码风格发散而升高），贡献的性价比就翻转了。结论是：AI 时代不会缺软件，会缺“值得被共同维护的软件”。反过来说，能被留下的是那些复刻成本不为零的东西——数据、网络效应、合规资质、硬件绑定、以及长尾边界情况的积累。代码本身从来不是壁垒，这句话在 AI 之前就对，只是以前被“写得出来的人少”这层假壁垒遮住了。

三、Supertag 与这场争论是同一个命题

群里对 Supertag 的第一反应是“跟 org-roam 好像类似”，这个疑问和 vibe coding 的疑问同构：当生产成本下降，工具的差异就全部转移到“它替你省掉了哪一步思考”。Supertag 的答案很明确——写的时候不用想放哪儿，整理留到需要的时候。它不是更好的组织方式，它是把组织成本从写入时延后到检索时。这个取舍有代价：延后意味着你必须信任检索，而检索质量取决于标签纪律和嵌入质量，这两样都是隐性维护成本。所以“跟 org-roam 像不像”是个伪问题，真问题是：你愿意把不确定性放在哪一端。

四、可继续研究/实践的方向

一个可验证的小实验：拿自己手上一个“能跑但只有自己用”的 vibe 项目，让一个没用过它的人（或另一个 agent，只给 README 不给源码）完成三个真实任务，记录它卡在哪。卡点分布就是那 80% 的地图，也是判断“这东西该不该开源/该不该让别人贡献”的经验依据。比继续争论比例有用得多。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】印度 CA 私钥泄露引发的生态级安全事件

本日讨论的核心焦点是一场由印度证书机构 eMudhra 引发的连锁安全反应。其根证书私钥因过于简单（0~255 之间的随机数）被破解，直接导致整个互联网的 HTTPS 信任体系受到冲击。群内讨论从技术细节蔓延至生态应对策略，形成了以下核心脉络：

1. 事件本身的技术冲击：群友直接指出“代理现在可以解你的 HTTPS 流量了”，这意味着中间人攻击（MitM）的难度从“需要获得权威机构信任”骤降为“简单私钥可破解”。有群友测试发现手机可以轻松打开 https://emudhra.we-have-a-problem.com/，且 mitmproxy 已内置相关支持（PR#8500）。
2. 生态应对的连锁反应：这引发了 PHP、Node.js、Go、Chrome、GitLab 等众多项目的集中式安全更新。其中 Go 的问题并非代码漏洞，而是标准库未能阻止失陷 CA 关联的中级证书通过验证（CVE-2026-111943）。Xray-core 连夜紧急更新（v26.10.21），移除三张根证书并使用 Go 1.27.3 编译。群友的机场“昨夜连夜处理”，但也有机场未发通知。
3. 用户的真实焦虑：讨论中多次出现“很吓人”、“仿佛看到了原子弹爆炸”、“像小白要关心的是浏览器更新和证书问题”等情绪，反映出该事件对普通用户信任体系的冲击。iOS 用户因难以手动处理证书更新而尤为担忧。
4. 应对方案的分歧：一部分人强调“先把系统的证书修复一下”，也有“直接关机等别人来修复”的调侃式提议。关于 Nix 和 Arch 的对比引起讨论，Arch 的反应速度明显优于 Nix，因为 Nix 最新版仍受影响的版本。还有群友总结出自己的应对清单：隔离投毒版本、收紧管理入口、修补 PHP/Node.js/NGINX、处理 CA 信任更新、核查密钥等。

【专题二】 Emacs 生态讨论与全键盘交互理念的碰撞

Emacs 相关讨论在群内持续活跃，从包管理到交互设计都有涉及：

1. 包管理与 monorepo 策略：围绕 emacs-taf 的包管理方式，有群友推荐了 jjosh 工具，并讨论了基于 emacs-taf 构建自定义 MELPA 的方案。有人分享了自己从“主动忽略子项目”转向 monorepo 的经验，但也提及 monorepo 开发环境和用户配置环境不一致的弊端。
2. Embark 与 auto-modal 的对比：有群友感慨“才终于体会到 embark 的妙处”，认为 Embark 的核心优势在于“根据光标所在位置提供对应命令”，不必担心键不够用。而 auto-modal 的开发者承认自己 24 年开发时不知道 Embark，两者逻辑相似但 Embark 更成熟。不过也有观点指出 Embark 的列表式交互不如 auto-modal 的单键快捷命令来得直接。
3. 键盘偏好：关于“所见即所得”与 leader key 操作方式的讨论，有群友主张“能少按一个键就少按一个键”，认为长期使用后应形成肌肉记忆。还有群友购入腹灵 OG87 仿 IBM 老式键盘，但遭遇蓝牙延迟 300 多 ms 的品控问题，决定退货。

【专题三】 AI 代码工具的选择与观望

• 群友普遍从 ChatGPT 转向 Claude：“all in Claude 了已经”、“什么时候好用了再回来”。ChatGPT Plus 的 5h 额度被吐槽为“跟早泄一样”、“20 分钟不到就跑完了”。而 Claude Pro 的额度“现在还没用完”。有人尝试 Claude Duet（可能指 Duet AI 类似物），但对 Pro 是否包含该功能存在疑惑。
• 对 OpenAI 产品体验的失望情绪明显，多位群友表示“已经不买 GPT 了”，仅保留 Plus 用于 code review，且“基本闲置状态”。
• Amp Code 宣布支持 Orbs 自托管，群友对其“BYOK + CLI runner”的路线表示欣赏，但也有疑虑：请求仍在服务端产生，不能自定义 baseurl。

---

🔑 关键概念与技术解析

• CVSS 4.0：通用漏洞评分系统的最新版本，本次 PHP 两项漏洞评分均为 9.2 分，属于严重级别。该评分体系将漏洞的严重程度量化，便于不同团队评估优先级。
• MitM（Man-in-the-Middle）攻击：中间人攻击。攻击者通过某种方式（如伪造证书）插入通信双方之间，可解密、篡改或转发流量。本次 CA 事件让代理软件理论上具备了这种能力。
• BYOK（Bring Your Own Key）：一种云服务模式，允许用户携带自己的 API 密钥（如 OpenAI/Anthropic 密钥）使用第三方工具，避免通过服务商间接调用。
• Embark：Emacs 的上下文菜单框架。核心思想是根据光标所在位置的对象类型（如代码符号、链接、文件路径）动态弹出对应的命令列表，将“键位分配”转化为“光标位置感知”。
• monorepo：将多个相关项目放置于同一代码仓库的管理策略，便于统一依赖管理和构建，但会带来开发环境和用户环境配置不一致的兼容性问题。
• MVU（Model-View-Update）：一种单方向数据流的 UI 架构模式（源自 Elm 语言）。群内讨论中曾提及，但被指出与所讨论的“构造模式”并不完全一致。

---

💎 碎片知识与金句拾遗

• “wezterm 几乎没有使用，待机后内存会神奇的增生。” —— 对终端模拟器内存泄漏问题的观察，令人困惑但真实存在。
• “如果你能做出 commercial emacs，必成大器。想不出来 commercial emacs 能怎么做。” —— 对 Emacs 商业化可能性的调侃，暗示其社区驱动的本质。
• “我感觉从 24 年起，几个大的游戏公司开发新作的速度就大幅减缓了。他们之前的营运方式已经落后了。” —— 对游戏行业现状的观察，EA 关闭 BioWare、索尼停止资助小岛秀夫被视为佐证。
• “索尼相机也被逆向了，系统可以安装富士的内置滤镜，不得了。” —— 对封闭生态被破解的感叹，群友认为“要么矛盾之争，要么以后软件就没什么封闭墙了”。
• “阿里的提醒也太迟了吧，13:59 收到的，给你的提醒就不错了。” —— 对云厂商安全通知时效性的吐槽，透露着“有就不错了”的无奈。
• “喜茶的雪毫，就是张一元的茉莉花茶，一模一样。两杯喜茶就可以买 50g 了。” —— 对奶茶行业用料成本的揭示，群友补充“很多奶茶店都买便宜的茉莉花、滇红做茶底”。
• “果茶既丢失了水果的口感，也丢失了水果的膳食纤维，而且果糖比奶茶还夸张。” —— 对果茶消费的健康提醒。
• “自己做奶茶：滇红底子炒热加红枣，冲出来茶汤，捞走渣渣，加入鲜奶和一点冰糖，包好喝的。只要注意茶少放点，放多了茶肯定就涩。” —— 一份实用的 DIY 奶茶配方。
• “乳糖不耐？喝多了就自然耐了。” —— 对乳糖不耐问题的实用主义解答。
• “Rust 的编译期检查很重就需要很多中间产物，搞 rust 得准备个 16TB 的硬盘。用 CPU 换硬盘，你这就因噎废食了。” —— 对 Rust 编译期消耗硬盘空间的吐槽与对策讨论。
• “重置也说明快不行了，有新 IP 可以搞谁愿意搞这个。” —— 对暴雪重置星际 2 的解读，认为这是 IP 枯竭的标志。
• “群友们会读 Makefile 的逻辑吗？400 多行的 Makefile 看的我脑壳有点痛。” —— 对古老构建工具的困惑，回答建议是“让 AI 读了给你解释”。
• “这个 terminal 模仿打字机的效果。” —— 对某终端模拟器（可能指 World Model Terminal）的趣味点评。
• “终于到 6000 了。。。果然，增加活人感才行。” —— 对社交媒体/社区运营的观察，暗示真实互动比灌水更能提升数据。
• “新键盘到了，腹灵 OG87，仿 IBM 的老式键盘。手感很像薄膜，蓝牙延迟 300 多 ms，正在准备退货。” —— 对键盘品控的失望体验。
• “那个 IBM 老键盘是弹簧的，手感很独特，带劲。当年 RMS 的手可能就是敲这种键盘废的。” —— 将 RMS 的手伤与经典键盘联系起来的趣味联想。

---

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

• World Model Terminal（simedw.com/2026/10/21/world-model-terminal）：直接用模型模拟软件界面的终端概念。用户向模型发出指令，模型模拟 TUI 响应，且具备自学习能力。群内有群友提议“训练一个 emacs 模型”，这一方向若成熟，或将彻底改变 Emacs 交互范式。
• jjosh（github.com/0WD0/jjosh）：嵌入在 monorepo 中开发的工具，兼容性问题考虑较少，但为“自定义 MELPA 构建”提供了参考。其 bazel 构建方式值得研究。
• emacs-apps 组织（github.com/emacs-apps）：一个隐藏的 GitHub 组织，专门开发 AppKit 相关 Emacs 应用。其组织管理方式（隐藏 admin、无成员但可推送）以及 AppKit 与 Emacs 的结合路径值得关注。
• Amp Code 的 Orbs 自托管方案：Amp 宣布支持自托管 Orbs，并引入 BYOK + CLI runner 模式。尽管不能自定义 baseurl，但“服务端请求”与“本地执行”的边界如何划分，值得深入评估。

观点延伸

今天真正值得细想的是当天出现了几种互不相同、却都撞到同一处限制的讨论：普遍习惯用“局部没暴露”来解释安全，用“键还够用”来解释交互；到了今天，这两个假设都已经接近失效边界。

键位并不会稀缺，光标位置的语义才稀缺

Embark 真正解决的是一个命名空间问题：它把命令和按键解耦，命令不再需要预先占用一个全局键位，改为挂在光标所在的对象上，根据当前光标位置按需出现。更准确的说法是：命令的寻址方式从按键序列换成了对象类型，所以不必再担心键位不够用。这件事跟界面无关，关键是命令以什么方式注册。

auto-modal 走的是另一条路：用 major mode 加光标条件来决定触发；条件命中时，单键直接执行命令。“能少按一个键就少按一个键”这个想法本身成立，但它省下的是按键，透支的却是隐式状态机。同一个光标位置上能成立的谓词越多，可用的字母就消耗得越快；到了那一步，leader key 就不再是审美上的缺陷，而是键空间不足时的必然退让。这一点可以实测：先把手头的谓词全部列出来，再数一数同一个 target 下同时生效的命令有几个，最后看还剩几个字母可用。

所以两者是分层关系，并非竞争关系。群里说“auto-modal 加个命令列表就是 embark”，这话没错；反过来说也成立：只要给 embark 补一个在没有 target 时使用的全局后备入口，就能覆盖“不关心光标在哪、但要触发全局功能”的场景。真正应该先定下来的是 target 协议，也就是对象如何识别、动作如何枚举。这一层定下来之后，上面挂列表还是挂单键，就都只是具体策略了。

“我自部署的都没放公网”是今天最危险的一句话

这次失陷的是信任根，并非某一家服务。MitM 的落点在客户端的验证链上，不在服务器暴露面上：只要浏览器或运行时信任了那张中间证书，攻击者就能站在你和任何站点之间，你访问别人的站点时同样如此。不放公网只能降低被扫描到的概率，无法防止被冒充。

顺着这条线索，关于代理的那点争论也能得出确定结论：代理本身不持有会话密钥，能做文章的是客户端的信任库，以及那些自己 bundle CA 的二进制。这同时解释了为什么 Go 这次的问题实质是验证链缺陷，而不是代码漏洞；也解释了为什么“覆盖运行时、容器和实际部署的二进制”比更新系统证书难得多，而且必要得多。

更该记住的是那句“这个 CA 还有些不舍得修”。它暴露出来的是“信任可控”的诱惑，而不是无知。一旦你发现自己能解开自己的流量，短期便利就会压过长期风险。这类判断靠自觉没有用，只能靠默认值来托底：自动更新、bundle 优先、关键路径显式固定。

可继续动手的方向

给 auto-modal 和 ETAF 做一次键空间压力测试：把谓词全部列出来，统计每个 target 上同时成立的命令数，找出必须退化成列表或双键的临界点。把“手感”变成数字，比再争一轮“哪个更好用”更有用。