A、B 第一輪
各自生成證據索引、審查意見、跨域問題、缺口清單與結果 ZIP。
合約審閱為什麼不適合交給一個 GPT 一次做完
合約同時牽涉交付、付款、驗收、授權、食品與廣告合規、權利義務與文字品質。本案不是要讓 AI 決定能不能簽，而是把它擅長的整理、比對、追問與格式化，放進可被人檢查的流程。
CASE 1 / 合約審閱
把專業審查拆開，才有辦法一起把關
先用 ChatGPT 規劃角色、證據與交接，再建立三個 Projects 完成獨立審查、交叉勾稽與人工決策。
問題起點
先設計
把合約工作拆成三種責任
| Project | 主要問題 | 必須留下的成果 |
|---|---|---|
| A 商務審查 | 交付、驗收、付款、KPI、時程與數字是否能執行？ | 商務審查意見、證據索引、給 B 的跨域問題 |
| B 法律合規 | 授權、責任、終止、廣告、個資與權利義務有哪些風險？ | 法律合規意見、法源與不確定性、給 A 的跨域問題 |
| C 整合 | A、B 的意見是否有證據、互補或衝突？ | 修訂建議草案、注意事項、人工決策清單 |
A、B 先獨立工作，才能保留不同視角；C 不是直接相信兩邊，而是回到合約原文逐項核對。
用 ChatGPT 共創
完整指令不是一次寫完，而是一連串設計與核准
如果一開始就要求 ChatGPT「幫我做三個合約審查 Projects」，它通常會很快給出一套看似完整的答案，卻可能自行決定角色、欄位與交接方式。真正可模仿的做法，是先把工作說清楚，讓 ChatGPT 提問與比較方案；你確認一層，才讓它往下一層建立。
先探索說明痛點、限制與人工責任，不先把角色和檔名當成答案。
再核准角色、資料流與檔案介面都要由使用者明確選擇。
最後建置分角色建立、分別測試，通過後才封裝成 Sources ZIP。
對話一：只談工作，請 ChatGPT 訪談
先描述使用者看得到的問題：審查耗時、商務與法律需要不同判準、AI 不得代替權責人。這一輪不談 A、B、C，也不要求檔案。
我想改善目前的合約初審工作。
現在的問題是：閱讀很花時間、容易漏掉前後不一致，而且商務執行與法律／合規需要不同判準。AI 可以協助整理、比對、計算、追問與產生初稿，但不能代替商務主管、法務或簽署人做最後決定。
我希望使用 ChatGPT Projects，讓固定規則、參考資料與工具可以重複使用；每次案件只更換新合約與直接附件。Project 數量希望控制在三個以內，不同專業觀點要先保留獨立判斷，再互相檢查並整理成人工可處理的結果。
請先擔任工作流程顧問，最多問我五個會改變架構的問題。每題說明為什麼要問、不同回答會影響什麼。不要提出檔名，不要建立程式、範本或 ZIP。你要檢查：問題是否真的會影響角色數量、責任邊界、資料流或人工決策；如果只是日後才需要補充的專業細節，不必在此時卡住。
對話二：回答問題，請它比較方案
以下是我的回答：
- Q1：___
- Q2：___
- Q3：目前不知道。請提出建議做法、理由與風險，供我選擇。
- Q4：___
- Q5：___
若資訊已足夠，請提出二至三種工作流程，逐一比較 Project 數量、角色目的、獨立性、互相勾稽方式、人工介入點與初學者操作負擔。請提出建議，但不要替我選擇，也不要建立檔案。合理答案可能是兩個獨立審查角色加一個整合角色，也可能是別的組合。這一階段比較的是能力與操作負擔，不是角色名稱有沒有和本課程一樣。
對話三：選擇方案，凍結角色契約
我選擇方案___。
選擇理由：___。
不採用其他方案的理由：___。
請把選定方案整理成角色契約：每個角色要解決的問題、可讀取的資料、不可決定的事項、主要步驟、最小交接目的，以及最後交給人工的內容。
請檢查角色重疊、工作漏接、第一輪獨立性、交接是否過量、整合角色是否回到原始資料，以及人工 Gate。先不要命名檔案，也不要寫完整 Instructions 或 Skill。確認後再回覆：DESIGN-GATE：通過。如果看不懂某項責任，先退回修改，不要為了趕進度直接通過。
對話四：從用途推導檔案與介面
另開新對話，只上傳已核准的工作流程摘要與角色契約，避免整段聊天把早期假設一併帶入。
請依核准的工作流程摘要與角色契約，設計可放進 ChatGPT Projects 的最小資料架構。
每個角色分別列出：固定放在 Sources 的內容、每案上傳內容、各階段成果、交給其他角色的最小資訊、只供保存而不應交接的結果、可由程式檢查的事項，以及必須由人工處理的事項。
先說明用途，再提出檔名、格式與必要欄位。另請定義命名原則、狀態值、交接白名單、結果包規則，以及正常、缺件、格式錯誤的最低測試。本輪只提出檔案與介面方案，不建立實際 Sources 或 ZIP。確認檔名與欄位真的能支援交接後，再回覆：FILE-CONTRACT-GATE：通過。從此刻起，後續建置才可以引用這些檔名。
對話五：一個角色一個對話，逐包建立
三個角色分開建置。每次只上傳核准的設計文件，避免把另一個角色的完整推理、範例與測試資料混進來。
請依我上傳的核准文件，只建立「___角色」的完整 Project Sources。
先檢查文件是否足以建置；若有會改變介面的阻塞問題，請停止並列出 BUILD_GATE，不得自行假設。若可繼續，再建立 Instructions、Skill、固定規則、參考資料、範本、必要程式、測試與精簡交接文件。
請實際測試正常、缺件與格式錯誤情況。通過後才建立 Sources ZIP，並列出檔案、契約差異、已執行測試、未執行項目與限制。每一包都要讀完測試結果再回覆 BUILD-GATE：通過。第二個角色只需要第一個角色的介面交接，不需要完整 Sources ZIP。
對話六：檢查三包是否接得起來
請依核准的工作流程、角色契約、檔案契約、介面契約與建置驗收表，檢查三包 Project Sources。
請驗證：第一輪是否保持獨立、交接是否最小化、整合角色是否回到原始合約、固定 Sources 與每案輸入是否分離、缺件時是否受控、個別成果與 ZIP 是否可產生、程式是否只做確定性檢查、人工 Gate 是否明確，以及 ZIP 是否含有快取、暫存或其他角色的完整內容。
若能力成立但檔名不同，不要判定失敗；若有問題，只提出受影響能力與最小修正，不要重做整套架構。對話七：用真實案件測試，不再修改設計答案
最後才建立三個 Projects，載入已通過檢查的 Sources，使用同一版去識別化合約跑第一輪、最小勾稽、最終版與整合。此時若發現問題，要判斷是資料缺件、使用者操作錯誤，還是工具契約真的需要修正，不要在案件對話裡臨時改寫固定規則。
| 看到的現象 | 應採取的動作 |
|---|---|
| ChatGPT 自行決定角色與檔名 | 退回探索或檔案契約階段，不要直接接受。 |
| 缺資料仍產生肯定結論 | 補上停止條件與 PARTIAL／STOPPED 狀態測試。 |
| A、B 互相看到完整答案 | 縮小交接白名單，只傳問題、證據與回應範圍。 |
| C 只摘要 A、B | 要求每項整合意見回到原始合約版本與證據位置。 |
| ZIP 能下載，但檔案互相接不起來 | 檢查欄位、格式與讀取器，不以「已打包」視為完成。 |
建立三個 Projects
每一包都用同一套安裝方式
- 1. 建立 A、B、C三個 Project 都選 Project-only，名稱清楚標示角色。
- 2. 解壓各自 Sources將每包的
00_Project_Instructions.md貼入對應 Project Instructions，其餘檔案加入 Sources。 - 3. 上傳同一份合約先把合約 A 或合約 B 同時上傳到 A 與 B；不要先把其中一方的答案交給另一方。
- 4. 確認輸入狀態資料完整就繼續；資料不足則選擇補件、接受 PARTIAL，或維持 STOPPED。
完成兩輪審查
照這個順序搬運檔案
只交換勾稽 CSV
把 A→B 問題表上傳 B；把 B→A 問題表上傳 A。
A、B 最終版
回應對方問題，標示維持、補充、修正、衝突或送人工決定。
交給 C
上傳原始合約、A 與 B 的最終交接檔。不要上傳兩包完整 ZIP。
檢查修訂草案
逐項確認原文位置、A／B 依據、衝突、待補資料與負責人。
人工決定
採用、補件、送專業覆核、商務決策待定或不採用。
你要檢查什麼
看到完整 ZIP，不代表審查已經可信
- 每一項意見是否能回到合約條款或附件。
- A、B 是否先獨立完成第一輪。
- 勾稽時是否只交換指定 CSV。
- C 是否把衝突與資料不足留在人工決策清單。
- 修訂文字是否仍標示為討論草案，而不是可直接簽署版本。
這一頁要下載的檔案