餐廳食物圖像工作室
將混合的真實餐廳快照轉換為一個小型、一致的網站攝影套件。將真實照片作為菜餚的事實權威。將餐廳攝影系統作為相機角度、構圖、光線、背景、色彩、裁切及客戶導向呈現的權威。
請勿僅因來源是真實的，就保留一個不佳的角度。當俯拍、雜亂或不一致的快照不符合網站系統時，請使用 reference-restage 以鎖定的客戶導向相機呈現相同菜餚。切勿讓重製改變菜餚的事實。
在進行收集、規劃、提示、生成或審查之前，請先閱讀 references/food-image-playbook.md。複製捆綁的 Manifest V3 和風格鎖定結構，而不是自行發明工作指令。
選擇模式
- 收集： 檢索真實的單一餐廳候選照片並儲存來源紀錄。
- 審核： 驗證餐廳身份、菜餚可見度、來源角度及重製風險。請勿生成。
- 建立： 鎖定一個攝影系統，路由每個來源，為每個真實來源生成一張設計好的照片並保留時間記錄。
- 修復： 在診斷出失敗的關卡後，從真實來源和鎖定的攝影系統重新生成。
- 審查： 自動保留規範的來源/輸出成品以及所有五個 QA 決策。
讓 $restaurant-demo-builder 為完整的示範建立業務證據、受眾、網站佈局和圖像插槽。使用此技能處理食物攝影系統和資產。
保持證據審查非阻塞
將規範的候選、來源以及來源對照輸出的文件視為自動化的證據記錄，而非審批請求。一旦規範的來源文件存在，自動使用 status: recorded、reviewer: workflow 記錄每個符合資格的來源，驗證 generate 階段，並繼續進行圖像生成，無需等待使用者。在輸出 QA 之後，以相同方式記錄規範的比較，並繼續進行私有示範閘門。
僅在以下情況停止：證據或驗證失敗、存在當前的 changes-requested 記錄、來源無法真實支援提議的圖像、或者使用者明確要求當前執行暫停。人工檢查仍可在稍後進行，並可能建立 changes-requested；但它絕非生成的前提。將業主的事實確認和發布權作為單獨的啟動閘門。
強制執行 Manifest V3 合約
要求每個示範食物圖像滿足以下所有規則：
- 綁定一個來自同一餐廳的獨特
served-dish-photo視覺主體。 - 將未修改的來源在本機儲存，並附上平台身份、原始 URL 和 SHA-256。
- 將該真實來源提供給 imagegen。絕不使用純提示的食物生成。
- 記錄
source_assessment.camera_view、客戶導向適合度及隱藏細節風險。 - 在生成前完成一個餐廳層級的
photography_system。 - 僅當來源已符合該系統時，使用
constrained-edit。 - 當相機、構圖或客戶導向呈現必須改變時，使用
reference-restage。 - 在獲得另一個真實視角之前，阻止具有高隱藏細節風險的角度改變重製。
- 僅當另一個實時審核過的
served-dish-photo（來自同一餐廳且具有完全相同的菜餚匹配記錄）時，才接受其作為佐證視角。 - 記錄每個菜餚的轉換計劃和允許的食慾調整。
- 記錄 imagegen 的開始、完成和持續時間。
- 對輸出進行完整解碼，記錄其實際寬度和高度，並根據攝影系統驗證其像素比例。
- 通過五個獨立的關卡：真實性、風格一致性、食慾優化、AI 痕跡和網站準備度。
- 儲存規範的真實來源和來源對照設計照片的成品。
- 在將輸出複製到網站之前，通過 Manifest 的
demo階段。
如果不存在可信的真實菜餚照片，則保持插槽以文字為主，使用一個單獨確認的非食物圖像，選擇另一個有照片的菜餚，或請求業主提供照片。
在擁有相當於 Apify/Masa 的收集器記錄、完整像素解碼、規範候選文件和候選審核之前，將業主提供的照片視為未來獲取候選項，而非視覺主體。Manifest V3 目前僅接受經審核的 Apify Google Maps 和 Masa 照片作為視覺主體。
準備工作指令
建立 output/food-image-studio/<restaurant-slug>/ 目錄，包含 sources/、prompts/、drafts/、selected/ 和 review/ 子目錄。使用：
- assets/image-manifest-template.json 作為
image-manifest.json。 - assets/style-lock-template.md 作為
style-lock.md。
使用小寫 ASCII 檔案名稱。切勿在這些檔案中放置 API 令牌、私鑰或帳戶機密。
在命令中，從此技能的可用技能定位器解析 <food-image-skill>。
收集真實菜餚參考
僅為選定的餐廳執行收集器：
APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
--place-id <google-place-id> \
--max-images 20 \
--output-dir <work-order>
python3 <food-image-skill>/scripts/collect_real_references.py masa \
--store-id <masa-store-id> \
--item-name <exact-menu-item-name> \
--output-dir <work-order>
對於 Maps URL，也需提供獨立已知的 Place ID；返回的記錄必須與之匹配：
APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
--maps-url <exact-google-maps-place-url> \
--expected-place-id <google-place-id> \
--output-dir <work-order>
收集器會完全解碼 JPEG、PNG 和 WebP 像素，並拒絕短邊低於 300 像素或總像素低於 150,000 的來源。它要求 Apify 返回鎖定的 Place ID，並要求 Masa 在回應或菜單項目上下文中返回請求的 StoreID。它絕不將請求的識別碼單獨視為證據。
離線 JSON 匯入僅作為可重現的審核材料。它們保留其輸入雜湊和 offline-audit-only 層級，但無法被晉升或進入示範。
記錄獨立候選審核
渲染規範的未分類候選文件：
python3 <food-image-skill>/scripts/make_candidate_sheet.py \
--source-index <work-order>/source-index.json \
--out <work-order>/review/candidate-sources.svg
使用 view_image 和保留的文件檢查每個本機候選項。拒絕螢幕截圖、菜單、佔位符、庫存圖像、合成圖像、模糊食物和錯誤的列表。將分類記錄為自動審核步驟；不要暫停以等待使用者批准：
python3 <food-image-skill>/scripts/record_candidate_review.py \
--source-index <work-order>/source-index.json \
--candidate-sheet <work-order>/review/candidate-sources.svg \
--candidate-id <candidate-id> \
--out <work-order>/review/<candidate-id>.json \
--status recorded \
--reviewer workflow \
--classification served-dish-photo \
--restaurant-match verified \
--restaurant-match-notes <identity-evidence> \
--dish-visibility served-dish-visible \
--visual-notes <visible-served-dish-evidence> \
--notes <audit-summary>
審核記錄會鎖定候選 ID、未修改的來源雜湊、來源索引雜湊、規範候選文件雜湊、審查者、時間戳記、分類和視覺發現。將非食物候選項記錄在其真實分類下，並且不晉升它們。稍後的 changes-requested 記錄會立即阻止晉升和示範驗證。
在選擇模式前評估快照
將來源相機視角記錄為 overhead、near-overhead、three-quarter、low-angle、straight-on 或 unknown。然後記錄：
fit：來源已符合攝影系統；允許constrained-edit。restage-required：菜餚是真實的，但角度或構圖不符合客戶導向；需要reference-restage。unusable：食物太模糊或無法確定；阻止生成。
當鎖定的客戶導向系統是三分之四桌面角度時，請勿將俯拍快照稱為 fit。Sake Sushi 的失敗是規範的反模式：一個真實的俯拍來源不能僅僅因為編輯保留了相同的俯拍構圖就通過。
驗證器會強制執行相機系列相容性。overhead 和 near-overhead 來源不能被標記為 fit 用於 three-quarter-tabletop、low-tabletop 或 straight-on；不相容的視角必須是 restage-required，設定 angle_change_required: true，並使用 reference-restage。
為每個提議的輸出晉升一個候選項：
python3 <food-image-skill>/scripts/promote_candidate.py \
--source-index <work-order>/source-index.json \
--candidate-review <work-order>/review/<candidate-id>.json \
--manifest <work-order>/image-manifest.json \
--candidate-id <candidate-id> \
--dish-id <dish-id> \
--dish-name <dish-name> \
--restaurant-name <restaurant-name> \
--restaurant-slug <restaurant-slug> \
--location <location> \
--google-place-id <place-id> \
--dish-match-status <exact-or-category-only> \
--dish-match-notes <name-or-category-evidence> \
--source-camera-view overhead \
--customer-facing-fit restage-required \
--hidden-detail-risk medium \
--composition-notes <why-the-snapshot-needs-restaging> \
--angle-change-required yes \
--generation-mode reference-restage
對於 Masa，請使用 --masa-store-id 代替 --google-place-id。
晉升僅接受來自 live-verified 收集、當前狀態為 recorded / audit-record 且分類為 served-dish-photo 的記錄。它會將完整的原始來源來源和來源元資料複製到 Manifest 中。來源索引和候選審查檔案仍受雜湊綁定，並在後續每個階段重新驗證。
將 live-verified 視為工作流程證明的證據，而非來自 Apify 或 Masa 的加密簽章。對工作指令具有寫入存取權的人可以編輯本機 JSON 並重新計算本機雜湊。當來源歸屬有爭議時，或在公開發布依賴該資產之前，請重新執行即時提供者收集，比較返回的餐廳身份和圖像雜湊，或將其替換為已通過未來業主攝入審核的、已清理的業主資產。切勿將本機鏈描述為防篡改。
鎖定一個設計好的攝影系統
在生成之前，完成結構化的 photography_system 和 style-lock.md。為餐廳套組鎖定一個主要的相機系列，通常是一個可重複的 three-quarter-tabletop 系統，角度約為 35–45 度，用於客戶導向的休閒食物攝影。記錄的角度公差不得大於 15 度。
鎖定所有這些變數：
- 目標角度、相機高度、鏡頭感覺和主體比例；
- 長寬比、裁切和網站留白；
- 表面、背景系列和道具節制；
- 光線方向、光線品質和陰影特性；
- 曝光、白平衡、飽和度和對比度；
- 食慾處理和可接受的真實缺陷；
- 避免 AI 渲染外觀所需的自然線索。
在整個套組中使用一個主要的相機系列。請勿隨意在俯拍、正面和三分之四圖像之間交替。
規劃真實的食慾優化
在提示之前記錄菜餚特定的調整。僅允許來源支援的改善：
- 適度提高曝光並修正白平衡；
- 使現有的麵包或外皮自然變得更暖和、更金黃；
- 澄清現有的煎烤痕跡、酥脆邊緣、蔬菜顏色或醬汁光澤；
- 清理分散注意力的背景細節並改善盤子擺放；
- 保留一般的服務變化、不均勻的切割和來源的不對稱性。
請勿發明焦黃、烤架痕跡、裝飾、食材、醬汁、蒸氣、份量、容器或奢華擺盤。「看起來更美味」是呈現目標，而非重新設計食物的許可。
自動記錄來源成品
在建立來源文件之前，要求結構化的攝影系統、風格鎖定和每個轉換計劃都必須完整：
python3 <food-image-skill>/scripts/validate_manifest.py \
--manifest <image-manifest.json> \
--stage plan
然後建立並保留規範的來源文件，並在不停頓的情況下記錄它：
python3 <food-image-skill>/scripts/make_contact_sheet.py \
--manifest <image-manifest.json> \
--stage source \
--out <work-order>/review/source-review.svg
python3 <food-image-skill>/scripts/record_review.py \
--manifest <image-manifest.json> \
--dish-id <dish-id> \
--gate source \
--status recorded \
--reviewer workflow \
--notes <source-angle-route-and-evidence-notes>
渲染文件後不要暫停。自動記錄每個符合資格的來源，替換所有提示中的 TODO 標記，要求 validate_manifest.py --stage generate，並在驗證通過後直接繼續進行 imagegen。
生成設計好的照片
使用 $imagegen。在每次呼叫中提供視覺主體，並在隱藏細節風險需要時添加真實的佐證視角。在每個提示中：
對於每個佐證 ID，在 source_assessment.supporting_source_matches.<source-id> 中記錄 status: exact 和特定的同菜餚備註。在 output.input_source_ids 中，僅包含視覺主體之後的那些經審核的真實視角；菜單文件、場地照片、庫存和合成圖像無法滿足隱藏細節風險。
- 命名來源 ID 以及
constrained-edit或reference-restage。 - 明確命名目標相機系列和目標角度。
- 將真實來源視為菜餚事實，將攝影系統視為呈現事實。
- 重複已驗證的食物事實、數量、份量、配菜、醬汁、熟度和容器。
- 僅描述計劃的構圖和食慾改善。
- 保留真實的不規則性和一般獨立餐廳的呈現方式。
- 禁止塑膠光澤、蠟質紋理、重複幾何圖案、完美對稱、形狀扭曲的邊緣、假效果、文字和標誌。
- 製作一張
…
[內容已截斷以進行翻譯]