GPT-5.6 Sol 網頁設計教學：用 Codex 做出電影感 Landing Page

很多人用 AI 做網站，第一版看起來都很像：藍紫漸層、大圓角卡片、每區三欄，文案也像同一個模板換了公司名稱。

問題不完全是模型審美不夠好，而是使用者只給了「幫我做一個有科技感的網站」，卻沒有提供視覺方向、內容層級與驗收標準。

設計師 Viktor Oddy 在一支 21 分鐘的 GPT-5.6 Sol 網頁實作影片中，示範如何先找參考、製作背景素材，再用 Codex 分段建立 Hero section、其他頁面與影片動效。Hero section 是訪客打開網站後第一眼看到的主視覺區，通常包含標題、說明與主要行動按鈕。

看完整段示範後，我的結論是：GPT-5.6 Sol 值得拿來快速製作高視覺的一頁式網站，但成品好不好，關鍵不在一條「神 Prompt」，而在參考素材、模組拆分與驗收迴圈。

Landing Page 是以單一轉換目標為核心的行銷頁。這套方法適合品牌活動頁、作品集、產品發表與概念驗證。若要做會員系統、結帳流程或長期營運的企業官網，仍要補上內容、效能、無障礙、安全與跨裝置測試，不能看完桌機預覽就直接上線。

這支影片真正值得學的是什麼？

原始貼文將重點整理為審美注入、模組解耦與互動調優。這個方向沒有錯，但看完原片後，最值得複製的其實是以下工作順序：

1. 不要求 AI 憑空發揮，先用不同參考圖分別定義版面、圖形與色彩。
2. 先做 Hero section，不讓 AI 一次生成整個網站。
3. 把文字、按鈕與背景素材分開，讓每一層都能獨立修改。
4. 首屏成立後，再擴充服務、案例、流程、見證與 CTA。
5. 動效失敗時，描述具體行為與技術限制，不只說「再順一點」。

CTA 是 Call to Action 的縮寫，指希望訪客完成的主要行動，例如預約諮詢、查看作品或開始試用。

影片也有幾個不能直接照抄的地方。示範使用的是暫時文案與生成素材，沒有完整測試載入速度、鍵盤操作、搜尋引擎內容與瀏覽器相容性。片中為了讓影片正播後倒播，曾把影格存進 Canvas；Canvas 是瀏覽器中可用 JavaScript 逐格繪圖的畫布。這種做法雖然能消除接縫，卻可能增加記憶體與處理負擔，正式網站有更簡單的做法，後文會說明。

開始前要準備什麼？

1. Codex 與 GPT-5.6 Sol

Codex 是能讀取專案檔案、修改程式並執行測試的 coding agent。依 OpenAI 官方說明，GPT-5.6 Sol 可在符合資格的 Codex 方案中使用；若模型選單沒有出現，先確認帳號方案與應用程式版本。

OpenAI 的 GPT-5.6 發表資料將 Sol 定位為旗艦模型，也提供更高推理強度與 ultra 模式。實作一般 Landing Page 時，建議先從 medium 開始。只有在任務同時包含多頁、素材處理、複雜動畫與完整測試時，再提高推理強度。這樣比較節省使用額度，修改速度也更快。

2. 一個獨立的專案資料夾

不要把第一次測試直接放進公司主網站。先建立一個獨立資料夾，放入參考圖、字型說明、影片與文案。若已有 React、Next.js 或其他前端專案，就要求 Codex 沿用現有技術與元件；若只是做概念頁，使用單純的 HTML、CSS 與 JavaScript 會比較容易理解和維護。

3. 三種用途不同的參考素材

影片作者從 Pinterest、Seesaw 與 Land-book 尋找靈感，再分別挑出版面、抽象圓環與主色。這比丟給 AI 一張完整網站截圖更容易控制，因為每張圖只有一個角色。

建議準備：

參考不等於照抄。不要沿用別人的 Logo、照片、插畫、文案與完整構圖。正式商用素材應確認授權，字型也要檢查網站嵌入與商業使用條款。

GPT-5.6 Sol 網頁設計教學：從參考圖到可預覽網站

步驟一：先寫一頁視覺 Brief，不急著寫程式

Brief 是交代目標、受眾、內容與限制的工作說明。很多 AI 網頁的廉價感，不是 CSS 寫得差，而是模型不知道品牌是誰、訪客來做什麼，也不知道哪些設計不能出現。

