AI 編程工具越來越強，為什麼寫出來的網站還是不好看？從 AI 程式碼生成到 UI 設計的完整解決方案

W3C 的 WCAG 2.2 指出，一般文字與背景的對比度至少要達到 4.5:1，才符合該項最低要求（對比度標準說明）。這個可核對的規格也提醒你：網站能跑，不代表視覺設計已完成。AI 程式碼生成擅長依指令產生程式，卻不會自動替你決定資訊層級、整體風格與設計規則。本週先選一個核心頁面，定下視覺方向，再用截圖逐輪修正；不要只叫 AI「做得更漂亮」。

正在用 AI 編程工具做網站、但對頁面觀感不滿意的開發者，可以從本文定位問題。
沒有專職設計師的獨立創作者，可用具體約束減少反覆試錯。
要交付小型網站或原型的團隊，可把以下流程用作共同驗收依據。

能運作，不等於有清楚的視覺層級

把頁面問題統稱為「AI 審美不好」，通常無法讓下一輪生成更準。更有效的做法，是檢查同一頁面的結構、層級、間距與元件一致性，再判斷是需求、規範還是實作出了問題。

常見落差有幾種：

• 需求描述太模糊。「做一個現代、好看的首頁」沒有交代誰會使用、要完成什麼任務，也沒有說明資訊優先次序。AI 只能自行補全空白，各區塊便可能各自成立，放在一起卻沒有主次。
• 沒有先定視覺方向。缺少參考頁面或具體描述時，字體、色彩、留白與卡片樣式可能各自取自不同慣例。單看某個元件未必突兀，放在同一頁卻容易失去整體感。
• 逐段生成，沒有整頁檢查。先做導覽列、再做首屏、最後補卡片，容易讓不同區塊採用不同的邊距、圓角或標題比例。局部程式碼完成，不代表整體版面已協調。
• 內容太短或是假資料。短句看起來整齊，但換成真實文案後，標題可能換行、卡片高度不一，按鈕也可能被推到不合適的位置。
• 只看桌面畫面。窄螢幕會暴露固定寬度、過長導航、溢出內容與難以點按的控制項；這些問題不會因為桌面版好看而消失。

先看頁面上最重要的任務是否容易找到，再檢查文字、按鈕與區塊是否形成可理解的順序。把「不好看」拆成可以指出位置的問題，才有辦法安排下一步修改。

先確定 UI 設計方向，再要求生成程式

AI 編程工具需要的是可執行的設計決策，而不是一串風格形容詞。開始生成前，先用幾句話說清楚：

• 使用者是誰：例如首次接觸產品的人，還是已知道服務內容、想比較方案的人。
• 頁面的主要任務：讓訪客理解產品、比較選項，或完成註冊；每頁先確定一項主要任務。
• 資訊優先次序：說明首屏必須出現的內容、可以往下放的細節，以及主要行動按鈕。
• 希望呈現的氣質：不要只寫「簡潔」或「專業」。補充具體線索，例如使用低彩度背景、清楚的標題層級、少量強調色，或採用偏編輯式而非卡片堆疊的版面。
• 參考畫面與限制：提供你有權使用的視覺參考，並指出要參考的是欄寬、字體感、留白還是資訊密度；同時說明哪些產品標誌、文案或元件不可更改。

方向是否有效，可以用兩個結果檢查：首屏能不能讓目標使用者理解頁面用途？主要行動是否比次要資訊更容易找到？如果回答不出來，先修正頁面目標，不要急著增加裝飾。

把設計決策變成可重用的規範

設計系統不是把陰影、漸層和圓角放得更多，而是讓不同頁面遵循一套能重複使用的規則。先定義色彩的角色，例如背景、正文、邊框與行動色；再決定標題和內文的字級階層、內容最大寬度、間距規則，以及按鈕、卡片和表單在一般、懸停、焦點與停用狀態下的樣式。

