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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 在 Windows 上的性能陷阱与路径查找开销

这是本日讨论最深入、最硬核的话题。围绕 Windows 环境下 Emacs 的卡顿问题，群友从函数调用、路径查找、进程开销等多个维度做了深度剖析：

• exec-suffixes 的查找开销：Emacs 查找可执行文件时，会按 exec-suffixes 列表（默认 ("" ".exe" ".bat" ...)）逐一尝试。空字符串排在最后面，导致找 git 时实际尝试 git、git.exe、git.bat、git.exe.exe... 最坏情况要遍历 PATH 目录数 × suffix 数。有人提出应把空字符串移到最前面避免 xxx.exe.exe 的搞笑情况，并计划给上游发补丁。
• executable-find 是热点函数：群友断点调试发现，几乎任何操作（dired、保存文件、查看文档）都会触发这个函数。Emacs 高耦合架构导致功能重复的函数被反复调用，且完全没有缓存。
• call-process 开销对比原生 CreateProcess：裸调用 CreateProcess 对比后发现，Emacs 的 call-process 多了大量 IO 请求和注册表读取，路径转换、软链接检查等步骤在 Windows 上尤其明显。
• find-file 被挂 10+ 个 hook：导致打开文件等待 1-2 秒，群友已手动删减。
• 结论：Emacs 慢的根源在于热点函数无缓存 + 沉重的 hook + 单线程假设。有人建议读 normal-top-level 理解初始化流程，也有人感叹"重写个 emacs 把这些用得不多的功能都删了"。

专题二：AI 时代下的开发模式与开源社区演变

围绕 AI 辅助编程，群友展开了多轮观点碰撞：

• vibe coding 成主流：有人明确表示"平时是 vibe coding 的"，写插件"只做给自己用"，甚至有人"上个月写了 9 个插件，自己用上 7 个"。开发本身不再是瓶颈，AI 把成本压到了极低。
• AI 对开源/闭源的影响：有人提出"AI 对闭源软件的伤害更大，直接给你复刻出来了"。开源社区方面，大家开始"懒得考虑兼容性需求"，比如"只支持 emacs 31"、"只支持 emacs master"。
• AI 代码质量问题：有群友坚持"还是要人审的，因为 AI 会降智"，并建议"一个 PR 召唤 copilot、claude 和 gpt 审核"。关于 artificialanalysis.ai（AA）榜单，有人指出"分数被刷成野榜了"，目前没有特别好的榜单可参考。
• AI 项目维护方式：有人提议 AI 项目"出了问题就本地魔改然后让 AI 把东西传上去"，但也有人强调正式项目还是要按流程走。

专题三：Mimo AI 助手的使用体验与性价比

小米的 Mimo 引发了小范围讨论，核心围绕免费转付费后的实际体验：

• 白嫖时代已结束：以前 mimo-v2.5 免费且无需登录，现在取消了免费额度。付费 token plan 约 50 元，实际只够用 2-3 天。
• loop 问题严重：经常 thinking 几分钟后点进去发现是死循环，付费模型同样如此。有人评价"token plan 太拉了"。
• 替代方案：有群友推荐 opencode 仍可免费白嫖且无需登录，还有 Mimo 的记忆压缩做得不错但移植出来 bug 太多。

🔑 关键概念与技术解析

• exec-suffixes / load-suffixes：Emacs 查找可执行文件/加载文件时尝试的扩展名列表。群友强调 exec-suffixes 的重要性比 load-suffixes 更甚，因为它影响所有 call-process 和外部程序调用。
• executable-find：Emacs 核心函数，用于在 PATH 中查找可执行文件完整路径。被群友定位为 Windows 上的热点函数，每次调用都要遍历 PATH × suffix 列表。
• dsh-emacs：群友开发的一个 Emacs 配置/框架，0.1.5 版本较稳定，最新版适配问题导致 dsh-server did not become ready within 30s 错误。
• vibe coding：指完全依赖 AI 进行编程开发，不做手工编码，强调"一句话做出来"的流程。
• ASTRA / SOL / Claude 5x：群内常用的 AI 模型代号，ASTRA 有 Medium/High/Ultra Fast 档位，SOL 更适合日常任务，5x 有 5h limited 窗口限制。token 消耗量是群友常讨论的话题。
• eglot 与 LSP：Emacs 的 LSP 客户端。作者不推荐在 hook 里挂 eglot-ensure，官方建议手动 M-x eglot 每个项目调用一次即可自动管理同一项目内所有文件。

