Claude Fable 5 網站設計完整教學：由品牌 Brief、Claude Code 到響應式 QA

「用最新模型做出高價網站」是一個很吸引的示範題目，但也是最容易把三件事混在一起的地方：模型能力、網站完成度、商業售價。模型可以很快閱讀規格、產生程式、比較畫面和修正錯誤；它不會自動取得品牌策略、真實案例、合法素材、客戶批准、production 安全、維護能力或願意付款的買家。漂亮首屏只證明某個畫面已經出現，不證明整個網站已完成，更不證明它值某個金額。

這篇教學採用一個完全虛構的香港品牌專案，示範如何把 Claude Fable 5 放進可追溯的網站流程：先核對產品身份和官方資格，再寫 brief、建立 repository 邊界、完成第一個 vertical slice、逐輪修正、用瀏覽器收集證據，最後只把通過 staging 審核的版本交給人批准。重點不是「一個 prompt 取代所有人」，而是每一步都有輸入、輸出、限制、證據和負責人。

若你仍在選擇 n8n、Claude Code 或 Google AI Studio，可先閱讀三款工具的責任邊界與部署決策指南。偏向視覺原型的讀者可對照Gemini Canvas 與 Figma UI 工作流；想比較另一條 prompt-to-site 路線，可看Google AI Studio Build 網站教學。本文不重複那些產品，而是集中 Fable 5、Claude Code、repository 驗收與正式交付。

媒體及來源披露：本文封面、6 張步驟圖、2 張影片海報和 2 段預覽全部是本站為教學重新製作的虛構示意媒體。畫面內的 North Pier Studio、人物、項目、數字、domain、repository、訊息、測試結果和品牌素材均非真實客戶資料；它們不是來源影片或 Claude 產品介面的截圖，亦沒有原作者、頻道、帳戶、社交平台或推廣身份。示意畫面只解釋流程，不證明實際帳戶具有相同按鈕、配額或結果。產品資料核對於 2026 年 7 月 26 日，使用前請重查第一方文件。

先校正名稱：Claude Fable 5 究竟是甚麼？

Anthropic 官方文件把 Claude Fable 5 定位為廣泛發布型號中能力最高、面向高難度推理與長時間 agent 工作的模型，API model ID 是 claude-fable-5。官方規格列出預設 100 萬 token context、每次最多 128,000 output tokens，以及每百萬 input／output token US$10／US$50 的 API 基準價。這些是模型規格，不是網站套餐、hosting 費、設計服務報價或收入預測。

Fable 5 可以作為 Claude Code 所使用的模型，但兩個名稱代表不同層。Fable 5 是推理與生成模型；Claude Code 是可在 terminal 或支援 IDE 讀 repository、修改檔案、執行指令和產生可審核 diff 的 coding tool。同樣道理，Claude Artifacts 是另一個製作獨立文件、HTML、SVG 或互動元件的表面。讀者若只記得「Fable 5 可以做網站」，很容易漏掉真正執行、測試、部署和維護的系統。

官方模型比較頁亦沒有叫所有人把每個網站任務都交給 Fable。它建議一般複雜 agentic coding 可由 Claude Opus 5 起步，需要最高能力時才使用 Fable 5。這是一個重要成本觀念：網站的困難工作可能是跨檔案架構、複雜視覺核對或長時間 debugging；更換一段文案、調整 8px spacing 或列出檔名未必需要最高能力型號。

香港讀者先做三個資格檢查，不要先開教學

截至 2026 年 7 月 26 日，Claude 官方可用地區名單沒有列出香港。這代表文章不能把「香港讀者」寫成「香港一定可直接開通」，更不應把 VPN、借用外地身份、購買成品帳戶或共享驗證資料包裝成教學。最穩妥做法是查看當日官方名單、你的實際帳戶和所屬組織政策；沒有資格時，可閱讀流程、用虛構專案練習一般 web development 方法，或選擇在所在地正式供應的工具。

第二個檢查是方案。官方 Fable 5 方案說明指出，早期推廣期在 2026 年 7 月 19 日結束。由 7 月 20 日起，Max、premium Team 和 premium seat-based Enterprise 席位可在方案每週用量的一定比例內使用 Fable；Pro、標準 Team 及標準 Enterprise 席位則要由 usage credits 使用。Fable 不在 Free plan。實際包含量、credit、組織開關和模型可見性仍以你帳戶當日介面為準，不能把影片拍攝時的短期優惠寫成永久免費。

第三個檢查是版本及收費身份。Fable 在 Claude Code 需要 2.1.170 或更新版本；登入方案與以 API key 執行的計費路徑不同。官方 Claude Code 方案指南提醒，環境內若設有 ANTHROPIC_API_KEY，Claude Code 會使用 API key 而非訂閱身份，因而產生 API 用量費。開始前應用 /model、/status 及帳單設定確認模型、身份和剩餘用量，不要只看 terminal 顯示「已登入」。

