OpenShell终端复用配置实战：从bash到zsh的高效工作流搭建

我折腾命令行工具这些年前前后后换过不下三十套配置从最早的.bashrc堆别名到后来 zsh 的 oh-my-zsh 全家桶再到现在的 OpenShell 组合方案算是把终端复用这件事彻底捋顺了。OpenShell 并不是某个官方发布的神奇工具而是我在实际工作中沉淀下来的一整套开源 Shell 增强实践把模糊检索、智能跳转、历史管理、命令补全、会话恢复这些能力整合到一个可以随时复制迁移的工作环境里。它解决的核心问题只有一个——让终端真正成为你的高频工作区而不是每隔几分钟就被重复敲命令和翻历史搞到心烦的旧板凳。这篇文章适合两类人一类是每天要跟服务器、日志、代码仓库打交道的开发者和运维另一类是刚接触终端、想直接抄一套成熟配置的入门玩家。我会把整套 OpenShell 的搭建思路、关键组件、配置细节和真实踩坑经历全部展开来讲你可以照着落地也可以只挑其中几个模块用。1. 为什么需要 OpenShell终端复用的痛点与设计初衷1.1 从 bash 到 zsh传统 Shell 的现成但不够用很多人把终端理解成一个输入命令的窗口这个理解没错但它低估了终端在真实工作流中的角色。以我自己的日常为例上午在三个微服务仓库之间切换、频繁查看几百行规模的日志、反复检索敲过一个小时的复杂 curl、同时开着两三个 tmux 会话管理不同的任务。这些操作如果用原生 bash 来做每一件事都算不上难但它们叠加在一起就非常折磨人。原生的 bash 和 zsh 其实已经具备基本的历史记录、命令补全和通配符展开能力但这些能力停留在能用的层面离好用差距很大。历史记录靠方向键上下翻找一条三天前输入过的复杂命令得翻几十次tab 补全只能补命令名和文件名补不了参数、补不了远程路径目录跳转靠 cd 一层层敲路径长一点就变成手误重灾区。OpenShell 这套方案的出发点就是把这些基础能力中的薄弱环节逐个替换成更聪明的实现而不是从零再造一个 Shell 解释器。说得直白一点OpenShell 不是要替代 bash 或 zsh而是要坐在它们上面把那些高频痛点用现代工具挨个填平。1.2 OpenShell 的核心设计原则拒绝造轮子只做整合我见过很多人的终端配置走到另一个极端——为了达到炫酷的效果堆了几十个插件启动速度慢到三秒以上每次打开终端都要等进度条走完最后因为维护成本太高又全部删掉重来。OpenShell 的设计原则跟这种思路正好相反简单说就是三句话能用一个成熟工具解决的绝不用两个能用配置文件解决的绝不动二进制能保持默认行为的绝不强行改掉。这个原则听起来有点保守但它保证了一件事整套环境不会因为你某一天更新了系统或者换了电脑就当场崩掉。OpenShell 里真正必须存在的增强模块其实只有五六个其余全都是可选的调优层。每一层都单独负责一件事互不干扰这也让排查问题变得非常容易——某个功能失灵了直接定位到对应的工具不会出现改一行配置影响另外三个模块的情况。另外还有一个容易被忽略的设计考量可复制性。OpenShell 的整套配置是纯文本的通过 dotfiles 仓库管理换机器、重装系统、甚至搬去给同事用都是十分钟之内的事。这一点在后文的实操部分会具体展开。2. 方案选型与架构拆解如何把零散增强工具整合成一套体系2.1 为什么选择工具链整合而非重写 Shell你会发现市面上确实有一些试图重写 Shell的项目比如用 Rust 或 Go 写的现代 Shell 实现。它们的思路很吸引人交互方式也更接近现代 IDE但它们有一个共性难题兼容性。生产环境里你总是会遇到老旧的 CentOS 机器、只有 bash 的 Docker 容器、别人维护的服务器这些场景下你不可能要求对方给你装一个自定义 Shell。就算你能装脚本语法、重定向、管道行为这些细节也很容易在多个环境之间产生微妙的不一致。OpenShell 选择建立在 zsh 之上、用外挂工具增强能力本质上是选择了兼容性优先。zsh 本身就是 bash 的超集语法层面基本平滑过渡而 fzf、atuin、zoxide 这些工具全是独立的二进制即使在一个比较原教旨的环境里你只需要把 zsh 配好再把几个二进制放进去整套能力就能立刻生效。这也让 OpenShell 具备了一个很务实的优势它不绑架你的工作方式。你之前怎么写脚本、怎么用管道、怎么配 cron在 OpenShell 底下一律照旧。它只是在交互层面加了更多可能性而不会强迫你改变已经成熟的命令习惯。2.2 OpenShell 的架构分层提示层、检索层、补全层、会话层在具体选工具之前我会先在脑子里把 OpenShell 拆成四个能力层每一层对应一类高频需求第一层是提示层负责让你一秒钟读懂当前状态。传统的userhost:~$提示符信息密度太低你经常需要额外敲pwd、git status才知道自己在哪、当前分支是什么。OpenShell 用 Starship 替换提示符渲染把目录、Git 分支、Python 虚拟环境、Docker 上下文、上一条命令执行耗时全部压缩进一行提示符里信息一目了然。第二层是检索层负责解决我记得敲过但找不到的问题。历史命令检索从方向键翻页升级为模糊搜索用 atuin 记录并索引完整的命令历史按下 CtrlR 之后输入任意关键词片段立刻以交互式列表的形式呈现所有匹配结果。这一层还包括文件检索——用 fzf 对文件路径、目录内容甚至 Git 变更做模糊过滤。第三层是补全层负责让 tab 键重新变得聪明。原生 zsh 的补全只做前缀匹配OpenShell 把 fzf 引入补全流程实现基于模糊匹配的智能候选过滤同时结合 bat 对预览内容做语法高亮。你在补全git checkout的分支名时不用再盲按 tab 循环直接输入几个字母模糊匹配帮你定位分支。第四层是会话层负责把终端的窗口管理升级成任务管理。通过 tmux 做底层会话管理OpenShell 在 tmux 之上封装了一套适合日常工作流的会话生命周期管理项目会话、临时任务会话、长期驻留会话各自独立互不干扰机器重启后还可以一键恢复。这四层之间没有强耦合你可以只启用其中任意一两个模块。我在后面的实操章节也会逐步演示每一层的接入方式。2.3 工具选型与取舍fzf、bat、zoxide、atuin、starship工具选型部分直接给结论后面我会逐个说明理由和场景。工具所属分层核心能力替代方案选型理由fzf检索层/补全层通用模糊过滤所有候选列表的交互核心pick、peco生态最好CtrlR、CtrlT、补全接管都能做bat检索层/补全层文件预览与语法高亮ccat、highlight高亮效果稳定支持多种主题和 fzf 配合预览极佳zoxide检索层智能目录跳转按访问频率和路径权重匹配z、autojump算法更智能支持交互式选择数据迁移成本低atuin检索层历史命令的模糊检索与同步fzf 直接搜history独立的 SQLite 存储和搜索语法比纯 shell 层面的处理更可靠starship提示层快速可定制的提示符powerlevel10k、spaceship跨 Shell 统一、渲染速度快、配置简单这里面我想单独展开说的是 zoxide 和 atuin。zoxide 是 z 命令的进化版它不只是简单记录你访问过的目录频率还会结合路径的字符串相似度做综合打分。比如你在/home/user/work/project-a和/home/user/work/project-b之间来回切换时输z project它就能精确跳到最近访问频率更高的那个。它还有个交互模式候选目录超过一个时按 Tab 弹出模糊选择列表操作上更可控。atuin 的核心价值在于它的存储设计。它把历史命令存进 SQLite 而不是传统的~/.bash_history文本文件这让检索时的性能和搜索的灵活性都大幅提升。你可以用时间段过滤、按目录过滤、按退出码过滤甚至在多台机器之间同步历史记录。我持保留意见的一个点是远程同步功能需要注册它的服务器但是我个人更建议把这些敏感命令数据留在本地方案在后文会讲到。3. 核心细节与实操作业五个让人上瘾的增强能力3.1 命令检索与历史管理换一种方式找回你敲过的命令历史命令检索是 OpenShell 里我使用频率最高的功能没有之一。传统方式下你想找回一条三天前用过的命令只有两个笨办法向上翻几十次碰运气或者history | grep去猜关键词。在 OpenShell 的架构里这个操作被完全重新设计了。第一步是把历史命令存储交给 atuin。安装 atuin 之后它会自动接管 zsh 的历史记录写入在~/.zshrc里配置好eval $(atuin init zsh)之后每敲一条命令都会在后台写入 atuin 的 SQLite 数据库。这个接管过程是透明的你原有的历史记录文件也还能用不会出现突然丢失旧历史的情况。第二步就是实际的检索交互。按下 CtrlR屏幕下方会弹出一个交互式搜索框直接输入git merge或者curl api这类关键词搜索结果会随着输入实时更新并且高亮显示匹配片段。这个搜索框支持更复杂的语法输入:dir:/home/user/work可以只看某个目录下的历史输入:exit:1可以筛出那些返回非零退出码的命令。找到目标命令之后按回车执行或者按 Tab 把它回填到命令行里继续编辑。从实操体验上来讲这一层带来的效率提升是最直观的。以前翻历史找一条命令可能要花二三十秒现在三秒内搞定。这里有一个细节要注意atuin 默认会对历史命令做去重和忽略敏感参数的处理比如把包含 token、密钥的命令文本过滤掉不记录这个功能默认启用我建议保留。3.2 模糊补全与目录跳转让 tab 键重新变聪明zsh 的原生补全已经比 bash 强不少但默认仍然采用前缀匹配逻辑——你输入cd doc永远匹配不到downloads目录。OpenShell 在这个环节把 fuzzy-match 引入进来核心变化是补全不再要求输入连续的前缀只要字符按顺序出现就可以作为匹配候选。具体实现上zsh 的补全系统通过 fzf 的fzf-tab插件进行接管在~/.zshrc里写入zstyle :fzf-tab:* fzf-preview bat --coloralways --line-range:100 $realpath之后tab 补全的行为变成按下 Tab 弹出候选列表列表由 fzf 提供模糊过滤右侧同步显示选中文件的预览内容。比如你想查看/var/log/nginx/access.log输入cd /var/log/nginx/tab候选列表弹出后继续输入acc文件立刻被定位右侧预览还能直接看到这个日志文件的开头内容不用先回车再打开。目录跳转这块主要靠 zoxide。配置好eval $(zoxide init zsh)之后cd这个命令当然还是原来的语法但你会更频繁地使用z这个快捷命令。它的语法非常随便z log、z nginx、z pro-a你不需要给出完整路径只要输入你印象里目录路径中的任意一段特征字符即可。zoxide 会根据数据库里累积的访问记录和路径相似度来综合判断你要去哪。实操中有个容易踩的坑zoxide 的记录依赖于你cd到某个目录的次数刚安装的一两天内它完全不认识你的目录结构因为数据库是空的。所以别急着删掉原来的 cd 习惯给它一个学习和积累的过程。我自己用了两周之后已经很难再打出完整长路径了。3.3 智能会话让 Shell 学会分组和断点续传不加会话管理的终端有个天然短板窗口即任务。你在窗口 A 里跑着 Web 服务窗口 B 里连着数据库窗口 C 在日志环境一旦窗口不小心关掉跑在前台的进程可能就被带走了。tmux 本来就擅长解决这个问题OpenShell 的会话层做的是把 tmux 的用法收敛成一套小组件式的操作逻辑。我的个人做法是写了一套简单的 tmux 会话管理脚本核心思想可以概括成三个命令ss new 项目名新建一个项目会话ss list列出所有会话及其窗口分布ss at 项目名进入指定会话。每个会话内部再按需分窗格比如项目 A 的会话里左窗格跑编辑器、右上窗格跑开发服务器、右下窗格留给 git 操作。这套逻辑还有一个实际好处断点续传。我经常因为下班或者切换任务把会话 detach等到第二天上班只需要ss at 项目名就把昨天的现场完全恢复——进程还在跑输出还在滚连光标位置都保存在原处。对比一下每天重新登录服务器、重新启动服务、重新切目录的旧流程省下的不只是十分钟而是大量重复性的上下文切换成本。如果觉得 tmux 的学习曲线太陡OpenShell 里也提供了简化方案只需要记住两个键位Ctrlb d临时离开会话和tmux attach回到会话剩下的高级操作可以随着使用慢慢积累。不要一开始就背全部快捷键那只会让你放弃。3.4 提示符与输出美化信息密度比好看更重要提示符的设计很有讲究但很多人把它理解成换个好看的皮肤。我用过一段时间花里胡哨的 powerlevel10k 配置各种图标、各种颜色区块视觉上确实过瘾但它对我的实际效率几乎零提升反而因为图标太多在 SSH 到旧机器上时经常乱码。OpenShell 的提示符选择是 Starship它的核心理念是信息密度优先。默认配置下提示符从左到右依次显示当前目录、Git 分支及脏状态、软件版本管理工具的上下文、上一条命令的执行耗时。这些信息全部由 Starship 根据实际情况动态渲染没有多余的装饰。举一个真实场景我在一个 Python 项目里用 Docker 跑服务之前的提示符完全看不出当前 Shell 是不是在虚拟环境中。Starship 的默认配置里如果检测到VIRTUAL_ENV环境变量就会自动在提示符上显示当前虚拟环境的名称检测到DOCKER_CONTEXT就会显示当前 Docker 上下文。这意味着我不需要额外敲命令就能随时确认我现在操作的是哪个环境。信息密度高不代表视觉上一定要拥挤。Starship 的配置里可以通过format字段精确控制每个模块的显示顺序和显隐条件比如非 Git 仓库目录下就完全不渲染 Git 模块整条提示符非常干净。我强烈建议花十分钟读一下 Starship 官方配置文档按自己的高频需求定制一次这个收益能持续很久。值得一提的是Starship 的渲染速度很快不会像某些老牌提示符框架那样每敲一个命令都要等几百毫秒。它的核心二进制用 Rust 编写在性能上的优化是肉眼可感知的。4. 从零搭建一套 OpenShell 环境完整实操记录4.1 环境准备与依赖安装在动手搭建之前先把工具链准备利索。以下步骤在 macOS 和主流 Linux 发行版上都能用差异只在包管理器这一层。macOS 用户安装 Homebrew 之后运行brew install zsh fzf bat zoxide atuin starship tmux一条命令装齐全部核心依赖。fzf 装完后会有一个交互式后缀说明提醒你执行$(brew --prefix)/opt/fzf/install来生成键位绑定脚本这一步需要做。Linux 用户以 Ubuntu/Debian 为例sudo apt install zsh fzf bat zoxide tmux其中 bat 的包名可能是batcat需要建立一个bat的符号链接ln -s /usr/bin/batcat /usr/bin/bat。atuin 和 starship 官方提供了安装脚本curl --proto https --tlsv1.2 -sSf https://sh.atuin.sh | sh和curl -sS https://starship.rs/install.sh | sh这里有一个容易出问题的点zsh 在多数系统里不是默认 Shell。装完 zsh 后需要用chsh -s $(which zsh)切换默认登录 Shell。切完之后最好开一个新的终端标签页测试确认echo $SHELL输出的是/bin/zsh或者对应路径再继续下面步骤。如果这一步跳过后续所有配置都会加载不到。4.2 五步完成基础接入依赖装好之后接下来就是把各模块接入 zsh 启动流程整体过程可以归纳为五步。为方便说明我会用.zshrc里的典型配置片段做示范但完整可迁移的配置建议放到 dotfiles 仓库里管理。第一步设置 zsh 的基础选项。这里我建议至少开启这些行它们能显著提升原生体验setopt AUTO_CD # 输入目录路径自动进入 setopt AUTO_PUSHD # cd 自动压栈 setopt HIST_IGNORE_ALL_DUPS # 历史记录忽略重复命令 setopt HIST_IGNORE_SPACE # 行首空格的命令不进历史第二步接入 fzf 和它的键位绑定。fzf 安装时生成的脚本可以帮助你快速给 Shell 增加 CtrlR 检索历史、CtrlT 检索文件路径、AltC 跳转目录三个交互入口。把以下配置写进.zshrcsource (fzf --zsh) export FZF_DEFAULT_COMMANDfd --type f --hidden --follow --exclude .git export FZF_DEFAULT_OPTS--height 40% --border --preview-windowright:60%第三句里的fd是一个更快更友好的 find 替代品如果你没有安装可以退回到系统自带的find但检索体验会差一些建议顺手装一个brew install fd或者apt install fd-find。第三步接入 bat 作为文件预览工具。bat 本身就是cat的增强版开箱即有语法高亮和行号。fzf 的预览窗口可以直接调它export FZF_CTRL_T_OPTS--preview bat --coloralways --line-range:100 {} export FZF_ALT_C_OPTS--preview ls -la {}第四步接入 zoxide 和 atuin。这两块的配置同样简单关键在顺序上应该放在 fzf 之后因为 zoxide 的交互模式经常复用 fzf 的渲染层eval $(zoxide init zsh) eval $(atuin init zsh)第五步接入 Starship 提示符并在 .zshrc 的最后让它接管提示符渲染eval $(starship init zsh)完成以上五步后重启终端正常情况下你已经拥有了一套增强型的 Shell。这时的直观感受是提示符变丰富、CtrlR 的交互完全不同、cd 之外可以自由使用 z 跳转。不用一次性写完所有配置先把这五步走通再逐步根据自己的工作场景加细节。4.3 踩坑记录与调优延迟、兼容、字体三座山基础配置完成后大概率会遇到的三个问题值得单独拿出来讲它们几乎是每个搭过这套环境的人都要翻过的坎。第一个坑是启动延迟。zsh 的启动延迟是个玄学问题因为插件和框架会在每次打开终端时做大量初始化。OpenShell 的模块大多是独立二进制理论上启动开销应该可控但如果你发现打开终端明显卡顿可以用time zsh -i -c exit测一下具体耗时。我自己的优化结论是把所有会导致阻塞的加载项全部移除或延迟化比如不要在.zshrc里同步加载太多体积大的补全函数改用按需补全。另一个提升明显的做法是把默认补全系统换成更轻量的实现或者对不常用的补全定义做autoload -Uz X惰性加载。第二个坑是命令兼容性。很多第三方工具在 Linux 和 macOS 上的二进制名不一样比如 Linux 下 bat 叫batcatfd 叫fdfind。我在.zshrc里用判断语句统一了符号链接建议你也做一个同名链接否则后面写配置时容易因为名字不一致而栽跟头。还有 fzf 的--zsh子命令是较新版本才加入的版本过旧的话要用source /usr/share/doc/fzf/examples/key-bindings.zsh这种传统方式加载。第三个坑是字体乱码。这里主要指 Starship 和 fzf 预览窗口可能出现的合成字符显示异常。解决思路很干脆终端软件和主题都换成支持 Nerd Font 的字体。我自己用的是 MesloLGS NF在 iTerm2 里设置为默认字体后Starship 的分支图标、各种状态点才显示整齐。如果你的终端仍然出现豆腐块或者问号请优先检查终端字体设置而不是工具本身。5. 常见问题与排查技巧实录5.1 各模块失灵时的排查速查表基于我自己和其他使用者经常反馈的问题整理了一张排查速查表按照现象→原因→解法的结构来看效率最高现象常见原因解决方案CtrlR 弹出的是原生反向搜索而非 fzf 界面fzf 键位绑定脚本未加载或 .zshrc 顺序不对确认source (fzf --zsh)在eval $(atuin init zsh)之前z 命令跳转结果反应迟钝zoxide 数据库积累不足正常使用一周数据量上来后准确度显著提升bat 预览大量报错无法高亮系统中 bat 符号链接不存在按 4.1 建立 bat 链接或者直接用 batcat 替换配置中的命令名tmux 窗口内提示符样式丢失tmux 的$TERM环境不匹配在 tmux 中执行set -g default-terminal screen-256color或者使用 tmux-256colorStarship 图标显示为乱码终端字体不支持 Nerd Font更换终端字体或关闭 Starship 中的 symbol 模块新开终端历史记录为空atuin 接管写入但未触发 init确认eval $(atuin init zsh)存在并检查~/.local/share/atuin目录是否有数据库文件环境迁移到新机器后快捷键失效dotfiles 同步不完整用 git 管理全部配置确保.zshrc、.tmux.conf、.config/starship.toml都纳入版本控制5.2 定位与解决 zsh 启动慢的完整案例启动慢这个问题的排查过程很有代表性值得展开讲一遍。有段时间我打开新终端总感觉有半秒的停滞用time zsh -i -c exit测出来耗时 780ms属于能感知但又不至于让人崩溃的水平。接下来我用 zsh 的zprof模块做性能分析在.zshrc顶部写入zmodload zsh/zprof底部写入zprof打开终端后就能看到函数级耗时分布。分析结果显示最大头不是 OpenShell 的几个模块而是我自己之前装的一个补全增强脚本占了接近 300ms。移除这个脚本并改用更轻量的补全方案后启动时间降到了 180ms 左右。这个案例说明两件事一是排查问题要用工具而不是凭感觉二是冷启动耗时很多时候来源不是你最近加的功能而是历史遗留的某个不起眼的配置。5.3 数据同步与团队复制的注意事项最后聊一下 OpenShell 配置的同步问题。很多人在自己机器上把环境调好之后会遇到换了一台新电脑怎么把环境搬过去的困惑。我的实践方式是维护一个 dotfiles 仓库把.zshrc、.tmux.conf、.config/starship.toml、.config/fzf等关键配置文件全部纳入版本控制同时写了一个setup.sh脚本用于在新机器上自动创建符号链接。因为 OpenShell 的设计原则里就没有引入任何需要登录云账号的组件atuin 的同步我特意关掉了所以这套迁移过程完全不依赖外部服务只要新机器能装好依赖、拉下仓库十分钟内就能回到旧环境的工作状态。对于团队场景我更建议把 OpenShell 的配置作为一个可选增强包而不是强制标准存在。有人喜欢极简终端有人习惯 vim 模式强行统一反而增加摩擦。把它做成一个可以在几分钟内启停的配置模块谁想用就 clone 一份跑 setup 脚本随时可以卸载这样才是可持续的推广方式。6. 扩展玩法让 OpenShell 进一步贴近你的工作流6.1 为 OpenShell 加上工作流记忆基础模块跑稳之后我强烈建议做的一件事是为 Shell 增加工作流记忆能力。这里的记忆指的不是通用的历史记录而是针对特定项目或任务的上下文自动加载。举个例子我的一个习惯是给每个项目目录放一个.oprc文件里面声明了这个项目常用的别名和环境变量。比如进入/home/user/work/api-server目录时自动加载alias devnpm run dev -- --port 3001、alias logtail -f ./logs/app.log这类项目专属命令。实现方式很简单在 zsh 的chpwd钩子里添加一个逻辑当进入目录时检查目录下是否存在.oprc文件存在则 source 它退出目录时自动 unset 相关别名。这套机制的好处是终端记住了你在哪个项目里并且主动把对应的操作方式提供给你。不需要在全局.zshrc里堆积所有项目的别名也避免了多个项目之间同名别名互相污染的问题。6.2 把重复性工作封装成会话模板另一个实用扩展方向是把固定流程做成 tmux 会话模板。比如我有个日志分析模板创建会话时会自动开两个窗格左边窗格执行tail -f /var/log/app.log | bat -l log右边窗格打开工作目录并预填好常用 grep 命令提示。这比每次手动切目录、敲尾命令快得多。具体落地不复杂在 OpenShell 的配置目录里放一个session-templates文件夹用脚本读取模板定义并透传给 tmux 的new-session和split-window指令。关键点是让模板可配置而非硬编码这样别人拿到配置后改一个文件就能适配自己的项目路径。6.3 结合 LLM 的语法辅助可选实验项最后说一个我自己还在实验阶段的玩法把自然语言转命令的能力浅接入 OpenShell。通过一个本地脚本把输入的自然语言请求发送给本地语言模型接口将模型返回的命令草稿回填到命令行中再由用户确认执行。这个方向的选型和实现细节都还比较早期但它有一个天然契合点OpenShell 的授权模型是工具永远是辅助最后由人来决定。语言模型负责把我想看看 nginx 最近 100 行日志里有多少 5xx 状态码翻译成一条命令草稿但执行权和确认权仍然在用户手里。这种辅助而非替代的思路和 OpenShell 整体的设计哲学是完全一致的。如果你对这个方向有好奇心可以先从本地小模型开始尝试注意控制好数据隐私边界不要直接把终端输出全部喂给模型接口。最后分享一点我这几年折腾终端环境的真实体会。很多人把 Shell 配置当成一种技术宅的玩具花大量时间调外观、堆插件最后真正提升效率的其实就那几个高频操作。OpenShell 这套方案对我最大的改变不是看起来更酷了而是从和终端搏斗变成了让终端听指挥——历史检索、目录跳转、会话恢复这些能力融进肌肉记忆之后我经常在敲完一条命令的瞬间才意识到这个动作在以前要多花好几倍的时间。如果你也想尝试我的建议是不要一次到位先把 CtrlR 的模糊检索和 zoxide 的目录跳转这两个模块配起来用一周亲身体验过一次之后你自然会有继续折腾的动力。