💎 碎片知识与金句拾遗

• "省略后缀一时爽，查找文件火葬场" —— 对 exec-suffixes 问题的精辟总结。
• "AI 是没有 ui 审美的。整个界面找不出来两个相同的边距，四种高亮有三种样式。" —— 群友对 AI 生成 UI 的吐槽，观察极其细致。
• "程序员的未来究竟会变成什么样" —— 群内无解的灵魂拷问。
• telega 作者住院期间还在优化 telega-server，群友感叹"太拼了"。
• 有人已完成 macOS 生态迁移：密码用 bitwarden、音乐自己做 iTunes 替代品、照片用 digikam + darktable、日程笔记用 org agenda + 自研 app。"能不被苹果生态绑架，太有魄力了"。
• Elisp 的评价："语法层面比 py 好，py 的语法给我一种 bash 的感觉"，"Windows 的 bat 给我一种汇编的感觉"。
• Emacs 代码量：整个项目 300w 行代码，其中 200w 行 lisp、60w 行 c，"很佩服整个项目用 c 写了 60w 行"。
• Elisp 单线程无异步："消息循环加 timer 的算的话就有"，简单 IO 场景如读文件时不能干其他事。
• 二手 T480 推荐："很适合 linux，所有硬件开箱即用，花了不到 2000，跑 emacs 性能足够"。
• 有人已经把"给 rime 做性能优化"做完了，并自研了 simpcpp-mode 独立包，替代速度慢的 c/c++-mode。
• "AI 对闭源软件的伤害更大"——直接复刻出来你就没法收费了。
• 群管理现状：spam 严重，"每天删 spam 的频率比发言高"，广告机器人通过 inline bot 召唤，有人提议加验证和 bot 审核机制。

🛠️ 值得深入研究的点

• exec-suffixes 上游补丁：群友表示"最近打算发邮件讨论"，把空字符串移到最前并考虑加缓存，可显著优化 Windows 上 Emacs 的启动和外部程序调用速度。
• dsh-emacs 0.1.5-rc2：群友反馈"用起来了，真的变快了"，尽管使用硬盘存储也能感受到明显提升，值得跟踪后续版本适配进度。
• simpcpp-mode：群友自研的 C++ 语法模式，独立发布在 GitHub（https://github.com/zHaOdANiuu/simpcpp-mode），作为 c/c++-mode 的轻量替代品，值得关注。
• tree-sitter-org：被问及后续开发计划时作者回应"没时间做"，但需求仍在，可关注未来是否有社区接力。

观点延伸

今天表面在聊 Windows 上 Emacs 卡顿，实质是一次很标准的性能剖析演示：真正贵的不是"某个慢函数"，而是被高频调用却完全不缓存的基础设施。

一、executable-find 的问题是架构性的，不是配置性的。exec-suffixes 默认把空字符串排在最后，于是找 git 会一路试到 git.exe.exe 这种荒唐候选，最坏开销是 PATH 目录数乘以后缀数——这也解释了为什么 magit 慢在这条路径上。更关键的是这个函数几乎无缓存，dired、保存文件、甚至查文档都会触发。所以 Windows 卡顿不是某个插件写得烂，而是 Emacs"用便利换性能"的默认假设，在注册表读取、路径转换、软链检查的叠加下被放大。调整后缀顺序、给查找加缓存都是对的方向，但缓存真正的难点不是顺序，而是生命周期：PATH 在会话内变化时的失效策略若不定义清楚，就会变成新一代"玄学 bug"。上游补丁值得发，但审的重点应该在这里。