資料保留不是附註，而是是否可以開始的條件

Fable 5 官方文件列明 30 日資料保留，亦不提供 zero data retention。對公開示例影響不大，對真實客戶卻可能是阻塞條件。未公開 campaign、個人資料、客戶名單、內部報價、production log、憑證、第三方授權素材和受保密條款約束的設計，不應因為「模型很強」便直接上載。先建立資料分類：公開、內部、機密、受規管；只有帳戶、合約、公司政策和客戶同意都容許的資料才進入工作流。

如果仍在比較方案和用量，可先讀Claude Pro、Max 5x、20x 比較及Claude 與 Claude Code 用量限制。若官方地區資格未確認，先看Claude 香港訂閱前指南，不要把付款成功當成地區合規證明。

沒有 Fable 5，也可以先學會同一套工程方法

這篇文章的核心方法不依賴某一個模型按鈕：brief、素材清單、repository 規則、vertical slice、小步 diff、responsive matrix、browser 證據、staging 和人工批准，全部都是一般網站工程與交付習慣。若所在地或帳戶沒有 Fable，讀者可用正式供應、公司批准而且能處理相應程式工作的工具練習；成果應誠實標示實際工具和版本，不可把其他模型輸出冒充 Fable 示範。

練習時建立一個沒有真實身份的虛構品牌，只做 navbar、hero、服務卡和聯絡表單的靜態測試版本。即使工具不能看畫面，也可由人提供具體 viewport 問題，要求它修改後跑 lint、test 和 build；即使沒有瀏覽器代理，也可由人開發者工具查看 DOM、console 和 network。工具能力不同會影響速度，不會改變「沒有證據便不能宣稱完成」這條規則。

這亦是避免追逐型號的最好方法。把 source of truth、驗收指令和批准閘保存在專案，而不是只留在某次聊天；日後轉換模型或 coding agent，仍可用同一個 brief 和測試比較結果。若新模型真的更強，應表現在更少錯誤、更小修改、更完整證據和更低重工，而不是表現在更誇張的宣傳形容詞。

高價網站的價值來自甚麼：把口號拆成可交付項目

一個客戶願意支付較高價格的網站，通常不是因為 hero 有 parallax 或字體很大，而是專案降低了風險、解決了問題並能持續營運。模型可以幫忙做原型和工程，但以下工作仍要有人負責：訪談與策略、資訊架構、原創文案、品牌系統、攝影與 licence、內容遷移、後端與整合、無障礙、分析同意、測試、部署、監察、培訓、保養和修改條款。

因此，任何「US$50,000 網站」說法只可作為影片式市場定位的例子，不能寫成 Fable 5 的能力保證。更誠實的教學問題是：怎樣用 Fable 5 和 Claude Code，把一份真實 brief 變成可審核、可測試、可交接的網站版本？若最後只做出一個靜態 hero，就按 hero prototype 交付；不要用高價網站語言掩蓋缺少內容、後端、測試和維護。

步驟一：用一頁 Brief 鎖定成果、非目標與完成定義

開始 coding 前，先把「做一個很高級的網站」改成可判斷句子。你要寫目標受眾、主要轉換、路由、內容來源、功能、裝置、無障礙、素材、分析、部署和非目標。尤其要加入「不做甚麼」：不連真實付款、不開 production database、不創造 testimonial、不複製其他網站、不部署。模型能力愈高，模糊 scope 愈容易變成大量看似合理但未經要求的工作。

專案：North Pier Studio 品牌網站（完全虛構示例）
目的：讓企業客戶在 90 秒內理解服務、證據和下一步
主要受眾：香港中小企的營運及市場負責人
主要轉換：預約 20 分鐘需求會議

必須交付：
1. 首頁、服務、案例、關於、聯絡五個路由；
2. desktop、tablet、mobile 三種版面；
3. keyboard 可操作的導覽、按鈕、表單及 modal；
4. reduced-motion 模式；
5. 真實表單送出前只接測試 endpoint；
6. build、lint、測試及連結檢查結果。

品牌資料：
- 語氣：精準、平靜、可信，不用誇張最高級；
- 色彩：深海軍藍、暖白、珊瑚橙，只作 CTA；
- 字體：使用已獲授權或系統字體；
- 圖片：只用專案資料夾內已標示 licence 的素材；
- 所有客戶名稱、數字和 testimonial 先用明確虛構內容。

非目標：
- 不建立付款、會員、CRM 或 production database；
- 不把 API key 寫進前端；
- 不抄襲指定網站、品牌文案或獨有互動；
- 未經批准不部署、不連真實 domain、不提交表單資料。

