作者原文：
Via HN：
记得我第一次看nullprogram的文章是有关dynamic module的，我用过Emacs很多年，之后也不用很多年了。看到这么厉害的人物也慢慢弃坑了，还是有一点点怀旧与伤感。
1 个赞
已经基本在codex中开发了, 偶尔用emacs改改文件,确实用的越来越少了..
1 个赞
不好意思，我放错了 HN 的连接，现在已经更新 
看过这个大佬的很多博客 
codex有哪些独特的功能？
不是codex有哪些独有的功能，是内容的生成都是通过沟通，然后AI来写了，diff也可以同时看，只有偶尔编辑需要用到编辑器。
但我还有其他比如 telega、数据库客户端、postman 类似、org 还是在 emacs 里面的，写代码或写配置本身确实只是用 emacs 来少量编辑。
从 24 年开始，因为 AI 辅助编码 Emacs 不理想，我渐渐从 Emacs 转移到类 VSCode 上，今年开始连 VSCode 都不用了，因为连代码都不用怎么看，直接 codex、 copilot 一把梭。 Emacs 还是每天打开用于 GTD，很难预料未来会什么样，但是已经很少花时间去折腾 Emacs 了。
我有点不同的体验。
AI 确实能帮我们写很多代码，但我感觉程序员还是需要对代码库有基本的理解，比如整体架构、复杂度这些，不然改着改着很容易变乱，技术债也会慢慢积累。
所以对我来说，还是需要一个比较顺手的“看代码 + 做局部修改”的工具，Emacs 这方面（配合 LSP、tags，还有一些 AI 辅助）还是挺有用的。
另外我也发现，用 AI 做 coding 或者调研时，context 给得好不好，对结果影响挺大，这点 Emacs 的可编程性也能帮上一些忙。
不过你这种用法我也挺能理解的，感觉大家现在都在慢慢找到一个新的平衡点。
其实AI编程对emacs这样的可编程编辑器反而有促进 因为用elisp的编程门槛大大降低了
现在AI coding CLI结合emacs mcp tools还可以更进一步实时调试emacs函数功能 帮助修复代码 修正配置等等 emacs mcp took这个概念最早由Claude-code-ide.el提出的 现在ai-coding-interface.el也借鉴了这个做法 并拓展了调试能力 而且 把这个能力拓展到了codex CLI和GitHub copilot cli 只需要告诉AI某个elisp函数不符合预期 key bindings 不工作 让它用emacs mcp tool检查 它就会自己调试修复 不再需要靠人自己费心力去找问题
我反而是用emacs用的越来越多了,之前还得切到jb系享受更强的静态分析补全.
现在codex混opc,更需要顺手的编辑器来review\写日志零散文件.
日常生活,文件管理和当跨平台shell也很好用.
1 个赞
这个主题的含金量还需要上升