二、"热点函数"比"热点功能"更难治。 讨论里出现了一个很有价值的分歧：find-file 到底算不算热点。答案取决于视角——从内核看，原生 hook 只有六七个；从配置看，有人挂了十多个，打开一个文件要等 1–2 秒。同一句抱怨背后的归因可能完全不同。更值得记的是那句自我纠正：聊着聊着发现"我自己的配置也有能优化的地方"。性能问题上，先量化再归因，永远比先改配置省钱。

三、AI 让"写"变便宜之后，稀缺品换人了。 "开发本身已经不是问题了"是当天信息量最大的一句，证据也扎实：一个月写 9 个插件、自己用上 7 个；只支持 Emacs 31 甚至 master 不再犹豫；两三百块就能搓出一个 org 应用。但紧跟的限定更值钱——"org 需要打磨的细节很多"，agenda 的时区处理就是典型：不难，只是没人被逼着做，多数人甚至没意识到要处理。于是瓶颈从实现挪到了三处：审阅、细节、需求识别。这也解释了为什么"一个 PR 召唤多个模型审核"和"AI 没有 UI 审美"会出现在同一天。但把审阅整体外包给模型同样危险：多模型投票只能降低明显错误的概率，替代不了"我知道这个项目要什么"。

可继续的方向： 做一次"热点审计"而不是"包审计"。在 executable-find、find-file、call-process 这几条真正的热路径上打断点或加计时，记录一周的调用次数与耗时，再决定删哪个 hook。这比换机器、换发行版更能解释体感差异。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】智谱 ZCode 开源风波：信任崩塌与行业讽刺

群内本次讨论最大焦点是智谱 AI 开源 ZCode 引发的轩然大波。事件经过及群友观点整理如下：

• 导火索：智谱开源了 ZCode（一款 Claude Code 风格的编程 Agent），但开源版本被指存在大量问题——不携带任何 history、关闭 Issue 和 PR 功能、设置了仅官网下载版本才可享受 150% 额度优惠的区分。
• 群友反应：群内情绪以嘲讽与愤怒为主。有人讽刺“如开”“不打自招”，认为这不过是“被迫的开源”“逗逗大家”。更有群友发现 GitHub Commit 页面仍可评论，于是“大型社死现场”出现——大量用户在 commit 页面下冷嘲热讽。
• 行业对比：群友对比了 xAI 的 Grok 开源事件。Grok 此前因被曝偷偷上传用户代码而被迫开源，但其开源版本至少是从内部 monorepo 同步代码，是“合理的”；而 ZCode 则是“基于闭源版 vibe 一个开源版”，属于“裁剪版都算不上”。
• 法律讨论：有群友质疑“收集用户代码是否违法”。回答称“侵犯商业机密”“非法获取数据”“侵犯著作权”等罪名理论上成立，但“取证困难”，对方律师可狡辩“没有存储”，而逆向者反而可能面临法律风险。
• 后续影响：群友认为智谱“把自己主要用户干黄了”，“价格本来就没啥普通用户会开”，如今更是在程序员社区中名声扫地。更有“每周 reset 一次”的传闻被视为火上浇油。有人感叹“两个傻逼 AI 公司，字母一头一尾，国家一中一美”（暗指 OpenAI 与智谱）。

【专题】AI 模型使用体验：降智、烧钱与“旧物新生”

• 降智焦虑：多位群友反映在使用 GPT（如 Astra、Codex）时遇到明显的“降智”体验——正到关键时刻突然变笨。有群友分享了 is-gpt-nerfed 检测脚本（见下文），并感叹“现在 chat 没有长度上限了，直接变 413 了”。有人索性“不用 GPT 写代码了，全部交给 DS，它就是规划 + 复查”。
• 烧 token 问题：Astra 被普遍吐槽烧 token 太快，“整理文档可以烧掉 20%”“low 都能这么快”，有用户因成本问题退回使用 Luna。
• “旧物新生”趋势：群友惊讶于 JEV（被形容为“更泛用的分类器”）和 Browser Use / CUA 等技术的复兴，感叹“最近怎么都是老物新生的 feel”“古代科技震撼人心”。有人认为 OpenAI 若继续加强 Computer Use 能力，不如外挂一个类似 System1 模型。