完成定義：
- 每個需求有可見證據；
- 320px 至 1440px 無水平溢出；
- console 沒有未處理錯誤；
- build、lint 和指定測試通過；
- 高風險改動及部署仍由人批准。

Brief 完成前先回答十條問題

1. 網站解決誰的哪一個問題？
2. 訪客完成甚麼行動才算主要轉換？
3. 哪些內容已有批准，哪些只是 placeholder？
4. 每個數字、案例、logo 和引語由誰證明？
5. 需要哪些 route、狀態、語言和裝置？
6. 表單送到哪裏，失敗和重複提交怎樣處理？
7. 是否需要登入、付款、CMS、search 或第三方 API？
8. 哪些素材可公開、可修改、可商用？
9. 誰批准視覺、文案、功能、安全與上線？
10. 哪些工作明確不在今次範圍？

Brief 不需要寫成五十頁。它的作用是讓第二個人能判斷「做完未」，也讓 Fable 知道何時應該停止。官方 Fable prompting 指南特別建議交代更大任務、使用者與輸出目的，並明示行動邊界。比起堆疊形容詞，寫清楚「為何要做、誰會用、甚麼不可做」更能減少漂亮但錯方向的產物。

步驟二：先整理素材、內容狀態和 licence manifest

AI 網站示範常把圖片視為隨時可換的裝飾，正式專案卻要知道每一張圖的來源、授權、人物同意、可修改範圍、使用期限與替代文字。建立 assets-manifest.csv，至少記錄檔名、來源、擁有者、licence、到期日、用途、人物同意、是否可裁切、alt 狀態和批准人。沒有資料的項目標示 pending，不要叫模型猜。

內容亦要有狀態。可用 Draft、Fact checked、Brand approved、Legal approved、Published 五級；每段文案連到 owner 和日期。虛構練習應在內容內直接標示 demo，而不是用看似真實的客戶數、收入、獎項和 testimonial。若模型為了填版面生成「服務過 300 個品牌」之類句子，即使設計很完整，仍屬發布阻塞問題。

• Logo：只用客戶正式提供或虛構 logo，不由模型模仿名牌。
• 字體：確認 webfont licence、檔案格式、載入方式和 fallback。
• 相片：保留來源與 model release；沒有權利便用中性 placeholder。
• 影片：確認壓縮、字幕、poster、autoplay、reduced motion 和流量成本。
• 數據：保留來源、日期、分母和批准；沒有證據便刪除。
• 第三方設計：可分析原則，不可要求像素級複製獨有畫面、文案或資產。

步驟三：建立可回滾 Repository，再寫專案規則

不要把 Fable 的第一個任務設成「由空白建整站並發布」。先確認 repository owner、branch、package manager、框架版本、Node 版本、安裝指令、開發指令、lint、測試、build 和 staging 流程。若專案已有結構，要求 Claude Code先唯讀探索；不要讓它因為偏好另一套工具便重建架構。

Anthropic 的 Claude Code 常見用例指出，可用 /init掃描專案並產生 CLAUDE.md，也可先進入 plan 模式審視跨檔案修改。對客戶網站，CLAUDE.md不應只是介紹技術；它要列 source of truth、指令、邊界、驗證和需要批准的操作。以下是安全起點，不應原封不動套到所有 repo。

# Project rules

## Goal
Build a reviewable marketing website for the fictional North Pier Studio brief.

## Commands
- Install: npm install
- Develop: npm run dev
- Lint: npm run lint
- Test: npm test
- Build: npm run build

## Source of truth
- Product scope: docs/brief.md
- Content: content/site-copy.md
- Design tokens: src/styles/tokens.css
- Acceptance checks: docs/acceptance.md

## Boundaries
- Do not deploy or connect a production domain.
- Do not add analytics, trackers, external forms, databases, authentication, or payment.
- Do not create testimonials, client logos, awards, prices, or performance claims.
- Use only assets listed in public/assets-manifest.csv.
- Ask before destructive, irreversible, paid, credentialed, or scope-changing actions.

## Verification
- Audit every completion claim against a command result, DOM check, screenshot, or file diff.
- If a check was not run, label it not verified.
- Keep changes small and preserve a reviewable diff.

第一次讓 Claude Code 接觸 repo 時只做唯讀盤點

1. 辨認 framework、版本、package manager 和 entry point。
2. 列出 route、layout、元件、style、content 和 asset 位置。
3. 找出現有 lint、test、build 和 preview 指令。
4. 確認有沒有未提交修改，不覆蓋其他人的工作。
5. 列出環境變數名稱，但不要輸出值。
6. 找出部署設定、analytics、form endpoint 和第三方 script。
7. 比較 brief 與現況，只寫 gap analysis。
8. 提交修改計劃和風險，等待真正必要的批准。

