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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】Emacs 与 AI Agent 的深度融合

群内最核心的讨论围绕“如何让 AI Agent 高效操控 Emacs”展开，从 emacsclient 接口到 superchat 项目落地，形成了一条完整的思路脉络：

• geekinney 提出：通过 emacsclient 这个稳定接口，Agent（如 codex）可以实时操控 GUI Emacs 查看渲染效果（他在开发 etaf 时已验证此原理）。进一步推论：无需额外终端，直接在 Emacs 内连接 Agent，将常用操作固化为技能，通过自然语言调用，实现“M-x 之外的自然语言命令调用”。Agent 仅负责意图理解，本地模型即可胜任。
• yibiechen 回应其 superchat 项目正是此思路的实践：内置 apropos 工具发现并组合 Emacs 命令，通过 llm.el 连接模型（支持本地模型），实现“在 Emacs 里用 LLM 调用 Emacs 自己”的自举闭环。当前仍在 debug 阶段，并计划模仿 Pi 的 OAuth 方式支持订阅套餐登录。
• geekinney 提议为 superchat 建立 skill 工作流仓库，鼓励社区贡献自己的工作流技能，yibiechen 表示认同。
• 讨论还触及底层问题：“这个问题涉及到根上了，我想应该去 emacs-devel 上讨论”。

【专题】Emacs 生态的杂谈与性能吐槽

• codex-ide 性能问题：roife 吐槽渲染卡顿，yibiechen 直言是 Emacs 渲染性能太弱，roife 尝试让 codex 自己优化代码，已获得若干项 10-100x 的提升。
• Lisp 的 AI 幻觉：有人感叹“什么时候 lisp 才可以大火”，但被反驳“AI 写 Lisp 幻觉太严重”，且 Elisp 被评价为“混乱邪恶”不宜大火。
• Windows 用户福音：zmn 分享了自己的 Windows Emacs IME 状态通知 patch（附 emacs-china 帖子与详解文章），解决 Windows 上输入法状态更新通知问题，获得“Windows 领域大神”的赞誉。

🔑 关键概念与技术解析

• emacsclient 作为 Agent 的稳定技能：利用 emacsclient 作为稳定的外部接口，让 AI Agent 以自然语言操控 GUI Emacs，实现实时渲染查看和命令组合。
• superchat 的自举机制：在 Emacs 内使用 LLM 调用 Emacs 自身，通过 apropos 工具发现命令，llm.el 连接模型，形成一个完整的“自然语言命令调用”闭环。
• markdown-ts-appear：基于 treesit 的 Emacs 包，在 markdown-ts-mode 中实现类似 org-appear 的渲染效果，支持实时数学公式预览，对嵌套结构等边界情况处理较好。
• ACP 协议：roife 吐槽“acp 太拉了”，指 Agent 通信协议（Agent Communication Protocol）性能不佳，开个会话需要好几秒。
• agent-shell：相对表现不错的 Agent 与 shell 交互工具，但受限于底层协议。
• Emacs-discourse：Emacs 内的 Discourse 论坛客户端，支持查看评论和写回复，但 markup 支持尚未完善。

💎 碎片知识与金句拾遗

• “给 emacs 写 patch 是极其耗费时间的一件事情，我想群友们只是没有精力去写”——zmn 在分享 Windows IME patch 后的感叹。
• “我只是恰好有时间给自由软件贡献一点我的知识”——zmn 对贡献 patch 的谦逊回应。
• “回到 kitty，啊，一切是如此清爽”——从 warp 终端回归 kitty 的感受，吐槽 warp“唯一的好处就是会自动帮你写命令”，且“加了 AI 之后就变得显示累赘，不小心还会误按”。
• “要登录来同步的东西能有几个好东西”——对需要登录同步的工具的讽刺。
• “阿里云主机现在也是这个样子，设计的很诡异，有的时候中文被识别为是提示词，有的时候又不行被认为是命令。”——对阿里云主机 AI 功能的吐槽，被评价为“一股草台味”。
• “苹果太恶心了，怎么一次性把 spotlight, 查病毒之类的关掉”——对 macOS 系统工具的抱怨。
• “gimp 的起源就是不满 ps”——对开源替代工具的调侃。
• “我几年前开发过 adobe 的插件，adobe 家的 sdk 特别差，给我的印象特别糟糕”——对 Adobe SDK 的差评。
• “我就为了跑 darktable 买了个 4070S”——对 darktable 的硬件需求吐槽，并讨论其 HDR 支持尚不完善。
• “vibe 一个 Adobe 全家桶出来”——用 vibe coding 调侃式地解决 Adobe 软件需求。

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

