負向提示跟正向描述,實際上是在解決同一個問題的兩個角度,還是完全不同的兩件事？
兩者解決的其實是同一個目標——讓生成結果更接近你真正想要的樣子——但切入的角度完全不同。正向描述是在「有限的描述篇幅裡,盡量精確地指出你想要什麼」，這個做法的侼限在於,你永遠無法窮舉所有你想要的細節,模型遇到你沒講清楚的地方,就會退回訓練資料裡最常見的預設做法。
負向提示則是反過來操作——不嘗試窮舉你想要的一切,而是精準地排除掉那些你知道會出問題的預設做法。這個角度的優勢是「排除」通常比「窮舉」容易——你不需要描述一個完美的設定頁面長什麼樣,只需要知道「不要把密碼存在沒加密的 state 裡」這幾件具體的事,模型就會自動從其他沒被排除的做法裡,選一個相對合理的方案。
為什麼模型的「預設做法」會傾向教學範例等級,而不是正式產品等級？
這跟模型訓練資料的來源分布有關——網路上公開可得、數量龐大的程式碼與設計範例,絕大多數來自教學文章、入門課程、快速原型展示,這類內容的目標是「用最少的程式碼講清楚一個概念」,不是「符合正式產品的安全與效能標準」。正式產品等級的程式碼（例如正確處理 Token 加密儲存、完整的錯誤處理邏輯）通常藏在企業內部的程式碼庫裡,不會大量出現在公開訓練資料中。
這代表當你的 Prompt 沒有明確排除某個做法時,模型統計上最容易選到的,就是這些數量龐大的教學範例模式——不是模型能力不夠,是訓練資料的分布本身就偏向這個方向，這也是為什麼負向提示能有效改善結果：它直接把模型拉出這個統計上最常見但品質較低的區域。
負向提示在圖像生成跟程式碼/設計生成上,運作邏輯有沒有不一樣？
底層邏輯是一樣的——都是透過明確排除某些模式,把生成結果從「統計上最常見」拉向「你實際需要」的方向,差異只在於排除的對象類型不同。圖像生成的負向提示排除的通常是具體的視覺缺陷（多餘的手指、扭曲的肢體、不該出現的文字疊加），這些是可以直接在畫面上看到、容易描述的瑕疵。
程式碼或設計系統生成的負向提示,排除的則往往是「做法」而不是「外觀」——不要用某種儲存方式、不要用某種型別宣告、不要用某種檔案結構。這類排除條件需要你對該領域的最佳實踐有一定認識,才能準確地指出「這個常見做法其實有風險」,比單純描述視覺缺陷需要更多背景知識，但一旦建立起這份排除清單,就能重複使用在同類型的生成任務上。
我要怎麼開始建立自己的「固定排除清單」，有沒有實際的起手方式？
最實際的起手方式是回顧你最近用 AI 設計工具生成的內容,挑出讓你每次都要手動修正的那幾個重複出現的問題——不是偶發的小瑕疵,而是「幾乎每次都出現、每次都要改」的模式。把這些重複出現的問題,改寫成明確的排除句，就是你的排除清單的第一版。
例如如果你發現 AI 生成的設定頁面老是用行內樣式,那就寫下「不要用行內樣式,改用既有的 CSS 類別系統」；如果發現生成的按鈕老是缺少 hover 跟 disabled 狀態,就寫下「不要只生成預設狀態的按鈕,hover 與 disabled 狀態都要包含」。這份清單不需要一次做到完美，每次生成完之後,如果又發現新的重複性問題,就補一條進去,幾輪之後你會有一份真正針對自己實際使用模式打磨出來的排除清單,比照抄別人的通用清單更有效。
大多數人寫 Prompt 的習慣是正向描述——「我想要一個簡潔的設定頁面」「我想要卡片式的佈局」。這類描述沒有錯，但有一個結構性的限制：AI 模型訓練資料裡最常見的「設定頁面」長什麼樣子,往往是教學範例等級的寫法,不是正式上線產品該有的品質。負向提示（negative prompting）的做法剛好相反——不只描述你想要什麼，更明確列出你不要什麼,直接把模型最常見的預設做法排除掉，逼它產出更接近正式產品標準的結果。
有記錄的實測案例是這樣的：同一個「設定頁面」的生成需求,在沒有任何排除條件的情況下,產出的結果是行內樣式（inline style）、沒有載入狀態指示、密碼欄位用未加密的方式存在狀態裡、而且不管使用者改了哪個欄位,送出時一律把所有欄位都提交一次。這些問題不是模型「做錯了」,而是模型從訓練資料裡學到的「這類頁面通常長這樣」的預設模式——這些模式在教學範例裡很常見，但不是正式產品該有的做法。
同一個需求，加上五條具體的排除條件之後，產出結果出現明顯差異。這五條分別是：「不要把認證 Token 存在 localStorage 裡」（改用 httpOnly cookie，避免 XSS 攻擊風險）；「TypeScript 裡不要用 any 型別」（改用正確的泛型與聯合型別，讓型別檢查真正發揮作用）；「不要加行內樣式」（改用 Tailwind 或 CSS modules，提升可維護性）；「除非必要不要新增檔案」（優先修改既有檔案，避免檔案結構碎片化）；「測試裡不要模擬資料庫」（改用真實的測試資料庫做整合測試,才能抓到真實的錯誤）。加上這五條之後，同一個設定頁面的生成結果變成：使用 Tailwind 的樣式類別、有讀取狀態指示器、密碼欄位會被清空、只追蹤真正被修改過的欄位、並且有適當的錯誤處理。記錄者的描述是「同一個功能，實作品質差了一個檔次」。
負向提示的概念最早、也最廣為人知的應用場景是圖像生成——明確排除常見的視覺缺陷（例如多出來的手指、扭曲變形的手部、畫面裡出現不該有的文字疊加），能直接提升生成圖像的品質。這個邏輯放到設計工具的視覺輸出上同樣適用——如果你已經注意到某個 AI 設計工具生成的介面反覆出現某種特定的視覺瑕疵（例如按鈕陰影過重、圖示風格不一致），直接把這個瑕疵寫進排除條件,比持續微調正向描述的形容詞更直接有效。
公開資料對這個技巧也給出一個重要的提醒：負向提示的本質是把模型從「常見但有風險的預設做法」引導開,改用更接近正式標準的模式,但它不能取代上游的安全或品質控管機制。換句話說，負向提示提升的是生成結果「一開始就比較對」的機率,但不代表加了幾條排除條件之後,就可以完全省略後續的人工檢查——這跟前面討論過的 AI 設計幻覺是同一個邏輯：生成品質提升,不等於不需要驗證。
如果你目前用 AI 設計工具時，常常對著生成結果裡某個反覆出現的小毛病感到厭煩——行內樣式太多、某種版面模式你根本不想用、某個視覺風格老是跑出來——與其每次都用正向描述試圖「導向」另一個方向，直接把這個毛病寫成一條明確的排除條件,通常更快看到效果。具體做法是為你常用的生成任務建立一份「固定排除清單」（例如「不要用純白背景」「不要用置中對齊的大標題」「不要省略 hover 狀態」），每次生成前直接貼上這份清單,而不是每次重新想一輪正向描述該怎麼寫。