
最近后台收到不少朋友留言搜索词里一直带着 superpowers。我一开始以为是某个新出的 App点进去发现好多人都在问“想要安装 superpowers”。说实话superpowers 这个词在开发圈里更像一种“状态”而不是一个固定的软件——它指的是“把顺手的工具组合起来让工作效率突然变强”的那种感觉。我自己很早就开始折腾这套东西甚至直接把个人开发环境命名为 superpowers一个集合了 zsh、模糊搜索、快速跳转、终端增强和 AI 辅助的工作流。今天这篇就是把我搭建这套环境的过程、选型理由和踩过的坑完整地摊开来讲一遍。如果你刚入行照着配下来能让你的终端操作顺畅很多如果你写了很多年代码也可以看看我在工具组合和工作流设计上的取舍。我的目标很简单打开一个项目不超过 3 秒搜索文件不离开终端git 常规操作一串命令搞定遇到报错有人能帮我快速解读。1. 先搞清楚 superpowers 到底要解决什么问题1.1 为什么“安装 superpowers”是个容易让人误解的词网上搜 superpowers至少能搜出好几种同名东西有开源游戏引擎有浏览器扩展有各种叫这个名字的库。如果你只想装某个具体软件第一步应该是先确认它的官方网站而不是直接在搜索框里凭名字找。我自己对 superpowers 的理解更“个人化”它不是某个单一程序而是一整套被命名成 superpowers 的开发环境配置。这就像一个厨师说自己的“秘密武器”不是某一把刀而是整个厨房动线的设计。终端环境也一样单独看每个工具都很普通但当它们被串起来、互相配合时那种“想干什么敲一下就出来了”的感觉才配叫 superpowers。1.2 我给 superpowers 设定的四个目标在动手安装任何工具之前我先写了一句话这套环境必须能减少重复操作并且让所有高频动作在键盘上完成。具体拆成四条快速打开项目不用一层层 cd输入项目名就直接跳进去。快速找文件按名字模糊搜索不依赖鼠标和 IDE 左侧的文件树。快速读结果cat 文件、看日志、查命令用法输出要有高行号、高亮、易读。快速记命令历史的、常用的、写过的命令搜得到、能复用。这四个目标决定了后面所有工具的选择。凡是满足不了的哪怕再流行我也不会装。1.3 值与不值先算一笔时间账有人会问花一两个小时配置终端到底值不值我算过一笔很朴素的账。手头操作配置前大致耗时配置后大致耗时每天大概次数切目录到项目5 到 10 秒1 到 2 秒20 次找文件并打开8 到 15 秒2 到 4 秒15 次查一条命令用法15 到 30 秒3 到 5 秒5 次git 提交并推送15 到 20 秒5 到 8 秒5 次每天节省的时间加起来看着不多但累计到一周、一个月是非常可怕的数量。更关键的是操作中断越少心流状态越不容易被打断。这比省下的几秒更有价值。2. 选型与准备核心工具组合为什么这么配2.1 终端与 Shell先决定底座superpowers 的底座我选的是 zsh 加 oh-my-zsh。macOS 自带 zshLinux 装一下也不难Windows 上我建议用 Git Bash或者直接用 Windows Terminal 配 WSL。不要一上来就纠结用什么终端模拟器先把 shell 换成 zsh界面手感再说。oh-my-zsh 的价值不是它自带了多少东西而是生态成熟、插件管理和主题体系完整。我的经验是主题选最简洁的插件默认够用后面只做减法。2.2 包管理器统一安装入口接下来需要一个统一的安装入口不然每个工具都有不同的安装方式管理起来会很痛苦。macOS 上我习惯用 HomebrewWindows 上可以用 ScoopLinux 发行版用系统自带的 apt 或 dnf 就行。统一包管理器之后卸载、升级、查看已装工具都变成一条命令。这也是很多人容易忽略的一步安装工具之前先确定包管理器否则环境会变成一团乱麻。2.3 选型对照这些工具解决的是同一件小事我的原则是一个痛点只选一个主力工具不给系统塞太多功能重叠的软件。下面是我最终的选型工具解决的问题我选它的理由常见替代方案fzf模糊搜索文件、历史命令支持正则和预览窗口和终端深度绑定ctrlr、pecozoxide智能目录跳转基于访问频率学习跳转准确且轻量autojump、fasdbat查看文件内容自带语法高亮、行号、git 变更标记cat、lesstldr快速查命令示例简明扼要比 man 手册更贴近实际使用man、cheatghGitHub 工作流管理直接命令行发 PR、看 issue减少上下文切换hub、git 原生表格里每一行都是奔着 1.2 节的目标去的。fzf 和 zoxide 解决“快速进入项目”bat 和 tldr 解决“快速读结果”gh 解决“git 常规操作不再手忙脚乱”。选型的关键不是“哪个工具最厉害”而是“哪个工具跟我的工作流最咬合”。3. 安装与配置一套可以直接抄走的终端组合3.1 分平台安装三分钟装完整套工具先装基础工具。以 macOS 为例一条命令能装完大部分brew install fzf zoxide bat tlrc ghLinux 下的对应命令sudo apt install fzf bat curl -sS https://raw.githubusercontent.com/ajeetdsouza/zoxide/main/install.sh | bash cargo install tlrcWindows 的 Scoop 用户scoop install fzf zoxide bat tldr gh安装完成后立刻验证一遍which fzf zoxide bat tldr gh如果能全部输出路径说明装齐了。这里有一个很多人踩过的坑装完 fzf 后没有运行它的初始化脚本导致 CtrlT 无效。等下配置 zshrc 的时候我会一并写进去。3.2 fzf 配置让搜索默认走全项目fzf 的性能和默认值已经不错但要成为超级工具还得让它默认搜索整个项目、包括隐藏文件。我在配置里加了这样一段export FZF_DEFAULT_COMMANDrg --files --hidden --follow -g !.git这样做的好处是搜索时不会受.gitignore影响能搜到隐藏文件和忽略列表外的内容。--hidden是包含点开头文件--follow是跟随符号链接-g !.git是把 Git 目录排除在外。如果机器上没装 rg也可以退而求其次用 findexport FZF_DEFAULT_COMMANDfind . -type f 2/dev/null | grep -v .git但要说明白rg 的性能和规则解析能力都是最优解建议先brew install ripgrep。3.3 zoxide 配置让 cd 不再是盲跳zoxide 的原理是记录你访问过的目录并给它们打分。配置也非常简单eval $(zoxide init zsh)之后想跳转到某个目录只需要输入目录名的一部分z myproj它会自动把你带到访问频率最高的“myproj 目录”。如果同一名字有多个目录可以用z projA projB这种组合方式缩小范围。注意在脚本里别直接用z因为它是交互式函数非交互 shell 环境里可能不会加载。脚本场景应使用zoxide query。3.4 bat 与 tldr让命令输出也赏心悦目cat 的输出是纯文本看日志和代码时眼睛很累。我把cat直接替换成batalias catbatbat 默认自带语法高亮、行号还能显示 git 的增删标记。再配合主题配置export BAT_THEMESolarized (dark)这个主题在大多数终端下都不会刺眼。查命令用法时tldr 比 man 更能救急tldr git commit它会先给出最常见的用法和示例而不是一整篇全量文档。我把它取了一个更顺手的名字alias htldr3.5 汇总配置片段改完直接能用把所有配置整理到~/.zshrc的最下面加一段注释分区分隔开# superpowers 配置开始 export FZF_DEFAULT_COMMANDrg --files --hidden --follow -g !.git export BAT_THEMESolarized (dark) eval $(zoxide init zsh) alias catbat alias htldr # fzf 默认快捷键 source (fzf --zsh) # superpowers 配置结束 保存后source ~/.zshrc生效。这时测试 fzf 的 CtrlT、CtrlR如果发现按键没反应优先检查是不是没启动 fzf 的 shell 集成。在最新版 fzf 中这一行已经开始建议用source (fzf --zsh)老版本则是$(fzf --zsh)这两种写法我都试过新版更稳定。4. 从“工具”到“工作流”自定义命令与自动化4.1 先看我原来的操作长什么样工具装好只是第一步。真正让 superpowers 成为体系的是把它们串成工作流。我先描述一个非常典型的场景我想打开/Users/me/work/projects/blog下的一个 Markdown 文件先要 cd 到项目目录再用 ls 找到文件名再用 cat 打开中途可能还得查一下刚才用过的一个 git 命令。这一串动作大概要敲四五条命令而且每条都得等上一步的输出。我想要的是一步到位。于是我给 superpowers 写了一组自己的 shell 函数。4.2 自定义函数把三步并成一步我在.zshrc里定义了五个高频函数现在它们已经成为我每天离不开的东西。# 快速进入项目目录proj 项目名 proj() { local name$1 local dir dir$(zoxide query -- $name) || return 1 cd $dir || return 1 echo 已进入 $dir } # 新建项目目录并初始化 gitnewproj 名称 newproj() { local path$HOME/work/projects/$1 mkdir -p $path cd $path git init -q echo # $1 README.md echo 项目已创建$path } # 一键 git 提交并推送gg 提交信息 gg() { git add -A git commit -m $1 git push } # 查看今天的改动当我需要快速回顾当天工作 glog() { git log --sincemidnight --oneline --author$(git config user.name) } # 快速搜文件内容找关键词就一条命令 ftext() { rg -n --hidden --no-ignore $1 . -g !.git }这些函数的共同点把多个动作合并成一个并且每一步都有安全兜底。比如proj里如果 zoxide 找不到目录就返回 1而不是继续往下执行导致进入错误路径。4.3 别名表高频命令减半除了自定义函数别名也能解决不少重复劳动。下面是我目前最常用的别名表别名展开后的命令用途catbat高亮查看文件lsexa --long --git带 git 状态的列表htldr查看命令示例gaagit add --all暂存所有改动gcmgit commit -m快速提交glgit log --oneline --graph看分支图gpgit push推送clclear清屏给别名取名字也有技巧一定要短而且连续按起来顺手。我见过有人把 git 提交的别名设成gcommit结果每次敲起来比原命令还费劲。aliases 的价值是减少击键次数不是增加记忆负担。4.4 自动化脚本让新项目初始化变成一条命令真正让我觉得“有了 superpowers”的是newproj这个函数。以前新建一个项目要手动建目录、init git、写 README、打开编辑器现在一条命令全搞定。我甚至还在版本迭代中把它扩展了一下加上自动打开当前编辑器的行为以及把上下级目录关系打印出来。比如想要创建一个带 Python 项目结构的模板newpy() { local name$1 mkdir -p $name/src $name/tests cd $name git init -q printf def main():\n pass\n\nif __name__ __main__:\n main()\n main.py echo Python 项目 $name 已创建 }这类脚本不用很复杂核心目标是把项目创建流程固化下来保证每次创建的结构一致。团队协作时这也是一种不错的“默认规范”。5. 更进一步让 AI 助手成为 superpowers 的增强层5.1 为什么我选择本地模型而不是云端接口AI 辅助是我后加进去的一块。现在很多终端工具都有 AI 功能但我不太想每个命令都走一次云端接口。所以我选了本地运行模型的方案用 Ollama 跑一个小体量模型专门负责解释报错、写脚本片段、生成提交信息。数据不出本地速度还快而且模型文件由我控制不会今天更新明天变样子。5.2 用 Ollama 搭一个终端报错解释器装 Ollama 的方法很简单macOS 和 Windows 都提供了安装包Linux 环境下也可以直接用官方脚本。装好后拉一个轻量模型ollama pull llama3.2:1b然后我写了一个 shell 函数让它处理终端报错aie() { local prompt请用中文解释下面这个报错给出可能原因和修复建议 local error$ echo $prompt\n$error | ollama run llama3.2:1b }以后遇到报错不再急着复制整段日志去搜索引擎而是直接aie fatal: not a git repository它会给出一段清晰的解释。这个能力在刚起步阶段极其好用因为很多新手卡住的根本不是解决方案而是不知道报错在说什么。5.3 AI 在什么环节真正帮到了我用了一阵之后我发现 AI 在三个场景最有价值报错解释这是最强的场景相当于给我安排了一个随叫随到的旁边老哥。常用脚本生成比如“写一个 bash 函数找出三个月没有修改的文件”生成完我审一遍再跑。git 提交信息生成把git diff的输出喂给它让它总结成一句提交信息。其他场景比如让它优化复杂算法我的态度是宁愿自己读代码。因为在核心业务逻辑上模型给的建议不一定理解上下文盲信反而危险。5.4 注意AI 不是 superpowers 的全部AI 加持后的 superpowers 确实很爽但我慢慢意识到工具的边际效益是有上限的。当环境已经足够顺手真正拉开差距的是你对自己技术栈的熟悉程度而不是又多装了一个插件。所以我后来给 superpowers 加了一条“使用宪法”辅助可以替代判断不行。生成的内容要能看懂、能验证才让它进入最终的代码库。6. 30 天实测踩过的坑与完整的排查思路6.1 快捷键冲突fzf 和自动建议打架怎么定位配置完第二天我按 CtrlT 想搜文件结果终端没反应。我先怀疑 fzf 没加载重新 source 也没用。后来我用bindkey | grep ^查看所有快捷键绑定发现自动建议插件把 CtrlT 占掉了。定位到冲突后处理方式有三种改 fzf 的快捷键、改自动建议的快捷键、或者干脆停用其中一个插件。我选择把 fzf 的搜索键整体改掉# 把 fzf 的文件搜索绑定到 CtrlF bindkey ^F fzf-file-widget这类问题的排查思路是一套固定流程先复现再查绑定再改配置最后验证。不要一上来就删插件那会掩盖真正的原因。6.2 启动变慢给插件做减法配置到第三周我发现每次打开终端都要等 1 秒多。排查方式很简单先注释掉.zshrc里的配置一段一段二分测试。最后定位到几个大插件拉慢了启动。我把 oh-my-zsh 的插件列表从 12 个砍到 5 个启动速度直接从 900ms 掉到了 300ms 左右。我的经验是每加入一个插件都要问自己它解决的那个痛点我是不是真的在用。不是的工具和插件一律不要留在配置里。6.3 脚本环境里的隐性坑zoxide 和 fzf 的非交互模式有次我在一个自动构建脚本里调用了z命令结果脚本报错。原因是脚本环境中 zoxide 的 shell 集成没有加载。解决方案很简单脚本内部改用zoxide query或者先显式source一下初始化脚本。fzf 也有类似问题在管道中调用fzf时预览窗口里的颜色设置可能跟主终端不一致。要避免输出乱码需要在.zshrc里显式声明$TERM和$CLICOLOR或者给 fzf 单独指定预览窗口的配色。6.4 跨设备同步用 dotfiles 把配置管理起来最后我要强烈建议把这套环境纳入版本管理。我自己把所有配置放在一个dotfiles仓库里用 git 管理然后在不同机器上 clone 下来用符号链接指向~/.zshrc、~/.config等位置。这样做的收益很明显换电脑之后一条命令就能把整个 superpowers 环境复原。不过我踩过的坑是不同平台的配置不能完全共用。比如 Linux 的 bat 包叫batcat而 macOS 直接叫batGit Bash 底下有些命令又不兼容。我后来在配置里加了一层系统判断才真正做到一套配置随处跑。if [[ $(uname) Linux ]]; then alias batbatcat fi我现在的 superpowers 已经很稳定不会再频繁往里面加东西。回想整个过程最值钱的不是某个具体工具而是那套“先想清楚痛点、再选工具、最后串成工作流”的思路。最后分享一个小技巧配置里任何一个自定义函数、别名都要写一行注释说明它解决什么问题。不然三个月后你回来看自己的配置会完全想不起来当时为什么这么写。保持少而精、可解释、可回滚这样的 superpowers 才真正值得长期依赖。