成長紀錄技能 是做什麼的？
問題所在： 多數人以「修復了 X 中的一個 bug」作為學習紀錄。這是一篇日記，而不是學習產物。真正的成長紀錄應萃取模式，以便你下次能辨識出來。
此技能教導： 如何撰寫能跨工作階段累積的學習條目。適用於任何筆記系統——Markdown 檔案、Notion、Obsidian、純文字。範本為通用格式；請根據自己的設定調整。
何時啟動
- 完成複雜任務後（包含多個檔案、新功能、架構變更）
- 遭遇失敗、犯錯，或覺得「這比預期困難」之後
- 想要回顧一段時間以來的學習成果時
何時不啟動： 瑣碎的變更（修正拼字錯誤、單行程式碼調整、無需除錯的設定值變更）。門檻是：這個任務是否涉及除錯、重做、回退，或非顯而易見的決策？ 如果是 → 撰寫條目。如果不是 → 跳過。
三項規則
規則 1：失敗重於成就
失敗在營養密度上勝過成功。一個花 2 小時才找到的 bug，其教訓比三個一次就成功的功能還要豐富。
不佳：「成功實作登入流程。」
良好（網頁開發）：「登入流程：工作階段權杖沒有持久化，因為 Chrome 128+ 中 cookie 的 SameSite 預設為 Lax。模式：當涉及跨源時，務必明確設定 SameSite=None; Secure。可辨識訊號：瀏覽器升級或跨越來源邊界時，驗證失效。」
良好（資料管線）：「CSV 匯入在空白列上無聲失敗，因為 pandas.read_csv(dropna=False) 保留了零寬度列，而 len() 將其視為有效。模式：在進行列數驗證前，務必執行 df.dropna(how='all', inplace=True)。」
規則 2：伯樂原則
在撰寫新條目前，先問：「這與我曾經紀錄過的內容，在本質上是否相同？」
相同根本原因、不同症狀 → 合併，不要重複。新的根本原因 → 建立新條目。
如何檢查： 在撰寫前，使用根源中的關鍵字搜尋現有條目。如果找到相符項，請將新症狀作為額外範例加入現有條目，而非建立重複項。
範例：「忘記在建立檔案後更新輸出索引」和「忘記在工作後更新技能評分」—— 相同的根本原因（缺乏自動化觸發）。合併為一條關於「工作後捕捉缺口」的條目。
規則 3：必須可轉移
每個條目都必須回答：「下次面對類似情況時，我要做什麼不一樣的事？」
如果你無法寫出這句話，代表你還沒萃取出模式。
如何從具體事件中萃取模式：
- 用一句話描述發生的事情
- 反覆問「為什麼？」直到觸及根本原因（通常需要 3–5 次）
- 概括：這是哪一類問題？（不是「Chrome 128 bug」而是「瀏覽器預設值變更破壞既有行為」）
- 表述為：「下次我看到[訊號]，我將會[行動]。」
- 命名訊號：哪個具體的可觀察現象告訴你這個模式正在發生？
條目範本
範圍： 每個獨立的根本原因一條條目。典型長度：4–8 句話。如果寫超過 2 分鐘，你就是在敘述事件。如果少於 30 秒，你挖掘得不夠深入。
## [標題：模式，而非事件]
### 背景
- 我當時想做什麼？
- 哪裡出了問題 / 出乎意料順利的是什麼？
### 根本原因 / 核心見解
- 底層機制，而非單純的症狀
### 模式（可轉移）
- 下次[類似情境]，我將會[具體行動]。
- 可辨識訊號：[哪個可觀察的現象告訴我這個模式正在發生？]
### 相關
- [條目名稱](../路徑/至/相關條目.md)
條目類型
所有四種類型都使用上述範本。類型決定了哪些章節比重最大：
| 類型 | 何時使用 | 重點 | 範例標題 |
|---|---|---|---|
| 失敗 | 有東西壞了、需要除錯，或需要重做時 | 根本原因 | 「設定繼承 ≠ 跨工作階段的行為繼承」 |
| 方法論 | 從工作中浮現出可重複的流程時 | 背景 / 模式 | 「PPT → 開書考試學習指南：三層結構」 |
| 模式發現 | 對工具、系統或思維方式有可重複使用的見解時 | 模式章節 | 「PR 描述範本：描述差距，而非功能」 |
| 能力變化 | 有可衡量的技能提升時 | 背景（前後對比） | 「Git：從 clone/push 到包含 12 次 commit 的獨立 PR」 |
品質檢查清單
完成成長紀錄條目前：
- 標題是否命名了模式，而非事件？
- 是否有「下次我會...」的句子？
- 「可辨識訊號」是否具體到足以在下次觸發該模式？
- 我在撰寫前是否搜尋過現有條目以檢查重複？（伯樂原則）
- 根本原因是否與症狀區分開來？
- 相關記憶是否有交叉連結？
- 條目是否為 4–8 句話？太短 = 過於淺薄；太長 = 在敘述事件。
反模式
- 避免：「修復了付款模組中的 bug」（事件，不是模式）
- 避免：逐字複製 git commit 訊息（commit 描述改變了什麼；紀錄提取為什麼它重要）
- 避免：為每個 commit 撰寫條目（僅在模式浮現時才寫）
- 避免：跳過可轉移的句子（沒有它，就只是日記——這是不可協商的）
- 避免：在不同的標題下重複相同的模式（違反伯樂原則——撰寫前先搜尋）
儲存
將條目存放在你慣用的筆記位置。常見模式：
growth-log/目錄下的 Markdown 檔案（每天一個檔案：YYYY-MM-DD.md）- Notion、Obsidian 或你筆記應用程式的專區
- 使用一致命名慣例的純文字檔案
選擇一種慣例並堅持使用。可搜尋性比格式更重要。
如果你使用交付閘門
delivery-gate 停止鉤子透過檔案系統時間戳記檢查學習檔案今日是否已被修改。此技能教導要寫什麼——這樣交付閘門檢查的檔案才會包含有用的模式，而非空的時間戳記。
任務完成 → 交付閘門檢查：學習檔案今日是否被觸及？
→ 過時（無檔案被修改）：阻止 —「你學到了什麼？」
→ 新鮮（檔案被觸及）：通過 — 此技能確保內容有用
僅有強制執行而無方法論 → 空條目。僅有方法論而無強制執行 → 被遺忘的捕捉。兩者各自獨立有用；結合起來則形成一個完整的循環。