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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：AI 编程 Agent 的军备竞赛——从 Codex 到 Pi/dsh 的迁移潮

群内最近讨论最热烈的是围绕 AI 编程 Agent 工具链的切换与优化。多位群友从 Codex IDE 迁移到了 Pi（一个可扩展的本地 agent harness）或 dsh（deepseek shell），理由是“快、便宜（省 token）”。Pi 因其“扩展性非常强，本地可以直接创建各种插件和扩展而不需要改 Pi 的源码”而被比作 Emacs 式的可扩展平台。大家普遍认为 Codex 在某些场景下“过于辣鸡”，而 dsh 配合官方 flash 模型效果很好。

痛点集中在 token 消耗与思考链长度：有群友抱怨“deepseek flash v4.1 我的阅读速度已经跟不上它的生成速度，瞬间把我拉爆”，也有“这么多思考过程我都是直接忽略的”，并指出 Pi + 廉价 flash 模型（如 GLM 5.3 flash、DS 4.1 flash）的组合在速度与成本上远超 Codex。群友 vritser 强调 dsh 的缺点/优点是“非常喜欢读整个项目，导致输入 token 极大”，但配合 dsh-emacs 使用“丝滑”。

另一部分人则尝试自制 编排器（orchestrator）来管理多模型协作（如 astra 负责计划、luna 执行），但一位群友坦言“现有的编排器都不是我想要的”，想要一个包含“任务派发、记忆清洗和索引”的中间件，却因“记忆需要清洗”等复杂性而“没能力继续做”。这反映出当前 AI agent 工具链仍处于早期探索阶段，缺乏标准化。

专题二：AI 时代下程序员的自我定位与职业焦虑

围绕“AI 写代码”的讨论延伸到职业发展。有人自嘲“我是一个 vibe coding 工程师我的编程语言是自然语言”，也有人感叹“一晚上的进度抵我过去几天了”。但大家普遍认同“现在稍微复杂一点的项目还是很需要人类来进行监管以防止跑偏的”，而人类最大的优势被总结为“可以坐牢”——即为 AI 的错误承担责任、定位 bug、进行 review。

群友 κόσμος 抛出观点：AI 时代第一个斩杀的就是上一代强调开发者体验的动态语言（如 JS、Python），因为 AI 需要“明确的负反馈”和“拿约束来换正确性”，而动态类型缺乏约束。然而也有反驳称“那个跟训练数据有关系，跟动态没关系”“训练集大就可以硬怼”。关于 AI 是否会导致程序员失业，有人觉得“程序员应该还能干两三年的活”，有人则认为“连数学家都没活路”，但数学证明验证“比程序简单”，因为“数学证明一般更在乎证明的真伪，而计算机程序还在乎计算性质（计算性能、安全性等等）”。

---

🔑 关键概念与技术解析

• Pi：一个本地运行的 AI agent harness，强调可扩展性，用户可创建插件而不改源码，被比作“Emacs 式的框架”。支持多种模型（如 GLM 5.3 flash、DS 4.1 flash），适合做 subagent 或 leaf 节点。
• dsh (deepseek shell)：类似 Pi 的 agent 工具，但针对 deepseek 模型优化。群友反馈其“非常喜欢读整个项目”，导致输入 token 极大，但配合 dsh-emacs 使用流畅。
• agent-shell (acp)：Emacs 中的 AI 编程插件，支持 acp 协议。群友反馈它在跑任务时“emacs 整个软件都卡卡的”，体验不如 dsh 或 Pi。
• JMAP：现代邮件/日历/联系人同步协议，比 IMAP 更现代。群友 chidu.el 是一个 JMAP native 的 Emacs 邮件客户端。
• org-timgrid / org-other-agenda：两个 Org-mode 日历增强方案。前者“完全使用 svg 实现，支持直接拖拽操作”，后者是 org-agenda 的主题，提供多个 view 让日历显示更丰富。
• leaf / setup / use-package：Emacs 配置 DSL。讨论回顾了历史：use-package 更早但一直未加入 Emacs，后来 leaf 先请求加入 core，却在讨论期间 use-package 抢先入了。有人评价“setup 更优雅”，但 use-package 进入 core 可能是“因为作者是 john wiegley”。
• Sublime Merge：Sublime Text 作者开发的跨平台 Git GUI，群友推荐用它替代 magit，售价 99 刀，无弹窗。
• Racket boot file：Racket 运行时由三个 boot 文件组成，distribute 时会合并成一个 shared library，导致分发体积高达 50MB（hello world 也要带 runtime）。对比之下，Chez Scheme 的 boot 文件只有 3-4MB，内存占用约 40MB。

