早几年我和同事排一个线上问题他坐在我旁边双手在终端和编辑器之间来回切大概十分钟就定位到了根因。我还在翻日志文件手忙脚乱地找关键词。当时我第一反应是这人是不是有某种“源码级直觉”后来共事久了才发现他的外号就叫“Superpowers”不是因为他天生反应快而是因为他给自己搭了一套工具箱快捷键、终端别名、自动化脚本、代码片段、复盘模板每一件单独拿出来都很普通组合在一起就形成了别人眼里的“超能力”。我写这篇文章就是想把“superpowers”这个词从神秘感里拽出来拆解成一套可学习、可训练、可复制的方法。适合对象很明确正在从“能用工具”走向“用好工具”的开发者和技术从业者。不管你现在是刚入行还是已经带小团队这套思路都能直接套用。我会把自己踩过的坑、验证过有效的方法、具体到可以直接抄的配置和脚本全部摊开写出来。1. 我的superpowers理解不是天赋是“组合技能”1.1 高手身上的神秘感其实是可以拆解的我们总习惯把厉害的人归结为“聪明”“反应快”“天赋异禀”但真去观察他们做事会发现一个更朴素的真相他们把大量低层操作练成了肌肉记忆把判断逻辑沉淀成了固定流程把重复事情交给了脚本和工具。这三个层面就是我所定义的“超能力组合”。打个比方普通人写字是在想“这个字怎么写”熟练的人写字是在想“这句话怎么表达”。效率差距不在写字动作本身而在于写字动作被自动化了大脑被解放出来处理更高层的问题。开发工作一模一样。快捷键为什么重要不是因为它让你“看起来快”而是因为它减少了思维切换到鼠标上的二次损耗。你心里想着“跳转到定义处”手里不用去摸鼠标代码阅读的流畅度会明显不一样。我见过太多人把“用IDE”当成“打开编辑器写代码”结果大量脑力消耗在“找按钮”和“记菜单位置”上。真正高效的人是先把工具层磨到无感再在这个基础上叠加流程设计和自动化。1.2 我给“超能力”画的一张能力地图如果你让我把“superpowers”翻译成可执行的维度我会分成四层工具层键盘、终端、编辑器、命令行的熟练度。这一层解决的是“手跟不上脑”的问题。自动化层把重复、机械、容易出错的事情交给脚本这一层解决的是“时间不够用”的问题。AI协作层把大模型、代码辅助工具当作一个可以随时召唤的“实干实习生”这一层解决的是“知识面不够宽”的问题。沟通层把你脑内的上下文高效地传递给别人这一层解决的是“团队协作中的信息损耗”问题。每层之间是有依赖关系的。工具层不稳自动化层容易翻车自动化层不熟AI给的产出你也没法快速验证前三层都做了但表达能力跟不上项目协作里照样拖后腿。后面几节我会按这个顺序一层一层讲。2. 先把工具练成肌肉记忆这是所有“超能力”的地基2.1 快捷键的正确练法不是“背”是“逼自己”很多人买过快捷键速查表打印出来贴在显示器上然后就再也没有然后了。我的经验完全不同快捷键不是背会的是在“够不着”的瞬间逼出来的。具体做法很简单把鼠标设置里的指针速度调低或者干脆把鼠标放到键盘旁边够不着的地方强制自己在常用操作上使用键盘。刚开始会很难受但人的适应能力超出自己想象。大约两到三周你会发现自己真正高频使用的快捷键已经进入肌肉记忆剩下的低频操作其实死了没关系。我自己的经历是强制自己使用键盘大概一个月后编辑器里的“跳转定义”“查找引用”“重命名符号”“多光标编辑”这四件事变成了一种本能。以前我改一个变量名要手动替换好几处还容易漏现在一个快捷键下去IDE自动帮我完成全局替换效率提升是肉眼可见的。这里我强烈建议每个开发者在自己的主力编辑器里最少要掌握这四组操作跳转定义和返回全局搜索和文件内搜索多光标同时编辑重命名符号不要贪多先把这四组练到无脑反应的程度你会发现写代码的“心流”质量会高很多。2.2 终端里的命令思维别把命令行当“另一个窗口”终端不是用来输入命令的终端是用来“表达意图”的。这个区别很多人没有意识到。你在终端里敲的不是一条条命令而是在构建一个可复用的操作流。比方说我要找最近3天里被我改过的文件我不该输入一长串“find /path -mtime -3 -type f”这不叫会用终端这叫会背命令。更合理的做法是写一个短的shell函数就叫recent放进~/.bashrc或~/.zshrc以后只要在任意目录输入recent就能看到当前项目最近改动过的文件列表。这一个小函数省下的时间看似不多但积累起来非常可观。我自己的recent函数大概长这样recent() { find . -type f -mtime -${1:-3} -not -path ./node_modules/* -not -path ./.git/* | sed s|^\./|| | sort }用法是recent 5就会列出最近5天改动的文件不带参数时默认3天。这个脚本帮我解决了“今天到底改了哪些文件”这种高频问题尤其在准备代码审查和写提交说明时特别好用。再说一个认知终端里最值钱的不是某个具体命令而是“管道思维”。把一个命令的输出接到另一个命令的输入不断组合就能产生出原本需要写程序和写脚本才能完成的处理能力。比如我统计一个项目里哪个文件名出现得最多可以这样git log --name-only --prettyformat: | sort | uniq -c | sort -rn | head -20这条命令把git提交历史里的文件名全部捞出来去重统计后按次数排序。看起来像魔术本质就是管道思维在起作用。2.3 把编辑器配置成“自己的工作台”而不是默认出厂状态默认配置的编辑器只能完成“写代码”这个动作但每个人工作流不一样默认配置远不够用。我会建议你在编辑器上花一点“装修时间”把高频操作变成顺手就来的东西。我的主力编辑器是 VS Code但思路对所有主流编辑器通用。我第一件事是关掉我不需要的动画和缩略图减少视觉噪音第二件事是配置好“代码片段”把项目里反复出现的模板比如新建组件的样板代码、写测试的初始结构变成敲一两个字母就能呼出的片段第三件事是设置好工作区级的配置把格式化、保存时自动整理、导入排序这些事交给工具。这里有个很关键的认知配置编辑器不是一次性的它应该随着你对项目的理解加深而持续演化。每隔一段时间我会问自己一个问题如果我每周都要手写三次以上同一段东西它是不是应该变成一个片段或者模板这个简单的提问帮我持续把“体力活”转化成“自动化资产”而这正是“超能力”增长的底层机制。3. 自动化把重复事情交给脚本你会省下大把时间3.1 第一个真实例子用Python给日志做摘要我参与维护过一个内部系统每天产生大量日志文件出了问题要在几十MB的日志里翻线索。人工翻日志这件事又慢又容易漏而且特别浪费脑力。后来我写了一个大约六十行的Python脚本做的事情非常简单读取指定时间段内的日志提取错误级别和关键词出现的频率把最可疑的异常信息摘要输出到终端并生成一份简易报告。脚本核心思路用的是“频率关键词”打分法。比如日志里出现“timeout”“connection reset”“error”这些词会加上对应的初始分数然后按时间窗口滑动统计把同类型错误聚类。最后只看数量骤增的规律就能快速判断出系统大约在什么时间点进入了异常状态。你看这个脚本并不复杂它只是把人工巡查的逻辑自动化了。但效果非常直接以前三十分钟的排查工作现在按下回车就可以拿到初步结论我可以把省下来的时间花在真正需要人脑的判断上。我讲这个例子的目的是想说明自动化的核心不是写复杂程序而是把“你本来就会的重复劳动”用代码固化下来。3.2 第二个真实例子自动归档下载目录另一个我特别喜欢的小项目是写了一个文件自动归档脚本。我的下载目录以前就是“垃圾场”图片、PDF、安装包、压缩包全混在一起每次找文件都靠回忆。我写了这样一个脚本按照扩展名把文件分门别类移动到对应的子目录并把超过三十天没动的临时文件清理掉。脚本本身不复杂import os import shutil from pathlib import Path DOWNLOAD_DIR Path.home() / Downloads MAPPING { .jpg: Images, .jpeg: Images, .png: Images, .gif: Images, .pdf: Documents, .docx: Documents, .txt: Documents, .zip: Archives, .tar: Archives, .gz: Archives, .exe: Installers, .msi: Installers, .mp4: Videos, .mov: Videos, } for f in DOWNLOAD_DIR.iterdir(): if f.is_file() and f.suffix.lower() in MAPPING: target DOWNLOAD_DIR / MAPPING[f.suffix.lower()] target.mkdir(exist_okTrue) shutil.move(str(f), str(target / f.name))我把它挂到系统的定时任务里每天早上自动执行一次。从此之后下载目录再也不会变成一个内心沉重的“杂物间”。这类自动化的特点是投入时间少、回报周期长、维护成本低非常划算。3.3 自动化的边界感有些事不值得自动化跟很多人想的不一样我并不是“什么都自动化”的拥趸。有些事自动化起来反而更麻烦。判断标准很简单这个重复动作将来还会不会有变化如果它三天两头变需求自动化就是在给自己制造维护债务。我踩过一个著名的坑某个报告的生成脚本因为数据格式和业务逻辑经常变我几乎每周都要改脚本最后一算账手动做五十分钟改脚本一次要两小时。后来我果断放弃了完全自动化改成“半自动”脚本只负责把数据清洗排序生成中间结果最后版式由我用模板手动微调。既保留了效率又留出了灵活度。所以我的建议是自动化之前先问自己三个问题。这个动作多久做一次频率低于每周一次的不急于自动化。这个动作的规则稳定吗稳定才值得写死规则频繁变动的不适合。自动化的收益是省时间还是减少错误如果只是省时间但规则不稳定还是先忍一忍。想清楚边界再用自动化你就会发现它带来的是真正的“超能力”而不是第二份麻烦。4. 和AI协作把大模型变成“外挂实习生”4.1 AI不是你第二个搜索引擎是你的“讨论对象”很多人在用AI时有个惯性把它当搜索引擎用问“某函数怎么用”“某框架的API是什么”。这样用不能说错但浪费了更大的价值。我更愿意把AI当做一个可以随时一起讨论方案的“同事”。区别在哪搜索引擎给你一堆链接让你自己筛AI直接给你一个基于当前上下文组织的答案但更重要的是AI可以陪你完成一个完整的设计讨论。比如我在设计某个数据同步模块时会把我现有的约束条件全部喂给AI然后问它“在这种约束下你会怎么设计有哪些风险点”然后我再去验证它的建议。这种用法让AI从“词典”变成了“预审官”能帮我提前发现盲区。4.2 项目级提示词把上下文打包而不是一句一句喂我发现很多人抱怨AI回答太泛、不够贴切其实是没把上下文给够。你问“怎么优化这段代码”AI只能基于这一小段代码回答但如果你先把项目背景、技术栈、性能目标、已知约束都告诉它它给出的建议质量会完全不同。我现在会在每个项目的根目录里放一个AI_CONTEXT.md文件里面写清楚这个项目是做什么的、技术选型是什么、代码风格有哪些约定、当前已知的架构限制是什么。以后我每次和AI对话都先把这份文件贴上去再提具体问题。这样做之后AI给出的结果质量提升非常明显。我举个例子。我让AI帮我写一个任务队列的实现如果只给“用Python写个队列”这种提示它只能给一个玩具示例但当我补上“这是给某个异步爬虫用的任务会突发增多建议用Redis做持久化消费端要保持幂等”这些上下文字它给出的设计就立刻接近生产可用。上下文就是AI的魔法燃料你给它越清楚它就越聪明——这和人打交道是一样的。4.3 视觉编程与代码审查AI的安全使用姿势除了写代码我更喜欢让AI做“代码审查”。我的做法是写完一段PR(合并请求)之前先把diff贴给AI给它提几个明确的问题有没有明显的边界漏洞命名是否清晰有没有更简洁的实现方式有没有并发安全问题这里要特别提醒AI的建议不能照单全收这是使用AI最大的安全红线。我会遵守几个铁律AI建议改代码的时候必须自己逐行理解后再改。涉及安全、数据一致性、权限控制的代码绝不能只依赖AI的判断。即使AI的建议不一致也不要勉强它而是回归代码本质自己判断。AI不是万无一失的它可能会自信地给出一个看起来合理但细节上有问题的方案。所以最好的用法是把它当成一个能快速给你候选方案的“实习生”而你依然是最终拍板的负责人。这个认知摆正了AI协作才不会反过来拖你的后腿。5. 团队协作中的“超能力”把上下文变成团队资产5.1 一句话说清问题比写一堆文档更有价值我见过太多人在群里抛出一个问题“我这边有个东西报错了有人遇到过吗”跟着附一张截图。这种提问方式的效率极低因为所有接收者都要做大量猜测。实际工作中“超能力”级别的沟通不是话多而是把问题精炼到别人不需要额外追问就能给出反馈。一个好的提问模板应该是这样的我做了什么操作、预期结果是什么、实际结果是什么、我怀疑的原因有哪些。按这个格式组织问题对方一眼就能看明白甚至可以跳过追问直接给建议。这不是什么天赋是底层习惯。我自己会把常用的“问题模板”做成片段所以遇到问题要问同事时我可以快速地把结构性信息填进去发出去。看起来好像只是节省了对方几分钟但长年累月积累下来别人会觉得跟你合作“特别顺畅”——这其实也是一种超级能力。5.2 代码评审不是挑刺是“防呆设计”代码评审是另一个被很多人做得很痛苦、也可以被做得很高效的地方。痛苦的做法是“人盯着代码找毛病”高效的做法是把它变成一个结构化流程。我会在发起评审之前先写一段简短的描述说明这次改动要解决什么问题、影响范围在哪里、有没有测试覆盖。同时在代码里用注释标注几个“重点请审核”的地方。这样评审人不需要读完全部代码就能抓住关键点评审速度和质量都会提高。评审意见的写法也很有讲究。与其写“这里写得不对改成……”这种命令式语句不如写“这里我在担心数据并发的问题你看这个逻辑在A和B同时触发时会怎样”这种提问式口吻能减少防御情绪把注意力引到问题上。这听起来很小但团队氛围和评审质量会因此完全不同。5.3 把决策过程记录下来给未来的自己“留后门”代码写完只是第一步真正的“超能力”体现在三个月后你还能不能快速回想起当初为什么这样做。我这里的做法是写轻量级的决策记录不写成正式文档只在代码提交信息或者注解里留下几句关键原因。比如某模块为什么选了消息队列而不是直接RPC某个字段为什么设计成冗余存储这类“决策原因”如果不写下来过三个月连你自己也会忘。而这些东西恰恰是整个系统最值钱的部分。还有一个小技巧我会在每次完成一个比较大的功能后写一份三五十行的复盘笔记记录哪些事做得顺手、哪些卡了很久、下次可以怎么避免。这些笔记不发布纯粹是给未来的自己看。但我发现正是这些零散的记录让我在类似项目里越来越快越来越像别人口中那个“有超能力的人”。6. 把以上思考浓缩成一份可执行的“超能力清单”6.1 技能地图别让能力成长靠运气如果你也想系统化地练出属于自己的“superpowers”我给你一个很直接的工具个人技能地图。说白了就是一张表格把自己想提升的方向拆成几大类每一类下面列三五个具体可考核的动作。我先给你看看我自己的清单长什么样类别具体动作可验证的成果状态键盘效率跳转定义/多光标/全局重命名每天高频练习鼠标使用频率下降一半以上已完成终端思维掌握管道组合自己写过5个小函数每天至少3次用管道组合命令进行中自动化每周识别一个可自动化的场景每两周增加一个稳定脚本循环AI协作每次对话先给上下文不直接开口要答案AI回答可用率明显提升进行中沟通协议提问和评审都用结构化模板产出的问题一次讲清率提升进行中这张表不一定要很复杂核心是可以回顾、可以复盘。没有这张地图你的能力提升就是随缘的今天学这个明天碰那个时间花了不少但看不出质变。6.2 每周给自己一个“45分钟实验”很多人想提升自己的能力但总是卡在“没有整块时间”上。我的解法是每周只安排一个45分钟的最小实验。挑一个最近使用频率最高、但还不够顺手的工具或流程集中火力去研究它、配置它、测试它。我举几个我做过的小实验给终端做一套更合理的别名方案研究编辑器的一个插件能解决什么问题测试AI在某个特定代码场景下给出的方案质量用脚本把某个手动操作变成一步式命令。每次实验后我会把结果写进笔记能直接用的就固化下来。这个方法的好处是它不要求你专门腾出一天时间而是把“自我提升”内化到每周的工作节奏里。长期积累下来一年五十二个实验就算只有一半真正沉淀成日常使用的技能你的“超能力库”也会是大多数人望尘莫及的。6.3 一次不要练三件事以上保护持续动力我见过有的朋友三分钟热度今天想学终端明天想学Python自动化后天又发现AI提示词很酷结果每样都只开了个开头回头什么都没留下。我自己的经验是同时推进的培养项不要超过三个。原因很简单新习惯的建立需要高频反馈三个已经接近人的精力上限了。如果清单上同时列了十件事你大概率会在第一周就陷入挫败感然后全盘放弃。我自己的节奏是先把“键盘效率”和“终端思维”练到能自然使用再开始推进“自动化脚本”和“AI协作”。底层能力扎实了上层工具运转才会稳定。就像搭积木底层不稳盖得越高越容易塌。7. 我在实操中绕开的四个“超能力”陷阱7.1 过度自动化反而给自己请来了一个“祖宗”我前面已经讲过自动化的边界但这里还想再强调一遍因为它实在太容易踩坑了。那些你心血来潮自动化的东西如果规则经常变、逻辑里有大量特例总有一天会让你在凌晨改脚本改到怀疑人生。我的经验是自动化要学会分阶段先用手动方式把流程跑顺确认规则稳定后再考虑脚本化脚本也不要一步到位先做一个“半自动”的版本验证效果后再逐步完善。这个过程听起来不够“酷”但稳定且可持续。7.2 过度依赖AI的记忆把项目上下文交给了对话窗口跟前两节讲的AI协作方式相关有个很隐蔽的坑是把重要的项目信息、架构决策只放在AI对话窗口里。对话记录会丢上下文会过期更危险的是如果哪一天你的账号换了一个工具所有积累就全没了。所以我一直都强调项目级的上下文信息要沉淀到代码仓库里写成文档、写成注释、写成决策记录。AI对话窗口是临时工作区不是持久化存储。我在项目根目录维护的AI_CONTEXT.md文件本质上就是把这个信息从对话里抽离出来变成一个团队共享的、可持续维护的资产。7.3 只追求“压榨时间”忽略了给大脑留白很多人理解的效率就是把每一秒都填满恨不得给自己排满任务。但以我自己的切身感受来讲大脑是在“发呆”和“空白”里完成信息整合的。长时间的高强度输入短期来看效率很高长期来看会让判断力明显下降。所以我会刻意给自己安排一些“无目标时间”不写代码、不看信息流、不刷工具教程就散步、泡杯茶、看看窗外。看起来毫无产出但很多难缠的问题恰恰是在这种放空状态下突然想明白的。不要把你的“超能力”理解成永动机适度的恢复才是长期保持高水平输出的底色。7.4 只有输入没有输出学了一堆炫技却从不落地最后这个坑比较隐蔽但也比较普遍。很多人在网上看了大量工具介绍、教程、技巧帖收藏夹里堆满了“干货”但实际工作和学习流程里一个都没用上。我给自己定了一个“输出门槛”看到任何新技巧必须在一两周内找到至少一个真实场景去试用它。用上了、跑通了、有体感了才允许自己把它纳入技能库如果试用后觉得不好用或者不适合就果断放弃。这个门槛帮我避免了“虚假的掌握感”。想一下如果学会了却没有改变你的工作方式那这个技巧其实从来都不曾真正属于你。只有经过实践验证并融入日常流程的东西才会成为你“超能力”的一部分。前几年我总觉得“superpowers”是少数天才的专属。后来真正动手做这件事才发现它只是把工具、流程、自动化、AI协作和沟通习惯一层一层叠加起来的结果。一个人不需要等到变厉害才开始搭建自己的体系恰恰相反正是每天花一点点时间搭建这套体系让一个人慢慢变得厉害。希望这篇分享能成为你“超能力清单”上的第一个实验项目。
组合出超能力：开发者效率工具箱从快捷键到AI协作
早几年我和同事排一个线上问题他坐在我旁边双手在终端和编辑器之间来回切大概十分钟就定位到了根因。我还在翻日志文件手忙脚乱地找关键词。当时我第一反应是这人是不是有某种“源码级直觉”后来共事久了才发现他的外号就叫“Superpowers”不是因为他天生反应快而是因为他给自己搭了一套工具箱快捷键、终端别名、自动化脚本、代码片段、复盘模板每一件单独拿出来都很普通组合在一起就形成了别人眼里的“超能力”。我写这篇文章就是想把“superpowers”这个词从神秘感里拽出来拆解成一套可学习、可训练、可复制的方法。适合对象很明确正在从“能用工具”走向“用好工具”的开发者和技术从业者。不管你现在是刚入行还是已经带小团队这套思路都能直接套用。我会把自己踩过的坑、验证过有效的方法、具体到可以直接抄的配置和脚本全部摊开写出来。1. 我的superpowers理解不是天赋是“组合技能”1.1 高手身上的神秘感其实是可以拆解的我们总习惯把厉害的人归结为“聪明”“反应快”“天赋异禀”但真去观察他们做事会发现一个更朴素的真相他们把大量低层操作练成了肌肉记忆把判断逻辑沉淀成了固定流程把重复事情交给了脚本和工具。这三个层面就是我所定义的“超能力组合”。打个比方普通人写字是在想“这个字怎么写”熟练的人写字是在想“这句话怎么表达”。效率差距不在写字动作本身而在于写字动作被自动化了大脑被解放出来处理更高层的问题。开发工作一模一样。快捷键为什么重要不是因为它让你“看起来快”而是因为它减少了思维切换到鼠标上的二次损耗。你心里想着“跳转到定义处”手里不用去摸鼠标代码阅读的流畅度会明显不一样。我见过太多人把“用IDE”当成“打开编辑器写代码”结果大量脑力消耗在“找按钮”和“记菜单位置”上。真正高效的人是先把工具层磨到无感再在这个基础上叠加流程设计和自动化。1.2 我给“超能力”画的一张能力地图如果你让我把“superpowers”翻译成可执行的维度我会分成四层工具层键盘、终端、编辑器、命令行的熟练度。这一层解决的是“手跟不上脑”的问题。自动化层把重复、机械、容易出错的事情交给脚本这一层解决的是“时间不够用”的问题。AI协作层把大模型、代码辅助工具当作一个可以随时召唤的“实干实习生”这一层解决的是“知识面不够宽”的问题。沟通层把你脑内的上下文高效地传递给别人这一层解决的是“团队协作中的信息损耗”问题。每层之间是有依赖关系的。工具层不稳自动化层容易翻车自动化层不熟AI给的产出你也没法快速验证前三层都做了但表达能力跟不上项目协作里照样拖后腿。后面几节我会按这个顺序一层一层讲。2. 先把工具练成肌肉记忆这是所有“超能力”的地基2.1 快捷键的正确练法不是“背”是“逼自己”很多人买过快捷键速查表打印出来贴在显示器上然后就再也没有然后了。我的经验完全不同快捷键不是背会的是在“够不着”的瞬间逼出来的。具体做法很简单把鼠标设置里的指针速度调低或者干脆把鼠标放到键盘旁边够不着的地方强制自己在常用操作上使用键盘。刚开始会很难受但人的适应能力超出自己想象。大约两到三周你会发现自己真正高频使用的快捷键已经进入肌肉记忆剩下的低频操作其实死了没关系。我自己的经历是强制自己使用键盘大概一个月后编辑器里的“跳转定义”“查找引用”“重命名符号”“多光标编辑”这四件事变成了一种本能。以前我改一个变量名要手动替换好几处还容易漏现在一个快捷键下去IDE自动帮我完成全局替换效率提升是肉眼可见的。这里我强烈建议每个开发者在自己的主力编辑器里最少要掌握这四组操作跳转定义和返回全局搜索和文件内搜索多光标同时编辑重命名符号不要贪多先把这四组练到无脑反应的程度你会发现写代码的“心流”质量会高很多。2.2 终端里的命令思维别把命令行当“另一个窗口”终端不是用来输入命令的终端是用来“表达意图”的。这个区别很多人没有意识到。你在终端里敲的不是一条条命令而是在构建一个可复用的操作流。比方说我要找最近3天里被我改过的文件我不该输入一长串“find /path -mtime -3 -type f”这不叫会用终端这叫会背命令。更合理的做法是写一个短的shell函数就叫recent放进~/.bashrc或~/.zshrc以后只要在任意目录输入recent就能看到当前项目最近改动过的文件列表。这一个小函数省下的时间看似不多但积累起来非常可观。我自己的recent函数大概长这样recent() { find . -type f -mtime -${1:-3} -not -path ./node_modules/* -not -path ./.git/* | sed s|^\./|| | sort }用法是recent 5就会列出最近5天改动的文件不带参数时默认3天。这个脚本帮我解决了“今天到底改了哪些文件”这种高频问题尤其在准备代码审查和写提交说明时特别好用。再说一个认知终端里最值钱的不是某个具体命令而是“管道思维”。把一个命令的输出接到另一个命令的输入不断组合就能产生出原本需要写程序和写脚本才能完成的处理能力。比如我统计一个项目里哪个文件名出现得最多可以这样git log --name-only --prettyformat: | sort | uniq -c | sort -rn | head -20这条命令把git提交历史里的文件名全部捞出来去重统计后按次数排序。看起来像魔术本质就是管道思维在起作用。2.3 把编辑器配置成“自己的工作台”而不是默认出厂状态默认配置的编辑器只能完成“写代码”这个动作但每个人工作流不一样默认配置远不够用。我会建议你在编辑器上花一点“装修时间”把高频操作变成顺手就来的东西。我的主力编辑器是 VS Code但思路对所有主流编辑器通用。我第一件事是关掉我不需要的动画和缩略图减少视觉噪音第二件事是配置好“代码片段”把项目里反复出现的模板比如新建组件的样板代码、写测试的初始结构变成敲一两个字母就能呼出的片段第三件事是设置好工作区级的配置把格式化、保存时自动整理、导入排序这些事交给工具。这里有个很关键的认知配置编辑器不是一次性的它应该随着你对项目的理解加深而持续演化。每隔一段时间我会问自己一个问题如果我每周都要手写三次以上同一段东西它是不是应该变成一个片段或者模板这个简单的提问帮我持续把“体力活”转化成“自动化资产”而这正是“超能力”增长的底层机制。3. 自动化把重复事情交给脚本你会省下大把时间3.1 第一个真实例子用Python给日志做摘要我参与维护过一个内部系统每天产生大量日志文件出了问题要在几十MB的日志里翻线索。人工翻日志这件事又慢又容易漏而且特别浪费脑力。后来我写了一个大约六十行的Python脚本做的事情非常简单读取指定时间段内的日志提取错误级别和关键词出现的频率把最可疑的异常信息摘要输出到终端并生成一份简易报告。脚本核心思路用的是“频率关键词”打分法。比如日志里出现“timeout”“connection reset”“error”这些词会加上对应的初始分数然后按时间窗口滑动统计把同类型错误聚类。最后只看数量骤增的规律就能快速判断出系统大约在什么时间点进入了异常状态。你看这个脚本并不复杂它只是把人工巡查的逻辑自动化了。但效果非常直接以前三十分钟的排查工作现在按下回车就可以拿到初步结论我可以把省下来的时间花在真正需要人脑的判断上。我讲这个例子的目的是想说明自动化的核心不是写复杂程序而是把“你本来就会的重复劳动”用代码固化下来。3.2 第二个真实例子自动归档下载目录另一个我特别喜欢的小项目是写了一个文件自动归档脚本。我的下载目录以前就是“垃圾场”图片、PDF、安装包、压缩包全混在一起每次找文件都靠回忆。我写了这样一个脚本按照扩展名把文件分门别类移动到对应的子目录并把超过三十天没动的临时文件清理掉。脚本本身不复杂import os import shutil from pathlib import Path DOWNLOAD_DIR Path.home() / Downloads MAPPING { .jpg: Images, .jpeg: Images, .png: Images, .gif: Images, .pdf: Documents, .docx: Documents, .txt: Documents, .zip: Archives, .tar: Archives, .gz: Archives, .exe: Installers, .msi: Installers, .mp4: Videos, .mov: Videos, } for f in DOWNLOAD_DIR.iterdir(): if f.is_file() and f.suffix.lower() in MAPPING: target DOWNLOAD_DIR / MAPPING[f.suffix.lower()] target.mkdir(exist_okTrue) shutil.move(str(f), str(target / f.name))我把它挂到系统的定时任务里每天早上自动执行一次。从此之后下载目录再也不会变成一个内心沉重的“杂物间”。这类自动化的特点是投入时间少、回报周期长、维护成本低非常划算。3.3 自动化的边界感有些事不值得自动化跟很多人想的不一样我并不是“什么都自动化”的拥趸。有些事自动化起来反而更麻烦。判断标准很简单这个重复动作将来还会不会有变化如果它三天两头变需求自动化就是在给自己制造维护债务。我踩过一个著名的坑某个报告的生成脚本因为数据格式和业务逻辑经常变我几乎每周都要改脚本最后一算账手动做五十分钟改脚本一次要两小时。后来我果断放弃了完全自动化改成“半自动”脚本只负责把数据清洗排序生成中间结果最后版式由我用模板手动微调。既保留了效率又留出了灵活度。所以我的建议是自动化之前先问自己三个问题。这个动作多久做一次频率低于每周一次的不急于自动化。这个动作的规则稳定吗稳定才值得写死规则频繁变动的不适合。自动化的收益是省时间还是减少错误如果只是省时间但规则不稳定还是先忍一忍。想清楚边界再用自动化你就会发现它带来的是真正的“超能力”而不是第二份麻烦。4. 和AI协作把大模型变成“外挂实习生”4.1 AI不是你第二个搜索引擎是你的“讨论对象”很多人在用AI时有个惯性把它当搜索引擎用问“某函数怎么用”“某框架的API是什么”。这样用不能说错但浪费了更大的价值。我更愿意把AI当做一个可以随时一起讨论方案的“同事”。区别在哪搜索引擎给你一堆链接让你自己筛AI直接给你一个基于当前上下文组织的答案但更重要的是AI可以陪你完成一个完整的设计讨论。比如我在设计某个数据同步模块时会把我现有的约束条件全部喂给AI然后问它“在这种约束下你会怎么设计有哪些风险点”然后我再去验证它的建议。这种用法让AI从“词典”变成了“预审官”能帮我提前发现盲区。4.2 项目级提示词把上下文打包而不是一句一句喂我发现很多人抱怨AI回答太泛、不够贴切其实是没把上下文给够。你问“怎么优化这段代码”AI只能基于这一小段代码回答但如果你先把项目背景、技术栈、性能目标、已知约束都告诉它它给出的建议质量会完全不同。我现在会在每个项目的根目录里放一个AI_CONTEXT.md文件里面写清楚这个项目是做什么的、技术选型是什么、代码风格有哪些约定、当前已知的架构限制是什么。以后我每次和AI对话都先把这份文件贴上去再提具体问题。这样做之后AI给出的结果质量提升非常明显。我举个例子。我让AI帮我写一个任务队列的实现如果只给“用Python写个队列”这种提示它只能给一个玩具示例但当我补上“这是给某个异步爬虫用的任务会突发增多建议用Redis做持久化消费端要保持幂等”这些上下文字它给出的设计就立刻接近生产可用。上下文就是AI的魔法燃料你给它越清楚它就越聪明——这和人打交道是一样的。4.3 视觉编程与代码审查AI的安全使用姿势除了写代码我更喜欢让AI做“代码审查”。我的做法是写完一段PR(合并请求)之前先把diff贴给AI给它提几个明确的问题有没有明显的边界漏洞命名是否清晰有没有更简洁的实现方式有没有并发安全问题这里要特别提醒AI的建议不能照单全收这是使用AI最大的安全红线。我会遵守几个铁律AI建议改代码的时候必须自己逐行理解后再改。涉及安全、数据一致性、权限控制的代码绝不能只依赖AI的判断。即使AI的建议不一致也不要勉强它而是回归代码本质自己判断。AI不是万无一失的它可能会自信地给出一个看起来合理但细节上有问题的方案。所以最好的用法是把它当成一个能快速给你候选方案的“实习生”而你依然是最终拍板的负责人。这个认知摆正了AI协作才不会反过来拖你的后腿。5. 团队协作中的“超能力”把上下文变成团队资产5.1 一句话说清问题比写一堆文档更有价值我见过太多人在群里抛出一个问题“我这边有个东西报错了有人遇到过吗”跟着附一张截图。这种提问方式的效率极低因为所有接收者都要做大量猜测。实际工作中“超能力”级别的沟通不是话多而是把问题精炼到别人不需要额外追问就能给出反馈。一个好的提问模板应该是这样的我做了什么操作、预期结果是什么、实际结果是什么、我怀疑的原因有哪些。按这个格式组织问题对方一眼就能看明白甚至可以跳过追问直接给建议。这不是什么天赋是底层习惯。我自己会把常用的“问题模板”做成片段所以遇到问题要问同事时我可以快速地把结构性信息填进去发出去。看起来好像只是节省了对方几分钟但长年累月积累下来别人会觉得跟你合作“特别顺畅”——这其实也是一种超级能力。5.2 代码评审不是挑刺是“防呆设计”代码评审是另一个被很多人做得很痛苦、也可以被做得很高效的地方。痛苦的做法是“人盯着代码找毛病”高效的做法是把它变成一个结构化流程。我会在发起评审之前先写一段简短的描述说明这次改动要解决什么问题、影响范围在哪里、有没有测试覆盖。同时在代码里用注释标注几个“重点请审核”的地方。这样评审人不需要读完全部代码就能抓住关键点评审速度和质量都会提高。评审意见的写法也很有讲究。与其写“这里写得不对改成……”这种命令式语句不如写“这里我在担心数据并发的问题你看这个逻辑在A和B同时触发时会怎样”这种提问式口吻能减少防御情绪把注意力引到问题上。这听起来很小但团队氛围和评审质量会因此完全不同。5.3 把决策过程记录下来给未来的自己“留后门”代码写完只是第一步真正的“超能力”体现在三个月后你还能不能快速回想起当初为什么这样做。我这里的做法是写轻量级的决策记录不写成正式文档只在代码提交信息或者注解里留下几句关键原因。比如某模块为什么选了消息队列而不是直接RPC某个字段为什么设计成冗余存储这类“决策原因”如果不写下来过三个月连你自己也会忘。而这些东西恰恰是整个系统最值钱的部分。还有一个小技巧我会在每次完成一个比较大的功能后写一份三五十行的复盘笔记记录哪些事做得顺手、哪些卡了很久、下次可以怎么避免。这些笔记不发布纯粹是给未来的自己看。但我发现正是这些零散的记录让我在类似项目里越来越快越来越像别人口中那个“有超能力的人”。6. 把以上思考浓缩成一份可执行的“超能力清单”6.1 技能地图别让能力成长靠运气如果你也想系统化地练出属于自己的“superpowers”我给你一个很直接的工具个人技能地图。说白了就是一张表格把自己想提升的方向拆成几大类每一类下面列三五个具体可考核的动作。我先给你看看我自己的清单长什么样类别具体动作可验证的成果状态键盘效率跳转定义/多光标/全局重命名每天高频练习鼠标使用频率下降一半以上已完成终端思维掌握管道组合自己写过5个小函数每天至少3次用管道组合命令进行中自动化每周识别一个可自动化的场景每两周增加一个稳定脚本循环AI协作每次对话先给上下文不直接开口要答案AI回答可用率明显提升进行中沟通协议提问和评审都用结构化模板产出的问题一次讲清率提升进行中这张表不一定要很复杂核心是可以回顾、可以复盘。没有这张地图你的能力提升就是随缘的今天学这个明天碰那个时间花了不少但看不出质变。6.2 每周给自己一个“45分钟实验”很多人想提升自己的能力但总是卡在“没有整块时间”上。我的解法是每周只安排一个45分钟的最小实验。挑一个最近使用频率最高、但还不够顺手的工具或流程集中火力去研究它、配置它、测试它。我举几个我做过的小实验给终端做一套更合理的别名方案研究编辑器的一个插件能解决什么问题测试AI在某个特定代码场景下给出的方案质量用脚本把某个手动操作变成一步式命令。每次实验后我会把结果写进笔记能直接用的就固化下来。这个方法的好处是它不要求你专门腾出一天时间而是把“自我提升”内化到每周的工作节奏里。长期积累下来一年五十二个实验就算只有一半真正沉淀成日常使用的技能你的“超能力库”也会是大多数人望尘莫及的。6.3 一次不要练三件事以上保护持续动力我见过有的朋友三分钟热度今天想学终端明天想学Python自动化后天又发现AI提示词很酷结果每样都只开了个开头回头什么都没留下。我自己的经验是同时推进的培养项不要超过三个。原因很简单新习惯的建立需要高频反馈三个已经接近人的精力上限了。如果清单上同时列了十件事你大概率会在第一周就陷入挫败感然后全盘放弃。我自己的节奏是先把“键盘效率”和“终端思维”练到能自然使用再开始推进“自动化脚本”和“AI协作”。底层能力扎实了上层工具运转才会稳定。就像搭积木底层不稳盖得越高越容易塌。7. 我在实操中绕开的四个“超能力”陷阱7.1 过度自动化反而给自己请来了一个“祖宗”我前面已经讲过自动化的边界但这里还想再强调一遍因为它实在太容易踩坑了。那些你心血来潮自动化的东西如果规则经常变、逻辑里有大量特例总有一天会让你在凌晨改脚本改到怀疑人生。我的经验是自动化要学会分阶段先用手动方式把流程跑顺确认规则稳定后再考虑脚本化脚本也不要一步到位先做一个“半自动”的版本验证效果后再逐步完善。这个过程听起来不够“酷”但稳定且可持续。7.2 过度依赖AI的记忆把项目上下文交给了对话窗口跟前两节讲的AI协作方式相关有个很隐蔽的坑是把重要的项目信息、架构决策只放在AI对话窗口里。对话记录会丢上下文会过期更危险的是如果哪一天你的账号换了一个工具所有积累就全没了。所以我一直都强调项目级的上下文信息要沉淀到代码仓库里写成文档、写成注释、写成决策记录。AI对话窗口是临时工作区不是持久化存储。我在项目根目录维护的AI_CONTEXT.md文件本质上就是把这个信息从对话里抽离出来变成一个团队共享的、可持续维护的资产。7.3 只追求“压榨时间”忽略了给大脑留白很多人理解的效率就是把每一秒都填满恨不得给自己排满任务。但以我自己的切身感受来讲大脑是在“发呆”和“空白”里完成信息整合的。长时间的高强度输入短期来看效率很高长期来看会让判断力明显下降。所以我会刻意给自己安排一些“无目标时间”不写代码、不看信息流、不刷工具教程就散步、泡杯茶、看看窗外。看起来毫无产出但很多难缠的问题恰恰是在这种放空状态下突然想明白的。不要把你的“超能力”理解成永动机适度的恢复才是长期保持高水平输出的底色。7.4 只有输入没有输出学了一堆炫技却从不落地最后这个坑比较隐蔽但也比较普遍。很多人在网上看了大量工具介绍、教程、技巧帖收藏夹里堆满了“干货”但实际工作和学习流程里一个都没用上。我给自己定了一个“输出门槛”看到任何新技巧必须在一两周内找到至少一个真实场景去试用它。用上了、跑通了、有体感了才允许自己把它纳入技能库如果试用后觉得不好用或者不适合就果断放弃。这个门槛帮我避免了“虚假的掌握感”。想一下如果学会了却没有改变你的工作方式那这个技巧其实从来都不曾真正属于你。只有经过实践验证并融入日常流程的东西才会成为你“超能力”的一部分。前几年我总觉得“superpowers”是少数天才的专属。后来真正动手做这件事才发现它只是把工具、流程、自动化、AI协作和沟通习惯一层一层叠加起来的结果。一个人不需要等到变厉害才开始搭建自己的体系恰恰相反正是每天花一点点时间搭建这套体系让一个人慢慢变得厉害。希望这篇分享能成为你“超能力清单”上的第一个实验项目。
