08 檔案整理方法論｜案件與研究領域的雙軌知識系統

發表於 2026-07-07 更新於 2026-07-11 分類於 AI x Obsidian 系列閱讀次數：

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

💡 本篇重點
律師的專業資訊分兩大塊——「手頭上的案件」與「專精的研究領域」。案件用律師版 PARA（P 改寫成 Matter）管生滅，研究用 Zettelkasten＋MOC 管累積；兩軌在「知識萃取」交會。

一、先想清楚：律師到底在管理什麼

在挑選任何整理方法之前，先把對象看清楚。律師電腦裡的東西，本質上只有兩大類，而且性質完全相反：

	第一塊：手頭上的案件	第二塊：專精的研究領域
例子	承辦中的訴訟、非訟、顧問案；法務手上的專案與合約	勞動法、個資法、公司法……你長期深耕的領域
生命週期	有始有終：委任（分案）→ 進行 → 結案	沒有終點：執業多久，經營多久
組織核心	以「卷宗」為中心，按案件聚合	以「主題／爭點」為中心，按知識聚合
目標	把這件事辦完、辦好	讓理解越疊越深
常見困境	檔案散落、版本混亂、找不到那份筆錄	研究過就忘、每次遇到同類爭點都重新查

整理之所以難以持續，一個關鍵原因是拿同一套邏輯管這兩塊。 只用案件資料夾，研究成果就被埋在個案裡，結案即蒸發；只按主題整理，進行中的案件材料又會散得到處都是。

（嚴格說還有第三塊——執業這門生意本身：請款帳務、行銷、所內制度等。其性質與研究領域相同，走同一軌即可，詳見第六節。）主結構是雙軌：案件一軌、研究一軌，各用適合的方法論，再設計兩軌之間的橋。以下依序介紹三套方法論，以及它們各自負責哪一軌。

二、PARA：整個 Vault 的頂層框架

PARA 是生產力專家 Tiago Forte 在《打造第二大腦》提出的分類法，四個字母代表四種「與行動的距離」。它的關鍵設計是：不按主題分類，按行動性分類。 轉譯成律師的語言：

資料夾	原意	律師的轉譯	對應哪一軌
Matters（案件）※原為 Projects（專案）	有明確完成日的工作	承辦中的案件、要交的文章、下個月的演講	案件軌
Areas（領域）	無終點的長期責任	執業／研究領域、事務所行政、進修學分	研究軌
Resources（資源）	未來可能有用的材料	判決、法規筆記、文獻、講座資料	研究軌的原料
Archives（封存）	不再活躍的東西	已結案件、辦完的演講	案件軌的終點

第一個字母動了手腳：原版 PARA 的 P 是 Projects（專案），本系列把它改寫成 Matters——matter 正是英文法律實務對「一件委任案件」的標準用語，事務所的計費、卷宗編號、利益衝突檢核，都以 matter 為單位。對律師來說，「專案」是別人領域的管理術語，「案件」才是每天掛在嘴邊的工作單位；資料夾名稱與工作語言一致，你和 AI 都少一層翻譯。

分類判準只有一個問題：「這個東西與當前行動的距離多近？」正在辦→Matters；長期經營→Areas；以後可能用→Resources；結束了→Archives。

PARA 給法律工作帶來兩個立即的好處：

「結案」有了明確的家。 案件辦完，整個資料夾從 10_MATTERS 拖進 40_ARCHIVE，工作區永遠只剩「現在進行式」。這跟事務所紙本卷宗歸檔的習慣完全同構，零學習成本。
案件與知識分流。 個案卷證留在案件資料夾（機密、會封存）；研究成果進入 Areas / Resources（去識別化、永久累積）。這正是雙軌的地基。

三、案件軌：卷宗式資料夾＋標準內部結構

案件管理不需要花俏的方法論，需要的是每個案件長得一樣。建議 10_MATTERS 底下固定兩層——先當事人、再案件——每個案件資料夾採用固定的內部結構：

