“superpowers”这个词听起来很中二但作为常年泡在终端和编辑器里的人我确实在慢慢接近那种“超能力感”别人还在翻文件夹找资料我已经一条命令把结果丢到屏幕前别人从零搭环境我十几分钟就复现了整套工作流。这套被我命名为 superpowers 的方案不是某个软件或框架而是一套可以复制的个人工作系统——把终端配置、自动化脚本、AI 辅助和知识管理串在一起专门解决“每天都在重复劳动真正想做的事却没时间做”的困境。这篇文章是对 superpowers 的完整拆解包括我为什么这么设计、每一步怎么落地以及踩过的坑和排查方法。如果你是一名开发者或者日常需要处理大量资料和文档的知识工作者这篇内容应该能帮你省下不少时间。我也尽量把方案写得通俗一些哪怕你之前对终端脚本不熟也能照着操作。1. 项目整体设计与思路拆解1.1 先把“超能力”拆成可训练的能力组合superpowers 到底指什么在我的定义里它不是玄学天赋而是在面对重复、复杂任务时能更快完成并把省下来的精力留给真正需要判断的事情。很多人在网上看到别人用一串命令完成一堆操作第一反应是“他肯定用了什么神器”但真相往往是他把基础能力训练到位了再用工具把所有基础能力组合起来效果才显得“超能力”。我用了一个很朴素的类比来理解这件事魔术师变魔术看起来很神奇但拆开看全是手法练习和道具设计。我们的“道具”是终端、自动化脚本、AI 工具“手法”是操作习惯和肌肉记忆“剧本”是每天真正面对的工作流。superpowers 的核心不是某个单点工具而是把这几层组合成一个完整的闭环。我最早想搭这套系统的原因也很简单我发现每天做的好多事其实并不需要“思考”只是无意识重复。打开项目目录、找上次用过的命令、从一堆 git log 里回忆这周做了什么、把同样的内容复制到不同平台。这些事本身没有创造性但很耗时间。与其靠毅力硬扛不如把它们交给脚本和工具。superpowers 本质上是一套“精力再分配”方案让我能把更多时间花在写代码、做设计和思考问题上。1.2 三条底层原则可复现、可替换、可测量搭这套系统的过程中我给自己立了三条原则防止越折腾越复杂。第一条是可复现。我所有的终端配置、脚本、模板都存在 Git 仓库里换电脑后执行一条脚本就能恢复。配置不落地等于没配置。网上很多人收藏了一大堆配置片段但从来没整理成自己的仓库等到换设备时又得重新找时间成本非常高。我见过不少同事换台电脑要花半天重新配置环境而我的恢复时间大概半小时差别就在配置是否版本化。第二条是可替换。我不希望系统依赖某个闭源工具或某个人的维护。核心工具必须有替代方案。比如 fzf 如果不维护了我可以用 picker、telescope 或 IDE 自带的模糊搜索顶上来。可替换的意义不是提倡反复换工具而是防止某天某个工具突然不能用了整个工作流停摆。第三条是可测量。我只关心两件事完成一个常规任务需要几步、花了多久一周内有多少时间用在创造性工作。如果折腾工具导致复杂度增加反而让我没时间做正事那这个工具就应该删掉。很多效率方案失败不是因为工具不好而是因为维护成本超过了收益。superpowers 的每一层都要能回答“它帮我省了什么”这个问题。1.3 哪些人适合照抄这份作业这套方案最适合三类人。第一类是高频使用终端和 IDE 的开发者他们每天要切换项目、查日志、跑命令收益最直接。第二类是兼职内容创作的工程师需要采集资料、整理文档、写周报和博客自动化脚本和知识管理部分会很受用。第三类是做新人 onboarding 的技术负责人因为这套东西对标准化启动环境很有帮助新人拿来就能用少走很多弯路。如果你只是偶尔用电脑处理简单工作不需要全套挑两三招就够了。superpowers 的核心不是工具数量而是减少杂念。我最开始也只加了一个模糊搜索后来发现稳了才慢慢扩展。这里也建议你读完先别急着全配选一个痛点试运行两周再决定要不要继续。2. 核心能力拆解工具选型与关键原理2.1 终端给双手装上“命令肌肉记忆”我把终端视为 superpowers 的地基因为所有自动化、搜索、远程操作都能在终端里串在一起。很多刚入门的朋友觉得终端是又黑又丑的窗口但当你熟悉之后会发现它是最高效的交互界面没有按钮层级所有功能都可以用命令直达。我目前的主力 shell 是 zsh因为它的补全、全局历史记录和插件生态比系统默认的 bash 更适合日常使用。我用的插件很少主要是 zsh-autosuggestions 和 zsh-syntax-highlighting。前者会在你输入命令时用灰色文字提示历史命令省去反复查记录的麻烦后者会在你敲错命令或语法不对时立刻显示出不同颜色相当于给命令输入加了一层实时校验。我的 .zshrc 里并没有堆很多别名只保留了高频操作。一个典型的片段是这样plugins(git zsh-autosuggestions zsh-syntax-highlighting) alias gsgit status alias gagit add -A git commit -m alias gpogit push origin HEAD为什么不追求插件数量因为每个插件在终端启动时都会占用资源。我实测过装了二十多个插件后终端启动从 0.3 秒涨到 1.2 秒以上体验反而变差。更关键的是配置越多记忆负担越大最后自己都忘了哪些别名是什么意思。终端的价值是“顺手”不是“炫酷”。2.2 fzf rg把“找文件”变成条件反射如果把终端环境比作基地那 fzf 就是基地里最常用的传送门。fzf 是一个通用模糊查找器可以接管命令历史搜索、文件搜索、git 分支切换等场景。它速度快、交互直观输入几个字母就能过滤出候选结果。rg 则是 grep 的现代替代品默认会忽略 .gitignore 里列出的文件搜索代码库时非常快。我常用的配置是让 fzf 默认用 rg 来生成文件列表export FZF_DEFAULT_COMMANDrg --files --hidden --glob !.git --glob !node_modules这样在 Vim、VS Code 或纯命令行里呼出文件搜索时都能快进快出而且不会把 node_modules 这种大目录一块儿算进去。还有一个使用频率很高的命令是查看之前执行过的命令。我把 fzf 接在历史记录后面alias fhfc -l | fzf输入fh后直接模糊搜历史命令回车就能复制再也不用往上翻几十行找一条几天前的命令。有人可能觉得这不过是少点几次鼠标但这种事一天发生几十次积累下来的时间和精力很可观。我常开玩笑说当你能“直接跳”到目标文件时编辑器文件树反而成了摆设。2.3 自动化脚本让机器替你执行“固定剧本”自动化脚本是 superpowers 里最朴素、但回报最稳定的一部分。机器的优势不是聪明而是稳定执行固定步骤。人最大的问题不是不会是重复做同样的事会烦会累还会偶尔漏掉一个参数。脚本可以把这个过程固定住。我平时会在~/scripts目录下放一些小脚本。最简单的例子一键收集最近两天改动的文件和 commit 列表#!/usr/bin/env bash git log --since2 days ago --pretty%H %s --name-only /tmp/changes.txt echo 改动文件已生成/tmp/changes.txt这个脚本本身没有任何高深逻辑但它把我每次都要敲的长命令封装成了一个固定动作。为什么这很重要因为人每天会忘记某个参数一旦忘记就得去查文档而脚本把参数固定下来我只需要记住一个名字。所谓“高手动作快”很多时候不是手速快而是决策次数少。脚本就是减少决策次数的最直接方式。2.4 AI 辅助用“指挥”代替“手写重复代码”AI 不是 superpowers但它可以当“经验实习生”来用。我目前把 AI 用在三件事生成重复性代码、解释陌生代码或日志、把口语表达改写成专业文档。这三件事的共同点是“结果确定性高”或“已有内容需要加工”不太需要真正的原创性判断。一个我常用的做法是让 AI 基于 git log 写周报条目。我会给一个很明确的 prompt你现在是资深开发者。请根据以下 git log 生成周报条目每条包含改动模块和影响忽略格式化提交。输入...用这个模板的收益很大因为周报过去要花不少时间回忆和措辞现在 AI 能基于真实提交记录生成初稿我再补充会议和沟通类信息就行。但我也要给 AI 的使用画一条红线生成的代码必须经过语法检查、测试和 review。我踩过 AI 按旧 API 生成代码的坑如果完全不看就合入生产环境迟早出问题。AI 可以提速但最终责任在你自己。2.5 知识管理把“我记得”升级为“我能搜到”超能力不只在执行层还在记忆层。如果你常常有“这事我之前处理过但想不起来怎么处理的”这种体验那问题不出在记性而出在你没有一套可检索的知识库。我的知识库现在只用纯 Markdown 文件加一个本地笔记软件主要用的是 Obsidian偶尔用 VS Code 直接打开文件夹。没有选择复杂数据库或在线服务的原因是Markdown 是纯文本零锁定可以被任何工具处理也可以放进 Git 管理天然适合长期维护。目录结构也很简单只有三层inbox/ 临时收集的想法、截图、链接 active/ 正在做的项目、尚未闭环的调研 archive/ 已结束的项目、已解决的问题我之前试过复杂的标签体系和双链图谱后来发现整理连接的成本远高于检索收益。对一个以解决问题为目标的工程师来说全文搜索比花哨的“第二大脑”更实用。归档这个动作本身也会给正反馈看到 archive 里积累的问题记录能明显感受到自己处理问题的半径在变大。3. 实操过程与核心环节实现3.1 快速搭建一个不拖后腿的终端环境如果你从零开始不想复制一大段看不懂的配置可以按我下面的顺序操作。这套流程的目标是“最少步骤最快可用”。第一步确认当前 shell。macOS 上 zsh 已经是默认Linux 上可以装一下。Ubuntu 使用apt install zsh然后执行chsh -s /usr/bin/zsh切换。第二步安装 starship 作为命令行提示符。starship 的特点是配置简单、显示信息清楚而且因为是用 Rust 写的不会显著拖慢启动速度。安装后只需在.zshrc末尾加一行eval $(starship init zsh)它能显示当前 git 分支、虚拟环境、命令执行耗时等信息。第三步克隆 zsh-autosuggestions 和 zsh-syntax-highlighting 到本地插件目录并在.zshrc里启用。不要一次塞太多插件先跑通最基础的配置再慢慢加。这里有个容易踩的坑很多人从网上复制一段庞大的.zshrc里面包含大量自己看不懂的配置。一旦出错根本不知道从哪排查。我的建议是自己逐行添加每加一行就重启终端验证一次确保知道每一行在干什么。这样慢一点但稳定。3.2 把项目切换做成“一条命令”过去我经常开一整天终端就为了等某个项目进程不中断。后来我用 tmux 管理开发会话并且和 fzf 做了结合现在切换项目成了几秒钟的事。tmux 是一个终端复用工具它的核心价值在于让你在断开连接后会话仍然在后台继续运行。我常用的一个 shell 函数是这样function ts() { local dir dir$(find ~/projects -maxdepth 2 -type d | fzf --prompt项目 ) tmux new-session -A -s $(basename $dir) -c $dir }原理很简单先用 find 列出所有候选项目目录再用 fzf 做模糊选择最后用 tmux 打开或附着到对应的会话。这样我不需要记住项目名也不需要一个个打开编辑器窗口输入ts、打几个关键字、回车就进入了完整上下文。经验提醒不要在 tmux 里再嵌套一层 tmux快捷键会变得很混乱。我的习惯是一个 session 对应一个项目这样切换上下文和关闭上下文都非常明确。3.3 自动化周报从半小时到五分钟写周报可能是很多人最不想做又不得不做的任务。我最开始的周报基本靠回忆后来想通了git 已经替我记下了所有代码改动为什么要靠脑子去还原我只需要一个脚本把 commit 拉出来再加上手工补充非代码信息。脚本其实很简单#!/bin/bash author$(git config user.name) since$(date -v -7d %Y-%m-%d 2/dev/null || date -d -7 days %Y-%m-%d) git log --author$author --since$since --pretty* %s /tmp/commits.md echo 请查看 /tmp/commits.md 并手动补充会议、沟通类条目为什么保留“手动补充”这一步因为 git log 只包含代码变更不包含“和技术负责人对齐需求”“和产品确认优先级”这类关键的非编码贡献。完全自动化生成的周报容易失真加一点人工输入反而更可靠。我会在脚本生成之后把 /tmp/commits.md 里的内容复制出来再丢给 AI 润色成更面向读者的表达。这个流程走下来原本半小时的周报大概能压缩到五分钟以内。节省下来的时间不多但起码我不再讨厌写周报了。3.4 AI 辅助编码的落地小案例讲一个真实的批量处理案例。我之前有一个 Markdown 文件夹需要做结构整理要求把每个文件中“第一个以 # 开头的标题行”剪切到文件第一行如果文件第一行本来就是标题就跳过。这种批量操作如果手动一个个改几十个文件得弄到崩溃。我的处理方式是用 AI 生成一次性脚本。我给的描述是写一个 Python 脚本递归处理当前目录下所有 .md 文件找到第一个以 # 开头的标题行把它剪切到文件第一行如果原文件第一行本来就是标题则跳过处理前先备份为 .bak。生成后我检查了两件事备份逻辑是否真的生效以及会不会误伤代码块里的# 注释。跑了一次小目录验证确认没问题后再全量执行。这个过程的体验是我像一个提需求的人而不是一个敲重复代码的人。但再强调一次AI 生成的代码也有可能出错尤其当语料里的规则和你实际文件不一致时。测试不完代码就不能说稳。3.5 知识库实操建立自己的“第二大脑”知识库不需要花哨关键是形成习惯。我一般看到有价值的文章、错误排查记录、灵感片段先丢进inbox每周固定一个时间整理到active或archive。这个流程看起来简单却能保证知识库不会因为维护成本过高而荒废。我常用的模板是这样的# 2025-xx-xx 问题记录 ## 现象 ## 原因 ## 解决步骤 ## 以后如何避免模板的作用是降低记录成本。如果每次都要想“怎么写”大概率不会坚持。用固定模板只要填空就行。等到一个项目结束完整的复盘已经在 archive 里沉淀好了写博客或者给团队分享时可以直接复用不需要临时翻聊天记录和邮件。实际用下来我能明显感到“搜得到”比“记得住”更可靠。记忆会受状态影响但全文搜索只要文件在结果随时都在。4. 常见问题与排查技巧实录4.1 终端启动越来越慢明明配置也没加多少这是最典型的效率工具问题最初搭环境很快用一段时间后发现每次打开终端都要等好久。常见原因有三个——插件数量失控、nvm 或 pyenv 每次启动都执行初始化、PATH 变量重复追加。排查方法可以分两步。先执行time zsh -i -c exit看一下总耗时。如果超过一秒说明配置里有明显开销。然后挨个注释掉.zshrc里的source行用二分法定位是哪个插件或初始化语句拖慢了启动。我最后的解决方案是把 nvm 改成懒加载只有真正执行 node 命令时才加载平时打开终端不做任何初始化。高频命令我已经熟到不用补全所以插件越少反而越顺。终端的价值是快速响应不是启动后做一堆检查。4.2 fzf 搜索不到我想找的文件有朋友问过我fzf 搜不到项目里某个文件是不是配置错了。多数情况是FZF_DEFAULT_COMMAND没有生效或者 rg 默认不搜索隐藏文件。排查思路很直接先跑which rg确认 rg 已安装再单独跑rg --files --hidden | head -20看输出是否符合预期。配置里一定要加上--glob !.git否则会把 .git 目录里的对象也搜进来既慢又乱。另一个容易被忽视的问题是某些目录文件特别多如果忘记写 .gitignorerg 默认会忽略它但如果你改成了--no-ignore搜索会突然变慢。fzf 的性能很多时候取决于 rg 的规则先别急着怀疑 fzf先查数据结构。4.3 自动化脚本到第二天就“失灵”我很早就遇到过脚本在终端里跑得好好的放进计划任务后却完全失效。排查下来最常见的原因是路径不一致。你终端里的 PATH 和计划任务里的 PATH 不一样导致脚本里依赖的 git、python 等命令找不到。解决方案是在脚本开头显式设置环境变量#!/bin/bash export PATH/usr/local/bin:/usr/bin:/bin:$PATH另一个坑是数据格式变化。比如某次 git 版本升级后log 输出格式变了我的周报脚本生成的 Markdown 里多出一些空行。排查手法是手动把脚本里的命令拆开一条一条跑看哪一步输出不符合预期。自动化脚本不是写完就能一劳永逸要把它当成一套需要定期维护的小系统。4.4 AI 改代码把好好的项目改坏了AI 能提高效率也会放大错误。我遇到过 AI 做全局变量名替换时把另一个语言关键字也替换了所有用到相关语法的地方全部编译失败。从那以后我给自己定了三条铁律。第一批量修改之前先建分支或打 tag。第二每次只接受一个 diff不一次性接受所有建议。第三执行前先git diff查看变化确认每一处都符合预期。这不是不信任 AI而是对生产环境负责。把 AI 当实习生你不会让实习生直接部署对吧AI 生成的内容也一样必须有人工 review 兜底。4.5 工具囤积癖买了一堆“超能力”人却更累了最后这条可能不是技术问题而是心态问题。有些人包括我自己有一阵子天天逛新工具、折腾配置觉得用上某个工具就能效率起飞。实际结果是工具越来越多配置越来越重真正写代码的时间反而少了。我后来给自己定了一个“效率工具预算”每周最多花三十分钟折腾配置其余时间全部投入业务。每月末清理一次冷静地问自己“这个配置最近两周用过吗”没有就删掉。这个习惯帮我保持了系统的精简也让我更接近 superpowers 的本质不是掌控所有工具而是被最少的好工具支持。5. 影响范围从一个终端到一整个工作方式5.1 量化对比旧方式和新方式实测我把这套方案用在自己身上两三个月后记录了不同场景的耗时变化。先放一张对比表数据来自个人经验仅供参考。场景旧方式耗时使用 superpowers 后耗时主要省在哪儿写周报约 30 分钟约 5 分钟git 自动汇总AI 润色新机器环境配置半天以上约 30 分钟配置进仓库一键恢复查找历史命令10-20 秒2-3 秒fzf 历史搜索切换项目上下文20 秒以上5-8 秒tmux session fzf 选择批量改文件磨蹭半小时10 分钟内含 reviewAI 生成脚本我不建议你把这几项当作绝对承诺。同样的工具在不同人手里效果差异很大和你的使用频率、项目复杂度都有关系。但如果方向对收益一定会在某个维度上体现出来。5.2 从个人效率到团队标准化当你适应了这套系统下一步可以考虑把低风险的配置共享给团队。我建了一个叫team-superpowers的仓库里面放.zshrc、starship.toml、weekly_report.sh和一份 README说清每个文件是做什么用的、有哪些副作用。新人入职后不需要从零摸索直接复用启动成本大幅降低。不过要注意边界不是所有个性化插件和别名都适合放进团队仓库。比如我习惯的私有别名只对自己有意义塞进团队仓库只会造成混乱。共享版本要保守只放收益明确、不含个人偏好的配置。然后每月或每季度做一次效率分享让团队里愿意折腾的人一起维护这套资产。5.3 后续还能怎么扩展superpowers 现在对我来说已经不是一个具体工具而是一个持续迭代的习惯。我最近的计划是把常用脚本整理成一个小型的命令行工具包加上帮助信息方便自己和新同事快速上手。AI 部分也可以往更深处走自动给 PR 写描述、自动分析近期故障的关联日志、基于本地知识库回答问题。再远一点还可以把本地脚本和低代码自动化平台结合让日报自动推送到团队协作工具让环境初始化变成一个可视化流程。你会发现当技术栈和业务变化后原本的工具可能被替换但“把重复动作自动化、把隐性知识显性化”这个思路一直有效。这才是 superpowers 真正能持续发挥价值的地方。文章到这里核心内容已经全部讲完了。最后分享一点我的真实体会这套 superpowers 说穿了不复杂它的价值来源于一个习惯——把每个动作拆成“需要思考”和“不需要思考”两类然后给后者一点自动化。如果你看完想试试我的建议很朴素不要一口气搭完所有内容。先选一个你最痛的点比如“找文件很慢”或者“写周报很烦”用一条命令或者一个小脚本解决它跑两个星期再回头判断。我自己最初只是想少敲几个字结果一路滚成了整套体系。你的 superpowers 未必和我一样但你可以从一个很小的脚本开始。