可以先用以下格式整理：

網站目的：讓潛在客戶在 30 秒內理解服務，並預約諮詢。
目標使用者：正在找網頁設計團隊的中小企業主。
主要 CTA：查看作品；次要 CTA：預約通話。

視覺方向：
- 純黑背景，主色為 #35F28B。
- 大標題使用高對比無襯線字體。
- 參考圖 1 只用於首屏資訊層級。
- 參考圖 2 只用於左右兩側的金屬圓環造型。
- 不使用常見的藍紫漸層、發光球與三欄 SaaS 卡片。

內容限制：
- 不虛構客戶名稱、數字、見證與得獎紀錄。
- 沒有真實資料的位置先使用明確 placeholder。

技術限制：
- 支援 390 px mobile 與 1440 px desktop。
- 背景影片失敗時仍要顯示 poster 圖。
- 尊重 prefers-reduced-motion。

prefers-reduced-motion 是瀏覽器用來判斷使用者是否希望減少非必要動畫的設定。先把這些條件寫進 Brief，Codex 才不會把「看起來會動」當成唯一成功標準。

步驟二：把背景圖與介面文字分開

影片先用生成工具做出主視覺，再要求移除文字、按鈕與 Logo，只保留同一構圖的背景。這一步很重要，因為網頁上的標題與按鈕應該是真正的 HTML 內容，才能被搜尋、選取、翻譯，也能在手機上重新排版。

如果把文字直接燒在圖片或影片裡，後續改文案、做響應式版面或調整對比都會變得很麻煩。響應式網頁設計（Responsive Web Design）是讓同一頁面能依螢幕寬度調整排列方式，而不是把桌機畫面等比例縮小。

產生背景素材時，可以這樣寫：

以附件作為構圖參考，產生相同比例的純背景素材。
保留左右兩側的金屬圓環、黑色背景與綠色光線。
移除所有文字、按鈕、Logo、導覽列與介面元件。
不要改變鏡頭位置，不要放大或裁切主體。
中央保留足夠負空間，讓網頁標題可以疊在上方。

負空間是刻意保留的空白區域，功能不是浪費版面，而是讓標題與主要操作更容易被看見。

步驟三：只要求 Codex 建立 Hero section

把背景圖、色碼與字型資料放進專案後，先建立 Hero section。不要在第一個 Prompt 同時要求首頁、關於我們、價目表、動畫與部署。資料還沒準備好的位置，可以使用 placeholder，也就是清楚標示用途的暫位內容。

請先閱讀專案內容，再只建立首頁的 Hero section，不要製作其他區塊或頁面。

目標：訪客在 5 秒內理解這是一家網頁設計公司，並看見主要 CTA。

版面：
- 參考附件的資訊層級，但不要複製原品牌、文案或圖形。
- 純黑背景，強調色使用 #35F28B。
- 桌機版讓裝飾圖形位於左右兩側，標題與 CTA 保持在中央可讀區。
- mobile 版重新排列，不要只縮小桌機畫面。

內容：
- 標題：Web Design That Performs
- 說明：一句話交代服務與商業價值。
- 主要 CTA：View Our Work
- 次要 CTA：Book a Call

技術：
- 沿用現有專案技術，不要為一個區塊更換 framework（前端開發框架）。
- 使用語意化 HTML，保留鍵盤可見的 focus 狀態，也就是目前用鍵盤選到元件時的外框提示。
- 完成後開啟預覽，回報修改檔案與尚未處理的項目。

這種 Prompt 的重點不是很長，而是範圍只有一個區塊，而且成功條件能被檢查。第一版完成後，先看資訊層級、文字對比與手機排列，再進到背景影片。

步驟四：加入背景影片，但先準備靜態備援

影片中的做法是把生成影片設為全版背景，並要求不要加黑色遮罩。正式網站不能只看視覺效果，還要考慮自動播放限制與網路速度。

MDN 的 HTML video 文件指出，現代瀏覽器通常會阻擋有聲影片自動播放。背景影片至少要使用 muted 與 playsinline，並提供 poster 靜態圖。poster 是影片還沒播放或載入失敗時顯示的預覽圖片。

可以要求 Codex：