這個步驟可防止三類錯誤：把舊 repo 當全新專案、在沒有需要時換依賴，以及把本機 demo 設定帶入 production。即使 Fable 能處理長 context，也不代表讀得愈多愈好。只給與今次 slice 有關的檔案，任務切換時清理對話或 compact，保留 CLAUDE.md作長期規則。

步驟四：用 Fable 5 完成第一個 Vertical Slice

Vertical slice 是一條由內容到畫面、互動和測試都可驗收的小路徑。例如 navbar、hero、證據區和 CTA；它比一次產生五頁更能測試設計方向、元件品質、responsive、焦點、素材載入和 build。第一輪不追求頁數，而是確認方法可重複。

你正在一個已建立、可執行的網站 repository 工作。

背景：
這是完全虛構的 North Pier Studio 品牌網站。目標不是複製任何參考網站，而是用 brief、design tokens 和已授權素材建立原創、可驗收的版本。

現在只完成第一個 vertical slice：
- responsive navbar；
- hero；
- 一個可信證據區；
- primary CTA；
- mobile menu；
- keyboard focus；
- reduced-motion fallback。

工作方式：
1. 先閱讀 docs/brief.md、docs/acceptance.md、CLAUDE.md 和現有架構；
2. 報告你會修改的檔案及原因；
3. 不新增 brief 以外的功能，不改 package manager，不部署；
4. 優先使用現有元件與依賴；
5. 所有圖片只可來自 assets manifest；
6. 不虛構 testimonial、獎項、客戶、收入或成效；
7. 完成後執行 lint、相關測試和 build；
8. 用 desktop 與 mobile 的實際 DOM／畫面證據核對驗收；
9. 只報告有工具結果支持的完成項目；未驗證的要明示。

交付：
- 修改摘要；
- 驗收表：需求｜證據｜狀態；
- 測試結果；
- 尚未處理的範圍；
- 需要人批准的下一步。

這個 prompt 有四個特徵。第一，它給出 larger task 和受眾，而不只叫模型「做靚」。第二，它列出本輪範圍，避免順便加後端和部署。第三，它要求用現有 repo 和 assets manifest。第四，它要求每個完成主張回到 command、DOM、畫面或 diff。這與官方 Fable 指南的建議一致：長任務要限定邊界，進度要由實際工具結果支持，自我驗證要明示。

第一個 Slice 的驗收表

步驟五：每輪只處理一組可重現的問題

第一版之後最常見的低效指令是「再高級一點」「更像 Apple」「加多點動畫」。這些句子沒有測量方法，也容易令模型大改已經通過的部分。把 feedback 改成差異：在 390px 下標題超出 16px padding；keyboard 到第三個按鈕時看不到 focus ring；hero 影片在 reduced motion 仍自動播放；服務卡標題與 brief v1.2 不一致。

以下是本輪唯一要處理的問題：
［例如：390px 寬度下 hero 標題超出容器，而且 CTA 焦點樣式不清楚］

期望：
- 找出實際原因，不先假設；
- 只修改直接相關檔案；
- 保留既有資訊架構、色彩和動畫方向；
- 不順便重構其他元件；
- 以相同 viewport 重現修改前問題；
- 修改後重新檢查該 viewport、keyboard focus、console、lint 和相關測試；
- 提供 before／after 證據及精確檔案清單。

如果證據不支持修改，停止並報告發現，不要為了顯示有進度而改 code。

每輪一組問題，不表示每次只改一行；而是所有修改有同一驗收目的。先保留重現證據，再改 code，然後用相同 viewport、輸入和 route 重試。若問題消失但另一個 breakpoint 破壞，這輪未完成。若 Claude 無法重現，應報告「未證實」，而不是為了產生 diff 隨便改 CSS。

把主觀評語轉成可驗收條件

• 「太普通」→ 主要訊息和次要訊息缺少層級，請比較字級、行長、間距與 CTA 對比。
• 「動畫不順」→ 在指定裝置記錄 frame drop、layout shift 或交互延遲，再減少相應效果。
• 「手機很擠」→ 指定 320px、390px 的元素、容器和最小點擊範圍問題。
• 「不像品牌」→ 回到 design tokens、品牌形容詞和禁用元素，不參考競爭者像素。
• 「內容太 AI」→ 列出無證據最高級、空泛句子和重複語法，交由內容 owner 改。
• 「幫我全部優化」→ 分開內容、視覺、interaction、performance、SEO 和安全六輪。

步驟六：擴展到完整頁面，但保持 Design System 與內容來源

第一個 slice 通過後，才把同一套 navigation、container、type scale、spacing、button、card、form 和 motion token 擴展到其餘 route。不要讓每一頁由新 prompt 自由發揮，否則五頁會像五個不同網站。Design tokens 應由檔案管理，頁面內容應由 content source 管理；模型只引用它們，不在元件內散落任意 hex、字級和 placeholder。

