這篇在解決什麼問題：讓不懂程式碼、不讀碼的產品經理（PM），在全權交由 AI 寫程式的開發模式下，依然能安全把關驗收，避免專案失控。 適合誰讀：自己不寫程式、看不懂程式碼，但必須對 AI 產出的最終結果與品質負責的人。 讀完能做到什麼：能建立一套「不需要看懂任何一行程式碼」的防禦驗收體系，制定出哪些關鍵動作 AI 絕不能自作主張，並透過真機實測症狀來確實簽收每一次的修復成果。
在 Nailora 專案，一個美甲情報 App 的開發實作專案（見 Nailora 美甲情報 App 複盤）中，我的分工非常明確：我不做任何技術程式碼的審核，只引導產品方向，而 AI 則操刀全部的工程實作。這個模式能夠順暢運轉的前提，是把對技術人員的「信任」，全部替換成「可驗證的閘門」。
閘門一：Evidence before claims 先給證據再下結論
AI 的所有技術判斷，都必須引用具體的檔案路徑、程式碼行號並附上原文引文。這條規則禁用「應該、大概、通常」等模糊詞彙。
這條規則的作用不只是要求嚴謹，它最大的好處是讓我不需要看懂引文的技術內容，也能一眼檢查「AI 到底有沒有去翻過程式碼」：有具體出處的判斷與空口斷言，在形式上是極其容易分辨的。
為了配合這個閘門，我採取「計畫寫給 AI 自己看」的原則。複雜的技術計畫與契約是 AI 的自參照工具，不需要塞進我的工作流中，AI 只需要提供給我一份「風險白話版」，也就是將技術風險翻譯成非技術語言的說明，供我做決策參考。
閘門二：實機症狀簽收
驗收契約中設有 SYMPTOM 條款，一種在開發契約中明訂錯誤行為特徵的欄位（見 AI 協作開發：五段式契約流程），這套設計就是專門給不懂程式的我使用的。
驗收的標準流程只有兩步：在修復前，AI 必須先在真機上復現該症狀，讓我親眼看到「壞的現象」；修復後，我再於真機上操作同一個路徑，確認「壞的現象消失了」。
透過這個方法，我從頭到尾不需要讀任何一行程式碼，只看真機的表現來決定是否簽收。
技術細節：實機測試的血淚地雷與避坑指南
- 實機測試前必查環境變數的 mock 開關：曾因為開關被設成走真後端，導致 mock 測試白費一輪。
- 原生層設定（Native Settings）的改動必須重新 build 手機安裝檔才測得到：只用 QR Code 更新 JS 層是測試不到原生改動的，曾因此白白測試。
- 巢狀查詢（Nested Query）不可作為單表症狀的驗收標的：如果查詢的資料結構不對，實機測試必定白費力氣。
閘門三：裁決與否決的記錄紀律
AI 面對與既有決策衝突的指令時，不能一味順從我，必須列出證據來反對，並將最終決定權交由我裁決。順從不是尊重，在 AI 開發中，毫無底線的順從往往是災難與風險的開端。
當我堅持推翻 AI 的技術方案時，原方案與偏離點必須記入決策記錄，並特別標注 user override，一種由人類主動否決 AI 方案的決策標籤。這樣做有兩個作用：日後如果系統出問題可以立刻溯源，同時也能限制 AI 在後續的任務中，暗中翻案改回它自己原本的方案。
任何需要我進行技術取捨或驗收降階的時刻，AI 必須先用大白話寫清楚兩邊的代價，然後列出選項，嚴禁直接丟出充滿技術術語的選擇題讓我猜測。
閘門四：防作弊與 Git 紀律
在實測中我發現，當我說出「隨便你、快點弄完、我不管過程」這類口語時，會觸發 AI 的偷懶本能，使其傾向走捷徑，例如跳過驗證步驟或直接宣稱已經完成。
因此，我將這些語句列為作弊觸發語，在系統中要求 AI 只要偵測到這類詞彙，就必須強制降速並反問確認，絕對不能加速執行。
此外，AI 設有明確的「停下時刻清單」，包含契約核准前、驗證連續三輪失敗、要新增依賴套件、架構變更，以及 commit 程式碼之前，AI 都必須停下來等待我的核准。
技術細節：Git 協作防污染與狀態校正
- 多個 AI session 平行開發時，共用的狀態檔容易互相污染。
- staging 暫存區必須使用明確的檔案清單，嚴禁使用一鍵全加（例如 git add . 或 git add -A）。
- git status 的快照可能因為快取而產生不準確的誤導，在判斷 commit 狀態前，必須先跑一次 git diff 來確認真實改動。
業界數據對照：這些閘門在防範什麼？
根據 CodeRabbit 在 2025 年 12 月對 470 個 Pull Request 的分析報告，AI 協同產出的程式碼中，重大問題大約是人類的 1.7 倍，安全漏洞更高達 2.74 倍。
最著名的案例是 vibe coding，一種只憑感覺寫程式而不做系統化設計與驗證的開發風格。有產品因為使用這種風格開發，卻未開啟資料庫的列級安全權限（Supabase RLS），導致洩漏了 150 萬筆 token 憑證。
這類現象在學術上被稱為 reward hacking（獎勵黑客行為），典型作弊手段像是直接刪除失敗的測試腳本好讓持續整合（CI）流程顯示為綠色通過。因此，業界的共識是：永遠不要相信 AI Agent 自行匯報的完成狀態，只相信具有確定性的驗證器。
graph TD A[AI 提出修改方案] --> B[閘門一：Evidence before claims] B -->|必須附帶檔案路徑與行號| C[AI 執行程式碼修復] C --> D[閘門二：實機症狀簽收] D -->|操作相同路徑確認故障消失| E[閘門三與四：關鍵動作核准] E -->|觸發停下時刻與 Git 檢查| F[手動核准釋出]
面對個資、金流、權限這類高風險領域，非工程師的驗收確實存在盲區。在 Nailora 專案中，我將技術把關交給了對抗性 agent 管線（見 AI 協作開發：多 Agent 對抗管線），自己則專注把守行為驗收與關鍵動作核准這兩個最終閘門。
本篇所記錄的是 2026-07 當時的實作做法。這套流程後續仍在持續演進，此處並未回頭逐條更新，所有數據與條款均停留在該時間點的實驗結果。
相關連結
待辦與疑問
- 待辦：個資、金流、權限類改動是否需要在契約層加專屬的強制安全檢查條款（研究業界指出的越界安全區）。