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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】Emacs 维护者生态与项目健康度之辩

群内围绕“Emacs 项目维护者数量是否健康”展开了一场持续数小时的讨论，由某个第三方包“近五个月合并100个PR但仅两人参与”的现象引出，进而上升到对Emacs官方维护机制的剖析。

• 第三方包活跃度之困：有群友指出，某包近五个月合并100个PR，但只有两位维护者处理，且大部分PR是三个月前提交的，近期几乎无新增。这被形容为“不健康”，因为项目命运完全取决于两个人的时间空暇。
• 官方维护机制探秘：围绕“Emacs官方是否也面临同样问题”，群友κόσμος指出官方其实也只有两三个人在处理bug报告并合并patch。但群友φuzy反驳称，Emacs的commit记录里有大量不同维护者的名字，说明官方生态更健康。
• 维护者权限的本质：κόσμος澄清了maintainer与committer的区别——有commit权限的人（约两三百人）大多是“自己推自己的代码”，并不会去合并别人的patch，而真正负责合并patch的核心维护者确实凤毛麟角。他还引用etc/MAINTAINERS文件作为权威依据。
• 前群友的“LLM事件”余波：有群友提到一位前群友最近的commit均由Eli代做，猜测可能与之前某次涉及LLM的事件有关。还透露“群里只知道2个人有commit权限”，其中包括这位前群友。
• 个人争取权限的路径：有群友表达了对commit权限的渴望，计划通过修复Windows相关bug来“攒资历”。φuzy给出了实际可操作的建议：用 git log --format="%cN" | sort | uniq 查看历史提交者名单，以此了解维护者全貌。

🔑 关键概念与技术解析

• auto-save-visited-mode：Emacs内置的自动保存模式，启用后会在缓冲区切换或空闲时自动保存已访问的文件。群友吐槽“开了这个模式，过一段时间就会丢失手动保存的习惯”，因为不再需要手动C-s保存了。
• C-x z / C-s 冲突：在Evil模式下，C-x z可用于重放上次宏，但群友指出习惯性地按C-s会触发搜索而非保存。这一现象是“evil模式模仿vim行为”导致的，vim中C-s默认就是搜索，而非Emacs中的保存。
• tex-gyre-termes：一种基于Times字形的开源PostScript字体，用于LaTeX排版。群友推荐用CTAN包tex-gyre-termes来获得“Times风格”，但另一位群友吐槽“这个也太原汁原味了”，暗示字形过于复古。
• maintainer vs. committer：在开源项目中，maintainer通常指拥有合并他人patch权限的核心维护者，而committer则泛指有写入权限但主要提交自己代码的成员。Emacs官方通过etc/MAINTAINERS文件维护这一权限体系。

💎 碎片知识与金句拾遗

• “开auto-save-visited-mode，过一段时间就会丢失这个习惯” —— 群友φuzy的经典吐槽，揭示了自动化工具如何改变人类行为习惯。
• “说明功能基本稳定” —— 群友对“近三个月没有新PR”的戏谑解读，用自嘲的方式化解了对项目活跃度的担忧。
• “等我以后不愁吃穿了” —— 群友对争取commit权限的调侃，暗示维护开源项目需要经济自由作为前提。
• “windows上的bug在我看来修复起来都比较简单” —— 群友对Windows平台bug难度的主观判断，但紧接着又补了一句“不过Windows就没几个bug来着”，既自信又谦逊。
• “修一下慢的问题” —— 群友对某个问题的轻描淡写，暗示性能优化往往比功能实现更棘手。
• 群友κόσμος分享了一个X（Twitter）链接（https://fixupx.com/Elder24601/status/2110310698056302821），并感叹“草”，随后另一群友回应“真实的印象”，暗示内容与Emacs维护者或LLM事件有关。

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