---

🔑 关键概念与技术解析

• CUA（Computer Use Agent）：指能直接操作 GUI 界面的 AI Agent，通过截图/DOM 等方式与系统交互。群友认为 CUA 的核心在于“让 Agent 自主迭代”，但“不是很依赖模型能力”，且“GPT 疯狂训练这个能力可能就走偏了”。
• CDP（Chrome DevTools Protocol）：Chrome 的远程调试协议。Google 基于 CDP 开发了官方 MCP（Model Context Protocol），让 Agent 能通过 MCP 直接操作 Chrome。群友指出这是比“图片识别”更稳定的方案，“能用程序操作的就不要靠截图，图片分析消耗 token 还不稳定”。
• Browser Use：基于 Playwright 等工具实现浏览器自动化的 Agent 方案。原理是通过 CDP 或 DOM 获取页面结构，直接由程序操作，避免截图带来的不稳定性和高 token 消耗。
• is-gpt-nerfed：一个用于检测 GPT 模型是否“降智”的开源工具（github.com/kiyoakii/is-gpt-nerfed），在群内被多次提及。
• ZCode：智谱 AI 推出的编程 Agent，开源版本存在无 history、关闭 Issue/PR、AB 版差异化优惠等问题，被群友嘲讽为“如开”（如同开源）。
• GLM-5.3 / Deepseek V4 Flash：群友对比了两款国产大模型的“条理性”，认为 Deepseek 即使不是 4.1 版本也“比 GLM 5.3 做事情有条理”。
• GPT-6 Astra 与哥德巴赫猜想：群内转发了一则消息，声称 GPT-6 Astra 在数论领域取得突破，无条件证明了哥德巴赫猜想的刘维尔弱形式，且已通过 Lean 4 形式化验证。群友普遍表示怀疑（“弱太多了这个形式”“等 Hodge 或着 BSD”），但这一消息本身引发了关于 AI 数学能力的讨论。

---

💎 碎片知识与金句拾遗

• “Deepseek 哪怕不是 4.1，就是 V4 Flash，也比 GLM 5.3 做事情有条理（泣）” —— 群友对模型能力的主观排序。
• “我很讨厌 orca 一打开就在我的主目录塞满了 .xxx” —— 对软件“乱拉屎”行为的不满。
• “程序员靠正规技术工作赚 USDT 完全行得通，但在 Web3、跨境远程办公圈子里非常普遍，这属于远程技术劳务结算，绝对不叫‘打黑工’” —— 群友科普 USDT 获取方式。
• “某种意义上，不交税的就是黑工” —— 对“打黑工”一词的调侃式定义。
• “我之前换币银行卡被冻过” / “卖 U 是很危险的” —— 群友分享 USDT 交易的真实风险经历。
• “道歉、赔每一个用户一年 plan 是不是可平众怒” —— 对智谱事件的调侃性建议。
• “目标已经达成了，吸引新用户，现在用户多到算力不够都停止新用户订阅了” —— 对 OpenAI 重置策略的解读。
• “模型直出的系统图/流程图/架构图等 比生成 mermaid/plantuml 再出图好非常多” —— 群友对 AI 直出 SVG 效果的认可。
• “我发现有很多 cpu 跑的算法可以让 ai 重写到 gpu 上，直接加速上千倍” —— 分享 GPU 加速经验，并推荐了 cutile-rs 项目。
• “我遇到这种依赖问题就是直接 import 到 monorepo 里改了” —— 对依赖管理问题的极客式解决思路。
• “完全突破了 emacs 固有的交互方式，有了 etaf 之后，emacs 也和微信一样，可以运行多个小程序了” —— 群友介绍自己用 Ebox/EATF 将 Emacs 变成桌面系统。
• “这篇文章很好，他提出了一个大型项目的【软件工程】” —— 推荐了 software-architecture.html（matklad 博客）一文。

