09 案件檔案實務｜底稿區與定稿區

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

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

ℹ️ 本篇適用對象
本篇預設一個前提：事務所有共用的案件文件庫或共用雲端硬碟（SharePoint 文件庫、Google 共用雲端硬碟等），專門存放案件的公版與定稿——本篇處理的正是「個人作業區」與「共用定稿區」如何分工銜接。符合這個前提的（多數採 M365 或 Google Workspace 協作的事務所），可參考本篇的設定。個人執業、或所內沒有這類共用空間的，本篇略讀即可：上一篇的案件資料夾結構已經很完整，本身就相當於文件庫的架構，直接沿用就能管好案件檔案；命名慣例（第五節）與 INBOX 週清的習慣，也仍可挑著用。

💡 本篇重點
Vault 就開在個人雲端硬碟上，筆記與檔案同住一棵樹。檔案用兩條規則管：任何檔案都有明確的家（五個頂層資料夾），以及底稿與定稿永遠分開（個人雲端＝作業區，案件文件庫＝定稿區，捷徑把兩區並排）。檔案系統整齊，AI 的歸檔、檢索與編纂才有穩定的基礎。

檔案整理方法論｜案件與研究領域的雙軌知識系統 處理的是「知識」（筆記）的組織；本篇處理「檔案」——每天湧進來的 Word、PDF、掃描檔、郵件附件。兩者互為表裡：檔案收納有邏輯，後續各篇的 AI 編纂與自動化才接得上。方法與上一篇同源（都是律師版 PARA 的轉譯），此處落實到日常檔案收納，並涵蓋 M365 與 Google Workspace 兩種協作環境的具體設定。

一、要解決的兩個問題

沒有固定收納邏輯時，常見的結果是：桌面和「下載」資料夾堆滿檔案，找東西只能靠記憶和逐一搜尋；同一份文書有五個版本散在不同地方，分不清哪份是最後送出去的；結案或交接時，得花大把時間回頭拼湊「哪些檔案屬於這個案件」。

這套方法的目標只有兩個：任何檔案都有明確的家（收到時不用猶豫放哪），以及定稿和底稿永遠分得開（不會拿錯版本）。

二、五個頂層資料夾：同一套 PARA，換成檔案視角

本篇的前提（承上一篇第八節）：Vault 就開在個人雲端硬碟（OneDrive 或同性質服務）的根目錄——整個個人雲端就是你的 Vault。筆記與檔案同住一棵樹：Obsidian 打開看到的是筆記，檔案總管打開看到的是全部。根目錄只有五個資料夾：

資料夾 放什麼 判斷標準
00_INBOX 所有還沒歸位的檔案 先丟這裡，之後再整理
10_MATTERS 進行中案件 有特定當事人、有要推進或追蹤的事項（含報價中）
20_AREAS 持續性的領域與職務 沒有結束日：執業領域研究、公會職務、所內行政
30_RESOURCES 模板與常用資源 跨案件重複使用：委任狀、報價函、簡報模板，加上判決與文獻等研究原料
40_ARCHIVE 已結案封存 案件終結，不再有進行中工作

這正是上一篇 PARA 架構的同一批資料夾（加上放範本與提示詞的 90_SYSTEM，表中略去）——上一篇從「筆記」的角度介紹它們，本篇從「檔案」的角度再走一遍。順帶劃清一條容易混淆的線：30_RESOURCES 收的「模板」是委任狀、報價函、簡報這類對外文書的檔案模板（docx、pptx 等）；Obsidian 的筆記範本則住在 90_SYSTEM/Templates/（見 Obsidian 進階｜外掛與 Canvas 白板 的範本一節），兩者分家。名稱可以自訂，分類邏輯是同一套：不按主題，按與行動的距離。 判斷一個檔案該去哪，依序問三個問題：屬於某個案件嗎（→10）？屬於某個長期領域嗎（→20）？是會重複使用的模板嗎（→30）？三個都不是、又不能刪，通常代表它其實屬於某個已結案的案件（→40）。

00_INBOX 是這套方法撐得下去的關鍵：忙的時候不用當場想清楚歸屬，先丟進去，每週找一個固定時段（例如週五）清空一次。INBOX 可以亂，但東西不能在裡面住超過一週。

三、核心設計：底稿區與定稿區分離

以 M365 環境為例：每個案件通常有自己的 SharePoint 文件庫（就是 Teams 團隊「檔案」頁籤背後的儲存空間），那是案件的正式紀錄。但草稿階段的東西——改到一半的書狀、給自己看的比較表、各種中間版本——全部塞進去，文件庫會變得難用，同仁也分不清哪份能引用。

解法是把兩個空間的角色分開：

  • 個人 OneDrive ＝ 作業區／底稿區：所有工作中的檔案都在這裡起草、修改。
  • 案件的 SharePoint 文件庫 ＝ 定稿區：文件完成、送出或需要讓團隊引用時，才移入。

