Skill: ysredcity/shop-review-generator (version 1.0.1)

--- name: shop-review-generator description: 为大众点评、高德扫街榜等平台生成高质量店铺点评。用户提供店铺地址（高德/大众点评链接）和菜品照片，技能会分析照片中的菜品、搜索店铺信息和历史评价，然后按照标准点评模板生成结构化的点评内容。当用户提到"写点评"、"店铺评价"、"餐厅点评"、"大众点评"、"高德扫街榜"、"帮我写个评价"、"生成点评"、"美食点评"，或者提供了餐厅照片并希望生成评价文案时，都应该触发这个技能。 --- # 店铺点评生成器 ## 任务目标 根据用户提供的店铺地址和菜品照片，生成符合大众点评/高德扫街榜风格的高质量结构化点评。点评需要基于真实照片分析和网络搜索到的店铺信息，做到真实、客观、有细节感。 ## 前置准备 - 需要网络搜索能力（web search）来获取店铺信息和历史评价 - 需要图片识别能力来分析菜品照片 - HEIC 图片处理能力（详见下方降级机制） ## 操作步骤 ### 步骤1：收集用户输入 确认用户提供了以下信息： 1. **店铺地址或链接**（必需） - 高德地图链接、大众点评链接，或店铺名称+城市 - 如果用户只给了店名，询问所在城市以便精确搜索 2. **菜品照片**（必需） - 至少 1 张菜品照片 - 环境照片（可选，用于环境描述） 如果缺少必需信息，礼貌地向用户索要。 ### 步骤2：图片预处理（HEIC 降级机制） 用户提供的照片可能是 iPhone 拍摄的 HEIC 格式。不同模型对 HEIC 的支持不一致，因此需要一个降级处理流程： **处理策略（按优先级尝试）：** 1. **直接识别**：先尝试直接分析用户提供的原始图片。如果模型能正常识别 HEIC 格式，跳过转换直接进入菜品分析。 2. **脚本转换**：如果直接识别失败（报错、无法解析、返回空白描述），使用本技能自带的转换脚本： ```bash python <skill-path>/scripts/convert_heic.py <图片路径或图片目录> ``` 脚本会自动选择可用的转换工具（macOS sips → pillow-heif → ImageMagick），将 HEIC 转为 JPEG 后重新分析。 3. **手动转换提示**：如果脚本也失败（缺少依赖），提示用户手动转换： - macOS: `sips -s format jpeg input.HEIC --out output.jpg` - 或安装依赖: `pip install pillow-heif Pillow` - 或使用在线转换工具 关键点：不要一上来就要求用户转换格式，先试再说。只有在确认当前环境无法处理时才降级。 ### 步骤3：分析菜品照片 使用视觉能力逐张分析用户提供的照片，提取以下信息： **对每张菜品照片识别：** - 菜品名称（初步判断，后续会校验） - 视觉特征：颜色、摆盘方式、食材组成、分量感 - 烹饪方式推断：煎、炒、烤、蒸、炸、卤等 - 温度线索：是否有热气、冰霜、凝固状态等 **对环境照片识别（如有）：** - 装修风格 - 座位布局 - 灯光氛围 - 整体卫生状况 将识别结果整理为结构化清单，供后续步骤使用。 **重要：此步骤得到的菜品名称只是初步判断，不要直接用于最终点评。** 纯靠看图猜菜名很容易出错（比如把"酸菜鱼"认成"水煮鱼"，把"糖醋里脊"认成"锅包肉"）。准确的菜品名称需要在步骤4搜索后交叉验证。 ### 步骤4：搜索店铺信息和历史评价 这一步通过多个渠道获取店铺信息和菜品数据，确保菜品名称准确、评价有据可依。 #### 4a. 高德 API 获取店铺基础信息 如果用户提供了高德地图链接或店铺名称，先用高德 API 获取准确的店铺信息： ```bash # 从高德链接查询 python <skill-path>/scripts/amap_poi.py link "高德链接" # 按店铺名+城市搜索 python <skill-path>/scripts/amap_poi.py search "店铺名" --city "城市" ``` 从 API 返回中提取： - 店铺准确名称（用于后续搜索，比用户口述的更准确） - 详细地址（用于位置描述） - 评分和人均消费 - 店铺类型（用于判断菜系） 如果用户提供的是大众点评链接，跳过这步，直接进入 4b。 #### 4b. Web Search 搜索菜单和推荐菜 用 web search 工具搜索店铺菜单信息，这是获取准确菜品名称的关键步骤： **搜索查询（按顺序尝试，直到获取到菜品列表）：** 1. `"店铺名" 大众点评 推荐菜` — 大众点评的推荐菜列表通常会出现在搜索摘要中 2. `"店铺名" 大众点评 菜单` — 获取更完整的菜单信息 3. `"店铺名" 美团 菜单` — 美团也有菜品列表 4. `"店铺名" 菜单 菜品` — 通用搜索兜底 **从搜索结果中重点提取：** - 店铺的招牌菜/推荐菜名称列表 - 菜品的价格信息 - 用户提到的具体菜品名称（这些通常是菜单上的真实名称） #### 4c. 小红书探店笔记搜索 小红书的探店内容通常最详细、最接近真实体验，是口味评价的重要参考： **搜索查询：** 1. `"店铺名" 小红书 探店` — 获取探店笔记 2. `"店铺名" 小红书 必点` — 获取推荐菜品 3. `"店铺名" 小红书 测评` — 获取详细评价 **从搜索结果中提取：** - 博主提到的具体菜品名称和口味描述 - 环境描述和拍照角度建议 - 人均消费和就餐体验 - 排队情况、服务评价等细节 #### 4d. 菜品专项搜索 对照片中识别出的每道菜品，搜索该菜品在这家店的历史评价： ``` "店铺名" + "菜品名（步骤3识别的初步名称）" ``` 这一步的目的： - 确认菜品名称是否正确（搜索结果中可能出现该店的实际菜名） - 获取其他食客对这道菜的口味评价 - 了解这道菜的价格和分量信息 **核心原则：只通过搜索引擎获取摘要信息，绝不直接抓取大众点评、高德等平台页面。** ### 步骤4.5：菜品名称交叉验证 这一步是确保菜品名称准确的关键环节，不可跳过。 **验证流程：** 1. 拿到搜索结果后，找出该店铺的菜单信息（大众点评的"推荐菜"、小红书笔记中提到的菜名等） 2. 将步骤3中照片识别出的菜品名称，与搜索到的菜单逐一比对： - 照片识别为"红烧肉" + 菜单上有"毛氏红烧肉" → 用菜单上的名称"毛氏红烧肉" - 照片识别为"炒饭" + 菜单上有"扬州炒饭"和"蛋炒饭" → 根据照片中的食材进一步判断是哪个 - 照片识别为"鱼" + 菜单上有"酸菜鱼"、"水煮鱼"、"剁椒鱼头" → 根据照片中的配料、汤色、器皿判断 3. 如果菜单上找不到匹配项，再搜索 `"店铺名" + "照片识别的菜品名"` 确认 4. 实在无法确定时，使用照片中可见的食材描述（如"一道红烧鱼"），不要硬猜一个具体菜名 **为什么这步很重要：** 很多餐厅的菜品有自己的命名（比如"老板娘私房鸡"而不是"白切鸡"），直接用图片识别的通用名称会显得不真实，一看就不像去过这家店的人写的。 **信息不足时的处理：** - 如果搜索结果很少，基于照片分析和餐厅类型常识进行合理推断 - 点评中只描述有依据的内容（照片可见 + 搜索到的信息），不编造细节 - 位置信息实在找不到时，可以写"具体位置见店铺主页" ### 步骤5：整合信息并生成点评 将照片分析结果和搜索到的信息整合，按照以下模板生成点评。 **点评结构（严格遵循）：** ``` #[标题] 位置: [地址信息] 环境: [环境描述] 口味: [菜品1名称]：[评价] [菜品2名称]：[评价] [菜品3名称]：[评价] ... ``` 各部分的详细规范见 [references/review-format-spec.md](references/review-format-spec.md)。 **生成要点：** 1. **标题**（15-20字） - 概括餐厅最突出的 1-2 个特点 - 可提及：餐厅类型、经营年限、核心特色、口味特点 2. **位置**（1句话） - 优先使用搜索到的地址信息 - 包含关键定位信息（商圈、地铁、楼层等） 3. **环境**（2-3句，不超过60字） - 基于环境照片（如有）和搜索到的其他用户评价 - 涵盖：装修风格、座位布局、灯光氛围 - 没有环境照片时，主要参考其他用户评价，保持简短 4. **口味**（每道菜 40-60字） - 每道菜必须包含 5 个要素：视觉呈现、口感描述、味道层次、温度、推荐指数（⭐️格式） - 视觉呈现基于照片分析 - 口感和味道结合照片推断 + 搜索到的历史评价 - 推荐指数综合照片外观和历史评价给出 **写作语气（非常重要）：** 点评要像一个普通人随手写的，不是文案策划精心打磨的。以下是核心原则： - **说人话**：用日常口语，不要用书面语堆砌。"鸡肉挺嫩的，不柴" 比 "鸡肉嫩滑不柴，口感细腻" 好。 - **别全夸**：真实的点评一定有好有坏，或者至少有"还行"的部分。全是夸赞一看就是假的。比如"味道还行但是量有点少"、"鱼挺新鲜的，就是刺多了点"。 - **少用四字成语**：像"浓郁醇厚"、"鲜美可口"、"色泽诱人"这种四字词组是 AI 味的重灾区。换成大白话："味道挺浓的"、"闻着就香"、"看着就有食欲"。 - **可以有个人偏好**：比如"我个人不太能吃辣，觉得有点过了"、"我比较喜欢这种咸甜口的"。 - **不要每道菜都五星**：如果三道菜都给五星，可信度直接归零。正常人总有觉得一般的菜。 - **温度描述别刻意**：不需要每道菜都强调温度，只在温度确实是亮点或槽点时提（比如"上菜很快，还是烫的"或"等太久了，都凉了"）。 **正面示例（口语化、真实感）：** ``` 三杯鸡：鸡肉挺嫩的不柴，酱汁很香，锅底还在冒泡，趁热吃很过瘾 ⭐️⭐️⭐️⭐️⭐️ 卤肉饭：肥瘦比例刚好，不会太腻，就是饭给的有点少 ⭐️⭐️⭐️⭐️ 珍珠奶茶：珍珠挺Q弹的，甜度正好，中规中矩吧 ⭐️⭐️⭐️ ``` **反面示例（AI味、过度夸赞）：** ``` ❌ 三杯鸡：鸡肉嫩滑不柴，酱汁浓郁香醇，口感层次分明，温度恰到好处 ⭐️⭐️⭐️⭐️⭐️ ❌ 卤肉饭：卤汁渗透米饭，肥瘦相间不腻人，咸甜适中，回味悠长 ⭐️⭐️⭐️⭐️⭐️ ❌ 珍珠奶茶：珍珠Q弹有嚼劲，奶茶茶香浓郁，甜度适宜，清爽怡人 ⭐️⭐️⭐️⭐️⭐️ ``` ### 步骤6：自检与输出 生成点评后，执行以下检查： **格式检查：** - [ ] 标题在 15-20 字之间 - [ ] 环境描述不超过 60 字 - [ ] 每道菜品评价在 40-60 字之间 - [ ] 每道菜品包含视觉、口感、味道、温度、星级 5 个要素 - [ ] 星级使用 ⭐️ emoji 格式 **内容检查：** - [ ] 没有编造照片中未出现的菜品 - [ ] 菜品名称与店铺菜单一致（经过步骤4.5交叉验证） - [ ] 没有硬编码复制其他用户的评价原文 - [ ] 颜色、摆盘等视觉描述与照片一致 - [ ] 语言自然流畅，不像 AI 生成 **风格检查（去 AI 味）：** - [ ] 没有连续使用两个以上四字成语/形容词（如"浓郁醇厚、鲜美可口"） - [ ] 不是每道菜都给了高分（至少有一道 3-4 星） - [ ] 有至少一处"不完美"的描述（量少、偏咸、等太久等） - [ ] 读起来像朋友发在群里的推荐，不像广告文案 - [ ] 没有过度使用网络流行语 如果检查发现问题，修正后再输出最终版本。 ## 常用口味词汇速查 生成点评时，优先使用右列的口语化表达，避免左列的"书面体"： | 书面体（少用） | 口语化（多用） | |---------------|---------------| | 嫩滑不柴 | 挺嫩的，不柴 | | 酱汁浓郁香醇 | 酱汁很香 / 酱给的足 | | 口感层次分明 | 吃起来有层次 | | 色泽诱人 | 看着就有食欲 / 卖相不错 | | 摆盘精致 | 摆盘挺用心的 | | 鲜美可口 | 挺鲜的 | | 回味悠长 | 吃完嘴里还有味 | | 分量充足 | 量挺大的 | | 温度适宜 | 上菜挺快，还是热的 | | 咸淡适宜 | 咸淡刚好 | | 入口即化 | 一咬就化了 | | 外酥里嫩 | 外面脆脆的，里面很嫩 | **可以用的"不完美"表达（让点评更真实）：** - "量有点少"、"稍微有点咸了"、"等了挺久的" - "中规中矩吧"、"没有特别惊艳"、"性价比一般" - "我个人觉得偏甜了"、"不太能吃辣的慎点" 更完整的词汇表和格式规范见 [references/review-format-spec.md](references/review-format-spec.md)。 ## 注意事项 - HEIC 照片：先尝试直接识别，失败后用 `scripts/convert_heic.py` 自动转换，最后才提示用户手动处理 - 高德 API：用 `scripts/amap_poi.py` 获取店铺基础信息（名称、地址、评分），API Key 已内置在脚本中 - 搜索策略：只通过 web search 获取搜索引擎摘要，不直接抓取大众点评/高德页面 - 菜品名称：必须经过步骤4.5交叉验证，不能只靠图片识别 - 搜索不到店铺信息时，基于照片可见内容生成点评，不编造信息 - 点评星级是综合判断（照片外观 + 历史评价），不是随意给满分 — 4星是"很好"，5星是"极力推荐" - 生成的点评应该像一个真实食客写的，避免 AI 味过重的措辞


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)