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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：手机端 Emacs 的键盘适配困境

群友围绕“在手机端使用 Emacs TUI 时，虚拟键盘与屏幕布局的冲突”展开激烈讨论。核心痛点：

• 常规虚拟键盘占用屏幕，导致 TUI 界面拥挤，甚至横屏双 Window 时触发闪退。
• 有人提出“半透明键盘”方案，覆盖在屏幕上但不遮挡内容，通过点击键盘外区域自动隐藏，并支持对特定 buffer 定制（如输入框旁弹出）。
• 也有观点认为应直接内置修饰键（如 Emacs 手机端、Termux 的做法），或寻找“带全按钮的虚拟键盘”，但受限于屏幕尺寸。
• 最终共识：半透明键盘是当前较优解，兼顾交互与可读性，且可通过选项隐藏、自动隐藏机制优化体验。

专题：AI 额度削减与模型成本讨论

群友抱怨 OpenAI/ChatGPT 额度明显缩水，对比了不同模型（gpt-6.1-sol vs glm-5.3）的成本差异：

• 公司提供的 gpt-6.1-sol 在任务负载上比 glm-5.3 便宜，但个人订阅额度“20x 跟以前的 5x 差不多”，且重置次数有限（有人已攒三次重置）。
• 讨论中提及“token 过剩”“AI 泡沫”等观点，并讽刺部分用户否认额度削减。
• 衍生出对模型替代方案的思考：语音输入（豆包输入法、小鹤双拼）可作为降本增效手段。

专题：org-latex-preview 异步渲染的合并进度

围绕新版 org-latex-preview 的异步渲染特性，群友确认：

• 新版已解决旧版渲染时卡死的问题，支持异步，但需等待 org-mode 10.0 发布才会合入 Emacs master。
• 当前 org-mode 版本为 9.8，需先到 9.9 再到 10.0，等待周期漫长。
• 有群友分享实践：将 AI 总结的书籍转为 org 格式在 Emacs 中阅读，配合新渲染体验流畅。

🔑 关键概念与技术解析

• gpt-6.1-sol / glm-5.3：群友公司提供的两款 AI 模型代号，用于对比不同任务负载的成本，gpt-6.1-sol 更便宜。
• org-latex-preview 异步渲染：新版 org-mode 的 LaTeX 预览功能，通过异步渲染避免阻塞 UI，但需 org 10.0 合并至 Emacs master 后才默认可用。
• org-mode 版本路线：从 9.8 → 9.9 → 10.0 的升级路径，10.0 才包含 org-latex-preview 新特性。
• TUI 半透明键盘：为手机端 Emacs 设计的可定制透明键盘，通过不遮挡屏幕内容来缓解空间冲突。

💎 碎片知识与金句拾遗

• “豆包输入法”被推荐为 mac 日常语音输入的解决方案，打字则配“小鹤双拼”。
• 有群友将 AI 总结的书籍转为 org 格式阅读，“感觉很爽”，体现了 AI 与 Emacs 工作流的结合。
• 广告机器人的测试环节意外贡献了金句：“豆包有我聪明吗？我至少 deepseek”——虽是玩笑，但侧面反映了群友对 AI 工具的比较心态。
• 关于 org-latex-preview 的实用建议：“自己拉 org-mode 下来，然后 Make install 到 site-lisp 就能用了”，适合想提前体验的硬核用户。

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

• 半透明键盘的实现细节：群友提到“点击键盘以外的区域默认隐藏”的交互逻辑，值得探索其在 Emacs TUI 中的具体代码实现（如基于 frame 的 overlay 或 termux 的 hack）。
• org-latex-preview 异步渲染：关注 org-mode 10.0 的发布进度，或通过源码提前测试异步渲染，并分享性能对比数据。
• AI 模型成本对比方法论：群友提及“任务负载对比”暗示有量化评估方式，可进一步调研如何用基准测试客观比较不同模型的性价比。

观点延伸

当天最值得咀嚼的，不是某个键盘样式、模型倍率或版本号，而是同一个工程判断：受限环境下，系统应优先保护“连续完成工作的能力”，而不是堆叠更多功能。手机端要保护可视区域和输入可靠性，AI 工具要保护有限额度，Org 则要保护编辑器的响应性。好设计的标准不是演示时看起来更强，而是长时间使用时少打断、可恢复、能验证。

1. 半透明键盘只是表象，真正重要的是交互状态机

群里从全按钮键盘、内置修饰键、Emacs 内 OSD 讨论到半透明键盘，分歧的核心其实是屏幕空间由谁支配。半透明只能减少遮挡；点击键盘外部自动隐藏、按 buffer 定制、在输入框旁弹出，才是在定义明确的状态：编辑时提高输入可达性，阅读或分屏时主动让出视口，切换上下文时不要求用户重新寻找控制方式。

因此，工程上应先验证状态转换，而不是继续增加按键。横屏上下 Window、键盘反复弹出与收起、光标附近内容是否被盖住、触摸事件是否误吞、异常布局是否再次触发闪退，都应成为回归用例。若“透明”仍然改变布局或拦截点击，它只是视觉修饰，并没有解决问题。

