技能商店
實驗室驗證過的安全技能
微任務三欄法：把 5 分鐘內能做完的事立刻清掉
每天早上從郵件切換到即時通訊軟體，再切換到行事曆，再切回文件——每次切換，大腦都要重新載入脈絡。研究發現一次脈絡切換平均損失 4 到 15 分鐘的專注時間。問題不在任務本身，而在於「要不要現在做」這個判斷本身就在消耗注意力。對付這類小事，最省力的辦法不是排程，而是給它一個固定出口。
給自動化任務留一張「交接卡」：讓明天接手的人 10 秒上手
上週深夜排查一個半夜跑的排程任務，我把「最近一次成功是什麼時候、失敗時該看哪個日誌」問了三個 AI 和兩份文件，誰都沒給我答案。任務本身沒死，但沒人說得清它現在怎麼樣了——這種「活著但不透明」的狀態，比任務直接掛掉更危險。
AI 改完程式碼，先一格一格讀 DIFF：30 秒的慢功夫，省下半天的救火時間
上次 AI 幫我清理一批排程腳本，它說「全部改好，邏輯等價」。我信了，讓它直接提交。當晚線上警報響起：三個腳本裡有兩條日誌被靜默吞掉了——它把帶 -f 的 stderr 重新導向順手「統一」掉了。復原、排查、修正，一共花掉四十分鐘。從那以後我固定一個習慣：AI 改完程式碼，先一格一格讀 DIFF，再談下一步。
分號、&& 與 ||：每天敲一萬次、卻極少人真正理解的命令鏈
每天早上我都會收到「我的 shell 腳本寫崩了」的求助，八成問題不在邏輯，而在這一行：
給凌晨兩點的自己寫備註：交接備註（Handoff Note）
把「做了什麼、為什麼這麼做、下一步風險在哪」寫在旁邊，讓任何不在線的讀者——尤其是未來的你——能直接接手，不用再翻聊天記錄。
改動前後，手動核對一遍 DIFF：小改動的隱性成本
你讓 AI 改了設定檔，或者手動動了一個 if 分支，點上「儲存」的那一刻，以下三件事發生了：
唯讀優先：第一次執行目標系統前先做唯讀驗證
你要為新環境部署設定變更，或是在執行緒中讓 AI 修改生產環境設定。你寫了一個改動，一發布上去整個服務就掛了，底下的人在罵你。經典情境：
把「大概能跑」變成「每次都能跑」：本機復現流程
具體場景：你寫了一個自動化腳本，在自己的機器上跑通了，傳給同事，他回一句：「我這裡報錯了。」或者更糟——三個月後你自己再跑，等著修環境。這種「在我這裡能跑」的尷尬，根源不是程式碼寫得差，而是你沒有把復現流程當成交付物的一部分來寫。
交付前的「提交檢查清單」：把交付事故消滅在最後一個小時
具體場景：週五下午 4 點，你把功能提交、寫了說明、截圖、打了個 tag，然後下班。週一早上客戶回覆：「欄位少了一個」、「顏色不對」、「沒有寫重啟步驟」。這些事故 90% 都能用一份提交檢查清單在最後一個小時攔下來。
上線後的三十秒：先想清楚怎麼退
週一早上 9 點，你改了一行支付閘道的超時設定，按下 Enter，部署完成，掃過日誌，清爽。你鬆了口氣，繼續去開別的會。
上線前先寫好回滾方案（Rollback First）
上週我盯的一次發版，新程式碼上線 20 分鐘後報了一個邊界資料異常。排查、定位、準備熱修，前後燒掉兩小時。事後復盤發現一個更扎心的事實：如果上線前花 10 分鐘寫一張「回滾單」，那兩小時裡至少有一小時半可以直接跳過——因為窗口的第一步本來就是「先回滾再查」，而當時沒人提前確認過回滾到底怎麼回、回不到哪裡。
卡住 15 分鐘，就對付一隻鴨子
上週四晚上，一個爬蟲任務卡在第三步，報錯說檔案不存在。我盯著程式碼看了二十分鐘，換了個變數名稱、重啟、又改路徑，全沒用。最後我打開一個空白文件，逼自己把問題寫成一句話：「任務從 /data/inbox 讀取檔案，而這個檔案昨天被批次處理任務移走了，沒人記錄。」寫完那一刻就發現了——不是程式碼有 bug，是我上週改了路徑