接著把規範寫成 AI 能照做的指令，而不是散落在每次對話中的形容詞。例如：

主要內容沿用同一個欄寬；頁面只使用已定義的文字、背景和行動色；標題、內文與按鈕使用共用元件。保留已核准的字體與間距，只修改指定的首屏排列。

把共用規則放進設計變數或共用元件，能避免每頁各自發明一套值。驗證時，並排檢查不同頁面的同類元件：按鈕高度與文字位置是否一致？標題與內文是否有穩定的層級？卡片是否使用同一套邊框和內距？如果每個頁面都靠複製貼上再手動微調，規範就還沒有真正落實。

無障礙規格也能轉成清楚的檢查條件。除了前述文字對比，WCAG 2.2 的「目標尺寸」最低要求包含 24 × 24 CSS 像素，並設有特定例外（可點按目標尺寸說明）。這不是所有按鈕都要做成同一尺寸，而是提醒你檢查窄螢幕上相鄰控制項是否容易點選。文字對比與點按目標各自檢查，不要用一項合格代替另一項。

用分步流程從 AI 程式碼生成走到完整 UI 設計

第一步：先搭頁面結構草稿

先列出頁面區塊及其用途，例如導覽、首屏、主要內容、證據或常見疑問、行動區。這一輪先確認資訊順序，不追求陰影或動態效果。產出後檢查：每個區塊是否服務於頁面任務？是否有重複或缺少的資訊？

第二步：確認單頁視覺方向

挑一個最能代表產品的頁面，落實字體、色彩、欄寬與留白。先用真實標題和大致完整的文案，否則短暫佔位文字可能掩蓋換行與密度問題。截圖確認首屏主次與主要按鈕位置後，再推廣到其他頁面。

第三步：實作共用元件

讓導覽、按鈕、卡片和表單沿用已確認的元件與樣式。每次請 AI 修改時，指出要改的元件、要保留的規則，以及完成後要檢查的畫面位置。避免同時要求「換字體、重排版、加動畫、改色彩」，否則難以判斷哪項改動造成結果變化。

第四步：填入真實內容

用產品實際文案、清單與按鈕文字取代佔位內容。檢查長標題是否打亂層級，卡片高度是否因文字長短失衡，行動文字是否清楚說明後續動作。若內容本身冗長或含糊，先處理內容，不要一味縮小字體來塞進版面。

第五步：處理響應式版面

以實際視窗寬度測試欄位變化、導覽收納、圖片裁切與文字換行。MDN 說明，CSS 媒體查詢可依裝置特徵或顯示環境套用不同樣式（媒體查詢指南）。據此設定版面調整條件，而不是只把桌面版等比例縮小。

第六步：逐輪截圖與回饋

每輪挑一個主要問題，把修改目標寫成可以比對的指令。例如：「首屏主標題與副標題左緣對齊，主按鈕跟隨文案，不改變已核准的字體與色彩。」修改前後用相同視窗截圖；如果目標沒有改善，就縮窄要求或撤回該輪變更。

用截圖和標準檢查，而不是只憑「更高級」

截圖是讓你和 AI 對準同一個問題的工具。回饋時避免「整體更精緻」這類無法核實的要求，改成說明哪裡不對、要改成什麼、哪些部分不能動。例如，指出卡片標題沒有對齊、內文與按鈕距離不穩定，並要求沿用既有間距規則修正。

逐項檢查時，可從視覺到操作依序看：

• 層級：首屏主標題、說明文字和主要行動是否能一眼區分？
• 對齊與留白：同類元件是否共用起點？區塊間距有沒有忽大忽小？
• 文字與顏色：文字是否清楚易讀？對比度問題是否有具體數值可核對？
• 內容密度：真實文案放入後，是否出現擁擠、孤立短行或卡片高度不穩？
• 互動狀態：鍵盤操作時焦點是否看得見？W3C 有說明可見焦點的判斷原則（焦點可見性說明）。
• 動態效果：若頁面有動畫，是否尊重使用者的減少動態效果設定？MDN 說明可透過 prefers-reduced-motion 偵測這項偏好（減少動態效果設定）。

