個人網站（Personal Website）

核心規則

不要直接進入程式碼。把網站視為一個分階段參考圖驅動專案：

內容與風格鎖定
參考圖鎖定
素材拆分清單
素材生成審核
高保真複刻與 QA

使用者可見流程預設有四個阻塞式確認：

確認完整的內容與風格 brief，包括站點形態、section 規劃、內容充分性、以及已選擇或使用者提供的視覺方向
在一致性、節奏和可實施性審查之後，確認參考圖組
生成或查找新素材前，確認素材拆分清單
頁面程式碼實現前，確認已生成/已整理素材和複刻執行 brief

參考圖組確認後，不要直接進入實現。先檢查每張已確認參考圖，產出給使用者看的素材拆分清單，並等待確認。清單確認後，只生成、查找或整理清單裡批准的素材。素材完成後，列出最終路徑、檢查結果和簡短複刻執行 brief；等待使用者接受、要求重新生成，或修改拆分。只有這一步確認後，才能開始高保真複刻。

舊的 lightweight pre-build design note 合併進素材審核輸出，變成一份簡短的複刻執行 brief。它不是額外獨立確認點：使用者在程式碼前同時確認素材結果和複刻執行 brief。

不要把後續階段壓縮成普通前端構建。已確認參考圖不是 moodboard。寫程式碼前，每張參考圖都必須有已確認的 render contract，並拆成程式碼負責區域、融合場景、獨立媒體、身分/真實來源素材、視覺錨點，以及最終來源和狀態決策。

硬停止條件：在素材拆分清單已確認、批准素材已生成或整理、素材審核與複刻執行 brief 已接受之前，不要建立或修改 HTML、CSS、JS、React、route 或 component 檔案。只在進度提示裡說「我會拆參考圖」不算完成。

精緻參考圖驅動專案還要執行證據硬停止條件：讀取 references/evidence-gate.md。缺少要求的落盤證據時，狀態只能是 not verified，不能寫 pass。使用者要求跳過確認暫停，只代表門檻通過後自動繼續；不代表自動通過、靜默替換參考圖、跳過審查或無證據完成。

如果使用者只有部分資料，先審查缺口，並優先建議更省力的資料輸入方式，而不是馬上要求使用者手寫所有內容。如果使用者已經有確認過的內容、參考圖和素材，可以直接跳到相關審查、素材審核或複刻階段，但程式碼前仍要保留相同確認邊界。

執行紀律

在階段之間推進時，說明當前假設、下一個可驗證目標，以及完成它的檢查方式。如果請求有多種解釋，先把選項說清楚並詢問，再進入具體方向。

保持修改克制：

不要添加使用者沒有要求或確認的 section、互動、內容、route、素材類型或配置
編輯現有專案時，只改已確認範圍內必要的檔案，並匹配專案現有風格
只移除本工作流新增後變成無用的程式碼、素材或 import；無關的既有死程式碼只提及，不刪除
優先使用能讓下一階段可靠推進的最小設計說明、素材清單、prompt 組或實現改動
多步驟工作要有足夠具體的成功標準，避免靠猜測推進
每次只實現並驗收一個 section slice；只檢查了部分 section 時，不得宣稱多個 section 已通過

語言與本地化表達

使用者可見引導要匹配使用者主要語言。使用者用中文提問時，進度提示、階段銜接、確認請求和選項標籤都使用中文，例如 第一步 / 內容與風格鎖定、接下來進入第二步。使用者用英文提問時，使用英文，例如 Step One / Content and style lock、Next I will move to Step Two。如果對話中英混合，優先遵循使用者最新的明確偏好，或最近一條實質請求的語言。

面向使用者的提示、階段轉場、確認請求和選項標籤預設使用中文；必要的檔名、命令、欄位名和技術術語保留英文，以免改變執行契約。

階段名也要完整翻譯。中文使用者應寫 第五步 / 高保真複刻與 QA，不要寫 Step Five / Build and QA 這類中英混合標籤。

內建 Companion Skills

本 skill 內建 companion reference，因此工作流不依賴使用者額外安裝其他 skill：

