superpowers听起来像个中二的项目代号但它真的是我给自己那套开发工作流起的项目名。我花了差不多两个月把终端、编辑器、自动化脚本和 AI 协作统一成了一套配置体系整体打包以后就叫 superpowers。这套东西解决的是我在日常开发中遇到的最实际的问题高频率、低价值的重复动作太多真正用来思考和写核心逻辑的时间被不断挤占。它适合所有被“切二十个窗口找配置、手打一串重复命令、反复改样板代码、查一遍又一遍资料”折磨过的开发者不管你是前端、后端、测试还是刚入门不久的新人都能从中拆几块直接拿走用。作为一个“项目”superpowers 没有一个现成的安装包它更像一系列约定和配置的集合。我的目标很朴素让键盘不离手、上下文不切换、重复的事一键完成、不会的东西让 AI 先兜底。这套思路听起来不难真正落地却需要很多细节打磨。下面的内容相当于我自己的落地记录包含了我踩过的坑、试错之后的取舍以及可以直接复制到你机器上的具体配置。1. 为什么我把日常开发流当成一个项目来重造1.1 所谓超能力其实是把高频动作的摩擦降到最低我以前写代码时有个特别糟糕的习惯把大量时间花在“找东西”上。找刚才打开过的文件、找上次跑过的命令、找某个函数在哪里定义、找某个配置项在哪层目录。一天下来真正写业务代码的时间可能只有两三个小时剩下的时间都在做低效穿梭。后来我想明白一个道理那些看起来像“超能力”的工程师并不是脑力真的比普通人强多少而是他们把高频操作打磨成了极低成本的肌肉记忆别人还在思考“怎么打开这个文件”的时候他们的手已经完成了动作。这就是 superpowers 这个项目的起源。我不追求创建一个什么了不起的框架也不打算把开发过程变成复杂的仪式感。我做的第一件事是统计自己一天里重复次数最多的动作然后逐个击破。统计结果排序下来大概是查找文件、切换分支、看 Git 状态、跑测试、改配置、复制粘贴样板、查命令帮助。这七类操作占据了大约 60% 的无效时间。superpowers 的设计目标就是把这 60% 的时间尽量压缩压出来的时间全部还给真正的技术思考和方案设计。这套工作流从诞生起就带着务实基因。我给自己定了四条硬性约束第一任何操作如果一天要做超过三次就必须有更快的方式第二能用快捷键完成的事情绝不打开菜单第三常用命令必须短到能闭眼敲出来第四所有配置必须放进版本管理换机器时一条命令恢复。这些约束后来成了筛选工具的唯一标准不满足的就换掉别被“功能更多”的假象绑架。1.2 四个设计原则与选型标准我把整个工作流拆成四个能力层分别对应终端、编辑器、自动化和 AI 协作。每一个层在选择具体工具时都遵循同一套判断标准延迟要低、占用要少、配置要轻、后续维护要简单。延迟低指的是操作响应要快到让人觉得是本能反应而不是明明想按快捷键结果还要等界面转圈。占用少指的是工具本身不能成为性能瓶颈装完以后风扇狂转的那种插件我会直接卸载。配置轻指的是能用默认配置解决的就别加扩展一个工具只干一件核心的事。维护简单指的是配置文件和脚本必须有清晰的注释半年不看还能一眼明白。这套标准帮我过滤掉了很多看起来很酷但实际很鸡肋的工具。比如我试过给终端装一个全功能的文件管理器但它启动太慢也试过给编辑器装一堆美化主题但它们除了让截图好看没有任何效率收益。superpowers 的核心不是“装得更满”而是“用得越少越顺手”。所以它最终呈现出来的样子是一个以核心配置为主、只保留少量关键扩展的工具链。每一层都有明确的职责边界层与层之间可以灵活组合就算你只采用其中一部分也不会影响其他部分的正常工作。2. 终端让命令行变成你的驾驶舱2.1 先把终端皮肤换掉一个不那么起眼但回报率极高的决定终端是整个 superpowers 体系里最优先改造的部分因为它会承载大量高频操作。第一步是换掉系统自带的默认终端模拟器。我在 macOS 上用 iTerm2在 Linux 上用 GNOME Terminal在 Windows 下用 Windows Terminal。它们都支持快捷键、分屏和自定义主题这些基本能力才是终端高效的前置条件。换了终端之后我发现光是“一键打开新窗口”和“左右分屏看日志”这两个动作就已经能省下不少时间。接下来是 shell 本身。我默认使用 zsh并且搭配一套轻量的补全和提示体系。很多人喜欢把 zsh 配到花里胡哨但我一开始就决定压缩加载时间。动态里说的那种“忠实既有约束”在终端这里体现得很极端如果装完插件以后zsh -i -c exit的耗时超过 1 秒我会直接把插件砍掉。后来我保留了几个真正高性价比的工具fzf 用于模糊查找历史命令和文件zoxide 用于快速跳到常用路径eza 作为 ls 的现代化替代bat 作为 cat 的高亮替代ripgrep 作为全目录搜索的加速器。它们都遵循一个原则不改变原有的操作语义只是把原来的动作变快。替换命令不是目的提高输出可读性才是。比如zoxide会让cd变成一个记忆路径的智能跳转提前把所有项目目录都加入索引。刚上手的时候你可能感觉不到它有多强但当你输入z blog就能一键跳进多级目录时那种“原来终端还能这样”的感觉就来了。我把这些工具写成了一个安装脚本放到 dotfiles 仓库里新机器上只需要一条命令就能恢复一套完整的终端环境。2.2 高频别名和函数配置让手速跟得上思路工具装好之后真正让终端产生“超能力感”的是别名和函数。我把高频 Git 操作、Docker 操作和文件操作全部压缩成了短命令放进~/.zshrc。下面这段是我实际在用的配置文件的核心部分# 高频 Git 操作 alias ggit alias gagit add -u git status alias gcgit commit -m alias gpugit push alias gpfgit push --force-with-lease # 千万不要用 --force alias glgit pull --rebase alias lggit log --oneline --graph --all -n 30 alias gbgit branch --show-current # 高频 Docker 操作 alias dpsdocker ps --format table {{.Names}}\t{{.Status}}\t{{.Ports}} alias dlgdocker logs --tail 100 -f # 文件操作 alias findffind . -type f -name alias tree2tree -L 2 -I node_modules|.git # 自定义函数快速进入并创建目录 mkd() { mkdir -p $1 cd $1; } # 自定义函数一键创建新项目 new-proj() { name$1 mkdir -p $name/src $name/tests cd $name git init echo # $name README.md printf node_modules/\n .gitignore code . }这里面我想特别提醒两点。一个是gpf这个命令它是对--force-with-lease的别名不是--force。--force会把本地分支直接覆盖到远程如果别人在同一个分支上提交过代码你的强制推送会直接摧毁对方的工作成果而--force-with-lease会先检查远程分支是否发生了你本地不知道的变化如果有就拒绝推送。开发协作中最容易出事故的地方往往就在这种“方便”的别名里所以别贪图省事用危险的版本。另一个是别名和函数不要贪多。初期我给自己定义了几十个别名结果不到一个月就忘了一大半最后那些别名反而成了记忆负担。后来我把它们砍到只剩高频使用的十几个留下的每一个都到“闭眼都能敲出来”的熟练度。这个经验很重要别把一组命令收藏起来就不管了那是死库存真正有意义的库存是你每天都会用手去调用的那部分。2.3 让搜索和切换快到飞起终端里的“找东西”曾经是我最大的时间黑洞。后来我用 fzf 和 ripgrep 彻底改变了这个局面。fzf 可以让我按CtrlR对历史命令做模糊搜索输入几个字母就能立刻定位到之前跑过的长命令。它的压制点是模糊匹配也就是说我不用记住完整命令只需要记住其中两个关键词就能把它翻出来。另一个高性价比用法是把CtrlT绑定到文件搜索在终端里直接模糊查找文件名找到后回车就把路径插入命令行。ripgrep 则解决“在一个工程目录里快速定位一段文本”的问题。它默认忽略.gitignore里列出的目录这意味着搜索时不会跑进 node_modules 和 .git 里浪费时间比传统 grep 快很多倍。我习惯用rg 关键词 src这样的命令把搜索范围限定在项目源码目录。再配合 fzf 做结果预览基本做到“前一个命令 vim 打开文件后一个命令就修改完保存”。这些工具组合起来给我带来的不是某一项单独的速度提升而是整体思考的流畅度——当查找的成本变得足够低我就更愿意去搜索而不是凭记忆硬猜最终的错误率也大幅下降。3. 编辑器把每一次跳转和补全都调成最低成本3.1 快捷键体系先把最常用的动作用手指记住编辑器是我写代码的主战场所以 superpowers 的第二层重点改造这里。我日常主力是 VS Code但偶尔也会用 Neovim 处理大文件或者远程环境所以我把两边的常用快捷键做了映射统一。常用的那批动作其实就十几个删除整行、移动整行、多光标选中、全局搜索、跳转定义、重命名符号、打开文件、切换侧边栏、打开终端。只要把这几个动作练成下意识反应编辑器的效率立刻会上一个台阶。我整理了一张 VS Code 高频快捷键对照表放在这里给大家参考动作快捷键说明删除整行CtrlShiftK不用光标选中整行直接删除当前行移动代码块Alt↑ / Alt↓上下移动当前行或选中块多光标选相同词CtrlD按一次选下一个相同的词适合批量修改全选相同词CtrlShiftL一次选中文件中所有相同词批量改名神器重命名符号F2跨文件重命名当前变量、函数不用手动挨个改跳转到行CtrlG输入行号直接跳转快速打开文件CtrlP输入文件名片段即可打开任意文件集成终端Ctrl不用切窗口在编辑器里直接跑命令打开侧边栏CtrlB切换左侧资源管理器快捷键入手时机也很关键。我见过不少同学拿到快捷键表就狂背但很快就会忘。更好的做法是把快捷键表和日常开发任务绑定比如今天只练“多光标批量修改”每次遇到批量改变量名时强制自己用 CtrlD哪怕一开始慢也比手动一个个改更快。一周之后这组快捷键就自然长在手上了。使用F2重命名时还要先确认自动预览里的修改范围是否符合预期别让跨文件重命名波及到不该动的引用。3.2 代码片段与 AI 补全的配合编辑器效率提升的另一半来自代码片段。superpowers 对代码片段的使用策略是不放太多花式模板只放那些结构高度固定、每次都要重复敲的代码。比如创建一个 React 组件、写一个 TypeScript interface、生成一条标准的路由定义。凡是需要根据上下文灵活变化的精细逻辑片段就不会硬套凡是结构重复的样板片段就会彻底接管。在这类场景中我一般用一个简单易记的缩略语触发比如输入rc再按 Tab就会自动生成一个 React 组件的骨架然后光标自动落在组件名上继续输入即可。更进一步的帮助来自 AI 补全。GitHub Copilot 这类工具的补全质量已经被训练到了“能猜出你下一步想写什么”的程度。但我不建议直接无脑接受它的所有建议。我的经验是AI 补全适合处理重复度高的代码比如从对象里解构字段、写表单校验规则、生成正则表达式这些场景里它能一次性给全效率极高但一旦涉及核心业务逻辑、异步时序或者边界条件很复杂的代码你就得停下来认真审一遍。代码片段和 AI 补全的配合要避免冲突。如果你给 Copilot 做了很长的自定义指令同时又设定了大量代码片段同一个缩略语可能会触发两个来源的建议反而打乱思路。我给自己的准则是代码片段只服务于“结构性固定”的那部分AI 补全只服务于“语义上可预测”的那部分日常写核心代码时则手动敲一边写一边思考。3.3 Git 操作在编辑器内的优化编辑器还有一个容易被低估的作用把 Git 操作变成可视化工作流。刚开始我用 VS Code 自带的源码管理面板后来发现只靠它做常规操作还可以一旦涉及复杂的交互式暂存或者改历史提交记录还是会回到命令行。所以我的策略是“双轨并行”在编辑器内搞定快速查看改动、提交信息填写、查看文件差异这三类高频操作遇到 rebase、cherry-pick、清历史这类重操作就切到终端配合快捷键完成。插件选择上GitLens 对我来说基本是必装的因为它能快速看到某行代码是谁在什么时候改的这对排查“这行代码为什么存在”特别有用。再配一个 Error Lens它能把错误和警告直接渲染在代码行尾部不用悬停鼠标才知道哪里出问题。不过 Error Lens 也有缺点就是屏幕上红色波浪线会比较多很多人看着焦虑所以如果你觉得噪音太大完全可以把它关掉只在测试时开启。代码拼写检查插件 Code Spell Checker 是我近半年新增的习惯。很多后端工程师会觉得这玩意儿只是给写英文文档的人用的但代码里大把的单词拼写错误其实会造成很隐蔽的 bug。比如某个变量名拼错一次后面所有引用它的地方都用错的拼写代码能跑但语义已经不对。花 5 分钟看一遍拼写建议长期来看能省掉不少命名混乱引发的沟通成本。4. 自动化把重复劳动变成一键脚本4.1 从一次日志分析说起终端和编辑器能解决“手工操作不够快”的问题但有些事光靠快不够需要完全脱离手工。自动化层就是 superpowers 里让我觉得“真的像超能力”的部分。触发点是一次线上日志分析每次排查问题时我都要从好几个文件里找出时间戳在某个范围内的日志再提取关键字段再按请求 ID 排序。这个过程重复了大概七八次之后我实在受不了了就花半小时写了一个小脚本把整条链路收敛成一条命令。这个脚本的思路其实不复杂就是先用 ripgrep 从原始日志里筛出目标行再用 awk 做字段提取最后用 sort 和 uniq 统计频率。因为直接用了一条管道串起来所以它执行起来非常快。后来我把它做成了公共命令logscan挂在每个项目目录下通过一个内置的config.yaml来声明“什么是关键字段”。这样面对不同的日志格式时只需要改配置不需要改脚本。自动化脚本最大的价值不是它用了什么高深技术而是把“每次都要花五分钟手敲”的事情变成了“一秒执行”。写这类小工具时我的第一个原则是不追求通用先解决眼前的问题。很多第一次尝试写自动化脚本的人总想把所有情况都覆盖到最后写出来一个几百行的怪物反而没人愿意维护。我的做法是先写一个只覆盖当前场景的短脚本让它快速跑起来使用一周后如果确实稳定再根据新需求一点点加参数。等它真的被用过很多次我才考虑把它重构得更通用。没有真实需求驱动的通用化都是自己感动自己。4.2 一键初始化项目模板自动化里回报率最高的是“项目初始化”。以前我创建新前端项目时要手动mkdir、git init、写README.md、添加.gitignore、用npm create vite初始化、再手动装依赖、最后打开编辑器。这一套流程至少要五分钟而且每一步都可能因为版本变化而出小问题。后来我把它写成了一个函数上一节里的new-proj就是其中一版。你可能会觉得这不算什么但它有一个很实际的好处团队协作时每个人创建的新项目结构都一样不需要再争论“模板长什么样”。我还会把这类函数放到一个独立的functions.sh里然后在.zshrc中 source 它。这样即使~/.zshrc本身被压到很短也能保持功能完整。脚本里我会用注释标明每一段作用比如“创建目录结构”“初始化 Git 仓库”“写入 package.json”半年后再看也能立刻知道要改哪里。这一条经验是从“长脚本变成面条代码”的惨痛经历里学到的脚本不复杂的时候可以不写函数但一旦超过 5 个步骤最好把每一段都独立出来并配上清晰注释。自动化的边界同样重要。我给自己定的规矩是重复执行超过三次的操作才写脚本一次性的、以后很难再遇到的临时操作手工做完就算了不写脚本。否则会把大量时间花在“自动化一个只发生过一次的操作”上这种投入完全是负收益。自动化的本质是投资你需要判断每次脚本的维护成本是否低于手工操作累计成本别让自动化本身变成新的负担。4.3 通知与定时任务让机器主动找你superpowers 里的自动化还有一个常被忽略的维度让机器主动找你而不是你反复去看机器。比如你有一个跑很久的测试或者构建任务跑完以后核心信息是成功还是失败、失败在哪一步。如果每次都要人肉盯终端那时间就浪费了。我写了两个简单的通知脚本一个在命令成功时弹出完成提示一个在命令失败时弹出错误摘要并附带日志尾部。macOS 上可以用 osascript 发系统通知Linux 上可以用 notify-sendWindows 上可以通过 PowerShell 的 BurntToast核心思路都一样。更进一步的用法是结合 cron 或 launchd 做定时任务。比如每天早上九点自动拉取所有项目的最新代码然后跑一轮轻量测试输出一份报告到本地文件中午十二点自动检查依赖是否有大版本更新周五下午自动清理过期的临时文件和镜像。这些任务都是静默运行的只在出现异常时才通知我。这样我每天打开电脑之后很多状态已经摆在那里了不需要一个个去查。这里要提醒一句凡是自动执行的破坏性操作必须加双重确认逻辑。比如自动删日志、自动清空缓存、自动推送代码这些操作一旦出错代价很高。我的做法是先把确认逻辑写在脚本里默认只输出将要执行的动作列表并生成预览文件只有手动执行确认命令后才真正生效。永远不要让整点自动任务直接删数据哪怕前一天删过一次没问题第二天也可能因为某个变量变化而删错目录。这种事故我见过太多次了。5. AI从聊天工具变成开发副驾驶5.1 建立自己的提示词库不让每次提问从零开始AI 在 superpowers 里的角色不是“聊天玩具”而是开发副驾驶。真正用好 AI 的第一个前提是建立一套自己的提示词库。我见过不少人每次提问时都要在文本框里重新写一遍角色设定、背景信息、输出要求效率非常低而且得到的答案质量往往也不稳定。我给自己准备了一组固定模板根据场景分成“代码生成”“代码解释”“测试用例”“重构建议”“学习概念”几个类别每个类别都有一段至少包含四要素的框架角色定义、任务目标、输入格式、输出约束。比如我经常用的一段模板是你是一名熟悉 TypeScript 和 Node.js 的资深后端工程师。请先指出我下面这段需求中不明确的地方然后给出两套实现方案并注明各自的性能取舍。暂时不要写完整代码先输出方案说明。如果我的需求本身有冲突请直接指出。看到区别了吗它明确要求 AI “先指出不明确的地方”这会逼着 AI 在动手之前做一轮需求分析而不是直接给一个想当然的答案。它还要求“不要写完整代码”这让 AI 先从方案层面思考避免过早沉浸在代码细节里。大多数人让 AI 写代码时都是把需求一扔、代码一收最后发现跑不通还得来回调反而比手写更慢。把提示词库建好以后我每次提问的成本降到了“只需要替换输入部分”而且输出质量明显更稳。5.2 让 AI 写代码的正确姿势把 AI 接入实际开发流程后我踩过最大的坑就是“想当然地信任输出”。AI 给出的代码表面上语法正确但很可能忽略边界条件、用了一个被弃用的 API、或者在并发场景里埋了雷。我现在的流程是分四步走第一步让 AI 先给出实现思路和代码结构不要一次性爆出完整文件第二步我自己把思路翻译成一组小任务序列比如“先定义数据模型”“再写解析逻辑”“最后写导出函数”第三步让 AI 按每个小任务分段生成代码并把生成结果逐一审查第四步让 AI 为生成的关键函数补充测试用例。这个流程看起来多花了一点时间但它实际能省下大量调试时间。因为分段生成以后每一段代码的错误都更容易定位测试用例也会从一开始就把回归风险兜住。我还养成了一个习惯每次让 AI 改完代码都会让它解释“为什么这次改这里”以及“这次改动影响哪些调用方”。一旦它的解释明显有问题我就会停下重新思考而不是让改动直接进版本库。AI 是生产资料不应该是决策者。另外给 AI 提供精确的上下文比提问技巧更重要。如果你要改的是某个函数就把函数定义和调用处都贴进对话而不是只说“帮我优化这段代码”。没有上下文的 AI 只能给通用建议很多时候你会得到一段与现有代码风格完全不一致的替代品。上下文越准确输出越精准。这也是我个人觉得 AI 代码补全和聊天式 AI 之间最大的差别补全是在你的真实代码里做的聊天则需要你自觉补充上下文。5.3 知识库沉淀AI 辅助下的个人笔记系统AI 真正帮我产生的长期价值是把“随手记”变成了“可检索知识库”。以前我记笔记的方式是在浏览器里开一堆标签页、收藏夹里存一堆链接到用的时候根本找不到。后来我统一用 Markdown 文件做笔记按“领域 / 主题 / 小节”组织目录配合 fzf 做全文模糊搜索。写作方式上我会先用录音或快速打字把原始素材丢进一个inbox目录然后隔一天再用 AI 帮忙把零散记录整理成结构化笔记提取出关键结论、操作步骤和易错点。这套流程的核心不是我“记了多少”而是“找得到、看得懂、用得上”。每周我会花 10 分钟把这一周新学到的命令行技巧、代码模式、配置心得追加到一个tricks.md文件里。这个文件不追求完美排版只追求“下次遇到同样的问题时能立刻翻到解决方案”。配合 AI整理的速度比以前快很多因为 AI 可以帮我把一句“今天发现可以用 xxx 绕过这个坑”扩展成“使用场景 操作步骤 注意事项”的完整条目。长期积累下来这个知识库就变成了真正属于我的 superpowers。6. 常见问题与翻车经验6.1 为什么你的终端越用越卡先给启动时间做个体检很多人在照着这类博客配置之后第一个遇到的坑就是终端启动变得特别慢。我见过有人装了十几个 zsh 插件以后每开一个窗口都要等三秒这已经完全违背了效率工具的本意。排查方法很简单在终端里执行time zsh -i -c exit这条命令会输出从打开 zsh 到退出所花的总时间。一般来说如果超过 1 秒就需要移除或懒加载一些插件。我自己的习惯是只在需要时手动加载插件比如某些重量级工具会在进入特定目录时才初始化一部分不常用的补全功能推迟到第一次按键时才加载。另一个常见问题是终端模拟器本身太老画面渲染跟不上换一个支持 GPU 加速的模拟器就能解决。这个体检动作建议新配置上线一周后做一次那时候你才真正知道哪些部分是新配置带来的额外负担。6.2 快捷键冲突和“这个插件到底干嘛的”编辑器里最容易爆发的两个问题是快捷键冲突和插件失控。快捷键冲突一般在刚安装一个重量级插件时会突然出现比如刚才还在用的 CtrlD装完某个代码折叠插件后就变成折叠面板了。VS Code 里可以通过命令面板输入JSON打开keybindings.json直接搜索对应快捷键看它被谁占用了然后决定是改插件绑定的按键还是删掉插件。我自己的准则是插件优先级低于原生快捷键任何插件都不允许覆盖我已经用惯的键位如果这个插件非要占用我就换一个可配置键位的替代品。至于“这个插件到底干嘛的”这个问题没有快捷键可以解决只能靠克制。我给自己的插件数量设了上限一个类别最多两个候选装新插件之前必须先卸载一个旧插件。这个习惯让我的 VS Code 启动时间和内存占用一直保持在健康水平也避免了“插件装了一堆真正用到的没几个”的经典浪费。建议大家每隔三个月就做一次插件大扫除逐个检查每个插件在过去一个月里的使用记录零使用次数的一律卸载眼不见心不烦。6.3 脚本换机器后失效的万能排查法自己写的脚本换一台机器就跑不起来这是很多人都会遇到的问题。最常见的原因是路径不一样比如脚本里写死了/Users/yourname/projects/换个用户名就失效第二个常见原因是依赖工具版本不一致比如某个命令需要新版 grep 支持-r参数但新机器上还是老版本第三个原因是 shell 环境变量没加载比如脚本依赖functions.sh里的某个函数但.zshrc没有 source 它。排查顺序可以按照“先看脚本第一行再看互相依赖最后看环境变量文档”来走绝大多数问题都能定位。更根本的解决方案是把整个 superpowers 配置纳入 dotfiles 仓库用 Git 做版本管理并写一个bootstrap.sh来完成新机器的安装。关键配置里不要写死机器名和私有路径能用$HOME的地方一律用$HOME。我的bootstrap.sh会依次做四件事安装基础工具、创建项目目录结构、链接配置文件、执行一次性初始化命令。新机器从头到可以正常跑任务大概只需要 20 分钟。这 20 分钟的投入换来的是“换电脑不再是灾难”的安全感非常值。6.4 自动化脚本出故障时怎么做才不会帮倒忙自动化脚本最怕的不是报错而是“没报错但是做错了事”。比如上面提到的日志分析脚本如果某天日志字段顺序变了脚本依然会正常输出但结果已经完全不同这时如果你没发现就相当于基于错误结论做决策。我为此给脚本加了一条简单的“健康检查”逻辑脚本主流程结束以后额外输出几行统计摘要并把结果和上一次运行时的摘要做对比如果差异超过阈值就在屏幕上提示风险。这条逻辑不复杂但能把“静默出错”变成“显式告警”。另一个容易帮倒忙的场景是“自动化任务堆积过多”。一开始我什么小事都想自动化后来发现自己每天要花不少时间维护这些脚本反而拖慢了开发。于是我把自动化分了级A 级是每周至少用三次的必须稳定维护B 级是每周用一次的可以放在一个scripts-extra目录里不保证完全可用C 级是那种“感觉以后可能用到”的直接删掉。分级之后我的维护压力明显降低真正核心的那些脚本也能得到更仔细的打磨。6.5 AI 协作中的三个心理陷阱最后聊几个 AI 协作里常见的心理陷阱。第一个是“过度信任”AI 写出 95% 正确的代码后人会放松对剩下 5% 的警惕但这 5% 往往正是边界条件和异常处理是生产环境最容易出 bug 的地方。我的原则是AI 生成的代码一定要过一遍测试没有测试覆盖的代码不要合入主分支。第二个是“提示词万能论”以为只要提示词写得好AI 就一定能给出完美方案。实际上提示词只负责减少歧义真正决定质量的还有上下文、任务粒度和验证闭环三者缺一不可。第三个是“废掉手写能力”过度依赖 AI 补全之后很多人会发现自己脱离补全就写不动代码这会削弱对语法和代码结构的敏感度。我现在的做法是新学一个框架时前两周完全手写代码不开启任何补全等基本语法都熟悉了再打开 AI 工具追求速度。这既保留了我的技术基本功也享受了 AI 的效率红利。7. 最后想分享给你的几个体会这套 superpowers 工作流改到现在我最真实的感觉是真正的“超能力”不是某一个神奇的工具而是一套能稳定沉淀、持续迭代、随时可复用的个人体系。工具会过时配置会被替代但“把高频摩擦降至最低”这个原则不会变。我身边有同事看到我用一串快捷键加一个别名完成他十分钟的工作时会觉得我“技术很厉害”但我知道我只是把这些操作的摩擦提前磨平了而已。如果你也想搭建自己的 superpowers我的建议是从最小闭环开始选一个你每天都会重复三次以上的操作给它做一个别名或快捷键然后用一周去形成肌肉记忆。不要一上来就试图把终端、编辑器、自动化、AI 全部重装一遍那样大概率会在第二周就放弃。先在真实场景里体会到“摩擦变小”的快感你才会有动力去优化下一个动作。最后分享一个小技巧我每周五下午会把本周新增的别名、快捷键、脚本片段补进tricks.md里然后通读一遍。这个动作只花 10 分钟但它让我对自己的工具链保持“熟悉且可控”。工具一旦失控效率就会反向增长。把这套定期复盘的习惯纳入你的工作流比我任何一条具体配置都更重要。