文字間距也要用真實內容驗證。WCAG 的文字間距說明列出相關測試條件，包括行高至少為字體大小的 1.5 倍、段落後間距至少為字體大小的 2 倍，以及字母間距與字詞間距要求（文字間距說明）。這些條件適合用來檢查文字放大或間距改變時是否被裁切，不是要求每個頁面都固定套用同一種排版。

上線前逐項勾選驗收

• [ ] 核心頁面的標題、主要內容和行動順序符合頁面目標。
• [ ] 共用按鈕、卡片、表單遵循同一套字體、色彩與間距規範。
• [ ] 以真實文案檢查標題換行、內容溢出與卡片高度。
• [ ] 在桌面與窄螢幕檢查導覽、欄位、圖片裁切與主要操作。
• [ ] 用鍵盤走一次主要任務路徑，確認焦點狀態可見、操作順序合理。
• [ ] 檢查可點按目標與文字對比，不以主觀觀感代替標準核對。
• [ ] 對照修改前後截圖，確認每輪指定的問題確實改善。
• [ ] 完成一次頁面任務測試：目標使用者能否找到資訊並完成主要操作？

響應式驗收不能只看頁面是否縮小。WCAG 的重排要求說明，在相當於 320 CSS 像素寬度的呈現條件下，內容應能重排而不需要同時向兩個方向捲動（重排要求）。用這項條件檢查主要內容是否溢出，比單純比較桌面截圖更能發現窄版問題。

若你還打算把 AI Agent 放進遠端 Mac 開發流程，可先閱讀本站的 OpenClaw 相關說明，再判斷是否符合你的工具與作業方式。

常見問題

為什麼功能正常，視覺效果還是不好？

程式能執行，只表示功能路徑大致可用；它不會自動替你整理資訊層級與版面一致性。先檢查首屏是否突出主要任務，再逐項查看字級、對齊、間距和元件樣式。把問題描述成能指出位置、能比對前後的改動，下一輪才有明確方向。

怎樣讓不同頁面的版面和字體更統一？

先定義共用的字體層級、色彩角色、間距與內容欄寬，再讓各頁面使用同一組元件或設計變數。不要只在每次提示中重複「保持一致」。生成後並排比較同類元件，若按鈕、卡片或標題各有不同規則，就回到共用元件修正。

怎麼把 UI 設計要求寫成可執行提示？

說清楚頁面要服務的使用者、首屏要先呈現什麼、主要按鈕放在哪裡，以及哪些視覺規則必須保留。將「更現代」等抽象要求改寫成版面、字體、顏色與對齊條件。每輪聚焦一個主要修改目標，並先說明完成後如何核對。

截圖回饋怎樣讓 AI 一輪輪改好介面？

用相同視窗尺寸的前後截圖，指出一個具體問題和預期變化，例如標題與按鈕未對齊、卡片間距不一致。要求只修改相關區域，保留已核准的規則。比對結果後再安排下一輪；若目標沒改善，就縮小修改範圍，而不是追加更多互相衝突的要求。

把下一步放在你真正需要的開發環境上

如果目前一直在「改提示、重生頁面、再手動補救」，問題可能不只在生成能力：設計規則仍靠口頭傳達、截圖缺乏一致對照，或本機環境不足以完成所需的裝置檢查。這些情況下，租用 Mac 不會自動讓 UI 變好，但在你確實需要遠端 Mac 開發或測試時，可以少一項自購硬體的前期負擔；若你長期高頻使用、需要實體介面，或現有設備已足夠，租用未必是合適選擇。

先用上方清單完成一個關鍵頁面的設計約束、截圖回饋和多尺寸驗收。若接下來確實需要遠端 Mac 環境，可先了解 Hashvps 的服務背景與定位，再判斷相關環境是否符合你的開發流程。