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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 底层代码维护的“恐怖”与“去文档化”

本次群组讨论的主线，是由一位开发者维护/优化 Emacs 底层 C 代码的真实体验引发的。他不止一次表达了对 Emacs 源码的“敬畏”和“恐惧”，并引发了一场关于 AI 辅助编程边界、平台分支差异以及文档价值的深度讨论。

1. Emacs 底层代码的“复杂度”痛点：发言者详细描述了 make-process、expand-file-name 等底层函数的代码状况——单个函数动辄数百行、二三十个变量，充斥着条件分支，可读性极差。这种复杂度带来的核心困境是：即便用 AI 读懂逻辑，也依然无法消除对“边缘情况”的恐惧。因为代码跑起来的行为，远比 AI 的静态理解要复杂得多。这成为了优化这些核心函数的心理门槛。

2. AI 在核心代码维护中的局限：讨论中形成共识——AI 能帮助“读”，但不能帮助“证”。对于底层优化，关键在于“改完之后如何证明没有回归问题”。这恰恰是静态分析工具和 LLM 难以解决的难题，导致开发者“一看就想吐，连用 AI 的心思都没有”。

3. 平台分支差异与文档悖论：有人提到 Windows 代码是移植的，各平台代码独立，mac port 近期停止开发，只需要从上游 merge 新版本。这引出了关于开发文档价值的讨论。有群友抛出“stallman 当年为什么不好好写文档”，另一位则给出犀利观察：“写文档用处似乎不大，xemacs 有很详细的开发文档，还是凉透了”。这反映了开源生态里，活跃的维护者与开发循环远比静态文档更重要。

🔑 关键概念与技术解析

• make-process（底层进程函数）：Emacs Lisp 中创建子进程的低级接口。讨论中提到该函数在 Windows 平台上的源码实现极其复杂，条件分支极多，是出了名的“难以阅读”和维护的痛点。
• Emacs-W32-IME-Notify：群友分享的博客文章标题，内容涉及 Emacs 在 Windows 平台上关于输入法（IME）的通知机制。属于 Windows 平台下 Emacs 的特定适配模块。
• mac port（macOS 移植版）：特指 Emacs 在 macOS 下的移植维护分支。该分支近期开发停滞，目前主要是同步上游 merge，且兼容性相对较好，没有 Windows 那边“折磨人”的维护问题。

💎 碎片知识与金句拾遗

• “AI说的和自己理解的是一回事，但代码跑起来是另一回事了。”——这句话精准地概括了 AI 编程辅助在当前底层系统开发中的“解释力”与“说服力”之间的断层。
• “维护者意识到慢的问题”——讨论起点，指出很多优化瓶颈不在于没人会写，而在于维护者是否有意愿去碰那些“烫手的代码”。
• 群友分享了个人博客 RSS 订阅（https://zdn.codeberg.page/rss.xml），以及一篇专门讲 Windows 版 Emacs 输入法通知的文章（https://zdn.codeberg.page/public/Emacs-W32-IME-Notify.html），供大家订阅和参考。
• 对 Xemacs 的观察：“xemacs 有很详细的开发文档，还是凉透了”——这被用来佐证“详细文档”并不能保证开源项目的生命力。

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

• Emacs 底层代码的“可读性重构”与“AI 辅助测试”：群内多次抱怨核心函数的“几百行条件分支”难以维护。这是一个典型的“可读性重构”场景。但难点在于，重构后如何证明行为一致。值得关注 Emacs 核心维护者是否引入了新的测试套件或差异测试工具来降低这类重构的风险。
• portal（GitHub 项目）：群友分享了 https://github.com/xiaoxinghu/portal，虽无上下文解释，但作为被硬核开发者分享的链接，很可能是一个针对终端或开发环境的新颖工具或配置方案，值得进一步研究。
• Thread 相关问题的群友解决方案：群里提到“就能群友解决 thread 相关的问题了”，暗示有群友正在开发或已经解决了 Emacs 在 Windows 平台上的 Thread 缺陷。这是一个关注 Emacs 并发模型优化的前沿线索。

观点延伸

当天最值得咀嚼的，不是“Emacs 源码难读”，而是一个更硬的问题：当系统的真实行为主要藏在边缘条件里时，理解代码并不等于拥有修改它的资格。

1. AI 的瓶颈不是读不懂，而是无法替你承担回归责任

群里说“AI 说的和自己理解的是一回事，但代码跑起来是另一回事”，这并不是对 AI 能力的笼统否定，而是在指出底层工程的评价标准已经变了。对于 make-process、expand-file-name 这类函数，真正重要的不是能否总结控制流，而是能否回答：哪些平台、参数组合、错误路径和时序条件会被这次修改影响？