把 assets/hero-video.mp4 加入 Hero section 作為背景影片。

要求：
- 使用 autoplay、muted、loop、playsinline。
- 設定 poster 為 assets/hero-poster.webp。
- 影片使用 object-fit: cover，但不得遮住標題與 CTA。
- 若 autoplay 失敗，保留 poster，不顯示空白背景。
- 不預設加入黑色 overlay（覆蓋在影片上方的遮罩）；若文字對比不足，先調整文字區位置或局部漸層。
- prefers-reduced-motion: reduce 時不要自動播放，改顯示 poster。
- mobile 版若影片造成明顯效能負擔，優先使用靜態圖。

影片放在首屏時會直接影響載入速度。依 web.dev 的影片效能指南，非首屏影片可延後載入；首屏背景影片則應壓縮檔案、提供尺寸合適的 poster，並避免同時預載不必要的資源。

步驟五：首屏通過後，再擴充其他區塊

Hero section 成立後，才讓 Codex 增加服務、案例與流程。影片中的 Prompt 只要求「再做四到五個區塊」，模型雖然產生了可看的版面，卻也填入了暫時文案與卡片。教學照做可以，正式專案則要先決定每個區塊的用途。

在現有 Hero section 下方新增 5 個區塊，不要改動已通過的 Hero。

區塊順序與目的：
1. About：用 80 至 120 字交代服務定位。
2. Capabilities：整理 3 項真實服務，不增加不存在的能力。
3. Portfolio：建立 3 張案例卡，資料不足時標示 placeholder，不虛構客戶。
4. Process：用 4 步驟說明合作流程。
5. Final CTA：引導訪客預約通話。

設計要求：
- 沿用現有色彩、字體、圓角與間距規則。
- 每個區塊要有不同資訊結構，不要全部做成三欄卡片。
- 動畫只用於解釋層級或回應操作，不要讓所有元素同時漂浮。
- 完成後檢查 390 px、768 px、1024 px 與 1440 px。

這裡用到的色彩、字體、圓角與間距規則，可以整理成 design token，也就是讓整個網站共用的設計變數。把它們集中管理，比每次叫 AI「維持一致」更可靠。

步驟六：用 mix-blend-mode 處理素材底色

影片有一個實用技巧：素材的黑底與網頁黑底不完全相同時，可以嘗試 CSS 的 mix-blend-mode: exclusion。mix-blend-mode 是讓元素與後方內容依指定方式混色的 CSS 屬性，MDN 文件也列出 exclusion、screen、multiply 等模式。

不過，混色不是去背工具。它的結果會隨後方顏色改變，也可能讓品牌色失真。更穩定的順序是：

1. 先輸出透明背景的 WebM 或圖片序列。
2. 無法輸出透明素材時，讓素材背景色與網頁使用相同色碼。
3. 仍有邊界時，再測試 mix-blend-mode。
4. 在 Chrome、Safari 與手機上逐一檢查，不要只看單一預覽。

給 Codex 的指令也要保留回退條件：

先嘗試 mix-blend-mode: exclusion，讓素材黑底融入目前背景。
如果綠色高光或文字對比明顯失真，撤回混色，改用未混色版本。
請分別截取 desktop 與 mobile 畫面比較，回報採用哪個版本與原因。

步驟七：需要正播倒播時，先在素材端處理

影片中最耗時間的問題，是背景影片播完後跳回第一幀。作者最後要求 Codex 把影片影格存進離屏 Canvas，再用 JavaScript 逐格正播與倒播。它能做出平順的 boomerang playback，也就是正播後倒播的乒乓循環，但不適合直接當成所有網站的預設方案。

原因很簡單：瀏覽器要先解碼並保存大量影格，長影片或高解析度素材可能消耗很多記憶體。更容易維護的方式，是在素材製作階段就輸出「正播＋倒播」的影片，前端只負責一般 loop。

如果電腦已安裝 FFmpeg，可以請 Codex 產生並執行以下指令：

ffmpeg -i hero.mp4 \
  -filter_complex "[0:v]split[forward][copy];[copy]reverse[backward];[forward][backward]concat=n=2:v=1:a=0,format=yuv420p[v]" \
  -map "[v]" -an -movflags +faststart hero-boomerang.mp4

