輸出導向：知識要可行動，計畫與報告由零件組起來

輸出導向：知識要可行動，計畫與報告由零件組起來 又要寫這個版本的測試計畫了。 你打開一個空白文件，游標閃著。明明做過十幾次測試計畫，腦袋裡也有一堆累積的知識，但還是從第一個字開始打。寫完發現，跟上次那份其實八成像，只是又手刻了一遍。 測試報告也一樣，每次從零拼。 知識囤了一整個系統，真正要產出東西的時候卻沒派上用場。系統建得越好，這個落差越讓人困惑：東西明明都在，為什麼還像從頭開始？ 囤積本身沒有價值 前面七篇都在往系統裡放東西：蒐集、組織、做可重用的零件、連上業務規則、把 bug 整理成啟發、用索引筆記當地圖。這些是基礎建設，但光放進去還不夠。 一個只進不出的系統，再整齊也只是漂亮的倉庫。 你花時間整理的測試模式、業務規則連結、bug 啟發，如果每次產出時還是打開白紙，就等於白整理了。 從白紙開始，是一個習慣問題 卡住的原因，多半是用創作的方式在做組裝的工作。 創作是從無到有。組裝是把現有的零件排在一起。這兩件事的腦力消耗差很多：創作很累，組裝很快。但多數人面對「要寫測試計畫」的時候，本能地走進了創作模式：打開空白頁，從頭開始想這份計畫該涵蓋什麼。 其實不用從頭想。翻一遍已經有的東西，把能用的撈出來，再補這次特有的部分。 計畫和報告的骨架，其實是固定的 一份測試計畫，結構上跑不出幾個要素：範圍、測試角度、風險重點，加上這次特有的安排。 一份測試報告，結構上也就是跑了什麼、發現什麼、風險結論。 這些骨架不會每次都不一樣。每次不一樣的，只有「這個功能的具體內容」。 骨架不用每次重新設計，把現成的零件填進去就好。 計畫的 範圍 ：從你之前做的業務規則連結網撈：這個功能動到哪些規則、影響哪些模組，連結網幾乎已經把範圍框好了，你只需要確認。 計畫的 測試角度 ：從你整理的可重用測試模式撈：這類功能你以前整理過哪些測試切入點、哪些 checklist，直接套用，再看這次有沒有特殊情況要調整。 計畫的 風險重點 ：從歷史 bug 整理出來的啟發撈：這個功能或相關模組過去踩過什麼坑、哪些地方容易出問題，這些啟發就是風險清單的原料。 把這三個方向的東西撈出來，計畫的骨架就有了。你真正需要想的，只有「這次有什麼跟以前不一樣的地方」。 我現在展列測試情境就是這樣做：先填一張固定格式的需求單，讓 AI 讀知識庫產出情境草稿，我審過才變成正式的測試案例。草稿會分開標出哪些是確認過的規則、哪些是 AI 推的、哪些還要問 PM。我的時間也跟著換了地方，花在想測試案例的少了，花在確認資訊的多了。 輸出的同時，系統也在被餵養 這一環最容易被忽略：每次輸出，也是在幫系統補洞。 你在組裝測試計畫的時候，會發現某個模組的測試模式零件還沒整理好，這個角度以前沒記下來。順手補進去，系統就厚了一點。 你在寫測試報告的時候，發現這次的 bug 跟以前一條啟發很像，但出現了新的變形。把新的變形補進去，下次碰到類似情況就有更完整的參照。 我的知識庫是在這個循環轉起來之後才變快的：流程順了，用的人就多；用的人多，寫回來的知識就多；知識多了，AI 產出更好，大家更願意用。只進不出的系統，零件越堆越多，卻不知道哪個真的有用。 怎麼開始 第一次這樣做，系統可能還很空，撈出來的東西不多。沒關係，重要的是先養成這個動作：動手寫計畫之前，先花五分鐘翻一遍系統，把能用的東西撈到旁邊，再開始組。 就算這次只撈到一兩個零件，你也省掉了憑空想這兩個部分的時間。而且用的過程中會看到哪裡該補，補完，系統就比上次厚一點。 幾次之後，翻系統會變成輸出的第一步。打開的不再是空白頁，是一堆等著組裝的材料。 下一篇：系統建好了，也開始用了，但三個月沒人維護，往往又悄悄爛回去。怎麼讓第二大腦不靠意志力撐，長在日常工作流裡？