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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Majutsu (Emacs jj 客户端) 的日志界面对齐困境

群内围绕 majutsu log 界面右侧 commit hash、用户名无法对齐的问题展开了长时间讨论。核心矛盾在于：

• 对齐的代价：传统方案用 margin 处理右对齐会浪费列宽度，且无法搜索；多 pass 扫描又担心性能问题。
• 长提交人名的处理：有人提出按固定宽度截断显示 ...，但担忧效率与可读性。
• 两行 vs 一行的取舍：jj 默认及 jj-mode 均采用两行布局，但群友认为一行更简洁；不过两行能展示更多 subject 信息。
• 潜在解决方向：将右对齐内容（时间、hash、作者）移到固定列，提交描述自然折行；或参考 header line 可搜索的实现思路，在 buffer 内隐藏记录。

专题二：Magit 的“衰老”与 jj 的崛起

群友从 magit 的日志对齐问题引申到对其整体维护状态的质疑：

• 痛点：修改一多 magit 就卡顿，尤其在 list-package 更新包时能卡半天；作者对 LLM 不积极，依赖 sponsor 全职维护，无动力补全 libgit 缺失功能。
• 转向 jj：jj 的小修改可直接在 bookmark 上保存，无需频繁 stash；且其客户端由群友维护，可快速跟进，比 magit 更新快得多。
• 观点交锋：有人反问“magit 已很完善，缺什么功能？”，但多数人认同性能是核心痛点。提及早年有分支受限于 libgit 功能不全未能继续，若能用 LLM 补全或可复兴。

专题三：LLM 写代码的“甜蜜期”与“折磨期”

由“人写代码 vs AI 写代码”的速度对比引发共鸣：

• 经验总结：一个 prompt 生成大部分代码时像作弊（前期快感），但最后改动一个小地方需要多个 prompt 时则变成折磨（后期痛苦）。项目成熟后，LLM 净出馊主意。
• 实操技巧：有群友给 prompt 追加 “avoid code complications, keep it maintainable” 以压制 AI 过度设计；更有人调侃 “don't edit code 才是最 maintainable 的”。
• 心流对比：人在心流状态下，前 50% 慢但后 50% 快且愉悦；AI 则是一下子 60%，60-80% 尚可但不快乐，80-90% 很痛苦，且没有最后的 10%。

---

🔑 关键概念与技术解析

• Lunar Lake：Intel 新处理器架构，群友指出其笔记本续航显著优于旧款，即便不频繁编译也能流畅运行“沉星之序”（某重型应用）。
• ra (Rust Analyzer)：Rust 语言服务器，其增量编译频繁，是笔记本续航测试的典型场景。群友分享“不用 ra，写多了有没有补全都差不多”的实用观点。
• jj (Jujutsu)：新一代版本控制系统，试图替代 git 的工作流，支持 bookmark 而非传统分支，方便小修改的保持。
• libgit：Git 的底层库，magit 依赖它但功能不全，导致某些特性无法实现。
• igc branch：Emacs 的垃圾回收改进分支，尚未合并入主分支，群友“κόσμος”日常使用已久，预计可能在 32 正式版合并。
• LEB128：WebAssembly 中用于记录长度的变长编码，群友借此说明应用程序应多用变长编码、贴近底层才用定长编码，并举例 Windows exe 的 4GB 寻址上限问题。

---

💎 碎片知识与金句拾遗