• superchat 项目：yibiechen 的 Emacs + LLM 自举交互方案，值得持续关注其进展和 skill 仓库的建立。
• markdown-ts-appear：基于 treesit 的 markdown 渲染增强包，可关注其与 org-appear 的对比及边界情况处理。
• Windows Emacs IME patch：zmn 的 patch 解决了 Windows 上输入法状态更新通知问题，对 Windows 用户意义重大。
• codex 自我优化：roife 让 codex 自己优化代码获得 10-100x 提升，此思路值得借鉴。
• emacs-discourse 的 markup 支持：目前只支持回复，markup 尚未实现，有待完善。

观点延伸

中心判断：当天真正有价值的讨论，不是“Emacs 也要接入 AI”，而是把 AI 从一个抢界面的聊天产品，降级成一个可验证、可组合、可替换的意图编译层。Emacs 已经有命令系统、buffer、mode、hook、apropos、emacsclient 这些稳定接口；AI 的位置不该是再造一个入口，而是把自然语言翻译成这些接口上的可审计操作。

1. 好的 Agent 集成，不是把 AI 塞进 UI，而是接上宿主系统的神经末梢

群里从 emacsclient 到 superchat 的讨论，关键点在于：Agent 能不能“看见并操控”真实 Emacs，而不是只在旁边给建议。emacsclient 让外部 Agent 操作 GUI Emacs、观察渲染结果；apropos 让模型发现命令；llm.el 让 Emacs 内部接模型。这三件事拼起来，其实是在做一种自举：Emacs 用自己的命令系统暴露能力，LLM 负责组合，而不是替代。

这比“做一个 AI 面板”更深。面板只增加入口，接口才增加能力。能否复用已有命令、能否回放操作、能否让用户看见中间状态，才决定这个东西是不是工程上可靠。

2. Skill 仓库的价值，不是 Prompt 分享，而是把个人工作流变成社区可复用资产

提出给 superchat 做 skill 工作流仓库，这个点值得咀嚼。Emacs 社区最强的资产一直不是某个大而全产品，而是大量可组合的小函数、小包、小配置。AI Agent 如果要融入 Emacs，也应该继承这个生态结构：技能不是神秘提示词，而应接近“命令编排说明书”。

一个好的 skill 应该说明：适用场景、调用哪些 Emacs 命令、如何确认状态、失败时怎么回滚、哪些步骤必须让用户确认。这样它才像工程资产，而不是一次性聊天记录。

3. 对 Warp、阿里云主机 AI 功能的吐槽，反过来给了判断标准

当天对 Warp 和“中文一会儿被当提示词、一会儿被当命令”的吐槽，本质是在说同一件事：AI 如果模糊了命令通道和对话通道，就会破坏工具的确定性。终端、编辑器、Shell 这些地方，最怕“系统自作聪明”。

所以 Emacs + Agent 的方向必须反过来：不要让 AI 到处浮层、抢输入、猜意图；要让它生成明确命令，经过明确边界，落到可观察 buffer 和可撤销操作里。AI 越强，接口越要笨、稳、透明。

可继续实践的方向

可以做一个最小闭环实验：选 5 个高频 Emacs 工作流，例如整理 Org、重构 Elisp、查命令、生成邮件、修 Markdown 渲染；为每个工作流写成 skill；要求每次执行都输出“将调用的命令、修改的 buffer、验证方式”。如果这个闭环在本地小模型上也能跑通，说明方向成立：自然语言不是新入口，Emacs 命令系统才是底座。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】JJ 开源项目的未来走向

群内围绕 JJ（一个现代版本控制工具）的开发生态展开了持续讨论，核心聚焦于其核心维护者可能的“商业化转型”对项目未来的影响。

• 背景：有人指出 JJ 的开发者是拿着 Google 工资做开源项目的，群内感叹“生态就是这么砸出来的”。随后有人提到开发者可能准备自研后端服务，未来重心会从 JJ 本身移开。
• 核心担忧：如果创始人开始做自己的商业产品，JJ 的“新功能开发、bug 修复”速度必然会变慢。虽然目前 JJ 仍可用，但长期维护存在不确定性。
• 应对思路：群友提出“开源项目创始人不在，就找接棒的”，并以 Linus 开发早期 .git 后交给他人维护为例，认为开源项目“只要技术好，生态就能持续”。
• 观点碰撞：有人持乐观态度，认为即使收费，那也是另一套服务，与 JJ 本身技术无关，JJ 依然可以免费使用。但更多人担心“主要精力不在 git 这边”会导致项目停滞。