因此，AI 最适合承担的是“建立地图”：解释变量、梳理分支、寻找相似实现、生成测试矩阵。它不应直接充当“正确性证明”。如果没有可重复的基准、跨平台测试和行为差异检测，AI 生成的 patch 只是更快地把未知风险变成可提交的代码。

2. 底层优化的第一产物，应该是可验证性，而不是更快的代码

面对几百行函数和二三十个变量，直接重构往往不是勇敢，而是缺少测量。更可靠的路径是先把“原来没有问题”具体化：记录输入输出、错误行为、资源释放、进程状态和性能基线，再用测试或差分工具锁住这些行为。只有这样，优化才有机会从“我觉得应该没问题”变成“在已覆盖的行为范围内没有回归”。

这也解释了为什么维护者意识到性能问题仍然不一定会动手。难点不是写出更漂亮的实现，而是为改动建立一套足够可信的证据链。底层代码越丑，测试和观测就越像安全带，而不是附属文档。

3. 文档不是项目生命力，维护循环才是

“XEmacs 有详细开发文档，还是凉透了”这个观察很尖锐，但不能推导出文档无用。它更准确地说明：文档只能降低进入门槛，不能替代持续的维护者、可运行的测试、明确的提交路径和真实用户反馈。静态知识解决“应该怎样理解”，维护循环解决“今天谁来修、修完如何证明”。

对 Emacs 这种跨平台项目而言，平台代码各自演化，文档尤其容易落后于实际行为。真正有价值的文档，应该和测试、构建配置、已知限制绑定，能够在代码变化后被验证，而不是一份孤立的历史说明。

可继续研究/实践

可以选一个相对集中的底层函数，做一次“小型行为考古”：先收集现有测试和平台分支，再建立输入—输出与性能基线，最后让 AI 只负责生成分支地图、测试用例和候选 patch。比较修改前后的行为差异，尤其关注错误路径和平台特有条件。这个实践能检验一个关键判断：AI 是否真正降低了维护成本，还是只是降低了阅读和提交的心理门槛。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Claude Code 账号风波与"订阅游击战"

群内整天围绕 Claude 账号封禁、订阅策略、替代方案展开高强度讨论。痛点是 Anthropic 对国内用户及"重置党"的严厉封控，以及 OpenAI 的缓慢与额度陷阱。 有人感叹"几个 anthropic 账号被封，没了 claude code 其他替代品用起来力不从心"，Lucius 则分享了"iOS 渠道注册 + 被封退款"的循环策略——用美区 Apple ID 订阅，封号后自动按用量退钱，他"退了三次钱没扯过皮"；还提到自己"用了将近一年的号是中国区的 apple id"。

核心方法论：

• 账号策略：优先 iOS 渠道注册，不纠结代理（用就得接受封号风险）；"用了封了就等过期了删号，然后重新用苹果 id 注册"。
• 退款经验：封号后退款自动处理，不必听信小红书上的"扯皮"传说。
• 模型体感差异：实测 GPT 只有 40 token/s，Claude 是 450 token/s；但 GPT 的 token efficiency 好 1.5-2 倍。Claude 半小时解决的问题，codex "一天都没搞定"。
• 最终结论：Lucius 发愿"用最傻逼 LLM 作出最 nb harness 然后开源，让 A 厂原地爆炸"，并吐槽 Gemini 4 Argon "是最离谱的"，"一个会话能用 15% 我感觉"。

专题二：ETAF —— 在 Emacs 里重构 Excel 的"深水炸弹"

一位群友向 nvim 群投去"深水炸弹"（Can nvim do this??????），展示 ETAF（Emacs Table Application Framework）在 Emacs 内渲染电子表格的能力。讨论从"行高列宽没问题"开始，迅速升级为对架构的探讨。

关键观点：

• 能力边界："理论上 Excel 绝大多数的功能都可以实现……我目前还想不到有哪些能力是不能实现。"（除了前端展示，还需后端配合，@yibiechen 已有基础）
• 组件库生态构想：作者提到已积累 etaf-ui 官方组件库，希望用户贡献可复用组件，并计划在 Emacs 内做一个"文本 APP"来浏览/提交组件。
• 性能实测：作者一开始就测试过 200 万个单元格的压力测试；增量载入与增量显示已实现；支持 VLOOKUP、跨表公式等"基操"。
• 测试方法论：群友提醒应"站在巨人的肩膀上"——上游（Rust 库）已测试过的功能不必重复，重点测渲染层和端到端兼容性。群友推荐了 40MB 大 Excel 测试文件（spytm.com/sample-files）。
• 商业化畅想：若 ETAF 能成为"基建"，开发者"一个月要花大几千"的 AI 订阅成本就值了；甚至有人已开始用它画 K 线图做股票盯盘界面。