references/imagegen-frontend-web.md：用於第二步個人網站參考圖生成硬契約
references/visual-quality-gate.md：用於第二步和第五步的真實意義、層級、留白、裁切、重疊、作者性與 fresh-context 審查
references/evidence-gate.md 與 scripts/verify_identity_run.py：用於不可覆蓋參考哈希、逐 section 截圖證據、拓撲歸屬和確定性完成校驗
references/reference-asset-splitter.md 與 references/split-patterns.md：用於第三步三軸素材裁決和真實糾錯案例
references/frontend-app-builder.md：用於素材審核後的高保真實現和 QA

個人網站參考圖生成階段，無論是否安裝獨立 imagegen-frontend-web，都必須讀取 references/imagegen-frontend-web.md。目標是精緻、專業、有辨識度或 Awwwards 級時，第二步和第五步還必須讀取 references/visual-quality-gate.md。這些內建檔案是本工作流的硬契約；獨立 skill 可以補充更廣的創意詞彙，但不能覆蓋已確認 brief、style fingerprint、meaning contract、視覺品質門檻、素材預算和可實施性規則。

素材裁決階段，若已安裝 reference-asset-splitter 就使用安裝版，否則使用內建版本；兩邊必須保持同一套 classifier 和案例。使用者已確認 brief 與本 skill 的硬階段邊界優先級高於 companion 預設規則。第五步仍優先使用安裝版 frontend-app-builder，內建副本作為 fallback。

如果 companion skill 沒有安裝，不要卡住，不要假裝 @skill 呼叫可用，也不要為了繼續流程就要求使用者安裝。讀取本包內建 companion reference，並把它作為本地最低執行契約。

只有當使用者明確想要可獨立安裝的元件時，才討論單獨安裝 companion skill。正常路徑裡，安裝 identity-skill 一個 skill 就應該足夠。

如果沒有任何圖片生成工具，寫可複製的 prompt，讓使用者貼到 GPT web Image 2 或其他圖片工具，或請使用者提供自己的參考圖。如果使用者完全跳過參考圖，則把構建視為較低 fidelity，並明確說明視覺 QA 只能對照文字 brief，不能對照已接受參考圖。

階段提示協議

每個使用者可見階段結尾都要給出清晰進度提示：

當前進度：第一步 / 階段名稱
已完成：剛產出的具體結果
仍缺失或存在風險：只列真正影響推進的阻塞點
使用者現在可以做什麼：確認、修改某個命名部分、提供缺失資料、或選擇選項
下一步：說明下一階段名稱以及會發生什麼

不要讓使用者停在一個隱含的斷點。如果流程會在沒有阻塞確認的情況下繼續，明確說明會繼續以及原因。

第一步：內容與風格鎖定

先判斷適用哪條內容路線。不要讓使用者手動重複輸入那些可以從已提供檔案、連結、履歷、profile、筆記、寫作樣本、專案文件、截圖或現有網站中讀取的資訊。

資料輸入路線

使用以下路線之一：

資料充足路線：使用者提供了履歷、CV、LinkedIn、個人主頁、作品集、專案連結、Notion/Markdown 文件、個人簡介、媒體包、社交主頁、寫作歸檔或類似材料。讀取可存取內容，提取已確認事實、可用於 section 的內容單元、連結、素材和缺口。只問會影響網站的定向補充問題。
簡略 brief 路線：使用者給了目標或身分，但支援材料很少。先邀請使用者提供更省力的輸入，例如履歷、現有介紹、專案連結、寫作連結、照片、參考網站或截圖。如果使用者不想提供檔案，再使用下面的引導問題。
從零開始路線：使用者沒有材料，或希望從零梳理。把引導問題一次性集中提出，不要一題一題長訪談。
快速 demo 路線：使用者明確強調速度或粗糙原型。可以使用輕量 mock 內容，但所有編造的事實、專案、引用、指標、連結或個人簡介細節都必須標記為佔位內容，正式版本前需要替換。

引導問題路線應緊湊收集：

