從 Sitemap 到正式產品：我的 AI 協作官網工作流程

2026年8月27日閱讀約 12 分鐘

設計到程式Next.jsSEO無障礙設計

我會用真正能操作的網站，確認完成的設計稿還沒辦法回答的問題。Ogloba 官網 prototype，就是我把 sitemap、Figma、AI 協作規則、React 元件、動畫、多語系和品質驗證串起來的實例。

這篇展示的是我參與製作、仍在進行中的公司官網 prototype，不代表最終官網或 WordPress 版本已經上線。截圖中的公司、客戶標誌與數字屬於 prototype 內容，不是我的個人成效數據。

開啟可操作的官網 Prototype（另開分頁）

桌機首頁的中央標題、兩個主要操作、品牌列與產品輪播 — 桌機版透過標題、主要操作與產品預覽建立瀏覽順序。

手機首頁將操作上下排列，並突出一張產品輪播卡片 — 手機版重新安排相同內容，不是把桌機版等比例縮小。

我的流程不是從寫 code 開始

Figma 完稿之後，還是有很多問題需要確認。桌機和手機之間的尺寸怎麼變化？法文標題變長之後還放得下嗎？背景動畫是在幫助訊息，還是增加等待時間？我建立這套流程，就是想在決定最終落地方式之前，先把這些事情做成能測試的介面。

先定義 sitemap釐清產品方案、資源、公司資訊和聯絡入口之間的關係。重複出現的頁面類型，也能在這個階段找出共用版型的機會。
完成 Figma 設計定義資訊層級、視覺 tokens、元件狀態，以及桌機和手機的設計意圖。Figma 是實作的依據，不是要 AI 自行發揮的模糊提示。
建立 AI workflow 與專案 skills說清楚要先讀哪些檔案、怎麼重用元件、哪些地方不能隨意修改，以及怎樣才算驗證完成。每個頁面的 brief 再補上內容、互動和情境。
做成 Next.js prototype讓設計在瀏覽器裡有真實的內容、導覽與動畫。這是一個驗證環境，不是生成完就自動變成 production。
邊做邊檢查比對設計與實作，測試斷點之間的尺寸、多語系和操作狀態。遇到重複問題，就回頭修改共用元件或專案規則。

React 專案怎麼搭起來

React 負責 UI，Next.js 則提供路由、rendering 和 metadata 等框架能力。這個 prototype 的套件設定使用 Next.js 15、React 19 和 TypeScript。這是在描述專案背景，不是建議新專案安裝舊版本。

如果要建立類似的小型專案，我會從目前的 Next.js scaffold 開始，再依介面需求加入 library。下面是可參考的起點，不是公司 private repo 的複製版本。

npx create-next-app@latest workflow-demo --ts --eslint --tailwind --app --src-dir --use-npm
cd workflow-demo
npm install next-intl framer-motion embla-carousel-react @radix-ui/react-accordion
npm install --save-dev @playwright/test vitest
npm run dev

裝完套件只是第一步。接下來還要設定 locale 路由、訊息載入、design tokens 和測試指令。我會依照實際安裝版本的文件調整，並把 lockfile 一起納入版本控制。

Next.js 建置文件、next-intl 路由文件

Next.js + TypeScript: 用頁面路由、metadata 與型別清楚的元件介面，讓實作可以被檢查和維護。
Tailwind CSS: 共用間距、字級和顏色規則，讓重複區塊維持一致。
next-intl: 管理語系路由，並把翻譯內容從元件 markup 中分開。
Framer Motion: 控制時間、transform 和 reduced motion，支援圖片立體效果與輪替標題。
Embla Carousel: 提供響應式輪播基礎，再補上明確的導覽與暫停行為。
Radix primitives: 提供 accordion 和 navigation 的互動基礎。標籤、focus 與視覺品質仍然需要自己確認。
Vitest + Playwright: 分別處理單元規則與瀏覽器回歸驗證，不能用其中一種取代所有檢查。

元件拆分要對應內容責任

首頁由 Hero、LogoCloud、HeroImage、WhyChoose、ReelsSection、FAQ 和 FinalCTA 等區塊組成。重點不是拆出很多檔案，而是每一塊都有明確的內容、狀態和 RWD 責任。底層 Button 或動畫 helper 才能真正共用，不用為了另一個頁面整份複製。

<PageShell>
  <Hero />
  <LogoCloud />
  <HeroImage />
  <WhyChoose />
  <ReelsSection />
  <FAQ />
  <FinalCTA />
