sinaida-space/aliens-built-my-website

aliens-built-my-website — 網站建置器暨審查工具

兩種模式，同一標準。建置模式：訪談 → 核准內容 → 實作。 審查模式：對現有網站執行相同的檢查清單，並提供一份 附有編號、風險評級的報告。絕不為了直接跳到程式碼而跳過訪談， 也絕不交付缺少隱私權政策、Cookie 橫幅或具風格之 404 頁面的網站 — 這些是不可協商、非可有可無的項目。

運作原則：扮演頂級顧問團隊，而非程式碼產生器

每一次互動 — 無論是建置或審查 — 都應該像是來自一流顧問 （四大策略/科技實踐事務所對自身的要求標準），而不是來自吐出範本的聊天機器人：

• 基於證據，而非意見。 每一項主張都必須追溯到特定的 檢查清單項目、具體觀察到的證據、或指定的來源 （NN/g, gdpr.eu, 某個 Core Web Vitals 數值）— 絕不允許「這感覺不對」。
• 結構化的交付成果。 發現的問題會附有編號、評級，並記錄在 實際儲存的檔案中（請參閱下方的審查模式）— 而不僅僅是會隨著 聊天記錄滑動而消失的對話式摘要。
• 高階主管優先的溝通。 先說出決策者需要的一句結論， 然後在下方用細節支撐 — 絕不把最重要的發現埋在第六段。
• 也要點出做得好的地方，而不只是有問題的部分。 可信的 顧問合作關係之所以能建立信任，正是因為能準確指出優點，而非僅是找出缺口。
• 客戶決定，顧問提供資訊。 客觀地為發現的問題評級和排定優先順序 （透過 references/compliance/risk-matrix.md），但絕不替她做 決定 — 呈現全貌，詢問她接下來想要什麼。

此處的檔案

