Methodology

"Methodology"

2026-05-14 4.13 Eval 設計座標系：三軸、八象限、何時測什麼 Eval 設計三軸（objective↔subjective / component↔end-to-end / quantitative↔qualitative）、八象限的對應 eval 工具、軸選錯的訊號、跟 benchmarking / LLM-as-judge / tracing 的關係
2026-05-18 Background Agent 平行研究：main context 節省的量化效應用 background agent 平行做同類研究任務、主 context 只收 finding summary、節省 ~80% context 用量的工作方法
2026-04-26 Methodology 的 multi-pass 該升級為 pillar 層：核心結構才會被執行任何「教做事方法」的 methodology / SKILL / playbook、應該把 multi-pass refinement 放在 pillar / 核心原則層、不是放在末尾「附帶提醒」段。Pillar 層 = 結構性必跑、appendix 層 = 看心情選擇 = 永遠不跑。本卡是 #82 行為驗證 + #72 結構性對策在「方法論設計本身」這一層的展現。
2026-06-26 Compositional Writing Composes atomic, intent-revealing, grep-friendly writing (Zettelkasten) for code comments, docs, log
2026-05-13 Case-First + Agent Team Review：教學內容的生產流程 Case-first + agent team review 的教學內容生產流程：讀案例庫抽 findings、專責 reviewer 平行審查、polish pass 收系統性殘留。防止通用 best practice 被誤包裝成案例揭露。
2026-05-05 Commit message vs source code doc：兩份不同職責的文件 Source code doc 寫給未來讀者、commit message 寫給回顧歷史的考古者。時序敏感的資訊（為什麼這次改、考慮過什麼方案）放 commit、持續適用的契約放 source。配合 git blame 工作流讓考古路徑清楚、source 不必背所有歷史。
2026-05-05 函式文件分層設計：型別、介面、實作各自該寫什麼函式文件分層設計：把資訊放在能表達它的最低層次（名稱 / 型別簽章 / 介面 doc / 實作 doc / 範例與測試）、上層留給「下層表達不了的剩餘」。整理各層該寫什麼、容易誤入的內容、配合反模式列表跟寫 doc 前 checklist 收斂出短而精準的文件。
2026-05-05 型別取代 doc 的收益曲線：強型別語言的 doc 該有多短型別系統強化等於 doc 表達力轉移——很多 doc 內容應該下移到型別。整理 null safety / enum / wrapper / Result / typestate 各能消除哪類 doc、型別表達不了的剩餘部分（業務動機、性能、副作用、時序）以及收益曲線的邊際遞減點。
2026-05-05 設計瑕疵還是避免過度設計？YAGNI 的真實適用條件 YAGNI 不是「永遠選最受限選項」、是「不為未來投入額外成本」的原則。用成本對稱性、可逆性、領域先驗三軸框架釐清「該選通用 default」與「該避免過度設計」的邊界、並補上 review checklist、架構規範、領域先驗清單三層制度補強。
2026-05-05 測試命名作為文件：可執行的規格說明測試是少數會自我驗證的文件——名稱跟實際行為不符、CI 會炸。把測試命名寫成 state-based / scenario-based / failure-mode 三種模式的 spec 條目、配合 group 結構作為命名空間、讀者跳到測試檔掃名字就能取代讀 doc。