FFmpeg 官方文件提供 reverse 與 concat filter，可先反轉影像再接回原片。素材很長時，反轉處理本身也需要較多記憶體，因此背景循環最好維持短秒數，並在接點附近裁掉重複影格。

若只是裝飾性的小動畫，還有一個更簡單的答案：接受一般循環，或改用 CSS 動畫。不是每個畫面都值得為了無接縫而增加程式複雜度。

步驟八：讓 Codex 做一次「找問題」，不要只叫它美化

第一版完成後，不要繼續輸入「更高級」、「更有電影感」。這些指令缺少判斷標準，容易讓 AI 堆疊更多模糊、發光與動畫。

改用驗收 Prompt：

先不要修改程式。請檢查目前 Landing Page，分成下列五類列出問題與證據：

1. 內容：是否有虛構數字、客戶、見證、案例或空泛文案。
2. UX：主要 CTA 是否清楚，導覽、按鈕與連結是否可用。
3. Responsive（響應式）：390 px、768 px、1024 px、1440 px 是否溢出、裁切或遮擋。
4. Accessibility（無障礙）：鍵盤 focus、色彩對比、替代文字、reduced motion 與動畫暫停方式。
5. Performance：影片大小、首屏載入、未壓縮圖片與不必要的 JavaScript。

每個問題請提供檔案位置、嚴重度與最小修改方案。等我確認後再改。

這一步能把 AI 從「繼續加效果」切換成「依證據修問題」。對 PM 來說，也比較容易決定哪些項目是 MVP 必修、哪些可以延後。MVP 是最小可行產品，目標是先交付能驗證需求的必要範圍。

正式上線前的 10 項驗收清單

影片最後短暫展示了桌機與 mobile 預覽，但響應式畫面看起來正常，不代表網站已經可以上線。至少要完成以下檢查：

• 首頁只有一個最主要的 CTA，其他按鈕不搶層級。
• 所有案例、客戶、數字與見證都是真實內容。
• 導覽、按鈕、表單與返回路徑可以實際操作。
• 390 px、768 px、1024 px、1440 px 沒有水平捲動與文字遮擋。
• 鍵盤可以走完主要流程，focus 樣式清楚可見。
• 自動播放超過 5 秒的裝飾動畫可暫停、停止或隱藏。
• 系統設定減少動態效果時，頁面改用靜態圖或較弱動畫。
• 背景影片有 poster、壓縮版本與播放失敗備援。
• Chrome、Safari、Firefox 與至少一台實體手機完成檢查。
• Lighthouse 與真實裝置測試沒有明顯效能阻斷。Lighthouse 是 Chrome 內建的網站品質檢查工具。

WCAG 2.2 對移動內容的說明要求，與其他內容同時呈現、會自動開始且持續超過 5 秒的移動內容，應提供暫停、停止或隱藏機制。prefers-reduced-motion 也能依使用者裝置設定降低動畫，MDN 有完整用法。

效能則不能只看自己電腦載入有多快。Google 的 Core Web Vitals用 LCP、INP 與 CLS 衡量實際體驗。LCP 是主要內容出現速度，INP 是操作後的回應時間，CLS 是載入過程中版面意外位移的程度。電影感網站若犧牲這三項，視覺效果反而可能降低轉換。

常見失敗：為什麼 Prompt 寫很長，網站還是有 AI 味？

只寫風格形容詞，沒有可執行規則

「高級、科技、電影感」每個人理解不同。改成色碼、字體、元素位置、動效時長、禁止樣式與參考圖角色，模型才知道要做什麼。

一次生成整站，再用更多 Prompt 修補

整站一起做的問題不是程式行數，而是你無法判斷錯誤從哪裡開始。先確認 Hero，再增加下一個區塊，修改範圍小，回復也比較容易。

把參考網站當成可以直接複製的模板

參考圖應該用來拆出規則，不是複製品牌資產。比較安全的做法，是從三個以上來源分別取得資訊層級、色彩與動效靈感，再用自己的文案與素材重新組合。

首頁很漂亮，但沒有真實內容

AI 能快速產生看似完整的作品集與見證，這也是最危險的地方。只要內容不是使用者提供或來源可驗證，就應保留 placeholder，不能把它包裝成真實客戶案例。

把「預覽正常」誤認為「可以正式上線」