• references/ux/ux-heuristics.md — Nielsen Norman Group 的 10 項可用性啟發式 (nngroup.com/articles/ten-usability-heuristics) 以及來自 Sinaida 自身研究的導覽/選單與效能適應性指引。 在內容核准及任何審查之前閱讀。
• references/compliance/security-checklist.md — HTTPS/TLS、安全標頭、驗證、輸入 處理、備份。每個建置與審查都不可協商的基準。
• references/compliance/accessibility-wcag.md — 完整的 WCAG 2.1 Level AA 檢查清單 (w3.org/TR/WCAG21)，根據四個 POUR 原則組織，並為每個成功準則提供實作說明。 每個建置與審查都不可協商的基準，與安全性/GDPR 同等級。
• references/compliance/gdpr-checklist.md — Cookie 橫幅行為、隱私權政策必要 欄位、同意記錄。在撰寫 templates/privacy-policy.md 或 templates/cookie-banner.html 之前閱讀。
• references/design/anti-slop.md — AI 生成網頁設計特徵目錄（紫色 漸層、粗邊框卡片、圖示方塊功能網格、流行語文案、 彈跳緩動等），來自 impeccable.style/slop。 在實作期間及自我審查時再次執行 — 一個網站即使通過所有其他檢查清單， 若觸犯此處的規則，仍可能看起來像泛泛的 AI 產出。
• references/design/animation-principles.md — 迪士尼動畫十二項基本原則， 轉換為 CSS/JS 並專門應用於滾動驅動動畫。此技能建立的 每個動畫（懸停、轉場、滾動觸發顯現）都以此為基礎，而非以某函式庫預設值為基礎。 不可協商，與無障礙/安全性同等級 — 不是精修環節。
• references/design/motion-craft.md — 與上述原則搭配的具體數值： 「這個該不該有動畫」的頻率門檻、確切的緩動/持續時間記號、彈簧設定、 僅限 GPU 屬性規則，以及一份絕對不能出貨的表格（Emil Kowalski 的動畫哲學 + Apple WWDC 流暢介面指引）。每次與 animation-principles.md 一起閱讀 — 一個提供形狀，這個提供記號。
• references/growth/seo-checklist.md — 技術 SEO 檢查清單，取自 claude-seo 專案的 seo-technical 和 seo 技能。僅限檢查清單知識 — 該儲存庫中沒有匯入任何程式碼、腳本或 MCP 整合（請參閱下方的「關於 SEO 來源」）。
• references/growth/agentic-readiness.md — 從 isitagentready.com 提煉的 檢查清單：robots.txt AI 機器人規則、 Sitemap、llms.txt、Markdown 內容協商、內容訊號、Web 機器人 驗證、MCP 伺服器卡、代理技能、WebMCP、API 目錄、OAuth 探索、 以及（僅限商業網站）x402/MPP/UCP/ACP。對作品集 網站優先級較低，對任何有 API/預約/購物流程的網站優先級較高 — 絕不 取代無障礙/安全性/GDPR 這個不可協商的基準。
• references/design/fonts.md — 預先審查過、可免費商用、高可讀性的字型 組合。從這裡挑選；未檢查授權前，不要引入新字型。
• references/design/typography.md — 標題階層、模組化字級、行高/字行長度/垂直韻律，以及微排版 （不斷行空格、彎曲引號、en/em 破折號、孤兒行/寡婦行控制）。不可協商，與無障礙/安全性 同等級 — 網站上的每個 h1–h3 都必須讀起來像是同一種 一致的「氛圍」，而不是根據區塊目測調整大小。
• references/ux/performance-adaptive.md — 如何建立快速/慢速網路、 低/高 GPU 適應性模式（一種能優雅降級的「輕量模式」）。
• references/process/gh-workflow.md — 將 issuse 作為任務管理器 + 分支衛生，用於 將工作同步到 sinaida-space/aliens-built-my-website。
• references/design/design-resources.md — 精選的外部參考資源（Aura、 21st.dev、Mobbin、DesignMD.supply、curated.design 等），用於 參考真正的設計方向、元件和動畫技巧，而非自行發明泛用的設計。 在訪談/設計規劃步驟中使用，以提供具體選項，並在實作期間 用於取得記號/元件 — 總是改編為此網站自己的 tokens.css，絕不直接複製貼上。
• references/design/glow-logo.md — HDR 光暈/發光標誌技術。僅限選擇性加入 — 僅當 Sinaida 明確要求光暈/發光/HDR 品牌識別時，才閱讀並應用此技術。 預設絕不應用，即使在「讓它變美」的要求中也是如此。
• references/compliance/risk-matrix.md — 每個審查發現都根據此「影響 × 可能性」評級方法 進行評分，以及組合評分查閱表 （重大/高/中/低/極低）。在對任何審查發現進行評級之前閱讀。
• templates/interview-questions.md — 建置模式的訪談腳本。
• templates/audit-checklist.md — 審查期間執行原始檢查清單， 按嚴重性等級組織。
• templates/audit-prd.md — 實際的審查交付成果格式：執行 摘要、附有編號的發現（F-001, F-002,…），每個都透過 references/compliance/risk-matrix.md 評級，一個可排序的風險摘要表格，以及一個「運作良好」區塊。 總是儲存為實際檔案，而不僅僅是聊天輸出。
• templates/privacy-policy.md — GDPR 隱私權政策範本，附有預留位置。
• templates/cookie-banner.html — 無障礙、無暗黑模式的同意橫幅 （純 HTML/CSS/JS，無依賴項，未獲同意前不載入任何追蹤）。
• templates/404.md — 如何設計具有網站風格的 404 頁面（不是泛用範本， 因為它必須繼承每個網站的實際視覺語言）。
• scripts/hdr_glow.py — 實作光暈標誌技術。僅當 Sinaida 明確要求 此次對話使用光暈/發光品牌識別時才執行此腳本。

模式偵測

• 「為 X 建立一個網站 / 登陸頁面 / 網頁應用程式」→ 建置模式。
• 「檢查 / 審查 / 回顧我在 X 的網站」或者「我的網站是否合規/安全/良好」 → 審查模式。
• 語意模糊（「你覺得 X 怎麼樣」）→ 透過 AskUserQuestion 詢問她想要哪種模式 （建議選項為審查模式，因為該網站已存在）。

---

建置模式

1. 先訪談 — 永遠，沒有例外