• Emacs维护者权限获取路径：群友计划通过修复Windows bug来争取commit权限，这可以作为开源贡献者的参考案例。建议进一步研究Emacs的CONTRIBUTE文档和etc/MAINTAINERS文件，了解具体的贡献流程。
• xdisp.c的复杂度：群友感叹xdisp.c（Emacs的显示引擎核心文件）“也太复杂了，修问题都不知道怎么下手”。这一文件是Emacs最著名的复杂模块之一，值得深入阅读其源码以理解Emacs的渲染机制。
• 前群友的“LLM事件”：群友暗示有前群友因涉及LLM（大型语言模型）而失去直接commit权限，其后续提交需Eli代做。这暗示Emacs项目可能对AI生成代码或自动化工具引入了严格的审查机制，值得持续关注。
• 第三方包维护者瓶颈：仅两人处理100个PR的案例是开源项目“巴士因子”（bus factor）的典型表现，值得研究如何通过自动化工具或社区激励机制解决此类问题。

观点延伸

当天最值得咀嚼的，不是“Emacs到底有多少维护者”，而是一个更一般的工程判断：提交数量不等于维护能力，权限数量也不等于治理冗余。 一个项目看起来有很多人提交代码，真正决定它能否持续演化的，却是有多少人能够理解问题、评估补丁、承担合并责任，并在关键模块出故障时接得住。

1. 开源项目的“巴士因子”应按决策链计算

“近五个月合并100个PR，但主要由两人处理”之所以令人不安，不在于数字本身，而在于整个决策链可能集中在两个人身上：他们既要理解代码，又要判断补丁质量、兼容性和长期代价。即使代码贡献者很多，只要审查和合并环节高度集中，项目仍然存在单点故障。

因此，衡量社区健康度不能只看 commit 数、PR 数或贡献者总数，至少还要看：补丁由多少人审查、不同模块是否有替代维护者、长期无人处理的问题是否集中在少数人手里。对第三方包而言，维护者数量少未必立刻意味着项目不行；但如果没有明确的接替机制，稳定只是维护者尚未耗尽精力时的表象。

2. “committer”和“maintainer”的差别，本质是责任而不是头衔

群里的讨论把一个常被忽略的事实说得很清楚：能把自己的代码推上去，和能替项目接受他人的代码，是两种不同能力。前者主要证明你熟悉某部分代码，后者则要求你承担更广泛的上下文责任。

这也解释了为什么大型项目不会轻易把合并权限扩散出去。权限越多，未必越去中心化；如果真正的审查标准、模块边界和责任归属没有同步扩展，增加的只是写入入口，不是治理容量。etc/MAINTAINERS这类文件的价值，正是把“谁负责什么”从口头印象变成可查的工程地图。

3. 对 AI 辅助贡献的真正考验，是可审计性

聊天中提到某些提交可能由他人代为完成，并联想到此前的 LLM 事件。这里不宜根据片段下结论，但它触及了一个现实问题：AI 生成代码并不自动降低质量，不可追溯、不可解释、责任边界不清，才会提高维护成本。

一个适合进入核心项目的 AI 辅助补丁，至少应能说明问题来源、修改范围、测试证据和人工审查者。维护者需要审查的不是“是否使用了 AI”，而是这个补丁能否被未来的人复现、解释和继续维护。

可继续研究/实践

可以选一个具体模块，建立一张小型贡献地图：列出近一年补丁的提交者、审查者、合并者、测试方式和未决问题，再与 MAINTAINERS 对照。这样才能把“项目很活跃”或“维护者太少”转化为可验证的判断，也能为想获得权限的人提供比“多修几个 bug”更清晰的成长路径：先成为可靠的模块维护者，再逐步承担项目级审查责任。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 模型格局剧变与“重置卡”现象

群内对 OpenAI、Anthropic、Google 等大模型厂商的讨论异常激烈，尤其是对 OpenAI 的“摆烂”和 Anthropic 的“阴险”表达了强烈不满。

