做这个项目纯属被自己的注意力涣散给逼出来的。作为一个需要长期对着屏幕写东西、看数据、回消息的人我发现自己每天真正能沉下心干活的时间其实少得可怜。手机是静音的通知是关掉的但电脑上那些隐形的“分心陷阱”——某个社交网站的小红点、某个新闻弹窗、甚至只是顺手点开的某个视频标签页——都能让半小时的工作被拉伸成三个小时。我试过各种时间管理App、番茄钟、白噪音但问题是提醒结束的时候很爽提醒开始的时候却管不住自己。所以后来我想干脆做一个叫“buzz”的小工具它不搞花哨统计不搞积分激励唯一的任务就是在你分心的瞬间用一次短促的“嗡”声把你拽回来。这个项目很小但做完之后我发现它背后的逻辑和很多“自我管理类工具”完全不一样——它不是靠“自律”逼你而是靠“条件反射”改变你。这篇文章就把我从立项到落地、从踩坑到打磨的全过程拆开来讲如果你也有类似的需求或者也想自己动手写一个类似的效率小工具可以直接照着复现。1. 项目整体设计与思路拆解先说说“buzz”这个项目的核心定位。我给它定了一句话一个只负责发出“提醒性嗡嗡声”的桌面端轻量工具。它的核心应用场景有两个一是你在写代码、写文档、做设计等需要连续专注的工作时它会默默在后台运行一旦检测到“当前活动窗口切换到娱乐、社交、新闻等非工作类应用”就立刻播放一声短促的蜂鸣二是配合番茄钟使用——你专心工作了25分钟它会用一声长音告诉你“可以休息了”但休息结束后你回到工作状态时它又会用一声短音确认“回来了”。这两个场景本质都是利用声音信号形成一个“无意识提醒”不需要你去看任何面板也不需要你手动去按什么键。当时我给自己列了几个硬性要求现在回头看这些要求决定了整个项目的走向足够轻量内存占用尽量控制在50MB以内不能像某电邮箱一样动不动上百MB启动之后必须安静没有主窗口只在菜单栏或系统托盘放一个小图标声音要短、要干净最好是一声类似老式电话震动或电子表闹铃的蜂鸣而不是一段音乐判定“分心”的逻辑要简单粗暴宁可有误报也不能漏掉真正的分心时刻不用联网不做云同步不收集任何数据所有记录只留本机最好可以跨平台——因为我主力机是Windows但有时也会用macOS写东西。基于这几个要求我开始在“技术选型”上做取舍。这里有必要说一个我后来踩了坑才悟出来的道理这种小工具千万不要选“重框架”。一开始我天真地想过用Electron来做因为前端资源多、界面好画。但Electron本身就是个浏览器套壳随便一个空项目内存轻松上200MB完全违背了我“轻量”的初衷而且它对于一个“没有主界面”的托盘程序来说纯属杀鸡用牛刀。所以我很快排除了它转向了Python加原生系统API的方案。选Python的原因其实也很朴实写检测窗口和播放声音的逻辑Python有几个很成熟的库可以直接调系统底层接口而且代码量很短加上我自己的主力开发环境一直有Python 3.10在跑省去了一堆环境折腾。播放声音这一块Windows下可以用现成的winsound库macOS下可以用afplay命令都不用额外装什么东西。检测当前窗口名字Windows下可以用pywin32的GetForegroundWindow加GetWindowTextmacOS下可以用AppKit里的NSWorkspace获取当前激活的应用名。这样下来项目本身不用引任何重型第三方依赖唯一的重量级依赖就是pywin32和pyobjc也都是各自平台上的标准绑定库。但光有用Python写的核心逻辑还不够。我同时想清楚了另一个关键点——这个项目一定要有“配置自由度”。每个人的“分心应用列表”完全不同有人刷B站是分心有人看GitHub是工作有人看新闻是分心有人做舆情监测恰恰需要挂着新闻页面。所以我把“什么是分心应用”设计成了一个可编辑的清单而不是硬编码写死在代码里。用户自己创建一个简单的文本文件一行一个应用名或窗口标题关键词程序启动时读取这个清单运行时逐秒检查当前活动窗口一旦匹配就触发提醒。这个设计后来被证明非常关键因为很多人拿到工具第一反应就是问“能不能把XX加进去”有了这个清单用户根本不用等作者更新版本自己就能适配自己的使用习惯。整个项目一开始拉起来的骨架是这样的buzz/ ├── buzz_client.py # 主程序入口负责事件循环、窗口检测、声音触发 ├── config.ini # 配置文件包含音量、检测间隔、声音类型等 ├── blocklist.txt # 分心应用关键词清单一行一个关键词 ├── sounds/ # 存放提示音的目录默认提供两种音效 │ ├── tap.wav │ └── long.wav ├── README.md └── requirements.txt这个结构非常简单但是足够跑通一个“最小可用版本”。我在整个项目里都不打算引入所谓的“工程化体系”连setup.py都没写因为它的定位就是“复制到任何一台电脑上装好依赖就能跑”而不是一个需要被分发安装的正式产品。换句话说我写它是为了“自己用着爽”其次是让有类似需求的人能拿到源码看懂、改改就能用。2. 核心细节解析与实操要点“buzz”这个项目看着简单但真正动起手来有几个核心细节必须处理好否则你会得到一个不是吵死自己、就是根本不起作用的废物工具。我踩了不少坑现在把它们拆开来说重点。2.1 声音本身蜂鸣不是“叫声越大越好”声音是整个工具的“输出媒介”也是最容易被忽略、却最深影响体验的部分。很多人做提醒工具喜欢直接放一段轻快的MP3音乐或者干脆用系统默认的“叮咚”声。但在实际专注场景下音乐只会让你更分心默认系统提示音又会和微信、短信混淆导致大脑很快脱敏——听到“叮”一声你以为有人找你顺手就切去微信了等你发现只是buzz在提醒你又已经过了半分钟。所以我设计了两个完全不同的音效一个是“短促蜂鸣”时长控制在0.3秒左右频率在1000Hz上下听起来像一个非常短促的“嘀嗒”另一个是“双段长音”用于番茄钟结束频率相同但连续响两下每段0.5秒中间隔0.2秒。短音的作用是打断你长音的作用是宣告阶段结束。两者有明确的区分度不会混淆。在实现上我没有用什么音频合成库而是直接生成两个WAV文件放在sounds/目录里。生成WAV的代码其实非常简单甚至不需要图形界面几行Python就能搞定核心就是用wave和struct模块把正弦波数据写进去。这里有个经验人耳对1000Hz左右的纯音最敏感但连续播放超过2秒就会开始烦躁所以提醒音越短越好宁可多几次短提醒也不要一次放个3秒钟的绵长音效。代码大致长这样import wave import struct import math def generate_tone(filename, frequency1000, duration0.3, volume0.5, sample_rate44100): with wave.open(filename, w) as f: f.setnchannels(1) # 单声道就够没必要立体声 f.setsampwidth(2) # 16位PCM f.setframerate(sample_rate) for i in range(int(duration * sample_rate)): # 简单的正弦波没有任何包络处理短音够用 value int(volume * 32767.0 * math.sin(2 * math.pi * frequency * i / sample_rate)) f.writeframes(struct.pack(h, value)) generate_tone(sounds/tap.wav, duration0.3) # 短促蜂鸣 generate_tone(sounds/long.wav, duration0.5, volume0.45) # 长音的基础音实际使用时我在“长音”的实现里做了一点变化用两个连续的tap.wav中间加0.2秒静音拼在一起而不是单独生成一个1.2秒的长音文件。这样做的好处是当用户觉得长音太吵时只要调整短音的音量长音也会跟着变不用分别调两套音量。这个设计思路是从“统一音源”的实践里来的也算是后期迭代的一个小优化。播放声音的代码在每个平台上略有差异。Windows下我直接用标准库的winsound.PlaySound(sounds/tap.wav, winsound.SND_FILENAME | winsound.SND_ASYNC)这里注意一定要加SND_ASYNC否则播放声音的调用会阻塞主循环导致下一轮检测被延后。macOS下我就直接调用命令行播放器import subprocess import time def play_tone(path): # macOS用afplay播放异步运行 subprocess.Popen([afplay, path], stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL) # Windows下用winsound的异步模式 if os.name nt: import winsound def play_tone_sync(path): winsound.PlaySound(path, winsound.SND_FILENAME | winsound.SND_ASYNC) else: def play_tone_sync(path): subprocess.Popen([afplay, path], stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL)这里有一个很重要的领悟很多“效率工具”做残了不是核心逻辑不对而是反馈感太滞后。如果你按下开始键2秒钟后才出声音大脑根本建立不了“切到豆瓣马上有干扰声”的条件反射。所以在设计时我把检测间隔压得很短甚至可以让用户自行设定到500毫秒一次。一旦切到分心页面几乎在瞬间就会响起来没有任何迟疑。这种“瞬时反馈”是工具能起效的前提。2.2 分心检测怎么判断“你正在做正事”“buzz”最核心的技术判断是怎么知道用户当前正在用哪个应用以及怎么判断这个应用属于“分心类”。这部分是很多类似工具设计得最粗鲁的地方——有的直接统计你整个系统的使用时长有的要求你手动填写“工作开始时间”有的干脆用摄像头看你是否坐在屏幕前。这些方案要么太笨重要么太侵犯隐私。我最后用的是最简单也最有效的一个办法读取当前“处于焦点的顶层窗口标题”然后和分心关键词清单做匹配。在Windows下这段逻辑用pywin32就能实现import win32gui def get_active_window_title(): hwnd win32gui.GetForegroundWindow() return win32gui.GetWindowText(hwnd)在macOS下则用AppKit和Quartz配合from AppKit import NSWorkspace from Quartz import CGWindowListCopyWindowInfo, kCGWindowListOptionOnScreenOnly, kCGNullWindowID def get_active_window_app(): ws NSWorkspace.sharedWorkspace() return ws.activeApplication()[NSApplicationName]但这里有一个很现实的坑窗口标题比应用名更需要做敏感词匹配。为什么因为同一个Chrome窗口可能同时开着工作邮件和微博。如果你只判断“当前激活的应用是Chrome”那就没法区分用户是在查资料还是在摸鱼。所以检测分心不能只靠“应用名”还得结合“窗口标题里的关键词”。我的匹配逻辑是两级判定第一级窗口标题或应用名里是否存在明确的工作关键词比如“工单”、“需求”、“日报”、“Postman”、“VS Code”、“Word”、“Excel”等如果有直接视为“工作状态”不触发提醒第二级如果不在工作关键词里再去匹配分心清单blocklist.txt里的关键词只要命中任意一个就触发提醒。这种“白名单先行、黑名单兜底”的设计比单纯的黑名单要人性化得多。举个例子你的分心清单里写了“Bilibili”但如果你恰好用Bilibili查一个开源项目的视频教学而那个视频标题里含有“教程”两个字那么第一级工作关键词会把“教程”命中从而不触发提醒。虽然这个逻辑不完美但“宁可不提醒也不要误提醒”因为误提醒会让你把工具关掉而漏提醒只是让你偶尔多划几次水。两害相权取轻。在实际实现时我会同时读取“应用名”和“窗口标题”把它们连成一个字符串后统一做关键词匹配。代码用一个简单的循环遍历清单即可不需要引入多少复杂的规则引擎——小工具就要有“小”的样子能用线性扫描解决的就不上正则能用正则解决的就不上机器学习。2.3 配置文件的取舍先做出来再改舒服项目里必须有配置文件但如果你一开始就想着做一套“界面精美、选项极多”的配置面板大概率会陷入改动代码两小时、调界面一晚上的泥潭。我的做法很简单用config.ini管全局参数用blocklist.txt管分心关键词所有配置都允许热加载。config.ini里的主要参数有[general] check_interval_ms 800 ; 检测间隔单位毫秒越小越灵敏但更费CPU volume 0.5 ; 音量0到1之间 remind_tone tap.wav ; 分心提醒音 finish_tone long.wav ; 番茄钟结束音 [work_keywords] enabled true ;; 注意分号后面是注释 ;; 可自行增删一行一个命中任意一个即视为“工作状态”我做了定期重读配置文件的设计每次检测循环跑完一轮就检查一下文件的修改时间一旦发现更改就重新加载。这样做的好处非常实际你不需要为了改一个关键词而重启整个进程随时打开blocklist.txt加一行下一轮检测就能生效。这个“热加载”设计在初期其实没做后来是因为我自己嫌重启麻烦才加的但实测下来非常值得——很多用户拿到工具后第一件事就是想自己定制关键词如果每次都要改代码重启传播难度就会大得多。还有一个小细节check_interval_ms我建议设置在500到1000毫秒之间太短了会让CPU风扇狂转太长了会让提醒变得迟钝。我之前试过100毫秒的间隔结果在开发机上CPU占用飙到了8%以上这还只是一个检测程序完全不可接受后来调到800毫秒CPU使用率降到0.3%以下感知上几乎没有延迟。这个平衡点各位在实际使用中可以根据自己电脑的配置来微调。3. 实操过程与核心环节实现讲完设计来说实际动手的过程。这一部分我尽量像当时写代码那样按步骤走每个环节都给出可以直接参考的实现方式。3.1 环境准备与启动逻辑先交代环境Windows 11专业版Python 3.10.9没有用conda直接在全局环境装依赖。我建议你也用Python 3.10或3.11Python 3.12在某些老的pywin32版本上可能会有兼容性问题别给自己找麻烦。安装依赖只要两行命令pip install pywin32 # macOS用户则执行 # pip install pyobjc如果你的系统里同时装了多个Python版本记得确认pip指向的版本和启动脚本时用的Python是同一个不然会反复出现ModuleNotFoundError。这个坑我刚开始就踩过后来学乖了直接用python -m pip install来避免歧义。启动逻辑上我期望的是“双击即运行全程无感”。所以在主入口处做了以下几件事检查配置文件是否存在如果不存在就自动生成一套默认值启动一个系统托盘图标方便用户随时退出或重启检测进入事件循环一直轮询当前窗口状态直到用户手动退出。这里要特别说一下托盘图标。很多命令行程序退出只能去任务管理器里找进程这很不方便。pywin32自带一个win32gui的托盘消息循环示例我照着改了一个精简版只保留一个“退出”菜单。macOS下用rumps库也能轻松创建菜单栏应用不过那个库是第三方依赖我当时为了“轻”没有引入只是在macOS上用一个带菜单的pyobjc原生实现稍微多一点代码但能少维护一个依赖。托盘部分的Windows实现大致是这样import pythoncom import win32gui import win32con class TrayApp: def __init__(self, titlebuzz): self.title title self.hwnd None self.tray_id None def create(self): message_map { win32con.WM_DESTROY: self.on_destroy, } self.hwnd win32gui.CreateWindow( 0, buzzTrayWindow, self.title, 0, 0, 0, win32con.CW_USEDEFAULT, win32con.CW_USEDEFAULT, 0, 0, None, 0 ) win32gui.UpdateWindow(self.hwnd) self.tray_id 1 win32gui.Shell_NotifyIcon( win32con.NIM_ADD, ( self.hwnd, self.tray_id, win32gui.LoadIcon(0, win32con.IDI_APPLICATION), 0, 0, 0, self.title ) ) # 简化版的菜单只有“退出” menu win32gui.CreatePopupMenu() win32gui.AppendMenu(menu, win32con.MF_STRING, 1024, 退出) win32gui.Shell_NotifyIcon(win32con.NIM_ADD, self._notify) pythoncom.PumpMessages()这段代码其实没那么难理解它就是借用系统托盘API挂一个图标然后进入消息泵循环。如果你对Windows底层不熟悉照抄即可暂时不用深究。3.2 检测循环从“获取窗口”到“发提醒”的主流程主循环是整个程序的灵魂。我用循环加sleep的方式实现没有用复杂的定时器回调。每轮依次执行以下操作读取当前活跃窗口的标题和所属应用名检查“工作关键词”白名单命中就跳过检查“分心关键词”黑名单命中就触发提醒记录一条本机日志方便事后复盘休眠指定毫秒数进入下一轮。判断逻辑经过几次迭代最终长这个样子import time from threading import Lock def run_loop(stop_event, config, blocklist_manager): while not stop_event.is_set(): try: title, app get_active_window_info() if not title and not app: time.sleep(0.5) continue combined f{app} {title} # 1. 白名单优先 if config.is_work_context(combined): # 记录一条最近工作信息为将来扩展做准备 state.last_work_time time.time() time.sleep(config.check_interval_ms / 1000.0) continue # 2. 黑名单匹配 if blocklist_manager.is_distracted(combined): if time.time() - state.last_alert_time 5: play_tone(config.remind_tone) state.last_alert_time time.time() log_distraction(combined) time.sleep(config.check_interval_ms / 1000.0) except Exception as e: debug_print(loop error, e) time.sleep(1)这里有几个细节值得单独说明。首先last_alert_time这个变量是后来才加的目的是做防重复提醒。如果用户切到了分心页面但没有切走那理论上每一轮检测都会命中黑名单如果每次都响人很快就崩溃了。所以我设定了一个5秒的冷却时间——同一轮“持续分心”状态下最多每5秒提醒一次。实际上这个提醒频率也偏高后来我建议用户把冷却时间调到15秒左右保留“被拉住”的感觉又不会让人想砸电脑。其次log_distraction这个日志函数很有用。它会把每次触发提醒的时间、当时的窗口标题记到一个文件里。晚上复盘的时候你可以清楚地看到自己一天到底摸了多少次鱼、都在哪里摸的。我有一个朋友用这个日志做出一份奇葩周报把自己每天分心次数最多的三个应用标黄然后和团队说“这是我本周要消灭的三个目标”一下子把效率工具玩成了团队KPI。还有一点try-except块的粒度要注意。我不建议在每一轮循环里使用巨大的try-except包住所有逻辑否则一旦某轮抛出异常你可能一直处于错误恢复的循环里。只捕获你预期可能出现的异常比如窗口句柄获取失败、文件被占用等其余的让它彻底暴露出来至少能让开发者看到清晰的报错信息。3.3 用“彩排”模式跑通全流程工程师有个习惯写完代码第一件事不是“真刀真枪干”而是先跑一遍“彩排”。我的做法是在程序里内置一个“演示模式”参数--demo它不进行真实窗口检测而是模拟一段预定的窗口切换序列比如“工作5秒、切到B站3秒、工作3秒、切到豆瓣5秒”然后观察提醒是否在正确的时机触发。这个模式帮了我大忙——它排除了“环境问题引起的假失败”。比如有一次我明明写了提醒逻辑但运行时死活不出声。彩排模式下很快就发现问题声音文件用了相对路径但工作目录不是项目根目录导致路径找不到。这种bug在真实场景下很难排查还可能被误认为是“窗口检测没生效”。彩排模式的实现也简单无非是循环里读一串预定的假窗口数据走一遍完整的判定流程。但它带来的价值是巨大的任何一次修改都可以在2分钟内验证预期行为而不是改一点、真摸鱼试半天。4. 常见问题与排查技巧实录这把工具自己做了不少天也把自己当小白鼠使用了不短时间。中间遇到的问题五花八门但大多是同类工具使用者会普遍踩中的我整理成了表格方便直接对照。4.1 典型问题速查表问题可能原因排查与解决方式无论怎么操作都不出声音量设置为0、winsound在远程桌面下不可用、音频文件路径错误先跑一遍--demo彩排模式若能出声说明主逻辑没问题检查config.ini里的volume在本地桌面重新登录试一次提醒太频繁吵得没法干活冷却时间设置太短分心清单里含有工作也会出现的通用词把check_interval_ms调到800以上把冷却时间调到10秒以上清理blocklist.txt去掉“Chrome”这类太泛的关键词切到分心页面后没有反应白名单把当前内容误判成工作状态窗口标题关键词匹配不到检查work_keywords白名单临时全部清空测试换用更精确的分心关键词比如把“B站”换成具体UP主名称或频道关键词CPU占用很高风扇狂转检测间隔设得太短把check_interval_ms从100改到500~1000毫秒检查是否有旧进程重复运行任务管理器里应该只有一个buzz进程macOS下用了afplay但播放有延迟有些macOS版本的声音服务初始化较慢在程序启动时先播放一次静音WAV预热音频服务或者改用PyObjC的NSSound播放延迟会更低日志文件越来越大磁盘吃紧没有做日志轮转加一段“超过5MB自动清空或按日期切割”的逻辑如果你只想用几天直接手动删掉日志文件即可4.2 几个毫无保留的独家避坑细节文件名里的关键词一定要“去空格、统一大小写”。Windows的窗口标题里经常有全角空格、“-”和“—”如果你在blocklist.txt里写的是“哔哩哔哩”而窗口标题里写的其实是“Bilibili”那就匹配不上。我的做法是在匹配前统一lower()并且把常见标点符号替换成空格否则很容易出现“明明分心了却不响”的怪现象。系统托盘图标在win11下可能不显示。这是Windows 11“托盘图标折叠”机制带来的改变。如果你在任务栏上看到小箭头里有个隐藏图标需要手动拖出来。否则你关掉程序时会找不到托盘入口以为脚本还活着。对应的我后来在buzz_client.py里加了一个命令行参数--quit可以直接通过命令行终止进程省得每次都去找图标。不要用全局快捷键来暂停检测。很多人会想“我上洗手间、接电话时不想被提醒怎么办”一开始我想做一个“暂停30分钟”的热键但发现热键监听要么依赖第三方库要么在自己写的消息循环里比较复杂。后来我换了一种更稳的方案直接在托盘图标菜单里放一个“暂停/恢复”菜单项。用户点一下菜单就切换不占用快捷键资源也不会和系统其它软件冲突。这个改动算是从“可用”到“好用”的关键一步。番茄钟模式和分心提醒联动时特别注意“阶段切换”的声音重叠。比如番茄钟刚结束时你正好在分心页面就会有两段提醒同时响。我的处理方式是给两种声音各设一个独立的“最近播放时间”互不覆盖而且设置成如果长音正在播放那短音会自动延后1秒播出避免两个音效叠成噪音。4.3 从“能用”到“愿意用”的路有多长代码层面这个项目的功能结构其实半小时就能写完。但从“能用”到“愿意用”我花了不少心思在各种体验细节上。举几个不太起眼、但缺了就会让人放弃的改动音量要能独立调。系统音量一更提醒音就没了或者炸了。我把提示音的音量单独封装在config.ini里在播放前用pydub做音量缩放或者直接在生成WAV时按音量系数生成多个版本避免受系统音量影响。白天和黑夜的提醒音要不同。这是我自己的怪癖——晚上写东西时听到高频率“嘀嘀”声会格外烦躁所以我做了一个“根据当前时间自动切换音效”的小功能18:00之后使用低频一点的蜂鸣听起来更像闷在枕头下的闹钟不刺耳。这个功能很小但真的提升了夜间使用的舒适度。每天第一次触发提醒时给出一条“一天的总结”。构思很简单每天早上9点第一次触发提醒前把昨天日志里分心最严重的三个时间点整理出来播完提醒音后用OS通知的形式展示一份“昨天你可能在这些时间段走神了”。这算是日志功能的一个自然外延也帮我把工具从“被动打断”升级成了“定期复盘”更有长期坚持的动力。这些细节没有一项是硬性需求但没有它们这个项目很可能在第三天就被我卸载了——对于一个效率工具最致命的问题不是功能弱而是用户不愿意持续打开。所谓“坚持自律”从来不是靠意志力实现的靠的是工具把阻力降到最低、把反馈做得恰到好处。5. 写在最后的一点实践心得“buzz”这个项目规模不大但它让我对“做个能改善自己日常习惯的小工具”这件事有了全新理解。很多人以为“效率工具”必须做成一个功能庞大的套件要有数据看板、要有AI分析、要有团队分享但真实场景里一个每天默默在后台运行、从不打扰你、只在关键时刻“嗡”一声的小东西反而更容易被长期保留。它不给你制造“我建设了完美系统”的错觉而是像牙医那个小钻头一样在你的注意力即将溜走的瞬间轻轻拉你一下。如果你也想从头做一个类似的工具我最想让你记住的其实是两件事第一先把“最小可用版本”跑起来再考虑加花活——不要一开始就上Electron、云同步、数据大屏这些重装备一个检测循环、一个播放声音的函数、一个关键词清单已经能解决80%的问题第二一定要留出“日志”和“配置”这两个口子一个让你看得见效果、一个让工具能适应你的使用习惯这两点决定了工具是呆板的死物还是能长久的伙伴。目前这个版本的“buzz”还在我自己的电脑上跑着每天都还在产生新的日志我也还在持续调教它的分心清单。它的代码量很小没有任何值得夸耀的高深技术但它确确实实帮我从每天七八个小时的对屏幕发呆找回了近两小时的干净注意力。这份收益远比写它的那几百行代码更重。如果读这篇文章的你也正被“注意力碎片化”困扰不妨动手复刻一下这个项目或者拿着我上面的思路去改造任何一款你已经觉得“哪里不对劲”的效率工具。很多时候好的工具不是做出来的是改出来的。
