Geekinney

外观

Emacs 社区日报 2026-10-11

约 5204 字大约 17 分钟

2026-10-11

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

Emacs 社区日报 2026-10-11 手绘图
Emacs 社区日报 2026-10-11 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】AI 时代，程序员的核心价值何在？—— 从"不会写 log"到"我必须要自己搞懂"

群内围绕 AI 对编程工作的冲击展开了一场跨越两小时的激烈讨论，话题从最初的自嘲（"没了 AI 连 log message 都不会写了"），逐渐沉淀出两条针锋相对的立场，并最终收敛到一套可行的实践方案。

观点一：旧时代的技能该被淘汰

有成员认为"旧时代的技能就该忘记"，程序员正在失去价值（"那人还有什么用"），甚至将 AI 取代人类视为人类演进的必然（"人类发展至今不就是为了这一刻吗"）。这种论调更多是情绪宣泄，但在讨论中被另一个更冷静的声音所反驳。

观点二：人必须理解代码，AI 只是工具

这是群内最具洞察力的核心论点。某成员提出了一个近乎金句的论断：

"我不需要 AI 搞懂，我需要我搞懂。我搞懂了我可以自己做，也可以让 AI 做。但是 AI 搞懂了，我不能知道它是不是真懂了，除非我搞懂了。"

随后另一位成员补充了实际的痛点案例："如果团队长期用 AI 污染一个项目，就没人能搞明白了。AI 也不行。" 并分享了一个令人脊背发凉的实战经历——一个业务被 AI 改成了最终一致性，导致没人敢删那段代码。这句话几乎完整地描绘出了"AI 生成代码"在企业项目中可能引发的灾难性后果：代码通过测试、逻辑看似正确，但没有人能够理解其分布式状态流转的潜在风险，只能原地供奉。

收敛方案：人机协作的"填空式"编码

讨论最终落到了一个可操作的实践上：

"自己先想清楚，然后写出来基本的数据结构和方法的伪代码框架，然后让 AI 去填充。AI 写完基本和自己的想法一致。代价就是比同事出活慢一些。"

更进一步，有人分享了自己用函数签名 + 行数约束 AI 代码质量的经验：

  • 先写出函数签名（类型、入参、返回值），然后根据行数判断 AI 的实现质量；
  • 用硬性约束（如禁止 for 循环深度嵌套、函数体不超 50 行）来强制 AI 产出可读代码；
  • 并感叹："我有点怀念 eslint 了，但是 c/c++ 和 elisp 是没有这种东西的"，指出 clang-tidy 约束力不够。

这场讨论没有停留在"AI 强不强"的表层，而是真正触及了 AI 辅助编程时代的核心矛盾：自动化带来的可读性负债，以及人类理解的不可替代性。

🔑 关键概念与技术解析

  • Fable：群内提及的一个工具，用于代码重构，据称"15 分钟搞定了一场原本以为要想很久的重构"。上下文暗示它是一个 AI 驱动的高效重构工具，但在记录中未明确其具体技术栈，值得后续考证。
  • 最终一致性 (Eventual Consistency)：分布式系统中的一致性模型。在群聊中被用作一个警示案例——AI 将某个业务逻辑改成了最终一致性，导致代码无法被任何团队成员理解与维护，成为"没人敢删"的遗留代码。
  • clang-tidy / eslint：C/C++ 与 JavaScript 生态的静态代码分析工具。群内成员将其类比为约束 AI 代码风格的规则引擎，指出 C/C++ 生态缺乏像 eslint 那样细粒度的可配置规则，导致 AI 生成的代码质量难以用工具统一把关。
  • Emacs 分页符技巧：在 Emacs 中，通过 C-q C-l 打出分页符（^L），并用 C-x [ 和 C-x ] 进行前后导航。这是一个冷门但实用的 Emacs 文件导航技巧，用于在长文件中快速切换"书签"位置。