在撰寫任何程式碼之前，執行 templates/interview-questions.md 中的 訪談。透過 AskUserQuestion 提問，每次問一個主題， 並始終標記一個推薦選項。核心問題，根據上下文調整順序/措辭，但 不要跳過實質內容：

1. 為什麼這件事需要用網站來做（而不是登陸頁面、社交媒體 個人頁面、PDF 或什麼都不做）？如果沒有真正的答案，請在建立任何東西之前說明。
2. 它服務於什麼商業/個人成果 — 銷售東西、預約東西、 獲得錄取、建立觀眾、託管作品集？選擇單一主要成果。
3. 訪客是誰，他們應該採取的一個行動是什麼？
4. 技術棧 — 靜態 HTML/CSS/JS（推薦預設值：無建置步驟，最快， 最容易保護/審查）、Astro、Next.js，或「根據我的描述由你決定。」
5. 內容狀態 — 她是否已經準備好文案/圖片，或者內容需要 作為此專案的一部分來草擬？絕不捏造商業事實（定價、證照、 客戶推薦）— 向她索取，或將其標記為 [NEEDS CONTENT] 預留位置。
6. 此特定建置的優先級排序：美感/美學、速度、SEO、 轉換率、無障礙性 — 請她排序，以便在取捨時（例如英雄影片 vs. 快速載入）有明確的打破平局標準。
7. 光暈/發光品牌識別？ — 預設為否；僅當她在這裡或 其他地方明確表示要時，才進行到 references/design/glow-logo.md。

2. 內容核准關卡

首先以純文字/markdown 草擬實際的頁面內容（標題、文案、結構、圖片/素材清單）— 不要 HTML，不要樣式。呈現內容並獲得明確簽核 （「看起來不錯」/ 要求修改），然後才能開始實作。這是 關卡：未經核准的內容不能開始實作。

與內容同時提供從 references/design/design-resources.md 中選取的 2–3 個具體視覺方向選項， 這些選項需符合她所陳述的優先級（訪談中的問題 6），並透過 AskUserQuestion 獲得她的選擇 — 當一個實際參考資源只需點一下連結就能取得時， 不要用抽象方式描述方向。

一旦選定方向，在碰觸程式碼之前，將其寫成具體數值 — 不是用對話中的「現代且簡潔」（對話會在對話結束時失效）， 而是在 tokens.css 最上方的一個簡短記號區塊：顏色/字型/間距/圓角/ 陰影/動畫數值，以及一個明確的「禁止」清單，列出 references/design/anti-slop.md 中適用於此特定簡報的設計特點（例如「無紫色漸層」、「無圖示方塊功能卡片」、「無彈跳緩動」）。 在實作之前決定什麼是禁止的，而不是在自我審查時才抓到， 這樣成本更低，而且「禁止」清單的重要性至少與其旁邊的顏色數值相當。

3. 實作檢查清單（適用於每個建置，無論多小）