目標：履歷、求職、作品集、創作者/個人 IP、顧問、創始人/高階主管介紹、演講/媒體頁，或其他目的
受眾：誰會訪問，看完後希望他們做什麼
定位：身分標籤、能被記住的一句話、語氣邊界
證明材料：經歷、專案、寫作、產品、客戶、媒體報導、演講、獎項或其他證據
專案細節：每個重要專案的背景問題、你的角色/行動、結果、連結/媒體，以及希望別人記住什麼
素材和邊界：頭像、logo、截圖、文件、連結、不可用或敏感內容，以及不能生成或不能誇大的內容
使用者偏好：站點資訊密度、是否傾向單頁或多頁、喜歡的參考、不喜歡的風格、後續維護意願

內容與站點形態文件

對於精緻個人網站、個人 IP 網站、作品集、Awwwards 級方向，或任何設計品質重要的場景，進入圖片前先產出內容與站點形態文件。快速 demo 可以保留同樣結構，但寫得更短。

文件應包括：

資料覆蓋：使用了哪些檔案、連結、筆記或使用者回答
已確認事實：只寫使用者提供或來源支援的事實
未確認草稿內容：清楚標記 agent 提議的文案、範例、佔位、推斷 claim 或缺失連結
站點目標與受眾：這個網站要完成什麼、給誰看
訪客記憶點：訪客應該記住的一到三件事
站點形態推薦：單頁、一頁履歷、首頁加 case study、多頁作品集、創作者 hub、顧問 landing page，或其他形態
推薦理由：為什麼這個形態適合使用者目標、內容量、證明深度和維護意願
可選替代方案：可行但不如主推薦的更輕或更完整結構
section 規劃：每個 section 的目的、必需內容、內容單元、連結/素材和狀態（ready、needs detail、placeholder 或 cut）
內容充分性風險：空泛、模板化、虛假、擁擠、缺少支撐或不值得保留的 section

站點形態必須根據使用者目標和資料密度推薦，不要預設套五六個 section。履歷或求職用途通常只需要單頁或一到兩頁。深度作品集可能需要 case-study route。創作者、創始人或顧問網站只有在內容支撐時，才需要更強敘事或轉化路徑。

用於參考圖的所有內容都必須來自使用者提供或使用者明確批准。agent 可以提出內容來補缺口，但這些內容只是草稿，不是已確認事實。不要因為內容寫得合理或好看，就把 agent 提議內容當作已確認。

第二步確認前，先鎖定每個可識別人物、公司、產品、作品、出版物或專案的證據來源策略。儘早收集可用的使用者素材或官方素材，讓參考圖直接圍繞真實證據構圖；不要先確認一個更強的生成佔位構圖，再計劃在鎖定後替換成視覺重量、比例或主體不同的官方素材。

風格推薦

內容和站點形態足夠清楚後，基於內容、使用者偏好、受眾、網站目的和已有參考，推薦最多三種視覺方向。使用者可以選擇一種、混合多個選項，或提供自己的視覺方向/參考。

風格選項必須是視覺概念，而不只是定位標籤。不要只給「國際學生精品履歷」「金融科技產品研究員」「AI + Finance Portfolio」這類只區分受眾或職業敘事的選項。這些標籤可以解釋為什麼適合，但選項本身必須讓使用者在生成圖片前就能想像頁面長什麼樣。

每個風格選項應簡要覆蓋：

視覺概念名：用短標籤描述畫面氣質，而不是只寫個人角色
情緒和定位匹配
色彩方向：3-5 個具體顏色或顏色角色，必要時給 hex
字體氣質：display/body 的字體性格和粗細對比
首屏構圖：姓名、headline、頭像/媒體、CTA、證明線索分別如何出現
佈局密度與 section 節奏：單頁克制、editorial 節奏、bento 證明塊、case-study 深度，或其他具體節奏
圖片或素材處理方式：頭像裁切、專案截圖、文件卡片、數據視覺、editorial 照片、抽象背景或程式碼渲染圖形
UI chrome 與導航感覺：header 密度、wordmark、CTA 形狀、邊框、圓角、icon 風格和 active state
動效性格
使用者會看到什麼：用一句話描述螢幕直觀印象
為什麼適合這個人和這種站點形態
主要風險或取捨

如果某個風格選項不能被描述成一個可見的網站畫面，先重寫再展示給使用者。如果使用者目標是職業定位，要把定位翻譯成視覺決策，而不是讓選項標題承擔全部表達。

必要時使用這個緊湊的風格選項格式：

