餐厅美食图片工作室
将混合的真实餐厅快照转化为一个小而连贯的网站摄影集。使用真实照片作为菜品的真实依据。使用餐厅摄影系统作为相机角度、构图、光线、背景、颜色、裁剪和客户呈现的权威依据。
不要仅仅因为一个弱角度是真实的就保留它。当俯拍、杂乱或不一致的快照不符合网站系统时，使用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 痕迹和网站就绪性。
- 保存标准的真实来源和来源对比设计照片的工件。
- 在将输出复制到网站之前，通过 Manifes
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。
提升只接受当前 recorded / audit-record 且分类为 served-dish-photo 来自 live-verified 收集的记录。它将完整的原始出处和来源元数据复制到 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。 - 明确命名目标相机系列和目标角度。
- 将真实来源视为菜品事实，将摄影系统视为呈现事实。
- 重复已验证的食物事实、数量、配菜、酱汁、熟度和容器。
- 仅描述计划的构图和食欲改进。
- 保留真实的瑕疵和普通的独立餐厅呈现。
- 禁止塑料光泽、蜡质纹理、重复几何图案、完美对称、畸形边缘、虚假效果、文本和徽标。
- 仅进行一次……
[为简洁起见已截断]