说实话，刚开始听到别人把一套工具组合称为“superpowers”时，总觉得这词更像是营销话术。直到某个周五下午，我盯着自己重复操作了一周的批处理任务，突然意识到：所谓超能力，不过是把高频、耗时、容易出错的重复动作，压成一条命令、一个快捷键、一段脚本。这篇文章想聊的，就是我这几年攒下来的一套个人效率工作流——从终端、编辑器到自动化脚本，再到更底层的注意力管理。不追求“酷”，只追求能真正减少返工、减少等待、减少脑子来回切换的实用方案。无论你是刚入行的新手，还是被琐事缠身的资深从业者，都应该能从里面挑出几件立刻能用的东西。
1. 为什么我们需要一套“效率超能力”：先从底层认知说起
1.1 多数人的效率瓶颈不在手速，而在决策成本
我见过很多朋友把“效率低”归结为“手慢”，拼命练习打字速度、快捷键，但真正拖垮他们的通常是另一件事：决策成本。
每次在命令行输入一段冗长命令前，你需要回忆命令格式；每次弹出文件管理器，你要思考文件放哪了；每次启动一个新项目，你要重新决定用什么模板、装哪些包。这些看起来只有几秒钟的“小决策”，一天累积几十次，大脑的认知资源就被悄悄耗光了。超能力的本质，就是把这类决策提前固化：让工具替你记住规则、替你记住路径、替你完成拼接。你只需要在最开始花一次时间把规则写死，之后每次触发都是零思考。
1.2 把“技能清单”升级为“能力模型”
很多人收集了一堆工具清单，收藏夹里有几十篇“效率神器推荐”，最后却一个都没用起来。问题在于他们把工具当成了“收藏品”，而不是“能力拼图”。
我自己的判断标准很简单：如果这个工具不能在我每周的工作里至少出现三次，它就不值得安装；如果它出现超过三次，我就必须为它写一个小结文档。这让我从“看到什么学什么”变成了“从一个完整工作流倒推需要什么”。比如我发现自己在写代码阶段总在“改格式—跑测试—看日志—再改”之间打转，于是依次配好了格式化插件、测试监听模式、日志过滤脚本。每一步都是被实际痛点逼出来的，不是被营销文章安利的。这套打法，才是把零散技巧拧成“superpowers”系统的关键。
后面五个章节，我会按这个思路，把我目前在终端、编辑器、自动化脚本和注意力管理四个维度上真正沉淀下来的东西，一个个拆开讲。每块都会解释“为什么这么选”，而不只是丢给你一堆命令。
2. 终端就是第一块训练场：我把命令行打造成了超级面板
2.1 基础三件套：zsh、direnv、tmux的搭配逻辑
先解释一个关键点：终端效率的核心不是某个单品，而是三件工具各自解决不同层面的状态管理问题。
- zsh负责“交互体验”：补全更聪明、提示符更友好。我建议不要一上来装整套oh-my-zsh，先装zsh-autosuggestions和zsh-syntax-highlighting两个插件就够了，保持启动速度在200毫秒以内。插件等于变量名一样，名字长会击中显现判断。
- direnv负责“环境记忆”：每个项目都有自己的环境变量，比如不同项目的Python虚拟环境路径、云厂商密钥、API地址。以前我每次切换项目都要手动source一堆配置，偶尔忘记就出现“在我电脑上明明是好的”。有了direnv后，只要进入项目目录，它自动加载对应的.envrc文件；离开目录，自动卸载。这等于把“项目上下文”直接绑定到了文件夹上，大脑完全不用记。
- tmux负责“会话保持”：我长期开着几个tmux窗口，分别跑日志、跑测试、跑服务器。即使SSH断开、电脑重启，重新连上后一切还在。tmux的prefix key我设置为Ctrl+a，避免和终端默认快捷键冲突。这个配置帮我省掉了无数次“重新启动一切服务”的返工。
这三件套的搭配逻辑是：zsh提升单次敲命令的速度，direnv消除切换项目的记忆成本，tmux解决长任务的状态延续。真正用起来之后，我可以在30秒内从一个项目的开发环境完整切到另一个项目，中间不需要翻笔记、不需要回忆路径。
2.2 搜索、跳转、历史记录：三类最值得投入的命令行工具
如果说上面三件套是“骨架”，下面这几件就是“肌肉”。我筛选它们的标准只有一个：能不能减少我一天里最高频的那三类操作——找文件、找内容、找历史。
第一类是文件跳转。我用zoxide替代了裸的cd命令。它会在后台记录你经常访问的目录，之后输入z doc就能跳到/Users/me/work/projects/documentation这类长路径。配合FZF（fzf的模糊查找器），我还可以快速列出最近访问的目录并模糊筛选。这里的细节是：zoxide是按“访问频率”排序的，不是按“最近访问”，所以那些天天要用的项目路径几乎总是排在前面。
第二类是内容搜索。我推荐ripgrep（rg）而不是老牌的grep，一个很朴素的原因：它快得多。我的代码仓库动辄几万个文件，rg能在几百毫秒内返回结果，而且默认忽略.gitignore里的文件，不会搜出一堆依赖包内容。实际用法上，最常用的是在某个目录里搜一段最近改过的函数名或报错关键词：
rg "request_timeout" src/如果只是找文件名，那就用fd——它就是find命令的现代替代，语法更短、默认更合理：
fd "config" ~/work第三类是历史记录。我通过FZF给Ctrl+R绑定了一个模糊搜索历史命令的窗口。默认的history | grep需要先猜关键词，而模糊搜索只需记得命令里任何一个片段，比如direnv、migrate，选中后回车即用。这一套下来，“找文件、找内容、找历史”这三类高频操作都被压到了几秒钟内，基本不需要打开VSCode自带的全局搜索。
2.3 关于别名与函数的一点私房经验
很多人给命令配了大串别名，最后自己都记不住。我的经验是两条：
- 别名只保留“三个字符以内、一天用很多次”的命令。比如
g代表git status，gp代表git push，l代表ls -lah。超过三个字符的缩写，记忆负担会明显上升，不值得。 - 稍复杂的操作，我倾向于写成shell函数并加上注释，而不是硬挤在一行别名里。
举个例子，我经常需要查看某个服务最近是否正常启动，这个操作在多个项目里重复出现，我就写了个函数：
# 查看指定服务的最近日志，支持关键词过滤 function svlog() { if [ -z "$1" ]; then echo "用法: svlog <服务名> [关键字]" return 1 fi if [ -z "$2" ]; then tail -n 100 "logs/$1.log" else tail -n 100 "logs/$1.log" | grep "$2" fi }写成函数而不是别名，好处是可以用if做参数判断、写使用提示，还可以放到dotfiles仓库里统一版本管理。当函数数量超过十个，建议按模块拆分到不同文件，别让~/.zshrc膨胀成一个两千行的大杂烩。
3. 编辑器里的“加速外挂”：优雅地减少重复操作
3.1 把光标移动和文本选择练成肌肉记忆
如果说终端是“外部操作的加速器”，编辑器就是“思维到代码的直通车”。大多数编辑器用户的高频操作是：把手从键盘挪到鼠标，选中一段代码，再挪回键盘。这个小动作看似不起眼，但每次都会打断思路。
我在VSCode里装了Vim插件，把光标移动、文本选择、窗口跳转都改成了纯键盘操作。这里想给新手的建议是：不需要学完整个Vim，只练五个核心动作就够回本了。
w、b：按词移动光标0、$：跳到行首、行尾f+ 字符：光标移动到当前行的某个字符上/+ 关键字：文件内搜索并跳转v+ 方向键（或V选了整行）：可视化选择文本，选中后按d删除、按y复制
这几个动作练熟后，我发现“选中并复制一段500行的代码”这类操作不再需要鼠标，几秒钟就能完成。肌肉记忆的养成确实需要一周左右的不适应期，但之后就再也回不去了。
3.2 多光标与宏：同一件事不用做第二遍
比起Vim移动，更立竿见影的是多光标和宏。很多人在编辑一个文件时，会遇到“给120行代码的每一行末尾加逗号”这种操作。一行一行改显然太蠢，正则替换又容易误伤。此时多光标是最好的解法：
- 按住
Option键（macOS）或Alt键（Windows）点击，可以在多个位置同时生成光标 - 更通用的方式是：
Ctrl+Shift+L选择当前所有匹配的单词，然后同时编辑 - 如果只需要逐个挑选，用
Cmd+D（macOS）或Ctrl+D匹配下一个，遇到不想要的再按一次Cmd+K跳过
宏的功能则更适合“模式更复杂”的场景。比如一个文本里有多行格式不统一的数据，你想把它们都改成某种固定格式。录宏的步骤一般是：
- 在文件开头按
q加任意字母（比如qa）开始录制 - 手动操作一次完整的替换流程：复制字段、格式化、跳转
- 按
q结束录制 - 按
@a回放宏，再按120@a一次性执行120次
我自己的体会是：宏适合“同一个动作要重复5次以上而且不好用正则表达”的场景。一旦录好，可以把常用宏保存成一个Snippet或键位绑定，下次直接触发。比起重复劳动，录宏那10分钟的时间投入，其实是对未来自己的一种投资。
3.3 快速跳转与全局搜索：别让鼠标打断心流
编辑器里最耗心智的，其实是“在多个文件之间来回切换”。很多项目文件结构很深，光靠侧边栏点开点去，一天下来光路径记忆就要耗费不少脑细胞。
我目前的组合是：
- 用
Cmd+P（macOS）或Ctrl+P快速打开文件，模糊匹配文件名，不需要记住完整路径，只要记得文件名的几个字母。这条几乎全行业通用。 - 用
Ctrl+Shift+F做全局搜索，配合正则替换。注意这里有个实用技巧：先在搜索框里输入一段足够特征化的关键词，确认搜索范围正确，再点“替换”。很多人一上来就直接替换，结果把一个通用单词全局替换成了错误逻辑，追悔莫及。 - 用VSCode自带的“面包屑”导航和
Go to Symbol in File...（Ctrl+Shift+O）在当前文件里跳函数定义。
这些操作都指向同一个目的：减少鼠标寻路和视觉搜索的时间。当你的手不需要离开键盘，思路就更容易连续。
4. 自动化脚本：真正拉开差距的“超能力”
4.1 识别高价值自动化目标的三条原则
终端和编辑器解决的是“操作层面的加速”，而自动化脚本解决的是“任务层面的省心”。但我不建议大家看到什么任务都想着写脚本。那样反而本末倒置。我给自己定下了三条原则：
- 高频：这件事至少一周会出现一次。如果三个月才做一次，脚本的价值大打折扣。
- 重复：每次执行步骤完全相同，不涉及复杂的、需要人类判断的决策。
- 易错：人工做容易漏步骤或写错参数，让程序来做能可靠输出。
举个例子：每周五需要把一周的项目日志从不同目录收集起来，按日期排序，汇总成一个Markdown周报。这个流程以前要手动点开十多个日志文件，费时且容易漏。我把步骤写成Python脚本，每次只要运行python weekly_report.py，就会自动扫描目录、拼接内容、生成草稿。三条原则全部满足，投入产出比极高。
4.2 两个零基础的自动化起点：文件批处理与API调用
如果你刚接触自动化，建议从两个“最不容易出错”的方向切入。
方向一：文件批处理。
批处理文件重命名、移动、格式转换，是几乎每个人都会遇到的痛点。以前我下载一批音频或PDF，文件名乱七八糟，手动改几十个会崩溃。用Python的pathlib库可以轻松搞定：
from pathlib import Path base_dir = Path("./downloads") for f in base_dir.glob("*.pdf"): # 把文件名里的空格替换成下划线，并统一小写 new_name = f.stem.replace(" ", "_").lower() + ".pdf" f.rename(f.with_name(new_name))这个脚本虽然简单，但已经包含了一个关键思想：“批量操作前先打印新名字，加一个确认步骤再执行”。我早期吃过亏，为了省事直接执行rename，结果把一个还未来得及备份的文件名改乱，后面恢复花了半小时。行代码里先print(new_name)，让人眼扫一遍再真正执行，是一种低成本高回报的保守做法。
方向二：API调用。
即使没有后端基础，也可以写几十行Python去调各种开放接口。比如每天上班后自动拉取天气、汇率或项目状态，生成一条汇总消息发到企业微信或钉钉机器人。示例：
import requests url = "https://api.example.com/status" r = requests.get(url, timeout=10) if r.status_code == 200: data = r.json() print(f"在线服务: {data['online']}, 延迟: {data['latency']}ms") else: print(f"接口异常，状态码: {r.status_code}")这里的重点不是API本身，而是异常处理。网络请求总会遇到超时、限流、字段缺失，脚本里必须写try/except并记录错误，否则某个周六早上你会看到机器人一句话都没有，不知道是服务挂了还是脚本崩了。
4.3 写脚本时容易被忽略的健壮性问题
很多人觉得脚本是“一次性代码”，能跑就行。但正经的经验是：几乎所有自动化脚本最后都会变成“长期任务”，要么被放到cron里定时执行，要么被别人复用。所以写的时候就得多考虑几个问题：
- 路径不能硬编码到绝对路径。尽量用项目根目录的相对路径，或通过环境变量配置。
- 输入文件缺失时要有明确提示。我在脚本里经常写：
if not input_file.exists(): raise SystemExit(f"缺少文件: {input_file}")这样报错信息一眼就能看懂，而不是抛一个FileNotFoundError的堆栈。
- 输出必须可追踪。脚本执行后，至少要在终端打印成功/失败摘要，如果能写一行日志到
logs/目录更好。宁可“啰嗦”一点，也不要像黑盒一样跑了没反馈。
这些细节决定了你的“超能力”是不是稳定可靠。一个偶尔跑不动的自动化任务，比手动做还让人心累。
5. 认知与习惯层面的“超能力”：工具之外更重要的部分
5.1 用任务清单和“时间块”降低大脑负载
工具再多，如果大脑整天在盘算“接下来该做什么”，照样会卡壳。我逐渐把“记忆任务”这件事从脑子里搬了出去。
我用的是一套极其轻量的任务管理方案：一个收件箱（任何快速记录工具都可以）加一个今日清单。所有想到的事先丢进收件箱，每天早上的第一件事不是打开邮箱，而是从收件箱里挑出今天真正要做的三件事，写进今日清单。这个步骤大约5分钟，但足以让一整天的工作有了焦点。
更进一步，我会给“写代码”“写文档”“回消息”这类任务分别划出时间块。比如上午9点到11点是深度工作块，期间不打开聊天工具、不刷信息流。这个简单的划分，比任何“番茄钟”App都有效，因为它借助的是“减少切换”的心理学原理——每次任务切换都有一个重新进入状态的“暖机时间”，频繁切换会让人一天下来明明忙得不行，却没有任何实质性产出。
5.2 复盘机制：让工具组合持续迭代
一套“superpowers系统”不是一劳永逸的，它需要定期迭代。我的习惯是每周五下午用一个小时做一次“工具复盘”，检查三件事：
- 这周有没有哪个操作让我重复了三遍以上？如果有，下周要不要写个脚本或别名解决它。
- 某条命令、某个快捷键这个月使用频率是不是很低？如果是，考虑删掉或重学。工具停止使用后，那些肌肉记忆也会逐渐退化，留着反而让你误以为自己“已经会了”。
- 有没有更好的替代工具值得试用？我会限定自己一个月最多试用两个新工具，防止陷入“安装—卸载”循环。
这种复盘最大的好处，是让我的配置文件和脚本库保持“新陈代谢”。它们不是一座越堆越高的古董塔，而是一个随时能支撑当前工作流的活系统。
5.3 这套“superpowers系统”需要刻意维护吗
说到维护，我最常被问到的一个问题是：搞这么多工具，光维护就得花不少时间吧？
我的答案是：维护成本取决于你愿不愿意做减法。我自己维护dotfiles仓库（里面统一管理zsh配置、编辑器配置、脚本）的时间，平均每周不到一小时。核心原因是大部分配置是增量添加的，而且每个配置都配了注释，我自己看得懂，改起来快。
但还有一个容易被忽视的点：系统中每一个工具都必须有一个明确的“主场景”。如果某个工具我也说不清它到底是用来干嘛的，那它大概率会在某个周末被我卸载。这种“断舍离”不是觉得工具不好，而是避免了认知负担的增加——工具越多，记住每个工具的使用场景本身就成了新的负担。
最后再分享一点我个人体会
回头看我这几年的“效率进化史”，真正拉开差距的，并不是我比别人多知道多少快捷键，而是我把“高频重复的确定性工作”交还给了工具，把自己宝贵的注意力留给了“需要人类判断的事情”。如果你也想构建自己的superpowers，不必一次性照搬所有方案，挑一个当前最让你头疼的重复场景，先解决它。等这个工具真正成了你工作流的一部分，再去点亮下一块技能拼图。这个过程没有终点，但每一步，都会让你从琐碎里多挣脱出一点。
