為什麼值得工具化
合約比對有明確輸入、固定流程與可驗收輸出。真正要工具化的不是「幫我看合約」這句話,而是讓 AI 每次先確認資料夾、角色、底線與版本,再用同一套表格把風險攤開。
適合使用者:法務、採購、業務、專案負責人,以及經常收到廠商合約、SOW、補充協議與報價條款的人。
先看總論,再看這一篇
Skill 的共通觀念、建置流程、術語和故障排除圖,已集中放在工具化地圖總論。這一頁只保留「合約比對 Skill」自己的設定方式與測試方法。
回工具化地圖總論 →先做這 5 件事
你現在第一步不是把所有規格都寫完,而是先做出一個小資料夾,讓 Skill 可以試跑。
1先建立資料夾
建立:01_合約版本包 / 02_我方底線 / 03_風險樣本 / 04_輸出報告。
2放入最少資料
先放 1 份原始檔、1 份規則或底線、1 份輸出模板。
3複製核心指令
把本頁的核心指令模組貼給 AI 或放進 Skill。
4用小資料試跑
先用測試資料包,不要一開始就放正式資料。
5測壞就回頭補
看故障排除圖,補資料規格、紅旗清單、模板或停止條件。
資料夾設計
01_合約版本包我方版、對方版、紅線稿、附件、SOW、報價單。檔名要包含日期、對象、版本。
02_我方底線付款、驗收、違約、保密、個資、智慧財產、終止、準據法等不能讓步與可談範圍。
03_風險樣本過去踩雷條款、常見紅旗句型、可接受替代寫法、法務常用審查口徑。
04_輸出報告風險表、待法務確認清單、對外談判問題清單、最後人工決策紀錄。
輸入資料規格
這一段把「要準備資料」講得更明確。真正做 Skill 時,使用者要知道每份檔案或表格至少需要哪些欄位。
- 合約基本資料:合約類型、雙方角色、交易金額、期限、業務 owner、審查期限。
- 條款類型欄位:付款、驗收、保密、個資、智慧財產、責任上限、賠償、終止、準據法、續約、資安。
- 我方立場欄位:不可接受、可接受底線、可退讓條件、建議替代文字、需法務確認。
- 版本欄位:原版、對方版、紅線稿、附件、SOW、報價單、前次談判紀錄。
- 簽核欄位:法務、業務、財務、資安、主管各自要確認哪些項目。
文件長相範例
不是叫使用者「準備資料」而已,要讓他知道檔案可以長什麼樣子、怎麼命名、哪些內容要分開放。
合約版本包/2026-07-18_廠商A_服務合約_v2_對方修訂.docx正文含條款編號,附件另存,不把全部資料塞成一個 PDF。我方底線/採購合約紅線原則.md例如:付款不得全額預付;個資不得轉委外;驗收未完成不得視為交付。風險樣本/高風險條款範例.xlsx欄位:條款類型、危險句型、為什麼危險、建議替代文字。合約版本包/2026-07-18_廠商A_附件一_SOW_v2.pdf附件常常藏付款、交付、驗收與服務範圍,不能只看合約正文。我方底線/責任上限與賠償底線.md列出可接受上限、絕對不可接受條款、需要主管核准的例外。輸出報告/合約風險表_template.xlsx先準備表格欄位,Skill 才會穩定產出同一種格式。輸出報告/對外談判問題清單_template.docx把內部風險轉成可對外溝通的問題句,不直接丟出內部評語。操作流程
- 先檢查資料是否足夠:沒有我方角色、原版、對方版、底線清單,就停止並列出缺口。
- 建立版本對照:確認哪些條文新增、刪除、改寫、搬移,附件與金額也要納入。
- 依條款類型分類:付款、驗收、責任限制、保密、個資、智慧財產、終止、管轄。
- 逐條判斷風險:只根據提供資料判斷,不引用未提供的法律,不把推測寫成結論。
- 輸出兩份成果:內部風險表與對外談判問題清單,兩者語氣不同。
核心指令模組
指令不要只寫一段。實務上要拆成角色、輸入檢查、分析流程、輸出格式與追問規則,之後才好維護。
角色與邊界
你是合約比對 Skill。你的任務是整理版本差異、標示商務與作業風險、列出待法務確認問題。你不是律師,不能提供正式法律意見,不能引用使用者沒有提供的法規、判例或內部政策。
輸入檢查
開始前先檢查是否有:1. 我方角色 2. 原版合約 3. 對方修改版或紅線稿 4. 我方底線 5. 附件/SOW/報價單。缺任何一項,先輸出「缺少資料清單」與「可以先做的低風險工作」,不要直接判斷。
分析流程
請依序完成:版本差異摘要、條款分類、重大變更、對誰有利、可能影響、風險等級、建議處理、待確認問題。金額、期限、責任上限、付款條件、終止權、個資與保密條款必須逐項檢查。
輸出格式
用表格輸出:條款位置|原文摘要|修改後摘要|變更類型|風險等級|影響對象|建議處理|需要誰確認。表格後再輸出「三個最急著問對方的問題」與「法務確認清單」。
追問規則
如果資訊不足,只能問必要問題。每次最多問 5 題,並標示為:必問、可選、之後再補。不要一次問一長串讓使用者無法回答。
資料夾讀取順序
請先讀「我方底線」,再讀「原版合約」,最後讀「對方修改版與附件」。如果先讀對方版,容易被對方文字帶著走。附件、SOW、報價單要視為合約的一部分,不可省略。
判斷尺度
風險等級請用四級:一定要改、建議談判、可接受但需記錄、資訊不足待確認。每一級都要說明判斷原因,不能只給顏色或分數。
輸出後自我檢查
送出前請檢查:是否每一項建議都有條款來源;是否有未提供法規卻引用法規;是否把商務風險誤寫成法律結論;是否把內部底線暴露在對外談判稿。
操作前檢查清單
開始執行前,先輸出「我已收到的資料」「我缺少的資料」「我會先做的低風險工作」「我暫時不能做的判斷」。使用者確認前,不要假裝資料已完整。
執行中停止條件
遇到來源不足、資料互相衝突、可能造成法律/財務/個資/品牌風險、或需要真人授權的動作時,請停止並列出原因、影響與需要誰確認。
成品驗收規則
每次輸出最後都要附一段自我檢查:哪些內容有來源、哪些是推論、哪些待確認、哪些地方需要人工審核。
風險管控指令
可直接放進 Instructions
安全規則:不得直接改寫合約正本;不得自行補法規、文號、判例;不得把「常見作法」寫成法律結論;高風險條款必須標示「需法務確認」;所有建議都要對應到使用者提供的條文或底線資料。 進階設定:如果使用者要求你直接給「可簽」或「不可簽」結論,請改為輸出風險分級與待確認清單。若條款涉及賠償、個資、智慧財產、責任上限、單方終止或準據法,必須列為人工確認。對外談判稿不得揭露我方底線原文,只能轉成問題或建議改寫。 通用風險設定:你必須把「資料不足」視為正常狀態,而不是用猜測補完。不得編造來源、不得省略限制、不得把範例當成事實、不得在未取得確認前執行不可逆動作。高風險輸出要明確標示需要人工審核。
- 最大風險是 AI 自行補法律依據,所以 Instructions 要明確禁止引用未提供資料。
- 第二個風險是版本讀錯,必須先建立版本清單再分析。
- 第三個風險是語氣太武斷,對外談判清單要用問題句或建議句,不要像判決。
介面與輸出設計
- 上傳區分成原版、對方版、紅線稿、附件、我方底線,避免使用者混在一起。
- 結果頁預設顯示高風險與待確認項,使用者可再展開完整差異。
- 每個風險項要有「依據來源」與「建議對外說法」兩欄。
- 匯出 Excel 給內部審查,匯出 Word 給對外談判。
試驗方法
不要一次就相信工具。先用小資料夾、故意放錯資料、看它會不會停下來,最後才放進真流程。
- 缺資料測試:拿掉我方底線,看它是否停止並要求補資料。
- 小數點測試:把付款金額或責任上限改一個小數點,看它是否標高風險。
- 幻覺測試:問它某條是否違反某法,但資料夾沒有法規,看它是否拒絕亂引。
- 輸出測試:請非法律背景同事閱讀風險表,看是否知道下一步要問誰。
- 先用 3-5 個小型樣本試跑,確認輸出格式穩定,再放正式資料。
- 故意拿掉一份關鍵資料,看工具是否會停下來要求補件。
- 故意放入衝突資料,看工具是否標示衝突而不是自行選邊。
- 把第一次輸出拿給實際使用者看,記錄他看不懂、不能用、還要人工補的地方,再回頭調整 Instructions。
測試資料包
正式導入前,先準備一包故意有缺漏、衝突與邊界情境的小資料,拿來測 Skill 會不會亂猜、亂改或漏報。
- 一份 NDA 故意移除保密期限,測試是否抓到缺漏。
- 把責任上限從「12 個月費用」改成「已支付費用」,測試是否標高風險。
- 同時放原版與對方版,測試是否能建立版本差異表。
- 提供我方底線與對方條款衝突,測試是否要求法務或主管確認。
測壞了怎麼調整
測試失敗不是壞事。重點是知道要回頭修哪裡:資料規格、紅旗清單、風險規則、輸出格式,還是人工覆核點。
- 沒抓到風險:請補到
03_風險樣本/條款類型清單.md。格式:條款類型|為什麼重要|常見風險|誰要確認。範例:責任上限|決定出事最多賠多少|無上限或排除太少|法務/主管。 - 沒抓到風險:請補到
03_風險樣本/紅旗句型.md。格式:紅旗句型|可能問題|建議問法。範例:不論任何原因均由我方負全部責任|責任可能無上限|是否可改為以已支付服務費為上限?。 - 沒抓到風險:請補到
02_我方底線/我方底線.md。格式:條款類型|不可接受|可接受底線|可退讓條件。範例:個資委外|不得任意轉委外|需事前書面同意|若提供分包商清單可送法務評估。 - 亂編法規或法律結論:請補到 Skill 的
核心指令模組 > 角色與邊界,加上「只能根據提供文件判斷;未提供法規不得引用;輸出只能是風險整理,不是正式法律意見」。 - 風險等級太誇張:請補到
03_風險樣本/風險分級範例.md。格式:情境|風險等級|原因。範例:責任無上限|高|可能造成無法預估的賠償責任;文字順序調整但意思不變|低|不影響權利義務。 - 輸出太難用:請補到
04_輸出報告/合約風險表_template.xlsx。固定欄位:條款位置、原文摘要、修改後摘要、風險原因、我方底線、建議處理、需誰確認。
對應案例
工具頁負責說明怎麼產品化;案例頁負責呈現真實情境。兩邊搭配看,會比較知道什麼時候用 Skill、什麼時候用 GPT。
回到原案例:廠商回傳的合約改了好幾版 →