做了十幾年開(kāi)發(fā)我電腦里最離不開(kāi)的東西不是什么花哨的圖形便簽反而是終端里那幾行命令。今天想聊的是我用 Python 自建一個(gè)命令行待辦事項(xiàng)應(yīng)用的完整過(guò)程從為什么選命令行到數(shù)據(jù)怎么存、命令怎么設(shè)計(jì)再到中間踩過(guò)的坑和最后沉淀下來(lái)的實(shí)用技巧。這類工具聽(tīng)起來(lái)簡(jiǎn)單仿佛寫(xiě)個(gè)增刪改查就能交差但真正要把它做成一個(gè)自己愿意每天打開(kāi)的東西需要考慮的細(xì)節(jié)遠(yuǎn)比想象中多。1. 為什么圖形界面解決不了“終端前隨手記一筆”的需求你第一反應(yīng)可能是待辦事項(xiàng)手機(jī)備忘錄、各種日歷應(yīng)用、桌面小組件哪個(gè)不能做確實(shí)能但那是另一類使用場(chǎng)景。我自己的情況是大部分工作時(shí)間都在終端里很多待辦不是“下午四點(diǎn)開(kāi)會(huì)”這種帶強(qiáng)時(shí)間屬性的事件而是“發(fā)版前記得改版本號(hào)”“修完這個(gè) bug 后把日志加上”“測(cè)試環(huán)境更新之前先備份數(shù)據(jù)庫(kù)”這類和工作上下文強(qiáng)綁定的短任務(wù)。它們不需要鬧鐘提醒不需要分類成“個(gè)人”“工作”只需要在我掃一眼終端時(shí)立刻想起來(lái)哦手上還有這件事。這類場(chǎng)景放進(jìn)圖形應(yīng)用里會(huì)產(chǎn)生一個(gè)摩擦你得先切走注意力打開(kāi)另一個(gè)軟件再等它加載完。而命令行工具沒(méi)有這個(gè)過(guò)程。你就在終端里敲一行命令任務(wù)已經(jīng)記下來(lái)了。這種“零切換”的體驗(yàn)恰恰是圖形界面替代不了的地方。1.1 這套工具真正要應(yīng)對(duì)的使用場(chǎng)景我最初觸發(fā)這個(gè)念頭是在一次線上問(wèn)題排查之后。當(dāng)時(shí)連續(xù)幾個(gè)小時(shí)都在命令行里查日志、改配置、重試操作中間接到幾件臨時(shí)任務(wù)確認(rèn)某個(gè)服務(wù)的新版本號(hào)、讓同事提交一份接口變更說(shuō)明、給某個(gè)目錄寫(xiě)個(gè)清理腳本。如果用圖形待辦工具就意味著每來(lái)一件任務(wù)我都要從終端切出去記錄在那種爭(zhēng)分奪秒的現(xiàn)場(chǎng)這是不可接受的。類似場(chǎng)景還有很多。SSH 登錄遠(yuǎn)程服務(wù)器做維護(hù)時(shí)你身邊往往沒(méi)有自己常用的圖形工具隨身帶著手機(jī)又覺(jué)得在服務(wù)器上做事卻要在手機(jī)上翻待辦很滑稽。再比如深夜處理告警大腦本來(lái)就在高速運(yùn)轉(zhuǎn)如果記錄任務(wù)還要經(jīng)過(guò)“進(jìn)入應(yīng)用、點(diǎn)擊新建、輸入標(biāo)題、設(shè)置提醒”這套流程那和沒(méi)記錄沒(méi)有區(qū)別。還有一些使用人群不太一樣——不是每個(gè)人都每天打開(kāi)十幾個(gè)圖形應(yīng)用。無(wú)論是寫(xiě)腳本的運(yùn)維、維護(hù) CI/CD 的開(kāi)發(fā)者還是長(zhǎng)期待在終端里的數(shù)據(jù)分析師都需要一個(gè)“不會(huì)主動(dòng)打擾、但隨叫隨到”的任務(wù)清單。命令行工具的優(yōu)勢(shì)就在這里它安靜地待在你的數(shù)據(jù)文件里你來(lái)了它就在你不來(lái)它也不刷存在感。1.2 命令行應(yīng)用不可替代的三個(gè)原因如果把這套工具和圖形待辦應(yīng)用放在一起對(duì)比命令行至少有三個(gè)地方是真正差異化的。第一是啟動(dòng)速度和資源占用。圖形應(yīng)用啟動(dòng)往往要經(jīng)歷窗口加載、界面渲染動(dòng)輒一兩秒甚至更久很多還會(huì)常駐后臺(tái)進(jìn)程沒(méi)事就在托盤(pán)里占著十幾 M 內(nèi)存。命令行工具是真正用完即走的每次執(zhí)行只存在幾百毫秒執(zhí)行完就退出不給你桌面環(huán)境平添負(fù)擔(dān)。第二是可腳本化。這是命令行工具“降維打擊”一般的能力。我可以寫(xiě)一個(gè)定時(shí)任務(wù)每天早上自動(dòng)把今天到期且未完成的任務(wù)列出來(lái)可以在發(fā)布流程里加一步彈出一個(gè)“記得更新 changelog”的提示甚至可以把任務(wù)輸出和 shell 腳本串聯(lián)做完一件事順手把對(duì)應(yīng)任務(wù)標(biāo)記為完成。圖形應(yīng)用做得再精致也很難提供這種可編程接口。第三是數(shù)據(jù)透明。圖形待辦工具的數(shù)據(jù)往往存在各自的應(yīng)用沙盒里想看一眼還要專門(mén)找導(dǎo)出功能。命令行工具的數(shù)據(jù)就是普通文件你可以直接打開(kāi)可以用其他腳本處理可以放進(jìn)版本管理工具。這種透明性對(duì)個(gè)人數(shù)據(jù)來(lái)說(shuō)是一種安全感——“我知道我的任務(wù)躺在哪里也知道它長(zhǎng)什么樣子”。2. 技術(shù)選型Python 配 JSON 文件是怎樣權(quán)衡出來(lái)的工具定位決定了技術(shù)路線。它需要跨平臺(tái)、容易改、沒(méi)有太復(fù)雜的外部依賴同時(shí)因?yàn)槲要?dú)用不需要考慮多人并發(fā)和復(fù)雜權(quán)限。帶著這幾點(diǎn)約束我做了下面幾輪取舍。2.1 用 Python 而不是其他語(yǔ)言這里邊有哪些妥協(xié)最初的備選項(xiàng)其實(shí)不少Go、Rust、Node.js、Python 都寫(xiě)過(guò)命令行工具我也并不排斥其中任何一個(gè)。最終選擇 Python 核心原因是標(biāo)準(zhǔn)庫(kù)足夠用。argparse、json、pathlib、time、tempfile、fcntl這些已經(jīng)覆蓋了 CLI 參數(shù)解析、數(shù)據(jù)讀寫(xiě)、備份、鎖文件等幾乎全部需求不需要額外安裝第三方庫(kù)也就意味著在任何一臺(tái)裝有標(biāo)準(zhǔn) Python 解釋器的機(jī)器上都能直接跑。這里當(dāng)然有妥協(xié)。Python 的啟動(dòng)速度比編譯型語(yǔ)言慢我實(shí)際測(cè)過(guò)進(jìn)程從敲下回車到輸出結(jié)果大約 300 到 600 毫秒取決于系統(tǒng)環(huán)境。圖形應(yīng)用動(dòng)輒幾秒的啟動(dòng)時(shí)間讓我們習(xí)慣了等待但命令行工具連半秒都顯得拖沓。我曾在一次發(fā)布窗口里連續(xù)使用十幾個(gè)操作感受到那種“幾乎無(wú)感”的瞬時(shí)反饋有多重要。為了進(jìn)一步壓縮啟動(dòng)時(shí)間我也想過(guò)換成 Go但后來(lái)評(píng)估發(fā)現(xiàn)待辦事項(xiàng)應(yīng)用每次操作本來(lái)就少半秒的延遲換成開(kāi)發(fā)效率和跨平臺(tái)免編譯的好處完全值得。如果哪天我真覺(jué)得這半秒不能忍了用 Go 重寫(xiě)一遍也是同一個(gè)設(shè)計(jì)方案數(shù)據(jù)格式和命令接口不變遷移成本很低。另一點(diǎn)讓我對(duì) Python 更放心的原因是它無(wú)需編譯。改一行字段校驗(yàn)邏輯保存后馬上就能跑調(diào)試路徑足夠短。很多個(gè)人工具修改頻率高每改一次都要編譯部署的話會(huì)顯著降低你優(yōu)化它的意愿。2.2 存儲(chǔ)方案JSON 文件還是嵌入式數(shù)據(jù)庫(kù)這是做工具類應(yīng)用時(shí)繞不開(kāi)的決策。下表是我在兩種方案之間反復(fù)對(duì)比的依據(jù)維度JSON 文件嵌入式數(shù)據(jù)庫(kù)查詢能力需要自己寫(xiě)過(guò)濾邏輯但簡(jiǎn)單任務(wù)足夠支持 SQL復(fù)雜聯(lián)表自然并發(fā)安全多進(jìn)程同時(shí)寫(xiě)會(huì)相互覆蓋需要鎖自帶事務(wù)與并發(fā)控制數(shù)據(jù)可讀性文本直接查看可用任何編輯器修改需要專門(mén)工具訪問(wèn)依賴復(fù)雜度標(biāo)準(zhǔn)庫(kù)即可內(nèi)置為一個(gè)庫(kù)文件體積略大適合場(chǎng)景單用戶、任務(wù)量小、重可讀性多進(jìn)程、數(shù)據(jù)量大、復(fù)雜查詢我選 JSON 文件的理由很直接待辦事項(xiàng)的數(shù)據(jù)結(jié)構(gòu)化程度低、數(shù)據(jù)量有限常見(jiàn)的過(guò)濾無(wú)非按狀態(tài)、按標(biāo)簽、按優(yōu)先級(jí)這類操作用一次線性掃描就能輕松處理。而且 JSON 的透明性是無(wú)可替代的——如果哪天工具本身出了問(wèn)題我還可以直接用任意編輯器把數(shù)據(jù)打開(kāi)來(lái)修復(fù)這種“裸奔式”的可靠感對(duì)命令行用戶很重要。嵌入式數(shù)據(jù)庫(kù)固然更規(guī)范但對(duì)我這個(gè)項(xiàng)目來(lái)說(shuō)明顯過(guò)重了。我不需要 LIMIT 分頁(yè)、不需要索引優(yōu)化、不需要跨進(jìn)程事務(wù)硬要上一個(gè)數(shù)據(jù)庫(kù)反而破壞了“所見(jiàn)即所得”的直覺(jué)。選型原則應(yīng)該是用最簡(jiǎn)單的能解決問(wèn)題的方案而不是用功能最全的方案。后面加功能時(shí)如果發(fā)現(xiàn)單文件 JSON 撐不住了再換數(shù)據(jù)庫(kù)不遲。2.3 任務(wù)字段怎么設(shè)計(jì)才能兼顧簡(jiǎn)單與好用數(shù)據(jù)結(jié)構(gòu)是這類應(yīng)用的地基我在第一次設(shè)計(jì)時(shí)沒(méi)想全后來(lái)付出了改腳本的代價(jià)。最終沉淀下來(lái)的任務(wù)字段大致如下{ id: a3f9c2e1, title: 發(fā)版前確認(rèn)版本號(hào)已更新, description: , status: pending, priority: high, due_date: 2025-06-10, tags: [release, ops], created_at: 2025-06-08T09:30:00, completed_at: null }字段解釋一下id 是唯一標(biāo)識(shí)用來(lái)精確操作某一條任務(wù)title 是任務(wù)標(biāo)題description 是可選描述status 是狀態(tài)pending、in_progress、completed 三種后面細(xì)說(shuō)priority 是高、中、低三檔due_date 是截止日期只存日期不存時(shí)間tags 是標(biāo)簽數(shù)組created_at 和 completed_at 是時(shí)間戳。有幾個(gè)字段是后來(lái)才加的。description 原本沒(méi)有后來(lái)發(fā)現(xiàn)一些任務(wù)需要寫(xiě)點(diǎn)背景比如“這個(gè)配置改過(guò)之后要回滾回滾步驟見(jiàn)某某鏈接”否則過(guò)兩周再看標(biāo)題已經(jīng)想不起來(lái)原委。tags 也是實(shí)用主義的結(jié)果工作里的任務(wù)天然分成“項(xiàng)目”“運(yùn)維”“個(gè)人”等維度光靠平鋪列表很難快速篩選。這些字段的教訓(xùn)是第一版不必貪多但至少要預(yù)留類型意識(shí)否則后面加字段就要寫(xiě)遷移邏輯。3. 命令設(shè)計(jì)把常用操作收斂為一屏能看懂的命令集命令行應(yīng)用最忌諱的是命令名長(zhǎng)得像繞口令或者每個(gè)操作都要求記住一長(zhǎng)串參數(shù)。我設(shè)計(jì)命令時(shí)的原則很簡(jiǎn)單高頻操作要短危險(xiǎn)操作要多一步確認(rèn)整個(gè)命令集一眼看過(guò)去不會(huì)超過(guò)一屏。3.1 完整命令集常用的 10 條操作下面是最終沉淀下來(lái)的命令總覽命令作用todo add 任務(wù)標(biāo)題添加任務(wù)可加 --priority、--due、--tagtodo list列出全部任務(wù)可加 --status、--tag、--due-beforetodo show id查看單條任務(wù)的完整信息todo start id把任務(wù)狀態(tài)從 pending 改為 in_progresstodo done id標(biāo)記為完成todo reopen id重新打開(kāi)已完成任務(wù)todo update id --priority high更新任務(wù)屬性todo delete id刪除任務(wù)需要 --yes 確認(rèn)todo stats統(tǒng)計(jì)未完成、已完成、過(guò)期任務(wù)數(shù)量todo backup手動(dòng)備份數(shù)據(jù)文件這樣一個(gè)周期里最常用的操作除了刪除其余命令都在三個(gè)單詞以內(nèi)。我刻意沒(méi)有把“edit”做成全屏文本編輯器因?yàn)閡pdate 加參數(shù)的方式更可控也更容易在 shell 歷史里留下操作軌跡。3.2 參數(shù)解析里最容易出錯(cuò)的地方講幾個(gè)真實(shí)的“坑”新手很容易踩。第一個(gè)是任務(wù)標(biāo)題帶空格的問(wèn)題。命令是todo add 這是一個(gè)任務(wù)如果用戶忘記加引號(hào)add后的位置參數(shù)只能拿到第一個(gè)單詞。我的解決方案是用argparse的REMAINDER模式讓add命令把剩余參數(shù)全部當(dāng)作標(biāo)題再配合--區(qū)隔選項(xiàng)這樣即使標(biāo)題里夾著引號(hào)、特殊字符也不容易崩。第二個(gè)是日期格式的統(tǒng)一。這個(gè)極其重要。用戶今天輸入--due 明天明天輸入--due 2025-06-20如果每個(gè)別名都支持解析邏輯會(huì)越寫(xiě)越復(fù)雜而且容易出現(xiàn)歧義。最終我把日期格式收斂為YYYY-MM-DD并在解析入口做一個(gè)純函數(shù)統(tǒng)一校驗(yàn)。不支持的格式直接報(bào)錯(cuò)絕不默認(rèn)當(dāng)成今天或任意猜測(cè)。原因是“猜錯(cuò)了用戶可能完全注意不到”導(dǎo)致一個(gè)任務(wù)在錯(cuò)誤的日期下被靜默過(guò)濾掉。第三個(gè)是危險(xiǎn)操作的確認(rèn)。刪除任務(wù)這種不可逆操作我在命令層做了二次確認(rèn)不傳--yes就進(jìn)入交互式確認(rèn)如果確認(rèn)發(fā)現(xiàn)傳了一個(gè)不存在的 id也要給出提示而不是默默忽略。CLI 工具做得越順手越要防“順手把重要數(shù)據(jù)刪了”的意外。3.3 核心命令的代碼實(shí)現(xiàn)骨架下面是核心數(shù)據(jù)層和 add、list 兩個(gè)命令的實(shí)現(xiàn)骨架其它命令邏輯大同小異。import argparse import datetime import json import os import tempfile import uuid DATA_FILE os.path.expanduser(~/.todo.json) def load_data(): try: with open(DATA_FILE, r, encodingutf-8) as f: data json.load(f) except FileNotFoundError: data {schema_version: 1, tasks: []} return data def save_data(data): dir_name os.path.dirname(os.path.abspath(DATA_FILE)) fd, tmp_path tempfile.mkstemp(dirdir_name) with os.fdopen(fd, w, encodingutf-8) as f: json.dump(data, f, indent2, ensure_asciiFalse) os.replace(tmp_path, DATA_FILE) def cmd_add(args, data): task { id: str(uuid.uuid4())[:8], title: args.title, description: args.description or , status: pending, priority: args.priority, due_date: args.due, tags: args.tags.split(,) if args.tags else [], created_at: datetime.datetime.now().isoformat(timespecseconds), completed_at: None, } data[tasks].append(task) save_data(data) print(f已添加任務(wù)ID: {task[id]}) def cmd_list(args, data): tasks data[tasks] priority_rank {high: 0, medium: 1, low: 2} tasks.sort(keylambda t: ( priority_rank.get(t.get(priority, medium), 1), t.get(due_date) or 9999-12-31 )) for t in tasks: status t[status] mark [完成] if status completed else [進(jìn)行] if status in_progress else [待辦] print(f{t[id]} {mark} {t[title]} 優(yōu)先級(jí):{t.get(priority)} 截止:{t.get(due_date)} 標(biāo)簽:{,.join(t.get(tags, []))})代碼里最值得說(shuō)的是排序邏輯。due_date可能為空排序時(shí)就把它映射成9999-12-31讓沒(méi)有截止日期的任務(wù)排到最后優(yōu)先級(jí)先于日期排列因?yàn)椤爸匾揖o急”永遠(yuǎn)應(yīng)該優(yōu)先于“單純明天到期”。粗看這像是數(shù)據(jù)細(xì)節(jié)其實(shí)它決定了列表的可用性。4. 讓任務(wù)真正“動(dòng)”起來(lái)狀態(tài)機(jī)、過(guò)濾與視圖待辦事項(xiàng)應(yīng)用如果只做到增刪改查那本質(zhì)上就是個(gè)帶命令行外殼的文本編輯器。讓它成為“工具”的關(guān)鍵是把任務(wù)放進(jìn)工作流里這就離不開(kāi)狀態(tài)設(shè)計(jì)和過(guò)濾視圖。4.1 狀態(tài)機(jī)設(shè)計(jì)三個(gè)狀態(tài)背后的工作流思考最初的版本只有兩個(gè)狀態(tài)未完成和已完成。用了兩周之后發(fā)現(xiàn)不夠有些任務(wù)已經(jīng)開(kāi)始處理了比如“修完 bug 后加日志”這件事我已經(jīng)改了兩行代碼但還沒(méi)完成下次打開(kāi)列表時(shí)希望知道“這件事已經(jīng)進(jìn)行中”而不想看到它和其他沒(méi)開(kāi)始的雜事混在一起。于是加了in_progress狀態(tài)。加上之后任務(wù)的生命周期變得清晰當(dāng)前狀態(tài)允許執(zhí)行的操作目標(biāo)狀態(tài)pendingstartin_progresspendingdonecompletedin_progressdonecompletedin_progressreopenpendingcompletedreopenpending任意狀態(tài)delete刪除之所以可以通過(guò)pending直接done是因?yàn)楝F(xiàn)實(shí)中經(jīng)常出現(xiàn)“還沒(méi)來(lái)得及開(kāi)始就完成了”的任務(wù)比如一個(gè)同事順手把事件處理掉了。強(qiáng)行要求必須經(jīng)過(guò)中間狀態(tài)會(huì)顯得死板。實(shí)現(xiàn)上我維護(hù)了一個(gè)合法的狀態(tài)轉(zhuǎn)換表非法操作直接報(bào)錯(cuò)ALLOWED_TRANSITIONS { pending: [in_progress, completed], in_progress: [completed, pending], completed: [pending], } def transition(status, action): target {start: in_progress, done: completed, reopen: pending}[action] if target in ALLOWED_TRANSITIONS[status]: return target raise ValueError(f無(wú)法將狀態(tài)從 {status} 通過(guò) {action} 變更為 {target})不要小看這一步它讓任務(wù)的流轉(zhuǎn)有了“語(yǔ)義”。當(dāng)別人追問(wèn)“這個(gè)任務(wù)現(xiàn)在到哪一步了”你能通過(guò)狀態(tài)一目了然地回答。沒(méi)有狀態(tài)機(jī)的數(shù)據(jù)倉(cāng)庫(kù)只會(huì)在列表里堆出一堆永不更新的舊記錄。4.2 過(guò)濾、排序與視圖一個(gè)待辦清單的靈魂命令行的待辦清單最怕什么最怕輸出一堆讓人眼花繚亂的任務(wù)。任務(wù)一旦超過(guò)三十條不做過(guò)濾就是災(zāi)難。所以我給list命令加了幾個(gè)常用過(guò)濾參數(shù)todo list --status pending todo list --tag release todo list --due-before 2025-06-30 todo list --status in_progress --priority high過(guò)濾邏輯用一段樸素的循環(huán)實(shí)現(xiàn)各個(gè)條件之間是“與”的關(guān)系同時(shí)滿足才會(huì)保留def apply_filters(tasks, statusNone, tagNone, due_beforeNone): result [] for t in tasks: if status and t.get(status) ! status: continue if tag and tag not in t.get(tags, []): continue if due_before and (t.get(due_date) or 9999-12-31) due_before: continue result.append(t) return result過(guò)濾之外我還有一個(gè)個(gè)人偏好列表輸出不要超過(guò) 20 行。任務(wù)一多我就只會(huì)在意“今天最要緊的幾件事”所以把--limit 10直接設(shè)為隱含參數(shù)不傳也默認(rèn)只顯示前 10 條想看全部再顯式加--limit 0。命令行應(yīng)用講究一個(gè)“克制”和“清晰”寧可少一些多余輸出也不要讓信息淹沒(méi)重點(diǎn)。這里有一個(gè)實(shí)用技巧把todo list的輸出格式處理成“ID 狀態(tài)標(biāo)記 標(biāo)題”的緊湊行每行不超過(guò) 80 個(gè)字符。這樣即使不做任何美化放在任何終端窗口都不會(huì)折行混亂。復(fù)雜展示放在todo show id里需要看完整信息時(shí)再展開(kāi)。4.3 批量操作與安全護(hù)欄任務(wù)基礎(chǔ)少時(shí)逐條操作尚可任務(wù)積累多了以后批量操作幾乎是剛需。最常用的兩個(gè)是“一次性完成全部工作”和“清理已完成任務(wù)”todo done --all --status in_progress todo clean --done批量操作很容易誤傷所以我把安全護(hù)欄作為默認(rèn)行為不支持“直接全部搞定”的語(yǔ)法必須加--status參數(shù)縮小范圍涉及批量刪除的命令第一次執(zhí)行時(shí)先輸出將受影響的任務(wù)數(shù)量再要求輸入y確認(rèn)。有些人可能嫌這一步多余但我在一次誤操作后意識(shí)到批量操作是“手滑高危區(qū)”寧可多花一秒確認(rèn)也不能用恢復(fù)數(shù)據(jù)的痛苦去冒險(xiǎn)。還值得一提的細(xì)節(jié)是增加了--dry-run選項(xiàng)。讓批量操作先走一遍完整邏輯只打印將執(zhí)行的動(dòng)作不真正改動(dòng)數(shù)據(jù)。這讓我可以在執(zhí)行前快速掃一眼結(jié)果確認(rèn)無(wú)誤后再去掉--dry-run重新執(zhí)行。命令行工具想做得好用“安全”和“快捷”本來(lái)就要這樣反復(fù)平衡。5. 數(shù)據(jù)安全與格式兼容命令行工具更該怕丟數(shù)據(jù)圖形應(yīng)用丟數(shù)據(jù)你會(huì)怪它自己寫(xiě)的命令行工具丟數(shù)據(jù)就沒(méi)處甩鍋了。數(shù)據(jù)文件是單文件 JSON結(jié)構(gòu)簡(jiǎn)單但簡(jiǎn)單文件的脆弱性也正是它的軟肋。寫(xiě)入一半斷電、多終端并發(fā)寫(xiě)、格式版本變化這些都有可能造成災(zāi)難。我在這個(gè)項(xiàng)目上做的安全措施對(duì)任何單文件數(shù)據(jù)存儲(chǔ)都值得借鑒。5.1 原子寫(xiě)入避免一次崩潰毀掉全部任務(wù)最常見(jiàn)的損壞場(chǎng)景是程序打開(kāi)數(shù)據(jù)文件寫(xiě)入了一部分此時(shí)突然斷電或進(jìn)程被殺文件停留在半截狀態(tài)。直接后果是 JSON 解析失敗整個(gè)任務(wù)列表打不開(kāi)。使用with open(DATA_FILE, w)這種直接覆蓋寫(xiě)法風(fēng)險(xiǎn)敞口非常大。正確做法是“原子寫(xiě)入”先寫(xiě)到同目錄下的臨時(shí)文件再通過(guò)os.replace原子替換舊文件。同目錄很重要因?yàn)榭缥募到y(tǒng)移動(dòng)不一定具備原子性而在同一文件系統(tǒng)內(nèi)os.replace是原子的。代碼就像前面 save_data 展示的那樣先mkstemp再os.replace這樣任何時(shí)刻目標(biāo)路徑要么是舊文件、要么是新文件絕不會(huì)是半截狀態(tài)。我把崩潰恢復(fù)也考慮進(jìn)去了即使寫(xiě)入臨時(shí)文件后、替換前進(jìn)程被殺舊文件也不會(huì)損壞唯一殘留只是一個(gè).tmp文件下次啟動(dòng)時(shí)清理掉即可。這段保護(hù)邏輯代碼量不多卻讓數(shù)據(jù)的可靠性提升了一個(gè)檔次。5.2 多終端同時(shí)打開(kāi)時(shí)的并發(fā)與鎖使用場(chǎng)景繞不開(kāi)“多個(gè)終端同時(shí)操作”。比如工作機(jī)上開(kāi)著兩個(gè) shell或者用 SSH 從另一臺(tái)機(jī)器訪問(wèn)兩邊同時(shí)各跑一條todo done。如果兩邊都讀到舊數(shù)據(jù)、各自修改后再寫(xiě)回會(huì)出現(xiàn)經(jīng)典的“后寫(xiě)覆蓋先寫(xiě)”問(wèn)題——一個(gè)任務(wù)標(biāo)記完成了另一個(gè)終端又把它還原了。解決辦法也不復(fù)雜在 Linux/macOS 上用fcntl對(duì)數(shù)據(jù)文件加鎖鎖持有期間才允許做加載-修改-寫(xiě)回操作在 Windows 上則退化為樸素的“先清臨時(shí)文件再直接寫(xiě)”因?yàn)閒cntl不是標(biāo)準(zhǔn)庫(kù)。簡(jiǎn)單起見(jiàn)我給工具加了一個(gè)啟動(dòng)鎖文件機(jī)制核心代碼如下import fcntl LOCK_FILE os.path.expanduser(~/.todo.lock) def acquire_lock(): f open(LOCK_FILE, w) fcntl.flock(f, fcntl.LOCK_EX) return f def main(): lock acquire_lock() data load_data() # 執(zhí)行命令邏輯 save_data(data) fcntl.flock(lock, fcntl.LOCK_UN)當(dāng)然鎖只能約束使用同一個(gè)工具的進(jìn)程。如果你用編輯器直接修改 JSON 文件又正好和工具寫(xiě)回并發(fā)操作依然可能沖突這個(gè)只能靠使用習(xí)慣回避。但工具之間的相互覆蓋問(wèn)題用鎖已經(jīng)可以杜絕了。5.3 數(shù)據(jù)遷移、備份與向前兼容我在load_data里留了schema_version字段這個(gè)字段到現(xiàn)在已經(jīng)救過(guò)我一兩次了。每版腳本如果字段結(jié)構(gòu)發(fā)生變化就在數(shù)據(jù)文件加版本號(hào)加載的時(shí)候根據(jù)版本號(hào)走對(duì)應(yīng)的遷移函數(shù)而不是直接按當(dāng)前代碼期望的結(jié)構(gòu)解析。字段一旦不匹配程序要么報(bào)錯(cuò)要么悄悄產(chǎn)生空值都會(huì)造成數(shù)據(jù)污染。備份則是一個(gè)獨(dú)立的todo backup命令它的實(shí)現(xiàn)是復(fù)制當(dāng)前數(shù)據(jù)文件為帶時(shí)間戳的.bak文件todo backup # 生成 ~/.todo.20250608-1530.bak說(shuō)實(shí)話這個(gè)命令我平時(shí)很少主動(dòng)想起來(lái)用所以后來(lái)干脆在每次“批量刪除”之前自動(dòng)跑一次備份。這樣即便確認(rèn)時(shí)手滑選中了不該刪的任務(wù)也還有上次操作前的完整快照。命令行工具的意義不是讓你更膽大而是讓你在犯錯(cuò)之后有退路。6. 連續(xù)使用一段時(shí)間后的真實(shí)體驗(yàn)與擴(kuò)展方向工具做完以后我把它裝進(jìn)了自己的日常工作流現(xiàn)在幾乎每天都在用。這一章不寫(xiě)教程式的收尾只記錄幾段真實(shí)使用感受以及這個(gè)項(xiàng)目未來(lái)可能延伸出的方向。6.1 日常使用方式與真實(shí)感受我現(xiàn)在最典型的使用節(jié)奏是早上到工位先打開(kāi)終端跑一遍todo list --status pending --due-before today看一眼今天必須處理的事。然后整天的雜事都往里面塞有的任務(wù)連一個(gè)描述都沒(méi)有只有一句話標(biāo)題比如“恢復(fù)某服務(wù)自動(dòng)更新”。處理到一半的會(huì)在狀態(tài)上標(biāo)成進(jìn)行中靠todo list --status in_progress把握手頭節(jié)奏。每次進(jìn)入代碼庫(kù)之前我也會(huì)用todo add把腦子里想到的收尾工作記下來(lái)避免寫(xiě)著寫(xiě)著把“記得補(bǔ)充注釋”這條細(xì)節(jié)徹底忘掉。這種“寫(xiě)到一半隨時(shí)記一筆”的場(chǎng)景圖形應(yīng)用做不到這么好因?yàn)榍凶叩乃查g注意力就斷了。真實(shí)感受中最重要的一點(diǎn)是這個(gè)工具因?yàn)椤疤?jiǎn)陋”反而沒(méi)有心理負(fù)擔(dān)。圖形待辦應(yīng)用功能多但正經(jīng)事沒(méi)記住多少而命令行工具只記任務(wù)本身連打開(kāi)它都覺(jué)得輕快所以記錄黏性反而很高。這也印證了我最初的觀點(diǎn)工具不應(yīng)該用功能數(shù)量來(lái)評(píng)價(jià)而要看它能不能融入你的使用習(xí)慣。6.2 現(xiàn)有方案的明顯短板必須誠(chéng)實(shí)地說(shuō)這個(gè)工具目前還有幾個(gè)短板。第一是沒(méi)有真正的“提醒”能力我只能靠每次list看到過(guò)期任務(wù)被動(dòng)提醒無(wú)法在任務(wù)到期時(shí)主動(dòng)通知。解決方案是外面套一個(gè) crontab 任務(wù)定期運(yùn)行但這樣也沒(méi)法做到像手機(jī)推送那樣實(shí)時(shí)。第二是移動(dòng)端場(chǎng)景完全空白如果出門(mén)在外想添加一個(gè)任務(wù)只能通過(guò)遠(yuǎn)程終端這對(duì)沒(méi)有隨身帶電腦習(xí)慣的人很不方便。第三是交互式編輯缺失想改一長(zhǎng)串描述時(shí)update的參數(shù)方式遠(yuǎn)不如一個(gè)編輯器來(lái)的高效。這幾塊短板讓我意識(shí)到命令行工具適合做“個(gè)人快速記錄和信息維持”但不適合做“全天候提醒中心”。做好定位比追求功能大而全更實(shí)際。6.3 再往下走這個(gè)項(xiàng)目可以長(zhǎng)成什么樣如果繼續(xù)迭代第一批我會(huì)做提醒與過(guò)期掃描。在list輸出中把過(guò)期的待辦任務(wù)前置并且用顯眼的字符標(biāo)記“已過(guò)期”再加一個(gè)todo today命令只顯示今天到期或已過(guò)期的任務(wù)。這能提高每天開(kāi)始的效率。第二批是子任務(wù)和重復(fù)任務(wù)。子任務(wù)滿足“一個(gè)大任務(wù)拆成幾個(gè)小步驟”的天然分解需求重復(fù)任務(wù)解決“每天早上更新環(huán)境”這類周期性事項(xiàng)。這兩個(gè)功能都會(huì)讓任務(wù)模型復(fù)雜化需要小心控制擴(kuò)展范圍。第三批是統(tǒng)計(jì)與導(dǎo)出。比如每周自動(dòng)輸出一份任務(wù)完成率報(bào)告或者導(dǎo)出成 iCal 格式與日歷應(yīng)用打通。這塊是錦上添花把一個(gè)至少“能記錄”的工具變成“能復(fù)盤(pán)”的數(shù)據(jù)源。在我個(gè)人的實(shí)踐里命令行待辦事項(xiàng)應(yīng)用最值得推薦的部分其實(shí)不是某個(gè)具體功能而是一種“以小事撬動(dòng)日常效率”的做法。先動(dòng)手做一個(gè)最小可用的版本放進(jìn)真實(shí)使用中再讓它沿著自己的習(xí)慣慢慢成長(zhǎng)。所謂效率工具從來(lái)不是安裝一個(gè)別人的完美作品而是長(zhǎng)成你自己用得最順手的模樣。