選項 A — Editorial Resume / 墨色紙感
色彩：暖白 #F7F3EC、墨黑 #171717、灰藍 #6B7280、強調藍 #2563EB。
字體：克制 serif display + 乾淨 sans body；專業但不裝飾化。
首屏：姓名和一句定位左對齊，置於大面積紙感留白中；右側是安靜裁切的頭像或 LinkedIn 風格照片，下方放兩個證明連結。
節奏：單頁履歷流，section 平靜，專案證明用小型卡片承載。
直觀感受：像一份精緻的國際候選人 editorial CV，而不是創業公司 landing page。
風險：如果使用者想要更強個人品牌，會顯得辨識度偏弱。

在使用者確認完整內容與風格 brief 之前，不要生成參考圖。如果使用者選擇了風格選項且沒有反對內容文件，只有在你的提示明確說明「這會同時鎖定內容和風格」時，才把該回覆視為第一次阻塞確認。

使用這個第一步收尾提示形態：

當前進度：第一步 / 內容與風格鎖定
我已經準備好：資料來源摘要、已確認事實、站點形態推薦、section 規劃、內容風險和風格選項。
請確認或修改：
1. 站點形態和 section 規劃
2. 所有標記為未確認的內容
3. 視覺方向：選擇一個選項、混合多個選項、修改色彩/佈局，或提供你自己的參考
確認後，我會進入第二步，生成或準備各 section 的參考圖。

第二步：參考圖鎖定

使用 section 級參考圖作為視覺事實來源。

參考圖 prompt 必須基於已確認的內容與風格 brief：已批准內容、已批准站點形態、已選擇或使用者提供的視覺方向、全局 chrome 規則，以及每個 section 的具體內容單元。使用者期待高品質個人網站時，不要基於薄 brief 或未批准的 agent 提議內容生成參考圖。

本階段始終讀取 references/imagegen-frontend-web.md。如果獨立 imagegen-frontend-web 可用，在內建個人網站硬契約下使用它補充更廣的 art direction。參考圖組必須做到每個已確認 section 一張橫向圖、強構圖、統一個人 IP 世界，以及可以真正實現的圖片拓撲。

如果使用者偏好 GPT web Image 2，則為使用者寫可複製過去的 prompt，而不是直接生成圖片。

參考圖生成計劃

生成任何 section 前，先準備一份簡潔的參考圖生成計劃。它屬於第二步內部 artifact，不增加新的使用者確認門。已有專案目錄時，把它寫入還原文件或小型 docs/reference-production-plan.md；沒有目錄時，保留在第二步工作輸出中。

先鎖定整組共用的 style fingerprint：

精確色彩角色與 hex 值
display/body/label/nav 字體角色和相對字號
全局 chrome 幾何、邊框/圓角/陰影語言和 CTA 家族
材質、光線、紋理、照片調色、插畫/icon 語言
密度範圍、間距節奏、畫布比例，以及最多一個可選 signature motif
不允許漂移的常量，以及每個 section 允許變化的一到兩個維度

然後給每個 section 指定一份 render contract：

C0 code-only：字體、佈局和簡單幾何，不需要 raster 素材
C1 integrated-scene：程式碼 UI 疊加在一張融合場景上；場景可以 full-bleed，也可以是有邊界的視覺島
C2 independent-media：程式碼外殼加一到三個有獨立意義的照片、截圖、封面或產品 mock
C3 scene-plus-identity：一張融合場景，加一張真實來源或 replace-later 的頭像、logo、官方產品圖

每份 render contract 必須寫清：程式碼負責內容、允許的全站 shared material、融合場景邊界、獨立媒體槽、身分/真實來源素材、禁止融合項、回應式行為、文字安全區、素材預算，以及拓撲歸屬（section-specific 或命名並說明理由的共享結構）。高品質目標還必須補齊 references/visual-quality-gate.md 的 meaning 欄位：三秒資訊、個人證據、作者性設計動作、焦點層級、閱讀路徑、留白地圖、語義圖形含義、重疊清單、封閉排除區和首屏有效載荷。C0 code-only 表示 0 個 section 專屬 raster；如果紙面或掃描條屬於已鎖定 fingerprint，可以復用一到兩個明確聲明的全站材質。但它不代表一個內容不足、只靠大字撐滿高度的 section 已經完成：除大字外還必須有第二個來自內容的設計決策，否則縮短、合併或重新設計該 section。每種 shared material 只生成一次、全站只計一次。預設每個 section 一個主視覺焦點、最多一張融合場景、section 專屬 raster 單元不超過三個；只有使用者明確批准 dense evidence-wall 方向時才能超出。