10_MATTERS/
└── 甲公司/                         ← 第一層：當事人
    ├── 00_共通/                    ← 跨案件共用：登記資料、組織架構、聯絡窗口
    └── 2026-015_工程款_甲v乙/       ← 第二層：案件（年度-流水號_案由）
        ├── CLAUDE.md              ← 本案工作規則（見前篇）
        ├── background.md          ← 穩定的案件背景，隨 CLAUDE.md 每次自動載入（見前篇）
        ├── 00_案件總覽.md          ← 本案的儀表板：動態狀態，需要時查閱（見下）
        ├── 01_請款資料/            ← 委任契約、報價函、待審閱工時、工時定稿版
        ├── 02_我方書狀/            ← 我方書狀歷次版本（草稿與定稿）
        ├── 03_對造書狀/            ← 對造書狀及其證物
        ├── 04_法院文書/            ← 開庭通知、裁定、判決
        ├── 05_電子筆錄/
        ├── 06_當事人提供資料/       ← 客戶交付的契約、往來文件、事證
        ├── 07_會議紀錄/            ← 會議、電話、LINE 溝通紀錄（見第七節）
        ├── 08_開庭報告/            ← 開庭筆記與庭後報告
        └── 09_法律研究/            ← 為本案做的法律研究（知識萃取的原料，見第五節）

幾個設計重點：

第一層先分當事人，再分案件。 一個當事人往往不只一件委任——訴訟進行中、常年顧問跑著、新案還在報價。若把案件直接攤在 10_MATTERS 底下，同一當事人的資料會散成好幾處；以當事人聚合，回顧委任歷史、檢索過往成果、進行利益衝突檢核，都在同一個地方。三條原則：

每個當事人只有一個資料夾，名稱用固定基準，不要一下全名、一下簡稱。
當事人資料夾底下只放案件，不散放檔案；唯一例外是跨案件共用的資料（公司登記、組織架構、聯絡窗口），收進 00_共通/。
演講、投稿這類「有完成日但沒有當事人」的工作，用一個 _內部 資料夾當虛擬當事人收攏。

檔名編號採 Johnny.Decimal 精神。 Johnny.Decimal 是另一套知名整理方法論，核心主張是「用固定的兩位數編號給資料夾排序，位置永遠可預期」。不必全套採用，只取其精髓：固定的兩位數編號讓每個案件資料夾順序永遠相同，你（和 AI）進到任何一個案件都不用重新適應。對 AI 尤其重要——結構可預期，AI 才能寫出可重複使用的工作流。

這套結構的來歷與調整空間。 01–08 的檔案層整合自實際運作中的事務所卷宗習慣——按文件的來源與類型分（我方／對造／法院／當事人；筆錄、會議、開庭報告），與紙本卷宗的分類直覺一致；CLAUDE.md、background.md、00_案件總覽.md 與 09_法律研究/ 則是為 AI 協作與知識萃取補上的知識層——傳統卷宗沒有這幾件，但它們正是這套系統長期累積價值的地方。

這套結構建在哪裡？ 分兩種情況：事務所有共用的案件文件庫（SharePoint、共用雲端硬碟）的，檔案層 01–08 建議建在案件文件庫——文件庫是全所共用的定稿區，結構統一的效益在那裡最大；個人這側的案件資料夾放知識層與自己的工作底稿，再掛一個文件庫捷徑把兩區並排（設定方式見下一篇）。沒有共用環境的，整套建在自己的案件資料夾即可——上圖畫的就是這種形態。

顆粒度可依所內習慣與案件規模增減（小案可以合併幾個資料夾、大案可以在 01 底下再分工時與委任），鐵則只有兩條：