---

💎 碎片知识与金句拾遗

• “我是一个 vibe coding 工程师我的编程语言是自然语言”——群友自嘲，反映了 AI 辅助编程下“自然语言编程”的流行。
• “人类最大的优势其实是可以坐牢。AI不能帮你坐牢”——指人类需要为 AI 的错误承担后果、定位 bug、review 代码，这是 AI 无法替代的。
• “ai写的代码不能细看”“细看发现就是屎山”——群友吐槽 AI 生成代码的隐蔽质量问题。
• “现在稍微复杂一点的项目还是很需要人类来进行监管以防止跑偏的，openclaw 我觉得其实也算人类在想方向和对策，只是说交给 ai 的比例大很多”——对 AI 自主性的冷静思考。
• “AI 用来做事情体验提升最大的是：1. 配环境 2. 找 bug 3. 写面条代码”——总结 AI 最实用的场景，尤其是“一次性脚本”和“重构”（如“给我把 org-html-link 这个又臭又长的函数拆开成十几个了”）。
• “现在两家公司的重点也不在代码上了，放到了办公和数学上”——对 OpenAI/DeepSeek 等公司战略方向的观察。
• “deepseek不给套餐纯api的”——指出 DeepSeek 的定价策略。
• “我现在用 20x gpt 才是便宜的吧”——讨论 token 套餐成本。
• “别用 ocg，过于辣鸡”——对某个工具的锐评（可能指 OpenCode 的某个配置）。
• “我经常 fork session”——提到 session 分叉工作流，类似 undo tree，是 AI 编程中的重要技巧。
• “flex 模型只适合单纯作为 subagent”——对 flash 类模型的定位总结。
• “现代语言的工具链简直是灾难”——群友对 JS/Python/Ruby 等生态的抱怨，特别是在容器部署时“一大堆 npm 的东西，巨大无比，里面甚至还有 tests”。
• “setup 更优雅，但是 :keyword local macro 确实直观上看太诡异了”——对 Emacs 配置 DSL 的审美分歧。
• “数学证明验证我觉得比程序简单”——因为数学只关注真伪，而程序还要考虑性能、安全性等性质。

---

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

• Pi + dsh-emacs 的组合实践：群友 vritser 推荐 dsh 搭配 dsh-emacs（GitHub: MarchLiu/dsh-emacs），并强调“目前使用下来没有必须的，啥也不需要，就直接开用”。值得测试它在 Emacs 中的流畅度与 token 消耗。
• 自制 AI 编排器：有群友提到“我想要的是一个中间件，包含了任务派发、记忆清洗和索引之类的，上下游是并发的”，虽然目前无成熟方案，但这是一个极具潜力的方向，尤其是在 token 管理方面。
• org-timgrid（SVG 日历）：基于 SVG 的 Org-mode 日历实现，支持拖拽，被评价为“有潜力”，但存在文本复制问题。适合探索 Org-mode 与现代交互的边界。
• Racket 运行时裁剪：群友提到想“裁剪 racket boot file 体积”，对比 Chez 的 3-4MB，Racket 的 50MB 有明显优化空间。这是运行时精简的前沿课题，可参考 Graal 和 Java module 的裁剪方案。
• JMAP 邮件客户端（chidu.el）：群友正在开发 JMAP native 的 Emacs 客户端，并计划扩展至日历和联系人。JMAP 相比 IMAP 更现代，值得关注其与 Org-mode 的集成潜力。

观点延伸

今天最值得追问的，不是哪款 Agent 更快，而是：生成速度上去以后，谁负责让错误更快暴露？ 从“编排后消耗反而上涨”到“拿约束换正确性”，两场讨论其实碰到了同一个瓶颈：代码越来越便宜，可验证的交付没有自动变便宜。

1. 编排器首先是信息工程，不是模型调度

