当 AI Agent 替你写代码，Vim 成了什么？

全文约 2300 字。

Hacker News 上有个帖子，50 分钟内冒出 19 条评论。发帖人是一位 Vim 重度用户，说了一句话：“我越来越少看代码了，Vim 还有没有意义？”

这个问题乍一看在问编辑器，其实问的是：当 AI Agent 开始替你写代码，“编程"这件事里，还有多少是你亲手在做的？

评论区里的真实工作流

评论区没有"别用 Vim 了换 Cursor"的劝退，也没有"AI 都是玩具"的嘴硬。大部分回答是同一个意思——用法全变了，但 Vim 没丢。

一位开发者在 herdr 里把 Vim 和 Claude Code 并排开着。一个 Tab 看代码，切到另一个 Tab 跟 LLM 聊。有时他在代码里写注释标注意图，让 Agent 按注释改；有时反过来，让 Agent 先分析一大段代码，出个方案，自己再动手实现。他区分得很清楚：“个人项目我更享受自己写，工作项目怎么快怎么来。”

另一位开发者干脆把终端一劈为二——左边 Vim，右边跑 Agent。Agent 改完代码，他在 Neogit 里 review diff。他说手写代码确实少了，但键盘导航、跳引用、看变更的速度，Vim 仍然比任何图形界面快。Vim 的编辑速度，用在审代码上一样好使。

还有一位更有意思。他说自己用 Vim 写 Markdown 格式的目标描述，发给一个自研的 CLI 工具调 LLM，结果也在 Vim 里看。“LLM 只是最新加入的工具箱。“这话说得很到位——AI 不是替代了你的工具，而是多了一件工具。

共识很清楚：没人丢掉 Vim，但几乎所有人都从"用 Vim 写代码"变成了"用 Vim 看代码、写指令、审变更”。

编辑器变了，Vim 反而更舒服

有位用户的转变特别有共鸣。他说自己仍然用 Vim，但"完全不关心那些编辑快捷键了，只用来浏览和导航文件”。

这话听着有点悲观——二十年的肌肉记忆，现在只剩 hjkl 用来翻页了？但仔细想想，这恰恰说明 Vim 的键位习惯已经变成了通用技能。有人从 Vim 转到 Zed 的 Vim Mode，理由是后台 Agent 在改文件，编辑器需要实时显示变更。Vim 的键位能移植，因为它们本来就是终端原生、键盘驱动的，跟 GUI 编辑器不是一条路。

两个极简用法被反复提到。一个是在 Claude Code 和 Codex 里按 Ctrl+G，会调出系统默认的 $EDITOR 来编辑你的 prompt。对 Vim 用户来说，这意味着你用 Vim 写 prompt，就像写代码一样自然。另一个是 vimdiff——Agent 改完了，用 vimdiff 做 side-by-side 代码审查，行跳转、折叠、差异高亮，全是 Vim 的老手艺。

还有一位开发者分享了他的策略：不让 AI 写代码自己来审，反过来——让 AI review 自己写的代码，加上 inline autocomplete。他说这样出来的代码质量更高，自己的心智模型也更清晰。“我和 Agent 单独都做不到这么好。”

Vim 从"写代码的地方"变成了"审代码的地方"加"写 Prompt 的地方”。这个转变对 Vim 用户来说几乎是零成本的——终端原生、键盘驱动、文件系统原生，这些特质在 AI 时代不是包袱，是优势。

说个更直观的例子。有位开发者在 Vim 里装了一个小插件，选中一段代码，加一句注释指令，直接发给 LLM，结果替换回来。小改动不走完整 Agent 会话，选中文本、敲指令、回车，完事。这跟当年用 Vim 的 :!command 调外部命令是同一个思路——编辑器不只是编辑文本，它是你和各种工具打交道的入口。只不过以前调的是 grep 和 make，现在调的是 LLM。

换个角度看，Vim 生态里那些老牌插件——fuzzy finder、LSP 客户端、文件树、git 集成——本来就是在做 Lilian Weng 说的"上下文管理"这件事。你用 :Telescope find_files 跳到某个文件，用 gd 跳到函数定义，用 :Neotree 看项目结构，说白了都是在管理你的工作上下文。AI Agent 加入之后，这套上下文管理的需求只增不减，只是多了"在旁边跑的 Agent 需要看什么、改了什么"这两个维度。

