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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 与 AI 集成——工具链的博弈与未来

群内围绕如何在 Emacs 中使用 AI（特别是 Codex、Claude 等 coding agent）展开了深入讨论，核心痛点集中在工具链的割裂与标准化缺失上。

• 工具对比与评价：
  • Codex 被认为是当前“王者”，尤其在写 CRUD 代码、处理 PDF（自动 OCR）和生成专业报告方面表现优异，返工率低。
  • Claude 评价分化，有人觉得“不好用”，也有人认为其 plan review 等高级功能有价值。
  • 免费模型 普遍被认为“笨笨的”，尤其是在排版（typst）等专业任务上，效果远不如付费的 Codex。
• Agents / Tool 的实践痛点：
  • Tool 命名问题：tools 概念与 LLM 原生认知冲突，且与 Codex 的 skills 相比功能太弱。
  • Agent 难驾驭：开发到后期（中等规模项目），LLM 会频繁“偷懒”，忽略 agent.md 中的规则，即使优化后仍会漏掉关键信息，导致 token 消耗巨大（半小时耗掉5小时额度）。这种感觉就像“带着一群不得力的员工”，需要大量精力盯着。
• 集成方案的权衡：
  • 直接对接 UI：不可靠，维护成本高且滞后。
  • 封装官方接口：需维护多个接口。
  • ACP 协议：作为 AI 时代的 LSP，由 Zed、Google 等联合制定。虽然支持力度不一（Codex 需额外安装，Gemini 原生支持），但被认为是目前最可行的标准化方案。群内对其前景存在分歧，有人看好它能降低社区维护成本，也有人因 Zed 风评不佳而看衰。
  • Emacs 内的优势：能快速选择文件/报错、利用 Emacs 做语法高亮和 LaTeX 渲染，这些是外部工具难以替代的。

专题二：Emacs 生态动态与工具推荐

• elfeed 更新：minad 接手 elfeed 后疯狂推代码，解决了大量“痛点”，值得期待。
• RSS 使用情况：有人放弃 RSS（因知乎无法订阅），也有人坚持用 Gnus 看 RSS。
• 新项目/工具：
  • emacs-codex-ide：一个非常好用的 Codex 前端，深度集成 Emacs 组件（如 diff），推荐试用。
  • EAT 回归：作者回来做调查，该项目有复苏迹象。
  • 对 Folo 的不满：“越来越受不了 folo 了”。
• 社区变化：Emacs-China 论坛开始直接删帖，不再说明原因，引发讨论。

---

🔑 关键概念与技术解析

• ACP 协议：Agent Communication Protocol 的缩写，由 Zed 编辑器推动，Google 等参与制定。旨在为不同 AI 模型（如 Codex、Claude、Gemini）提供一个统一的接口，类似于 LSP 对编辑器的作用。Emacs 未来只需对接 ACP，即可兼容多种 AI 后端。
• Sliding Attention：一种处理长上下文的技术，并非全量计算 attention，而是只关注局部滑动窗口。虽然节省资源，但会导致长程依赖丢失，是 LLM 在处理大项目时“漏信息”的技术原因之一。
• Serverless：群内讨论其本质与 CGI 无大差异，但国外（如 Cloudflare Workers）用得更多，可用于快速拼凑应用服务。与 AI 编码的伪需求（CRUD）结合得较好。
• agent.md：Coding Agent（如 Codex）的项目级配置文件，用于定义项目规则、约束和上下文。内容过多或长上下文时，模型会忽略其中的部分指令。

---

💎 碎片知识与金句拾遗