💎 碎片知识与金句拾遗

  • "AI 只需几分钟就能搞懂整个项目，无论间隔了多久"——这是对 AI 上下文记忆能力的直观观察，也是后续"我必须要自己搞懂"争论的导火索。
  • "有人生活在山洞里，有人已经移民火星" / "奶娃你移民了吗" / "我活在深井里"——群内对技术差距的黑色幽默自嘲，值得原样保留。
  • "AI 的脚手架和出 demo 确实非常快，但是到了中后期，人懂项目才是核心，认为人可以凭借经验和预期提前规划。"——这句话精准总结了 AI 在项目初期与中后期的价值差异，可以作为知识库的格言级别记录。
  • "人也可以耦合特定的结构来简化问题，提高效率。"——这是在讨论"人类价值"时的一个亮点，点明人类主动设计架构的能力（如领域驱动设计、分层模式）本身就是一种"人优于 AI"的生产力杠杆。
  • Emacs 文本装饰 patch：群内分享了 B 站视频《我给 GNU Emacs 写了一个 underline 等文本装饰随字体缩放的 patch》，并评价"对 fable 来说也是小菜一碟"。这暗示了 Fable 可能是一个通用的代码或文本变换引擎，同时也展示了硬核玩家用 patch 打磨 Emacs 的日常。
  • "颜色盘就是按照这样 vibe 出来的"：提到了用 AI 以"vibe"方式生成设计资源（颜色盘）的个人经验，说明 AI 在 UI/UX 辅助生成方面已经进入了日常 workflow。

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

  • 基于约束的 AI 代码生成模式：群内成员提出"函数签名 + 行数上限 + 禁止深嵌套"的约束策略，并以 clang-tidy/eslint 作为类比。这是一个非常前沿且实用的研究方向——将代码规范转化为可编程的约束，用于引导 LLM 生成可读代码。可以进一步调研是否已有开源项目（如 Guardrails、Outlines）支持此类 schema-based 生成约束。
  • Fable 工具本身的原理与适用场景：群里两次提及 Fable 处理复杂重构（15 分钟解决"想很久的重构"），但未说明其具体实现。作为一个可能改变重构工作流的工具，值得单独深挖。
  • AI 生成代码的"最终一致性"陷阱：这个案例揭示了 AI 在无意识状态下可能引入分布式系统复杂度，从而导致代码库"不可维护"。这指向了一个更深层的问题：如何用静态分析或测试覆盖率，自动检测 AI 提交的代码是否引入了超预期的复杂度（如意外引入事件总线、异步消息队列等模式）。

观点延伸

当天讨论真正有价值的结论，不是“人会不会被 AI 取代”，而是：AI 正在把编程从“产出代码”推向“管理复杂度”。谁不能判断一段代码为什么存在、改变后会影响什么，谁就只能接受 AI 的解释，而不能真正控制系统。

1. “AI 懂项目”不等于项目可维护

AI 几分钟重新理解一个项目，解决的是上下文恢复问题；人长期维护项目，承担的却是边界判断和风险责任。前者擅长从现状中找出一条能运行的路径，后者必须知道哪些路径不该走。

“被 AI 改成最终一致性，没人敢删”是一个很准确的警报：最危险的代码不一定是错误代码，而是没人能证明它为什么安全。它可能通过测试、暂时稳定，却把隐含的时序、状态和补偿逻辑埋进系统，最后形成“不能解释、不能删除、也不能重写”的技术遗产。AI 提高了局部实现速度，却可能放大系统级不可逆性。

2. 约束不是限制 AI，而是保留人的判断权

先写数据结构、函数签名和伪代码，再让 AI 填充，本质上是在把“设计权”和“实现权”分开。行数上限、禁止深层嵌套、明确返回类型，也不只是代码风格，而是把人的可读性标准变成机器必须遵守的接口。

这说明成熟的人机协作不是让 AI 自由发挥，而是缩小它可以自由发挥的范围。约束越接近架构边界，生成结果越容易被审查；约束只停留在格式层面，AI 仍然可能写出整洁但错误的系统。真正缺的或许不是更多自动补全，而是能检查“复杂度是否超出原设计”的工具。

3. 慢一点交付，可能是在提前购买维护能力

群里提到的代价是“比同事出活慢一些”。但如果更快的交付换来一个无人理解的项目，速度只是把成本推迟到故障、交接和重构阶段。自己先想清楚再让 AI 实现，表面上牺牲了几分钟，实际上是在保存系统的因果链：为什么这样设计、哪些地方可以改、哪些地方绝不能动。

可继续研究的方向是建立一套“AI 代码准入协议”：提交前要求给出数据流、状态变化、失败路径和删除条件，并用函数规模、嵌套深度、依赖变化等指标做自动检查。重点不是让 AI 写得更像人，而是让人始终能够证明这段代码值得留下。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：AI编程工具的口碑分化——Tibo vs Claude

