設計師開始推程式碼上線：DoorDash、Watershed、Flux 各自怎麼設審查關卡

當設計師開始把 AI 產生的程式碼推上正式環境，真正的問題不是「能不能」，而是「誰來擋」。State of AI Design 2026 的 Craft 章節收錄了幾家公司的做法：DoorDash、Watershed、Flux，加上數家未具名的公司。這篇把它們放在同一條光譜上比較。需要先說明：這份報告的合作夥伴包含 Anthropic，Anthropic 的產品設計主管 Joel Lewenstein 也在報告中被引用；報告內容是受訪者自述，沒有任何缺陷率或事故數據。

調查先說了什麼

報告指出，50% 的受訪者已把 AI 產生的程式碼推上正式環境，但只有 20% 自認是設計工程師。依公司階段分，早期公司是 68%，成長期 50%，上市公司 33%；創辦人是 70%，將近一半的主管也在出貨。擁有權的回答是：40% 認為完全屬於自己，43% 認為大致屬於自己，9% 說很難區分。使用 AI 寫程式的設計師，覺得自己更有創意、更有能力的機率是其他人的兩倍，並回報更高的品質標準。這些都是自我回報的感受，不是產品品質的量測。

三家公司，三種閘門

DoorDash 把設計師放進與工程師相同的流程。消費者體驗設計主管 Shali Nguyen 說：「Everything goes through GitHub PR approvals」，設計師被要求達到與工程同儕一樣的正式環境品質標準；他們還加了一道設計審查，被標記的設計師要核准 UI 變更。Watershed 的設計主管 Hannah Hudson 表示，所有設計師都提交過正式環境的 PR，設計師也和工程師一起審查程式碼。這兩家的共同點是合併之前由人把關。

Flux 則在光譜的另一端。資深產品設計師 Brooks Solveig 說，他們做的是事後的 PR 審查，搭配 AI 風險評分系統與多個 AI 機器人的審查；他本人在許多情況下可以不經監督就合併自己的 PR。換句話說，把關從合併前移到合併後，由自動化系統承擔一部分責任。報告也提到未具名公司的做法：用 AI 風險評分讓低風險變更自動推送，設在沙盒讓工程師審查，或由工程師重建原型。Stripe 的 Katie Dill 提供一個自問的標準：「如果這花了我一週才做出來，我還會滿意嗎」。

Anthropic 的 Joel Lewenstein 說得更直接：現在沒有理由不深入參與最後的交付過程。因為 Anthropic 是報告夥伴，也是被引用的案例，這句話要當作立場表述，而不是中立的證據。

光譜上沒有答案的部分

這幾個案例回答的是「怎麼管」，沒有回答「管得好不好」。報告沒有提供任何比較：合併前人工把關與事後自動審查，哪一種造成較少的退回、回滾或事故。Flux 的做法依賴風險評分系統的準確度，而報告沒有揭露這個系統的誤判率。所以我們只能說這三種模式存在，不能說哪一種比較好。

這跟你的錢有什麼關係

如果你的設計師要開始提交程式碼，先決定走哪一種閘門，再談工具。人工把關的成本是工程師的審查時間，自動化的成本是建置與維護風險評分、機器人審查的工作；兩者都不是零。沒有數據證明事後審查比較省，也沒有證明它比較危險。

實務上的低成本起點，是從低風險的變更開始（文案、樣式），保留人工審查，並記錄退回率。累積自己的數據，比引用別人的案例可靠。