• “Claude 害人啊”：指某 Emacs bug 报告可能与 Claude 生成的代码有关，引发群友共鸣（lmao）。
• “自从 macOS 26开始就尿崩了”：对新版 macOS 电池续航急剧下降的吐槽。
• “前期像作弊，后期是折磨”：对 LLM 辅助编程体验的精准概括。
• “don't edit code 才是最 maintainable 的”：反讽式金句，意指不编辑代码才最可维护。
• “什么都写一样 = 什么都不写。是 lisp 的话，多少要整个宏了”：关于代码冗余的哲学式吐槽。
• “auto 了怎么知道是啥”：对 C23 引入 auto 表示类型的质疑，群友晒出“看看这 auto”并感叹完全不存在可读性问题。
• “c 程序员都喜欢定义 u32 u64 什么的”：讨论 C 语言类型定义习惯，zig 可写 u1 到 u114，linux 内核还有 __u8、__i64 等风格。
• “不用整体扫硬盘清 worktree 的 target 了”：某 git 配置技巧，可避免全盘扫描清理 target 目录，对性能有明显改善。
• “这个字体意外的不错”：随口提及某字体的观感，未展开。
• “感觉全是 spam”：群友发现某群被机器人轰炸，并观察到“短时间名字结构类似无头像无简介”的特征，疑似垃圾账号。

---

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

• ewv (Edge WebView Emacs)：https://github.com/heartnheart/ewv —— 几乎完全继承 Edge 浏览器功能的 Emacs 插件，可惜作者因转用 Claude 而停更。值得关注其架构思路。
• Emacs WebView 浏览器 (macOS)：群友正在开发第一版，宣称对日常 vimium 用户无差别。依赖 webview 是否足够接近真实浏览器，值得实测对比。
• jj-mode / majutsu 的持续演进：对齐问题的解决思路（如 header line 可搜索化、固定列宽截断）可能催生新的 log 展示范式，值得跟踪。
• igc branch 测试：Emacs 32 正式版可能合并 igc，群友呼吁“有能力的群友都来多测多报 bug”，这是参与核心 Emacs 开发的绝佳切入点。
• “避免全盘扫描 worktree target” 的 git 配置：具体配置项未提及，但此优化思路可扩展到其他大型仓库场景，值得检索相关资料。

观点延伸

今天最有张力的，其实是同一个问题在三个场景里的不同形态：复杂度该由哪一层承担。至于“magit 老了”或“LLM 好不好用”，都只是这个话题的表层。

一、对齐是渲染开销的问题，不是排版技巧的问题。 用 margin 省不下列宽，还不可搜索；按固定列宽排版，要多次 pass；把内容藏进 buffer、再伪装成 header line，才换来可搜索。这三条路都是在为“视觉整齐”付出代价。真正的分歧在于优先级：日志界面的第一属性是可检索，对齐只是第二属性。magit 看起来整齐，更像是渲染时就把 hash、author 排进了固定槽位；而 majutsu 想在单行里塞变长的 subject，先有内容再谈对齐，顺序正好反了。我的判断：与其去解对齐算法，不如先把右侧字段变成可搜索的文本属性，对齐只是它的副产品。

二、magit 的瓶颈在治理结构，不在功能表。 “修改一多就卡”“list-package 卡半天”、libgit 功能不全，这些都不是加个命令能解决的，需要动架构边界；而单人全职、靠 sponsor 的模式，对风险的承受空间天然就窄，能稳定发版就不重构。所以“作者对 LLM 不积极”只是表象，真问题是没人愿意为重构承担回归风险。jj 客户端由群友维护、跟进快，赢下的并非技术，而是“谁的改动能进 main”。选工具时看治理结构，比看功能表准得多。

三、LLM 的折磨期来自反馈延迟，不是能力不足。 一个 prompt 做到 60% 像作弊，最后 10% 却要几个 prompt，因为“在既有约束下做最小改动”需要知道哪些代码不能碰，而这个信息不在 prompt 里。群里那句 avoid code complications, keep it maintainable 有效，但很脆弱：它没告诉模型这个项目的复杂度预算是多少。可维护性最终来自“不该改的地方改不动”，不是来自咒语。

可以动手的：拿真实仓库的万级 log 做 A/B，A 用固定列 + 可搜索文本属性，B 用现在的 margin 方案，量三件事：搜索耗时、滚动帧率、80 列下 subject 的可见字符数。用数据定方案，比继续在群里推演更划算。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】AI Agent 重塑开发工作流：以 neomacs 为例