全所每個案件長得一樣——這比結構本身細不細重要得多。「一樣」指的是基本骨架與編號邏輯；依案件性質與個案複雜度，仍可以在這個基礎上增加或縮減資料夾（非訟案未必需要書狀與筆錄夾、大型工程案可能要為鑑定資料另立一資料夾），但編號與語意不變，你和 AI 到任何案件都找得到路。
把各資料夾的語意寫進知識庫層的 CLAUDE.md（「對造書狀進 03、開完庭的報告寫進 08」——全所案件結構相同，所以寫在 Vault 根目錄那份即可），AI 讀過一次，之後歸檔、檢索、生成開庭準備包都會走對地方。

00_案件總覽.md 是每個案件的儀表板，也是 AI 協作時最有價值的一份檔案：

# 案件總覽：2026-015 工程款案

## 基本資料
案號｜法院｜當事人｜委任日期｜受命法官／檢察官

## 目前狀態
下次開庭：2026-08-12（言詞辯論）
待辦：證人詰問問題清單（8/1 前）

## 時間軸
- 2026-05-02 收受起訴狀
- 2026-06-10 第一次庭期，爭點整理

## 爭點清單
1. 工期應否展延、甲公司有無遲延完工（變更設計、追加工項）→ [[09_法律研究/工期展延可歸責事由研究]]
2. 遲延違約金是否過高、應否酌減 → [[09_法律研究/違約金酌減基準研究]]

## 卷證索引
- 原證1：工程承攬契約 → 02_我方書狀/原證01_工程承攬契約.pdf

有了這份總覽，你對 AI 說「幫我為下次開庭準備爭點整理狀草稿」時，它先讀總覽就掌握全案脈絡。開完庭丟一份筆記進 08_開庭報告，再說一句「請更新案件總覽的時間軸與待辦」，儀表板隨時保持在最新狀態。

前篇介紹過的 background.md（見 CLAUDE.md｜寫給 AI 助理的到職須知第三節）乍看也在「描述這個案件」，兩者用途其實不同，界線要劃清楚：

	`background.md`	`00_案件總覽.md`
定位	給 AI 的開場背景（設定檔）	案件儀表板（狀態檔）
內容	穩定的部分：當事人與代理立場、案情梗概、核心爭點框架、本案用語慣例	變動的部分：下次庭期、待辦、時間軸、卷證索引、爭點研究連結
讀取方式	隨 CLAUDE.md 每次啟動自動載入	需要時才讀——你打開案件先看它，AI 做開庭準備包時第一步讀它
更新頻率	低：案件有實質變動才改（追加聲明、和解方向改變）	高：每次開庭、每個新事件

判準一句話：半年不會變的寫 background.md，每週在變的寫 00_案件總覽.md。 之所以要分開，是因為自動載入的內容必須小而穩定——把天天長大的儀表板塞進每次啟動的背景，既佔用對話容量，AI 也分不清哪些是「本案是什麼」、哪些是「現在進行到哪」。

兩檔不會造成重複維護，原因有二：

一件事實只有一個家：照上表分工，兩檔內容本來就不重疊；真正重疊的只剩案號、當事人名稱這類一兩行的表頭識別資訊，開案時寫一次，之後不會變。
維護交給 AI 分流：把分流規則寫進案件 CLAUDE.md（前篇的案件 CLAUDE.md 範例第三條就是這一條）。之後你只負責口述發生了什麼——「今天開庭，法官要求兩週內補呈；對造提出新的和解方案」——寫進哪一份、要不要兩份都更新，由 AI 依規則判斷。你維護的從來不是兩份檔案，而是一句話。

💡 案件「檔案」的收納是另一個主題
本篇聚焦「知識」（筆記）的組織；每天湧進的 Word、PDF、卷證等「檔案」怎麼收納、底稿與定稿如何分離（含 SharePoint／Google Workspace 協作環境的文件庫捷徑設定），是下一篇案件檔案實務｜底稿區與定稿區的主題。

⚠️ 注意
案件軌涉及真實卷證與個資，放進 Vault 的範圍、以及允許 AI 讀取的範圍，必須先讀過資安與倫理｜律師使用 AI Agent 的紅線再決定。原則：練習期只放去識別化材料；正式使用時依事務所的資安政策分級。