2. AI 的性价比应按“完成的工作”计算

群里关于额度缩水、重置次数和不同模型成本的争论，说明“便宜”不能只看单次 token 价格，也不能只看订阅倍率。更可验证的指标是：在同一类任务上，模型完成一次可交付结果需要多少额度，返工多少次，人工校验花多少时间，最终是否进入工作流。一个模型即使输出便宜，若需要频繁重写或无法稳定遵循格式，端到端成本仍可能更高。

语音输入和小鹤双拼的讨论也指向同一事实：降本不只靠换模型，还可以减少输入摩擦，把额度留给真正需要推理的环节。

3. 异步预览让 AI 内容进入知识系统

把 AI 总结的书转成 Org 阅读，价值不在“生成了一篇摘要”，而在于它进入了可编辑、可链接、可反复渲染的环境。org-latex-preview 异步化的意义也不只是更快，而是把渲染副作用从编辑主循环中隔离出来，让长文可以边读边改，公式失败不会拖死整个界面。

可继续研究/实践

做一组端到端基准：记录手机键盘的遮挡率、误触率和崩溃率；记录不同模型完成同类任务的额度、返工次数和人工耗时；再用同一份含公式的长 Org 文档比较同步与异步渲染的卡顿、失败恢复和资源占用。这样才能把“感觉更顺”“烧得更慢”变成可复查的工程判断。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI Coding Agent 与 Harness 之争

群内今日最核心的讨论围绕 AI coding agent 的架构演进展开，尤其聚焦于 Google 发布的 Harness2 与开源项目 JitRL 的关联性。多位群友认为二者“路子差不多”——核心都在于改进模型“积累经验”的机制，而非传统的一次性生成。讨论中浮现出两条技术路线：

1. 不修改模型权重，让模型在运行中总结经验（如 JitRL，需要专门设计会话，日常对话无法叠加使用）
2. 直接内建技能（skill0 / lifeskill），让模型自带可调用的工具集

群友对 Harness2 的评价是“思路不错，可借鉴到 superchat 上”，但一致批评其 token 消耗“简直爆炸”，对 Gemini 更是如此——一条 prompt 用掉 33% 配额是常态。另有观点认为，未来模型继续训练（而非运行时学习）可能会“降低这类 harness 的比重”。

顺带引发了对 aider 的集体怀旧：作为“第一个启动纯对话框的 coding agent”，它因坚持 CLI + 强制 git 绑定的操作方式而逐渐被边缘化，群友感叹“时代的眼泪”。

专题二：Google AI Pro 订阅的性价比争议

围绕 Gemini 配额机制的吐槽意外延伸为对 Google AI Pro（20 美元/月）整体价值的计算。有群友指出，即使不考虑 AI，附送的 5TB 网盘 + Fitbit Premium + Google Home Premium + 无广告 YouTube 四项单独订阅价已远超 20 美元，“AI 那部分是倒贴钱的”。但 Gemini 的配额设计被批评“太不人性”——5 小时额度仅占周额度的 6%，必须白天连续用光才能耗尽周额度，Reddit 对比显示 Claude Pro 的用量是 Gemini 的 7 倍。另有细节：AI Studio 有单独每日刷新配额，付费 Pro 还送 10 美元 API 额度，“杂七杂八全加起来额度直接翻 3 倍”。

---

🔑 关键概念与技术解析

• Harness2（Google）：一种 AI coding agent 框架，核心思路是让模型在运行中积累经验（类似运行时总结经验），而非静态依赖预训练知识。群友评价其 token 消耗极高，但对 Gemini 是“毁誉参半”——有人认为上了新模型后“更通人性了一点”。

• JitRL（GitHub: liushiliushi/JitRL）：与 Harness2 思路相近的开源项目，聚焦改进模型“积累经验的机制”，强调无需手工打标签，但需要专门设计会话，无法在日常对话中叠加使用。

• ETAF（Emacs 框架）：群内活跃开发者的 Emacs 增强框架，支持将 Markdown 实时渲染到 buffer（不持久化），可做 TUI 界面（如网易云音乐客户端），并通过增量更新每行实现滚动。群友评价“感觉不像是 Emacs”，并已有人认领 Windows 字体行高问题的 PR。

• skill0 / lifeskill：一种将技能直接内建到模型中的方案，与运行时总结经验（Harness2/JitRL）并列的另一条技术路线。

• 词级跳转 / 逐词时间戳：Spotify 歌词同步的细分方向，群友发现 Spotify 的接口“挺开放”（需 Premium），但日语歌词仍需从国内平台抓取，且国内平台歌词“容易加私货”。实际实现上“按比例分配时间”而非真正的词级对齐。

• 行编辑器的行高机制：Emacs 中只有包含行尾换行符时，设置的行高才能生效，这是导致滚动抖动和“不等高”的根本原因。Windows 下 Emacs 读取字体高度用的 OS/2 表，ascent/descent 值过大导致中英文字体大小不一。

---