案例頁尤其容易變成虛構。正式做法是每個 case study 有內容狀態、客戶批准、問題、工作、證據、限制和可公開資產。沒有批准時，使用明顯標示的虛構案例或不發布該 route。testimonial 亦不應由模型「寫得自然一點」；真實引語要保留提供者、日期、同意、可修改範圍和最終批准。

元件完成定義

1. Normal、hover、focus、active、disabled、loading、success、error 狀態已定義。
2. 內容長短、沒有圖片、錯誤圖片和多語文字不會破版。
3. 有語義 HTML、標籤、名稱和 keyboard 行為。
4. motion 有目的，並有 reduced-motion 替代。
5. 沒有把 secret、私人 endpoint 或 production ID 寫入 client code。
6. 元件測試與頁面整合測試分開。
7. 所有可見主張有內容 owner，不由模型成為來源。

高級感不等於動畫愈多：為 Motion、影片與 3D 寫驗收規格

高價網站示範經常以全屏影片、scroll-driven animation、parallax、shader 或 3D 物件作為視覺焦點。這些效果可以建立記憶點，也可以令內容難讀、手機過熱、操作延遲、暈動不適和維護成本上升。不要只把「加入電影感」交給模型自行解讀；先寫效果服務哪一段訊息、在甚麼裝置啟動、何時停止、失敗時顯示甚麼，以及沒有動畫時內容是否仍完整。

每一個 motion 應有四個狀態：首次載入、互動中、離開 viewport、reduced motion。背景影片應另有 poster、字幕或文字等價內容、載入失敗 fallback、流量控制和非自動播放方案；3D canvas 要處理初始化、resize、頁面離開、資源釋放和不支援裝置。模型可以生成程式，但產品負責人要決定效果是否值得增加的下載、測試和維護成本。

Motion 規格範例

要求 Fable 修改動畫時，一輪只處理一個可觀察問題，例如「當使用者設定 reduced motion，hero、menu 和 route transition 仍在移動」。驗收要在實際偏好和同一 route 重現，不能只搜尋 CSS 是否存在對應 media query。若動畫 library 與 framework 已經在 repo，優先沿用；不要為單一淡入效果加入大型新依賴。每次改動後重新看 focus、layout、console 和手機 fallback，因為動畫修正最容易意外改變 DOM 次序和 overflow。

表單、CMS 與第三方服務：先畫資料流，才讓模型接線

聯絡表單是 marketing site 最常由「看得到」誤判為「已完成」的部分。畫面有姓名、電郵和提交按鈕，只代表前端元件存在；完整流程還包括 validation、同意、server endpoint、spam、rate limit、錯誤、重試、通知、資料保留、刪除、權限和監察。先畫出每個欄位由瀏覽器到哪個服務、誰可讀取、保存多久、失敗怎樣處理，再決定模型可以修改哪一層。

練習專案只應連測試 endpoint，並使用虛構資料。正式整合時，把 secret 保留在 server runtime，不在 prompt、畫面、client bundle 或 repository 顯示值。Claude 可以辨認環境變數名稱和使用位置，但完成摘要不應輸出值。若第三方服務需要 OAuth、管理員權限、付費操作或 production write，由持有人親自批准，並為 token 設最小 scope、測試帳戶和撤銷方法。

表單必測的九條路徑

1. 所有欄位空白提交，錯誤摘要和每個欄位提示一致。
2. 格式錯誤、過長文字、特殊字元和多語內容不會破版或繞過驗證。
3. keyboard 能到達、修正和重新提交，focus 會回到適當位置。
4. 成功送出只產生一次紀錄，連續點擊不重複。
5. 網絡中斷、timeout、server error 和第三方服務失效有清楚訊息。
6. 失敗後不會清空使用者仍需要的內容，亦不在 console 洩漏資料。
7. 測試和 staging 不會寄給真實客戶、建立 production lead 或觸發正式 automation。
8. 通知內的資料最少化，收件人、權限和保留期已批准。
9. analytics 和 error tracking 不會意外收集完整表單內容。

CMS 亦要同樣處理。先定義 content model、狀態、preview、發布權限、排程、版本和回滾，再叫模型建立 component 或 query。不要把可編輯 CMS 欄位直接插入不安全 HTML，也不要讓 production content schema 因 demo 需求任意改動。若今次 scope 不包括 CMS，清楚交付靜態內容和未來接口，不用假畫一個「管理後台」令客戶誤以為已存在。

客戶 Review 不是一句「喜不喜歡」：用決策包減少無限改版

