餐厅演示搭建器
构建一个基于证据的销售演示，让老板一眼认出自己的餐厅，并让缺失的在线商机变得显而易见。将演示视为餐厅网站的一个实用初版，而不是一个仅贴上餐厅名字的通用主题。
在进行大量研究、设计、图像制作或实施之前，请阅读 references/demo-playbook.md。仅使用与请求相关的部分。
选择任务模式
在行动之前确定请求的模式：
- 分析： 返回一个基于来源的概念、理由、页面结构、图像方向、菜单计划和验证缺口。除非被要求，否则不要编辑项目文件。
- 构建： 研究餐厅，创建或准备适当的资产，实现可工作的演示，运行它，并视觉验证桌面和移动视图。
- 刷新： 检查现有演示和当前公开事实，然后仅更新过时或薄弱的部分，并重新运行视觉验证。
仅当多个企业共享名称且无法推断出正确位置时，才要求澄清。否则，首先检查本地线索数据和公开来源。
基于证据工作
- 在浏览之前检查当前工作空间。搜索线索导出的数据、简报、现有演示和设计资产，以获取餐厅名称、位置、Place 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历史，不参与新的演示路由。不要复制参考餐厅的代码、照片、文字、Logo、插图或独特的完整构图。
将食谱和布局选择视为独立的约束。食谱控制受众、语气、功能和视觉态度；布局语法控制首屏、媒体构成、证据形式、菜单几何形状、部分几何形状和移动端转换。已验证的餐厅证据继续控制订购、预订、活动、营业时间、服务、菜单内容、评论和图像。切勿手动绕过V2锁定：当结果错误时，请更正档案、兼容性定义或历史记录指纹。
锁定餐厅品牌调色板
在食谱和布局锁定之后，但在最终视觉样式设置之前，只要店面、招牌、Logo、菜单、包装或室内图像提供了可用的身份色彩证据，就使用 $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门缺失，则保持该插槽以文本为主导，或使用单独验证的非食物资产。切勿使用菜单描述、库存照片、合成风格图像或“代表性概念”渲染来绕过此门。
优先选择餐厅自有图像，因为菜品身份和氛围是证据。对于私人销售演示，即使上传者未知，来自地图、社交页面、评论平台、目录和菜单页面的公开真实照片也可以作为临时的事实或构图参考。记录来源和不确定性，不要暗示参考权限已清除，并在公开发布前获得批准或替换资产。
使用独立的门。在源门处，自动保留唯一的真实菜品来源、来源相机评估、路线、来源和哈希值。在私人演示门处，保留来源与设计照片的比较、生成时间、注册输出角度以及五道门：保真度、风格一致性、食欲优化、AI痕迹和网站就绪。用户可以在以后检查任一工件并请求更改。当一张真实的公开照片可信地归属于正确的餐厅时，不需要上传者身份。在公开发布门处，需要获得批准的替换品或相关权利持有人的许可，以及所有者对事实准确性的确认。不要暗示记录的私人或一对一使用授予了发布权。
当没有当前的数字菜单时，让 $restaurant-food-image-studio 运行其以Google Maps为首选的后备方案。将重复的真实菜品照片分组，用菜单照片、社交帖子、标题和评论提及进行佐证，然后选出三到六个候选特色菜。重复是一种选择信号，而不是销量证明：默认使用“特色”，并将“热门”、“最热门”、“畅销”或确切的菜品名称保留给有证据支持的说法。
将AI用作艺术指导和修复层：
- 在生成之前检查每个真实来源并分类其相机视图。
- 保留菜品种类、配料、份量、烹饪方法、配菜和餐具；将来源视为食物事实，而不是强制性的最终构图。
- 为餐厅设置锁定一个主要的客户面对相机系列、角度容差、主体比例、裁剪、背景、光照方向、风格、镜头质感和道具策略。
- 将不符合该系统的来源路由到“参考-重新设计”；不要仅仅因为它是真实的就保留不合适的俯拍或随意快照角度。
- 在不改变熟度、标记、份量或配料的情况下，改善曝光、白平衡和来源支持的食欲线索，例如天然的金黄色面包或可见的焦糖化。
- 拒绝塑料光泽、蜡质纹理、重复、完美几何形状、不可能的视觉效果和其他可见的AI痕迹。
- 为首屏使用宽幅图像，并为特色食物使用一致的
4:3系列。 - 仅生成三到六张特色食物图像；让完整的菜单保持文本主导。
- 将不确定的输出标记为概念图像，并将其包含在所有者验证集中。
- 将Google Maps截图和其他第三方原始文件保留在演示页面之外；仅在内部清单和联系表中记录它们。
当参考材料未证明其配料时，不要将生成的图像标记为准确的菜单项。避免不可能的装饰、夸张的蒸汽或拉丝奶酪、虚假的Logo、生成的菜单文本、过度的完美以及有悖于餐厅现实的库存照片风格。
使用 $restaurant-exterior-image-studio 进行实际的店面来源审计、保存规划、AI辅助修复或基于参考的重新创建、清单跟踪、注册、比较和六部分QA。在完整的演示构建中，首先在此处决定到达图像的目的和插槽，然后将纵横比、焦点、预期位置和寻路要求传递给该技能。
将外观图像工作室 demo 验证视为集成边界。除非满足以下所有条件，否则不要将AI辅助的店面复制到网站中：当前真实来源证明了招牌、入口、立面几何形状、立面颜色和固定特征；所有输出面向的区域都有支持或被裁剪掉；保存合同完成；所有六个QA门通过；并且 <exterior-skill>/scripts/validate_manifest.py --stage demo 在集成前立即成功。
当食欲是主要转化目标时，保持食物主导的首屏；除非建筑本身是经过验证的吸引力，否则将外观放在“访问”部分附近。将公共平台的原始文件保留在内部，将私人演示输出标记为照片提议，并保留单独的所有者准确性和发布权限门。街景视图除了官方嵌入或链接外，仍仅用于研究。
在规划或放置资产之前，请阅读 references/demo-playbook.md 中的“外观和到达图像”部分；让专业技能控制制作细节。
让菜单成为核心工具
将菜单构建为结构化的页面内容，而不是……
……（原文在此处截断）