「移入定稿區」這個動作本身就是訊號：進了文件庫的就是可以引用的版本，還在個人底稿區的就是草稿。 不需要另外溝通，版本混淆的問題自然消失。

實際設定：文件庫捷徑

讓這個流程順手的關鍵，是把案件的文件庫「掛」進自己的 OneDrive：

  1. 用瀏覽器打開該案件的 SharePoint 文件庫（或 Teams「檔案」頁籤 →「在 SharePoint 中開啟」）；
  2. 點工具列上的「新增 OneDrive 捷徑」（Add shortcut to OneDrive）；
  3. 捷徑會出現在 OneDrive「我的檔案」根目錄，再把它拖進對應的案件資料夾。

之後在檔案總管／Finder 裡，案件的底稿與定稿區並排出現在同一個資料夾內，完成一份文件只是「拖過去」一個動作。掛整個文件庫時，捷徑名稱結尾會自動帶「 - 文件」字樣，一眼就能認出定稿區。

⚠️ 幾個容易卡住的地方

  • 「新增 OneDrive 捷徑」按鈕有時收在工具列的「⋯」裡；找不到時，先確認位在文件庫根目錄、且沒有勾選任何檔案。
  • 工具列另有「同步」按鈕，建議選「新增捷徑」而非「同步」——同一文件庫兩者只能擇一，捷徑可自由收納進案件資料夾、換電腦也不必重設，同步做不到。
  • 拖動或重新命名捷徑，只影響自己的 OneDrive；刪除捷徑也不會刪除文件庫裡的任何檔案，可以放心操作。
  • 案件還沒有文件庫（例如報價階段）時，先全部在底稿區作業，文件庫建立後再掛捷徑。

Google Workspace 環境的對應

概念完全相同，名詞替換如下：

M365 的做法 Google Workspace 的對應
個人 OneDrive（底稿區） 「我的雲端硬碟」（My Drive）
案件的 SharePoint 文件庫（定稿區） 案件的「共用雲端硬碟」（Shared Drive）
「新增 OneDrive 捷徑」 對共用雲端硬碟的案件資料夾按右鍵 →「整理」→「新增捷徑」

三點差異：共用雲端硬碟的檔案屬於組織而非個人成員，天生適合當定稿區，承辦人異動檔案也不會消失；安裝「Google 雲端硬碟電腦版」後，共用雲端硬碟本來就會出現在檔案總管，捷徑的作用主要是在「我的雲端硬碟」的案件資料夾內並排看到定稿區；Google 文件與試算表是連結而非實體檔案，命名慣例照用，版本管理直接靠內建的版本紀錄。

四、案件資料夾的結構

10_MATTERS 底下固定三層：

1
2
3
4
5
6
7
8
9
10
10_MATTERS/
└── 甲公司/
    └── 2026-015_工程款_甲v乙/                ← 一個案件一個資料夾
        ├── 2026-015_工程款_甲v乙 - 文件       ← SharePoint 文件庫捷徑（定稿區）
        ├── CLAUDE.md                         ← 知識層（見前兩篇）
        ├── background.md
        ├── 00_案件總覽.md
        ├── 09_法律研究/                       ← 為本案做的法律研究筆記
        ├── 20260620_工期展延研究/             ← 單次工作的底稿，日期＋主題命名
        └── 20260626_爭點整理.docx

三條經驗法則：

  1. 每個當事人只有一個資料夾，名稱用固定基準（台灣公司用中文登記名、日本公司用日文商號、其他用官方英文名）。同一當事人出現兩個資料夾，檔案就會開始分家。
  2. 當事人資料夾底下只放「案件」，不直接散放檔案。單次工作一律收進所屬案件，日後才對得回案號；唯一例外是跨案件共用的資料（公司登記資料、集團架構圖、聯絡窗口），收進一個 00_共通 資料夾。
  3. 還沒開案的（報價中、潛在委任）也放 10_MATTERS——它們是活的、需要追蹤；40_ARCHIVE 只放真正結束的案件，活的案子放封存區等於移出視線，會漏追。

上一篇第三節的固定編號結構（01_請款資料～08_開庭報告），建議套用在案件文件庫那一側——文件庫是全所共用的定稿區，結構統一的效益在那裡最大。個人這側的案件資料夾則保持精簡，就是上圖那幾樣：文件庫捷徑、知識層筆記（CLAUDE.md、background.md、00_案件總覽.md、09_法律研究），加上進行中的日期底稿。沒有共用文件庫的，把編號結構直接建在自己的案件資料夾即可；小案不必勉強套，用日期資料夾就夠。

五、命名慣例

規則只有兩條，好記才做得到：