模型可以在數分鐘生成多個方向，團隊反而更容易失去決策紀錄。每次 review 應交一個決策包：版本、此次目的、已批准項目、兩至三個需要選擇的問題、每個選擇的影響、未驗證項目和下一個 gate。不要同時展示十個沒有篩選的版本，亦不要讓客戶在未看 mobile、內容和功能時只按首屏美感批准整站。

Feedback 要落在 brief 或 acceptance criteria。若客戶說「不夠 premium」，主持人應追問是字體層級、內容可信、圖片方向、留白、互動、品牌一致，還是競爭定位；把答案寫成具體差異，才交給 Claude。若要求加入原 scope 沒有的會員、支付、多語 CMS 或複雜 3D，標示為 change request，先評估內容、架構、測試、費用和日期，不因生成很快便假設實作與營運免費。

一次有效 Review 的輸出

• 版本：staging URL、commit、日期、負責人。
• 本輪問題：只討論已列出的內容、視覺或功能範圍。
• 證據：desktop、mobile、狀態、測試和已知限制。
• 決定：批准、修改、拒絕、待資料，每項有 owner。
• 變更：是否屬原 scope，影響哪些 route、資料、測試和時間。
• 下一步：下一個 gate、需要提供的內容和停止條件。

Review 完成後，把批准內容鎖定為版本，不再由下一輪 prompt 隨意改寫。Claude 的任務要引用確切版本和差異；如果新要求與舊批准衝突，先報告衝突，不自行選邊。這種紀錄看似比一句「再做靚啲」慢，實際上能阻止反覆重建，亦令最終報價對應真實工作，而不是對應模型生成了多少畫面。

步驟七：Responsive QA 要測狀態，不是只縮瀏覽器

Responsive 不只是 desktop、tablet、mobile 三張靜態圖。你要測內容、導覽、表單、鍵盤、modal、長標題、錯誤訊息、圖片失敗、soft keyboard、orientation 和 reduced motion。至少由 320px 到 1440px 搜尋水平 overflow；不要只選一部高階手機。若 container 以固定寬度、超大字級或 absolute position 拼出 hero，桌面很漂亮，細屏可能立即失效。

對每個主要 route 建立 viewport matrix：320、390、768、1024、1440px；再加 keyboard-only、reduced motion、圖片失敗和表單錯誤。每格記 Pass、Fail、Not verified，而不是只放截圖。截圖證明可見狀態，DOM、console 和測試證明部分行為，兩者都不能單獨代表全部品質。

Accessibility 最少人工走一次

1. 不用滑鼠，由頁首 Tab 到頁尾，焦點次序符合閱讀順序。
2. 跳過導覽、menu、modal、accordion、carousel 可由鍵盤操作及關閉。
3. 焦點不被 sticky header、cookie banner 或 modal 遮住。
4. 標題層級反映內容，不因字體大小亂用 heading。
5. 表單有 label、required、說明、錯誤摘要和欄位錯誤關聯。
6. 圖片 alt 說明用途；純裝飾圖不重複朗讀。
7. 不用顏色作唯一狀態訊號。
8. reduced motion 下停用非必要 scroll、parallax 和 autoplay。
9. 放大文字和窄屏時內容不被截斷。
10. 由真正使用者或第二位測試者覆核高風險流程。

步驟八：用 Browser 建立 Build–Test–Verify 證據鏈

Claude in Chrome 官方說明列出一條 build-test-verify 工作流：在 Claude Code 建置，部署到可存取 URL，再以瀏覽器測試，並查看 console、network 和 DOM。這很適合比對設計與實作、找 runtime error 和驗證 route；同一頁亦明確提醒瀏覽器代理仍有風險。能夠點擊不等於應該獲准點擊。

先把 staging 與 production 分開。測試帳戶沒有真實客戶資料，表單只去測試 endpoint，付款用 sandbox，analytics 關閉或獲批准。對登入、付款、刪除、發送電郵、提交表單、修改 DNS、改 production config 和公開部署，保留人工確認。不要在 prompt 內放密碼或 OTP，也不要要求模型讀個人 browser session。

請對目前 staging build 做只讀發布審核，暫時不要修改、部署或提交。

逐項檢查：
1. brief 的每個 must-have 是否有可見證據；
2. 所有路由、導覽、CTA、表單驗證和錯誤狀態；
3. 320、390、768、1024、1440px 是否有溢出或遮擋；
4. keyboard 順序、焦點、標籤、reduced motion；
5. 圖片尺寸、alt、懶載入、失敗 fallback；
6. console error、network failure、broken link；
7. build、lint、test 的實際結果；
8. source map、環境變數、secret、個人資料和測試 endpoint；
9. SEO title、description、canonical、分享圖片；
10. licence manifest、虛構資料標記及客戶批准狀態。

輸出表格：
項目｜證據｜Pass／Fail／Not verified｜風險｜建議負責人

