AI 網站建置器
一個應用程式要達到世界級水準，必須同時滿足五件事。它回應了使用者真正想要的。它看起來獨一無二，但仍然能有效轉換。它只說實話。它的一切都正常運作。而且在宣告完成之前，有人在真實的瀏覽器中看過它。這個技能就是達成這五個目標的方法，適用於任何技術棧，可以單獨使用或搭配輔助代理。
從這裡開始：人們會用它「做」什麼？
在進行任何工具呼叫之前，請先決定你要建置的是哪一種。如果不確定，請閱讀 references/01-read-the-request.md。
| 使用者要求的是... | 建置 | 閱讀 |
|---|---|---|
| 一個關於某個企業、人物、地點或他們所銷售東西的應用程式 | 一個閱讀型應用程式：故事、他們提供的真實證明、一個聯絡他們的方式 | 01, 02, 03, 09, 04, 10 |
| 一個可以「使用」的東西：儀表板、工具、入口網站、「像 Slack 但...」、對現有工具的重新設計 | 一個可運作的應用程式：/ 是工作畫面，包含演示資料，如果可登入，則顯示可見的演示憑證 | 01, 05 優先，然後 03, 09, 04 |
| 一個活動（學習語言、考試練習、規劃、追蹤）有目標受眾但沒有指定企業 | 一個可運作的應用程式。對於學習類：一個有區塊設計的首頁，然後是課程、練習、進度。絕對不是一個虛構學校的宣傳手冊 | 01, 05, 09 |
| 一個介紹現有產品的頁面 | 一個關於該產品的閱讀型應用程式 | 01, 02, 03, 09, 04, 10 |
請求中的「網站」這個詞並非決定性因素；擁有者的用詞（「我的學院」、「我們的商店」）以及人們將在其中「做」什麼才是關鍵。如有疑問，請按照「建置可運作應用程式」的路徑來閱讀，並在你的第一條訊息中說明。
工作循環（詳見 references/00-operating-loop.md）
- 閱讀請求。 撰寫
.app-notes/brief.json（包含使用者自己說的話、未知事項、假設的事實）和.app-notes/requirements.json（他們現在和之後說的每一件事）。最多提出一個分組後的問題，僅在「錯誤的猜測會改變建置方向」時提問。 - 研究與策略（與第 3 步並行）。研究真實的類別，撰寫九項策略答案和設計論點。
references/02-research-and-strategy.md - 靈感板（與第 2 步並行）。每一輪六個板；每個板是一個設計，以同一個應用程式的四個畫面呈現，約 2048 x 1280；使用者可以要求更多輪直到滿意為止。這六個板來自受眾文化中的六個候選世界，而不是六個形容詞（
references/09-design-craft.md第 2 節）。references/03-design-direction.md - 概念、證明、評選。 每個板一個概念，結構上各不相同；將每個概念渲染成真實頁面；為它們打分；選擇最佳者。
- 綁定方向。
DESIGN.md、tokens.css、fonts.css、對比度檢查、每個頁面的藍圖。 - 規劃。 頁面和區段（附一行工作說明）、功能（附可執行的驗收步驟）、圖片（附其作用）。
- 建置。 先建立基礎，然後並行建立頁面建構器，最後是整合器。僅使用權杖、真實文案、真實圖片、可運作的控制項。
references/04-build-system.md，對於可運作應用程式，請參閱05-working-apps.md。 - 驗證：在生產環境建置上執行
scripts/check-app.mjs：三種尺寸、以訪客瀏覽的方式滾動、圖片、測量事實、設計掃描（對比度、字體、層級、被遮蓋的文字、生成器告訴）、功能流程、錄製導覽。references/06-qa-and-repair.md - 評論，然後修復。 首先，不受錨定效應影響地評判設計；然後閱讀掃描結果；接著，依序執行命名的修正步驟（佈局、排版、上色、大膽化、強化、打磨...），每次一個，範圍明確，每個步驟結束時都要有證據。修復根本原因；重新檢查；如果某項修改使情況變得更糟，則還原它。
references/09-design-craft.md - 根據所選圖片進行打磨，然後根據測量結果誠實報告。
不要跳過第 3、4、8 和 9 步：這些是應用程式不再只是模板的關鍵，也是「完成」不再只是聲明的時刻。可以同時進行獨立步驟。
不可協商的規則
- 誠實重於一切。 絕不虛構見證、Logo、新聞報導、評分、統計數據、獎項、團隊成員、地址、電子郵件、電話號碼、價格、營業時間、回覆時間、政策、保證或資格。缺少的事實就省略（預設情況），將其轉變為邀請，或使用可見的
<Draft>標記一次以供擁有者填寫。計算使用者未列出的內容就是虛構。可運作應用程式中的範例資料是允許的，但前提是應用程式畫面上顯示「演示資料」。 - 沒有任何東西假裝可以運作。 不能有
href="#"、不能有無效的表單、不能有失效的「尚未連接」按鈕、不能使用使用者未選擇的第三方表單服務、不能接受任意輸入的登入功能。要嘛真實連接，要嘛完全省略並說明原因。 - 絕不聲稱未經測量的事。 未提供證據前，不能說「已測試」、「已驗證」、「可存取」、「已打磨」或「適應性強」。「無法檢查」絕不等於「乾淨」。除非你已進行啟動該工作的呼叫，否則絕不能說工作已經開始。
- 在撰寫程式碼之前，根據圖片決定外觀，並依照所選圖片進行建置。不使用預設外觀。拒絕第一、第二階段的AI生成痕跡，除非這個客戶的世界值得這樣做（
09將它們列為QA腳本測量的規則；保留review發現的問題時必須附上理由）。 - 一個設計系統。 顏色、字體、圓角、陰影和動態效果僅來自權杖。最多兩種字體家族。一個標誌性時刻和一個刻意的瑕疵。強調色要節制使用。
- 圖片要豐富、經過精心設計且絕非偽造。 大約每滾動一個畫面一張圖片，風格統一，透過圖片清單管理，提供真實的替代文字；不能有手繪的 SVG 物體或人物圖片；圖片內不能有文字；不能將 AI 圖片加上「真實事件」的標題。
- 正確的語言，正確的書寫系統。 設定
lang和dir；使用真實的書寫系統（絕不能使用音譯代替）；使用邏輯 CSS 屬性；對於你無法驗證的翻譯，要標記給擁有者處理。 - 使用者說的每一句話都要記錄並使用。 後續的提問、調整方向以及回應都要記錄到需求清單中，並且所有後續步驟都要讀取它。同一個項目的後續提問應繼續在同一個專案中進行。
- 證據重於程式碼。 每個關於視覺的聲明都必須來自你在本次運行中看過的圖片，且解析度為 390、768 和 1440。
- 修復根本原因，最小的變更。 重現問題，修復根本原因，重新檢查。兩次修復失敗則重寫該元件。如果生成的圖片有缺陷，需要新的圖片，而不是用 CSS 修補。
啟動腳本與腳本
<skill> 指的是此 SKILL.md 檔案所在的資料夾（例如 ~/.claude/skills/ai-website-builder）。請從專案資料夾執行這些腳本。
bash <skill>/scripts/scaffold.sh ./my-app [--app] # 複製啟動模板，安裝依賴，進行 lint，建置 (--app 會建立 src/app/ 目錄用於可運作應用程式)
node <skill>/scripts/contrast.mjs --tokens src/styles/tokens.css # 檢查元件使用的每一組顏色配對（淺色與深色模式）
node <skill>/scripts/optimize-images.mjs --src .app-notes/originals --alt .app-notes/alt.json # 產生 avif + webp 格式的圖片集與清單
pnpm build && pnpm preview # 啟動生產環境建置的預覽伺服器（保持運作）
node <skill>/scripts/check-app.mjs --url http://localhost:4173 --flows .app-notes/flows.json --tour [--extremes]
# 拍攝圖片、測量事實、執行設計掃描、測試功能流程、錄製訪問過程、產生報告
# --extremes 會額外測試 320x640 和 1920x1080 兩種尺寸；--no-design 會跳過設計掃描
QA 腳本需要 Playwright（執行 pnpm add -D playwright && npx playwright install chromium）或使用 --chrome /path/to/chrome 參數。圖片優化器需要 sharp。
assets/template/ 是一個 Vite + React 19 + TypeScript + Tailwind v4 的專案，具備按路由預先渲染、權杖合約、18 個 UI 原語、一套動畫套件、一套沉浸式套件、一個應用程式套件，以及一個會在常見錯誤時讓建置失敗的 lint 檢查器。其中的 AGENTS.md 是權威的文件映射；STANDALODE.md 說明在沒有代管平台的情況下，需要手動完成的事項（設定作者權杖、製作圖片、設定表單端點）。對於可運作應用程式，請使用 scaffold.sh --app（它會建立 src/app/{accounts,db,seed}.ts；沒有人登入的應用程式中，demoAccounts 保持為空）。如果使用者專案已有其他技術棧，請使用該技術棧：這個方法、規則與腳本不依賴於模板。
使用輔助代理
如果使用子代理工具，請根據 references/08-role-briefs.md 進行分工，並給予每個輔助代理不相交的寫入範圍（基礎建置：共享檔案；頁面建置者：每人一個頁面資料夾；整合器最後執行）。如果單獨工作，請遵循相同的順序。維護一個共享的待辦事項清單：使用者的事項是他們可以更改的；不要在還有符合你部分的工作事項未完成時就交還控制權；最終，每個事項都應該是「已完成」、「已封鎖（附說明）」，或「未完成（附理由）」。
結案報告（僅根據測量結果）
你建置了什麼（頁面、功能）；對於可運作應用程式，哪些是真實的，哪些是模擬的；使用者需要提供什麼；哪些已經過驗證（結論）和哪些尚未驗證；以淺白語言說明哪些事項仍未解決；針對每個需求：已建置且已驗證、已建置但未驗證、或未完成（附理由）。簡短、平實、無行銷語氣。在送出報告前，請使用 assets/checklists/done.md 進行最終檢查。
參考文件對照表
| 檔案 | 何時閱讀 |
|---|---|
references/00-operating-loop.md | 規劃執行、分配工作、維護記錄和待辦事項清單時 |
references/01-read-the-request.md | 每個專案的前十分鐘；判斷是閱讀型還是可運作應用程式；語言；聲明；後續提問 |
references/02-research-and-strategy.md | 研究類別、撰寫策略和設計論點、選擇頁面骨架時 |
references/03-design-direction.md | 處理靈感板、概念、動線、排版、工藝法則、AI 痕跡、證明、評選、逼真度時 |
references/04-build-system.md | 撰寫程式碼：權杖、頁面、文案、表單、圖片、動畫、SEO、可存取性、預算 |
references/05-working-apps.md | 處理任何使用者會使用的東西：演示後端、登入、區域、流程、學習應用程式時 |
references/06-qa-and-repair.md | 進行驗證、評判、修復、評論、撰寫結案報告時 |
references/07-failure-catalogue.md | 開始之前和撰寫報告之前：過去出了什麼問題以及解決方法 |
references/08-role-briefs.md | 為輔助代理設定任務時；對應工具名稱時 |
references/09-design-craft.md | 決定應該投入多少心力（訪客模式）、建構世界、顏色和字型的下限、以規則形式呈現的 AI 痕跡、改善步驟、兩種評估、評分時 |
references/10-copy-and-voice.md | 撰寫或審查應用程式上的任何文字：從事實推導出的語調、內容插槽規則、生成式散文的 AI 痕跡時 |
references/11-listening-to-the-audience.md | 研究步驟：傾聽受眾的擔憂和用語，但不借用他們的聲明時 |
references/12-diagrams.md | 需要繪製運作原理、流程、架構圖時；使用標記語言從權杖建構 |
references/13-reference-teardown.md | 在研究過程中，測量最多三個參考應用程式的工藝和結構時 |
references/14-scripts-and-app-jobs.md | 處理非拉丁語系的字型；各類應用程式的訪客目的；無障礙增強功能時 |
references/15-redesign-and-extension.md | 現有應用程式需要重新設計時：記錄現狀，選擇要打磨、重新設計風格還是全面翻新，證明沒有遺漏任何功能時 |
references/NOTICE.md | 關於此技能從中學習的公開專案的 credits 和授權資訊 |
assets/checklists/brief.md, done.md | 記錄文件的格式模板；最終檢查清單 |