今日讨论最激烈的话题集中在AI编程助手的使用体验上。群内多位成员对 Tibo（tibo） 的额度政策表达了强烈不满，认为其“偷偷降额度”后“公开投票说搞升额度”是缺乏诚意的公关行为，甚至称其为“新一代耍猴大圣”。而 Claude 则获得了高度评价，多位成员表示“我是 Claude 的拥趸”，并分享了高强度使用后额度消耗极低的实测体验（“每天高强度用，几天过去了，居然只用了 16%”）。

  • 痛点：Tibo 的额度策略反复、公关话术引人反感；Devin 需额外开通 $20 套餐才能配合 ChatGPT 使用，被视为“买车还得自己交油费”的收割逻辑。
  • 对比观点：有成员指出 Claude 的 Opus 输出“比较抽象”，而 Fable 输出质量更好，但价格较贵（“5x 用不起，偶尔放纵一下可以”）。Claude 被评价为“偏科研和高端的”，而 ChatGPT 则“更偏向 C 端基本盘”（如 Computer Use、取代 Google 搜索入口等）。
  • 深度吐槽：“人家偷偷扩额度，他倒好偷偷降额度，降了就算了，觉得快要打不过了，就偷偷升额度呗……他倒好，拿这个当话题炒作”——这反映了用户对 AI 厂商营销策略的普遍不信任感。

专题：etaf 游戏引擎的进展与生态讨论

围绕 etaf（一款正在开发中的游戏引擎）的讨论持续展开，并延伸至游戏开发与 Emacs 渲染技术的结合。

  • 游戏构想：成员们提及坦克大战、小丑牌、SHENZHEN I/O 中的纸牌小游戏等童年经典，有人表示“我现在有一个通用的做卡牌类游戏的框架引擎”，也有人关注“能做动画效果吗”。
  • 技术细节：etaf 引擎以 SVG + 文本增量更新 为核心，成员指出“动画的本质就是增量更新”，并认为这种交互“也能做那种很好看的流程图或思维导图的绘制”。游戏棋盘由 SVG 棋子与文本组成，而非 Canvas。
  • 关联讨论：Neomacs（Emacs 的浏览器渲染前端）在没有 GPU 的电脑上走 software render 路线，“估计性能很差”，但核显也算 GPU。

专题：开发者账号风控与替代方案

一位成员表示用了近一年的账号“常在河边走”被封，引发关于账号申诉、替代渠道的讨论。

  • 应对方案：有人提到“听其它群的人说得用静态ip”；也有流传的申诉方式（“之前有一个 X 流传的应对方式……可以把账号申诉下来的”）；实在不行则“注销账号，然后新注册”。
  • 替代工具：讨论涉及 Copilot、Kiro、Factory、Junie、AMP 等渠道，但“要用 Pi 的话好像都不行”。有成员认为 AMP “应该蛮不错的”，且“AMP 可用 Claude Code”。
  • 延伸观点：有人吐槽 orca service 配置不稳定（“连个 orca service 都要我从 IDE 裁减的……配成功过一次，都不能保证下一次配成功”），因此转向尝试 Paseo 和 Moshi 进行手机端管理。

🔑 关键概念与技术解析

  • etaf：一款正在开发的游戏引擎/框架，核心设计为“SVG 棋子 + 文本渲染 + 增量更新”。增量更新是动画与交互流畅性的基础，成员认为它适合构建游戏、流程图、思维导图等视觉交互应用。
  • strata-mlx：一个引发开发者注意的项目，推测与 stratus（或某个 Emacs 相关工具）的 MLX 版本有关。具体细节未展开，但被提及“这么快就引来 strata 开发者的注意”。
  • SWE-2：Claude 的编码模型/功能（或对应套餐），群内成员对其评价较高（“SWE-2 确实不错，这个月疯狂用都给用爽了”），但也提到“跑多线程容易碰到 limit”。
  • software render：无 GPU 时 Neomacs 采用的软件渲染路径，性能较差，核显（iGPU）也被视为 GPU。
  • AMP：一个可用的 Claude Code 接入渠道，被认为“蛮不错的”，可能是替代官方订阅的 API 中转方案。