對象 格式 範例
日期性的工作資料夾／檔案 YYYYMMDD_主題 20260612_經銷契約審閱版（客戶A 非訟案）
案件資料夾 案號_案由 2026-015_工程款
  • 日期一律西元八碼 YYYYMMDD 開頭，檔名排序即時間序。
  • 底稿版本用 v1、v2 結尾。文件送出後留一個「當時送了哪一版」的紀錄：郵件寄出的另存 _vSent；有遞狀或收發文事實的，連同憑證存成 _遞狀存底／_收文存底 PDF。定稿本身已在文件庫，文件庫的版本歷程管「定稿的沿革」；這裡的標記管「底稿區的送出紀錄」，兩者分工、不重複。
  • 本系列以虛構案號 2026-015 示範，實務上代入所內分案系統的編號即可。還沒開案的先用 報價中_主題，開案後改名補上案號。

六、日常運作起來的樣子

  • 收到檔案時：能立刻判斷歸屬 → 直接放進案件資料夾；在忙 → 丟 00_INBOX。
  • 每週固定時段：清空 INBOX。歸案件的歸案件、模板進 30_RESOURCES、垃圾刪掉，通常十分鐘內結束。
  • 文件完成時：把定稿移入「 - 文件」捷徑——正式版本永遠只有文件庫那一份。想在底稿區留底的，留的是標了 _vSent 的底稿，不是另一份定稿；兩邊各放一份定稿，版本歧義就回來了。
  • 結案時：確認定稿都已在文件庫，把整個案件資料夾從 10_MATTERS 移到 40_ARCHIVE。案件檔案從頭到尾都在同一個資料夾，結案封存就是移動一個資料夾的事。
  • 結案前多做一步（選做，但報酬最高）：把具通用價值的法律研究去識別化後複製到 20_AREAS 對應領域——這就是上一篇「知識萃取」在檔案系統端的動作，做法詳見該篇。

💡 這套檔案系統與 AI 的關係
結構固定、命名一致的檔案系統，正是 AI Agent 最好發揮的環境：「把 INBOX 裡的檔案依規則歸檔」「把這個案件 09_法律研究 的成果去識別化萃取到 20_AREAS」都能交辦（見 從檢索到編纂｜讓知識庫自己長大）；批次歸檔這類重複動作，甚至可以做成自己的工具。人訂制度，AI 執行制度。提醒：這個區放的是真實當事人卷證，讓 AI 讀取、歸檔之前，先過方案分級的判斷（見 資安與倫理｜律師使用 AI Agent 的紅線）。

七、導入建議

不需要一次到位：

  1. 先在個人雲端建好五個頂層資料夾（十分鐘）。
  2. 從下一個新案件開始套用「當事人／案號＋文件庫捷徑」結構；近期沒有新案件，就挑一個進行中、檔案還不多的案件先試，當天就能練到文件庫捷徑這個關鍵動作。
  3. 訂一個每週清 INBOX 的固定時段。

成本主要在前兩週的習慣養成，之後「檔案該放哪」就不再是需要思考的問題。

八、常見問題

Q：會不會跟事務所 SharePoint 的既有結構衝突？
不會。這套方法完全不動 SharePoint 端的任何東西，只整理個人的 OneDrive，並透過捷徑「引用」文件庫，不影響其他人。

Q：多人共同承辦的案件怎麼辦？
定稿區（文件庫）本來就是共用的，不受影響。各人的底稿在各人的 OneDrive；需要給同事看的階段性草稿，放進文件庫或用共用連結即可。

Q：檔案很多的舊案件要搬進這個結構嗎？
不用。回溯整理的工作量太大，是導入時最常見的挫折來源。只對新案件套用，舊的維持原狀，自然汰換。

Q：INBOX 積了一堆清不完怎麼辦？
清 INBOX 只做「移動」不做「處理」——判斷歸屬然後拖過去，不要順便打開檔案開始工作。真的判斷不了的，多半代表那個檔案其實可以刪。

Q：往來郵件要不要存進資料夾？
郵件原始紀錄留在 Outlook。但會被引用或具卷證性質的——客戶的正式指示、對造來函、行政機關通知——另存成 PDF 或 .msg 放進案件資料夾，命名照 YYYYMMDD_主題。判準：結案後別人只看案件資料夾，能不能掌握全案。

Q：結案封存在個人 OneDrive，跟事務所的正式保存是什麼關係？
40_ARCHIVE 封存的只是個人工作底稿。案件的正式紀錄自始至終在文件庫，保存年限與交接依所內規定，不因個人整理方式而受影響。

小結

  • 兩條規則：任何檔案都有明確的家（五資料夾＋INBOX 週清）；底稿與定稿永遠分開（文件庫捷徑）。
  • 「移入定稿區」是全團隊不言自明的版本訊號。
  • 命名兩條：YYYYMMDD_主題、案號_案由；送出留 _vSent 存底。
  • 檔案系統是 AI 施力的地面——下一篇，讓 AI 開始在這片地面上替你編纂。

⬅️ 上一篇：檔案整理方法論｜案件與研究領域的雙軌知識系統
➡️ 下一篇：從檢索到編纂｜讓知識庫自己長大
🏠 回到 總覽｜AI x Obsidian 律師實戰系列