• 关于工具选择：“只有当 Emacs 内使用比外部强的时候，才值得用 Emacs 来做。”
• 对 AI 编码的反思：“CRUD 本来就是伪需求，所以 Serverless 才能大行其道。”
• 对 AI 上限的判断：“目前的 LLM 也就这样了，感觉已经到顶了。搞 AGI 感觉要找新方法了。”
• 关于模型选择策略：“每月换一家比较合适，这样每月的我，都是最强的。”
• 对行业趋势的评论：“感觉现在才是软件工程时代，以前是软件手工时代。”
• 对 JetBrains 的悲观：“JB 感觉公司要没了，现在都没啥新活。”
• 技术细节：优化 agent.md 时，把重要内容放前面可以缓解模型忽略的问题，但这会导致 token 消耗剧增。
• 实用小技巧：
  • 想用 AI 实现复杂 typst 排版，可以先写 LaTeX 再让 AI 重写成 typst。
  • 使用 Codex 时，可以信任它的 OCR 能力，即使是图片 PDF 也能分析。
• 生活/运维经验：Telega.el 在 Mac 上登录 Telegram 无响应，可能是网络/代理问题导致收不到验证码。

---

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

1. emacs-codex-ide：一个与 Emacs 组件深度集成的 Codex 前端，支持 diff 等原生功能。值得下载试用并对比与 gptel、agent-shell 的优劣。
2. ACP 协议现状：虽然存在争议，但作为“AI 时代的 LSP”，它的成熟度与社区活跃度值得追踪。建议关注 Zed 和 Google 对 ACP 的维护更新。
3. elfeed 的 Minad 版本：minad 刚接手 elfeed，推出了大量痛点修复，值得第一时间更新体验并反馈 bug。
4. Rust 重写 Emacs：群内戏称“需要爱”，但确实是 Emacs 未来性能优化的一个维绕方向，可关注相关项目（如 emacs-ng、libgccjit 等）的最新进展。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：AI 工具的使用、成本与生态博弈

群聊围绕 AI 工具（主要是 GPT/Claude/DeepSeek）的使用体验、成本控制、以及开源/自制工具的生态博弈展开了密集讨论，呈现出一个典型的“硬核玩家”群体在 AI 热潮中的行为模式与痛点。

核心观点与痛点：

1. 成本焦虑与Token膨胀：多个成员反映 AI 模型（尤其是 codex 和 GPT-5.5-xhigh）的 token 消耗“飞快”，导致“全靠 GPT-5.5-xhigh 撑不了几个回合”。讨论中提到需要研究 pi（一种上下文压缩方案）或multi-agent架构来降低开销。
2. 替代方案与性价比：对于高端模型（如 GPT Pro 100美元/月），成员分享了“闲鱼礼品卡”（570元）、“土耳其区”、“5个Plus”等拼单或低成本方案。DeepSeek（DS）因其 1M 超长上下文和出色的记忆保持能力被高度评价，一位成员表示“从昨天用到现在，DS的1M上下文才用了32%”，并称赞其“记忆力很强，不会过了几个对话就忘了之前的”。
3. 平台与工具链：成员分享了将 DeepSeek 接入自定义 Agent（Hermes Agent）的经验，并对比了在 claude code 中使用 DS 的高消耗，转而使用 pi 以获得更稳定的体验。codex-auth 被提及，但似乎存在货源不稳定的问题。
4. “离不开了”的依赖：“ai就像毒品 沾上就离不开了”、“没了ai感觉现在不会写代码了”等言论，生动反映了 AI 编程辅助工具在开发者群体中已成为几乎不可替代的生产力引擎。

专题：Hacker News 阅读器与新 RSS 方案的探索

群聊中出现了对传统 RSS 系统的不满，并催生了自建 Hacker News 阅读器的讨论，体现了对信息获取方式的高度定制化需求。

核心观点与痛点：

1. RSS的“痛苦”：成员认为传统 RSS 存在“全文拉取困难、Cookie 失效、反爬虫”等一系列维护难题。一位成员直言“rss 需要维护的内容更加细碎”，并感叹“我觉得这就是反爬和爬取的长期拉锯战”。
2. 中继服务的必要性：讨论认为一个稳定、轻量的后端中继服务器（如 RSSHub）是解决 RSS 问题的关键。但自建中继（如 Vercl）成本高、易出问题，而购买服务（如 Feedly）又失去了自定义的乐趣。
3. 新方案构想：一位成员正在开发一个自用的 Hacker News 阅读器，并已将其放在 GitHub 上打磨。其设计思路似乎旨在解决上述痛点，但尚未详细披露技术细节。
4. 放弃论：也有人提出“已经放弃rss了，rss内容现在不仅仅是文字，还有其他的视频、图片、音频，这些并不适合Emacs”，反映出对单一阅读范式局限性的认知。