群友尝试上游规划、下游执行，却发现两边消耗都涨了。这不足以证明多 Agent 无用，但足以戳破“拆给便宜模型就能省钱”的直觉：任务交接需要重述背景，执行结果需要上游重新理解，拆得越碎，协调成本可能越高。

“记忆清洗和索引”因此不是附加功能，而是在回答：哪些信息值得再次进入上下文？但记忆也不是越精简越好。把一次猜测压缩成长期事实，可能比重复读代码更贵。对个人知识系统也是如此：值得保留的不是结论本身，而是结论的来源、适用条件和失效依据。 工程上应优先沉淀可定位的代码事实、已验证的决策和失败案例，而非整段思考记录。

2. 动态语言未必输，模糊反馈一定吃亏

“AI 会斩杀动态语言”说得太满；“训练数据多就能硬怼”也混淆了两件事：模型容易写出代码，不等于系统容易发现错误。

静态类型的价值，是把一部分错误变成及时、可定位的反馈；它不能保证需求理解正确，也不能包办性能、安全和兼容性。反过来，Emacs Lisp 没有因此失去工程抓手：字节编译警告、ERT 测试、明确的数据边界，都能缩短纠错回路。

群里把 org-html-link 拆成多个函数的例子，恰好适合检验这个区别：函数变短是结构变化，导出行为不变才是重构成立的证据。让模型修改实现，再让它按新实现补测试，容易得到一套共同误解需求的代码。 应先固定关键输入与预期输出，再允许它动刀。

可继续实践：测“验收成本”，别只测生成速度

挑一个有明确行为边界的 Emacs 小任务，固定起始代码、验收用例与执行预算，对比单 Agent 和规划—执行分工。记录总耗时、总费用、人工审查时间，以及独立回归测试发现的缺陷。

若分工只让生成更快，却增加审查和返工，就没有证明它更高效。真正值得留下的工作流，不是能同时指挥更多模型，而是能用更少的人类注意力，交付同样可信的结果。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI Coding Agent 生态大乱斗

群内围绕多个 AI 编码工具（AMP、OMP、Pi、Prime-Agent、Hermess、Fable、Bub、Tape、DSH、Grok、Codex 等）展开了激烈的讨论，核心痛点在于工具选择、自学习能力、无头运行、BYOK 支持。

• AMP（ampcode.com）：被提及为“比较优雅”的 coding agent，支持 BYOK 方式调用模型，但免费用户不开放自定义 base-url，本质仍要经过其服务器。有人评价其解决问题能力强，有忠实用户，博主甚至曾想订阅 200 美元套餐。
• Prime-Agent：0.90 大改版后 /goal 功能改善明显，但 TUI 卡顿问题严重，Windows WSL 下无法使用，曾被吐槽“爆掉 VPS 内存”。有用户认为其 TS 扩展和 skill 与 Pi 差异大，自学习功能“没触发过”或“没测试过”。
• Fable：曾因额度用完后退款等待问题，被迫转向无头模式。
• Bub：被定位为“building block”，非竞争指标，而是让大家构建自己的 Bub。明哥哥（明哥）跑了一个前沿 harness 测评，据称是目前唯一跑了该测评的 Python Harness，结果不错。
• DSH：被提及支持自学习，能自己发现问题（如变量表达错误），但处理 elisp 时出现低级错误。
• Grok / Grok Build：有用户觉得 Grok 不好用，边用边让 AI 看代码修复改进；也有用户用 Grok Build 接 API/反代，而非官方 coding plan。
• Codex（xodex）：被认为是“最强的，和 Claude 坐一桌”。

核心观点：不同模型能力各异，组合使用是趋势；TUI 工具卡顿是普遍痛点；无头运行成为刚需；免费额度（如 OpenRouter free）被广泛尝试用于测试。

专题二：Emacs 生态的 Git 集成与性能调优

围绕 Magit 的 diff/merge 体验、性能开销，以及 Ediff vs Smerge-mode 的选择展开了深入讨论。

