11 實戰｜打造判決知識庫：從裁判書到 WIKI 索引

發表於 更新於 分類於 閱讀次數：

作者｜有澤法律事務所 林廷翰律師

💡 本篇重點
裁判書存成 .md 丟進 Vault → AI 在每份開頭插入三色摘要區塊 → AI 編出索引頁與爭點 WIKI。之後查判決，先翻自己整理過的索引與 WIKI，再回全文查證。

判決研究有兩個日常困境：裁判書動輒數十頁，每份都精讀不現實，只看主文又抓不到論理；而且同一個爭點，隔了半年往往又是一次從零開始的檢索。本篇是整個知識管理主線的核心實戰，完整走一遍「判決知識庫」的建置流程。這條流程訴訟律師感受最直接，但非訟律師與企業法務同樣受用——文末會分別說明兩種視角的用法。

第一步：把裁判書變成 .md 檔

原料來自「司法院裁判書系統」（判決書查詢）。把裁判書變成 Vault 裡的 Markdown 檔，有三種做法：

做法一：複製貼上（零門檻）。 在裁判書頁面全選複製，回 Obsidian 新增筆記貼上，檔名取判決字號。適合偶爾為之。

做法二：瀏覽器擴充功能一鍵下載。 筆者以 Claude Code 自行開發了 Chrome 擴充功能「司法院裁判書閱讀助手」（免費上架於 Chrome 線上應用程式商店，無任何收費或商業利益；GitHub 原始碼公開），可以在裁判書頁面自動解析判決架構、標示參照判決，並一鍵複製判決全文、或將整份裁判書下載成 .md 檔。下載下來直接就是 Obsidian 能用的格式，批次研究判決時效率差距可觀，提供讀者參考。

做法三：交給 AI 轉檔。 手上是 PDF 或 Word 的裁判書（例如當事人提供的卷內判決），直接丟進 00_INBOX，讓 Claude Code 轉成 md（本機轉檔工具如 markitdown 可全程不外傳資料）。

做法四：讓 AI 直接檢索（MCP）。 前三種做法都是「人先找到判決、再入庫」；裝好 MCP｜把 AI 接上法規資料庫 介紹的 taiwan-legal-db 之後，還有第四種——連檢索本身也交辦出去：

1
2
3
請用裁判書系統檢索與「工期展延 違約金酌減」相關的近三年判決，
列出：字號｜法院｜一句話爭點，供我挑選；
我勾選後，將全文下載存入 30_RESOURCES/判決/，檔名用判決字號。

這條路的界線要先劃清：AI 初篩、律師複選。 檢索詞抓得全不全、哪幾則值得入庫，是判斷，不隨檢索一起外包——AI 列出的是候選名單，不是研究結論；重要爭點宜再用自己的檢索詞補一輪，確認沒有漏網。

下載下來的判決，統一放進 30_RESOURCES/判決/，或先丟 00_INBOX 等待編纂。

第二步：AI 產生三色摘要（Skill 實戰）

開頭說的第一個困境——精讀不現實、只看主文不夠——解法是讓 AI 在每份裁判書的最開頭插入三個 Obsidian callout 色塊：

  • 🟩 [!tip] 重點摘要——把案件講成一個完整的故事：當事人身分、關鍵行為、時間點與金額、最終判決結果，關鍵事實加上螢光標記。讀完能向同事三句話講清楚這個案子。
  • 🟨 [!question] 爭點整理——本案法律上真正在吵什麼，每個爭點一句話標題＋具體爭執內容，通常二至五個。
  • 🟦 [!note] 法院見解——法院對各爭點的結論與論理，與爭點一一對應；最高法院判決並說明維持或推翻下級審的哪些認定。

三色區塊之後以 --- 分隔，裁判全文原封不動接在後面——摘要是導覽，不是替代，全文永遠都在。

三色摘要的任務，是幫你在一批判決中快速分辨「哪幾份值得精讀」，而不是讓你從此不必讀判決。對案件成敗有影響的關鍵判決，一定要親自讀全文——法院論理的轉折、事實認定的細節、可供攻擊的縫隙，這些只有精讀才看得見，而它們正是書狀功力的來源。讓 AI 摘要一百份判決是效率；靠摘要「理解」判決、從此不碰全文，則是把律師最核心的功夫外包出去。AI 可以替你整理，理解永遠要靠你自己的閱讀。

這套固定格式怎麼讓 AI 每次穩定產出？答案是把它寫成一個 Skill（技能）——以實際運作中的 judgment-summary 技能為例，它就是一份教 AI「怎麼整理裁判書」的 SOP 文件，內含格式模板與撰寫原則（不杜撰、數字照抄、不更動全文、台灣法律用語）。裝好之後，操作只剩一句話：

1
幫我整理 00_INBOX 裡這三份判決