讨论主题：WhatsApp 验证、跨平台服务与风控

群聊中穿插了一条关于 WhatsApp 验证的案例，引发了短暂的讨论，展现了现代互联网服务中电话与即时通讯工具交互的复杂性。

核心观点：

• 验证方式变化：一位成员遇到英国号码不发短信，却要求通过 WhatsApp 验证的奇葩情况，感叹“离谱！WhatsApp 普及度这么高的吗？”。
• 风控严苛：有成员指出 WhatsApp 本身风控极严，需要整“passkey”等更安全的认证方式，也提示了在国外操作前需谨慎准备。

🔑 关键概念与技术解析

• pi：一种上下文压缩（Context Compression）技术，旨在通过智能压缩或重写提示词内容，减少 token 消耗，从而降低 AI 调用成本，尤其适用于长时间对话或复杂任务。
• multi-agent（多智能体架构）：通过将复杂任务拆解，分配给多个专门的 AI Agent（如规划 Agent、编码 Agent、测试 Agent）协作完成，旨在降低单个 Agent 的上下文压力和 token 开销，提升效率和可靠性。
• proxy 与 codex-auth：指通过代理或认证服务（如 codex-auth）绕过官方限制或成本，使用 AI API 的方式。群聊中提及 codex-auth 似乎是某种第三方服务或内部项目，存在货源不稳定的问题。
• hermes agent: 一种开源的 AI 代理框架，允许用户通过自然语言驱动代码执行、文件操作等，是连接 AI 模型与本地工具链的中间件。

💎 碎片知识与金句拾遗

• AI 上瘾现象：“ai就像毒品 沾上就离不开了”、“没了ai感觉现在不会写代码了” —— 非常真实且高频率的反馈。
• 开发者日常吐槽：“食之无味弃之可惜 哎 硬盘快满了” —— 一位成员在讨论本地模型时的心声。
• 学习方法建议：“知识库过时了，你至少要关注 reddlt 的 LocalLLM 这个子社区” —— 提醒关注前沿社区而非过时资料。
• 小技巧：“翻译做了缓存 重复翻译不要token” —— 一个关于提高效率、节约 API 调用的实用提示。
• Emacs 相关：“我希望可以用这个思路改一下 elfeed，那么多年了，它一点改进都没有” —— 对 Emacs RSS 阅读器 Elfeed 的稳定性和功能停滞的无奈调侃。
• 冷门服务：“WhatsApp 普及度这么高的吗？” —— 对 WhatsApp 在工作场景中被用作验证渠道的惊讶。
• 对极简主义与硬核的思考：“vercel...，说实话，是好上手，但渡过初级阶段，就不应该用它了” —— 对过度依赖低代码/云平台的反思，表达了对更底层、更稳定控制方案的偏好。

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

1. pi 上下文压缩方案：深入调研 pi.dev 的技术原理、与常见框架（如 LangChain）的集成方式，以及在降低 token 消耗方面的实际效果。
2. hermes agent 社区动态：关注该项目的更新，特别是其对 DeepSeek 等新模型的接入能力，以及如何优化 token 使用。
3. 新型 Hacker News 阅读器项目：关注这位成员在 GitHub 上发布的 Hacker News 阅读器，其设计理念和解决 RSS 痛点的方法值得探索。
4. multi-agent 编程范式：研究如何使用多智能体架构（例如通过 crewai 或 autogen）分解复杂的软件开发任务，作为单一大模型高消耗的替代方案。
5. LocalLLM 社区动态：关注 Reddit 上 r/LocalLLM 社区的讨论，以获取关于 4060 8G+64G RAM 这类常见硬件上运行本地模型的最新方案和性能提升技巧。