专题三：家务机器人与"工业化洗衣"的价值观碰撞

一条吐槽"家务机器人"的长消息引爆讨论：认为花 100 万美元做机械臂抓苹果纯属智商税，现代生活应该是"袜子内裤直接原厂全自动化生产，一次性用完就扔"。群友随即展开生活化讨论：

• 一次性衣物成本极低（广州批发市场 20 元/斤），"成本大概一天 10 块"。
• 但"一次性的舒适度都太差了"。
• 痛点不在于"洗"而在于"洗不干净"（油斑、血渍、羽绒服发黄、羊毛衫手洗护理）。
• 有人提议"把干洗店自动化"，解决"一周太慢、价格贵"的问题；但"烘干和干洗的衣服有一股味道"。
• 最终结论倾向：现代洗衣机 + 精细分类手洗 + 低频送洗仍是主流，机器人方案"成本只有在一天洗一百次才能收回来"。

专题四：AI Agent 工具链的"主观评测"

• Tern：被称赞"极度丝滑，Agents 终端集大成应用，应该替代我的 Herdr"。插件生态强，"直接说需求加功能"，且作者深度集成自有工具 OMP。但闭源且不支持触屏，导致部分人转向 foot。
• Codex vs Claude Agent Loop：Codex 被批评"简陋、没有 monitor、SSE 代理不稳定、18 分钟才开始工作"；而 Claude 的 agent loop 设计更优（x.com 上有教程），"空闲时精简本地 memory"。
• Grok Bot 云电脑：订阅附送云电脑（8 核 16GB，128G 存储），位于美国/郑州，有人尝试在远程跑 Claude 账号，"轻量级的活"如 markdown 转 PDF、写 Rust 脚本。

---

🔑 关键概念与技术解析

• ETAF：Emacs Table Application Framework，用 Emacs 底层文本渲染 + Rust 动态模块解析 Excel，实现类 Excel 体验。增量更新、200 万单元格压力测试通过。上游用成熟 Rust 库魔改，重点在渲染层。
• Claude Reset：付费账号额度用完后，不等待自然周期，而是通过渠道商（"tibo 公子"）手动重置额度。风险极高，容易触发封号。
• KYC（Know Your Customer）：Anthropic 对新号要求身份验证；中国护照可通过，但账号不能在大陆 IP 登录。
• Token Efficiency：不同模型输出相同语义所需 token 数不同。GPT 约为 Claude 的 1.5-2 倍效率，但生成速度远慢于 Claude。
• Agent Loop：Claude Agent SDK 中的核心循环，包含"思考 → 行动 → 观察 → 记忆精简"机制，被群友认为比 Codex 的线性执行更聪明。
• SRE/Responses API 痛点：OpenAI 的 responses API 被吐槽"设计很烂"，SSE 代理不稳定导致频繁断连。
• 六边形窗口与 VR 窗口管理：讨论"窗口一定是方的吗"——屏幕是方的、密铺困难、文本阅读需要矩形；但 VR 场景下窗口概念仍需存在，适合"开一个贼大的屏幕写代码"。

---

💎 碎片知识与金句拾遗

• "模型构造出来他说我的非 home row 按得比 home row 还要快"——训练键盘模型时的反直觉发现。
• "如果不是下面的 mode-line 应该没人觉得这是 emacs"——Emacs 自定义 UI 后的"隐身"效果。
• "claude 会读你本机信息，看语言时区"——Claude Code 存在环境探测行为。
• "咸鱼现在的黑话是什么，都搜不到了"——大数据推送的另一种解法："白天聊的天，晚上就在咸鱼找到了"，怀疑手机厂商卖数据。
• "投资还是不要看自己赚不到的钱"——BTC 讨论中的清醒剂。
• "2016 年我还被勒索过 1 个比特币，当时就一万人民币了"——来自 VPS 拖库的惨痛教训。
• "据说 Anthropic 刚开始时就注册的帐号比较好"——老号体质论。
• "deepseek 这波大方啊"——DeepSeek 宕机后按 7 日消耗全额补偿赠金，群友评价"对常用用户很有诚意，损失几个亿"。
• "用vd😁"——Visidata 被推荐为 Excel 互操作神器。
• "就差一点就能做通达信了"——有人已逆向股票接口，计划在 Emacs 里做 K 线图。
• "直觉上感觉人和 harness 参与越多，对模型要求越低"——对 Agent 框架价值的本质判断。
• "还有川剧变脸"——形容 OpenAI 封号速度。
• "我真傻，真的，我单知道达里奥因为做过艳红星努力，憎恨老中人；我不知道他恨老中恨到入骨…"——鲁迅体吐槽某对冲基金大佬。