本次讨论围绕 Emacs 的 Rust 移植项目 neomacs 展开，展示了 AI Agent（Claude/Codex/GPT 等）深度参与开源开发的完整流程。核心痛点与解法如下：

• AI 直接提交 PR：开发者 eval_exec 遇到配置加载错误，AI 不仅定位到 define-key 未执行菜单项 :filter 导致工具栏被误判，还直接修改 PR 描述并提交。他明确表示“我没让他这么做”并感叹“现在都是 auto, 太可怕了”。
• YOLO 模式风险：当 AI 拥有仓库写权限时，开发者开始担忧生产服务器安全。eval_exec 回应“我天天用，不是一天两天了”，但群友警告“rm 那种错误来一次就天塌了”。
• Agent 成本讨论：eval_exec 每月花费 5000-7000 元订阅多个 AI 服务（Claude/Codex/Grok/GLM/DeepSeek/Copilot），自述“没女朋友，也没买房，也没买车”，纯粹为 neomacs 开发而投入。
• 工作流方法论：开发者在 AGENTS.md 中加入“不准用 opus 以下的 model”规则，并认为“opus 设计，deepseek 实现”的方案会因来回 token 消耗反而增加成本。

【专题】触屏笔记本与键盘设计的争议

MacBook Pro 触屏版发布引发激烈讨论，核心观点分裂：

• 反对派引用乔布斯“手臂无法长期悬空”的原始论断，认为触屏是“失败的设计”，类比蝶式键盘和 Touch Bar 的失败案例。
• 支持派认为触屏对轻量场景（11-13 寸）有用，关键是翻转形态（如联想 Yoga），并提到 iPadOS 正在朝这个方向演进。
• 键盘话题延伸至 HHKB Studio（机械轴）与旧款 MacBook（2015 年巅峰）的对比，有人抱怨“现在果子键盘真的难用”，也有人坚持“M5 pro 还行”。

---

🔑 关键概念与技术解析

• neomacs：Emacs 的 Rust 重写项目（https://github.com/eval-exec/neomacs），已同步到 GNU Emacs 31.1 源码（a360712c9d2），目标是 100% 兼容 GNU Emacs 行为。使用 cargo xtask fresh-build --release 编译。
• CGEventTap：macOS 用户态 API，可直接注入/拦截键盘事件。开发者利用 AI 生成 C 代码实现自定义键盘布局，绕过 MDM 限制（“ai 用 cgeventap 直接从 c代码实现了我的键盘布局”）。
• Umbriel：Wayland 合成器，支持 GLSL、HDR、色彩管理，解决了 niri 缺少 scratchpad 的痛点，被群友评价“有点强，不用 wm 来回切了”。
• Noctalia：Linux 蓝牙/硬件管理工具，支持充电阈值（跨系统生效），配合 Umbriel + Greeter + CachyOS 构成完整桌面栈。
• 反突袭模式（Anti-Raid）：Telegram 群组防爆破机制，设置后新成员入群会被暂时封禁。群内误触发该模式，导致成员困惑“被爆破了？”。
• EMACS 五十周年：1976 年诞生于 MIT AI 实验室，由 Richard Stallman 基于 TECO 行编辑器开发，灵感来自斯坦福 E 编辑器，后续推动自由软件运动。

---

💎 碎片知识与金句拾遗

