10 從檢索到編纂｜讓知識庫自己長大

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

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

💡 本篇重點
你只負責把材料丟進 Inbox，AI 負責讀取、寫成結構化筆記、補上連結、更新主題地圖；整理由 AI 完成，你把時間放在審查與判斷。

先看一個熟悉的場景：Inbox 裡堆著三週前存的判決、上個月研討會的講義、幾則隨手筆記，而經驗告訴你，它們多半不會再被打開。本篇要處理的就是這件事——把整理交出去。

一、編纂工作流：只有三步

前幾篇講過「檢索 vs 編纂」的典範轉移，一句話複習：檢索是資料存起來、要用時自己翻找；編纂是資料丟進去，AI 把它寫進一本有結構、有交叉連結、持續成長的法律百科全書。本篇是編纂的完整操作版，工作流全貌只有三步：

1
2
3
4
5
你：丟材料進 00_INBOX（判決、文章、開庭心得、隨手筆記）
        ↓
AI：編纂（讀取 → 結構化 → 連結 → 更新 MOC → 清空 Inbox）
        ↓
你：審查與修訂（法律判斷永遠是你的）

二、核心提示詞：Inbox 編纂

這是整套系統最常用的一段提示詞，建議存進 90_SYSTEM/Prompts/，每天（或每幾天）對 Claude Code 執行一次：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
請執行 Inbox 編纂：

1. 讀取 00_INBOX 內的所有檔案。
2. 逐一判斷類型並處理：
   - 判決全文 → 套用判決筆記範本改寫成結構化筆記
     （字號、法院、案由、事實摘要、爭點、法院見解、評析留白給我填），
     檔名用完整判決字號，存入 30_RESOURCES/判決/
   - 文章或文獻 → 寫成文獻筆記（書目資訊、核心論點、與現有筆記的關係），
     存入 30_RESOURCES/文獻/
   - 我的隨手筆記 → 判斷所屬主題，整併入 20_AREAS 對應的爭點筆記；
     沒有對應筆記就新建一則
3. 所有新筆記中提到的判決、法條、爭點，若 Vault 已有對應筆記，
   加上 [[wikilink]]；沒有的也先放上連結（未建立內容的連結會以較淡顏色顯示，留待未來補寫）。
4. 更新受影響領域的 MOC 主題地圖。
5. 處理完的原始檔移入 00_INBOX/done/。
6. 最後報告：處理了幾份、新增哪些筆記、更新了哪些 MOC、
   有哪些內容你不確定需要我人工確認；
   並將本次報告附記一則到 90_SYSTEM/編纂日誌.md（日期＋摘要）。

執行一次之後你會看到：Inbox 清空了、判決變成了格式一致的筆記、爭點筆記多了新的實務見解、MOC 加了新的條目、筆記之間的連結網又密了一層。而你做的，只有把東西丟進資料夾。

第 6 步的編纂日誌，讓 AI 每次編纂都在 90_SYSTEM/編纂日誌.md 留下一則帶日期的紀錄，作用有二——防重複（AI 開工前可以先翻日誌，確認哪些材料已處理過，避免重複匯入）與稽核：跟要求助理留工作紀錄是同一個道理，你隨時可以回頭檢視 AI 哪一天動了哪些筆記，發現問題也追得回去。

三、編纂的進階應用

應用一：見解衝突偵測

法律研究最有價值、也最花時間的工作之一——找出實務見解的分歧：

1
2
3
4
5
請讀取 20_AREAS/營建工程/ 底下所有與「工期展延」相關的判決筆記，
比對各判決對「工期展延是否以依契約約定程序申請並經定作人核准為必要」的立場，
如果發現見解分歧，在「工期展延的可歸責事由」筆記中
新增「⚠️ 實務見解分歧」段落，分列兩說、各自引用判決（wikilink），
並註明每則判決的年度，讓我看得出見解的時間演變。

應用二：週期性的知識庫健檢

1
2
3
4
5
請對整個 Vault 做健康檢查：
1. 找出所有「孤島筆記」（沒有任何連結進出的筆記），建議它們該連到哪裡；
2. 找出 MOC 中尚未建立內容的連結，列成「待研究清單」；
3. 找出內容重複或高度相似的筆記，建議合併方案（先不要動手，列給我看）；
4. 檢查判決筆記是否都符合範本格式，不符合的列出清單。

應用三：跨筆記的主題綜整

當你要寫文章、準備演講或研究新案件時：

1
2
3
4
我下個月要以「工程遲延與違約金酌減的實務發展」為題演講。
請綜整 Vault 中所有相關筆記，產出一份演講大綱筆記：
按爭點分節，每一節列出可引用的判決（wikilink）與我過去寫下的評析，
最後加一節「知識庫目前的缺口」，告訴我哪些子題的材料還不夠。

注意最後一句——讓 AI 告訴你「知識庫還缺什麼」，這是編纂系統獨有的能力：它能盤點全庫筆記，指出材料不足的缺口。

四、關鍵原則：編纂歸 AI，判斷歸你

編纂系統有一條不能妥協的分工線：

AI 做的（形式與整理） 你做的（實質與判斷）
摘要、結構化、格式統一 「這則判決重不重要」的評價
建立與維護連結、更新 MOC 評析欄的法律見解
發現見解分歧、指出知識缺口 分歧中哪一說有理、缺口值不值得補
引用的搬運與標註 引用的查證（永遠是人）

這條分工線的背後有一個原則：編纂系統替你省下的是「整理時間」，省不掉的是「閱讀與理解」。 正確的用法是讓 AI 的整理幫你決定哪些值得精讀，再把省下來的整理時間投資到精讀本身。完整的論證見 實戰｜打造判決知識庫：從裁判書到 WIKI 索引。

