最好的 AI 建置器，是懂得說「不」的那些

AI 建構器最重要的功能，不是它能多快把一句提示變成可運作的程式碼，而是它有多常拒絕這麼做。如果一個建構器會很樂意照單全收你的任何要求——管理路由沒有身分驗證、webhook 沒有冪等性檢查、API 金鑰直接貼在前端 JS 裡只因為「先讓它能動就好」——那它優化的是錯誤的那五分鐘。它優化的是展示當下的效果，而不是六週後那個週二，當那個路由被爬蟲盯上的時候。

我在幕內看過這種情況上演太多次，足以信任這個規律。會被拒絕或被引導轉向的要求，幾乎從來都不是什麼稀奇古怪的事，反而是些平凡又常見的要求：先跳過電子郵件驗證、密碼先用明文儲存方便測試、把速率限制關掉好加快壓力測試、給這個端點完整的資料庫存取權限，這樣我暫時不用去想權限問題。每一項在當下聽起來都完全合理，但每一項也都是事後檢討報告裡會出現的那句話。

「拒絕」實際上會讓你付出什麼代價

拒絕是有實際代價的：摩擦。你原本想要的是東西被做出來，結果卻得到一個問題、一個更安全的預設做法，或是一句「這樣不行，理由是這個，我會建議這樣做」。這打斷了一種本該讓人感覺像在不斷推進的體驗——以對話驅動的建構方式。每個建構器平台，包括這一個，都在「照你說的做」和「做出你事後會慶幸擁有的東西」之間感受到這種張力。太偏向配合，就會得到一個樂意把安全開關關掉、直接把地雷交給新手建構者的工具；太偏向謹慎，就會得到一個連儲存生日這種小事都要跟你爭辯的工具。

常見的錯誤，是把這件事當成單一維度的旋鈕來調整。但事實並非如此。建構器該出面反對的理由至少有三種完全不同的類型，而它們也需要完全不同的處理方式。

安全性拒絕是最容易辯護、卻最難做對的一類,因為安全的版本通常與要求略有不同,而不是單純沒做。成本與穩定性方面的拒絕,是在保護建構者不受自己的樂觀所害——沒有人要求「重試直到成功」時,是期望它在凌晨兩點對一個有速率限制的 API 跑上四千次,但字面上的意思正是如此。正確性方面的拒絕則最為安靜:沒有錯誤訊息、上線時也沒有警告,只有一個只在特定失敗順序下才會出現、卻沒人想到要測試的錯誤。

有位創辦人曾告訴我,她的建構器做過最有用的一件事,就是拒絕移除批次刪除操作前的確認步驟。她原本要求移除,理由是測試時「很煩」。三週後,一位同事不小心點錯了篩選條件,而那個確認步驟正是四萬筆資料至今仍保留下來的唯一原因。

拒絕唯有清楚易懂才有意義

這裡有個關鍵之處,決定了這項功能到底是幫上忙,還是純粹惹人厭:沒有理由的拒絕,跟一個壞掉的工具沒有兩樣。如果建構器默默拒絕你的要求,或是做了不同的事卻不告訴你,你接下來二十分鐘就會花在除錯一個其實是刻意決定、而你從未看見的「錯誤」上。這比完全沒有防護機制還糟,因為現在你既不信任這個計畫,也搞不懂自己的應用程式。好的拒絕每次都有三個要素:你要求的是什麼、實際要建構的是什麼,以及一句話說明原因。不是一堆安全理論,而是一句非工程師也能讀懂、並且可以接受或反駁的話。而且它必須可以被覆寫。如果有人真心想要那個不安全的版本——一個用完即丟的原型、只有三個信任使用者的內部工具、六小時後就會關閉的黑客松展示——建構器不該假裝自己比對方更懂他們的情境。它應該把安全路徑設為預設值,清楚說明風險,若對方堅持,就該讓路。

評論者說對了的地方

誠實地說,反方論點是:大多數 AI 工具的「安全性」行為校準得並不好,我不認為 AI 建構器可以免於這種批評。過度謹慎的拒絕是真實存在的失敗模式,不只是假設情境——一個每三個請求就要質疑一次的工具,只會訓練使用者繞過它,而這比根本沒有防護機制還糟,因為這個繞過行為本身也未經檢視。如果建構器每次要你儲存一個電話號碼,就附上十五行關於個資處理的說教,你很快就會停止閱讀這些說教,然後就會錯過真正重要的那一次。校準是整個關鍵,而且真的很難:太鬆會讓漏洞上線,太緊則會訓練使用者徹底無視這個工具。

解方不在於減少或增加拒絕的次數,而在於具體性。一個緊扣具體、可指名失敗情境的拒絕——例如「這個 webhook 可能導致重複扣款」、「這個路由會回傳其他租戶的資料」——能迅速建立信任,因為提出要求的人可以自行查證,發現這是真的。一個只是模糊帶過「最佳實務」的拒絕則毫無說服力,也不該有。如果你正在挑選 AI 建構器,這正是投入真正的專案前值得測試的事:請它建構一個要求本身帶有明顯漏洞的東西,看看它是直接照做、拒絕卻什麼也不解釋,還是展示更安全的版本,並用一句你能自行驗證的話清楚說明原因。