• OpenAI 的衰落：有群友反映 Codex 频繁报错（The 'gpt-6-astra' model is not supported when using Codex with a ChatGPT account），以及模型“速度慢，智商低”、“大重置遗忘术即将发动”。更有群友吐槽 OpenAI“不发新模型要似了”，并调侃“openai：又有新的模型比我们好了，别慌，我们为您发放重置卡”。部分用户对 OpenAI 的订阅策略不满，计划不再续费。
• Anthropic 的“阴险”与 KYC：群友吐槽 Claude 触发 KYC（了解客户）风控，且“Claude 也没退款”，“这家公司太流氓了”。还有人提到一个 V2EX 帖子，讨论 Claude 因用户表达“独立音乐”等敏感词而封号，引发了对 AI 审查机制的讨论。群友普遍认为 Anthropic 在“钓鱼执法”，但也有人认为“看评论区好像不是钓鱼执法这一回事”。
• Gemini 4 Argon 的性价比争论：Google 的 Gemini 4 Argon 成为新焦点，群友反馈“巨贵”、“输出慢的要死”，但也有观点认为“gemini 突然有了性价比？”（API 价格减半）。有消息称 Argon 已向 Gemini API / Google AI Pro & Ultra Plan 用户推送，但 Antigravity 中必须 Ultra Plan 才能用。群友对 Google 的定价策略和“自家套餐也没多少额度”表示不解。
• Azure 泄露 Claude Fable 5.5：有快讯称 Azure 泄露了 Claude Fable 5.5，预计最晚 12/5 发布，引发了对下一代 Claude 的讨论。

专题二：职场压榨、维权与“牛马”生存指南

围绕加班、病假扣薪、社保、试用期等话题，群友展开了一场深刻的职场吐槽和维权经验分享。

• 加班文化：群友普遍反映“加班申请本就是恶心人”，尤其是“钉钉要求说清楚加班原因”。有人分享“上月加了大概50个小时班，算了大概两百块钱”，也有人表示“不打卡的，所以是做不完自己无偿加班”。有群友计算“三小时扣我三百多，那就是每天七百多，工资是30，那我直接不上班了白拿剩下的钱”。
• 社保与维权：有群友指出“社保副局长真的有种不知人间疾苦的感觉”，并提及“最近这个社保政策一出，很多公司更不愿意招人了吧”。有人建议“去人社局举报，大概率会被整治”，但也有群友担心“举报了，找下份工作会有记录吗? 影响不”。有群友分享自己对象所在公司的合同是“自愿放弃”社保，并指出“没有自愿放弃的说法，你那玩意没有任何作用，一告一个准”。
• 求职与润学：有人想“弄工签润美”，但被指出“英伟达中国和英伟达美国应该不存在可以通过工作直接润的情况”。有群友分享“我们组有个哥们在德国赚中国的薪资😂”，并感叹“现在stem留学都不能留下工作了”。

专题三：童年回忆与成长环境

群友从“笨笨的妈妈和笨笨的儿子”的闲聊，转向了对童年打架、校园霸凌、传销经历的回忆，讨论了中国基层社会的治安和人际生态。

• 校园暴力：群友分享了各种童年打架经历，如“五年级管纪律我就用那个抽人”、“我初中老师没由来给我3记窝心拳，我直接打的他左手都抬不起来”、“我六年级吃饭吃不饱，菜来了我先分，分了剩下的别人才能吃”。有群友总结“按你说的我就是霸凌别人啊”。
• 社会环境：有群友感叹“小时候治安太差了”、“中国这个国家有人吹牛皮说是什么‘爱好和平’，才不是那样，爱斗争，动不动就打”。还有人提到“传销暴雷前，就是个正常公司”、“当地警察也不管的”。
• 教育理念：围绕孩子教育，有群友分享“我家只有几个底线，不借钱，不犯法，不偷不抢。其他随意”、“人品没问题就行，滑头一点反而好混”。

专题四：双拼输入法设计与个人定制

有群友分享了自己用 AI 设计双拼方案的过程，从键位布局到重码率，进行了深度探讨。

• 方案设计：群友提到“想要尝试设计自己的双拼方案”，并尝试“左声母右韵母”的布局。有人分享“用 opus 搞出来的新双拼方案”，并提到“只考虑测量的数据，其他啥都没考虑”。还有人对比了“微软双拼”、“小赫双拼”、“自然码”等方案。
• 优化目标：有人指出“整个通用方案是使用成本最低，效率最高的，整小众方案，副作用太大了”。群友表示“在尝试在类似效率的情况下让方案更易学”，并提到“比前一个慢 1.7%，但是看上去就好记很多”。还有人分享“用模拟退火跑的”、“针对特定语料跑布局优化”。
• 工具链：有人提到“用 taf 搞个打字练习的包”、“用 GPUI 写的，效果相当不错”。群友分享“用 opus 搞出来的新双拼方案”，并提到“适应一下刚才用opus搞出来的新双拼方案”。