先生成最能定義身分的 anchor section，通常是 Hero。後續 section 在同一批次生成；圖片工具支援參考輸入時，必須把 anchor 作為視覺指導，否則逐字復用同一份 style fingerprint。anchor 與後續圖片之間不增加額外確認門。

預設輸出：

每個 section 一張橫向參考圖
不要長豎版整頁拼貼
不要細碎難讀的多 section board
所有 section 保持一致的個人 IP 世界觀
參考圖應像真實網站截圖，不像海報
程式碼負責的文字和控件要能與 raster 材質乾淨分離
靜態融合場景保持為一個完整視覺單元；獨立媒體槽之間不得出現跨邊界陰影、反射或遮擋

把參考圖組交給使用者確認前，執行四重審查：

視覺意義審查：執行 references/visual-quality-gate.md 的全部硬門檻，包括三秒傳達、單一第一焦點、有目的的元素清單、個人特異性、完成的構圖、密度上下限、有意義留白、圖形語義、裁切完整性、重疊安全與回應式首屏有效載荷。一個 section 即使漂亮或可實現，只要想法、證據或構圖薄弱，仍然失敗。
一致性審查：把每張圖與精確 style fingerprint 對照，檢查全局導航、字體角色、色板、間距、框體語言、圖片調色、motif 和移動端邏輯。必須讓人一眼看出屬於同一網站。
節奏審查：列出每個 section 的構圖骨架並檢查 variation envelope。可以有節制地變化 section 任務、尺度、對齊、裁切或密度，但不要強迫每屏成為全新視覺概念。運行 grey-block test：照片變成灰塊後，至少一半 section 仍應通過字體、佈局、色彩和結構保持設計感。
可實施性審查：把每張圖與 render contract 對照。如果程式碼文字與 raster 材質不可分離、獨立素材共享硬陰影/遮擋、身分素材被融進生成場景、回應式重排需要在單張圖內部搬動像素、未經批准超過素材預算，或出現計劃外圖片島，該 section 失敗。

參考圖拓撲失敗時使用 redesign-required：保持全站 style fingerprint，只重新生成失敗 section，再交給使用者確認。不要把不可實施的參考圖硬塞進第三步，用脆弱切片或低保真程式碼替代來補救。

審查通過的參考組確認後，把它複製進新的不可覆蓋目錄，例如 references/locked/v1/，並把每張圖的 SHA-256 寫進 docs/identity-evidence.json。不要覆蓋已鎖定檔案；重新生成或重構必須建立新版本並重新執行受影響的第二步審查。

當設計品質重要，或使用者要求 taste guidance 時，同時讀取 references/taste-calibration.md 和 references/visual-quality-gate.md。taste 樣本負責校準可選視覺世界，品質門檻負責判斷這個世界是否真正表達清楚並完成了設計。

使用這個第二步收尾提示形態：

當前進度：第二步 / 參考圖鎖定
我已經準備好：全站 style fingerprint、每個 section 的 meaning 與 render contract、參考圖，以及視覺意義/一致性/節奏/可實施性審查。
請確認或修改：
1. 接受這些圖片作為構建目標
2. 指定要重新生成的 section
3. 在構建前調整視覺方向
圖片確認後，我會進入第三步，正式產出素材拆分清單：哪些留在程式碼裡、哪些是一張融合場景、哪些是獨立媒體、哪些必須用真實來源、哪些需要 blocked、replace-later 或 redesign-required。我會等你確認後再生成或查找新素材。

第三步：素材拆分清單

參考圖組確認後，先檢查已接受參考圖，不要生成素材，也不要寫程式碼。本階段產出給使用者看的素材拆分清單，並停下來等待確認。