三個落實方法：

1. 範本裡設「評析留白」。 判決筆記範本的「評析」欄位讓 AI 留白（或只寫「（待評析）」），強迫自己每則重要判決都親手寫兩行。這兩行是整則筆記最值錢的部分，也是防止「認知外包」的護欄。

2. 引用一律標註待核。 CLAUDE.md 裡已寫入的規則：AI 產出的法條與判決引用一律標「（待核對）」。你核對過後把標註拿掉——筆記裡沒有這個標註的引用，就代表經過你親手查證。 這讓知識庫的可信度有了明確的內部標準。若已設定法規資料庫 MCP（見 MCP｜把 AI 接上法規資料庫），可讓 AI 先做第一輪核對，但最終責任仍在人。

3. 交件前，先讓 AI 自校一輪。 事務所的規矩是「文件送核前先自己校對」，對 AI 也一樣。任何批次任務的結尾加一句：

1
2
3
完成後，請對照我最初的指示逐項自我檢查：
每一份都處理了嗎？格式都符合範本嗎？連結都加了嗎？
把檢查結果列表回報，有遺漏就直接補正。

一句話的成本，換到明顯更穩的產出品質——AI 跟助理一樣，「知道要被驗收」時做得比較仔細。你的人工審查則從「逐項檢查」升級為「抽查＋看自檢報告」。

五、長任務的實務眉角：對話容量管理

AI 的對話有容量上限（context window），一次塞進太多判決，會出現回應變慢、忘記前面指示、任務中斷等狀況。初期最常撞到的牆就是這一面，五個對策：

  1. 分批：一次編纂五到十份，勝過一次五十份。批次之間說一句「請繼續處理下一批」即可。
  2. 換場就清空：一個任務結束、要開新任務時，用 /clear 清空對話重新開始——檔案完全不受影響，成果都已寫進筆記，對話本身不需要留戀。對話太長時，也可用 /compact 把前文濃縮後繼續。
  3. 不要把容量用到見底：大約用掉七、八成時，就主動 /compact 或收尾另起對話——由自己決定哪些重點該保留下來，而不是等系統自動壓縮時替你取捨。（想隨時掌握容量水位，見 安裝 Claude Code｜讓 AI 進入你的知識庫 的狀態列小提示。）
  4. 先定案、再動工，兩個對話分開跑：大型任務先用一個對話把做法討論定案，結論寫成計畫筆記存檔；執行時另開新對話，請 AI 依計畫筆記進行。計畫住在檔案裡，執行的對話隨時可以清空重來，也不會被前面的討論佔用容量。
  5. 讓規則住在檔案裡，不要住在對話裡：重要指示寫進 CLAUDE.md 與範本，而不是在對話中反覆叮嚀——檔案裡的規則每次啟動都在，對話裡的話會隨清空而消失。

（進階關鍵字：處理超大批量時，Claude Code 可派出「子代理（subagent）」平行分工，每個子代理有自己的獨立對話容量。先知道有這個詞，用得到時直接問 AI 怎麼用。）

大工程，先要一份計畫書（Plan Mode）。 會影響大量檔案的任務（重整整個 Vault 的資料夾、批次改寫上百則筆記），不要讓 AI 直接動手。Claude Code 有「計畫模式」（按 Shift+Tab 切換）：AI 會先通盤研究、提出完整的執行計畫給你核可，核可前不會更動任何檔案。這跟你帶助理辦大案的習慣一模一樣——先交辦案計畫，主辦律師核過才動卷。計畫哪裡不妥，直接用中文修改它，改到滿意再放行。

六、養成節奏：每天三十秒，每週十分鐘

編纂系統的成敗不在技術，在節奏。建議的最低維運成本：

  • 隨時（3 秒）：遇到任何有價值的材料，丟進 00_INBOX。不整理、不分類、不猶豫。
  • 每天或隔天（30 秒）：對 Claude Code 說「請執行 Inbox 編纂」，看一眼它的報告。
  • 每週（10 分鐘）：翻一下本週新增的筆記，補寫評析、核對引用、順手調整。
  • 每月（10 分鐘）：跑一次知識庫健檢，看看待研究清單。

💡 網頁文章的 3 秒入庫：Obsidian Web Clipper
「隨時丟材料」在瀏覽器裡也有專屬工具：Obsidian 官方的免費瀏覽器擴充功能 Web Clipper（Chrome、Edge、Firefox、Safari 都支援），可以把正在閱讀的網頁一鍵擷取成 Markdown 筆記、直接存進 Vault 指定的資料夾（設成 00_INBOX 正好）。主管機關新聞稿、函釋公告、學者專欄、法律新聞——看到就按一下，剩下的交給下一次 Inbox 編纂。裁判書則用 安裝 Claude Code｜讓 AI 進入你的知識庫 介紹過的「司法院裁判書閱讀助手」，兩個擴充功能正好分工。

過去知識管理難以持續的主因是「整理太花時間」；把整理交給 AI 後，維運成本降到這個程度，系統才可能長期持續，逐步累積成你自己的專業資產。

小結

  • 編纂工作流：你丟材料 → AI 結構化並連結 → 你審查判斷。
  • 四大招式：Inbox 編纂、見解衝突偵測、知識庫健檢、主題綜整。
  • 分工鐵律：形式歸 AI，判斷歸你；評析親手寫，引用親手查，重要材料親自精讀——AI 省下整理時間，省不掉閱讀時間。
  • 下一篇進入實戰：把這套系統用在最日常的場景——判決研究。

參考資料

⬅️ 上一篇：案件檔案實務｜底稿區與定稿區
➡️ 下一篇：實戰｜打造判決知識庫：從裁判書到 WIKI 索引
🏠 回到 總覽｜AI x Obsidian 律師實戰系列