🔑 关键概念与技术解析

• KYC (Know Your Customer)：群友多次提到“触发 kyc 了”。在 AI 服务语境下，指服务商要求用户提供身份证明、信用卡信息等以验证身份，防止滥用。群友抱怨新号用 Google Pay 付款也触发 KYC。
• Codex 错误：Error: Codex error: The 'gpt-6-astra' model is not supported when using Codex with a ChatGPT account. 指的是 OpenAI 的 Codex CLI 工具与 ChatGPT 账号不兼容，无法使用特定模型（如 gpt-6-astra）。群友多次遇到此问题。
• Claude Fable 5.5：通过 Azure 泄露的消息预测的 Anthropic 下一代模型，预计 12/5 发布。群友讨论其潜在定价和性能。
• Gemini 4 Argon：Google 最新发布的旗舰模型。群友反馈其 API 价格“减半”，但“输出慢的要死”、“只能 chat”。有消息称其已向 Pro 账号开放。
• Tibo：群友多次提到“tibo 有一个计划”、“希望不是大重置周计划”。这可能是一个 AI 模型或服务的代号，群友对其性能提升抱有期望。
• Herdr：一个用于调度和管理多个 AI agent 的工具，支持在不同机器上分发任务。群友讨论其“提供了 skill 如果你要分发，在 leader agent 那里调用这个 skill 就成”。
• Supertag：一个被群友推崇的性能测试工具。群友分享其性能指标“蛮突出的”，并发布了使用视频。
• YOLO (You Only Look Once)：一种目标检测算法，用于视觉识别任务。群友提到公司用它识别“江边钓鱼的、火灾、抽烟、是否带安全帽”，以及“pdf 识别，布局，latex 等等都是用的 yolo”。
• STEPX Neo：阶跃星辰发布的大模型原生智能体手机，全栈定价 3999 元，群友表示已购买等待实测。
• WordCarft：一个“严格抄袭了 Word”界面的 AI 工具，群友对其“1:1 复刻原来软件的界面和功能”表示震撼，并担心“要吃官司了吧”。

💎 碎片知识与金句拾遗

• Emacs 用法：群友分享了一个替换 Raycast 的 Emacs 用法链接（unclex.net），并感叹“这个 emacs 用法很酷”。有人提到“我以前用 ef-theme 作者写的那个快速输入和这个一样的原理，但是总会卡”。
• Hammerspoon 性能：群友吐槽“Hammerspoon 的性能太差了”，但认为“作者在重写，但是慢”，并猜测“作者只是觉得可以赚钱，所以想重写，但是又发现竞争特别激烈，所以没啥动力”。
• 开源项目盈利：群友指出“开源项目基本上都是靠捐助的，除非是针对企业的中间件,就会有基金会开工资”。
• AI 监控技术：群友分享了一个监控技术网站（littleprince.dev），并讽刺“这些用来监控的技术都是用你订阅的钱研究出来的哦”。尽管如此，有人表示“但是架不住好用，我还是会注册 Claude”。
• 小王子 3D 游戏：群友分享了一个用 Opus 5.5 将《小王子》制作成 3D 剧情游戏的案例，使用 Tripo+Blender 生成游戏资产，引擎用 Unity。
• 兼职与黑灰产：有群友分享“现在兼职也是黑灰，做某社交平台账号注册的，tg上面联系的，每月v我1w”。具体工作是“根据手机号查询账号是不是注册过，封没封过，每个号查一次给我2毛钱”。群友提醒“这算不上黑灰吧”、“建议扔容器随时销毁”。
• 键盘与输入法：群友讨论随身携带分体键盘，但感叹“终究带不进💩坑”。还有人提到“手机上感觉全拼显著更好，因为实在太容易按错了”、“iPhone 手机上双拼的话 没法用首字母匹配app”。
• AI 协作模式：群友分享“claude 和 deepseek 的配合还挺不错的，两个都适应多 agent 交流的场景”，并具体描述“用 deepseek 执行读取，和验证的任务，速度比较快，而且准确度不错。我是 Claude Code 和 Pi + Pi-Subagent”。
• TTS 工具：群友分享 Supertag 中文视频的配音是“qwen3-tts 本地生成的”，并评价“没有太强的AI感”、“效果还不错”。
• 绿导师：群友提到“绿导师终于更新了”，并评价“每节课都很精彩，时常让我有重头再看一遍的冲动”。绿导师被描述为“上课让学生自己准备token的那个”。
• DeepSeek 使用技巧：群友分享“DS真够了，除非是那种特别特别复杂的问题。我觉得更关键的还是Harness。”并强调“关了效果肯定差。我理解 Deepseek 就是靠以思考换能力。它的自我纠错能力非常强。”
• AI 时代的 Star 通胀：群友感叹“感觉ai时代后 github的⭐️通货膨胀了，现在动则几K几十K的star”。

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