四、研究軌：Zettelkasten 的「一爭點一筆記」＋MOC 主題地圖

研究領域這一軌，PARA 只給了「放哪裡」（Areas / Resources），沒回答「知識怎麼組織」。這裡要借用第二套方法論：Zettelkasten（卡片盒筆記法）。

Zettelkasten 是德國社會學家 Niklas Luhmann 的工作法，他靠一個索引卡片盒寫出七十多本書。核心原則有三，每一條都對應法律研究的實際需求：

1. 原子化（Atomicity）：一張卡片只寫一個概念。
轉譯成法律版：一個爭點＝一則筆記。與其把整個領域寫成一則「營建工程研究.md」，不如拆成「工期展延的可歸責事由.md」「工程遲延違約金的酌減基準.md」。原子化的筆記才能被精準連結、在不同案件間重複使用。

2. 連結重於分類：卡片的價值在於它連到誰。
法律知識天生是網狀的：一個爭點連到數則判決，一則判決涉及數個法條，一次修法牽動一串實務見解。樹狀資料夾裝不下這種結構，wikilink 才裝得下。實務作法：判決筆記以字號為檔名（引用時自然形成 [[最高法院110年度台上字第XXXX號]]，與律師引註習慣完全一致），爭點筆記內連結所有相關判決、法條與其他爭點。

3. 用自己的話寫。
複製貼上判決全文，只完成了「保存」；筆記真正的價值，在於你寫下的那兩行評析：「本判決與◯◯號採相反見解，關鍵在於……」——這才是十年後仍有用的東西。（全文可以照存，但要求自己在開頭寫摘要與評析。摘要可由 AI 起草；評析是判斷——「本判決與◯◯號採相反見解」這種話必須自己寫，AI 至多把兩則判決的異同點並列出來供你參考。）

MOC（Map of Content，主題地圖）則是研究軌的樓層導覽。 筆記多了之後，每個領域建一頁「目錄筆記」，按爭點體系把重要筆記用 wikilink 串起來。以下以營建工程示範——這正是主案例 2026-015 的領域；實作時代入自己的主力領域即可：

# 營建工程 MOC

## 工期與遲延
- [[工期展延的可歸責事由]]
- [[工程遲延違約金的酌減基準]]

## 契約價金
- [[追加工項之報酬請求]]
- [[物價指數調整條款之適用]]

## 瑕疵與保固
- [[工作物瑕疵之修補請求]]
- [[保固期間與瑕疵擔保期間之區分]]

## 待研究
- 情事變更原則在工程款請求之適用

MOC 就是你這個領域的「個人教科書目錄」，而且會隨筆記成長。維護 MOC 正是最適合交給 AI 的工作——每次新增筆記後說一句「請更新營建工程 MOC」即可，詳見從檢索到編纂｜讓知識庫自己長大。

五、兩軌的交會：知識萃取——複利的關鍵

案件裡的法律研究（09_法律研究/）是你花了幾十個小時產出的高價值知識，但它綁在個案脈絡裡、夾雜當事人資訊。如果隨案封存，這些知識就死了；下次遇到同類爭點，一切重來。

解法是萃取：把個案研究改寫成去識別化的通用知識，存入研究軌。這件事過去做不到，因為太花時間；現在它是一句話的工作，而且有兩個時點：

隨案萃取——寫完就萃。 很多研究其實在辦案過程中就完成了：為一份書狀蒐集判決、分析爭點，書狀交出去的當下，這一輪研究的知識已經成形。趁脈絡還熱的時候順手萃取，品質最好：

1
2
3

準備書狀三已定稿。請把這次就「工期展延的可歸責事由」所做的研究
（09_法律研究 內相關筆記與引用判決），改寫成去識別化的爭點筆記
存入 20_AREAS/營建工程/，並更新營建工程 MOC。