【专题】AI 服务集体宕机事件

当天晚间，多个主流 AI 平台（OpenAI、Claude、Grok、Cursor）同时出现故障，群内气氛一度紧张，大家纷纷猜测原因。

• 现象：ChatGPT 官方客户端出现 404 Not Found（指向 backend-api/codex/responses），Codex 同步崩溃，Claude 也报告异常。有群友反馈“一个会话崩了，另一个正常”，属于“选择性故障”。
• 猜测：有人怀疑是 Cloudflare 层面被攻击，有人猜测是“有预谋的攻击”，甚至有人调侃“fable5.1 通过 0day 漏洞攻击了 OpenAI”。但随后群友验证“我的博客还能访问”，说明 Cloudflare 整体服务未受影响。
• 结果：故障持续约半小时后恢复，群友调侃“提前过周末”。有人感叹“这要是一去不回，从此 AI 时刻结束，人们还能回到刀耕火种的古法编程吗”——引发共鸣。

【专题】Helix + Steel 事件系统的设计争议

群友 ylagr 深入体验了 Helix 编辑器的 Steel 分支（steel-event-system），对集成设计提出了质疑，并主动与作者沟通。

• 核心问题：export function 默认导出为 command，会污染原有的命令空间。作者没有像 Emacs 那样区分“导出函数”和“interactive command”，导致设计上显得“奇怪”。
• 技术背景：该分支由 Steel 语言作者开发，功能更新活跃但 PR 一直未合并，功能推进主要靠作者的个人分支。
• 解决尝试：ylagr 已在 GitHub 上提交 issue（#60），与作者进行直接沟通。

---

🔑 关键概念与技术解析

• Jujutsu（jj）：一种现代版本控制系统，旨在简化 Git 的复杂操作，支持自动分支管理和更友好的历史改写。群内讨论集中在其生态维护和未来走向。
• Helix + Steel Event System：Helix 是一款现代终端文本编辑器，主打“无模式”编辑。Steel 是 Racket 方言，作者尝试用其实现事件系统，但当前集成方式存在设计问题，即导出函数与命令未做区分，容易污染命令空间。
• monorepo（单体仓库）：一种将多个相关项目集中在一个仓库中管理的版本控制策略，便于跨项目原子性提交和依赖管理。群友因开发 12 个 Emacs 包而考虑采用此方案。
• AI Passport（ai-passport.folotoy.cn）：一个群友分享的趣味工具，推测与 AI 身份认证或模型能力展示相关，具体细节未展开。

---

💎 碎片知识与金句拾遗

• “生态就是这么砸出来的”——感慨大厂用真金白银养开源生态的现实。
• “Google 员工可以给开源项目捐钱”——透露 Google 内部对开源支持的某种机制。
• “英国历史上最失败的避税者，一不小心拯救了整个国家的农业”——转发的长文讲述了 Clarkson 的农场从避税失败到意外推动农业政策变革的故事。核心细节：买地避税→亲自种地（亏损144英镑）→开农场小卖铺→逼改规划法（“克拉克森条款”）→面对牛结核病强制扑杀→推动政府提高遗产税免税门槛（100万→250万，夫妻500万）。评价：“追了5年的综艺，没想到背后的社会意义…”
• “充 Token 如同充话费！天猫上线 AI 充值中心，阿里云、智谱、Kimi 都来了”——AI 服务消费正在向“话费充值”模式演化，渠道化趋势明显。
• “CLAUDE.md 没有用的，薛定谔的有用。你需要直接在 .claude/settings.json 里直接设置，加 hook”——分享 Claude 配置的实操经验，强调直接修改配置比文档更可靠。
• “我很早放弃 org gtd 了，我现在用 google calendar gtd 我都烦”——对 GTD 工具流变的吐槽。
• “手动挡，听起来已经过去了一个世纪…转速到了完美换挡的那一下让我很爽，就像是在操作一台精密的仪器，人有着完全的掌控感”——手动挡驾驶的怀旧与乐趣，群友共鸣“自动挡就完全是为了赶路，没了开车的乐趣”。
• “我病了，什么都做不了…我甚至有时候希望我得的是大病，这样可以住医院，有人来照顾我”——分享病中状态，流露出对“被照顾”的渴望，群友暖心安慰“都会过去的”。
• “最近几天都没人反馈 bug 了，让我怀疑都没人用我开发的 app，虽然测试里面显示 30 多个人”——开发者对“用户沉默”的焦虑，反衬出开源社区“无人问津”的孤独感。
• “Git 和 JJ 的差异？Rust 用的是 josh-project/josh，但我日常用的是 jj”——提及 Git 生态中的镜像/协作工具。
• “智谱情商确实不太行”——对国产大模型能力的调侃。