• Magit 性能痛点：启动时调用大量 git 进程（优化后 26 次，未优化 50+），在 Windows 上尤为严重，甚至导致白屏。有人提到 C-g 可以中断，但白屏后只能 pkill -s SIGUSR2 emacs。
• Ediff vs Smerge-mode：多数人认为 Ediff 的三向合并（3-way merge）体验不佳，更喜欢 Smerge-mode 在当前 buffer 内用 + - 号显示 diff 的风格。
• 未来方向：有用户提到想给“majutsu”新设计一套 diff 方案；也有用户想用 libgit2 或 gitoxide 替代进程调用，但 libgit2 追不上官方进度。有人提出 VSCode 等 IDE 使用专门库集成 git，避免进程创建开销。
• Emacs Daemon：有人对 daemon 启动速度失望，但其他用户解释 daemon 是预加载，关键在于后续 client 连接速度。

专题三：Windows 包管理与开发环境

从 scoop 与 winget、chocolatey 的对比展开，最终聚焦于 Windows 开发环境的核心痛点。

• Scoop 的优势：不污染 Program Files（默认在 C 盘），被赞为“比 chocolatey 和 winget 强”，但被指“不是包管理，只是个软件源”，真正的包管理需要 msys 的 pacman 等。
• Windows 进程管理：讨论了 pkill、pgrep、killall -USR2 在 Windows/MSYS/WSL 下的兼容性问题，结论是 Windows 下很难管理原生进程，建议用 LLM 解决（玩笑）。
• 其他：有用户提到微软在移植 uutils coreutils 到 Windows，但仅用于 WSL；还有用户对 Windows 上的 Emacs 体验有阴影，认为不如 Linux 流畅。

🔑 关键概念与技术解析

• BYOK（Bring Your Own Key）：用户自带模型 API Key 进行调用，AMP 最近支持此方式，且“最近不额外收手续费”，但免费用户仍不能自定义 base-url。
• 无头模式（Headless）：指不依赖 TUI/GUI 的 agent 运行方式，适合长时间任务（如 Fable 额度用完等待退款时）。
• Computer Use：模型通过自实现的 opencv 系统获取窗口内容 + xdotool 操作，直接控制游戏/桌面，而非 MCP 协议。群内有单位模型用它玩 Luanti。
• Harness 测评（Frontier Harness Eval）：由 runta 推出的前沿 AI 编码能力测评框架，Bub 是目前唯一跑了该测评的 Python Harness。
• River：非单体 Wayland compositor，将 compositor 与 window manager 分离，用户可选用实现 river-window-management-v1 协议的 WM。相比之下 dwm 仅 2.7k 行 C，river 是 15k 行 Zig。
• SIGUSR2：Emacs 白屏时用于恢复的 Unix 信号，可用 pkill -s SIGUSR2 emacs 发送，Windows 下需在 MSYS 环境配合使用。
• Niri + Noctalia：Wayland 合成器 + 极简浏览器的组合，内存占用极低（Niri 90M，Noctalia 105M），适合低配机器。
• Luanti（原 Minetest）：自由软件 3D 游戏引擎，社区规模可观，群友是社区 #1 subgame（Mineclonia）的开发者之一，曾 1:1 复制 Minecraft level generator（未读源码）。
• Smerge-mode：Emacs 冲突解决模式，在当前 buffer 内用 + - 号显示 diff，被群友认为比 Ediff 更自然。

💎 碎片知识与金句拾遗

• Total Commander 十年老用户：两位群友都用了 10+ 年，还有人想 vibe 一个“vibecommander”的替代品。
• 微软新鼠标指针：Windows 11 实验版 Build 26340.9354 展示重新设计的鼠标指针，更宽、更柔和、更对称，去掉尾部——群友吐槽“我早已用上”（指向 Bibata_Cursor 项目）。
• Scoop 的定位：“scoop 是一个开发者工具环境管理，虽然现在承担的更多了，但就一点，scoop 不污染 Program Files，就比 chocolatey 和 winget 强了。”
• Emacs 与 SQLite：有人分享 Lars Ingebrigtsen 的文章《emacs-movies-and-sqlite》，展示 Emacs 与 SQLite 的玩法。
• OLED 屏幕：群友发现 OLED 比 IPS 对眼睛压力大，但更好看；另有人新买 T480 IPS 屏，觉得屏幕不错但比 OLED 有差距。
• suckless 风格：“suckless 是一种更极端的风格，但有道理，有一些逻辑上的美感”，sway 虽然简单但没有这种美感。
• AI 额度焦虑：多位群友“weekly 只剩 15%”，且“下一次充值要等到 19 号”，只能靠 OpenRouter free 模型“蹬一蹬”。
• AGENTIK 玩 Minecraft：某模型在 Luanti 中解锁“Acquire Hardware”“DIAMONDS!”“The Nether”等成就，但最后被 Blaze 击杀——“RIP, Pride before a fall”。
• devspace 安装到 ChatGPT 网页端：有人把 monorepo 合并后，在网页端 ChatGPT 上安装成功。
• vibe 编程的体验：“vibe 多了可能会觉得 jj 好用吧”“自动改了文件撤回不了通常是很难受的”，核心是代码审查与自动修改的风险。

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

