餐廳示範建置器
建立一份以證據為基礎的銷售示範，讓老闆能認出自己的餐廳，並讓顯而易見的線上機會缺失更為突出。將此示範視為餐廳網站第一個有用的版本，而非僅是貼上餐廳名稱的通用主題。
在進行實質研究、設計、影像製作或實作之前，請先閱讀 references/demo-playbook.md。僅使用與請求相關的章節。
選擇任務模式
在行動之前，先確定請求的模式：
- 分析： 傳回有來源依據的概念、理由、頁面結構、影像方向、菜單計畫和驗證缺口。除非被要求，否則不要編輯專案檔案。
- 建置： 研究餐廳，建立或準備適當的素材，實作可運作的示範，執行它，並視覺驗證桌面和行動裝置檢視。
- 刷新： 檢查現有示範和當前公開事實，然後僅更新過時或薄弱的部分，並重新執行視覺驗證。
僅在多家企業同名且無法推斷出正確位置時，才要求澄清。否則，先檢查本機線索資料和公開來源。
基於證據工作
- 在瀏覽之前，先檢查當前工作區。搜尋線索匯出、簡報、現有示範和設計素材，以取得餐廳名稱、地點、地點ID和URL。
- 驗證當前公開事實，因為餐廳資訊經常變動。檢查餐廳擁有的網站和社群頁面、Google商家檔案或地圖資料、當前菜單或訂購頁面、近期評論，以及相關的官方旅遊或商會頁面。
- 記錄名稱、地址、電話、營業時間、評分、評論數、類別、服務、菜單項目、價格、活動、線上訂購、社群連結，以及任何提議用於示範的場地或外觀影像的來源和信心度。
- 在工作時，將內容分為三個標籤：
- 驗證事實： 直接由當前來源支援。
- 合理推論： 由評論中的重複模式或地點背景所支援。
- 創意提案： 為示範建立的標語、藝術方向、佈局或活動構想。
- 解決衝突的事實，優先使用最近由業主控制的來源（如果可能）。將未解決的衝突放入業主驗證清單。
- 當餐廳身份、網站問題、菜單可用性、核心聯絡資訊、主要受眾證據和重複評論主題已充分確立時，停止研究。對於分析模式，偏好一組強而有力的來源，而非詳盡的目錄搜尋；列出未解決的細節，而不是延遲簡報。
切勿發明菜單項目、價格、營業時間、獎項、折扣、外送、預約、活動日程或無障礙聲明。除非目的地和服務是真實的，否則不要添加看似可運作的命令按鈕。
定義一個商業定位
從證據中選擇一個主要受眾和一個主要轉換目標。典型受眾包括過路旅客、在地家庭、早餐常客、運動酒吧顧客和晚間團體。典型目標包括查看菜單、獲取路線、撥打電話或進行已驗證的線上訂購。
第一個視口必須在五秒內回答：
- 這是哪家餐廳？
- 為什麼訪客應該選擇它？
- 它是否營業？或何時營業？
- 訪客如何查看菜單或到達那裡？
使用餐廳名稱作為 H1。將定位放在輔助文案中。偏好具體的證據，例如時段、招牌菜、地點、營業時間、份量或評論主題，而非「美食」或「新鮮食材」等通用詞語。
路由設計
在餐廳證據、受眾、場合和主要行動確定後，閱讀 references/design-routing.md。建立餐廳輪廓檔案，執行 scripts/select_recipe.py，並將產生的 recipe-lock.json 與示範研究記錄一同儲存。
僅閱讀所選配方參考，然後複製獨立選擇的佈局起手式檔案 assets/layouts/<layout-id>/：
morning-regular： references/recipe-morning-regular.mdhometown-table： references/recipe-hometown-table.mdlocal-tavern： references/recipe-local-tavern.mdoccasion-dining： references/recipe-occasion-dining.md
僅在檢視 V2 庫背後的結構證據、擴展佈局語法或診斷設計不匹配時，才使用 references/layout-research-2026-07-v2.md。早期的 design-research-2026-07.md 和 assets/starters/ 是 V1 歷史，不參與新的示範路由。不要複製參考餐廳的程式碼、照片、文字、標誌、插圖或獨特的完整構圖。
將配方和佈局選擇視為獨立的約束。配方控制受眾、調性、功能和視覺態度；佈局語法控制首區、媒體構圖、證據形式、菜單幾何、區塊幾何和行動裝置轉換。已驗證的餐廳證據繼續控制訂購、預約、活動、營業時間、服務、菜單內容、評論和影像。切勿手動繞過 V2 鎖：當結果錯誤時，請修正輪廓檔案、相容性定義或歷史指紋。
鎖定餐廳品牌色板
在配方和佈局鎖定之後，但在最終視覺樣式之前，每當店面、招牌、標誌、菜單、包裝或內部影像提供可用的身份色彩證據時，使用 $restaurant-brand-palette。將驗證過的 brand-palette.json 與 recipe-lock.json 一同儲存並預覽。
將色板、配方和佈局視為獨立的鎖。色板控制 CSS 色彩角色和比例；它不會改變受眾、功能、首區語法或區塊幾何。在匯入代碼之前，需要色板技能的 handoff 階段。將驗證過的代碼對應到 CSS 變數，並且在實作期間不要引入臨時替換的十六進位值。
如果沒有可靠的品牌色彩能在證據審查後留存，讓色板技能建立一個清楚標示的配方備用方案。不要聲稱備用方案來自餐廳。在任何代碼變更後重新驗證，並分別檢查照片上的文字效果。
圍繞決策建置頁面
當所選配方沒有指定更好的、以證據為基礎的順序時，使用此預設順序。移除任何缺乏證據的區塊：
- 緊湊的導航，包含「菜單」、「最愛」和「前往」，加上一個高價值的命令。
- 全出血的首區，包含餐廳名稱、一個具體的價值主張、「查看菜單」和「獲取路線」或「撥打電話」。
- 證明條，包含已驗證的評分/評論數、營業時間、價格訊號或市區/地點背景資訊。
- 三到六道精選菜餚，使用已確認的名稱（如果有）；當一道菜缺乏已驗證的真實照片時，使用以文字為主的類別或代表性標籤，而不是發明逼真的食物影像。
- 可讀的 HTML 菜單，包含類別導航。
- 僅在它能闡明業務時加入體驗或時段區塊，例如早餐到深夜、家庭用餐、運動或現場活動。
- 簡短、有來源的評論證明，支援所選的定位。
- 當已驗證的店面照片能實質改善辨識度或尋路功能時，加入到達或外觀區塊。
- 「前往」區塊，包含地址、當前營業時間、電話、地圖/路線和擁有的社群連結。
- 行動裝置固定的行動按鈕，用於最重要的命令。
保持體驗直接且有用。避免為每個區塊使用裝飾性卡片、偽造的預約表單、通用的廚師故事、未經驗證的「城市最佳」聲明和冗長的行銷文案。
建立一致的影像系統
使用 $restaurant-food-image-studio 進行實際的食物參考稽核、影像生成、修復、清單追蹤以及來源與提案的對照表。在完整的示範建置中，先在此處建立餐廳證據和商業方向，然後將已驗證的菜餚候選清單和影像需求傳遞給該技能。將以下原則作為最終網站的驗收合約。
將食物影像工作室清單 V3 demo 驗證視為整合邊界。除非滿足以下所有條件，否則不要將 AI 重新調整的食物素材複製到網站中：它有一個來自同一家餐廳的獨特、已記錄的真實 served-dish-photo；該真實照片已作為影像輸入提供；來源已被路由到一個鎖定的客戶面向攝影系統；兩個規範性的證據表單都已以雜湊鎖定；所有五個 QA 關卡都通過；且當前清單通過 <food-image-skill>/scripts/validate_manifest.py --stage demo。在每次複製輸出之前立即執行該驗證器，並在最終示範 QA 期間再次執行。如果來源、攝影系統、證據記錄或任何 QA 關卡缺失，則保持該插槽以文字為主，或使用單獨驗證的非食物素材。切勿使用菜單描述、庫存照片、合成風格影像或 representative-concept 渲染來繞過此關卡。
偏好真實的餐廳自有影像，因為菜餚身份和氛圍是證據。對於私人的銷售示範，來自地圖、社群頁面、評論平台、目錄和菜單頁面的公開真實照片，即使上傳者未知，也可以用作暫時的事實或構圖參考。記錄來源和不確定性，不要暗示參考權限已清除，並在公開上線前取得批准或替換素材。
使用單獨的關卡。在來源關卡，自動保留獨特的真實菜餚來源、來源相機評估、路由、來源出處和雜湊值。在私人示範關卡，保留來源與設計照片的比較、生成時間、註冊的輸出角度和五個關卡：逼真度、風格一致性、食慾優化、AI 痕跡和網站就緒度。使用者可以稍後檢查任一工件並要求變更。當一張真實的公開照片可信地歸屬於正確的餐廳時，不需要上傳者身份。在公開發佈關卡，需要已清除的替換素材或相關權利持有人的許可，加上業主確認事實準確性。不要暗示記錄的私人或一對一使用授與發佈權。
當不存在當前數位菜單時，讓 $restaurant-food-image-studio 執行其以 Google 地圖為優先的備用方案。將重複的真實菜餚照片分組，並以菜單照片、社群貼文、說明文字和評論提及加以佐證，然後選出三到六個候選項目。重複是選擇訊號，而非銷量證明：預設使用「精選」，並將「熱門」、「最受歡迎」、「暢銷」或確切菜名保留給有依據的主張。
將 AI 用作藝術指導和修復層：
- 在生成之前，檢查每個真實來源並分類其相機視角。
- 保留菜餚類型、食材、份量、烹飪方法、配菜和盛裝容器；將來源視為食物真相，而非強制的最終構圖。
- 為餐廳設定鎖定一個主要的客戶面向相機系列、角度容差、主體比例、裁切、背景、照明方向、等級、鏡頭感和道具政策。
- 將不適合該系統的來源路由到
reference-restage；切勿僅因為是真實的，就保留不合適的俯拍或隨意快照角度。 - 改善曝光、白平衡和來源支援的食慾提示，如自然的金黃麵包皮或可見的褐變，而不改變熟度、痕跡、份量或食材。
- 拒絕塑膠光澤、蠟質紋理、重複、完美幾何、不可能的效果和其他可見的 AI 痕跡。
- 為首區使用寬幅影像，並為精選食物使用一致的
4:3系列。 - 僅生成三到六張精選食物影像；讓完整的菜單保持以文字為主。
- 將不確定的輸出標記為概念影像，並將其納入業主驗證集。
- 將 Google 地圖螢幕截圖和其他第三方原始資料保留在示範頁面之外；僅在內部清單和對照表中記錄它們。
當參考資料未證明其食材時，不要將生成的影像標記為確切的菜單項目。避免不可能的裝飾、誇張的蒸氣或起司拉絲、偽造標誌、生成的菜單文字、過度的完美以及與餐廳矛盾的庫存照片修飾。
使用 $restaurant-exterior-image-studio 進行實際的店面來源稽核、保存規劃、AI 輔助修復或基於參考的重建、清單追蹤、註冊、比較和六部分 QA。在完整的示範建置中，先在這裡決定到達影像的目的和位置，然後將長寬比、焦點、預期放置位置和尋路需求傳遞給該技能。
將外觀影像工作室 demo 驗證視為整合邊界。除非滿足以下所有條件，否則不要將 AI 輔助的店面複製到網站中：當前真實來源證明了招牌、入口、立面幾何、立面色彩和固定特徵；所有輸出面向的區域都已被支援或裁剪掉；保存合約已完成；所有六個 QA 關卡都通過；且 <exterior-skill>/scripts/validate_manifest.py --stage demo 在整合前立即成功。
當食慾是主要轉換目標時，保持以食物為主的首區；除非建築物本身是已驗證的吸引力，否則將外觀影像放置在「前往」區塊附近。將公開平台的原版資料保留在內部，將私人示範輸出標記為照片提案，並保留單獨的業主準確性和出版權限關卡。街景僅供研究使用，官方嵌入或連結除外。
在規劃或放置素材之前，請閱讀 references/demo-playbook.md 中的「外觀和到達影像」章節；讓專業技能控制製作細節。
讓菜單成為核心功能
將菜單建置為結構化的頁面內容，而非
…
[為翻譯而截斷]