結案總萃取——最後一道保險。 隨案萃取難免有漏，所以結案時再把 09_法律研究/ 整個掃過一遍，確認沒有漏網的知識，然後才封存：

「2026-015 工程款案」已結案。請執行結案萃取：
1. 讀取該案件資料夾中 09_法律研究 的所有筆記；
2. 將具有通用價值的法律分析，改寫成「去識別化」的爭點筆記
   （移除所有當事人名稱、可識別事實，只保留法律論證與判決引用），
   存入 20_AREAS/營建工程/ 對應位置，套用爭點筆記範本；
3. 更新營建工程 MOC；
4. 完成後列出清單給我審查，確認無殘留可識別資訊；
5. 我確認後，將整個案件資料夾移至 40_ARCHIVE。

這個動作重複兩年，效果是複利式的：你辦過的每一個案件，都在讓你的知識庫變厚；知識庫越厚，下一個案件就辦得越快。這就是雙軌系統真正的報酬。

在多人事務所，這個儀式的價值還會放大：萃取出的爭點筆記若進入全所共用的知識庫，資深律師辦過的每一個案件，就成為所有同仁的教材——年輕律師研究新案時，前輩在同類爭點上的分析已經在那裡等著。傳承不再只能依賴口耳相傳與帶案機會（作法詳見 Skills｜把你的 SOP 變成 AI 的技能的傳承一節）。

六、第三塊：事務所經營與行政管理

律師不只辦案與研究，還要經營一間事務所——獨立執業者尤其如此：請款與帳務追蹤、報價紀錄、行銷文章與演講邀約、所內制度與 SOP、進修學分。這一塊在 PARA 裡的答案很乾脆：它們全是「無終點的長期責任」，與研究領域同住 20_AREAS——研究領域是 Areas 的專業面，經營行政是 Areas 的營運面：

20_AREAS/
├── 營建工程/、個資法/……        ← 研究領域（第四節）
├── 所務經營/
│   ├── 客戶與行銷/             ← 文章構想與產線、演講邀約紀錄、潛在委任追蹤
│   ├── 財務請款/               ← 報價紀錄、請款追蹤筆記（各案 01_請款資料 的彙總視角）
│   └── 制度與SOP/              ← 所內流程、範本政策、教育訓練規劃
└── 進修/                       ← 學分紀錄、課程筆記

判準與案件軌相同：有完成日的經營工作（某場演講、某篇投稿、所內某個導入專案）依第三節放進 10_MATTERS/_內部/，辦完移入 Archives；沒有終點的經營責任住在 Areas。兩個實用的 AI 用例：

1
2

請讀取 20_AREAS/所務經營/財務請款/ 的請款追蹤筆記與各案件 01_請款資料 的報價紀錄，
列出：尚未請款的已完成工作、逾期未付款項目，更新請款追蹤筆記。

1
2
3

下個月要交一篇「AI 與個資法」的專欄文章。
請從 20_AREAS/個資法/ 與所務經營/客戶與行銷/文章構想 調出相關素材，
產出文章大綱，標明哪些論點已有筆記支撐、哪些還缺材料。

⚠️ 注意
財務數字與人事資料的機密等級高、且多半已有專門系統（會計軟體、所內 DMS）管理。Vault 裡放的是「筆記層」（追蹤、構想、制度文件），帳務明細與薪資這類敏感原始資料未必要進 Vault——依資安與倫理｜律師使用 AI Agent 的紅線的分級判斷。

七、客戶溝通的收納：會議、通話與 LINE 訊息

案件的真實脈絡，往往不在書狀裡，而在會議、電話與 LINE 對話裡——客戶為什麼改變立場、什麼時候同意了什麼、對造律師在電話裡透露了什麼。這些零散溝通若不落地，兩個月後就誰也說不清。收納規則一句話：

與特定案件有關的溝通紀錄，一律進該案件的 07_會議紀錄/；當下判斷不了歸屬，先丟 00_INBOX，讓 AI 編纂時歸位。

三種來源各有最省力的落地方式：