產出清單前，如果已安裝 reference-asset-splitter，讀取它和 references/split-patterns.md；否則讀取內建 references/reference-asset-splitter.md 與 references/split-patterns.md。按順序執行三軸 classifier：邊界顆粒度、渲染介質、圖片層級。不要把三件事壓成一句「看起來很複雜」。

使用固定衝突優先級：真實身分/來源素材；live semantic 內容與無障礙；獨立互動/替換/更新/回應式重排；code whitelist 與 raster signals；fusion 關係；素材預算；最後才是審美偏好。視覺複雜度本身既不能強制細拆，也不能證明程式碼可以高保真複刻。

目標是實用，不是過度規格化：告訴使用者哪些可見部分應該留在程式碼裡，哪些需要單獨生成或收集素材，哪些需要透明/前景素材，哪些屬於背景，哪些真實資產不能偽造，以及哪些判斷一旦猜錯會影響最後複刻效果。

本階段建立或更新一個可見還原 artifact。可接受形式包括：

docs/restoration-plan.md，合併參考圖對應、素材 manifest 和後續複刻執行 brief
docs/reference-to-build-map.md 加 docs/asset-manifest.md
如果倉庫已有 docs 約定，也可以使用等價的專案內文件

artifact 必須在素材生成前、頁面程式碼編輯前落地。它必須列出每張已確認參考圖和每個 section/page。只在聊天裡總結、隱藏推理或用一句進度提示說明，不滿足要求。

給使用者看的素材拆分清單應比內部 artifact 更短。每個 section 包括：

程式碼負責元素：文字、導航、按鈕、佈局、簡單形狀、標籤，以及需要可編輯的動效
全站 shared material：可選的紙面、顆粒、掃描條或其他只生成一次並復用的 fingerprint 材質，或 none
融合場景素材：整段背景或有邊界的融合場景、紋理、地圖、照片場、桌面世界、卡片拼貼，或 none
獨立媒體素材：頭像、產品 mock、截圖、照片、封面、單體插畫，或 none
已有真實素材：使用者提供照片、logo、產品截圖、官方素材，或待複製的來源檔案
可生成素材：安全可生成的氛圍圖、裝飾物、抽象產品 mock、背景或 stand-in
blocked、replace-later 或 redesign-required：真實人物、官方品牌/logo/產品圖、帶 claim 的缺失截圖，或無法忠實分層的參考圖拓撲
為什麼重要：如果素材邊界判斷錯誤，會造成什麼複刻 fidelity 風險

素材邊界規則

準備第三步素材拆分清單和第四步素材生成審核時，使用以下規則。

參考圖存在後、寫程式碼前，把三個判斷軸分開執行：

邊界：只有獨立互動、替換/更新、獨立語義或回應式重排才強制細拆。移除程式碼節點和強制獨立節點後，把存在疊壓、跨物體陰影/反射、連續紋理、透視、光線或材質關係的靜態 raster 物件合併。同一個 fusion group 預設一張素材，不看裡面能數出幾張卡片。
介質：只有 live text、DOM 佈局、純色、普通邊框/圓角/陰影、簡單 CSS gradient、標準 icon、基礎 grid/dot 和簡單 SVG 幾何可以 code-native。照片、不規則材質、手寫/筆刷、複雜插畫、密集 UI/product mock、自然紋理、3D、真實光影/反射或共享 raster 效果必須用圖片。既需要 live 行為又需要 raster fidelity 時，用 hybrid：圖片負責視覺，程式碼負責外殼、文字和互動。
層級：integrated-scene 是與 section 綁定的一張融合視覺，可以 full-bleed，也可以只佔 Hero 右側；independent-media 是可獨立替換的照片、截圖、封面、mock、頭像或單體插畫。透明與否不分類。

預設每個 section 最多一張融合場景，raster 單元總數不超過三個。獨立媒體槽各自成素材，融合靜態群保持一張。所有最終文字、導航、按鈕、表單、事實數據和互動留在程式碼裡。允許整屏藝術背景，不允許把程式碼負責內容一起烘成整屏截圖。

當 live text 無法從材質裡分離、互動元素與另一層共享硬陰影/遮擋、真實身分素材不可逆地融入生成場景、移動端需要在單張圖內部獨立搬動像素，或重組依賴脆弱像素接縫時，使用 redesign-required，不要強拆。保持 style fingerprint，只把這個 section 退回第二步重新生成。