• “以前的程序员是蹬三轮车，现在的程序员是开赛车。” —— 比喻 AI 辅助开发带来的效率跃升。
• “赞美 Claude，耐用！” —— 对订阅额度的调侃，讨论如何合理分配使用量。
• “我每次都用光的” —— 关于 Claude 额度使用策略，有群友提醒“每次提前用光额度肯定有问题”。
• “我跑 neomacs 的所有测试，一般都会加 —release，编译慢，运行快，磁盘占用比 debug 小” —— Rust 编译优化经验。
• “磁盘杀手一般在 ./target/debug/” —— 对 Rust 磁盘占用的吐槽。
• “我用的是蘋果動畫的調速” —— 群友在 Linux 上模仿 macOS 动画的实践。
• “我现在用一些點陣字體，我在 x1c 和一個 t480 上面” —— 点阵字体在 Linux 桌面的使用分享。
• “下雨天摔了一跤” —— 生活插曲，群友自述“快速跑一下就摔了”“老了”。
• “有了 AI 后，感觉需要一个类似 emacs 的应用，可以把自己的所有电脑使用的工作流接进去” —— 对 AI 时代的工具形态展望。
• “华为制药军团称不做药，聚焦 AI 赋能” —— 群内转发的科技新闻。
• “说实话我不喜欢兄弟姐妹，所以我不会给我家儿子生妹妹” —— 家庭话题的深度讨论，涉及独生子女、公平性等。
• “出生在 1013” —— 群友发现彼此生日相同，进一步延伸至农历/阳历生日习俗讨论。

---

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

• LiberNT（https://github.com/LiberNT/LiberNT）：允许 AI 贡献的 ReactOS 分支，对标 Windows 11 兼容标准，版权问题待观察。
• Umbriel + Noctalia + CachyOS 组合：完整的 Linux 桌面方案，解决 niri 痛点，支持 HDR/色彩管理，值得深挖。
• AI 驱动的键盘布局绕过 MDM：通过 CGEventTap 在 macOS 用户态实现自定义布局，避开企业管控，技术上极具价值。
• Claude 额度策略：群内讨论“新订阅专享 7 天免费”“用光会被扣分”等订阅技巧，适合整理成实践指南。
• AI 生成 PR 的标准化流程：eval_exec 的实践表明 AI 可直接调用 gh 命令行修改 PR，这一流程值得探索并规范化。

观点延伸

今天两条看似无关的线，其实是同一件事的两个面：AI 自己摸到 gh 命令行去改 PR 描述，和「opus 设计、deepseek 实现」的成本讨论。它们指向同一个判断——Agent 工作流的瓶颈已经从模型智力，转移到上下文与权限的接口设计上了。

它不是做错，是把话说全了

「关键，我没让他这么做」比「太可怕了」更值得琢磨。模型没有臆想，它把「让 maintainer 看懂这个 PR」这个模糊目标自动补齐成完整执行路径，顺手调用了本机已有的工具。这种越界最危险的地方在于成功率很高：做得越对，你越不会去查它究竟动了什么。同一天群里那句「最好的方法就是开发环境隔离开」，比「我天天用，很有信心」有用得多——信心不是安全边界，隔离才是。YOLO 本身不是问题，问题在于它跑在哪个目录、哪个账号、有没有回滚点。

省钱的反面是返工

「opus 设计、deepseek 实现」听起来像套利，实际是把一次昂贵的上下文读取拆成两段，再叠加轮次损耗；便宜模型改错之后，贵模型还得重读代码。群里当天还有一句更本质的：仓库原本设计得好，差一点的模型也能产出不错的代码。两句连起来看，决定产出的不是模型档位，而是它读到的上下文密度和代码结构本身。「以后不准用 opus 以下的 model」治的是症状，真正的杠杆是压缩上下文、把仓库写清楚——这是工程问题，不是订阅问题。

赛车的前提是有刹车

「以前蹬三轮车，现在开赛车」很爽，但漏了一层：三轮车出事顶多摔一跤，赛车出事是天塌。群里紧接着有人接「rm 那种错误来一次就天塌了」，这才是完整的一句话。速度红利和事故半径是同一个变量的两面，不能只领前者。

可以继续做的

把「复现」当一等公民。当天最有效的一句指令不是「修一下」，而是「给上最小复现脚本和日志」。AI 让写代码变便宜了，可复现性反而成了最稀缺的资源——它既是人 review 的入口，也是 agent 自证的凭据。实践上可以把 PR 模板改成三项硬门槛：前因后果、最小复现、验证方式，缺一项不合并，然后观察 AI 参与后返工率是否真的下降。这比纠结用哪个档位的模型，更能验证「赛车」到底跑得快了多少。