規則：
- 不可以把「看起來正常」寫成已通過；
- 沒有執行的測試一律標示 Not verified；
- 分開阻塞發布問題與可延後改善；
- 不進行任何寫入或外部操作。

每個「已完成」句子要有哪種證據？

步驟九：安全、Performance、SEO 和私隱要分開驗收

「幫我做最終 QA」太寬。把發布審核分成四份清單，由不同責任人看。安全看 secret、權限、依賴、輸入和外部服務；performance 看資產、載入、runtime 和實際裝置；SEO 看 metadata、canonical、結構、crawl 和內容；私隱看收集甚麼、為何收集、送往哪裏、保留多久和如何取得同意。模型可以整理發現，不能單獨作法律或安全批准。

安全清單

• client bundle、source map、repository 和 log 沒有 secret 或個人資料。
• 環境變數只存在適當 runtime，staging 與 production 分開。
• 表單在 server boundary 驗證，並有 rate、spam 和錯誤處理策略。
• 外部 script、font、video、widget、analytics 和 chat 工具有 owner 及批准。
• 依賴和 build output 已檢查；不因模型建議便安裝不明 package。
• 部署帳戶使用最小權限，刪除、DNS 和 production write 有人批准。

Performance 與穩定性清單

• 圖片用正確尺寸、格式、寬高和 loading 策略，不下載巨大原圖再縮小。
• 字體有 fallback，不因網絡失敗令內容不可讀。
• 動畫不持續佔用資源，低效能裝置和 reduced motion 有替代。
• 第三方服務失敗時，核心內容、導覽和聯絡方式仍可用。
• route、404、錯誤頁、離線或慢網絡狀態已看。
• 測試結果記錄實際環境和日期，不把單次本機數字寫成永久承諾。

SEO 與內容清單

• 每頁 title、description、canonical、heading、分享圖片和主要內容一致。
• 連結文字有意義，沒有 broken route、空 CTA 或假按鈕。
• 虛構 placeholder、demo 數據和未批准文案不進 production。
• 結構化資料只描述頁面真實可見內容，不創造評分、價格或公司資料。
• 圖片 alt、caption 和檔名服務內容，不堆疊關鍵字。
• 發布後有 owner 負責更新時效資料和移除過期 campaign。

步驟十：由 Staging 交付，不由模型直接宣布上線

完整交付至少有 staging URL、版本或 commit、驗收表、未解問題、環境變數清單、第三方服務、licence manifest、內容批准、部署步驟、回滾方式、監察、備份和維護 owner。Fable 可以整理 handoff，但不能取代客戶簽收。若只有靜態 demo，就在交付書寫「prototype」，不要把未建立的 CMS、form、analytics、SEO 遷移和支援列作完成。

建議的四道批准閘

1. Scope gate：brief、非目標、費用與時間由雙方確認。
2. Design/content gate：視覺、文案、素材和數據由 owner 批准。
3. Technical gate：build、test、browser、安全、環境和回滾通過。
4. Release gate：domain、analytics、私隱、監察、支援和發布時間獲批准。

每道 gate 都應保存版本。如果客戶在 design gate 後要求完全改方向，這是 scope change，不應悄悄由模型吸收。高能力模型可以令修改看起來便宜，卻不會消除重測、內容重批、素材重做、合約和時間成本。把變更寫成 change request，比無限對話更能保護交付品質。

如何控制 Fable 5 的成本、時間和過度工作

官方 Fable prompting 指南指出，高難度請求在較高 effort 可運行多分鐘，長任務甚至更久；effort 是能力、延遲和成本的主要取捨。官方建議大部分任務可由 high 起步，最需要能力的工作才用 xhigh，例行工作可用 medium 或 low。實際 Claude 介面未必向每個帳戶顯示完全相同控制，因此以當日模型和設定為準。

網站專案可用「高難度集中」策略：讓 Fable 分析跨 route 架構、複雜 bug、設計差異和發布審核；把格式化、簡單文字替換、固定 metadata、機械測試和已定義的小改交給較合適工具。每個任務結束後清理 context，避免把無關的長對話反覆送入模型。記錄每個成功 slice 的用量或時間，而不是只比較月費。

兩種工作表面：Artifacts 與 Claude Code 不要混用責任

Anthropic 的 Artifacts 說明列出 single-page HTML、SVG、diagram 和 interactive React component 等例子，也支援查看 code、複製、下載和版本切換。它很適合把想法變成一個可互動原型，讓非技術持份者先看流程。官方亦提醒修正錯誤不保證成功；已發布 Artifact 的分享、embed、storage 和組織限制要按方案文件處理。

Claude Code 更適合正式 repo：它可讀現有架構、編輯多檔案、跑 lint、test、build、建立可審核 diff 和配合部署流程。這不表示 Claude Code 一定比 Artifact「更高級」，而是工作單位不同。若專案只是會議前的一頁互動 demo，Artifact 可以較快；若要接現有 CMS、route、test、CI 和 team review，repo 工作流較合適。