每張已確認參考圖都要在可見還原 artifact 中記錄 reference-to-build map：

Reference: 01-hero.png
Code layer: nav、headline、subhead、CTA group、portrait frame、proof labels
Integrated scene: hero-finance-desk.png，16:9，full-bleed，允許深色遮罩
Independent media: portrait.png，右側 24% 寬；product-card-mock.png，下方中間 22% 寬
Must preserve: 深色桌面/金融照片氛圍、左側大標題比例、右側頭像卡、綠色 CTA、頂部導航間距
Allowed deviation: 生成圖裡的圖表標籤改為程式碼渲染的已確認文案
Risk trigger: 未確認的真實公司標記或用戶頭像需要先確認

每個 section 都必須覆蓋所有有意義區域：semantic role、boundary triggers、code whitelist 結果、raster signals、fusion group、owner（code 或 asset）、placement（integrated-scene、independent-media 或 none）、reuse scope（global 或 section）、provenance、responsive mode、decision/status（ready、generate、find/copy、code-native、replace-later、blocked 或 redesign-required）、source/action 和 final path。若沒有 section 專屬圖片，直接寫清原因，並單列復用的 shared material。

記錄素材 manifest（asset、role、boundary trigger、raster signal、fusion group、placement、reuse scope、provenance、reference box、aspect ratio、relative size、responsive mode、status、final path），這樣複刻時可以把每個素材放進固定寬高比容器，而不是讓圖片原始尺寸驅動佈局。

使用這個第三步收尾提示形態：

當前進度：第三步 / 素材拆分清單
我已經準備好：reference-to-build map、素材決策清單和初版 asset manifest。
請確認或修改：
1. 哪些元素保持 code-native
2. 哪些融合場景和獨立媒體要生成、複製或 replace-later
3. 哪些真實頭像、logo、產品截圖或官方素材不能生成
4. 清單裡真正存在歧義的互動或替換假設
確認後，我會進入第四步，只生成或整理已批准的素材。我還不會編輯頁面程式碼。有用時我可以並行處理已批准的素材組；如果你希望順序執行，請直接說明。

第四步：素材生成審核

素材拆分清單確認後，只生成、複製、查找或整理已批准的素材。然後給使用者展示素材結果和簡短複刻執行 brief。使用者接受素材審核前，不要開始頁面程式碼實現。

素材審核應包括：

每個 ready 素材的最終路徑
每個素材對應哪個 section 和哪個可見元素
來源：生成、使用者提供、官方/複製、code-native，或 replace-later
檢查結果：accepted、needs regeneration、weak but usable with named deviation、blocked，或 replace-later placeholder
重現素材所需的 prompt/source notes

每個圖片素材只有兩種合法來源：

第一步 intake 中已經收集到的真實素材，例如使用者照片、logo、產品截圖或媒體檔案。第四步不要臨時要求使用者補新素材，除非使用者自己選擇提供；到這一步仍未提供的內容，要生成 stand-in、使用 code-native placeholder、標記 replace-later，或在會造成誤導時標記 blocked。
新圖片生成：必須錨定對應參考區域。寫任何生成 prompt 之前，先重新打開已確認參考圖，把目標區域轉錄成視覺清單：場景類型（紙質卡片拼貼 / 攝影場景 / 扁平插畫 / UI mock / 紋理場）、每個主要物件及其大致位置、色板 hex 值、光線、材質、留白佈局。生成 prompt 必須從這份轉錄寫出——同場景類型、同物件清單、同構圖同色板——絕不能從素材名或拆分清單的一行摘要寫。如果出圖工具支援輸入圖片，同時把參考區域作為視覺參照附上。只寫內容類目（「創作者坐在桌前有筆記本和卡片」）而沒有轉錄的 prompt 是缺陷：它等於授權模型自己發明一個不同的場景。素材內的佔位文字要求寫 "abstract unreadable placeholder bars and squiggles"——不要用 "greeked" 這個詞，出圖模型可能把它字面理解成希臘語文字。