AI 讀到「整理判決」就自動套用這個技能，三份裁判書開頭各自長出三色摘要。Skill 的原理與自製方法，是 Skills｜把你的 SOP 變成 AI 的技能 的主題，該篇會帶你逐步做出自己的版本。

⚠️ 注意
一樣的原則：AI 摘要中的判決要旨與引用法條，採用前一律人工核對（或先讓法規資料庫 MCP 做第一輪核對，見 MCP｜把 AI 接上法規資料庫）。摘要幫你「快速掌握」，查證責任永遠在人。

第三步：AI 編出 INDEX 與爭點 WIKI

判決筆記累積到十份以上，就值得讓 AI 建立兩層導覽結構。

3-1 判決索引頁（INDEX）

1
2
3
4
5
請掃描 30_RESOURCES/判決/ 內所有判決筆記，建立「判決索引.md」：
1. 以表格呈現：判決字號（wikilink）｜法院｜裁判日期｜案由｜一句話爭點；
2. 按法領域分節（勞動、個資、公司……），同領域內按裁判日期新到舊排序；
3. 之後每次新增判決筆記，都要同步更新這份索引。
   （這條規則請同時寫進 CLAUDE.md）

3-2 爭點 WIKI 頁

索引解決「找判決」，WIKI 解決「找答案」。讓 AI 以爭點為單位，把散落各判決的見解編纂成百科條目：

1
2
3
4
5
6
請讀取所有涉及「工期展延」的判決筆記，建立或更新爭點 WIKI 頁
「工期展延的可歸責事由.md」：
1. 段落：爭點說明／實務見解整理／見解分歧（如有，分列各說並附判決）
   ／時間演變／相關法條／待研究問題；
2. 每個論點都必須以 [[判決字號]] 連結到出處筆記；
3. 完成後把這一頁掛上「營建工程 MOC」。

做完之後，你的檢索路徑變成：MOC（領域地圖）→ 爭點 WIKI（答案在這）→ 判決筆記（三色摘要）→ 裁判全文（終極查證），四層每一層都互相連結。等 2026-015 案（甲公司對定作人乙公司的工程款訴訟）打到「變更設計、追加工項應否展延工期」這個爭點時，答案已經寫好在 WIKI 頁，而且每一句都點得回出處。

第四步：檢索與引用（收穫期）

日常使用場景：

寫書狀時調閱：

1
2
3
4
我正在寫 2026-015 案的上訴理由狀。一審認定甲公司遲延完工、應依約給付違約金，
我方（甲公司）主張乙公司變更設計、追加工項，依約工期應予展延，展延後如期完工、並無遲延。
請從判決知識庫找出所有支持這個立場的判決，
按法院層級排序，各附一段可引用的法院見解原文與出處字號。

開會前十分鐘惡補：在 Obsidian 打開爭點 WIKI 頁，三分鐘掌握全部實務見解——因為那是你過去半年編纂出來的。

發現新判決時：丟進 Inbox，一句「整理並更新索引與相關 WIKI」，知識庫自動長大。

兩種視角的用法差異

訴訟律師：如上主流程。加碼建議——為進行中的案件建立「本案判決庫」子資料夾，把對造引用的判決也丟進去做三色摘要，讓 AI 比對「對造引用的判決與我方立場的判決，事實基礎有何不同」，攻擊防禦的素材就出來了。

非訟律師／企業法務：把「判決」換成你的日常原料，整套流程原樣可用——

  • 契約審閱：建「條款知識庫」。每次審約遇到的特殊條款與處理方式，存成條款筆記；相關判決（例如違約金酌減、定型化條款效力）掛在條款頁下。下次審到同類條款，WIKI 頁就是你的 checklist。
  • 法律意見：建「議題知識庫」。每份意見書研究過的法規、函釋、判決，萃取成議題 WIKI；主管機關函釋也用同一套三色摘要邏輯處理（重點／爭點／機關立場）。
  • 教育訓練：知識庫直接變教材產線——「請根據個資法 MOC 及其下所有筆記，產出一份對客戶人資部門的教育訓練大綱，附實務案例」。

小結

  • 四步流程：取得 md（擴充功能一鍵下載，或交給 MCP 檢索）→ 三色摘要（Skill）→ 索引與爭點 WIKI（編纂）→ 檢索引用（收穫）。
  • 檢索路徑四層：MOC → 爭點 WIKI → 判決摘要 → 全文。
  • 訴訟用判決、非訟用條款與議題，方法完全同構。
  • 下一篇把鏡頭拉到日常：訴訟與非訟的每日工作流。

⬅️ 上一篇：從檢索到編纂｜讓知識庫自己長大
➡️ 下一篇：實戰｜訴訟與非訟的日常工作流
🏠 回到 總覽｜AI x Obsidian 律師實戰系列