AI 交叉審查流程（REVIEW-LOOP）
用一個 AI 產出，用另一個 AI 審查，由你自己判斷要不要採納。可以複製這份文件到任何專案中重複使用。
① 產出 → ② 產生審查 prompt → ③ 另一個 AI 審查 → ④ 逐項判斷、只套用同意的、commit
↑______________________________________________|
重複，直到符合「停止條件」三個原則
- 審查者會說錯。 它可能很有自信地給出錯誤的指令、錯誤的原因，或互相矛盾的建議。每一項都要判斷。
- 審查者只讀不改。 審查時不准它執行指令或修改檔案，避免它在你的電腦上做了你不知道的事。
- 每一輪都留下紀錄。 保存 prompt、審查原文、你的判斷。
紀錄方式
你的專案/
├── review-log/
│ ├── round-1-prompt.md ← 步驟 ② 產生的審查 prompt
│ ├── round-1-review.md ← 步驟 ③ 審查者的回覆（原文貼上，不要修改）
│ ├── round-1-decision.md ← 步驟 ④ 你的逐項判斷與理由
│ └── round-2-...
└── （你的程式或文件）每一輪都 commit 一次，review-log/ 的三個檔案和這一輪的修改一起 commit。git 記錄「改了什麼」，review-log/ 記錄「為什麼改」。
這樣做的好處：用 git log --oneline 能看到每一輪的變化；某一輪改壞了，可以從 git 找回那一輪之前的程式。想看初版到完成版的整體差異時，請 AI 幫你比較。
步驟與提示語範本
步驟 ①：產出
對產出用的 AI 說明需求，完成第一版。確認可以執行後，做第一次 commit：
git add -A
git commit -m "第 0 輪：初版"步驟 ②：請 AI 產生審查 prompt
貼給產出用的 AI：
請先執行 git status，確認沒有未 commit 的修改。如果有，先停下來告訴我，不要產生 prompt
（最常見的原因是上一輪套用修改後忘了 commit）。
確認沒有之後，幫我寫一段給另一位 AI 專家的審查 prompt，存到 review-log/ 的下一輪 prompt 檔。
開頭寫上：第幾輪、目前 commit 編號（git rev-parse --short HEAD 的結果）。
你只負責填寫「專案用途」「已決定的事」「前幾輪已修正與已否決的項目」（從 review-log/ 整理）。
以下規則必須逐字放進審查 prompt，不得改寫或省略：
- 只讀檔案，不要執行任何指令或修改任何設定。
- 依 🔴 一定要修／🟡 建議修 回報，每項寫明檔案與位置、問題、原因、建議修改。
- 不確定的地方請標「不確定」，不要猜測。
- 沒有重大問題就直接說「可以發布」。AI 會存成 review-log/round-N-prompt.md，開頭標明第幾輪與 commit 編號。先確認沒有未 commit 的修改，審查者看到的才會是那個 commit 的版本。AI 回報有未 commit 的修改時：如果是上一輪忘了 commit，依步驟 ④ 的格式補上那一輪的 commit；如果只剩這一輪剛產生的 round-N-prompt.md（例如重貼了一次提示語），刪掉它再重貼。每一輪都用同一段提示語：第 1 輪沒有紀錄，AI 只會寫專案用途；第 2 輪起會自動加上前幾輪已修正與已否決的項目，審查者就不會重複提出。交出去之前先檢查「已決定的事」：AI 常把自己寫程式時的設計選擇也列進去，等於叫審查者不要檢查。不是你決定過的，就刪掉或改成「請審查者評估」。
步驟 ③：交給另一個 AI 審查
把 prompt 貼給不同 AI 工具、且使用不同模型的 AI（例如產出用 Antigravity IDE，審查用 ChatGPT 網頁版），否則容易互相認同。
審查者讀不到你的檔案時（例如網頁版），把檔案內容貼在 prompt 最後，格式如下：
text（貼上 round-N-prompt.md 的全部內容） 本次共提供以下 N 個檔案：（列出檔名）。請在回覆開頭列出你實際收到的檔案； 若有缺少或內容不完整，請先說明，不要審查缺少的部分。 以下是專案檔案的內容： ===== 檔名 ===== （貼上檔案內容） ===== 檔名 ===== （貼上檔案內容）把回覆原文存成
review-log/round-N-review.md。
步驟 ④：逐項判斷
貼給產出用的 AI：
請逐項判斷以下審查建議（接受／部分接受／否決），附上可驗證的理由，先不要修改：
（貼上審查原文）你自己看過 AI 的判斷，有不同意的地方就提出來討論。確定後再說：
只套用同意的項目，修改後實際執行一次，並把判斷存到 review-log/ 的這一輪 decision 檔。AI 會依下方格式存成 review-log/round-N-decision.md。
確認修改後的程式實際執行成功，再把這一輪 commit（review-log/ 的三個檔案一起）：
git add -A
git commit -m "第 N 輪：接受 #1 #3，否決 #2"訊息列出這一輪接受與否決的項目編號（部分接受算在「接受」，「已處理」不列入）；全部否決時寫 "第 N 輪：否決 #1 #2"；審查者沒有提出任何建議時寫 "第 N 輪：無建議"。符合停止條件的最後一輪，訊息寫法見「停止條件」。
判斷紀錄格式（round-N-decision.md）
# 第 N 輪判斷
審查者：（使用的 AI 工具）
| # | 建議 | 判斷 | 理由（怎麼驗證的） |
| --- | --- | --- | --- |
| 1 | … | ✅ 接受 | … |
| 2 | … | ⚠️ 部分接受 | 問題是對的，但建議的做法會…，改成… |
| 3 | … | ❌ 否決 | 實際執行後發現… |
| 4 | … | 已處理 | 審查者看的是舊版，第 N-1 輪已修正 |
統計：接受 _ 項、部分接受 _ 項、否決 _ 項、已處理 _ 項怎麼判斷審查建議
| 狀況 | 怎麼做 |
|---|---|
| 指出的問題可以重現 | 實際執行一次，確認真的會出錯再改 |
| 給了具體的指令或程式碼 | 不要直接照抄，先想想在你的環境（作業系統、shell、資料）是否成立 |
| 引用版本號、檔案大小、預設值 | 查官方文件確認；查不到就不要寫進去 |
| 兩位審查者意見相反 | 不要多數決，回到事實與你的使用情境判斷 |
| 結論對、理由錯 | 可以接受結論，但在紀錄中寫下正確的理由 |
| 產出用的 AI 否決了某項建議 | 它是在評自己的作品，否決的項目要自己再驗證一次（實際執行或查官方文件） |
| 重複提出已否決的事 | 下一輪的 prompt 把它加進「已決定事項」 |
| AI 產生的審查 prompt 裡，「已決定事項」包含你沒決定過的事 | 刪掉或改成「請審查者評估」。第 1 輪通常只有需求文件裡的規定才算已決定 |
| 會讓內容變得很複雜，只為了處理極少見的情況 | 可以改成在文件中提醒，不一定要改程式 |
停止條件
符合以下全部條件才可以停止：
- 最後的版本已交給一個與產出者不同 AI 工具、且使用不同模型的審查者審查，沒有提出未處理的 🔴，並判定「可以發布」。（正式專案建議再請第二個不同的 AI 審查同一版本，兩位都同意才停止。）
- 所有 🟡 都已有判斷（接受／部分接受／否決）與理由。
- 套用修改後，已用測試資料實際執行過（程式跑過測試資料、安裝流程實際跑過），不是只看審查意見。
- 如果最後的修改會改變程式行為，修改後的版本要再審查一次；修改前得到的「可以發布」不能算在新版本上。
最後一輪如果套用了會改變程式行為的修改，就不能標成審查完成，要再審查一輪（第 4 點）。所以「審查完成」那次 commit 通常沒有程式修改，或只有不影響行為的修改。
符合停止條件的最後一輪，commit 訊息改用：
git add -A
git commit -m "審查完成：共 N 輪（第 N 輪：接受 #1，否決 #2）"這裡接受的只限不影響程式行為的修改，例如註解或文字。這一輪沒有修改時，只寫 "審查完成：共 N 輪"。「共 N 輪」不含第 0 輪，和括號裡最後一輪的編號相同。