12 實戰｜訴訟與非訟的日常工作流

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

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

💡 本篇重點
同一套「Vault＋AI Agent」，訴訟律師拿來管案件與書狀，非訟律師與企業法務拿來管契約、意見書與教育訓練。本篇是六個可以直接照抄的日常工作流。

前面各篇把系統建好了，本篇回答最實際的問題：「星期一早上進辦公室，這套系統到底怎麼用？」以下六個工作流，訴訟三個、非訟三個，每個都附可直接複製的提示詞。所有範例都假設你已依 檔案整理方法論｜案件與研究領域的雙軌知識系統 建好雙軌架構、寫好 CLAUDE.md｜寫給 AI 助理的到職須知。

訴訟視角（訴訟律師的辦案節奏）

工作流一：開庭前準備包

開庭前一天，在案件資料夾啟動 Claude Code：

1
2
3
4
5
6
7
8
明天是 2026-015 案的言詞辯論庭。請準備「開庭準備包」筆記：
1. 讀取 00_案件總覽、08_開庭報告 內歷次開庭紀錄、
   02_我方書狀 與 03_對造書狀 內雙方最新書狀；
2. 整理：目前各爭點的攻防現狀（我方主張／對造抗辯／法院已表態事項）；
3. 列出對造上一份書狀的新主張，以及我方尚未回應的點；
4. 從知識庫（20_AREAS 與 30_RESOURCES/判決）找出與各爭點相關的
   判決筆記，附 wikilink；
5. 最後產出「庭上可能被問的十個問題」與建議回應方向。

十分鐘後你得到一份開庭準備包——過去這往往是助理半天的工作量。你的時間花在修訂與判斷：AI 列的問題哪些真的會被問、回應方向對不對，這是你的專業。

💡 加碼：把時間軸變成一張互動圖
工期爭議這類案件，攻防常常就發生在時間軸上——原定工期、變更設計、追加工項、展延後完工日，先後順序一目瞭然勝過十段文字。可以在準備包之後追加一句：「請依 00_案件總覽的時間軸與卷證日期，生成一份互動式時間軸的 HTML 檔，存入本案資料夾」——用瀏覽器打開，就是一條可以縮放、點選的案件時間軸，開庭對照、向客戶說明進度都用得上。它與 Obsidian 進階｜外掛與 Canvas 白板 的 Canvas 是「空間性思考」的兩種載體：Canvas 適合自己動手排，HTML 圖表適合讓 AI 依資料生成。

工作流二：開完庭三十秒歸檔

開完庭在高鐵上，手機打開 Obsidian，把記憶猶新的要點口語化地丟進 00_INBOX（語音輸入也行）：

「今天法官關切工期展延事由的認定，要求兩週內補呈；對造聲請傳喚監造工程師王某；下次庭期 9/2 上午 9:30。」

回辦公室一句話：

1
2
請把 Inbox 裡今天的開庭紀錄整理成正式開庭筆記存入 08_開庭報告，
並更新 00_案件總覽的時間軸、待辦與下次庭期。

案件儀表板隨時保持在最新狀態，而花的力氣極少。

工作流三：書狀初稿的「三明治工作法」

書狀不能讓 AI 從零寫到底，但可以用「人—AI—人」三明治：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
【第一層：你口述論證骨架】
我要寫 2026-015 案的準備書狀，回應被告乙公司主張甲公司遲延完工、
應依約按日計罰違約金並自工程款扣抵的抗辯。我方（甲公司）論點：
一、乙公司變更設計、追加工項，依約工期應予展延，
展延後甲公司如期完工，並無遲延；
二、退步言，縱認有遲延，違約金之約定亦屬過高，
應依民法第 252 條酌減。請先不要寫，
向我確認你對這兩個論點的理解，並指出可能的弱點。

【第二層：AI 起草】
理解正確。請起草書狀這一段落：依台灣民事書狀慣例行文，
從知識庫調閱相關判決筆記作為引用素材（標註待核對），
存入 02_我方書狀/草稿_準備書狀三_v1.md。

【第三層：你修訂定稿】
（人工逐段修改、查證每一個引用、注入只有你知道的案件細節）

第一層的「先確認理解、指出弱點」是關鍵——它逼 AI 當你的辯論對手，而不是速記員；也逼你自己先想清楚。論證是你的，文字勞動是它的。

非訟視角（非訟律師、企業法務的交易節奏）

工作流四：契約審閱與條款知識庫