---

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

• is-gpt-nerfed：检测模型“降智”的开源工具，可作为评估模型服务质量的日常参考。
• cutile-rs（NVlabs）：让 CPU 算法快速移植到 GPU 的 Rust 库，对需要性能优化的开发者极有价值。
• Chrome 官方 MCP（基于 CDP）：官方推出的浏览器自动化方案，比第三方截图方案更稳定高效。
• Ebox / ETAF：群友自研的 Emacs 桌面环境框架，目标是在 Emacs 内实现类微信小程序生态，理念新颖且有实际演示，值得关注。
• GPT-6 Astra 的 Lean 4 数学证明：虽然群友普遍怀疑，但若属实，将是 AI 在数学研究领域的重要里程碑，值得跟进验证。
• 代码审计：git 监控可疑流量：有群友提出“以后要分析流量，看看有没有可疑行为”，结合 ZCode 事件，更凸显了审计开源软件网络行为的重要性。

---

本文基于群聊记录整理，部分技术细节可能因消息碎片化而有所简化。群聊记录中提到的第三方信息（如 GPT-6 Astra 数学突破）未经核实，仅供参考。

观点延伸

今天群里几件事吵的是同一个问题：能力无法被验证时，能力就不构成可用性。 判据不是"功能有多少"，而是"我能不能确认它究竟做了什么"。

一、伪开源的真正代价，不是开源得不够彻底，而是关掉了可追责的接口。 ZCode 把 Issue 和 PR 一并锁上，等于连公开的失败记录和修复历史都省掉了；最后大家涌到 commit 页面留言，说明社区的要求低到只想有个能留痕的地方。群友对比 Grok 时给出的判据其实非常工程化——"至少真的从内部 monorepo 同步代码"。这条可以直接当工具用：判断是否真开源，不看 LICENSE 和 README，看发布物是不是主干的构建产物、release 是不是 CI 出的、相邻版本能不能对上 diff。LICENSE 只是授权动作，可复现构建才是开源的事实形态。对个人工具链的推论很直接：选依赖时，"能否读到源码、能否提 PR、能否看清 diff"应当和功能并列成为选型项，否则今天省下的选型时间，将来会变成一次无法追责的意外。

二、CUA 的截图派与 CDP 派之争，是同一母题。 "能用程序操作的就不要靠截图"这句话可以被推广成 agent 设计的一般原则：截图是观测，产出的是概率；CDP 是接口，产出的是确定性。优先走带 schema 的接口，把视觉理解压缩到确实没有接口的那最后一段。群里对 JEV 的描述——"一个更泛用的分类器"——和"不如外挂一个 system1 模型"的建议，指向的是同一件事：不要指望单个大模型端到端地"看懂并点准"，而要把它拆成若干可局部验证的小决策。这也解释了为什么持续重投 computer use 让人感觉"走偏"：涨的是观感上的流畅，不是可复现的成功率。有人实测点侧栏调试断点重试十几次仍不中，就是这个差距的具象。

三、成本那条线接得上。 有人把 GPT 降级为"规划 + 复查"、主力交给别的模型；有人抱怨降智"正到关键时候发生"、整理个文档烧掉两成额度。这两件事是一体两面：你不知道它在哪一层省了力气，也不知道它什么时候换了档。上下文放开、一次连续作业拉长到数天之后，不可验证的面积只会更大。

可以继续实践的方向：给自己常用的 agent 与 harness 做一次可审计性盘点——逐个标注能否读到源码、能否观察到出站流量、出问题能否留下公开记录；先落最小的一步，把出站域名固化成白名单、异常即告警。与其指望供应商自律，不如让自己随时能答出"它到底发了什么出去"。