---

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

• Helix Steel 分支（mattwparas/helix 的 steel-event-system）：作者持续推进功能，但设计上区分“导出函数”与“command”的方式值得关注。可跟踪其后续设计决策，对比 Emacs 的 interactive 机制，探讨编辑器命令系统的更好抽象。
• AI 服务“充值中心”化（天猫 AI 充值中心）：AI 服务正在向“话费充值”模式演化，渠道化趋势明显。可关注其后续设计决策，对比 Emacs 的 interactive 机制，探讨编辑器命令系统的更好抽象。
• Emacs 包管理 → monorepo：群友开发了 12 个 Emacs 包，遇到“版本控制”与“接口修改”痛点，打算迁移到 monorepo 模式。可借鉴 pnpm workspace 思想，共享依赖和测试，实现“相关修改在一个提交里”。
• 本地视频生成（minimax h3 推理优化）：群友提到“最近全是针对 minimax h3 的推理优化，本地视频生成会落地的很快，agent with video 应该也会有新的形态”——值得跟进视频生成模型在本地部署的进展，以及其对 Agent 交互形态的影响。

观点延伸

今天最值得咀嚼的不是“JJ 会不会收费”或“AI 服务是不是被打了”，而是一个更工程化的判断：一套工具真正进入日常生产流之后，最危险的依赖不是代码不可用，而是“维护权、命令边界、故障恢复”没有被制度化。群里从 JJ 创始人精力可能转移、Helix Steel 的 command 污染，到 Codex/Claude 晚间同时异常，其实都在说同一件事：工具的爽感来得快，可信赖性建立得慢。

1. 开源项目的风险不在“收费”，而在维护重心漂移

JJ 讨论里有个分歧很典型：乐观者说“收费也是另一套服务，JJ 本身还可以用”；担心者说“主要精力转去自研后端，新功能和 bug 修复必然变慢”。后者更接近工程现实。

开源项目的可用性不是仓库还在、二进制还能跑，而是关键决策、回归修复、生态接口还能持续推进。Linus 把早期 .git 交出去能成立，是因为后来形成了维护结构、审查流程和明确的项目边界。没有接棒机制时，“创始人不在就找接棒的”更像愿望，不是保证。

可验证的判断标准很简单：看 release 节奏、关键 issue 响应、核心 PR 合并、扩展生态是否出现第二梯队维护者。否则技术再好，也只是“当前好用”，不能自然推出“长期可依赖”。

2. Emacs 的 interactive 不是老派包袱，而是命令系统的安全阀

Helix Steel 那段争议很有价值：export function 默认变成 command，并污染原有命令空间。这个问题看似只是编辑器插件设计，实质是“程序接口”和“用户操作入口”混在了一起。

Emacs 的 interactive 机制恰好说明老系统为什么耐用：函数可以是内部 API，可以是库函数，也可以显式声明为用户命令。这个边界让扩展作者知道什么会暴露给用户、什么会进入命令空间、什么需要稳定交互契约。AI Agent 时代这个边界更重要，因为 Agent 会调用命令、组合命令、批量执行命令；如果所有导出函数都默认可执行，命令空间就会从“操作界面”退化成“泄漏出来的实现细节”。

所以判断一个编辑器扩展系统是否成熟，不只看语言好不好写、事件系统炫不炫，而要看它是否能区分 API、command、hook、event、capability。边界越清楚，自动化越安全。

可继续研究/实践

可以把当天几个线索合成一个小实验：为自己的 Emacs 包或 Agent 工具链列一张“依赖信任表”，逐项标出维护者风险、命令边界、故障降级方案。比如 monorepo 解决的是跨包接口一致性；interactive 解决的是命令暴露边界；AI 服务宕机提醒的是外部能力必须有降级路径。真正的工程化，不是找到最爽的工具，而是知道它什么时候会失效，以及失效时系统还能剩下什么。