💎 碎片知识与金句拾遗

• Gemini 配额黑话：“把 Gemini 的限额用完，既简单又困难。简单的是额度掉得快，困难的是基本得在 5 小时重置以后马上把下一个 5 小时的用完才能把周额度用完。”

• iOS 生产力悖论：“iOS 防外接键盘简直像防贼一样，外接键盘三方输入法都不让用。可以不用，但是不能不给用吧——就这 iOS 还定位为生产力工具🫠”

• 输入法骚操作：“这个 AI 建议我用词选字。比如‘膝’先打出膝盖，然后把盖删掉。” 另有群友提及 iOS 系统输入法原生支持小鹤双拼，但“不加形”。

• 终端内存玄学：有群友反馈 wezterm/ghostty 待机后内存会膨胀到 330MB+，ELYTerminal 也会轻微上升几 MB。“foot 好像占用低”。

• 开源声明：“梁圣把推理引擎和毛利都开源了”——某群友对开源项目的评价，上下文不详但充满戏谑。

• 股票对冲：“油跌了希望明天股票好起来”——技术群里难得的非技术瞬间。

• 盘古大模型传闻：“华为不是已经放弃了吗？和 ds 之间估计有协议吧，我看华为不少场景都是直接用的 ds 的大模型”“余大嘴挂帅负责大模型，大概率就是拿开源模型做调整了。”

• 包管理界面争论：“这个包管理界面也是 etaf 做的吗？”——打开就给人一种不像是 Emacs 的感觉。开发者回应：先有鸡还是先有蛋的问题。

---

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

• Google Harness2：群友评价其“思路不错”，但 token 消耗惊人。值得研究其与 JitRL 的具体实现差异，以及是否可通过“继续训练”来替代运行时经验积累。

• JitRL（GitHub: liushiliushi/JitRL）：与 Harness2 思路接近的开源项目，无需手工打标签，但会话设计受限。可深入研究其经验积累机制与 Harness2 的差异。

• ELYTerminal（GitHub: ELY-Open-Source/ELYTerminal）：新生代 terminal，群友实测发现内存泄漏问题（待机后小幅上升），适合作为终端内存管理研究的案例。

• cleanyourtv（GitHub: Gathin23/cleanyourtv）：被群友点名“这个项目不错”，未见细节，值得点开仓库一看。

• openspec.el（GitHub: Zacalot/openspec.el）：Emacs 生态的新项目，出现在 AI agent 讨论中，可能与模型交互或 spec 管理相关。

• Emacs Rime TUI（emacs-china.org 帖子）：在 iOS/终端模拟器中实现 TUI 输入法的探索，配合“端砚”可在 iOS 里打字，AI 时代终端技术“迎来了第二春”。

观点延伸

今天最值得咀嚼的，不是 Harness2、JitRL 谁更像谁，而是一个更硬的判断：AI coding agent 的竞争，正在从“模型会不会生成代码”转向“系统能不能把失败变成下一次的可靠执行”。群里提到运行时总结经验、内建 skill，以及未来继续训练模型这几条路线；它们真正的分界，不在宣传里的“自学习”，而在经验能否跨任务复用，并且确实减少重试。

1. 经验不是上下文堆积，而是可验证的反馈闭环

如果每次任务都要专门设计会话，经验就很难进入日常工作流；如果只是把旧对话重新塞回上下文，又可能带来 token 膨胀、注意力分散和错误复用。评价 harness 不能只看一次调用用了多少 token，而应看固定任务集上的总成本：完成率、重试次数、人工介入量、失败恢复时间。群里说“学会之后反而节省 token”，其实已经指出了正确指标：前期训练成本可以接受，但必须在后续任务中稳定回本。

2. skill 的价值在于约束执行，不在于增加说明书长度

无论 skill 放在模型内部还是外部 harness 中，都应该被定义成操作契约：什么条件下触发，允许调用哪些工具，怎样算完成，失败时如何回滚，何时交给人处理。否则 skill 只是更长的提示词，遇到大上下文或陌生项目仍会漂移。aider 的讨论也说明，贴近 LLM 层不等于工作流设计合理；CLI、git 绑定等约束只有在降低风险时才有价值，不能反过来让用户迁就工具。

3. Emacs 的机会是交互底座，而不是复刻 IDE 外观

ETAF 的 Markdown 渲染、视频播放、TUI 输入法和终端 agent，看似是不同组件，实际都在争取同一个位置：让文本、状态、输入和渲染保持可组合。真正的工程门槛不是“看起来不像 Emacs”，而是原始 Markdown 能否作为唯一来源、渲染结果能否随时重建、增量更新是否稳定、字体行高和输入法路径能否跨平台。AI 让终端重新变重要，但机会属于能把这些不变量做成基础设施的系统。

可继续研究/实践：用一组固定的 Emacs 任务，对比裸模型、harness 和持久 skill 的完成率、总 token、重试次数与人工修改量；同时为 ETAF/TUI 建立 Windows、macOS、Linux 的行高与滚动回归样例，避免只凭截图判断“已经可用”。