會議：開會時直接在該案件的 07_會議紀錄/ 開會議筆記，需要時搭配錄音機外掛邊錄邊記（見 Obsidian 進階｜外掛與 Canvas 白板的錄音機一節）；會後一句「請依會議紀錄範本整理，並更新案件總覽的待辦與時間軸」。

通話：掛掉電話的三十秒內，用手機對 Obsidian 的 Inbox 口述要點（語音輸入即可）：「甲公司張總來電，2026-015 案，對造把和解金額提高到三百萬，張總要求下週三前給評估意見」。AI 編纂時自動寫成電話紀錄筆記、歸入案件、更新總覽。

LINE 訊息：關鍵對話用 LINE 的「匯出聊天紀錄」存成文字檔（或截圖），丟進 Inbox 並註明案件，交給 AI：

Inbox 裡的「LINE對話_甲公司_0708.txt」是與甲公司窗口的對話，屬 2026-015 案。
請整理成溝通紀錄筆記存入該案 07_會議紀錄/：
1. 摘要雙方立場與提到的新事實；
2. 原文擷取所有含「指示、承諾、期限」的訊息，逐則註明日期時間；
3. 更新 00_案件總覽 的時間軸與待辦。

這一塊做起來之後，回報最明顯的地方是開庭與談判的準備：準備包（見實戰｜訴訟與非訟的日常工作流工作流一）讀取的不只是書狀，還有完整的溝通軌跡——「客戶已於 6/12 的 LINE 對話中同意調解方案」這種關鍵細節，靠的就是平時的三十秒。附帶的執業保護：委任過程文件化，日後對報酬、授權範圍有爭執時，紀錄就是你的證據。

⚠️ 注意
LINE 對話含大量個資與隱私（且常夾雜無關第三人的內容），匯出後先刪除與案件無關的部分再入庫；能否交給雲端 AI 處理，依方案分級（資安與倫理｜律師使用 AI Agent 的紅線）判斷。

八、整體架構長這樣

一個貫穿後續各篇的設定：本系列的正式形態，是把 Vault 直接開在個人雲端硬碟（OneDrive 或同性質服務）的根目錄——整個個人雲端就是你的 Vault，筆記與檔案同住一棵樹，這也是下一篇「底稿區／定稿區」設計的前提。（練習期照 Obsidian 入門｜安裝、Vault 與基本操作的建議放本機就好；要不要上雲、上到什麼範圍，是資安決定，見資安與倫理｜律師使用 AI Agent 的紅線。）

個人雲端硬碟（＝Vault 根目錄）/
├── CLAUDE.md                  ← 給 AI 的到職須知（見前篇）
├── 00_INBOX/                   ← 一切新材料先丟這裡，等 AI 編纂
├── 10_MATTERS/                 ← 案件軌：進行中（第一層：當事人）
│   ├── 甲公司/
│   │   ├── 00_共通/
│   │   └── 2026-015_工程款_甲v乙/（內部結構見第三節）
│   └── _內部/
│       └── 演講_202609律師公會AI課/
├── 20_AREAS/                   ← 研究軌：爭點筆記＋MOC；經營行政也住這裡
│   ├── 營建工程/
│   │   ├── 營建工程 MOC.md
│   │   └── 工期展延的可歸責事由.md
│   ├── 個資法/
│   ├── 所務經營/               ← 客戶與行銷、財務請款、制度與SOP（見第六節）
│   └── 進修/
├── 30_RESOURCES/               ← 研究軌的原料庫
│   ├── 判決/最高法院110年度台上字第XXXX號.md
│   ├── 法規筆記/
│   └── 文獻/
├── 40_ARCHIVE/                ← 案件軌：已結案（萃取後移入）
└── 90_SYSTEM/
    ├── Templates/             ← 判決筆記、爭點筆記、案件總覽範本
    └── Prompts/               ← 常用提示詞（如上面的結案萃取）

補充兩個支援性設計：