Harness：Vim 是你的套具的一部分

Lilian Weng 最近写了一篇长文，标题是"Harness Engineering for Self-Improvement"。她提出了一个概念叫 Harness——围绕基础模型构建的系统，负责编排一切：模型怎么思考规划、调用工具、管理上下文、存储产物、评估结果。

她的核心判断是：模型和真实世界之间的这层 Harness，跟模型本身的智能一样重要。AI Agent 的成功不取决于模型有多聪明，而取决于围绕它搭建的那套系统有多好用。

她说总结了 Harness 的几个设计模式：工作流自动化（规划→执行→观察→改进的循环）、文件系统作为持久化记忆、子代理并行执行。如果你把这些映射到 Vim 用户的日常操作，会发现惊人的对应——tmux 分屏就是工作流编排，文件系统持久化记忆就是 Vim 的插件生态（Neogit、telescope、fzf-LSP 全是这个思路），Vim 本身就是 Harness 里的"代码导航和审查"模块。

Weng 还提到一个值得玩味的趋势：Harness 优化的对象在升级，从指令提示到结构化上下文，到工作流，到 Harness 代码本身。换句话说，整个系统都在变得可编程、可搜索、可自动改进。但她说了一句很清醒的话——“很多 Harness 改进最终会被内化到模型行为里，但指定目标、约束、上下文和评估的需求不会消失。”

翻译成人话：就算 AI 写了所有代码，审代码的人不会消失。判断代码该不该 merge 的人不会消失。决定下一步该做什么的人不会消失。

话说回来，HN 评论里有人开玩笑说"Vim 用户和 AI 的交集基本为零"，被好几个人反驳。这倒让我想起另一条评论——一位开发者在远程服务器上跑 Claude Code，Claude Code 跑在沙箱里，改不了本地文件系统。他的 Vim 配置通过一个 setup 脚本一键部署到远程，所以 SSH 上去之后 Vim 的手感跟本地一模一样。“需要先 ssh remote-server，这感觉我喜欢。“这种执念大概就是 Vim 用户和 AI 确实有交集的证据——他们用 AI 写代码，但仍然在乎终端里的手感。

Vim 就是为这些人准备的。

这个思路反过来也成立——如果你正在构建 AI Agent 的 Harness，Vim 用户是你的最佳用户群之一。因为他们已经习惯了终端原生的工作方式，已经把文件系统当记忆用，已经能在 tmux 分屏之间跳来跳去。你不需要教他们"怎么跟 Agent 协作”，他们自己摸索出来的工作流可能比产品设计者想象的还顺滑。

NeoPad 的选择：工具做好工具的事

聊到这里其实想顺带说一件事。前两天我刚发了一篇 NeoPad 写完了的文章——一个本地便签工具，纯 Markdown，轻量，有 Vim 模式。

做这个工具的时候我面临一个选择：要不要在应用里塞一个 AI 聊天窗口？市面上很多笔记工具已经这么干了，AI 问答、AI 总结、AI 自动分类，功能一个接一个。

我没加。

NeoPad 内置了一个本地 MCP 服务，支持 AI Agent 在授权后读取、搜索、写入笔记。但它默认关闭，需要手动启用，访问要 bearer token。笔记工具仍然是笔记工具，Agent 只是被授权的协作者。

这个决定跟 Vim 在 AI 时代的处境其实是同一个问题：AI 应该在哪里？

Vim 不需要内嵌 AI。它在 Harness 体系里有自己的位置——终端原生、键盘驱动、文件系统原生。它只需要做好自己，让 Agent 在旁边跑。NeoPad 也是一样的道理——做好一个可靠的记录工具，给 AI 留一个清晰的接口就够了。

一个工具最怕的不是功能少，是失去边界。NeoPad 不做知识库，不搞云端同步，不塞 AI 聊天窗口。Vim 也不该变成 IDE。边界清晰，反而能在 AI 时代活得久。

写在最后

回到 HN 帖子那个问题——“Vim 还有没有意义？”

有。只是意义变了。

编辑器不会死。它会从写代码的地方，变成你和 AI 协作的那个界面——审代码、写指令、在终端里跳来跳去。tmux 分屏开着，左边是你，右边是 Agent。

手还在键盘上。

这就够了。