• 双拼方案优化：群友基于模拟退火和语料优化设计了新双拼方案，并开发了打字练习程序。这个方案的设计思路和测试结果值得持续关注，尤其是其对重码率和易学性的权衡。
• AI Agent 协作模式：群友分享的“Claude + DeepSeek”多 Agent 协作模式，以及 Herdr、FirstMate 等调度工具，展现了 AI Agent 协作的新范式，值得深入研究。
• YOLO 在文档识别中的应用：群友提到公司用 YOLO 做 PDF 识别、布局分析、LaTeX 识别等，这显示了传统视觉模型与 AI 工作流的结合潜力。
• Supertag：群友多次提及 Supertag 的性能指标，并发布了中英文使用视频。该工具在 AI 模型评测领域的应用值得关注。
• WordCarft：该工具“1:1 复刻” Word 界面的方式引发了关于知识产权和 AI 应用边界的讨论，值得追踪其后续发展。

观点延伸

当天最值得咀嚼的，不是“哪家模型赢了”，而是一个更现实的判断：模型正在从产品，退化成基础设施变量；真正决定生产力的，越来越是你有没有一套不依赖单一模型的工作系统。

1. 模型比较的终点不是排行榜，而是故障切换能力

群里一边抱怨 Codex 报错、速度下降、额度消耗异常，一边又因为 Claude 好用而继续注册，直到另一个模型“赶上来”。这其实已经说明：订阅模型并不等于拥有能力，只是租用一条随时可能限流、改价、风控或重置的管道。Gemini 的套餐隔离、API 与聊天额度差异，以及新账号触发 KYC，都在提醒同一件事：服务商的产品边界不是用户的工作边界。

工程上更稳的做法，是把模型当作可替换执行器，而不是系统核心。核心应当是任务拆解、上下文整理、测试、验证和失败恢复。至少要能做到：一个模型负责理解和编写，另一个模型负责读取、检查和反驳；模型不可用时，任务仍然可以暂停、重试或降级，而不是整个工作流瘫痪。所谓“Claude + DeepSeek 配合得好”，价值不在于两家模型神奇互补，而在于有人开始给不同模型分配不同职责。

2. Agent 的竞争力不在“会不会调用”，而在 Harness 是否可靠

群里有人说“更关键的还是 Harness”，这句话比单纯讨论模型智商更接近工程事实。大范围读取、代码编写、测试验证、跨机器协作，如果都由一个 Agent 自己决定，最终往往只是更快地产生不可审计的复杂度。把读取、实现、验证拆开，再用 tmux、子 Agent 或调度工具连接起来，虽然土，却保留了人工可见的边界。

这也解释了为什么大家嫌编排工具复杂，却仍然使用 tmux：复杂系统的真正成本不是启动任务，而是知道任务现在做到了哪一步、出了错能否定位、结果能否复现。漂亮的多 Agent UI 如果没有状态、日志、超时、重试和验收标准，只是把 shell 的混乱换了一层包装。

可继续研究/实践

可以做一个最小化的个人 Agent Harness：固定“读取—计划—修改—测试—复核”五个阶段，为每阶段记录输入、输出和失败原因，并准备两个可替换模型。先不用追求自动编排，观察一周后统计哪些步骤最常失败、哪些步骤最值得交给便宜模型。届时比较的就不再是“谁的榜单排名高”，而是单位成本下，哪套工作流更少返工、更容易恢复。