尝试了一段时间的 Doom-Emacs 以后，感觉作为一个文本编辑器而言，Emacs 可以说是做得相当好了，相比以前使用的 lazyvim，更有了一种大而美的体验。
但是随之而来的问题是，AI 时代下的 Emacs 何去何从？最近深度使用各种 AI agent 进行编程，基本都不怎么用 Emacs 了（除了 org 记录）。
所以是否有可能将 emacs 和各种 agent 进行集成？如 cc、opencode、codex 等等，如果能整合到 emacs 的插件中，岂不美哉？
目前是 copilot 做 inline completion，偶尔用 claude code ide，但是多数还是在终端中用 agent，因为在 emacs 有中文输入还有闪烁等各种问题，感觉不太好用，等个楼下的最佳实践
为什么中文输入有闪烁呀？是什么系统？我感觉对中文的适配相当好呀，fcitx5 还支持自动切换模式
我感觉没必要纠结，Claude code or Codex 好用就去终端用，Emacs依旧扮演一个编辑器的角色就好。
现在是这样的 
感觉可以和 emacs 结合得更深一些？毕竟还没有生态
我的体感正相反，ai 时代不怎么手搓代码，我反而很少打开之前主力编程用的 nvim 和 vsc 了（有个开发环境推了重建两周后我才发现还没装 nvim）
现在都是 emacs 和 helix 一把梭。emacs 可以随时随意扩展，且 ai 写的 elisp 还不错，有啥定制小需求都能让 ai 立刻搓，ai 时代隐藏红利吃满了（不是）
至于跟 cli 集成，我持消极态度，无论是 web 还是编辑器的集成都没法保证实时 100% 复原 cli 体验（cli 更新迭代太快了），还不如 tmux 一个窗口 cli 一个窗口编辑器来得实在
1 个赞
+1,我就是这么干的
我用了以下和 AI 相关的包：
- copilot.el: inline 代码补全，只在
prog-mode使用。 - gptel: 主要的 AI 入口。我平时主要有三种使用场景：
- 问答：和网页端使用 AI 类似。优点是可以用 org-mode，AI 给的代码可以直接用 org-babel 运行，特别是 elisp 代码，直接执行，立即生效，很爽。缺点是 AI 使用 org-mode 语法不太严谨，特别是中英夹杂时，格式常会有瑕疵。
- 总结/翻译/解释：一篇文章，一个词，一段代码，看不懂或懒得看，可以通过 gptel 的 transient 菜单，按两三个键，让 AI 直接给出答案。非常方便。
- 重写/重构：怕注释的英文不地道？感觉某个函数的逻辑不够清晰简洁？可以通过 gptel 让 AI 帮忙重写或重构。AI 完成后会有专门的 UI 让你 review，然后接受、拒绝或让 AI 返工。
- gptel-agent: gptel 的 agent 模式，支持 sub-agent，有助于缓解上下文爆炸的压力。其中有一个 sub-agent 叫 introspector，可以自己查看 Emacs 变量和文档，帮你改配置，非常方便。
- gptel-magit: gptel 的扩展，用来在 magit 中 commit 时让 AI 自动生成 commit message。
我对自己目前的配置很满意。不过，我从来没用过 AI IDE（如 Cursor）或 AI CLI（如 Claude Code），所以，也许我只是个井底蛙。
6 个赞
已经有一些把各种agent和emacs集成的项目了, 比如, GitHub - tninja/ai-code-interface.el: Unified Emacs interface supporting Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot CLI, Opencode, and more, 现在已经支持10来种ai coding agent了. 一部分是其他网友贡献的. 作为开发者, 重点之一放在emacs和agent之间的交互, 让agent能够理解editing context. 我自己写代码写文档都用它. 在Claude Code / Codex / Github Copilot CLI / Gemini 之前切换, 命令是通用的, 不需要重新记忆.
在本站的发布贴在(发布) 集成多种AI coding cli tool的emacs前端, ai-code-interface.el
其他比如agent-shell, 在emacs圈子里很受推崇, 但是我自己用的时候发现 / 斜杠命令没有补全, AI响应的时候有时候没有进度提示. 也许是我没学会怎么配置. 也可能是目前agent shell protocol的限制.
4 个赞
claude code ide 和Emacs结合的挺好啊；如果喜欢原始命令行模式，在Emacs开个term/eat用claude code / codex感觉也一样
我感觉和vscode装claude code插件用，或者直接命令行用也没差别；当然cursor那个深度tab和inline调用chat的模式比较结合深入，但现在大部分时间其实也一样是用它分屏的plan/agent，也差不多。
现在vb模式，其实就是一边编辑器、一边开一堆cc或codex干活，这个基本形式下感觉差别都不大：vscode、cursor自已内部分屏；左屏vscode、右屏terminal开若干cc；tmux下一边vim、一边一堆cc；emacs里一边buffer一边一堆cc。cc agent模式的出现，反而ai提升inline completion角度没多大必要了，有个传统补全能局部高效编辑改改代码也够了（反正我又不长段写代码，纯bb就成，全靠右边4、5个cc牛马
）。
下面插件大差不差的，支持cc的功能就成：
1 个赞
最有用的发明之AI撰写docstring
4 个赞
你这个比 agent-shell 好用，AI 交互便利性上是个补充。ACP 那套感觉损失很多功能。
ai 的出现正在杀死旧的一批所谓的 ide, 同时让 emacs 这种基于文本的交互工具获得新机
历史本身是审判者，而 emacs 就是执行官
3 个赞
确实，Emacs 兼具TUI模式和高度扩展性，我很看好emacs，感觉今年会火
我目前还在传统的论语式用 AI，你一句我一句的聊天 
。
拿我那个帖子来举例的话，Google 的 Ai Studio 支持生成 Python 代码来直接调，可以把生成 docstring 的提示词这个功能包装成 Python 子进程脚本，然后根据回调直接插入 Docstring 到注册的 Marker 位置。
也许这个也能直接 gptel 搞定。
5 个赞
论语式
好清奇的比喻
1 个赞
也可以说是 Daniel P. Friedman 那种小人书式，zsbd。
1 个赞
至少对我来说，集成 agent 到 emacs 意义不是很大，因为总是要分屏的，很多事情在 terminal 反而容易一些，而且那些 TUI agent 生态也更成熟。但 AI 的好处是能最大地发挥 emacs 的超强扩展能力，很多小工具一下就 vibe 出来了，minibuffer、补全、UI 全是现成的，也不用费力气重做，最后只会越用越顺手。前阵子就 vibe 了一个跳转和管理 opencode session 的 emacs 工具，已经完全够用了。
可能 emacs 在 AI 时代是另一种 paradigm。其它工具都还是别人做好了喂给你，但 emacs 是一个能无限定制的交互层，什么都不需要，自己靠 AI 搓就完事儿了，效率会越来越高。
3 个赞
用claude code帮我整理笔记，还有把各种其他格式的文件识别之后导入org文件里，确实很爽
1 个赞
最近编辑器对我来说只有实时审阅AI代码的作用了。目前AI还不能替代的是学习过程，Emacs还可以作为笔记软件。
1 个赞