💎 碎片知识与金句拾遗

  • GitHub 通知坑：自己发起的项目，新 issue 和 PR 默认不会通知，因为默认不是 watch 项目的，“你需要手动改”。成员感叹“阿西吧。。。这么坑”。
  • Claude 耐用实测：“每天高强度用，几天过去了，上午查了一下，发现居然只用了 16%”——Claude 的额度耐用性获得口碑。
  • AI 重写自己的案例：一个 AI 编程工具指挥两千多个 AI 分身，花两周把代码从 TypeScript 全部重写成 Rust，每改一处都跑新旧版本对比，行为一致才算过。“思路不复杂，但规模吓人”，值得一看：https://www.primeintellect.ai/blog/prime-agent-rust
  • 程序员硬核实力：讨论 YouTuber 时提到“tsoding 的少哦，现在程序员不依赖 lsp 的都很少”，以及“敲代码太慢了……我觉得就是上来唠嗑的”，强调“程序员还是看实力”。
  • 写作比喻：“就像我写作文的时候，800字的话可以一口气写完。代码我还没到这个程度”——对自己编码流畅度的自嘲。
  • Fable 使用建议：“我写 spec 都用 fable”“我挺满意的，而且没什么废话”——Fable 在 spec 写作中表现良好。
  • lody 的优势：调用稳定、手机 UI 流畅、跨机调用不会出现混乱、session 隔离做得好、chat 有可展开日志。成员后悔没在国庆前买半价 lody。
  • memoh 的坑：“最近的 memoh 差点让我裂开，不过只要不用它，它的云主机真香”。
  • Org 笔记性能测试：d12frosted 的几大笔记 package 性能测试结果发布，supertag “表现尚可”：https://github.com/d12frosted/org-notes-bench/blob/master/RESULTS.md
  • vulpea 的 API 设计：“有 vercel 的优秀一致性的体验”，但手机端配合不便。
  • B 站内容推荐：一个 Linux 手元视频展示“nvim 在任何地方作为输入法”（sway 环境），另一个是“给 GNU Emacs 写了一个 underline 等文本装饰随字体缩放的 patch”。
  • 技术栈观察：某项目使用 C + Janet（Lisp 方言），被认为是“C + Lisp 大法”；也有成员用 Rust + Janet 做 dirge，但“让 AI 写插件的时候好难受”。

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

  • etaf 引擎：增量更新驱动的 SVG + 文本渲染方案，适合构建游戏、流程图、思维导图等视觉应用。值得关注其发布后的 API 设计与实际性能。
  • strata-mlx：新出现的 MLX 相关项目，可能对 Apple Silicon 生态下的 Emacs/工具链有影响，值得持续观察。
  • Prime Agent Rust 重写案例：AI 驱动的全量重写流程（两千多个 AI 分身 + 行为对比验证），展示了 AI 自动化工程实践的前沿可能性。
  • Neomacs 的 vertical writing 支持：成员正在为 Neomacs 添加“从上到下，从右到左”的书写支持，适合阅读诗歌，微信读书不支持该排版，Moon Reader 支持。这是一个小众但有趣的排版方向。
  • 手机端管理 herdr 的方案：Paseo、Moshi、beorg 等工具在讨论中被提及，未来可能会有更成熟的移动端解决方案。

观点延伸

当天最值得咀嚼的，不是“哪个模型更强”，而是两个判断标准正在浮出水面：工具是否让人保持掌控感，以及系统是否把复杂性藏在可验证的边界后面。前者解释了大家为什么对 Tibo 的额度叙事反感，却愿意称赞 Claude“只甩功能”；后者则同时出现在 etaf、AI 编程代理和手机端 session 管理的讨论里。

1. AI 工具的核心竞争力，已经从能力转向可预期性

群里对 Tibo 的不满，表面是额度变动，实质是行为不可预测：用户不知道限制何时改变，也不知道厂商是在改产品，还是在经营舆论。相反，“高强度用了几天只消耗 16%”之所以形成口碑，不只是因为额度多，而是因为用户可以据此安排工作。

这对 AI 编程工具有一个直接判断：不要只测一次回答质量，要记录一段时间内的限流、并发、失败恢复和费用变化。一个偶尔输出惊艳结果、但会突然改变边界的工具，很难成为工程基础设施。真正值得付费的产品，应该像稳定的编译器或数据库：能力可以迭代，契约不能偷偷漂移。

2. Agent 的瓶颈不是“能不能调用”，而是“能不能隔离”

多线程触发 limit、反代配置反复失效、手机端 session 串台，以及大家对 lody“调用稳定、跨机不混乱、日志可展开”的称赞，其实都指向同一个工程问题：Agent 系统的价值不只在模型，而在运行时边界。

当一个工具能明确区分主机、pane、session、任务日志和权限，用户才敢把长任务交给它。否则模型越聪明，出错后的排查成本越高。所谓“好用的 Agent”，首先应该是一个可靠的任务调度器，其次才是一个会写代码的模型外壳。

3. etaf 的“动画就是增量更新”是很有力量的抽象

这句话值得从游戏推广到工具设计：界面不必每次重建整个世界，只需维护状态变化及其可见影响。SVG 棋子加文本、增量更新，天然适合棋盘，也可能适合流程图、思维导图和 Emacs 内部工具。关键不在 SVG 本身，而在于是否能建立清晰的状态模型、局部更新规则和可回放的事件序列。

可继续研究的方向是：给 etaf 做一个最小事件日志和基准测试，同一份状态分别驱动游戏、流程图和编辑器组件，比较全量重绘与增量更新在对象数量、动画帧率和调试难度上的差异。若这套抽象成立，它就不只是一个“在 Emacs 里做游戏”的引擎，而可能成为 Emacs 交互式应用的一种通用运行时。