維護習慣：讓第二大腦長在工作流裡，不再爛回去

維護習慣：讓第二大腦長在工作流裡，不再爛回去 三個月前，你下定決心建了一套系統。 收件位置設好了，分層定好了，零件庫也有了幾個可重用的 checklist。前兩週很勤：需求討論完順手記，踩到雷的當下馬上補。有種終於把東西整理清楚的感覺。 然後一個趕版本的衝刺來了。三週內兩個功能、設計稿改了四次，bug 一批接一批。沒空整理，就先欠著。衝刺結束之後，說要補，但下個版本又來了。 三個月後，你打開那個系統，收件位置積了七十幾條沒處理的筆記，分層亂掉了，零件庫幾個檔案不知道是不是還準。 你心想：果然這種東西撐不久。 我自己也有過這種時候。有一個月我幾乎沒碰知識庫，整理很花時間，每寫一筆、每補一條規則，當下都看不到回報，我開始懷疑它值不值得。 爛掉的原因不是你不夠勤 系統爛回去，多半是因為把建系統當成一次性的專案。 專案有起點、有終點：「我要建一套知識系統」，建好，打勾，完成。但知識管理沒有完成的那一天。產品一直在改，知識就得一直跟著改。 很多人的解法是「更勤奮地維護」：安排固定的清理時間，計畫每週整理一小時。這通常撐不過一個月。固定排出來的維護時間，是第一個在忙碌衝刺裡被砍掉的行程。 比較有用的做法是讓維護變輕，輕到最忙的衝刺也不會被放棄。方法是把維護綁進你本來就會做的事，不另外開時間。 三個維護錨點 三個錨點都掛在你原本就有的節奏上，不用養新習慣。 第一個錨點：蒐集綁進日常。 需求討論的當下、站會裡聽到一條資訊、測試踩到一個雷，順手丟一條進收件位置。一句話就夠，不需要整理好再放。「這個欄位驗證有個邊界條件：空字串和 null 行為不同」，就這樣，丟進去，繼續手邊的工作。 這個動作發生在工作的自然中斷點，不用切換狀態，也不用另外找時間。 第二個錨點：整理綁進版本收尾。 每個版本收尾本來就有一些固定動作：retro、handoff、上線後觀察。在這個節點，順手清一次收件位置：把該分類的分類、該下沉的下沉、這版踩到的坑補進零件庫。 版本節奏就是整理節奏。一個版本一次，不積，不另外安排。 這招有效，是因為版本收尾本來就是回顧期，注意力本來就在「這版發生了什麼、學到了什麼」，順手整理系統很自然。 第三個錨點：回顧綁進固定時段。 每週或每兩週，花十分鐘掃一遍整個系統：有沒有死掉的連結、有沒有零件已經長大到可以獨立一個分類、功能地圖還準不準。十分鐘，不求完美，只要有沒有跑偏的感覺。有，調一下；沒有，關掉，繼續下一件事。 死掉的連結這種事，我後來交給腳本。知識庫用 git 留版本，用檢查腳本抓壞掉的連結和格式不對的頁面，bug 入庫、重建索引也不用手動做。能自動的交給腳本，那十分鐘就只花在需要判斷的地方。 這個回顧不需要很頻繁。兩週一次比一週一次更容易撐下去。目標只是別讓它在你沒注意的時候爛掉。 收尾時留一條筆記給未來的自己 有個小習慣很划算，可以放進蒐集那個錨點：每次測試告一段落，花一分鐘留一條筆記，寫現在卡在哪、下一步要做什麼、有什麼快忘掉的細節。 下班前、衝刺結束前、中途被打斷去開會之前，就一分鐘，寫下「目前狀況 + 下一步」。 下次回來，不用花二十分鐘重新進入狀況。順著那條筆記就接上了。 這條筆記也是蒐集的一種：它讓中斷點的 context 不流失。你腦袋裡那個「下次要記得……」的念頭，寫下來就不用靠記性了。 不要追求完美結構 系統爛掉的另一個常見原因，是花太多時間糾結結構，反而沒在用。 「這條筆記應該放在哪個分類？」「這個零件的命名不夠精準，要先想清楚再放。」「等我把結構設計好再開始。」 這種完美主義的心態，讓整理變成一件消耗能量的事，累了就放棄。 一個有點亂但一直有人在用的系統，比結構漂亮但三個月沒人碰的系統有用得多。分類不精準、命名有點將就，都沒關係，用的過程裡結構會慢慢調整。 九篇，一個完整的迴圈 這是系列的最後一篇。 S02 讓知識進來有地方落，不再散在 Slack、Figma 和站會的一句話裡。S03 分層，讓活的案例浮上來、過期的下沉，案例庫才信得過。S04 把反覆用到的思路做成零件，下次直接套用。 S05 把 case 連到業務規則，「這次改動要回歸哪些」不用靠記憶。S06 把踩過的 bug 整理成測試啟發，同一類問題在設計測試時就攔住。S07 用索引筆記當地圖，新人不用靠口耳相傳。S08 從零件組出測試計畫和報告，不從白紙開始。 S09 讓整套東西長在工作流裡，靠輕量的錨點維持，不靠意志力。 回到 S01 那個場景：上線前三天，負責回歸的資深 QA 臨時請假，整個版本卡住。 如果知識在系統裡，又有三個錨點讓它一直被維護，那位 QA 請假，版本測試也不會停擺，因為知識不只在一個人腦袋裡，其他人也看得到、接得下去。 可以先在行事曆排一個固定時段，每週十分鐘，或下個版本收尾時的整理時間。先排進去，其他的坐下來再說。