★ FEATURED ARTICLE superpowers这个词这两年我在开发者社区里看到的频率越来越高甚至直接出现在热搜词里。很多人第一反应是去搜某个软件包想着装上就拥有“超能力”但真正折腾过的人才明白所谓superpowers是一整套能反复放大你产出效率的工作方式、脚本工具和思维习惯的组合不是一个能一键安装的插件。这篇内容我想分享的是如何从零搭一个属于你自己的个人效率系统——不需要多高深的技术背景只要愿意记录、调试、维护它就能在写代码、处理文件、整理资料这些日常事上帮你省下大量时间。适合谁看被重复劳动拖垮的办公族、刚入门想折腾工具链的开发者以及所有对“让机器干活”这件事感兴趣的人。1. 别把superpowers当成魔法先理解超能力的本质1.1 为什么这个词突然成了热词近段时间“superpowers”频繁出现在开发社区、效率论坛和短视频平台上评论区里最常见的一句话就是“想要安装superpowers”。表面上看大家是在找一个工具往深了看其实是大家普遍感受到一种差距同样一天8小时有人能完成三倍的事情还能准时下班而自己光处理重复的琐事就用掉一半精力。这种差距不是智商决定的也不主要是经验决定的而是工具链和工作方式的差距。我给你举个最简单的例子手动重命名200个文件一个个右键、F2、输入字符至少40分钟写一个三行脚本跑完只需要几秒钟。40分钟和5秒这就是普通人眼里的“超能力”。这种能力在十年前还需要深厚的编程功底才能做到但在现在一个稍微懂点命令行的人就能搭起来。热词背后真正流行的不是某个软件而是这种“让机器替我干活”的思路开始普及了。1.2 我对superpowers的定义在动手之前我先说清楚我理解的“超能力系统”到底是什么不然很容易做成一个吃灰的工具收藏夹。我的定义很简单就一个公式高频动作的自动化 知识沉淀的可检索性 启动成本的趋近于零。三个部分缺一不可。自动化解决的是“重复劳动耗时间”的问题比如批量改名、批量压缩、一键部署知识沉淀解决的是“收藏了却找不到”的问题比如把零散的笔记、资料、代码片段变成可以搜索的库启动成本解决的是“工具比手动还麻烦”的问题如果每次都要打开终端、找到脚本、回忆参数那这个能力就不会被长期使用。我个人最看重最后一点。很多人的dotfiles仓库里堆了几十个脚本真正常用的可能就三五个原因就是那些脚本的调用链太长、记忆成本太高。真正成功的superpowers系统应该是“输入短、反馈快、出错有提示”最好能做到你只需要敲一两个字符剩下的交给脚本。1.3 哪些能力值得装哪些是伪需求有了定义还需要一把尺子去判断什么值得搭建、什么应该放弃。我的尺子有三个标准触发频率、维护成本、失败代价。高频但不复杂的任务最值得自动化比如文件备份、图片压缩、代码提交低频但高风险的任务可以半自动化比如服务器部署脚本生成命令人工确认后再执行低频又简单的任务别自动化手动做更快。最常见的问题是把“看起来很酷”当成“必须拥有”比如有人写了一个自动整理下载文件夹的脚本结果因为分类规则太粗暴文件被乱移最后反而损失了时间。我用一张表来区分常见的需求场景场景触发频率维护成本失败代价是否值得自动化批量重命名文件高低低强烈推荐自动备份工作目录中低中推荐一键启动开发环境高低低强烈推荐自动回复邮件低高高不推荐自动整理下载目录中高中谨慎自动化部署上线低中高半自动这张表是我踩过不少坑之后总结出来的核心原则只有一句如果你的自动化方案需要花三小时写但这三小时不能在未来三个月里省回来那就别干。2. 我的superpowers工具箱四个核心模块2.1 终端与编辑器增强让高频操作一键直达整个系统里最基础也最见效的模块是终端和编辑器的高频操作增强。刚接触命令行的人可能觉得无非是把一长串命令记住但其实更好的方式是让系统帮你记住你只需要负责“想做什么”。以我自己为例我在.bashrc里维护了一批短别名和函数。以前我每天都要敲cd ~/Projects ls -la看项目目录现在只需要敲dev以前我提交代码要打出完整的一长串git add -A git commit -m ...现在只需要敲gac后面跟提交信息。差距看似不大但每天敲几十次积累一个月节省的是实实在在的注意力和手指负担。# ~/.bashrc 片段 alias devcd ~/Projects clear ls -la alias gacgit add -A git commit -m alias pypython3 alias llls -lah # 常用目录快速跳转 function mkd() { mkdir -p $1 cd $1 } function findport() { lsof -i :$1 }这些都不是复杂的东西但“简单高频”恰好是超能力系统最健康的组合。我建议你不要一上来就折腾那些需要特殊配置的终端框架先把这类“省一个动作”的小函数积累起来等到量变引起质变的时候你自然知道下一步该优化哪里。2.2 自动化脚本把重复劳动交给机器第二个模块是自动化脚本对应的场景是那些“虽然没有技术含量但做起来很烦人”的批量任务。最常见的三个场景是批量重命名、批量压缩图片、批量整理日志文件。我给你看一个我实际在用的图片压缩脚本。做内容的人几乎每天都要处理截图原图动辄几MB直接放进文档和网页里非常卡手动一张张压缩又很浪费时间。#!/usr/bin/env bash # compress_images.sh # 用法: ./compress_images.sh for img in *.jpg *.png; do [ -e $img ] || continue convert $img -resize 1920x1080\ -quality 80 compressed_$img echo 已处理: $img done echo 全部完成输出文件位于当前目录执行的前提是机器上装了ImageMagickMac用户可以用brew install imagemagick装好。脚本里1920x1080\的意思是只把大于这个尺寸的图片缩小已经是小图的不动-quality 80平衡了大小和清晰度。我第一次跑这个脚本十分钟内处理了三百张截图从那之后我再也没有手动压缩过图片。这类脚本有一个共同的特点边界清晰、逻辑简单、输出明确。一旦任务开始涉及判断“这张图质量要不要更高一点”“这类文件应该放到哪个目录”这类模糊逻辑脚本的维护成本就会直线上升这种情况我会选择只做半自动让脚本列出来我人工看过后再确认。2.3 资料剪藏与统一检索让收藏不再是囤积第三个模块最容易被忽视但它其实才是长期收益最大的部分资料的剪藏与检索。我们都有过这样的经历浏览器收藏夹里躺着一百多个网页“回头再看”基本就再也没打开过。原因很简单收藏时只需要点一下但真正使用时很难定位时间一长就变成了数字囤积。我的做法是所有值得留下的内容统一转成纯文本或Markdown按固定的命名规则存进本地目录文件名格式是“日期_主题_标签.md”。比如20250320_用Nginx做反向代理_后端.md、20250322_如何写出好的commit message_git.md。内容可以是网页摘录、技术文档片段、甚至是自己突然冒出来的想法。固定格式的命名看起来有点笨但它保证了两件事一是所有文件可以按时间排序二是搜索时可以按照主题和标签快速缩小范围。配合本地搜索工具这个目录就成了个人知识库。我不需要记住内容只需要记住大概主题和日期几秒内就能调出来。这个习惯坚持三个月以后我发现自己写东西、做方案时找素材的时间大大缩短那种“这个我好像看过但找不到”的挫败感基本消失了。2.4 本地存储与多端同步数据握在自己手里最后是存储和同步模块。这个模块的价值在于让上述所有脚本、笔记、配置在多台设备间保持一致同时自己掌握数据不依赖某个单一平台。我的策略很简单所有重要的数据脚本、笔记、配置文件、知识库都放在本地的一个工作目录里用网盘工具做增量同步。好处是本地始终有一份完整副本云端只是备份坏处是多设备同时改动时可能产生冲突所以我的使用习惯是固定一台主力机器做“写入”其他设备只做“读取”。配置文件我全部放进一个dotfiles目录用Git管理版本。换新电脑时只需要把仓库克隆下来再跑一个小脚本把所有配置软链接到正确位置就能恢复到跟旧电脑几乎一样的开发环境。这个模块不需要很复杂的自建服务只需要一点纪律性新配置随手加进版本控制旧配置定期清理。时间长了这一整套东西就成了一个只属于你自己的超级系统。3. 实操一步步搭出你自己的superpowers3.1 第一步先花一周盘点高频操作很多人的失败不是因为不努力而是不知道从哪里下手。我的建议是先别急着写脚本花一周时间做一次操作流水账。具体做法是随手记录每天重复做两次以上的操作不用正式手机备忘录或者一张纸就可以。记录三件事操作内容、单次耗时、每周大概几次。一周后你手里会有一张清单直接暴露浪费时间的黑洞。我那次盘点发现自己每天光是清空临时目录、切换项目、重复输入长命令就花了将近四十分钟而这些任务全部可以用三两行脚本解决。盘点时注意区分“耗时长但不频繁”的任务和“耗时短但极其频繁”的任务。前者比如搭建一台服务器你可以写文档或者半自动脚本后者比如每次打开电脑都要切换到固定目录你只需要一个别名就能解决。大多数人的效率提升恰恰来自后者。3.2 第二步从一个最小脚本开始先跑通再扩展盘点完之后挑一个最容易的脚本写起来。我建议从“带时间戳的备份脚本”开始因为它逻辑简单、出错风险低而且立刻就有实用价值。#!/usr/bin/env bash # backup_workspace.sh # 把工作目录打包成带日期后缀的压缩文件 SOURCE_DIR$HOME/Projects BACKUP_DIR$HOME/Backups STAMP$(date %Y%m%d_%H%M) mkdir -p $BACKUP_DIR tar -czf $BACKUP_DIR/workspace_$STAMP.tar.gz $SOURCE_DIR 2/dev/null echo 备份完成: $BACKUP_DIR/workspace_$STAMP.tar.gz把这个文件保存为backup_workspace.sh用chmod x backup_workspace.sh赋予执行权限然后运行./backup_workspace.sh。跑通之后你会有两个选择手动隔几天跑一次或者加个定时任务让它每天自动执行。从这一步开始你已经在搭建自己的superpowers系统了。这个脚本虽小但它包含了所有后续脚本的骨架环境变量定义、目标目录检查、操作执行、结果反馈。以后写任何脚本都按这个结构走就不会出现“脚本跑完不知道成功还是失败”的糊涂情况。3.3 第三步把配置沉淀成dotfiles仓库脚本积累到一定数量之后你会发现一个问题换电脑或者换工作环境时所有配置和脚本都要重新搞一遍非常痛苦。解决办法就是建立dotfiles仓库。在~/dotfiles目录下把.bashrc、.gitconfig、脚本文件夹、编辑器配置都放进去用Git管理。原位置只需要做软链接比如ln -s ~/dotfiles/.bashrc ~/.bashrc。这么做的核心价值有两个一是所有配置都有历史记录改坏了随时回滚二是新环境恢复时只需要一条命令把所有链接建好半小时内就能搭出一个熟悉的环境。我见过很多人不愿意做这一步理由是想等配置稳定了再说。但我的经验是配置永远不会稳定它每天都在微调恰恰是需要版本控制的时候。你不需要一开始就做得完美先把最重要的两三个配置纳入Git后续自然会上瘾。3.4 第四步给自己的能力建立索引脚本和配置越来越多之后最大的敌人变成了记忆你一个月前写了一个特别好用的脚本今天想用却忘了它叫什么、放在哪里、参数是什么。所以第四步也是很多人会漏掉的就是给整个系统写一份“使用索引”。我在dotfiles仓库里维护了一个README.md用表格记录每个脚本的名字、作用、调用方式、依赖环境。为什么要写文档不是写给同事看的是写给“一个月后的自己”看的。人脑的短期记忆根本靠不住文档化的成本很低但能避免“重复造轮子”和“脚本吃灰”这两种浪费。脚本名作用调用方式依赖compress_images.sh批量压缩图片到合适尺寸./compress_images.shImageMagickbackup_workspace.sh备份工作目录为tar.gz./backup_workspace.sh无batch_rename.py批量重命名文件python batch_rename.py /pathPython 3这份索引不需要很专业能让自己看懂就行。每次新增脚本时顺手更新一行等整个系统运转半年你会发现它不仅是工具链还成了你自己的“能力清单”。4. 常见问题与排查技巧实录4.1 脚本在别人的电脑上跑不起来这个问题出现的频率极高尤其是当你终于决定把脚本分享给同事或朋友时对方跑一下直接报错。原因无非三种没装依赖、环境变量不同、文件权限不对。排查思路按顺序走。先看报错信息是不是“command not found”如果是基本就是依赖缺失需要在文档里写清楚前置条件再看脚本里有没有写绝对路径如果写了~/Documents这种以当前用户家目录开头的路径在另一个用户名下就会出问题最后确认有没有执行权限很多时候bash script.sh能跑./script.sh跑不了区别就在chmod x。调试时最实用的命令是bash -x script.sh它会逐行打印脚本的执行过程一眼就能看出是哪一步出了问题。我在脚本里统一使用的习惯是变量名全部大写路径开头用$HOME依赖检查放在脚本最前面。这样即使对方环境不同也能快速定位问题。4.2 自动化比手动还慢怎么办这是另一个让人沮丧的问题折腾半天写了个脚本结果每次用之前要想半天怎么用反而比手动操作还慢。遇到这种情况先别怀疑自己的水平而是要先回头审视一个标准你到底在自动化什么。我给自己设定了一个简单的阈值判断单次耗时超过5分钟、每月重复超过2次的任务才值得自动化如果单次只要30秒哪怕每天做10次也没必要为了省五分钟去写一个维护成本极高的脚本。另外如果你的脚本每次用都要查文档、想参数说明它的调用方式太复杂了应该重新设计让默认值最常用、参数可省略。还有一种情况是脚本本身运行缓慢比如用循环逐个处理大量文件。可以先在少量文件上测试耗时如果还是慢考虑用一些更高效的方式比如图片压缩可以用并行处理文件查找可以用系统原生的工具代替自己写的递归逻辑。总之自动化的目的是让事情变快如果感觉更慢了优先降低使用成本而不是继续堆功能。4.3 配置改坏了系统直接崩搞配置文件最怕的事情就是改着改着终端没法用了或者整个环境起不来。这种情况我经历过不止一次最后总结出的应急方案很简单所有改动之前先做备份。cp ~/.bashrc ~/.bashrc.bak # 开始修改配置…… # 如果改坏了回滚 mv ~/.bashrc.bak ~/.bashrc如果你已经建立了dotfiles仓库处理起来更简单直接用Git回滚cd ~/dotfiles git checkout -- .bashrc我的经验是修改任何关键配置之前先看一眼这个文件是否已经纳入了版本控制或至少有备份。另外改动完之后不要立刻关终端新开一个终端窗口验证没问题再写进版本库。这种“改完必验证”的习惯能让你的环境始终处于可控状态而不是一直踩在钢丝上。4.4 维护成本失控学会定期“裁员”脚本越来越多以后维护成本会慢慢吃掉收益。有些脚本可能只是因为当时觉得有趣写的之后半年都没再碰过有些脚本维护起来很费劲但实际使用频率极低。这时候最需要做的不是继续添加而是定期“裁员”。我每季度会做一次清理打开脚本目录和dotfiles仓库的提交记录看每个脚本最近的调用情况。连续一个月没用过的脚本先标记为待删除再过一个月还是没用直接删除。别心疼脚本的价值在于被使用不在于数量多。真正好用的脚本一个月里肯定会被调出来好几次。清理的同时还要做一件事合并同类项。比如把三个散落的图片处理脚本合并成一个用参数区分场景把多个目录跳转函数统一到一个配置文件里。维护成本是实实在在的时间开销只要它开始影响你做正事就必须处理。脚本状态判断标准处理方法常用一周至少用1次保留持续优化少用一月用1次保留但补文档罕用三个月没用过标记待删除弃用已找到替代方案立即删除5. 后续还能怎么扩展你的superpowers5.1 把能力包分享给团队个人的superpowers系统成熟以后一个自然的扩展方向是分享给团队。你可以把整理好的dotfiles仓库、常用脚本、使用文档打包成一个团队模板让同事克隆即用。这件事对团队效率的提升非常明显因为很多人不是不想提升效率而是不知道该从哪里着手你直接给出一套带说明的现成方案能帮大家省掉至少一个月的摸索期。但分享之前一定要做一次隐私和通用性检查把脚本里的个人路径、私密配置、特定业务逻辑全部替换成环境变量或示例值。我吃过亏把自己的项目路径写死在脚本里分享出去同事跑的时候直接报错后来才意识到脚本本身没问题问题出在路径没有做抽象。分享的过程同时也在倒逼你把脚本写得更规范是一次很有价值的复盘。5.2 让配置具备“低学习成本”再往下扩展我开始关注一件事整个系统的学习成本。现在的很多工具配置使用起来很爽但一旦三个月不接触再回来就完全想不起来怎么用。解决这个问题的办法是把所有“反直觉”的地方都记录下来。比如某个脚本为什么要加某个参数、某个环境变量设置为特定值的原因、某个别名对应的完整命令是什么都要在README里写清楚。配置不是越短越好而是“能让未来的自己看得懂”才是真的好。这个过程有点像是在用自己的系统训练自己让整个superpowers生态具备自我解释能力。另外一些使用频率极低但关键时刻很有用的脚本我会把它们单独放在一个tools/目录里并带一个USAGE.md说明。普通常用脚本允许靠肌肉记忆调用但那些低频高价值的工具非常依赖文档来唤醒记忆这个分类习惯帮我避免了很多次“曾经会写但完全忘了怎么用”的尴尬。5.3 关键是你自己的节奏不要为了自动化而自动化最后说一个我自己的教训。曾经有一段时间我沉迷于把一切能自动化的任务都脚本化甚至花了一个下午写代码只是为了让一个每天耗两分钟的小事变成一键完成。算下来回本周期差不多要三个月而且脚本偶尔还需要维护。说实话这种行为打动我的不是效率本身而是“写完一个脚本”的那种满足感。后来我调整了自己的节奏先判断这个任务到底值不值得自动化再去判断是简单自动化、半自动化还是完全手动。判断标准就回到第一节讲的那三个维度频率、成本、代价。这样一来我写的脚本越来越少了但留下的每一个都真正在帮我省时间系统的整体维护负担也降下来了。我个人实际折腾几个月后最大的感受是superpowers这个词的关键不在power而在于super——它不是让你变成超人而是把那些平庸的、重复的、耗神的事情从你手里拿走让你把精力放到真正值得的地方。能稳定运行半年、能让你每天多出一个小时做正事的小系统远胜过一个看起来很厉害但两周就吃灰的大工程。
阅读完成 · 觉得有帮助？