---

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

• ETAF 组件库生态：作者希望用户贡献可复用组件，计划在 Emacs 内做文本 APP 浏览/提交。未来可能成为 Emacs 生态的"杀手级应用"。
• DeepSeek 补偿策略：按 7 日消耗全额返还赠金，值得关注其"留存用户 vs 成本控制"的平衡。
• Grok Bot 云电脑：订阅附送美国 IP 云电脑，可用于跑 Claude 远程，群友正在测试，"期待群友结果"。
• Agent Loop 开源教程：x.com 上有 Claude Agent SDK 的 loop 教程，值得深入研究其 memory 精简机制。
• Tern 终端：闭源但集成 Agent 生态（OMP），可关注其插件机制与"说需求加功能"的开发模式。
• 六边形平铺窗口：讨论虽属想象，但 VR 窗口管理、"嵌套 compositor" 概念值得关注。
• VisiData (vd)：被群友力荐的终端表格工具，适合 Linux 下 Excel 互操作，可作为 ETAF 的对比参照。

---

以上。群内讨论密度极高，模型账号战争与 ETAF 生态是今日两大主轴。

观点延伸

当天最值得咀嚼的，不是哪个模型更快、哪个账号更耐用，而是一个更底层的判断：当基础模型越来越容易替换时，真正形成长期差异的，会是承载模型与工作流的“工程底座”。 ETAF 和 Agent harness 看似分属 Emacs UI、表格处理、AI 编程三个领域，实际上都在回答同一个问题：如何把一次性的能力，沉淀成可复用、可验证、可迭代的系统。

1. ETAF 的价值不在“把 Excel 搬进 Emacs”，而在于建立新的应用构造方式

群里从行高列宽、VLOOKUP、百万行数据，讨论到增量显示、跨表公式、兼容性和组件库。这说明 ETAF 的竞争力不应只用“能不能替代 Excel”衡量，而应看它能否成为一种稳定的应用基建。

“先实现后抽象”是合理路径，但到了组件库阶段，抽象必须开始接受约束：组件要有明确的数据结构、生命周期、刷新边界和测试样例，否则所谓可复用只是把个人项目里的隐式假设搬到公共仓库。尤其在 Emacs 中，渲染、交互和业务逻辑容易混在一起，短期开发很快，长期维护却会变成隐性成本。

因此，ETAF 下一步最关键的不是继续证明“还能画什么”，而是证明“别人能否在不理解内部细节的情况下稳定地使用它”。一个组件能否独立演示、替换数据源、在 TUI 或 SSH 场景下退化运行，可能比再增加一个视觉效果更能决定生态是否成立。

2. Agent 的上限，越来越取决于 loop，而不是单次回答质量

群里对 Codex 和 Claude 的差异，表面上是速度、SSE 稳定性和模型能力，实质上是工作循环不同：模型是否能及时获得反馈，是否会检查结果，是否能在空闲时整理记忆，是否有 monitor 让人知道它究竟卡在网络、工具还是推理阶段。

“人和 harness 参与越多，对模型要求越低”这句话有启发性，但不能理解为 harness 可以掩盖模型的一切不足。更准确的说法是：好的 harness 把模型从一次性答题器变成了受约束的执行组件。 它通过任务拆分、工具边界、状态记录、失败重试和结果验证，把模型的随机性压缩到可管理范围内。

这也解释了为什么一个并不占优的模型，配合更好的循环，可能在真实工程任务中胜过更强但缺少反馈机制的模型。以后评测 Agent，不应只记录首 token 延迟或单轮 benchmark，还应记录从任务接收、工具调用、失败恢复到最终交付的完整成功率与人工介入次数。

可继续研究或实践

可以为 ETAF 和 Agent harness 各做一套“端到端而非炫技式”的基准：ETAF 测真实复杂表格的加载、编辑、导出、兼容性和增量渲染；Agent 测同一代码任务在不同模型、loop 和网络条件下的完成时间、返工次数、工具失败恢复率。这样才能把“好用”“丝滑”“模型聪明”转化为可复现的工程判断。