為什麼專案需要「證據」？成品只能證明最後長什麼樣

一個網站終於上線，畫面很完整，按鈕會動，手機也能正常開。半年後有人問：「登入權限當初怎麼設計的？」「這個版面為什麼改過三次？」「你在這個專案裡到底負責哪一段？」如果手上只剩最後一張截圖，很多答案就會開始靠記憶拼。成品還在，但專案真正發生過的事情已經消失了一大半。

專案裡的證據，可以先理解成：任何能支持一個敘述、讓別人或未來的自己重新確認「這件事確實怎麼發生」的材料。 它可能是早期草稿、Git commit、測試紀錄、版本比較、老師回饋、失敗照片、會議決策，甚至是一段當時留下的簡短註記。重點不是形式，而是它能不能回答某個問題。

最後成品，只回答了一個問題

成品最擅長回答的是：「最後做出了什麼？」這當然重要，但一個專案通常還有更多值得看的問題。你原本想解決什麼？第一版哪裡失敗？誰提出修改？你試過哪些方法？哪些部分是你做的？什麼時候改變方向？如果只留下最終版本，這些資訊幾乎都不會自己留在成品裡。

這也是為什麼一份漂亮的成果頁不一定比三張普通的過程圖更有資訊量。完成畫面可以展示品質；一張標出錯誤的測試截圖、一段修改前後的版本差異，反而可能更能證明問題如何被發現與解決。兩者不是互相取代，而是在回答不同的問題。

證據真正有用，是因為它能對上敘述

「我負責改善網站效能」本身只是一句話。如果旁邊有修改前後的 Lighthouse 結果、某次壓縮圖片的 commit、載入時間變化，這句話才開始有可以追查的支點。「我們討論後決定改題目」也是一樣；如果保留了初版企劃、老師回饋與修正版，就能看見決策不是事後補出來的故事。

所以保存證據時，不需要問「我今天要存幾張照片」，而應該問：「未來如果我要解釋這件事，我需要什麼才能證明？」這個問題會直接改變你留下來的東西。程式專案可能需要 commit、issue、測試結果；研究可能需要原始數據、實驗條件與失敗紀錄；活動企劃可能需要初稿、預算變更、工作分配與現場照片。證據永遠跟你想支持的敘述有關。

過程證據不是要把每一步都存下來

另一個極端，是什麼都留。每次存檔都截圖、每個聊天訊息都備份、資料夾最後堆出幾百個幾乎一樣的檔案。這並不會自動讓紀錄變好，因為真正需要的是有辨識力的節點：第一次定義問題、重大失敗、方向改變、重要回饋、關鍵版本、最終結果。證據密度比證據數量更重要。

最實用的方式通常很簡單：事情發生時先保留原始材料，再加一句最短的上下文。例如「v2：把登入從前端判斷改到 server-side，因為原方案可以被繞過」。這句話幾個月後的價值，往往比一段事後寫出的長篇心得更高，因為它保留的是當時的決策脈絡。

版本本身，就是一種證據

很多學習其實藏在差異裡。第一版和第三版如果長得完全不一樣，真正值得看的不是「第三版比較漂亮」，而是中間為什麼變。保留版本，才能比較假設怎麼改、問題怎麼被修、判斷標準怎麼成熟。對程式來說 Git 天生就在做這件事；對文件、設計、影片或研究，也可以用明確版本名稱、日期或變更紀錄留下同樣的軌跡。

這也是「可比較」很重要的原因。沒有舊版本，就很難證明進步；沒有修改前的數據，就很難說明改善；沒有第一次的錯誤，就很難知道後面的做法到底解決了什麼。證據讓成長不只剩一句「我學到很多」。

回饋也要留下，但不是拿來裝飾

老師說「這裡看不懂」、使用者說「這個按鈕找不到」、隊友說「流程太複雜」，這些都可以成為證據，但真正有價值的是它們和後續行動的連結。如果一條回饋最後什麼都沒有改，它仍然可以被保留，只是要說明你為什麼沒有採用；如果真的改了，就最好能看到修改前後的差異。回饋不是勳章，而是一個決策輸入。

到了作品集或學習歷程，才開始做選擇

平常的專案紀錄應該盡量接近事實發生的樣子；真正要整理給別人看時，才依目的選擇證據。這跟上一篇談的成果紀錄、作品集與學習歷程是同一條邏輯：原始材料先存在，之後才有東西可以挑。如果一開始只保存「看起來適合申請」的畫面，很多真實的轉折反而會被刪掉。

ColleGo! 對課程學習成果的建議也反覆提到學習過程、方法、收穫與反思；portfolio 的做法則常要求挑選能支持學習敘事的 artifacts。兩邊其實指向同一件事：材料本身不是目的，它要能讓讀者看見你宣稱的那段學習是怎麼發生的。

什麼才算值得留下的證據？

可以用一個很簡單的判斷：如果刪掉這份材料，未來會不會少掉一個重要事實？能證明「做過」、能說明「為什麼改」、能比較「改之前和之後」、能界定「誰負責什麼」、能保存「當時的數據或回饋」，通常都值得留。反過來說，如果十張照片只重複證明同一件事，就沒有必要全部進最終作品。

專案結束之後，人最容易留下的是結論，最容易忘掉的是中間。證據的價值，就是把那些原本會被時間磨掉的部分固定下來。它不會讓一個普通專案突然變厲害，但會讓真正發生過的工作不必靠你幾個月後重新發明一次。