</PageShell>

下面是簡化的組合示意，不是 private source code。兩張截圖分別呈現共用區塊與產品頁版型，比起每一頁各做一套，更能說明系統的重用方式。

左右兩欄可展開的平台功能說明與中央地球標誌 — 04 · 透過漸進揭露，讓複雜的平台資訊更容易掃讀。

Gift Card Programs 頁面，含圖片組合、麵包屑與側邊導覽 — 16 · 共用產品頁的資訊結構，搭配個別產品的素材。

動畫也是實作方式的選擇

把影片概念換成程式水波紋

原本的圓波點概念需要載入影片。我後來改成在靜態圖片上做 WebGL 水波紋，讓波紋能回應游標，同時不需要下載那支裝飾性影片。目前的 helper 會限制同時存在的波紋數量，離開可視範圍就暫停渲染。沒有 WebGL，或使用者要求減少動態時，仍然有靜態圖片可以呈現。

這個選擇是把影片傳輸和解碼，換成裝置上的 shader 運算，不代表效能成本消失了。我仍然要檢查 GPU 負擔、圖片載入和較低效能的裝置。目前沒有足夠的比較數據，所以不會宣稱載入速度提升了幾個百分比。

用圖片和 code 做出立體感

WhyChoose 使用同一張處理好的卡片圖片，搭配多層低透明度影像。旋轉、透視、透明度和錯開的時間，讓它在瀏覽器裡形成厚度與立體感。調整動畫時，不需要重新輸出一支影片，標題和操作也能保持穩定。開啟 reduced motion 時，額外殘影與持續旋轉會取消。

Why Choose Ogloba 標題後方的半透明旋轉卡片 — 09 · 圖片搭配程式形成的立體感，旋轉狀態 A。

同一張半透明卡片轉向接近垂直的角度 — 10 · 同一張素材的立體旋轉狀態 B。

半透明卡片斜向旋轉，前方標題與操作維持不動 — 11 · 旋轉狀態 C。內容保持穩定，不跟著背景移動。

客製 cursor 不能成為操作門檻

CTA 的游標提示只出現在被標記的操作上，不是整個網站每個位置都跟著動。只有精準游標裝置，而且沒有要求減少動態時，才會啟用。原生游標也只會在替代提示可用時隱藏。到了觸控裝置，同一個操作就是正常可用的連結，不靠裝飾才知道怎麼使用。

CTA 按鈕旁的圓環與 Go Ogloba 游標提示 — 15 · 客製 cursor 是額外回饋，不是使用操作的必要條件。

多語系會改變版型的條件

這個 prototype 目前實作英文、法文、西班牙文、繁體中文和簡體中文。我把訊息與元件分開，使用真實文字檢查換行、文字密度、導覽寬度與按鈕標籤。只有短英文能放得下的版型，還不能算是可重用的版型。Arabic 和 RTL 在這個專案屬於後續範圍，不會列成這次已完成的成果。

我怎麼把 SEO 放進結構裡

我把搜尋結果和分享時的呈現，也視為資訊架構的一部分。如果 crawler 不清楚頁面的語系、正式網址或發布狀態，畫面做完還不算完成。

每個語系都有明確的頁面身分

共用 metadata builder 用 locale 加上頁面路徑，產生各自的 canonical 和對應 hreflang，並以英文作為 x-default。這樣不用每個頁面各自維護語言連結清單。正式網域另外設定，部署時仍然要確認 hostname 和是否允許索引。

分享資訊跟著同一個頁面走

標題、描述和社群網址使用同一份頁面資料。Open Graph 的語系代碼另外對應成 en_US、zh_TW 等格式，不把路由代碼直接當成社群格式。分享卡片描述的內容，要和使用者點進去的頁面一致。

動畫不能取代語意結構

Hero 的視覺文字會輪替，但仍保留穩定的語意標題。資源頁使用真正的章節 heading，麵包屑則依照命名過的路由層級產生 BreadcrumbList 結構化資料，而不是只放一張看起來像導覽的圖片。

是否發布，也要反映在索引規則

尚未完成審查的法律草稿使用 noindex，也不列入 sitemap。Sitemap 依支援的語系展開，使用明確的內容日期，不把每次 request 都當成內容剛更新。這些是發布管理的決策，不是排名保證。Robots 和 noindex 也不能拿來保護機密內容。

