我最早意識到自己需要一個“CLI-Anything”這樣的工具是因?yàn)槟骋惶煨难獊沓睌?shù)了一下自己電腦里隨手寫的.py、.sh、.js腳本。不算項(xiàng)目里的光是散落在~/scripts、/usr/local/bin和項(xiàng)目根目錄的小工具就有四十多個。有的用來批量重命名文件有的用來查端口占用有的用來把 JSON 轉(zhuǎn) CSV有的只是固定格式地拉取某個接口的數(shù)據(jù)然后拼成一段話復(fù)制到剪貼板。這四十多個腳本的問題不在于多而在于“記不住”。我經(jīng)常忘記某個腳本叫什么名字、參數(shù)是什么最后索性重新寫一遍。后來我下定決心把所有這些零散腳本統(tǒng)一收攏到一個命令行入口里起名就叫cli-anything。它的核心思路很簡單把幾乎所有日常零碎的小功能全部收納進(jìn)一個統(tǒng)一的命令行工具通過子命令的方式調(diào)用。這篇文章就是我對這個項(xiàng)目從零到可用、再從可用到順手整個過程的一個完整復(fù)盤。如果你也攢了一堆腳本不知道該怎么管理或者你總想在終端里少敲幾個字、少記幾個命令這篇文章應(yīng)該對你有用。我會從設(shè)計(jì)思路、架構(gòu)選型、核心實(shí)現(xiàn)、踩坑經(jīng)歷到擴(kuò)展方向盡量講得細(xì)一點(diǎn)方便你直接照著搭一套屬于自己的“命令行萬能工具箱”。1. 先想清楚這個工具到底解決什么問題1.1 腳本多到記不住才是真痛點(diǎn)很多人覺得“命令行工具”都是給程序員用的跟自己沒關(guān)系。但真正常年混終端的人心里都清楚日常碰到的“小事”有多煩圖片要壓縮一下再發(fā)出去找不到趁手的工具打開網(wǎng)頁圖片壓縮怕泄露隱私。日志文件太大想快速看一眼最后的 500 行每次都要想tail -500還是tail -n 500。后端給了一串 JSON想格式化一下看層級關(guān)系復(fù)制到在線工具還要擔(dān)心數(shù)據(jù)被拿去訓(xùn)練。每天要提交的 Git 分支名長得離譜每次都要復(fù)制粘貼。這些事單獨(dú)看都不難但每個都打開一個工具或者敲一長串命令人的耐心很快就被磨沒了。更關(guān)鍵的是這些操作通常還有“固定套路”——比如圖片壓縮完要輸出壓縮率、JSON 格式化完要自動復(fù)制到剪貼板。這些套路一旦固化成腳本再收攏到一個命令入口里日常效率的提升是非常明顯的。cli-anything定位的并不是把復(fù)雜任務(wù)“自動化”而是把高頻小操作“固化”成一條子命令。它不需要多智能前提是足夠順手、足夠統(tǒng)一、足夠好記。1.2 為什么不做圖形化界面而是死磕命令行有人可能問做成一個有界面的小工具不是更直觀嗎我的回答是如果你日常大部分工作流都在終端里界面的切換成本反而是最大的開銷。舉個例子圖片壓縮這件事如果我用圖形工具流程是打開工具 App、拖入圖片、等壓縮、另存為。但換成命令行流程是kai image /path/to/img.png壓縮完自動覆蓋原圖并輸出壓縮率。后者明顯更省事而且可以匹配進(jìn)已有的自動化流程里比如配合find批量壓縮目錄下所有圖片。再一個原因是命令行的“可組合性”。圖形界面的功能是封閉的但命令行工具天然可以和管道、重定向、循環(huán)組合。比如我壓縮完圖片希望順便把壓縮后的圖片上傳到圖床并把 markdown 鏈接復(fù)制到剪貼板用命令行幾行就寫出來了圖形工具里就很難這么玩。還有一個很現(xiàn)實(shí)的原因?qū)懸粋€命令行工具的成本遠(yuǎn)低于寫一個 GUI。只要處理好參數(shù)解析、輸出格式和錯誤提示一個子命令可能只需要幾十行代碼。投入產(chǎn)出比非常高。1.3 設(shè)計(jì)目標(biāo)裝進(jìn)兜里的瑞士軍刀我給cli-anything定了幾個設(shè)計(jì)目標(biāo)所有功能的取舍都以這幾個目標(biāo)為判斷標(biāo)準(zhǔn)子命令名字要好記全部用動作或縮寫比如img圖片處理、jsonJSON 工具、gitGit 助手、port端口檢查。參數(shù)要少核心功能不給用戶太多自由度能自動判斷就自動判斷能用默認(rèn)值就用默認(rèn)值。因?yàn)檎{(diào)用頻率高的工具每次多敲一個參數(shù)都是在增加摩擦力。輸出要克制終端輸出只保留關(guān)鍵信息能一行顯示就不要三行。報(bào)錯時則要給出人話提示而不是甩一段 Python traceback。無依賴優(yōu)先能用標(biāo)準(zhǔn)庫解決就不用第三方庫實(shí)在不行再把依賴打成一個子命令專用的小環(huán)境避免整個工具因?yàn)槟硞€子命令的依賴問題而崩掉。可擴(kuò)展新增一個子命令的成本必須足夠低最好只創(chuàng)建一個文件、寫一個函數(shù)就夠了。這五個目標(biāo)直接決定了后續(xù)的架構(gòu)形態(tài)。2. 架構(gòu)選型為什么我選了“路由 插件”而不是一個巨型腳本2.1 單體腳本的問題在于改一處崩一片如果只是新增一個功能就往同一個腳本里塞很快這個文件就會變成幾千行的大雜燴。你改動了某個公共函數(shù)可能影響十個完全不相干的子命令你想刪掉一個半年沒用過的功能又要小心不要碰壞別的地方。這種“牽一發(fā)動全身”的維護(hù)體驗(yàn)對一個高頻使用的個人工具來說是致命的。cli-anything一開始就采用了一個非常經(jīng)典的架構(gòu)主入口只負(fù)責(zé)命令路由每一個子命令都放在獨(dú)立的模塊里。主程序做的事情極少就是把用戶輸入的第一個參數(shù)映射到對應(yīng)的處理函數(shù)然后把剩余的參數(shù)傳過去。這樣做的好處非常多新增子命令時不需要改動主程序邏輯只需要在命令注冊表里加一行。刪除或者臨時禁用某個子命令時注釋掉注冊表里的一行就行物理隔離非常干凈。每一個子命令可以擁有自己的依賴互不干擾。某個子命令報(bào)錯了traceback 只涉及它自己的模塊排查范圍小很多。2.2 Python vs Node vs Shell我最終選了 Python做命令行工具的語言選型我見過太多爭論。有人覺得 Node.js 生態(tài)好有人覺得 Go 編譯成單個二進(jìn)制的體驗(yàn)最爽也有人堅(jiān)持純 Shell 足夠用。我的選擇是 Python理由很個人但可能對很多人也有參考價值標(biāo)準(zhǔn)庫覆蓋日常需求文件處理、JSON、壓縮包、hash 計(jì)算、HTTP 請求、子進(jìn)程管理標(biāo)準(zhǔn)庫基本都覆蓋了。寫起來沒有負(fù)擔(dān)隨手幾行就能處理一個格式調(diào)試也直觀。跨平臺好一些雖然我主要在 macOS 上使用但是偶爾切到 Linux 或 Windows 環(huán)境Python 腳本的兼容成本比 Shell 低太多了。第三方生態(tài)幾乎是萬能的以后想加什么功能往往是pip install一個庫然后封裝一下的事不會有“這事用 Python 做不了”的尷尬。缺點(diǎn)我也清楚Python 啟動時間比 Go 二進(jìn)制慢、分發(fā)時要處理解釋器環(huán)境。但對我這種自用工具來說幾百毫秒的啟動耗時完全可以接受依賴環(huán)境也就固定在一臺機(jī)器上根本不需要考慮分發(fā)問題。2.3 目錄組織方式一個子命令一個文件cli-anything的項(xiàng)目結(jié)構(gòu)非常簡單簡單到?jīng)]有任何框架味cli-anything/ ├── main.py # 入口解析參數(shù)并路由 ├── commands/ │ ├── __init__.py │ ├── img.py # 圖片壓縮、格式轉(zhuǎn)換 │ ├── json_tool.py # JSON 格式化、提取、轉(zhuǎn)換 │ ├── net.py # 端口檢查、下載測速、IP 查詢 │ ├── git_tool.py # 常用 Git 命令封裝 │ ├── file_tool.py # 批處理重命名、查找、去重 │ └── dev.py # 日常開發(fā)輔助 ├── utils/ │ ├── __init__.py │ ├── paths.py # 路徑與系統(tǒng)相關(guān)工具函數(shù) │ ├── output.py # 終端輸出的統(tǒng)一格式 │ └── clipboard.py # 剪貼板操作的跨平臺封裝 └── config.py # 全局配置、命令注冊表main.py里基本沒有具體業(yè)務(wù)邏輯只做三件事讀取sys.argv。查命令注冊表找到對應(yīng)的模塊和函數(shù)。調(diào)用函數(shù)捕獲異常并輸出格式化錯誤信息。實(shí)際代碼只有四十行不到。但這四十行是整個項(xiàng)目“活得久”的關(guān)鍵因?yàn)樗鼜?qiáng)制保證了每位新子命令作者都按固定的方式接入而不是想到哪寫到哪。2.4 命令注冊表自動化掃描命名規(guī)范命令注冊我試過手工維護(hù)一個大字典但后來發(fā)現(xiàn)每次新增命令都要改config.py里的一個表雖然不麻煩但屬于“可以避免的手工步驟”?，F(xiàn)在的做法是commands目錄下的每個.py文件暴露一個register函數(shù)或者一個COMMANDS字典主程序加載模塊時自動掃描并注冊。具體約定是每個子命令模塊內(nèi)部定義一個COMMANDS字典格式如下COMMANDS { compress: { help: compress images in current dir, handler: handle_compress }, convert: { help: convert image format, handler: handle_convert } }主程序遍歷commands目錄import所有模塊收集它們導(dǎo)出的COMMANDS合并成全局注冊表。這樣新增一個子命令只需要兩步創(chuàng)建文件、寫函數(shù)和COMMANDS表。注冊由程序自動完成入口文件永遠(yuǎn)不用改。這背后的設(shè)計(jì)理念是“約定大于配置”——你按照約定的方式寫剩下的一切都是自動的。對個人項(xiàng)目來說這種方式能讓你把有限的注意力放在功能本身而不是框架的接線工作上。3. 核心實(shí)現(xiàn)把“好用的細(xì)節(jié)”逐個打磨出來3.1 參數(shù)解析不用 argparse 的場合雖然 Python 標(biāo)準(zhǔn)庫有argparse但我在設(shè)計(jì)cli-anything時刻意沒有大規(guī)模用它。原因很簡單argparse適合參數(shù)多的復(fù)雜命令但我的子命令大部分參數(shù)就一個兩個用它反而要寫大量修飾代碼。我采用了一種非常輕量的方式在主程序里只做最簡單的切分第一個參數(shù)作為子命令名剩余參數(shù)全部傳給子命令處理函數(shù)。每個子命令內(nèi)部再決定如何解析自己的參數(shù)。這種方式的優(yōu)點(diǎn)是完全自由缺點(diǎn)是需要自己控制參數(shù)解析的異常。我在utils/args.py里寫了一個小工具函數(shù)專門處理“參數(shù)缺失”和“參數(shù)類型不符”的場景讓每個子命令的報(bào)錯文案保持統(tǒng)一def require_param(args, index, name): if len(args) index: err(fMissing parameter: {name}) sys.exit(1) return args[index]這樣一來寫一個新子命令時如果它有必填參數(shù)直接一行調(diào)用就能完成校驗(yàn)不用為每一個子命令額外寫一套參數(shù)異常處理。3.2 統(tǒng)一輸出人話優(yōu)先顏色克制個人工具的輸出風(fēng)格其實(shí)非常影響使用體驗(yàn)。我見過一些工具輸出一大堆彩色 ASCII 藝術(shù)邊框看得人眼花繚亂但信息密度極低。我的原則是成功輸出用綠色標(biāo)識失敗用紅色標(biāo)識普通信息用默認(rèn)色輔助信息用灰色千萬別濫用顏色。輸出這部分我封裝了一套簡單的工具函數(shù)def info(msg): # 普通提示 print(f {msg}) def ok(msg): # 成功 print(f\033[32m ? {msg}\033[0m) def warn(msg): # 警告 print(f\033[33m ? {msg}\033[0m) def err(msg): # 錯誤 print(f\033[31m ? {msg}\033[0m)別小看這幾個函數(shù)它們統(tǒng)一了全項(xiàng)目所有子命令的視覺風(fēng)格。更關(guān)鍵的是我在設(shè)計(jì)時就強(qiáng)制要求所有子命令遵循“先結(jié)果后細(xì)節(jié)”的順序——先告訴用戶“成功了”或“失敗了”再補(bǔ)充關(guān)鍵參數(shù)。因?yàn)樽鳛楦哳l工具用戶的第一需求是快速知道結(jié)果而不是看一段散文式的輸出。3.3 剪貼板封裝這個功能極大提升了幸福感很多人低估了“自動復(fù)制到剪貼板”這個功能的價值。以前我處理完一段 JSON 或者生成一段 markdown 代碼塊還需要手動選中、復(fù)制?，F(xiàn)在cli-anything里幾乎所有子命令都支持一個--copy標(biāo)志處理完直接往剪貼板里塞一份。實(shí)測下來這個小小的功能讓整個工具的使用頻率提升了一個量級。剪貼板這功能我在四個平臺上都驗(yàn)證過macOS直接使用pbcopy命令簡單可靠。Linux根據(jù)桌面環(huán)境使用xclip或xsel要提前確認(rèn)已安裝。Windows使用clip命令。通用場景Python 3.10用標(biāo)準(zhǔn)庫shutil.copy的 fallback雖然不夠底層但可以用。我封裝的方式非常務(wù)實(shí)檢測到當(dāng)前系統(tǒng)就選擇合適的命令不引入第三方剪貼板庫因?yàn)槟切焱鶐в写罅恳蕾嚥环稀拜p量”的定位。3.4 圖片壓縮子命令一個完整案例的拆解以最常用的圖片壓縮功能為例看看一個子命令從想法到落地要經(jīng)歷哪些步驟。圖片壓縮在命令行里其實(shí)有很成熟的方案macOS 可以調(diào)用系統(tǒng)自帶的sips命令Linux 可以調(diào)用 ImageMagick 的convert。但直接調(diào)用系統(tǒng)命令有兩個痛點(diǎn)參數(shù)太長記不住、輸出不夠友好。我對img compress子命令的要求是kai img compress xxx.png [--quality 80] [--copy]壓縮完自動備份原圖到.trash目錄并輸出壓縮前后的大小對比和壓縮率。核心邏輯如下def handle_compress(args): path require_param(args, 0, image path) quality 80 if --quality in args: idx args.index(--quality) quality int(args[idx 1]) original_size os.path.getsize(path) tmp_path path .tmp.jpg # macOS 下的 sips 方案 res subprocess.run( [sips, -s, format, jpeg, -s, quality, str(quality), path, --out, tmp_path], capture_outputTrue ) if res.returncode ! 0: err(fCompress failed: {res.stderr.decode()}) sys.exit(1) compressed_size os.path.getsize(tmp_path) ratio (1 - compressed_size / original_size) * 100 shutil.move(tmp_path, path) ok(fCompressed: {format_size(original_size)} - {format_size(compressed_size)} ({ratio:.1f}% smaller)) if --copy in args: clipboard_copy(path) # 把壓縮后的圖片路徑復(fù)制到剪貼板這里有幾個細(xì)節(jié)值得注意。第一先壓縮到臨時文件再替換原文件這樣萬一壓縮失敗不會把原圖搞壞。第二壓縮質(zhì)量給了默認(rèn)值 80用戶不傳參數(shù)也能直接用。第三輸出里包含壓縮率這是用戶最關(guān)心的數(shù)據(jù)。3.5 JSON 子命令把“半分鐘一次”的操作果斷收編JSON 格式化是我日常頻率最高的操作之一。每次對接接口都要把返回的一長串 JSON 扔到格式化工具里。json_tool子命令實(shí)現(xiàn)了幾個核心功能kai json fmt格式化 JSON 并支持--copy。kai json find key.subkey從 JSON 里按路徑提取某個字段的值。kai json csv把一個 JSON 數(shù)組轉(zhuǎn)成 CSV 文件。find這個功能的實(shí)現(xiàn)挺有意思。很多人第一次遇到“從嵌套 JSON 里取某個字段”會覺得用jq就完了但jq的語法對非重度用戶是有學(xué)習(xí)成本的。我的實(shí)現(xiàn)是用點(diǎn)號路徑逐層查找def find_by_path(obj, path): parts path.split(.) current obj for part in parts: if isinstance(current, dict): current current[part] elif isinstance(current, list): current current[int(part)] else: raise KeyError(fCannot traverse into {part}) return current這個功能極大的好處是零學(xué)習(xí)成本路徑表達(dá)非常直觀。雖然它遠(yuǎn)不如jq靈活但對大多數(shù)人來說“夠用”比“強(qiáng)大”更重要。工具設(shè)計(jì)就是這個道理如果每個功能都追求極致用戶每天要記的語法就太多了。3.6 Git 子命令少敲一個字的舒服Git 相關(guān)的子命令設(shè)計(jì)思路不一樣它不追求新功能而是把幾個高頻操作壓縮成短命令kai git branch-copy復(fù)制當(dāng)前分支名到剪貼板省去每次手動選中復(fù)制的操作。kai git touch在本地和遠(yuǎn)程倉庫同步創(chuàng)建一個新分支省得記兩條命令。kai git cleanup清理本地已經(jīng)合并到主干的分支并列出刪不掉的分支和原因。這個子命令的代碼量不大但它解決的是終端用戶每天都會碰到的“肌肉記憶成本”。每次少敲幾個字、少復(fù)制粘貼一次日積月累省下來的時間其實(shí)很可觀。4. 實(shí)操中踩過的坑這四類問題你早晚會碰上4.1 子命令內(nèi)部 import 第三方庫失敗第一個踩到的大坑是在個別子命令里用了第三方庫但主程序啟動時并沒有校驗(yàn)這些依賴是不是安裝了。結(jié)果用戶辛辛苦苦敲了命令等了幾秒彈出來的是一坨 traceback完全不符合“人話優(yōu)先”的原則。我的解決方案是給每個子命令加一個“依賴預(yù)檢”機(jī)制。在COMMANDS表里可以聲明deps字段列出這個子命令依賴的 Python 包名。主程序在路由到該子命令之前先嘗試 import 這些依賴失敗的話直接輸出一條友好的提示? Missing dependency: pillow Please install first: pip install pillow對于帶第三方依賴的子命令還可以做“惰性加載”——不把第三方庫在模塊頂層導(dǎo)入而是在函數(shù)內(nèi)部才 import。這樣即使這個庫沒有安裝也只會影響這個子命令本身不會拖垮整個工具。4.2 參數(shù)解析中把“字符串?dāng)?shù)字”和“整數(shù)”搞混這種問題聽上去很基礎(chǔ)但實(shí)際工作中非常容易出現(xiàn)。比如從參數(shù)里取quality直接在int()轉(zhuǎn)換。如果用戶傳了80abc程序就會崩出一個 ValueError。我的統(tǒng)一做法是寫一個parse_int_arg函數(shù)解析失敗時給出清晰的提示并列出合法范圍def parse_int_arg(value, name, min_valueNone, max_valueNone): try: num int(value) except ValueError: err(fInvalid value for {name}: {value}) sys.exit(1) if min_value is not None and num min_value: err(f{name} must be {min_value}) sys.exit(1) if max_value is not None and num max_value: err(f{name} must be {max_value}) sys.exit(1) return num這類錯誤很底層但恰恰是這些底層的細(xì)節(jié)決定了一個命令行工具是“好用”還是“難用”。你想想報(bào)錯信息如果是一行invalid literal for int() with base 10普通用戶直接懵掉。但換成Invalid value for quality: abc誰都能看懂。4.3 輸出內(nèi)容被終端截?cái)嗷蛘邅y碼另一個實(shí)際問題是對非 ASCII 字符和超長輸出的處理。我發(fā)現(xiàn)個別子命令輸出的文字包含特殊符號時在某些終端主題下顯示異常。而更經(jīng)常遇到的問題是輸出內(nèi)容過長時直接被終端截?cái)嗔擞脩艨床坏疥P(guān)鍵信息。我的解決方案是把輸出函數(shù)里增加一個“長度控制”參數(shù)def ok(msg, max_len80): display msg if len(msg) max_len else msg[:max_len - 3] ... print(f\033[32m ? {display}\033[0m)同時把完整信息寫入日志文件~/.kai/logs/如果用戶看到截?cái)嗔丝梢匀ト罩纠锓暾麅?nèi)容。這種“終端精簡但日志詳細(xì)”的輸出模式在個人工具里非常實(shí)用。4.4 路徑中的空格和特殊字符引發(fā)的血案路徑帶空格是命令行工具的經(jīng)典殺手。我早期寫文件處理子命令時直接通過subprocess.run([sips, path, ...])調(diào)用基本都能正確處理。但某些子命令為了省事用了fcommand {path}的字符串拼接方式一個帶空格或中文的路徑就能讓命令支離破碎。我的原則很明確凡是要傳給子進(jìn)程的路徑一律用列表參數(shù)形式禁止字符串拼接。只有在生成 shell 命令腳本時才用shlex.quote()做轉(zhuǎn)義。這個原則執(zhí)行到位之后路徑相關(guān)的 bug 基本絕跡。另外在處理用戶輸入的路徑時我會先做os.path.expanduser()和os.path.abspath()處理把~和相對路徑都轉(zhuǎn)成絕對路徑這樣后續(xù)邏輯里拿到的一定是一個完整可靠的路徑不會因?yàn)椤爱?dāng)前目錄不同”而產(chǎn)生不同結(jié)果。5. 工具擴(kuò)展方向從“能用”到“好用”的幾個實(shí)用建議5.1 增加一個“輸出可編程”模式普通終端用戶看到的是友好的人類可讀輸出但對于想進(jìn)一步自動化的人來說人類可讀文本反而不好解析。我計(jì)劃給cli-anything增加一個全局參數(shù)--json任何一個子命令執(zhí)行后都可以輸出機(jī)器可讀的 JSON 格式結(jié)果比如kai img compress xxx.png --json輸出{status: ok, original_size: 1024000, compressed_size: 512000, ratio: 50.0}這樣一來在外層腳本里調(diào)用cli-anything就能很輕松地把結(jié)果解析出來做下一步操作。這個功能的實(shí)現(xiàn)對內(nèi)并不難關(guān)鍵在于每個子命令要有“結(jié)果對象”的概念輸出時統(tǒng)一按人類格式或 JSON 格式渲染。5.2 增加子命令之間的互相調(diào)用機(jī)制很多操作并不是獨(dú)立存在的。比如“下載一張圖片并壓縮”可以拆成兩個子命令但能不能一條命令完成能不能支持“管道”式的鏈?zhǔn)秸{(diào)用目前cli-anything的做法是允許子命令內(nèi)部調(diào)用其他子命令的函數(shù)未來的方向是提供更依賴式的編排方式比如kai run download url | kai run compress --quality 60不過說實(shí)話這種鏈?zhǔn)秸{(diào)用目前用原生的 shell 管道也能實(shí)現(xiàn)關(guān)鍵是每個子命令的輸出要足夠干凈。所以“輸出可編程模式”其實(shí)是“互相調(diào)用”的前置條件。5.3 增加配置文件記住用戶偏好目前很多參數(shù)靠默認(rèn)值但如果用戶經(jīng)常用某個參數(shù)就可以配置一個持久化的偏好。比如圖片壓縮質(zhì)量默認(rèn)是 80如果某人經(jīng)常用 70那應(yīng)該可以通過~/.kai/config.yaml配置img: compress: quality: 70 backup: true這屬于“越用到后面越離不開”的功能。不過優(yōu)先級不高因?yàn)閭€人工具的使用者通常只有自己改配置的頻次很低。如果這個工具給團(tuán)隊(duì)用配置文件的必要性和優(yōu)先級都會大幅上升。6. 項(xiàng)目收益復(fù)盤這個折騰值不值從純粹的“節(jié)省時間”角度看搭建cli-anything這件事一開始的投入大約是十幾個小時包括架構(gòu)設(shè)計(jì)、核心命令實(shí)現(xiàn)、踩坑修復(fù)。這十幾個小時多久能回本我用簡單的方式估算了一下以前隨手操作一次圖片壓縮大概要二十秒到一分鐘打開工具、導(dǎo)入、導(dǎo)出、對比現(xiàn)在一條命令大概兩秒。按每天使用十次計(jì)算一天節(jié)省大約三分多鐘一個月就是一百多分鐘半年就能回本這十幾個小時。而且還不算“不用打開圖形軟件”的專注力節(jié)省。從“降低摩擦帶來行為改變”的角度看收益遠(yuǎn)不止時間。以前我雖然知道“可以寫腳本”但很多場景還是會因?yàn)椤伴_編輯器寫腳本”的成本而放棄。現(xiàn)在往cli-anything加一個新子命令的成本就是“創(chuàng)建一個文件、寫一個函數(shù)、注冊一行命令”從想法到落地經(jīng)常十分鐘內(nèi)搞定。當(dāng)工具的使用成本降到這個程度人的行為會有質(zhì)的改變——你更愿意自動化了也更愿意給自己省事了。從“思維能力”的角度看這個項(xiàng)目讓我把很多“接口式思維”固化了下來。每個子命令的本質(zhì)是一個函數(shù)集合輸入?yún)?shù)、返回結(jié)果、處理錯誤這些模式和寫后端接口的思維是一致的。當(dāng)你習(xí)慣用這種方式拆解日常問題時你會發(fā)現(xiàn)很多重復(fù)性的操作都可以“接口化”“工具化”。所以回到標(biāo)題CLI-Anything 到底是什么它不是一個了不起的開源項(xiàng)目也不依賴什么高深的技術(shù)。它就是你給自己打造的一套“命令行外掛”把生活中高頻發(fā)生的、有明確套路的、適合在終端里完成的小事全部收納到一個入口里。平時它安安靜靜地躺在那里但你每一次敲下它都是在用十幾分鐘前的自己幫現(xiàn)在的自己省下幾十分鐘。我個人在實(shí)際操作中最大的體會是與其買各種“效率神器”軟件不如先把自己重復(fù)做三遍以上的操作列一個清單。那些能寫進(jìn)命令行的試著往自己的工具箱里裝。裝得多了你會發(fā)現(xiàn)終端這個東西越用越順手越用心越細(xì)。最后再分享一個小技巧沒必要一開始就追求架構(gòu)完美先在一個目錄里堆腳本也完全可以當(dāng)你哪天覺得“這堆東西實(shí)在沒法維護(hù)了”再重構(gòu)也來得及。CLI-Anything 的真正起點(diǎn)永遠(yuǎn)是你覺得“這事必須治一治”的那一刻。