• Bub + Frontier Harness Eval：Bub 是首个通过 runta 前沿 harness 测评的 Python harness，值得探索其框架设计与评价体系（https://github.com/frontier-harness-eval/eval）。
• River 的非单体 Wayland 架构：River 将 compositor 与 WM 分离，作为实验性架构值得深入研究（https://isaacfreund.com/blog/river-window-management/）。
• Smerge-mode vs Ediff：Smerge-mode 的 diff 展示方式更自然，可以作为 Emacs 冲突解决工具的替代方案，值得配置试用。
• Mineclonia 的 level generator 逆向实现：在不阅读 Minecraft 源码的前提下 1:1 复制 level generator，值得研究其方法论（https://codeberg.org/mineclonia/mineclonia/pulls/3419）。
• Emacs Daemon + SIGUSR2 恢复：在 Windows/MSYS 环境下，如何优雅地处理 Emacs 白屏，值得记录 pkill -s SIGUSR2 emacs 的操作路径。

观点延伸

今天最值得连起来看的，是 Agent 的“自学习”争论，以及 Magit 的卡顿与审查体验。我的判断是：开发工具的上限不只取决于能做多少事，更取决于做错以后，人能否看懂、叫停、撤回。 自动化越强，这些能力越不能靠用户补救。

1. 自学习的证据，不是“它发现自己错了”

群里有人提到，工具折腾数小时才发现变量表达有误，处理 Elisp 仍有低级错误；也有人直言，更愿意自己推进 harness 改造。这些经历不足以证明自学习无效，却指出了一个关键区别：当场纠错是反馈，跨任务减少同类错误才是学习。

如果要把“自学习”当成工程能力，就应回答：究竟保存了什么规则？下次在什么条件下调用？能否纠正旧错误，又不破坏原来正确的行为？写下一篇反思，不等于获得了一项能力。个人知识系统也一样：笔记变多只是存储增长，面对相似问题时判断更准，才算知识生效。

因此，与其看它如何解释失败，不如给它一组未见过的同类 Elisp 测试，对照学习前后的表现。否则，所谓成长可能只是同一次对话里的临时补救。

2. Magit 的问题，先别急着用换语言回答

从多次进程调用聊到 libgit2、gitoxide，很容易得出“换成库就快了”的结论。但群里关于其他编辑器是否也调用 Git，已经出现不同判断；现有材料不足以锁定唯一瓶颈。

更值得注意的是：有人抱怨全量 diff，有人只看当前文件，还有人其实在讨论三向合并。这里既有性能问题，也有任务边界没分清的问题。 单文件比较、全仓审查、冲突解决，不该被当成同一种交互。

工程上应先拆开测量：进程启动、Git 执行、输出解析、界面渲染分别耗时多少？再决定减少调用、按需加载还是更换后端。即便最终计算时间不变，先呈现可操作的局部结果、允许取消，也可能比缩短一次完整刷新更有价值。

可继续实践：把“撤得回来”做成验收项

群里“自动改了文件撤回不了很难受”，恰好连接了这两场讨论。可以做一次小实验：让 Agent 在已有人工修改的仓库里完成一个 Elisp 修复，要求留下独立变更和测试证据；随后故意否决它，检查能否只撤回 Agent 的修改，不伤及原有工作。

同时记录审查耗时、取消是否有效、恢复是否完整。若生成越来越快，确认与恢复却越来越慢，自动化只是把成本转移给了人。下一轮工具选型，值得先比这个，再比谁的功能列表更长。