專案有針對 canonical、語言替代連結、麵包屑位置和 sitemap 的單元檢查。我仍然會看實際 render 出來的 metadata 與部署網域。測試通過，不能代替是否適合公開的判斷。

Benefits Guide 的主視覺、章節目錄與長文內容 — 18 · 資源文章需要適合閱讀的版型，不能直接複製行銷頁。

Benefits Guide 的持續可見目錄、章節標題與 PDF 連結 — 19 · 章節導覽與文件格式，支援不同的閱讀需求。

A11y 會直接改變互動設計

我希望介面保留個性，但不要求使用者一定要看動畫、使用滑鼠，或有完美視力才能理解。以下是 prototype 裡能看到的實作選擇，不代表已取得完整的無障礙認證。

把輪播的控制權交還給讀者

產品輪播提供上一個、下一個、暫停、鍵盤方向鍵和 slide 名稱。滑鼠停留或 focus 進入時會暫停，使用者手動暫停或要求減少動態時也會停止。自動播放不應該和閱讀搶時間。

不要每隔幾秒就朗讀一次

如果 live region 在自動輪播時不斷播報新卡片，螢幕閱讀器的使用者會一直被打斷。所以自動輪播時不主動播報，停止輪播後才使用 polite，讓訊息在適合的時機被讀出。

把裝飾和資訊分開

輪替標題有一個穩定的無障礙句子，視覺上變動的文字不重複暴露給輔助科技。Cursor 圖案與背景圖層屬於裝飾，不應該產生重複名稱，也不需要成為鍵盤 focus 的目標。

Fallback 本身就是設計

靜態水波背景、不旋轉的立體素材，以及觸控裝置上的一般連結，都是預先考慮的替代方式，不是壞掉的版本。我也會檢查 focus、對比、44px 操作範圍、圖片替代文字和窄螢幕換行，並在實際裝置與內容上重新確認。

下面是簡化的啟用條件。不論這個效果有沒有開啟，原本的操作都必須存在。

const finePointer = window.matchMedia('(pointer: fine)')
const reducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)')

const enableCursorEffect = finePointer.matches && !reducedMotion.matches
// Keep the native link, keyboard focus and accessible name in every mode.

UI QA 和實作一起進行

每完成一個區塊，我就比對設計、測試真實內容、調整到斷點之間的寬度。如果問題來自共用規則，就修正規則，而不是只補眼前這一頁。我會把資訊層級、focus 和 RWD 換行這類 UI review，與資料、權限、商業規則的 functional testing 分開。漂亮的 prototype 不能證明後端功能已經完成。

桌機和手機截圖，是某一個時間點的介面證據，不能取代鍵盤測試、實機驗證或效能紀錄。這篇文章也維持精選的主閱讀動線，完整畫廊則等讀者需要時才載入。

桌機寬度下的 Ogloba 產品方案區塊 — 用桌機產品頁作為基準，比對手機版的內容順序與排版變化。

窄螢幕上的 Ogloba 產品方案內容與卡片 — 手機產品頁保留完整資訊，操作仍然可以抵達。

驗證之後，依目的地選擇落地方式

繼續使用 React

確認哪些元件保留、哪些需要重構，和工程師對齊真實資料與商業邏輯，再執行無障礙、效能和回歸檢查。Prototype 把驗證過的設計意圖帶進正式實作，但不跳過工程 review。

返回 Figma，再進入 WordPress

如果 WordPress 是目的地，我會把驗證後的結構帶回 Figma，依專案約定整理 Elementor 命名與區塊規則。命名是交接慣例，不是通用的自動轉換格式。Elementor 實作完成後，還要再做 UI 和 RWD QA，因為它的版面與斷點行為可能和 React 不同。

這篇連結證明的是 Next.js prototype，不是已完成 WordPress 移轉，也不是最終產品已正式上線。

AI 幫了什麼，我負責什麼

AI 幫我處理 scaffold、重複 markup、實作方案和 code 迭代。我負責 sitemap、完成的設計、協作規則、視覺判斷、動畫方向、RWD 決策和驗收條件。看出不好的結果，以及決定什麼不該上線，也都是這份工作的一部分。

現在能展示的成果，是一個可操作、以元件組成的 prototype，以及可重用的交付流程。如果要說明商業成效或效率提升，我會先建立可比較的 review 時間、修改輪數、漏出的問題、媒體重量和正式產品程式重用比例。我比較想把決策和成果給人看，而不是先編一個百分比。