1. 从“superpowers”这个热词说起它到底指什么“superpowers”这个词最近在技术社区和效率工具圈子里被反复提起很多人第一次看到它是在某个开源项目的讨论区或者是在朋友转发的一条“效率翻倍”的截图里。它不是一个具体的软件产品也不是某个大厂发布的框架而是一个能力增强层的概念代称——你可以把它理解成给现有工具链装上一套“外挂模块”让原本需要多步操作、反复切换的事情变成一条指令或者一次点击就能完成。我最早接触这个概念是在一个自动化脚本的分享帖里有人把一套自定义的命令集称为“我的 superpowers”意思是这套东西让他的日常操作变得像超级英雄一样高效。后来这个词逐渐被泛化用来指代那些能显著提升个人或团队生产力的工具组合、脚本集合、配置方案。它可能是一组 shell 别名可能是一套浏览器书签脚本也可能是一个本地运行的自动化服务。为什么这个词会火因为现在大家手里的工具太多了——编辑器、终端、浏览器、笔记软件、任务管理、API 调试工具每个工具都有自己的操作逻辑切换成本极高。而“superpowers”代表的是一种把碎片化操作收拢成统一入口的思路。你不需要换掉现有工具只需要在它们之上加一层“能力层”把高频操作抽象成简短指令。这篇文章适合谁看如果你是那种每天要在终端里敲几十条重复命令的人或者你经常在多个 SaaS 工具之间来回倒腾数据又或者你只是想给自己搭一套顺手的效率系统但不知道从哪开始那接下来的内容就是为你准备的。我会从概念拆解、选型逻辑、搭建步骤、踩坑记录几个角度把“superpowers”这件事讲透。注意本文讨论的“superpowers”是效率工具层面的概念不涉及任何特定商业产品也不涉及任何需要特殊网络环境才能使用的内容。所有方案均基于本地可运行、公开可获取的工具链。2. 拆解“superpowers”的常见形态与适用边界2.1 它通常以哪几种形态出现在实际使用中“superpowers”落地下来主要有四种形态每种形态的搭建成本和适用场景差别很大我按从轻到重排一下。第一种是命令别名与函数集合。这是最轻量的形态本质上就是在你的 shell 配置文件里加一堆alias和function。比如把git status缩成gs把“切换到主分支并拉取最新代码”写成一个函数sync。这种形态的优点是零依赖、启动快、改起来方便缺点是只能覆盖终端内的操作跨应用的能力有限。第二种是脚本化的自动化流程。比如用 Python 或 Node 写一个脚本把“从某个表格读取数据、调用接口、生成报告、发送通知”这一串动作串起来。这种形态适合处理有固定步骤的重复任务搭建成本中等但一旦跑通节省的时间非常可观。第三种是本地服务加快捷指令。比如在本地跑一个轻量 HTTP 服务然后通过系统级的快捷指令或者浏览器扩展去调用它。这种形态能打通“浏览器里看到的内容”和“本地能执行的操作”适合需要抓取网页信息、批量处理链接、快速保存素材的场景。第四种是配置化的工具集成层。比如用一套配置文件把编辑器、终端、窗口管理器、启动器的行为统一起来让快捷键逻辑一致、主题一致、操作习惯一致。这种形态最重但体验也最完整适合长期在固定设备上工作的人。2.2 什么场景下值得投入什么场景下不值得不是所有工作都值得搭一套“superpowers”。我自己的判断标准是看重复频率和操作步骤数。如果一个操作你每天要做五次以上而且每次都要点三下以上或者敲超过十个字符那它就值得被抽象成一个更短的入口。反过来如果一个操作一周才用一次或者本身已经很快了那花时间去封装它反而是一种浪费。还有一个容易被忽略的维度是上下文切换成本。有些操作本身不慢但因为它需要你从当前思维状态里跳出来——比如你正在写代码突然要去查一个文档、复制一段配置、切换一个环境——这种切换带来的注意力损耗往往比操作本身更耗时。这类操作即使频率不高也值得被封装成“一键完成”的形式。我见过不少人一上来就想搭一套大而全的系统结果配置了两天用了三天就放弃了。问题不在于技术难度而在于过度设计。正确的做法是从一个最小的痛点开始先解决一个具体问题跑顺了再逐步扩展。下面这张表是我总结的几种常见场景与推荐形态的对应关系你可以对照自己的情况看看。场景描述重复频率推荐形态搭建成本终端里反复输入长命令每天多次命令别名与函数低每周整理一次数据报表每周一次脚本化流程中浏览网页时频繁保存素材每天多次本地服务加快捷指令中高多工具之间切换频繁每天持续配置化集成层高2.3 一个容易被忽视的前提先理顺工作流再动手在动手写任何配置之前我强烈建议你先花半小时把自己一天的操作流程过一遍。具体做法是打开一个空白文档从早上开始工作那一刻起把你做的每一个“非创造性”操作记下来——打开哪个应用、点了哪个按钮、输入了什么命令、切换到了哪个窗口。不用记太细记到“动作级别”就行。这个练习的价值在于它会让你发现很多你平时根本没意识到的重复动作。我自己第一次做这个练习的时候发现自己每天平均要执行二十多次“切换到浏览器、打开某个固定页面、复制一段内容、切回编辑器、粘贴”的循环。这个循环单次只要十几秒但一天累积下来就是好几分钟的纯机械操作而且每次切换都会打断写代码的思路。理顺工作流之后你再去决定哪些环节需要“superpowers”优先级会清晰很多。我的建议是优先处理那些打断创造性工作的操作而不是那些本身就在创造性工作内部的操作。比如“查文档”会打断写代码值得优化“在代码里重命名变量”本身就在写代码流程内用编辑器自带功能就够了。3. 搭建一套可用的命令别名与函数层3.1 从 shell 配置文件入手选 zsh 还是 bash如果你用的是 macOS 或者主流 Linux 发行版默认 shell 大概率是 zsh 或 bash。两者在别名和函数支持上差别不大但 zsh 在交互体验上更顺手一些——比如更好的补全、更灵活的提示符、更丰富的插件生态。如果你还没有特别偏好我建议直接用 zsh因为后面如果要扩展成更复杂的“superpowers”zsh 的生态会更省事。配置文件的位置bash 是~/.bashrc或~/.bash_profilezsh 是~/.zshrc。我习惯把别名和函数单独放在一个文件里比如~/.mypowers然后在主配置文件里用source ~/.mypowers引入。这样做的好处是配置清晰迁移的时候直接拷这一个文件就行不会把主配置文件搞得乱七八糟。# 在 ~/.zshrc 或 ~/.bashrc 末尾添加 if [ -f ~/.mypowers ]; then source ~/.mypowers fi3.2 别名设计的三条实用原则写别名看起来简单但设计不好反而会增加记忆负担。我踩过的坑包括别名太短导致和现有命令冲突、别名太多记不住、别名逻辑不一致导致用错。后来我总结了三条原则基本能避开大部分问题。第一条别名长度控制在二到四个字符且尽量保留原命令的首字母。比如git status缩成gsgit diff缩成gddocker ps缩成dps。这样即使你忘了具体别名凭直觉也能猜个八九不离十。第二条同一类操作使用统一的前缀或后缀。比如所有和 git 相关的别名都以g开头所有和目录跳转相关的都以c开头change directory。这样你的大脑会把它们归成一类记忆成本会低很多。第三条不要给已经有短命令的操作再起别名。比如ls已经够短了再起个别名没意义cd也是。别名应该用在那些“原命令明显偏长”的地方。下面是我自己常用的一组别名你可以直接抄也可以根据自己的习惯改。# git 相关 alias gsgit status alias gdgit diff alias gagit add alias gcgit commit -m alias gpgit push alias glgit log --oneline -10 # 目录跳转 alias llls -alF alias ..cd .. alias ...cd ../.. # 系统相关 alias portslsof -i -P -n | grep LISTEN alias myipcurl -s ifconfig.me3.3 函数才是真正拉开差距的地方别名只能做简单的命令替换真正能体现“superpowers”价值的是函数。函数可以接受参数、可以做条件判断、可以组合多个命令。我举几个自己每天都会用的例子。第一个是“创建目录并立即进入”这个操作我每天至少做五次用函数封装后从两步变一步。mkcd() { mkdir -p $1 cd $1 }第二个是“快速查找并进入某个项目目录”。我习惯把所有项目放在~/projects下但项目多了之后每次都要cd好几层。这个函数用find加模糊匹配输入关键词就能跳过去。proj() { local dir dir$(find ~/projects -maxdepth 2 -type d -iname *$1* | head -n 1) if [ -n $dir ]; then cd $dir else echo 没有找到匹配的项目目录 fi }第三个是“批量重命名当前目录下的文件扩展名”。这个操作不常用但每次用的时候手动写循环很烦封装一次一劳永逸。renewext() { local old$1 local new$2 for f in *.$old; do [ -e $f ] || continue mv $f ${f%.$old}.$new done }这三个函数的共同特点是它们解决的都是有明确输入输出、步骤固定、手动做很烦的问题。你在设计自己的函数时也可以按这个标准去筛选。3.4 让配置可维护注释、分组与版本管理很多人写配置文件的时候图快一堆别名函数堆在一起过两个月自己都看不懂。我的做法是按功能分组每组前面加注释说明用途并且把配置文件纳入 git 管理。这样换电脑的时候直接 clone 下来改错了也能回滚。# git 快捷操作 alias gsgit status # ... 其他 git 别名 # 目录与文件操作 mkcd() { ... } # ... 其他文件操作函数 # 网络与系统信息 alias myipcurl -s ifconfig.me # ... 其他系统相关版本管理这块我建议单独建一个仓库只放配置文件不要和项目代码混在一起。仓库里可以放一个install.sh在新机器上跑一下就把配置文件软链接到正确位置。这个脚本本身也是“superpowers”的一部分。提示修改配置文件后记得执行source ~/.zshrc或对应的配置文件让改动生效或者直接开一个新终端窗口。我见过有人改完没生效排查了半天以为是语法错误其实就是忘了重新加载。4. 把重复流程脚本化从手动到自动的关键一步4.1 判断一个流程是否适合脚本化不是所有重复操作都适合写成脚本。我判断的标准有三个步骤是否固定、输入是否可参数化、出错后是否容易恢复。三个都满足就值得脚本化缺一个就要谨慎。举个例子“每周从某个数据源拉取数据、清洗、生成图表、发到群里”这个流程步骤是固定的输入可以参数化成日期范围出错了大不了重跑一次所以非常适合脚本化。反过来“根据客户反馈临时调整方案”这种流程步骤每次都不一样输入也无法提前定义就不适合脚本化硬写只会写出一堆用不上的分支逻辑。还有一个隐性标准是脚本的维护成本。如果一个流程三个月才跑一次写脚本花两小时手动做每次二十分钟那要跑六次以上才回本。这种情况下我倾向于先手动做等确认它真的会长期重复再考虑脚本化。4.2 用 Python 写一个可复用的流程脚本Python 是我最推荐的脚本语言原因是标准库够用、第三方库丰富、跨平台、可读性好。下面我用一个“整理下载目录”的例子来演示怎么写一个可复用的流程脚本。这个脚本做的事情是扫描下载目录按文件类型分类移动到对应子目录并生成一份整理报告。#!/usr/bin/env python3 import os import shutil from pathlib import Path from datetime import datetime # 配置文件类型到目标目录的映射 TYPE_MAP { images: [.jpg, .jpeg, .png, .gif, .webp], documents: [.pdf, .docx, .txt, .md], archives: [.zip, .tar, .gz, .rar], videos: [.mp4, .mov, .avi], } def get_category(suffix): for category, extensions in TYPE_MAP.items(): if suffix.lower() in extensions: return category return others def organize(source_dir): source Path(source_dir).expanduser() if not source.exists(): print(f目录不存在{source}) return report [] for item in source.iterdir(): if item.is_dir(): continue category get_category(item.suffix) target_dir source / category target_dir.mkdir(exist_okTrue) target target_dir / item.name # 避免重名覆盖 if target.exists(): stem item.stem target target_dir / f{stem}_{datetime.now().strftime(%H%M%S)}{item.suffix} shutil.move(str(item), str(target)) report.append(f{item.name} - {category}/) print(f整理完成共处理 {len(report)} 个文件) for line in report: print(line) if __name__ __main__: import sys target sys.argv[1] if len(sys.argv) 1 else ~/Downloads organize(target)这个脚本有几个设计点值得说明。第一配置和逻辑分离文件类型映射放在最上面改起来不用动下面的代码。第二重名处理直接覆盖会丢数据所以加了时间戳后缀。第三报告输出每次跑完告诉你处理了什么方便核对。第四参数化入口默认整理下载目录也可以指定其他目录。4.3 脚本的调度与触发方式脚本写好了接下来要解决“什么时候跑”的问题。常见的方式有三种手动触发、定时触发、事件触发。手动触发最简单就是敲一条命令。我习惯把常用脚本放在~/bin下并把这个目录加到PATH里这样在任何地方都能直接敲脚本名运行。定时触发用系统的定时任务工具。Linux 和 macOS 上用cron或者launchdWindows 上用任务计划程序。比如你想每天早上九点自动整理下载目录可以在crontab里加一行# 每天 9:00 整理下载目录 0 9 * * * /usr/bin/python3 ~/bin/organize.py ~/Downloads ~/logs/organize.log 21事件触发稍微复杂一点需要监听文件系统变化。macOS 上可以用fswatchLinux 上可以用inotifywait。比如你想在下载目录有新文件时自动整理可以这样fswatch -0 ~/Downloads | while read -d event; do python3 ~/bin/organize.py ~/Downloads done我自己的经验是大部分场景用定时触发就够了事件触发虽然更实时但调试起来麻烦而且容易因为频繁触发导致资源浪费。除非你对实时性有硬要求否则优先用定时。4.4 脚本出错时的排查思路脚本跑不起来或者跑出奇怪结果是最让人头疼的。我总结了一个排查顺序基本能覆盖八成问题。第一步确认脚本本身能跑。直接在终端里手动执行看有没有报错。如果手动跑没问题那问题出在调度环节如果手动跑就报错那问题在脚本内部。第二步检查路径和权限。定时任务的环境变量和你的交互式终端不一样PATH可能不同相对路径可能解析到别的地方。所以脚本里尽量用绝对路径或者在脚本开头显式设置PATH。第三步看日志。定时任务默认不会把输出发给你所以一定要重定向到日志文件。我习惯在脚本里加logging模块把关键步骤和错误都记下来出问题的时候直接看日志。第四步加临时输出。如果日志信息不够就在关键位置加print或者echo把中间变量打出来。这个方法虽然笨但最有效。注意脚本里涉及删除、移动、覆盖的操作一定要先在小范围测试确认逻辑正确再放到正式目录跑。我见过有人写了个清理脚本路径写错把整个项目目录清空了这种事故恢复起来非常麻烦。5. 本地服务加系统快捷指令打通浏览器与本地操作5.1 为什么需要这一层命令别名和脚本解决的是终端内的效率问题但很多操作发生在浏览器里——看到一篇好文章想保存、看到一个有用的代码片段想存到本地、看到一组数据想快速处理。这些操作如果每次都手动复制粘贴、切换窗口、新建文件累积起来非常耗时。“本地服务加系统快捷指令”这一层的思路是在本地跑一个轻量 HTTP 服务它暴露几个简单的接口然后通过系统级的快捷指令或者浏览器扩展去调用这些接口。这样你在浏览器里点一下本地就自动完成保存、处理、归档的动作。5.2 用 Python 起一个最小可用的本地服务Python 标准库里的http.server就够用了不需要装额外的框架。下面是一个最小示例提供两个接口一个用来保存文本片段一个用来保存链接。#!/usr/bin/env python3 from http.server import HTTPServer, BaseHTTPRequestHandler from urllib.parse import urlparse, parse_qs from pathlib import Path from datetime import datetime import json SAVE_DIR Path.home() / snippets SAVE_DIR.mkdir(exist_okTrue) class Handler(BaseHTTPRequestHandler): def do_POST(self): parsed urlparse(self.path) length int(self.headers.get(Content-Length, 0)) body self.rfile.read(length).decode(utf-8) if parsed.path /save/text: data json.loads(body) filename SAVE_DIR / ftext_{datetime.now().strftime(%Y%m%d_%H%M%S)}.md filename.write_text(data.get(content, ), encodingutf-8) self._respond(200, {status: ok, file: str(filename)}) elif parsed.path /save/link: data json.loads(body) filename SAVE_DIR / links.md with filename.open(a, encodingutf-8) as f: f.write(f- [{data.get(title, 无标题)}]({data.get(url, )})\n) self._respond(200, {status: ok}) else: self._respond(404, {status: not found}) def _respond(self, code, payload): self.send_response(code) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(json.dumps(payload).encode(utf-8)) def log_message(self, format, *args): pass # 静默模式不输出访问日志 if __name__ __main__: server HTTPServer((127.0.0.1, 8765), Handler) print(本地服务已启动监听 127.0.0.1:8765) server.serve_forever()这个服务只监听本地回环地址不对外暴露安全性上没有问题。启动后你可以用curl测试一下curl -X POST http://127.0.0.1:8765/save/text \ -H Content-Type: application/json \ -d {content: 这是一段测试文本}如果返回{status: ok, ...}说明服务正常。5.3 用系统快捷指令调用本地服务macOS 上的“快捷指令”应用可以直接发 HTTP 请求Windows 上可以用 PowerToys 的快捷方式或者 AutoHotkey。这里以 macOS 快捷指令为例说明思路其他平台逻辑类似。创建一个新快捷指令添加“获取 URL 内容”动作方法选 POSTURL 填http://127.0.0.1:8765/save/text请求体选 JSON内容里把当前剪贴板的内容传进去。然后给这个快捷指令分配一个全局快捷键比如CtrlOptionS。这样你在任何地方复制一段文字按一下快捷键内容就自动保存到本地了。浏览器里保存链接也是同样的思路只是接口换成/save/link请求体里带上当前页面的标题和 URL。有些浏览器支持自定义搜索快捷方式你可以把javascript:脚本绑定到关键词上实现“输入关键词加回车就保存当前页面”。5.4 这一层的常见坑与规避方法第一个坑是端口冲突。8765 这个端口可能被其他程序占用。解决办法是在启动服务前先检查端口或者干脆用一个随机高位端口把端口号写到一个固定文件里客户端从文件读取。第二个坑是服务没启动。如果你重启了电脑本地服务不会自动起来快捷指令就会失败。解决办法是把它做成开机自启的服务。macOS 上用launchdLinux 上用systemdWindows 上用任务计划程序。配置稍微麻烦一点但一次配好长期省心。第三个坑是编码问题。中文内容在传输过程中如果编码不一致保存下来会变成乱码。解决办法是客户端和服务端统一用 UTF-8并且在请求头里明确指定Content-Type: application/json; charsetutf-8。第四个坑是安全问题。虽然只监听本地但如果你的电脑上有其他不受信任的程序理论上也能调用这个接口。我的做法是加一个简单的 token 校验请求头里带一个只有本机知道的字符串服务端校验不通过就拒绝。这个 token 可以放在环境变量里不写死在代码中。6. 配置化集成层让多个工具行为一致6.1 统一快捷键逻辑的价值当你同时使用编辑器、终端、浏览器、窗口管理器时最大的摩擦往往不是某个工具本身不好用而是它们之间的操作逻辑不一致。比如在一个工具里CtrlW是关闭当前标签在另一个工具里是关闭窗口在第三个工具里又是别的意思。这种不一致会导致你频繁按错按错之后又要花时间恢复。配置化集成层的目标就是让高频操作的快捷键在所有工具里保持一致。我的做法是先定义一套自己的“快捷键语义”然后在每个工具的配置里尽量往这套语义上靠。比如我定义CtrlTab永远是“切换到下一个标签/缓冲区”CtrlShiftTab永远是“切换到上一个”CtrlW永远是“关闭当前标签/缓冲区”而不是关闭窗口。这套语义定下来之后我去编辑器配置里改键位去终端配置里改键位去浏览器扩展里改键位。虽然每个工具改法不同但改完之后肌肉记忆是统一的切换工具时不需要重新适应。6.2 用配置文件管理工具行为除了快捷键还有很多行为可以通过配置文件统一。比如主题和配色编辑器、终端、浏览器用同一套配色方案减少视觉切换成本。字体统一用等宽字体字号一致减少阅读疲劳。启动行为编辑器启动时恢复上次会话终端启动时自动进入项目目录浏览器启动时打开固定的一组页面。搜索行为所有工具里的搜索快捷键统一搜索范围默认包含当前项目。这些配置分散在各个工具的配置文件里管理起来比较麻烦。我的做法是建一个~/dotfiles目录把各个工具的配置文件都放进去用软链接链接到工具实际读取的位置。然后用 git 管理这个目录换电脑的时候 clone 下来跑一个安装脚本就全部就位。# 示例把 dotfiles 里的配置链接到实际位置 ln -sf ~/dotfiles/zshrc ~/.zshrc ln -sf ~/dotfiles/vimrc ~/.vimrc ln -sf ~/dotfiles/gitconfig ~/.gitconfig6.3 启动器把所有入口收拢到一个地方配置化集成层的最后一块拼图是启动器。启动器的作用是让你用一个快捷键呼出一个输入框输入几个字符就能找到并执行任何操作——打开应用、搜索文件、执行脚本、访问网址、运行快捷指令。macOS 上我用 Alfred 或 RaycastWindows 上我用 PowerToys Run 或 WoxLinux 上我用 rofi 或 Ulauncher。这些工具的共同点是支持自定义脚本扩展你可以把自己写的脚本、函数、快捷指令都注册进去用一个统一入口调用。我自己的启动器里注册了这些入口打开常用项目目录、运行整理脚本、保存剪贴板内容、搜索笔记、打开常用网页、切换窗口布局。这样我大部分日常操作都不需要离开键盘也不需要记住每个操作在哪个工具里呼出启动器输入关键词就行。6.4 集成层的维护节奏配置化集成层最大的问题是容易过时。工具升级后配置文件格式可能变快捷键可能被占用脚本可能因为依赖更新而失效。我的做法是每个月花半小时做一次“配置巡检”把所有配置过一遍确认还能用把不再需要的删掉把新发现的需求加上。这个巡检不需要很正式就是打开配置文件扫一眼跑几个常用操作看看有没有报错。发现问题就当场修修不了就记下来周末再处理。坚持几个月之后你的配置会越来越贴合自己的实际需求维护成本也会越来越低。提示配置文件一定要纳入版本管理每次改动前先提交一次。这样改坏了可以随时回滚不会因为一次误操作把积累很久的配置全丢掉。7. 我踩过的坑与几条实在建议7.1 不要追求一步到位我最初搭这套东西的时候想的是“一次性把所有能自动化的都自动化”。结果花了整整一个周末配了几百行配置写了十几个脚本用了一周就发现一半以上根本用不上还有一部分因为设计得太复杂改起来比手动做还麻烦。后来我全部推倒重来从一个别名开始用到什么加什么反而稳定下来了。这件事给我的教训是效率工具的价值在于“用起来”不在于“配得全”。一个只有五条别名的配置只要你每天都在用就比一个有两百条但你记不住的配置有价值。所以我的建议是从最小的痛点开始解决一个再加下一个让配置跟着你的实际需求生长。7.2 给每个自动化留一个“手动逃生口”自动化最怕的是“自动化失败之后你不知道怎么手动完成”。我见过有人把所有操作都封装成脚本结果脚本一挂他连最基本的操作都不会做了。这种情况在压力大的时候特别致命——你正赶着交东西自动化挂了你还要花时间研究怎么手动做。我的做法是每个自动化流程都保留一个手动版本写在注释里或者单独的文档里。平时用自动化自动化挂了就按手动步骤走不耽误事。等有空了再去修自动化。这样你永远不会被自己的工具卡住。7.3 定期清理不再使用的配置配置和代码一样会随着时间积累垃圾。不再用的别名、过时的脚本、失效的快捷指令留着不仅占地方还会干扰你找东西。我现在的习惯是每个季度做一次清理把过去三个月没用过的配置删掉。删之前先注释掉放一周确认真的不需要再彻底删除。这个习惯帮我保持配置文件的精简。现在我的~/.mypowers只有不到一百行但覆盖了我日常百分之八十的高频操作。剩下的百分之二十要么频率太低不值得封装要么每次情况不同没法封装手动做就行了。7.4 把配置当成个人知识资产来对待最后说一个心态上的建议。很多人把配置文件当成“临时凑合的东西”随便写写丢了就丢了。但我觉得一套打磨好的效率配置是你个人工作方式的沉淀它记录了你对工作的理解、对工具的选择、对流程的优化。它值得被认真对待、被版本管理、被持续迭代。我现在换新电脑第一件事就是 clone 我的 dotfiles 仓库跑安装脚本十分钟之内就能恢复到熟悉的工作环境。这种“随时可以重建”的能力本身就是一种 superpower。它让你不被任何一台设备绑定也不被任何一次系统重装打断节奏。如果你还没有开始搭自己的这套东西我建议就从今天开始先加一个你最常用的别名明天再加一个一周之后你就会感受到变化。不用急慢慢来让这套东西跟着你一起成长。