让我效率翻倍的Linux工作流：不是更快的手速，而是更少的纠结

效率翻倍，不是手速翻倍

我以前觉得"提效"挺玄学的。不就是干活嘛，能快多少？

后来发现，所谓的效率翻倍，根本不是打字速度翻倍，而是那些让你停下来想"这玩意儿放哪了"、“这命令怎么写来着"的时刻，少了一大半。

就像做饭。新手炒菜，锅热了才发现葱姜蒜没切，手忙脚乱找菜刀，切完发现酱油在另一个柜子里，等找到酱油，锅都凉了。老手呢？食材摆好，调料就位，从头到尾行云流水。

效率的差距不在手速，在减少"停下来想一想"的次数。

把我这几年养成的习惯归纳一下，其实就三条：

第一，让环境可预测。 终端永远开着，分成固定的Tab：主战场、日志监控、Git操作、临时实验。所有项目统一目录结构：src/放代码，tests/放测试，scripts/放脚本。就像超市货架，番茄酱永远在调料区，闭着眼睛都能找到。

第二，记流程不记命令。 日常开发就这几步：拉分支、写代码、提交、rebase、推送。排查问题就这几步：看日志、缩小范围、最小复现、定位修复。具体命令可以查，但流程得刻在脑子里。就像开车，你记的是"我要左转”，不是"方向盘转15度"。

第三，消灭上下文切换。 终端能干的事儿不开GUI，键盘能完成的不碰鼠标，工作时关掉所有通知。GUI会打断思考：眼睛移开、找按钮、点击、等动画、眼睛移回来、重新进入状态。这一套下来，脑子里装的东西就忘了一半。

日志优先于调试器。 出问题先别急着打断点，看看日志：

tail -n 100 app.log                    # 看最近的
grep -i "error\|exception" app.log     # 筛错误
grep "request-id-xxx" app.log          # 追踪特定请求

日志讲故事，调试器回答问题。你得先知道问题大概在哪儿，才能问对问题。

小脚本胜过大工具。 统计关键词出现次数、找最近修改的文件、批量替换字符串，几行脚本就搞定：

grep -R "$1" src/ | wc -l              # 统计关键词
ls -lt src/ | head -6                  # 最近修改的文件
grep -rl "$1" src/ | xargs sed -i "s/$1/$2/g"  # 批量替换

丑是丑了点，但能用就行，用完就扔。

做两次就自动化。 每天早上拉代码、启服务、开日志，写成脚本一键搞定：

cd ~/projects/main && git pull origin main
npm run dev &
tail -f logs/app.log

自动化不是为了偷懒。好吧，主要是为了偷懒。但更重要的是，它消灭了"忘了某一步"的可能性。

工具收集癖。 以前我特别喜欢装各种工具，装着装着一大堆，真要用的时候想不起来叫什么名字。后来学乖了，能用几行脚本解决的，就别装工具。

过度优化终端。 换主题、装插件、配别名，折腾半天结果效率没提升多少，还多了一堆要维护的配置。够用就行，别把工具当目的。

强迫症统一。 有些项目就是目录结构乱，接手之后非要重构成自己习惯的样子。其实适应几天就好了，重构的时间够你干完活了。

三句话：

下一步可以试试：给自己的终端分几个固定Tab，把重复做的事情写成脚本，工作时把通知关掉。

最快的开发者，不是懂最多命令的人，而是消灭了最多摩擦的人。

觉得有用的话：