預覽只證明頁面在當下環境能打開。正式網站還需要表單、SEO（搜尋引擎最佳化）、流量分析、隱私政策、素材權利、效能、安全與持續維護。若這些都沒有驗收，成品仍是 Prototype，也就是供討論與測試的原型。

GPT-5.6 Sol 做網站值得嗎？

我的立場是中性偏多。

對 Landing Page、活動頁與作品集來說，這套流程值得用。GPT-5.6 Sol 能根據參考圖快速建立版面、延續視覺規則，也能在同一個專案裡修改程式與檢查預覽。它最直接的價值，是縮短「看見方向」與「做出可操作首版」之間的時間。

但我不接受「從零生成後就能直接上線」的說法。影片最強的是視覺探索，最弱的是正式交付證據。沒有真實文案、效能數據、無障礙與跨瀏覽器測試，就還不能等同設計公司完成的商業網站。

真正該追蹤的不是第一版有多驚豔，而是三個數字：完成一個可用頁面需要幾輪修改、最後有多少程式要人工重寫，以及通過 mobile、效能與內容驗收花了多久。若連續三個專案都能降低這些成本，這套流程才算真的進入生產環境。

GPT-5.6 Sol 網頁設計常見問題

不會寫程式，也能跟著做嗎？

可以先做單頁 Prototype，但仍要看得懂 Codex 改了哪些檔案，並學會檢查預覽、按鈕、手機版與錯誤訊息。若網站包含付款、登入、會員資料或後台權限，應找工程師 Review，不適合只靠視覺結果判斷。

一定要使用 GPT-5.6 Sol ultra 嗎？

不需要。單一 Hero section 或小範圍版面修改先用 medium，通常更快也更省額度。只有任務包含多頁、複雜互動、素材處理與完整測試時，才值得提高推理強度或使用 ultra。

可以直接丟一個喜歡的網站叫 Codex 複製嗎？

技術上能提供截圖作為參考，但不應複製原網站的品牌、文案、圖片、插畫與完整視覺。把參考拆成版面、色彩、字體與動效規則，再重新套用自己的內容，成果也比較不容易像低品質仿站。

背景影片一定要用 AI 生成嗎？

不用。品牌現有影片、3D 動畫、合法素材庫影片或 CSS 動畫都能使用。若只需要簡單光線與幾何移動，CSS 通常比高解析度影片更輕，也更容易配合 reduced motion。

要選 React，還是單純 HTML、CSS、JavaScript？

若已有產品專案，就沿用現有 framework 與元件庫。只做一頁式概念頁時，HTML、CSS、JavaScript 最容易部署與維護。不要因為 AI 會寫 React，就為一個靜態頁面增加不必要的架構。

Codex 做完後，怎麼判斷是不是「電影感」？

不要把電影感當成單一評分。可以檢查視覺焦點是否清楚、畫面是否有節奏、動效有沒有服務內容，以及使用者能否順利完成主要 CTA。若動畫讓文字難讀、載入變慢或操作被遮住，再漂亮也不是好的商業網站。

結論：把 GPT-5.6 Sol 當成製作團隊，不是靈感抽卡機

這支 21 分鐘影片最值得學的，不是一條神奇 Prompt，而是一個務實的製作順序：先定方向、拆素材、只做首屏、逐區擴充，再針對具體問題修改。

GPT-5.6 Sol 能把設計想法更快變成可操作的網頁，但它不會替你決定品牌定位、內容真假與商業目標。最實際的用法，是先拿一個非核心 Landing Page 跑完「參考板 → Hero → 內容區塊 → 動效 → mobile → 效能與無障礙驗收」。

如果完成後，頁面不只看起來漂亮，也能快速載入、清楚導流並通過真實裝置測試，這套流程才算成功。

資料來源

• AYi：GPT-5.6 Sol 網頁教學中文整理貼文
• Viktor Oddy：How To Build Premium, Cinematic Websites with GPT-5.6 Sol
• OpenAI：GPT-5.6 發表與模型定位
• OpenAI Help Center：GPT-5.6 in ChatGPT
• OpenAI Help Center：ChatGPT Work and Codex
• MDN：HTML video element
• MDN：mix-blend-mode
• MDN：prefers-reduced-motion
• W3C WAI：WCAG 2.2 Pause, Stop, Hide
• web.dev：Video performance
• web.dev：Core Web Vitals
• FFmpeg Filters Documentation