一條合理路線是：Artifact 驗證資訊或互動概念 → 把已批准需求寫回 brief → 在乾淨 repo 重新實作 → browser QA → staging。不要把未知來源的 published Artifact code 直接放入 production。官方分享指南亦提醒，只從可信來源複製 code；即使能複製，也要像審查陌生檔案一樣檢查依賴、外部 request、內容和 licence。

最常見的十二個失敗模式

一個可重複使用的兩日練習流程

第一日上午：資格、Brief 和 Repo

核對官方地區、方案、模型選單、版本、資料保留和組織政策；只使用虛構品牌。完成一頁 brief、內容狀態、assets manifest、acceptance matrix 和 CLAUDE.md。讓 Claude Code 唯讀盤點 repo，人工批准第一個 slice 計劃。

第一日下午：第一個 Slice

只完成 navbar、hero、證據區和 CTA。跑 lint、相關測試和 build，再測 390px、1440px、keyboard 和 reduced motion。把所有未通過項寫入 issue list，不用模糊的「再優化」指令。

第二日上午：擴展與內容

按通過的 tokens 和元件建立服務、案例、關於和聯絡 route。每個 route 使用已批准內容或明確 demo。測空狀態、長內容、圖片失敗、表單 valid／invalid、network success／failure。每輪維持小 diff。

第二日下午：只讀審核與交付

建立 staging，執行 final audit prompt，分開 Pass、Fail、Not verified。解決阻塞項後再重跑；保存 URL、commit、command、畫面、console、network、licence 和批准。最後由人決定是否發布。兩日練習的成果是一條可重複流程，不是承諾兩日完成任何正式客戶網站。

發布前總清單

1. 官方地區、方案、模型、版本和計費身份已核對。
2. Fable 5 的 30 日資料保留已獲公司與客戶接受。
3. brief、非目標、完成定義和責任人已批准。
4. repository、branch、package manager 和 source of truth 清楚。
5. CLAUDE.md包含指令、邊界、驗證和批准條件。
6. 品牌文案、數字、案例、testimonial 均有來源及狀態。
7. 每個圖片、字體、影片、logo 和第三方 code 有 licence。
8. 沒有要求模型複製其他網站的獨有內容或設計。
9. 第一個 vertical slice 已單獨通過才擴展。
10. 每輪修改有重現、最小 diff 和相同條件的 after check。
11. 320 至 1440px 的主要 route 沒有未處理 overflow。
12. keyboard、focus、label、error 和 reduced motion 已走查。
13. 表單只送正確 endpoint，測試不接觸 production 資料。
14. console、network、broken link、404 和 error state 已檢查。
15. lint、test 和 production build 由當次 output 證明。
16. client code、source map、log 和 repository 沒有 secret。
17. SEO metadata、canonical、分享圖和可見內容一致。
18. analytics、cookie、chat、font 和第三方 script 已獲批准。
19. staging URL、commit、環境、部署和回滾有文件。
20. 未驗證項目沒有被寫成已完成。
21. 內容、設計、技術和 release gate 都有人工 sign-off。
22. 交付文件明確區分 prototype、staging 和 production。
23. 維護、監察、更新、備份和支援責任已交接。
24. 宣傳沒有把模型輸出寫成固定網站售價或收入保證。

延伸閱讀

• n8n、Claude Code、Google AI Studio 怎樣選：先分清自動化、coding agent 和 app builder。
• Google AI Studio Build 網站教學：比較另一條由 prompt、preview 到 code 和 Cloud Run 的路線。
• Gemini Canvas UI 與 Figma 工作流：適合先做視覺稿和可編輯設計交付。
• Manus AI Agent 與網站工作流：了解 browser、connectors、研究和網站任務的權限邊界。
• Claude Pro、Max 方案比較及Claude Code 用量指南：建立成本和重設預期。

總結：真正的 Premium，是每一項承諾都能被驗證

Fable 5 的價值在於它可以處理更長、更複雜、需要視覺和自我檢查的工作；這不會令需求、版權、客戶內容、安全、測試、部署和維護責任消失。把它放在清楚 brief、限制和 evidence loop 內，它可以縮短大量分析與實作時間；把它當成一鍵高價網站機器，則只會更快產生難以證明的完成感。

最可靠的流程可以濃縮成一句：先核對資格和資料，再鎖定 brief；先做一條可驗收 slice，再逐輪擴展；先以 command、DOM、console、network 和畫面證明，最後才由人批准發布。網站是否有商業價值，要由真實客戶問題、原創內容、工程品質、交付責任和長期結果回答，而不是由模型名稱或影片標題回答。