已確認參考圖是構建目標和 QA 基線，不是素材來源。不要把參考圖區域 crop、screenshot、slice 或 extract 到構建裡；裁切會繼承低解析度、烘焙文字和破邊。manifest 裡沒有 extract 狀態。參考區域像需要素材時，用視覺描述重新生成該素材。

素材生成完成後，聚集所有素材為使用者審查。素材路徑必須最後可用於 public/ 或 assets/。等待使用者批准素材、要求重新生成，或修改拆分。

使用這個第四步收尾提示形態：

當前進度：第四步 / 素材生成審核
我已經準備好：所有已批准素材的最終路徑、檢查結果和複刻執行 brief。
請確認或修改：
1. 接受這些素材準備構建
2. 要求重新生成特定素材
3. 修改遺漏或錯誤的拆分決策
確認後，我會進入第五步，基於已確認參考圖、已確認素材和複刻執行 brief，開始高保真頁面程式碼實現。

第五步：高保真複刻與 QA

素材審核接受後，基於已確認參考圖、已確認素材和複刻執行 brief，開始建立或編輯頁面程式碼。

本階段優先使用安裝版 frontend-app-builder，內建 references/frontend-app-builder.md 作為 fallback。高品質目標還必須讀取 references/visual-quality-gate.md 進行程式碼實現與 QA。

實作方法：

從最大 section（通常是 Hero）開始，一次實現一個 section
只在程式碼中建立參考圖裡的功能和版型
使用參考圖作為精確構圖校準，而不是建議
對齊參考圖時，使用視覺比較（螢幕截圖取樣或肉眼檢查）而不是像素完美盲目對齊
排版必須使用參考圖中的實際字重和字距，而不是預設值
程式碼中的 live 文字必須是使用者確認的內容，不是圖片中的佔位文字
素材路由到對應的最終路徑
每個 section 完成時，比較程式碼實作、參考圖、素材和複刻執行 brief。找出一致和不一致之處，並判斷簡短 QA：pass、needs refinement、needs redesign。不要同時標記多個 section 已通過，除非每個都已個別驗證。
如果 QA 發現 section 與參考圖顯著不同，先解決不一致處，不要繼續實作下一個。
如果是替代佈局或使用者要求偏離，更新複刻執行 brief 並標記偏離。
當調整中發現現有素材不足時，在素材增益和程式碼解決方案之間做權衡：如果素材問題可以透過程式碼解決方案可靠修復，選擇程式碼；否則標記素材問題並退回素材生成階段。
除非複刻完成且符合參考圖，否則不要增加新功能或改進。除非使用者明確要求，否則不要優化未要求的效果或動效。

實作所有 section 後，執行完整的 QA 審查：

忠實度審查：將每個實作與對應參考圖進行比較。程式碼實現的一致性如何？所有內容是否存在？素材位置和比例是否接近？是否存在應該保留但在實作中遺失的參考圖細節？
內容審查：所有文字是否源自確認的內容？所有連結是否有效？所有素材是否顯示且使用正確？是否使用了未經批准的預留位置或代理內容？
互動審查：導航、表單、按鈕和任何互動是否如預期運作？頁面是否可瀏覽？是否存在死連結或未實作的功能？
回應式審查：佈局是否在各種螢幕尺寸上合理？文字在小螢幕上是否可讀？素材是否適應而不會造成難看的溢出或間距問題？
品質審查：如果品質很重要，根據 references/visual-quality-gate.md 進行評估。構圖是否完整？是否存在有意義的留白？字體渲染是否與參考圖相符？佈局節奏是否正確？

完成所有審查後，向使用者提供完整的 QA 總結。標記任何偏離、未解決的問題以及後續維護建議。

使用這個第五步收尾提示形態：

當前進度：第五步 / 高保真複刻與 QA
我已經完成：每個 section 的實作和完整 QA 審查。
QA 結果：
- [section 1]: pass / needs refinement / needs redesign
- [section 2]: pass / needs refinement / needs redesign
- ...
偏離：
- [列出參考圖與實作之間的任何已記錄差異]
已知問題：
- [任何未解決的問題或預留位置]
後續步驟：
- [如果存在需要改進的地方] 改進
- [如果是 pass] 維護建議或部署說明

個人網站：參考圖鎖版，1:1 高保真復刻