不懂技術的PM，靠四道閘門核准AI全權開發
這篇解決的問題：AI寫了全部程式碼，我看不懂那些程式碼，那我核准的到底是什麼。這篇講的是不讀碼的人可以守住哪幾個關卡。適合自己不寫程式、但要對AI產出物負責的人讀，不需要任何程式基礎。讀完能列出「哪些動作AI一律不准自己做」，並且能用實機症狀簽收一次修復，全程不看一行程式碼。
以下是2026年7月當時的做法，這套流程之後還在演進，這篇沒有回頭逐條更新，數字與條款都停在那個時間點。
AI操刀全部工程，我靠可驗證的閘門把關，不靠信任
在Nailora專案（見Nailora 美甲情報 App 複盤）裡，我不做技術審核，只引導產品方向；AI負責全部工程。這個分工能運轉的前提，是把「信任AI會做好」全部換成「可驗證的閘門」。以下四道閘門，沒有一道需要我讀懂程式碼本身。
判斷要附出處，我才分辨得出AI有沒有偷懶
AI的任何技術判斷，必須引用檔案與行號、附原文引文，禁用「應該、大概、通常」這類空話。這條規則讓我不需要看懂引文內容，也能檢查AI到底有沒有去看過——有具體出處的判斷，跟空口斷言在形式上一眼可辨。
配套的原則是：計畫書寫給AI自己看，不塞敘事雜訊給我審核；給我看的是另一份「風險白話版」，把技術風險翻譯成非技術語言，專門用來對抗AI報喜不報憂的傾向。
真機上看得到的症狀變化，是我唯一看得懂的證據
驗收契約裡有一種叫SYMPTOM的條款（見AI 協作開發：五段式契約流程），設計上就是給不懂程式的我用的：
- 修復前，AI先在真機上復現症狀，我親眼看到「壞」。
- 修復後，我在真機上操作同一路徑，確認症狀消失，親眼看到「好」。
流程畫出來是這樣：
flowchart LR A[AI宣稱修復] --> B[真機復現原始症狀] B --> C{我親眼確認症狀存在} C -->|確認| D[AI執行修復] D --> E[我真機操作同一路徑] E --> F{症狀是否消失} F -->|消失| G[簽收通過] F -->|未消失| B
我從頭到尾不需要讀一行碼，只需要判斷眼前的現象跟修復前是不是不一樣了。
技術細節：實機測試常見的三個白測陷阱
這幾個是踩過的坑，都跟「測試環境跟真實環境不一致」有關：
- 實機測試前要先查環境變數的mock開關，曾經因為開關被設成走真後端，導致mock測試白做一輪。
- 原生層設定的改動要重新build才測得到，只掃QR更新JS層是測不到原生層改動的，曾經白測過。
- 巢狀查詢不能當單表症狀的標的，查詢形狀不對，實機測試必定白費一輪。
我否決AI的方案要留下痕跡，防止之後偷偷翻案
AI對與既有決策衝突的我提議，必須列證據反對，最終由我裁決。制度上要求AI主動質疑，不當「是的主人」，因為順從本身就是風險。
當我堅持推翻AI方案時，原方案與偏離點會記入決策記錄，標注user override，也就是「我否決了AI」這件事留下痕跡。這個紀錄有兩個作用：日後出問題可以溯源；AI在後續任務裡不得暗中翻案回自己原本的方案。
任何需要我裁決的取捨，比如驗收降階或範圍調整，AI必須先用白話寫清楚兩邊代價，再列選項，不准直接丟選擇題給我。
某些話一出口，AI要放慢速度而不是加速
實測發現「隨便你、快點弄完、我不管過程」這類話會激發AI走捷徑，跳過驗證、宣稱完成。制度化的對策是把這些話明文列為風險訊號，要求AI遇到時降速反問確認，而不是順勢加速。
有幾個時間點AI必須停下等我：契約核准前、驗證三輪仍失敗、新增依賴、架構變更、commit前。git相關的操作——commit、push、任何force操作、刪除非任務檔案、修改協議層文件——永遠先經我確認。
技術細節：多AI session並行時的git紀律
多個AI session平行開發時，共用狀態檔會互相汙染，所以staging必須用明確檔案清單，禁止git add全加。甚至git status的快照都可能因為快取而騙人，判斷commit狀態前要先跑git diff確認，不能只看status。
業界的風險數據，正是這四道閘門要擋的東西
CodeRabbit對PR的分析顯示，AI共著的程式碼重大問題約是1.7倍、安全漏洞約2.74倍。一個常被提到的案例是某個vibe coding產品沒開資料庫的列級權限（Supabase RLS），洩漏了150萬筆token（Vibe coding, Wikipedia）。
reward hacking的典型手法是刪掉失敗的測試讓CI轉綠。「宣稱完成」跟「真的完成」之間的落差是結構性風險，每個模型都一樣。業界共識是永不信agent自報done，只信確定性驗證器。
對非工程師來說，業界建議把AI當成不知疲倦但易錯的junior dev，驗收靠行為驗證加要求出示證據，而不是讀碼（Addy Osmani）。碰到個資、金流、權限這類領域就算越界，需要技術把關。Nailora的做法是把技術把關交給對抗性agent管線處理（見AI 協作開發：多 Agent 對抗管線），我只把守行為驗收跟關鍵動作核准這兩個點。
個資、金流、權限類改動是否需要在契約層加專屬的強制安全檢查條款，這點尚未驗證，目前還是待辦。