審約是最能吃到「知識複利」的工作。先建立習慣：每次審約的成果回流知識庫。以下以客戶A委託審閱的經銷契約為例（客戶A是這份經銷契約的委任客戶，立場為供應商）：

1
2
3
4
5
6
7
請審閱 00_INBOX 裡客戶A的這份經銷契約（客戶A為供應商）：
1. 讀取 20_AREAS/契約條款庫/ 的「經銷契約 checklist」筆記，逐項比對；
2. 產出審閱備忘錄：高風險條款（含理由與修改建議，表格呈現：
   條號｜原文重點｜風險｜建議修訂文字）、checklist 上有但本約漏未
   約定的事項；
3. 若發現 checklist 沒涵蓋的新型條款，在備忘錄末段提出，
   我確認後再更新 checklist。

注意最後一項的設計：checklist 會隨著每一次審約長大，這就是非訟版的「知識萃取」——而且是隨案進行的版本。這份 checklist 累積的是貼合自身業務的審約經驗。

工作流五：法律意見書的研究底稿

1
2
3
4
5
6
7
客戶詢問：外國公司未經認許，在台灣以網站向消費者銷售軟體訂閱，
有無公司法及消保法上的合規義務？請執行意見書前置研究：
1. 檢索知識庫中相關的爭點筆記與函釋筆記，列出已有的研究基礎；
2. 列出需要另行查證的法規與函釋清單（我會用法規資料庫核對）；
3. 產出意見書架構草稿：問題整理／適用法規／分析／結論與建議，
   分析部分先以條列呈現論證步驟，標明每一步的依據強度
   （明文規定／函釋／實務見解／推論）。

「依據強度標註」是給律師的設計：意見書最怕把「推論」寫得像「明文」，讓 AI 自己標註，你審查時一眼看出哪裡要補查證。法規查證環節接上 taiwan-legal-db 這類 MCP 工具後可以半自動化，見 MCP｜把 AI 接上法規資料庫。

工作流六：教育訓練教材產線

企業法務的年度苦差：幫業務部門上個資法課、幫採購部門上契約課。有知識庫之後：

1
2
3
4
5
6
7
8
請根據個資法 MOC 及其下所有筆記，為客戶A的人資部門製作
90 分鐘教育訓練教材：
1. 課程大綱（三大段，每段 25 分鐘＋Q&A）；
2. 講義筆記：每個主題附「人資日常情境案例」
  （招募履歷保存、員工監控、離職資料處理）；
3. 十題課後測驗（單選，附解析）；
4. 存入 10_MATTERS/客戶A/2026-021_教育訓練_人資個資課/
   （教育訓練也是一件有完成日的委任，比照案件編號收納）。

教材產出後可以再接一句「請把大綱轉成簡報格式」，交給簡報工具生成投影片初稿。知識庫平時養得越好，教材產出就越快。

加映：交件的最後一哩——從 Markdown 到 Word

六個工作流的產出都是 Markdown 筆記，但律師的交件格式是 Word。最後一哩同樣交給 AI：

1
2
3
4
請把 02_我方書狀/草稿_準備書狀三_v3.md 轉成 docx：
套用台灣書狀慣用格式（A4、標楷體、字級 14，
「壹、一、（一）」的標號層次對應標題層級），
存到同一個資料夾。

Claude Code 會完成轉檔與排版；事務所有固定範本的，把範本 docx 給它「比照這個格式」即可。兩個提醒：轉出後務必用 Word 開啟做最終檢查（分頁、註腳、當事人欄位）；需要保留修改軌跡時，明講「以追蹤修訂方式呈現我方修改」。從研究、起草到交件，全程不需要離開這套系統。

共通心法：工作流的三個設計原則

回顧六個工作流，會發現同樣的模式：

  1. AI 永遠從「讀你的知識庫」開始，而不是憑空生成。這是「先讀知識庫」這個設計的關鍵：產出建立在你累積的判斷之上，而不是模型的通用回答。
  2. 每個工作流都有回流設計：開庭筆記回流總覽、審約發現回流 checklist、研究成果回流爭點筆記。用一次，系統就變強一點。
  3. 人的位置固定在頭尾：頭是你定方向與框架，尾是你查證與定稿。中間的文字勞動，交給 AI。

反覆用到順手的工作流，就值得「制度化」——寫成一個 Skill，讓一句話就能觸發完整流程。這正是下一篇的主題。

⬅️ 上一篇：實戰｜打造判決知識庫：從裁判書到 WIKI 索引
➡️ 下一篇：Skills｜把你的 SOP 變成 AI 的技能
🏠 回到 總覽｜AI x Obsidian 律師實戰系列