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