效率工具不是越多越好，而是越“懂你”越好
凌晨一点半，窗外的上海早已安静下来，只有键盘敲击声和偶尔传来的外卖电动车呼啸而过。作为刚升任技术组长没多久的“老新人”，我发现自己越来越依赖那些能让我少写重复代码、少点几下鼠标的效率工具。毕竟，白天被产品经理追着改交互、被测试催着修 Bug、被运维问“你们前端怎么又打爆接口了？”，晚上还得抽空看团队成员的 PR，哪还有时间手动干那些机械活？
说起来，这半年带团队的经历让我对“效率”两个字有了新的理解——不是跑得更快，而是把力气花在刀刃上。而效率工具，就是那把帮你磨刀的人。
从一次“爬虫救急”说起
去年双11前两周，我们接到一个紧急需求：需要抓取竞品网站的商品价格和促销信息，做动态比价分析。后端同事人手紧张，直接甩锅（哦不，是“信任”）给我们前端：“你们不是会写 JS 吗？用 Puppeteer 跑个爬虫很快的。”
我当时内心是拒绝的——前端搞爬虫？这不是跨界打劫吗？但 deadline 不等人，只能硬着头皮上。
一开始我用最原始的方式：手动复制粘贴 + Excel 处理。结果第二天就被产品总监灵魂拷问：“就这？数据才 50 条？” 我当场社死。
于是赶紧祭出 Puppeteer + Cheerio 组合拳。写了个脚本自动登录、翻页、提取结构化数据，再用 csv-writer 输出成 CSV。整个过程自动化后，5000 条数据半小时搞定。
// 简化版爬虫核心逻辑
const puppeteer = require('puppeteer');
const createCsvWriter = require('csv-writer').createObjectCsvWriter;
(async () => {
const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
await page.goto('https://competitor.com/sale', { waitUntil: 'networkidle2' });
const products = await page.evaluate(() => {
return Array.from(document.querySelectorAll('.product-item')).map(el => ({
name: el.querySelector('.title').innerText,
price: parseFloat(el.querySelector('.price').innerText.replace('¥', '')),
link: el.querySelector('a').href
}));
});
const csvWriter = createCsvWriter({ path: 'products.csv', header: [
{ id: 'name', title: 'NAME' },
{ id: 'price', title: 'PRICE' },
{ id: 'link', title: 'LINK' }
]});
await csvWriter.writeRecords(products);
await browser.close();
})();
这次经历让我意识到：效率工具的价值，在于把“人肉操作”变成“一键执行”。从此我对这类工具上了瘾。
我的效率工具箱：不是堆砌，而是组合
很多人一提效率工具，就疯狂安利 Notion、Obsidian、Raycast、Alfred……但说实话，工具太多反而会成为负担。我现在的原则是：只保留那些真正融入我工作流的工具。
1. 终端增强：Zsh + Oh My Zsh + zoxide
以前我用 Bash，每次 cd ../../../project/src/utils 都想砸键盘。现在用了 zoxide，只要输入 z utils 就能秒进目录。配合 Oh My Zsh 的 git 插件，当前分支、是否有未提交变更一目了然。
# .zshrc 配置片段
eval "$(zoxide init zsh)"
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)
2. 代码片段管理：VS Code Snippets + Alfred（Mac）
作为前端，天天写 useEffect, useState, 动画钩子，手写太慢。我把常用逻辑封装成 VS Code 自定义 Snippet，比如：
{
"Animate In View": {
"prefix": "animInView",
"body": [
"const [isVisible, setIsVisible] = useState(false);",
"useEffect(() => {",
" const observer = new IntersectionObserver((entries) => {",
" entries.forEach(entry => {",
" if (entry.isIntersecting) {",
" setIsVisible(true);",
" observer.disconnect();",
" }",
" });",
" });",
" observer.observe(document.querySelector('#${1:targetId}'));",
"}, []);"
]
}
}
在 Mac 上，我还用 Alfred 快速搜索代码片段、文档链接，甚至直接执行 shell 命令。比如输入 ip 就能复制本地 IP，省去 ifconfig 的麻烦。
3. 自动化脚本：Taskfile 替代 Makefile
很多团队用 Makefile 管理项目命令，但语法反人类。我最近在团队推广 Taskfile，YAML 写起来清爽多了：
# Taskfile.yml
version: '3'
tasks:
dev:
desc: 启动开发服务器
cmds:
- pnpm run dev
build-prod:
desc: 构建生产包并上传 CDN
cmds:
- pnpm run build
- aws s3 sync dist/ s3://my-cdn-bucket --delete
lint-fix:
desc: 自动修复 ESLint 和 Prettier 问题
cmds:
- pnpm run lint --fix
- pnpm run format
执行 task dev 比记 pnpm run dev 更顺手，而且新人一看就懂。
工具选型的三个“不要”
在带团队的过程中，我也踩过不少坑。总结下来，选效率工具有三个“不要”：
| 原则 | 反面案例 | 正确做法 |
|---|---|---|
| 不要为了新而新 | 强推某小众终端模拟器，结果团队一半人不会配 | 优先选择社区成熟、文档齐全的工具 |
| 不要忽视学习成本 | 用复杂的低代码平台生成表单，结果调试比手写还累 | 工具带来的收益 > 学习+维护成本 |
| 不要脱离业务场景 | 为简单项目引入 Webpack 5 Module Federation | 小项目用 Vite + 原生 ES Modules 足够 |
上周五晚上，组里一个新人兴奋地给我看他用某个 AI 代码生成插件写的组件，结果 props 类型全错，事件回调没防抖，动画卡成 PPT。我哭笑不得：“兄弟，AI 是辅助，不是替身。代码人生，终究是你自己写的。”
效率的本质：减少上下文切换
其实，所有效率工具的核心目标，都是减少上下文切换。每次你从 IDE 切到浏览器查文档，从终端切到 Slack 回消息，大脑都要重新加载“工作缓存”。而好的工具，能让你保持心流状态。
比如我现在写文章时，用 Typora + 自定义 CSS 主题，所见即所得；查资料用 Raycast 的 Browser Search，不用开新标签页；代码示例直接在 VS Code 里写完复制过来——整套流程丝滑如德芙。
甚至我的租房选址也体现了这一点：公司步行 10 分钟，省下通勤时间，晚上就能多 debug 两小时（或者多睡两小时，看心情）。
最后一点开发心得
效率工具不是银弹，它解决不了架构混乱、需求反复、沟通低效这些根本问题。但在确定的方向上，它能让你跑得更快、更稳。
作为技术组长，我现在的任务不仅是自己高效，还要帮团队建立可持续的高效习惯。比如我们规定：凡是重复操作超过三次，就必须自动化；PR 里禁止出现“手动测试通过”，必须附上自动化测试或脚本验证。
前几天，组里一个同事用 Puppeteer 写了个自动回归测试脚本，覆盖了我们最头疼的支付流程。上线后，线上事故率降了 40%。那一刻我觉得：所谓综合效率提升，不是一个人快，而是一群人一起少踩坑。
所以，别盲目追新工具。问问自己：它真的让我少做了什么？少想了什么？少骂了产品经理几句？
如果答案是肯定的，那就留下它。否则，果断删掉——你的注意力，比硬盘空间更宝贵。
深夜码字完毕，咖啡已凉。 但想到明天又能用脚本自动跑日报，突然觉得生活充满希望。
共勉，各位在代码人生路上摸爬滚打的战友。
评论 0