如果我只是想先試用看看 Legal Plugin，不確定要不要長期使用，還需要先花時間客製化 legal.local.md 嗎？
如果只是想了解這個 Plugin 大致的操作介面跟報告格式長什麼樣子，直接用預設值跑一次 /review-contract 沒有問題——這能讓你快速感受到 GREEN／YELLOW／RED 分類、逐條分析跟修改建議這些功能實際輸出的樣子。但只要你打算把跑出來的分析結果當真、拿去實際判斷一份合約該不該簽、或是要不要跟對方談判某個條款，這時候預設值跟你實際所在司法管轄區之間的落差就會直接影響到你的判斷品質。
比較務實的分法是：用預設值測試「這個工具能不能用」，用客製化過的 playbook 決定「這份分析結果能不能信」——前者是產品評估，後者是實際依賴，兩者需要的準備工作不一樣。
我們公司在台灣，也有跟美國公司簽約的業務，這種情況下 playbook 應該怎麼設定？
這種情況下，比較實際的做法不是二選一（只設台灣標準或只設美國標準），而是把 playbook 裡的「可接受範圍」欄位設計成能同時涵蓋兩種情境。以準據法條款為例，「標準立場」可以設定為你們公司主要營運地（台灣）的法律，「可接受範圍」則可以把跟美國公司簽約時常見的準據法選項（例如 New York、Delaware）也一併列入，並在旁邊註明這類條款需要額外留意哪些跟台灣法規範可能有落差的地方（例如資料保護的通知時限）。
這代表客製化 legal.local.md 不是一次性寫死一組標準，而是要先盤點清楚你們公司實際往來的合約類型橫跨哪些司法管轄區，再把這些差異明確寫進「升級呈報觸發條件」裡——例如「準據法為美國各州且涉及資料保護條款時，一律升級給律師複核」，讓 Claude 知道哪些組合是需要特別小心處理的，而不是假設所有合約都適用同一套邏輯。
客製化 legal.local.md 這件事，是法務團隊自己就能做，還是需要工程或 IT 部門協助？
法務團隊自己就能完成，不需要工程或 IT 協助。這個檔案本質上就是一份結構化的 Markdown 文字檔，內容是條列式的法律立場跟標準，沒有任何程式語法——官方範例檔案裡的格式，就是用標題跟項目符號列出「標準立場」「可接受範圍」「升級觸發條件」這幾類資訊，任何熟悉合約審查邏輯的法務人員都能直接編輯，跟寫一份內部合約審查指引文件的技術門檻是一樣的。
真正需要的準備工作，其實是把原本存在資深律師經驗裡、沒有系統性寫下來的判斷標準，整理成白紙黑字——這件事本身可能比想像中花時間，但困難點在於「盤點跟整理公司的談判準則」這個知識工作，而不是任何技術操作上的門檻。存放位置也很簡單，只要放進任何一個已經分享給 Cowork 的資料夾，Plugin 就會自動找到它，不需要額外的部署或設定步驟。
如果我們公司暫時沒有時間完整客製化整份 legal.local.md，有沒有比較務實的折衷做法？
有，可以採取分階段客製化的策略，優先處理風險最高、最容易造成實際損害的條款類別。以多數公司常見的合約類型來看，準據法條款跟資料保護條款是優先順序最高的兩項——前者決定了整份分析的比對基準是否成立，後者則直接關係到法規遵循，一旦誤判可能有實質的合規風險，這兩項值得優先客製化，即使其他條款（例如智慧財產權歸屬的細節）暫時還沿用預設值。
另一個務實做法，是先在升級呈報觸發條件裡，把「準據法或資料保護條款尚未客製化比對標準」明確設成一律轉交律師複核的條件，等於是在還沒完整客製化之前，先設一道防線，確保這些高風險類別不會被 Claude 用美國預設值直接判定為 GREEN 放行——用這種方式先降低最大的風險敞口，再逐步把其他條款類別補齊。
Anthropic 開源的 Knowledge Work Plugins 裡，Legal Plugin 是話題性最高的一個——它用 GREEN／YELLOW／RED 三色標記逐條審查合約條款，公開消息一出，甚至讓 Thomson Reuters、RELX 這類法律科技上市公司的股價當天下跌超過一成，Jefferies 集團形容這是「SaaSpocalypse」。但幾乎所有教學文章都在講怎麼裝、怎麼用，很少有人仔細講清楚官方頁面上那段容易被跳過的免責聲明——這個 Plugin 預設用的是美國法域的標準，如果你的公司不在美國營運，裝完直接用，很可能是在用錯誤的法律框架審自己的合約。
Legal Plugin 的 GitHub 頁面上有一段話值得逐字讀：這個 Plugin 內建的預設 playbook 範例反映的是美國法律立場跟司法管轄區（Delaware、New York、California），如果你的公司在不同的法律體系下營運（EU、UK、Netherlands、Australia 等），在依賴這個 Plugin 的分析結果之前，你必須在 `.claude/legal.local.md` 裡客製化 playbook，讓它符合你所在司法管轄區的具體法律要求、標準合約條款跟合規義務。這句話用的是「must」，不是「建議」——代表這不是錦上添花的客製化選項，而是官方自己認定的必要前提。
Legal Plugin 的核心運作方式，是拿一份合約去比對你在 `legal.local.md` 裡定義的標準立場、可接受範圍跟升級呈報的觸發條件。官方提供的範例檔案裡，涵蓋了責任限制條款（標準立場：雙方互相設定 12 個月費用的上限）、賠償條款（標準立場：智慧財產權侵權跟資料外洩的互相賠償）、智慧財產權歸屬、資料保護要求（標準立場：任何個資處理都要簽 DPA，72 小時內通知外洩）、合約期限與終止，以及準據法條款——這些每一項的「標準立場」跟「可接受範圍」，都是以美國商業慣例為預設值寫死在範例裡的。
如果你直接安裝、不改動範例檔案就開始審合約，Claude 會拿美國商業合約的慣例去對照你的合約——例如把「72 小時內通知資料外洩」當成標準值去比對，但如果你營運的司法管轄區要求的通知時限跟這個數字不同，Claude 可能會把一個其實完全合規的條款標記成需要修改的偏離項；反過來，也可能把一個在你的司法管轄區明顯有問題、但剛好符合美國慣例的條款標成 GREEN 直接放行。這不是 Claude 判斷錯誤，而是它忠實地執行了你設定（或沒有設定）給它的標準——你沒有客製化，它就只能用內建的美國預設值去做比對。
範例 playbook 裡對準據法條款的預設標準立場，直接寫的是「你的司法管轄區」這個佔位符，可接受範圍則列出 NY、DE、CA、England & Wales 這類主要商業司法管轄區。如果你完全沒動這個佔位符，Claude 在審合約時對準據法條款的判斷邏輯就會是空的或誤用美國慣例，這正是最直接暴露「沒客製化」這件事的地方——一份合約如果約定的準據法是台灣法，用預設 playbook 去審，Claude 很可能因為找不到符合的比對標準而不知道該怎麼評估這條，或是誤用了不相關的美國司法管轄區慣例做比對。
好消息是，客製化 `legal.local.md` 不需要寫程式，它就是一份結構化的 Markdown 文件，你只需要把裡面每一項條款的「標準立場」「可接受範圍」「升級觸發條件」換成你所在司法管轄區、你公司實際採用的立場。這份文件本質上是把你們法務團隊原本存在資深律師腦中的談判準則，寫成 Claude 可以查閱的白紙黑字——換句話說，這個客製化步驟做的事情，跟找一位新進律師、把公司的合約審查標準教給對方是同一件事，只是這次教的對象是 Claude。存放位置也很單純：Cowork 裡存在任何一個你已經分享給 Claude 的資料夾內，Plugin 會自動找到它。
如果你的公司在美國以外的地方營運，安裝 Legal Plugin 之後，第一件事不是急著拿一份合約去測試 `/review-contract`，而是先花時間把 `legal.local.md` 裡的每一項條款，換成符合你司法管轄區的標準——這件事只需要做一次，之後每一次審合約都會沿用這份客製化過的標準。如果你的公司剛好就在美國、且採用的合約慣例跟範例裡的預設值相近，這個風險對你影響有限；但只要你的答案是「我不確定我們公司具體採用哪些標準立場」，這正是這個客製化步驟真正該解決的問題——與其等到用預設值審出一份看似合格、實際上完全沒有對照到正確法律框架的報告，不如把這一步當成安裝流程裡不能跳過的一環，而不是選配項目。