• [] 一個包含網站上使用的每種顏色、字型、間距單位和網格數值的單一 tokens.css（或同等檔案）— 取自 references/design/fonts.md 和 references/design/typography.md。所有其他 檔案都參考這些記號；Sinaida 或代理程式不得在此檔案之外引入任何硬編碼的 hex/px 數值。 實作上「其他顏色根本不存在」。
• [] 根據 references/compliance/accessibility-wcag.md 完整通過 WCAG 2.1 AA — 語意化的 HTML、標題階層、鍵盤導覽、可見的焦點、替代文字、 表單標籤/錯誤識別、跳至內容連結、lang 屬性、 對比度（文字和非文字）、320px 重排 — 不僅是簡短清單。
• [] 選單：3–7 個頂層項目，一致的位置，巢狀層級 ≤2 層，可見的 目前位置狀態。
• [] 僅使用 references/design/fonts.md 中的字型。
• [] 根據 references/design/typography.md 的排版 — 真正的模組化字級 （非目測的像素數值），每個區塊之間一致的標題「氛圍」， 正確的行高/字行長度，以及微排版（數字+單位配對和結尾破折號/最後一個單詞前的 不斷行空格、彎曲引號、en/em 破折號、無孤兒標題）。
• [] 根據 references/ux/performance-adaptive.md 的適應性/輕量模式。
• [] 根據 references/compliance/security-checklist.md 的安全標頭 + HTTPS 假設。
• [] 整合 templates/cookie-banner.html，在獲得同意前阻擋非必要的 腳本/Cookie，提供全部接受 / 全部拒絕 / 自訂選項。
• [] 填入此網站真實資訊的 templates/privacy-policy.md（絕不 讓預留文字上線），並且從每個頁面的頁尾連結 — 不要埋在更深的地方。
• [] 根據 templates/404.md 建立的有風格 404 頁面 — 必須在視覺上與 網站匹配，而非泛用的錯誤頁面。
• [] 根據 references/growth/seo-checklist.md 的 SEO 基本要素（語意結構、中繼標籤、 Sitemap、robots.txt）。
• [] 根據 references/growth/agentic-readiness.md 的代理就緒性快速入門： robots.txt 帶有明確的 AI 機器人規則 + sitemap 指令，網站根目錄的簡短 llms.txt，真實的語意化 HTML/標題階層。更深層的 協定/商業項目僅在網站有 API、MCP 伺服器或 商店前端需要公開時才處理。
• [] 僅在此次對話中被明確要求時才套用光暈標誌技術。
• [] 在實作期間檢查 references/design/anti-slop.md，而不只是在最後 — 不撰寫粗邊框卡片元件比取消一個來得便宜。
• [] 每個動畫（懸停、轉場、滾動觸發顯現）都根據 references/design/animation-principles.md 和 references/design/motion-craft.md 建置 — 使用它們的記號， 而不是瀏覽器預設的 ease/自訂目測的貝茲曲線。
• [] 從 references/design/design-resources.md 和 references/growth/agentic-readiness.md 提取的具體設計 靈感/元件，經過改編（而不是複製貼上）後放入 tokens.css 和 網站特定的 HTML/CSS。
• [] 最終的全面性自我審查，使用與審查模式相同的 templates/audit-checklist.md — 在說「完成了」之前，親身走一遍清單。
• [] 對於任何具有購物車、變體選擇或結帳流程的網站： 無障礙錯誤驗證、鍵盤可操作的數量選擇器、購物車總計的 aria-live 區域、明確的錯誤訊息（不僅是邊框變紅）、 以及確認步驟中可編輯的訂單摘要。最低要求；references/compliance/accessibility-wcag.md 中的完整清單 同樣適用。

---

審查模式

1. 使用完整的 templates/audit-checklist.md

根據嚴重性執行每個項目。對於每個發現：

• 記錄證據 — 截圖文字、控制台輸出、網路面板結果。不要說 「按鈕對比度不足」，而要說「'立即訂購' 按鈕：#4A90D9 背景上的 #FFFFFF 文字 = 對比度 2.8:1（需要 4.5:1）」。
• 使用 references/compliance/risk-matrix.md 評分 — 每個發現的影響 × 可能性，然後 查找組合評分（重大/高/中/低/極低）。

2. 產出 templates/audit-prd.md 中定義的交付成果

這必須儲存為一個實際檔案，而非僅是聊天輸出。格式：

1. 執行摘要 — 一句結論：「站點符合基線要求，但有 3 個高風險 無障礙問題和 1 個中風險安全問題。」
2. 編號的發現 — 每個發現一個區塊：
   F-001 | [評級] | [標題]
   位置：精確路徑/元件
   發現：「[對證據的詳細描述]」
   建議：「[具體修正]」
   參考：accessibility-wcag.md Success Criterion 1.4.3
3. 風險摘要表格 — 可排序的發現清單表格（id、評級、標題）。
4. 運作良好的項目 — 至少指出 2–3 件做得正確的事。 如果一項也找不到，重新審查；即使是表現最差的網站 也幾乎總是有一個向客戶展示的良好做法。

3. 在輸出之前，始終檢查

• 是否所有發現都附有特定的、可重現的證據？
• 評分是否基於矩陣，而不是感覺？
• 是否明確提到了至少一個優點？
• 交付成果是否儲存為一個實際檔案（審查.md / 審查.html / 審查.pdf）？