摘要：作为程序员，我信奉"能自动化就不手动重复"的原则。这篇文章分享 5 个我日常工作中高频遇到的琐碎场景——从日志清洗到时区管理，从注意力调度到编码原理的理解——以及我目前最顺手的处理方案，包含命令行和在线工具两种思路的对比。
写在前面
我电脑上装了很多「重型」工具：IDE、Docker、各种 CLI……但日常工作中真正消耗时间的，往往是那些小到不值得写脚本、却又不得不反复处理的琐事。
比如：
- 从网页复制一段代码，带了一堆空行和奇奇怪怪的缩进
- 跟海外同事约会议，心里默算"旧金山现在几点"
- 看英文技术文档，遇到
32°F或100MB/s时愣一下 - 想专注写代码，结果刷了两小时手机
这篇文章不是工具清单，而是我面对这些场景时的思考路径和解决方案。每种场景我都会给出「命令行方案」和「在线工具方案」，你可以按需选择。
一、日志/文本清洗：sed/awk 不是唯一解
场景：后端同事甩过来一段 500 行的报错日志，要我帮忙找出其中所有唯一的异常类型，按出现频次排序。
命令行方案（经典但有点重）
# 提取异常类型、去重、计数排序
cat error.log | grep -oP '\w+Exception' | sort | uniq -c | sort -nr
这套组合技确实强大，但有个前提：你得先打开终端、cd 到对应目录、确保日志文件在本地。很多时候日志是在浏览器控制台、钉钉消息或者邮件里看到的，复制到终端还要处理引号转义，反而更麻烦。
我的实际选择：在线文本处理
对于这种「复制即处理」的场景，我现在更倾向用一个在线的文本处理工具。核心逻辑很简单：把常用的文本操作做成按钮，省去记忆正则和管道语法的成本。
我常用的几个操作：
| 操作 | 命令行等价物 | 适用场景 |
|---|---|---|
| 去重行 | sort | uniq | 日志去重、IP 去重 |
| 空行清理 | sed '/^$/d' | 复制网页代码后的格式化 |
| 大小写切换 | tr '[:lower:]' '[:upper:]' | 变量名规范化 |
| 行排序 | sort | 枚举值整理、列表排序 |
| 正则替换 | sed -E 's/.../.../g' | 批量替换变量前缀 |
我的判断标准：如果处理的是本地文件且逻辑复杂，用脚本；如果只是临时处理一段从别处复制的文本，在线工具更快。
二、跨时区协作：时间换算比想象中更烦
场景：你参与的开源项目维护者分布在旧金山、柏林、新加坡三地，你要发一条关于线上故障的 issue，想知道现在是不是对方的工作时间。
我之前的工作流：
- 打开搜索引擎
- 搜索 "San Francisco time now"
- 在心里算夏令时是否生效（每年 3 月和 11 月还要确认一次）
- 对比北京时间，得出结论
这一套下来至少要 30 秒，而且下次还要重复。
我的解决方案
用一个支持多城市并行显示的世界时钟，把常打交道的城市固定在上面。好的世界时钟工具应该满足：
- 自动处理夏令时切换（这个很重要，手动算很容易错）
- 用图标区分白天/夜晚（一眼就知道对方是不是在睡觉）
- 日期和星期同步显示（避免"你那边已经周六了"的尴尬）
一个小发现：很多服务器的定时任务日志用的是 UTC 时间，配合世界时钟看一眼，能快速定位故障发生的本地时间。
三、番茄工作法：程序员的注意力急救
场景：你坐下准备重构一段核心模块，刚理清思路，钉钉弹了一条消息。回复完回来，忘了刚才想到哪了。再理清，又弹了一条……
这叫上下文切换成本。有研究说程序员被打断后，平均需要 23 分钟才能回到之前的心流状态。
番茄工作法的程序员适配版
传统的番茄钟是 25 分钟工作 + 5 分钟休息。但我实际用下来，对程序员来说**「正计时」模式**比固定时长更实用——因为你根本不知道这个 bug 要修多久，强行 25 分钟中断反而破坏心流。
我比较在意的几个功能点：
- 打断记录：不是简单的计时，而是记录"这次专注被打断了几次"。这个数据比"我工作了多久"更有价值——它能帮你发现是哪个时段最容易被打扰
- 任务关联：把计时和具体任务绑定，比如"修复订单状态机 bug"，而不是泛泛的"写代码"
- 数据统计：周维度看自己哪段时间效率最高，据此调整工作安排
用了一周后，我的数据显示：下午 3~5 点的打断次数最少，连续专注时间最长。于是我把需要深度思考的重构工作都挪到了这个时段，会议和沟通放在上午。
白噪音是个加分项。我习惯开「雨声」，对屏蔽开放式办公区的噪音很有效。
四、单位换算：技术文档里的那些「坑」
场景：你在看一篇英文技术博客，作者说"The file size is about 100MB"，你想知道这个文件下载需要多久。或者看到 32°F，想知道要不要加外套（不是）。
程序员最常踩的单位坑
1. 数据存储单位：MB vs MiB
硬盘厂商用十进制（1 GB = 10^9 bytes），操作系统用二进制（1 GiB = 2^30 bytes）。这就是为什么你买的 1TB 硬盘，电脑上只显示约 931GB。
1 TB（厂商） = 1,000,000,000,000 bytes
1 TiB（系统）= 1,099,511,627,776 bytes
1 TB ≈ 0.909 TiB
2. 网络带宽 vs 下载速度
运营商说的 "100M 宽带" 是指 100 Mbps（兆比特每秒），而浏览器显示的下载速度是 MB/s（兆字节每秒）。差了一个 8 倍的关系：
100 Mbps = 100 / 8 = 12.5 MB/s
所以下载一个 2GB 的 Docker 镜像，在 100M 带宽下理论需要：
2048 MB / 12.5 MB/s ≈ 164 秒 ≈ 2.7 分钟
3. 温度
华氏度转摄氏度，不要记公式，记住两个锚点就行：
32°F = 0°C（水的冰点）
212°F = 100°C（水的沸点）
一个好的单位换算工具，核心价值不是"能算"，而是输入一个值，所有相关单位实时联动，省去反复切换换算方向的步骤。
五、摩斯电码：从点划看「编码」的本质
场景：CTF 比赛遇到一串 .... . .-.. .-.. ---，你知道是摩斯电码，但手头没有解码工具。
摩斯电码 = 最早的字符编码方案
很多人把摩斯电码当成「谍战片里的东西」，但其实它跟程序员每天打交道的 ASCII、UTF-8、Base64 是同一类东西——都是字符编码方案。
它们的共同本质：建立一种映射关系，把「人类可读的信息」转换成「另一种符号系统」。
| 编码方案 | 符号集 | 用途 |
|---|---|---|
| 摩斯电码 | 点(·) 划(−) 空格 | 电报通信 |
| ASCII | 7 位二进制 | 计算机早期字符表示 |
| Base64 | A-Z a-z 0-9 + / | 二进制数据文本化 |
| URL Encode | %XX | URL 特殊字符转义 |
摩斯电码的设计其实很有讲究：
- 常用字母更短：
E是一个点(·)，T是一个划(−)，因为它们在英语中出现频率最高 - 编码不等长：不像 ASCII 固定 8 位，摩斯电码是变长编码，靠空格分隔字符和单词
- 容错设计：点和划的音频特征差异很大，在嘈杂的电报线路中也能区分
这些设计思想，在现代编码方案里依然能看到影子。比如霍夫曼编码（数据压缩）的核心思想——高频字符用短编码——跟摩斯电码如出一辙。
一个有趣的实验
试着理解这段摩斯电码：
... --- ...
这是国际通用的求救信号 SOS。选这三个字母不是因为它们是某个单词的缩写，而是因为摩斯电码中这三个字母的序列（点-点-点 划-划-划 点-点-点）非常容易识别和记忆，甚至在视觉上也是对称的。
总结：我的工具选择原则
写完这 5 个场景，我想总结一下我的工具选择逻辑：
| 场景 | 我的选择 | 理由 |
|---|---|---|
| 本地文件批量处理 | 命令行脚本 | 可复用、可自动化 |
| 临时文本清洗 | 在线工具 | 打开即用，无需环境 |
| 跨时区时间管理 | 在线世界时钟 | 可视化直观，自动处理夏令时 |
| 专注工作 | 在线番茄钟 | 跨设备同步，数据可统计 |
| 单位换算 | 在线换算器 | 多单位实时联动 |
| 编码学习/趣味 | 在线摩斯电码 | 即时反馈，支持音频 |
核心原则就一条：重复超过 3 次的事，值得找一个工具解决；不值得为了一次性任务装一个软件。
顺便一提
这 5 个工具我平时主要在 工具派 上用，感兴趣的话可以搜一下。
你处理这些场景时有什么更好的方案？评论区聊聊 👇
