1. 從“盯著終端發(fā)呆”到“讓終端喊我”一個(gè)提醒器的誕生背景如果你跟我一樣日常大量時(shí)間泡在命令行里用各種代碼輔助工具跑任務(wù)那你一定經(jīng)歷過這種場景敲下一段指令工具開始吭哧吭哧干活你盯著屏幕等結(jié)果等了半分鐘沒動(dòng)靜于是順手切到瀏覽器刷了兩條資訊再切回來發(fā)現(xiàn)任務(wù)早就跑完了而你的注意力已經(jīng)碎了一地。更糟糕的是有些任務(wù)跑完不跑完你根本不知道只能反復(fù)切窗口去確認(rèn)這種“人肉輪詢”的方式效率低得令人發(fā)指。這個(gè)項(xiàng)目的出發(fā)點(diǎn)特別樸素讓工具在任務(wù)完成的那一刻主動(dòng)通知我而不是我像個(gè)哨兵一樣守著它。標(biāo)題里提到的“完成提醒器”本質(zhì)上就是一個(gè)輕量級(jí)的任務(wù)狀態(tài)監(jiān)聽與通知轉(zhuǎn)發(fā)機(jī)制。它要解決的核心問題有三個(gè)第一任務(wù)什么時(shí)候結(jié)束的我得第一時(shí)間知道第二通知方式要足夠顯眼不能是那種一閃而過、錯(cuò)過就沒了的小提示第三整個(gè)方案要足夠輕不能為了一個(gè)提醒功能引入一堆重型依賴把原本清爽的工作流搞得臃腫不堪。適合誰來參考這篇內(nèi)容如果你日常使用命令行工具跑代碼生成、批量處理、自動(dòng)化腳本并且希望在這些任務(wù)完成時(shí)獲得一個(gè)可靠的、可定制的提醒那這篇分享就是寫給你的。哪怕你只是偶爾跑一個(gè)耗時(shí)較長的命令這套思路也能幫你省下不少無謂的等待時(shí)間。我接下來會(huì)從設(shè)計(jì)思路、技術(shù)選型、具體實(shí)現(xiàn)、踩坑記錄幾個(gè)維度把這個(gè)提醒器拆開揉碎講清楚你可以直接照著復(fù)現(xiàn)也可以根據(jù)自己的習(xí)慣做二次改造。2. 提醒器的核心設(shè)計(jì)邏輯為什么不用現(xiàn)成的方案2.1 現(xiàn)成方案為什么不夠用市面上其實(shí)不缺通知工具操作系統(tǒng)自帶的通知中心、各種命令行下的notify-send、終端復(fù)用工具自帶的狀態(tài)欄都能在一定程度上告訴你“任務(wù)結(jié)束了”。但實(shí)際用下來它們各有各的局限。系統(tǒng)通知中心的問題在于它太容易被忽略——尤其是當(dāng)你全屏開著編輯器或者瀏覽器的時(shí)候一個(gè)角落里的橫幅彈出來幾秒鐘就消失了等你注意到的時(shí)候已經(jīng)錯(cuò)過了。終端狀態(tài)欄倒是常駐但它要求你始終把終端窗口放在可見范圍內(nèi)這又回到了“必須盯著”的老問題上。還有一個(gè)更現(xiàn)實(shí)的痛點(diǎn)很多代碼輔助工具在執(zhí)行任務(wù)時(shí)輸出是流式的你很難通過簡單的“進(jìn)程是否退出”來判斷任務(wù)是否真正完成。有些工具會(huì)在結(jié)束時(shí)輸出特定的結(jié)束標(biāo)記有些則只是安靜地停止輸出進(jìn)程卻還掛著。如果只是粗暴地監(jiān)聽進(jìn)程退出要么誤報(bào)要么漏報(bào)。所以一個(gè)真正好用的提醒器必須能夠理解任務(wù)的生命周期而不是簡單地看進(jìn)程死活。2.2 我的設(shè)計(jì)原則輕量、可組合、不侵入基于上面的分析我給自己定了三條設(shè)計(jì)原則。第一是輕量整個(gè)提醒器最好就是一個(gè)腳本或者一個(gè)小工具不依賴復(fù)雜的運(yùn)行時(shí)環(huán)境啟動(dòng)開銷要小到可以忽略不計(jì)。第二是可組合提醒的觸發(fā)條件、通知的方式、通知的內(nèi)容都應(yīng)該是可以自由拼接的模塊而不是寫死的一套邏輯。第三是不侵入它不應(yīng)該要求我改變原有的工具使用習(xí)慣而是以“包裹”或者“旁路監(jiān)聽”的方式工作原來的命令該怎么敲還怎么敲。這三條原則直接決定了后續(xù)的技術(shù)選型。輕量意味著我傾向于用 Shell 腳本或者單一二進(jìn)制的小工具來實(shí)現(xiàn)而不是搞一個(gè)常駐的后臺(tái)服務(wù)。可組合意味著我要把“檢測任務(wù)完成”和“發(fā)送通知”這兩件事解耦中間通過一個(gè)標(biāo)準(zhǔn)化的接口傳遞事件。不侵入則意味著我需要在命令執(zhí)行的外層做文章比如用一個(gè)包裝腳本來接管命令的執(zhí)行和結(jié)束。2.3 任務(wù)完成的判定比想象中更微妙這里要特別說一下“任務(wù)完成”的判定邏輯因?yàn)檫@是整個(gè)提醒器最核心也最容易出問題的地方。最直覺的做法是監(jiān)聽子進(jìn)程的退出碼進(jìn)程退出且退出碼為 0 就認(rèn)為成功非 0 就認(rèn)為失敗。但實(shí)際場景遠(yuǎn)比這復(fù)雜。有些工具在任務(wù)完成后會(huì)進(jìn)入一個(gè)交互式的等待狀態(tài)進(jìn)程并沒有退出但任務(wù)其實(shí)已經(jīng)完成了。還有些工具會(huì)把實(shí)際的工作委托給一個(gè)后臺(tái)進(jìn)程前臺(tái)進(jìn)程很快就返回了但后臺(tái)任務(wù)還在跑。我的處理方式是采用“多信號(hào)融合”的判定策略。主信號(hào)是進(jìn)程退出這是最可靠的。輔助信號(hào)包括輸出流中是否出現(xiàn)了預(yù)定義的結(jié)束標(biāo)記、輸出是否在超過一定時(shí)間后不再增長、以及進(jìn)程的 CPU 占用是否降到了接近零。這幾個(gè)信號(hào)通過一個(gè)簡單的加權(quán)邏輯組合起來只有當(dāng)主信號(hào)或者足夠強(qiáng)的輔助信號(hào)出現(xiàn)時(shí)才判定任務(wù)完成。這樣既避免了誤報(bào)也減少了漏報(bào)。當(dāng)然這套邏輯需要針對不同的工具做微調(diào)后面我會(huì)講怎么調(diào)。3. 技術(shù)選型與實(shí)現(xiàn)路徑從 Shell 包裝到跨平臺(tái)通知3.1 為什么選擇 Shell 包裝腳本作為入口在實(shí)現(xiàn)路徑上我最終選擇了用一個(gè) Shell 包裝腳本來做入口。原因很簡單Shell 是命令行的通用語言任何工具都可以被一個(gè) Shell 腳本包裹起來執(zhí)行不需要工具本身提供任何插件機(jī)制或者 API。包裝腳本的職責(zé)很清晰接管用戶輸入的命令在子進(jìn)程中執(zhí)行它同時(shí)監(jiān)聽子進(jìn)程的狀態(tài)和輸出在判定任務(wù)完成后觸發(fā)通知。這個(gè)包裝腳本的核心結(jié)構(gòu)大概是這樣的首先解析用戶傳入的命令和參數(shù)然后啟動(dòng)一個(gè)子進(jìn)程來執(zhí)行這個(gè)命令同時(shí)把子進(jìn)程的標(biāo)準(zhǔn)輸出和標(biāo)準(zhǔn)錯(cuò)誤重定向到一個(gè)臨時(shí)的管道或者文件里主進(jìn)程則循環(huán)讀取這些輸出并做分析。當(dāng)子進(jìn)程退出或者滿足其他完成條件時(shí)包裝腳本調(diào)用通知模塊發(fā)送提醒。整個(gè)過程中用戶看到的輸出和直接執(zhí)行命令幾乎沒有區(qū)別體驗(yàn)是無感的。#!/usr/bin/env bash # 簡化的包裝腳本骨架 CMD$ TMP_OUT$(mktemp) # 在后臺(tái)執(zhí)行命令輸出同時(shí)寫入臨時(shí)文件和終端 eval $CMD 21 | tee $TMP_OUT CMD_PID$! # 等待命令結(jié)束 wait $CMD_PID EXIT_CODE$? # 觸發(fā)通知 notify_done $CMD $EXIT_CODE $TMP_OUT rm -f $TMP_OUT上面這段代碼只是一個(gè)最簡化的骨架實(shí)際實(shí)現(xiàn)中還需要處理信號(hào)轉(zhuǎn)發(fā)、超時(shí)控制、輸出分析等細(xì)節(jié)。但核心思路就是這樣包裝、執(zhí)行、監(jiān)聽、通知。3.2 通知通道的選擇終端內(nèi)提醒與系統(tǒng)級(jí)提醒的取舍通知通道的選擇上我做了分層設(shè)計(jì)。第一層是終端內(nèi)提醒這是最輕量的直接在終端里輸出一段醒目的文字配合終端標(biāo)題的變化和響鈴字符。終端標(biāo)題的變化特別有用因?yàn)楹芏嘟K端模擬器會(huì)在標(biāo)簽頁上顯示當(dāng)前標(biāo)題任務(wù)完成后把標(biāo)題改成“任務(wù)完成”你一眼就能從一堆標(biāo)簽頁里看到哪個(gè)完成了。響鈴字符則是最后的保險(xiǎn)即使你沒看屏幕聽到聲音也會(huì)下意識(shí)地看一眼。第二層是系統(tǒng)級(jí)提醒這需要調(diào)用操作系統(tǒng)的通知接口。在 Linux 上可以用notify-send在 macOS 上可以用osascript調(diào)用通知中心在 Windows 上可以用 PowerShell 的 BurntToast 模塊或者簡單的消息框。這一層的優(yōu)勢是提醒更顯眼即使終端被最小化了也能看到。但它的缺點(diǎn)是依賴具體的操作系統(tǒng)需要做平臺(tái)適配。第三層是可選的擴(kuò)展通道比如發(fā)送到某個(gè)消息隊(duì)列、寫入日志文件、或者觸發(fā)一個(gè)自定義的鉤子腳本。這一層是為了滿足更復(fù)雜的自動(dòng)化需求比如任務(wù)完成后自動(dòng)觸發(fā)下一個(gè)流程。我把它設(shè)計(jì)成可插拔的默認(rèn)不啟用需要的時(shí)候在配置里打開就行。通知層級(jí)實(shí)現(xiàn)方式優(yōu)點(diǎn)缺點(diǎn)終端內(nèi)提醒標(biāo)題修改、響鈴、彩色輸出零依賴、即時(shí)終端不可見時(shí)無效系統(tǒng)級(jí)提醒系統(tǒng)通知接口顯眼、跨窗口需平臺(tái)適配擴(kuò)展通道鉤子腳本、消息隊(duì)列靈活、可自動(dòng)化配置復(fù)雜3.3 輸出分析的實(shí)現(xiàn)細(xì)節(jié)如何識(shí)別“任務(wù)真的結(jié)束了”輸出分析這塊是整個(gè)提醒器里技術(shù)含量最高的部分。我的做法是維護(hù)一個(gè)滑動(dòng)窗口記錄最近一段時(shí)間內(nèi)的輸出行數(shù)和字節(jié)數(shù)。如果輸出在連續(xù) N 秒內(nèi)沒有增長并且進(jìn)程的 CPU 占用低于某個(gè)閾值就認(rèn)為任務(wù)可能已經(jīng)完成。這個(gè) N 和閾值需要根據(jù)具體工具的行為來調(diào)。比如有些工具在生成代碼時(shí)會(huì)有一段“思考”時(shí)間期間沒有任何輸出但任務(wù)并沒有結(jié)束這時(shí)候如果把 N 設(shè)得太小就會(huì)誤報(bào)。為了減少誤報(bào)我還加入了一個(gè)“結(jié)束標(biāo)記”機(jī)制。很多工具在任務(wù)真正完成時(shí)會(huì)輸出一些特定的字符串比如“Done”、“Completed”、“Finished”之類的。我允許用戶在配置里定義一組正則表達(dá)式當(dāng)輸出匹配到這些模式時(shí)就提高完成判定的置信度。這個(gè)機(jī)制不是必須的但配上之后準(zhǔn)確率會(huì)明顯提升。另外對于退出碼的處理也要小心有些工具即使任務(wù)成功也會(huì)返回非零退出碼所以退出碼只能作為一個(gè)參考信號(hào)不能作為唯一依據(jù)。4. 實(shí)戰(zhàn)部署把提醒器接入日常工具鏈4.1 安裝與基礎(chǔ)配置部署這個(gè)提醒器的第一步是把它放到一個(gè)方便調(diào)用的位置。我習(xí)慣在用戶目錄下建一個(gè)~/bin目錄把腳本放進(jìn)去然后確保這個(gè)目錄在PATH環(huán)境變量里。這樣在任何地方都能直接調(diào)用。腳本本身不需要編譯就是一個(gè)純文本文件給它加上可執(zhí)行權(quán)限就行。mkdir -p ~/bin cp task-notifier.sh ~/bin/task-notifier chmod x ~/bin/task-notifier # 確保 ~/bin 在 PATH 中 export PATH$HOME/bin:$PATH配置文件我放在了~/.config/task-notifier/config下采用簡單的鍵值對格式方便手動(dòng)編輯也方便腳本解析。配置項(xiàng)包括通知方式終端內(nèi)、系統(tǒng)級(jí)、兩者都開、靜默超時(shí)時(shí)間多少秒無輸出判定為可能完成、結(jié)束標(biāo)記正則、是否啟用響鈴、是否修改終端標(biāo)題等。這些配置都有合理的默認(rèn)值不配置也能直接用但調(diào)一下會(huì)更貼合自己的使用習(xí)慣。4.2 接入代碼輔助工具的幾種姿勢接入方式取決于你使用的具體工具。最通用的方式是用別名alias或者函數(shù)function來包裝原來的命令。比如你原來習(xí)慣敲codex run現(xiàn)在可以定義一個(gè)別名codex指向task-notifier codex這樣每次調(diào)用都會(huì)自動(dòng)經(jīng)過提醒器。這種方式的優(yōu)點(diǎn)是透明你不需要改變?nèi)魏尾僮髁?xí)慣。# 在 .bashrc 或 .zshrc 中添加 alias codextask-notifier codex alias claudetask-notifier claude另一種方式是在腳本或者 Makefile 里顯式調(diào)用提醒器。比如你有一個(gè)自動(dòng)化腳本里面調(diào)用了代碼輔助工具那就可以把調(diào)用命令改成task-notifier 原命令。這種方式更可控適合在 CI 或者批處理場景下使用。還有一種比較極端的做法是直接修改工具的啟動(dòng)腳本但我不推薦這么做因?yàn)楣ぞ呱?jí)后修改可能會(huì)丟失而且會(huì)影響所有使用場景不夠靈活。4.3 針對不同工具的完成判定調(diào)參不同的代碼輔助工具其輸出模式和任務(wù)生命周期差異很大所以完成判定的參數(shù)需要分別調(diào)。我拿兩個(gè)典型場景來說明。第一個(gè)場景是那種“一次性輸出”的工具你給它一個(gè)指令它思考幾秒后一次性吐出結(jié)果然后進(jìn)程退出。這種場景最簡單直接用進(jìn)程退出作為完成信號(hào)就行靜默超時(shí)設(shè)短一點(diǎn)也沒關(guān)系。第二個(gè)場景是“流式輸出”的工具它會(huì)一邊生成一邊輸出中間可能有停頓。這種場景下靜默超時(shí)就不能設(shè)得太短否則會(huì)把正常的思考停頓誤判為完成。我的經(jīng)驗(yàn)值是設(shè)到 15 到 30 秒具體看工具的響應(yīng)速度。同時(shí)如果工具在結(jié)束時(shí)會(huì)有明確的結(jié)束語一定要把那個(gè)結(jié)束語加到結(jié)束標(biāo)記正則里這樣判定會(huì)準(zhǔn)確得多。調(diào)參的過程其實(shí)就是觀察幾次實(shí)際運(yùn)行記錄下從“最后一次輸出”到“進(jìn)程退出”之間的時(shí)間間隔然后把這個(gè)間隔的 1.5 倍左右作為靜默超時(shí)值。提示調(diào)參時(shí)建議先把通知方式設(shè)為“僅終端內(nèi)提醒”這樣調(diào)試信息不會(huì)彈得到處都是等參數(shù)調(diào)穩(wěn)了再開啟系統(tǒng)級(jí)通知。5. 踩坑記錄那些讓我半夜爬起來改腳本的瞬間5.1 信號(hào)轉(zhuǎn)發(fā)沒做好導(dǎo)致 CtrlC 失效這是最早踩的一個(gè)坑而且影響很大。包裝腳本啟動(dòng)子進(jìn)程后如果用戶按了 CtrlC信號(hào)默認(rèn)是發(fā)給包裝腳本本身的子進(jìn)程收不到結(jié)果就是包裝腳本退出了但子進(jìn)程還在后臺(tái)跑變成了一個(gè)孤兒進(jìn)程。更糟糕的是有時(shí)候子進(jìn)程會(huì)繼續(xù)占用終端導(dǎo)致終端狀態(tài)混亂。修復(fù)方法是在包裝腳本里捕獲信號(hào)并轉(zhuǎn)發(fā)給子進(jìn)程。trap kill -INT $CMD_PID 2/dev/null INT trap kill -TERM $CMD_PID 2/dev/null TERM加上這兩行之后CtrlC 就能正常傳遞給子進(jìn)程了。但這里還有個(gè)細(xì)節(jié)如果子進(jìn)程有自己的子進(jìn)程樹光殺直接子進(jìn)程可能不夠需要用進(jìn)程組的方式來處理。我后來的做法是用setsid讓子進(jìn)程成為新會(huì)話的組長然后殺整個(gè)進(jìn)程組。這個(gè)改動(dòng)之后信號(hào)處理就穩(wěn)了。5.2 輸出重定向?qū)е碌木彌_問題第二個(gè)坑是輸出緩沖。為了讓包裝腳本能分析輸出我把子進(jìn)程的輸出重定向到了管道。但很多程序在檢測到輸出不是終端時(shí)會(huì)啟用全緩沖模式也就是攢夠一定量的數(shù)據(jù)才真正寫出來。這就導(dǎo)致包裝腳本看到的輸出是滯后的靜默超時(shí)的判定完全失準(zhǔn)。修復(fù)方法是給子進(jìn)程設(shè)置一個(gè)偽終端pty讓它以為自己是在終端里運(yùn)行這樣就會(huì)用行緩沖模式輸出是實(shí)時(shí)的。在 Shell 里實(shí)現(xiàn) pty 稍微麻煩一點(diǎn)可以用script命令來包一層或者用stdbuf來強(qiáng)制行緩沖。stdbuf更簡單但只對使用了標(biāo)準(zhǔn) C 庫緩沖的程序有效。對于更復(fù)雜的情況還是得上 pty。我最后的方案是優(yōu)先用stdbuf如果發(fā)現(xiàn)輸出還是滯后就切到script方案。這個(gè)坑讓我意識(shí)到輸出分析的前提是能拿到實(shí)時(shí)的輸出否則一切判定都是空中樓閣。5.3 系統(tǒng)通知在特定桌面環(huán)境下的兼容性系統(tǒng)級(jí)通知這塊Linux 下的notify-send看起來簡單但在不同的桌面環(huán)境下行為差異很大。有的桌面環(huán)境會(huì)正常彈出通知有的則會(huì)把通知丟進(jìn)一個(gè)不顯眼的消息中心還有的干脆不顯示。我測試了幾種常見的桌面環(huán)境發(fā)現(xiàn)通知的顯示效果和持久性都不一樣。最后的應(yīng)對策略是不依賴單一通知方式而是同時(shí)觸發(fā)終端內(nèi)提醒和系統(tǒng)通知并且把系統(tǒng)通知的失敗當(dāng)作非致命錯(cuò)誤處理不讓它影響主流程。另外通知的內(nèi)容也要注意。有些系統(tǒng)對通知標(biāo)題和正文的長度有限制太長了會(huì)被截?cái)?。我一開始把整個(gè)命令都塞進(jìn)通知標(biāo)題里結(jié)果在某個(gè)環(huán)境下只顯示了前幾個(gè)字符完全看不出是哪個(gè)任務(wù)完成了。后來改成標(biāo)題只放“任務(wù)完成”或者“任務(wù)失敗”正文里放命令的簡短摘要和執(zhí)行時(shí)長這樣既清晰又不會(huì)超長。5.4 長時(shí)間運(yùn)行任務(wù)的資源占用問題還有一個(gè)不太起眼但實(shí)際影響體驗(yàn)的問題包裝腳本本身在長時(shí)間運(yùn)行時(shí)的資源占用。因?yàn)橐掷m(xù)讀取輸出并做分析如果實(shí)現(xiàn)得不好CPU 占用會(huì)一直居高不下。我最初的實(shí)現(xiàn)是用一個(gè)忙等待循環(huán)去讀輸出結(jié)果跑一個(gè)幾小時(shí)的任務(wù)包裝腳本自己就吃掉了不少 CPU。后來改成了基于read的阻塞讀取沒有輸出時(shí)就阻塞在那里幾乎不占 CPU。這個(gè)改動(dòng)雖然簡單但對長時(shí)間任務(wù)的體驗(yàn)提升很明顯。6. 進(jìn)階玩法讓提醒器更懂你的工作流6.1 根據(jù)任務(wù)類型定制通知內(nèi)容基礎(chǔ)的提醒器只會(huì)告訴你“任務(wù)完成了”但你可以讓它更聰明一點(diǎn)。我的做法是在包裝命令的時(shí)候額外傳入一個(gè)任務(wù)標(biāo)簽比如task-notifier --label 生成文檔 -- codex run。這樣通知里就會(huì)帶上這個(gè)標(biāo)簽?zāi)阋谎劬椭朗悄膫€(gè)任務(wù)完成了。標(biāo)簽可以手動(dòng)指定也可以根據(jù)命令內(nèi)容自動(dòng)推斷。比如檢測到命令里包含test就標(biāo)記為“測試任務(wù)”包含build就標(biāo)記為“構(gòu)建任務(wù)”。這個(gè)功能實(shí)現(xiàn)起來很簡單就是在通知模塊里加一個(gè)標(biāo)簽字段但用起來體驗(yàn)提升很大。6.2 任務(wù)完成后的自動(dòng)后續(xù)動(dòng)作提醒器最有價(jià)值的擴(kuò)展方向是“任務(wù)完成后自動(dòng)做點(diǎn)什么”。比如任務(wù)成功后自動(dòng)打開生成的文件任務(wù)失敗后自動(dòng)把錯(cuò)誤日志收集到一個(gè)固定位置或者任務(wù)完成后自動(dòng)觸發(fā)下一個(gè)流程。這些都可以通過鉤子腳本來實(shí)現(xiàn)。我在配置里加了一個(gè)on_success和on_failure兩個(gè)鉤子分別指定任務(wù)成功和失敗時(shí)要執(zhí)行的命令。鉤子腳本會(huì)接收到任務(wù)命令、退出碼、輸出文件路徑等參數(shù)可以自由發(fā)揮。# 配置示例 on_success~/bin/hooks/open-result.sh on_failure~/bin/hooks/collect-error.sh這個(gè)機(jī)制讓提醒器從一個(gè)單純的“通知工具”變成了一個(gè)“工作流節(jié)點(diǎn)”你可以用它來串聯(lián)起更復(fù)雜的自動(dòng)化流程。比如跑完代碼生成后自動(dòng)格式化格式化完成后自動(dòng)跑測試測試通過后自動(dòng)提交整個(gè)鏈條都可以用鉤子串起來。6.3 多任務(wù)并發(fā)時(shí)的通知去重與聚合當(dāng)你同時(shí)跑多個(gè)任務(wù)時(shí)通知可能會(huì)變得很吵。我遇到過同時(shí)跑五個(gè)任務(wù)結(jié)果通知一個(gè)接一個(gè)彈出來反而造成了干擾。解決思路有兩個(gè)一是去重如果同一個(gè)任務(wù)在短時(shí)間內(nèi)重復(fù)完成只通知一次二是聚合把一段時(shí)間內(nèi)完成的任務(wù)合并成一條通知比如“3 個(gè)任務(wù)已完成1 個(gè)任務(wù)失敗”。聚合的時(shí)間窗口可以配置我一般設(shè)成 10 秒這樣既不會(huì)漏掉通知也不會(huì)被刷屏。實(shí)現(xiàn)聚合需要一個(gè)簡單的隊(duì)列和定時(shí)器。任務(wù)完成時(shí)把事件推入隊(duì)列然后啟動(dòng)一個(gè)定時(shí)器定時(shí)器到期后把隊(duì)列里的事件合并成一條通知發(fā)出去。如果定時(shí)器還沒到期又有新事件進(jìn)來就重置定時(shí)器。這個(gè)邏輯用 Shell 寫稍微有點(diǎn)繞但用幾行sleep和后臺(tái)進(jìn)程也能實(shí)現(xiàn)。如果追求更精細(xì)的控制可以考慮用一個(gè)小型的腳本語言來寫這部分邏輯。6.4 把提醒器做成一個(gè)可復(fù)用的命令行工具如果你覺得這套邏輯在多個(gè)場景下都有用可以把它進(jìn)一步封裝成一個(gè)獨(dú)立的命令行工具。我的做法是把核心邏輯抽出來做成一個(gè)接受子命令的工具比如notifier run -- 命令來執(zhí)行并監(jiān)聽notifier config來管理配置notifier test來測試通知通道是否正常。這樣它就不再是一個(gè)依附于特定工具的腳本而是一個(gè)通用的任務(wù)監(jiān)聽與通知工具可以用在任何需要的地方。封裝成工具之后還可以考慮發(fā)布到包管理器或者內(nèi)部共享目錄方便團(tuán)隊(duì)里其他人使用。不過要注意的是一旦要給別人用配置的默認(rèn)值和錯(cuò)誤處理就要做得更完善不能假設(shè)用戶會(huì)去讀源碼。文檔和示例配置就變得很重要了。我一般會(huì)附上一個(gè)README和一個(gè)config.example讓新用戶能在五分鐘內(nèi)跑起來。7. 一些實(shí)際使用中的體會(huì)這套提醒器我用了挺長一段時(shí)間最大的感受是它改變了我跟命令行工具的相處方式。以前我總是在“等任務(wù)”和“切窗口看任務(wù)”之間反復(fù)橫跳注意力被切得很碎?，F(xiàn)在我可以放心地把任務(wù)丟出去然后去處理別的事情任務(wù)完成時(shí)自然會(huì)收到提醒。這種“異步化”的工作方式讓我的時(shí)間利用率高了不少。另一個(gè)體會(huì)是完成判定的準(zhǔn)確性比通知的炫酷程度重要得多。我一開始花了很多時(shí)間在通知的樣式上后來發(fā)現(xiàn)真正影響體驗(yàn)的是判定邏輯。一次誤報(bào)就會(huì)讓你對提醒器失去信任之后每次收到通知都要去確認(rèn)一下那這個(gè)工具就白做了。所以如果你要自己實(shí)現(xiàn)建議把大部分精力放在完成判定的調(diào)參和驗(yàn)證上通知方式夠用就行。最后分享一個(gè)小技巧在調(diào)試完成判定邏輯的時(shí)候可以先把通知方式設(shè)成“只寫日志文件”然后跑一批不同類型的任務(wù)事后分析日志看看哪些任務(wù)被誤判了哪些被漏判了。根據(jù)日志來調(diào)參數(shù)比憑感覺調(diào)要靠譜得多。這個(gè)日志文件也可以長期保留作為任務(wù)執(zhí)行歷史的一個(gè)記錄偶爾翻翻還挺有用的。