00_INBOX 是降低摩擦的關鍵。 讀到好文章、拿到新判決、開完庭想記兩句——不要想「該歸哪」，全部先丟 Inbox，分類歸檔是 AI 的工作。記錄門檻越低，系統才活得下去。
數字前綴 讓資料夾永遠按固定順序排列，你和 AI 都一眼掌握全局。

最後把三套方法論的分工整理成一張表：

方法論	負責的問題	在本架構中的角色
PARA（律師版：P 改寫為 Matter）	東西放哪裡？	頂層四資料夾；案件的生滅流轉（Matters→Archives）
Johnny.Decimal（取其精神）	資料夾怎麼排？	案件內部的固定編號結構
Zettelkasten	知識怎麼組織？	研究軌：一爭點一筆記、連結重於分類
MOC	網狀知識怎麼導覽？	每個領域的主題地圖
知識萃取（本篇提出）	兩軌怎麼交會？	個案研究 → 去識別化 → 永久知識

九、用 AI 一次搭好骨架

架構不用手動建。啟動 Claude Code，貼上：

請幫我在這個 Vault 建立雙軌知識庫架構：
00_INBOX、10_MATTERS、20_AREAS、30_RESOURCES、40_ARCHIVE、90_SYSTEM。

我的執業領域是：勞動法、個資法、公司法（請換成你自己的），
在 20_AREAS 為每個領域建資料夾與「◯◯法 MOC.md」主題地圖，
段落：重要法規、核心爭點、實務見解、待研究問題。

在 90_SYSTEM/Templates 建立三個範本：
1. 判決筆記：字號、法院、裁判日期、案由、事實摘要、爭點、
   法院見解、評析、相關筆記
2. 爭點筆記：爭點、相關法條、實務見解、學說、我的分析、相關案件
3. 案件總覽：基本資料、目前狀態、時間軸、爭點清單、卷證索引

在 10_MATTERS 建立示範當事人資料夾「示範客戶」，其下建立
案件資料夾「2026-000_示範案件」，內部結構：
00_案件總覽.md、01_請款資料、02_我方書狀、03_對造書狀、
04_法院文書、05_電子筆錄、06_當事人提供資料、
07_會議紀錄、08_開庭報告、09_法律研究。

三十秒，骨架完成。

十、三個長期心法

先求有，再求好。 架構是用出來的，不是設計出來的。三個月後要調整，也是一句話交給 AI 的事：「請把 Resources 的判決筆記按法領域分子資料夾，並更新所有連結。」
資料夾管樹狀，wikilink 管網狀。 「這則筆記既是勞動法又是個資法，放哪？」——放哪都行，用連結讓兩個 MOC 都指到它。讓資料夾保持粗略，把精細留給連結。
方法論是僕人，不是主人。 PARA、Zettelkasten 都只是工具，判準永遠是：下次要用時找不找得到、五年後知識有沒有變厚。合用就留，不合用就改。

小結

律師的專業資訊分兩塊：案件（有始有終）與研究領域（永續累積），必須雙軌管理。
案件軌：PARA 管生滅（P 改寫為 Matter，貼合律師用語）＋當事人為第一層、案件為第二層＋Johnny.Decimal 式固定內部結構＋案件總覽儀表板。
研究軌：Zettelkasten「一爭點一筆記」＋wikilink＋MOC 主題地圖。
事務所經營行政與研究領域同住 Areas；會議、通話、LINE 溝通紀錄進案件的 07_會議紀錄/，判斷不了先丟 Inbox。
兩軌交會於「知識萃取」：個案研究去識別化後回流知識庫——書狀定稿順手萃、結案總萃收尾。
這套架構同時寫給你和 AI 看——下一篇先把檔案的地面整平：底稿區與定稿區。

⬅️ 上一篇：CLAUDE.md｜寫給 AI 助理的到職須知
➡️ 下一篇：案件檔案實務｜底稿區與定稿區
🏠 回到總覽｜AI x Obsidian 律師實戰系列