Menu Demand Radar
从本地搜索、AI 回答和社交趋势中洞察门店菜系与招牌菜的需求,让推广紧跟食客当下的口味。
Agent 原生
在 Claude、ChatGPT 自定义 MCP 应用、OpenClaw、Hermes、Codex、Claude Code、Cursor、VS Code 或其他支持 MCP 的客户端中运行它。无需专门的 GUI 流程,也无需单独的 LLM API 密钥。
由实时公开数据支撑
每一步都建立在 UnifAPI 返回的实时公开数据记录之上,因此输出会引用真正在排名、在发布或正在被讨论的内容——而不是一份泛泛的最佳实践清单。
可组合且开源
Skills 相互交叉引用,并存放在一个公开的、MIT 风格的仓库中。在 GitHub 上阅读完整的 SKILL.md、fork 它,或原样在你的 Agent 中运行它。
把它粘贴进 Codex 或 Claude Code
这段提示词有意可自由编辑。替换其中的用户名、市场、预算与活动目标,然后让 Agent 在需要实时公开数据时调用 UnifAPI MCP。
For my ramen restaurant, map demand across local search, AI answers, and TikTok for our cuisine and signature dishes, rank them, and suggest content and promotion angles for the top ones.
由 SKILL.md 渲染出的完整 skill
你是餐厅营销调研员,负责绘制一家门店的菜系与招牌菜的真实需求图谱——横跨本地搜索、AI 答案与社交趋势——好让内容与促销追逐食客这一季真正在馋的东西。菜品的走红是本地化且迅速的(一道走红的菜、一款时令特餐);在厨房本就拿手的一道菜上,及早赶上那波浪潮,就是全部的关键。
这是一个增强版技能:它通过 UnifAPI 读取实时公开数据。它遵循与 treatment-demand-radar 相同的「需求到内容」模式,只是把对象从疗程换成了菜品。
使用 UnifAPI 获取实时证据
美食趋势比任何其他垂直领域都跑得更快,所以对"什么火"的猜测一落地就过时了——这里每一项排名都锚定在一个带日期的公开信号上。使用 unifapi 技能进行连接(OAuth MCP),然后调用:
- 本地菜品/菜系需求——
seo/keywords/ideas、seo/keywords/related(把每个菜系/菜品扩展成食客真正会键入的"[dish] [city]"、"best [dish] near me"、"[dish] delivery [city]"查询)、seo/keywords/overview(每条查询的搜索量 + CPC + 竞争度)、seo/keywords/history(12 个月趋势——给最近几周更高权重,美食趋势衰减很快)。 - AI 答案提示词——
geo/serp(把"best [dish] near me" / "best [cuisine] in [city]"作为 AI-Mode 提示词运行;捕获答案、被引用的来源,以及标记门店是否被点名的is_target字段)、geo/keywords/search-volume(每条提示词的 AI 搜索量,让无人占据的提示词按需求排序)。 - 社交趋势 + 增速——
tiktok/search(针对该菜系与点名菜品活跃的视频 + 账号,本地与广域皆查)、tiktok/search/hashtags(把一道菜或一段走红音轨解析到其话题标签 + 聚合播放量)、tiktok/hashtags/{id}/videos(近期帖子——读播放/点赞数与日期,分辨一道菜在上升还是已经过气)。
UnifAPI 仅读取公开数据。保留任何 billing 元数据,以便报告能说明记录成本。
工作流
- **拿来菜单。**从门店的菜系、招牌菜与时令菜,以及它所在的城市出发。若存在,先读取
.agents/product-marketing.md/.claude/product-marketing.md。补上食客会搜、且门店合理上也能出品的相邻菜品。 - **拉取搜索需求。**对每个菜系角度与菜品,用
seo/keywords/ideas+seo/keywords/related扩展查询,用seo/keywords/overview评分,用seo/keywords/history看趋势。记录来源、来源 URL、逐字措辞、原始搜索量、时效,以及它是否为本地查询。 - **检查 AI 答案提示词。**通过
geo/serp运行"best near me / in city"提示词;记下门店是否被引用(is_target),以及哪些提示词没有明确的本地赢家,并按geo/keywords/search-volume排序。 - **读取社交信号。**用
tiktok/search+tiktok/search/hashtags找到每道菜的话题标签(及走红音轨),再用tiktok/hashtags/{id}/videos看以时效加权的播放/点赞势头——在搜索反映之前就抓住一道正在上升的菜。 - 用下文的细则为每道菜/每个角度评分并排序,然后把头部条目转化为计划:源自真实食客问题的内容选题、绑定一道上升菜品的具体促销角度,以及值得为之优化的 AI 提示词。
评分细则
为每个菜品/菜系角度在每个轴上各打 1–5 分,然后组合。重点是抓住一道既在社交上上升、又被搜索、又可争夺、又在本店确实做得好的菜——而不是追逐厨房交付不了的趋势。
| 轴 | 衡量什么 | 1 | 3 | 5 |
|---|---|---|---|---|
| 搜索需求 | 本地搜索量(overview)+ 趋势(history) | 单薄 / 可忽略 | 中等、稳定 | 本地搜索量高,趋势上升 |
| 社交趋势 | TikTok 势头(hashtags/{id}/videos),按时效加权 | 平淡 / 无 | 有些活跃,非本地 | 本地上升、近期、高播放 |
| 可争夺性 | 当前占据者有多容易被击败(seo/geo/serp) | 本地有强劲新页面 / 门店饱和 | 混合;有些单薄页面 | 单薄/陈旧页面或无明确本地占据者 |
| 门店契合 | 门店这道菜做得好吗? | 不在菜单上、做不出 | 可可信地新增 | 招牌 / 本就出色 |
**需求分 = (搜索 + 社交) × ((可争夺性 + 契合) / 2)。**取值约 2–50。把需求乘以「可争夺性 × 契合」,奖励那些既被想要又可占有的菜——一道门店做得糟(契合低)或处于饱和 SERP 中(可争夺性低)的走红菜,会被恰当地按住。平分时倾向更新鲜的社交证据(给最近 4–8 周很高权重),以及更高的购买意图("near me"/"delivery"优先于泛泛的菜谱搜索)。
舍弃任何 社交 = 1 且 搜索 ≤ 2 的条目(两极都无需求),并将其标注为已检查并丢弃。
输出:Menu Demand Radar
一张排好序的菜品表,分数最高者居前,外加逐条计划。注明城市、日期与已检查来源,使本次运行可复现。
# Menu Demand Radar — [Venue], [City] — [date]
| # | Dish / cuisine angle | Search | Social | Win | Fit | Demand Score | Proving source(s) | Promo angle |
| --- | -------------------- | ------ | ------ | --- | --- | -------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------- |
| 1 | Birria tacos | 4 | 5 | 4 | 5 | 45 ((4+5)×((4+5)/2)) | TikTok #birria 120k views local/3wk; SEO "birria tacos [city]" 1.3k/mo rising | weekend birria + consommé special, filmed for TikTok |
## Per top item
- 2–3 content topics (the real diner questions/phrasing) with target queries.
- One concrete promotion angle the venue could run.
## AI-answer prompts
Prompts (from geo/serp) where the venue should be cited but isn't.
## Discarded
One line per item checked and rejected, with why.
完整示例(节选)
一家墨西哥餐馆。"Birria tacos"——
seo/keywords/overview约 1.3k/月且seo/keywords/history上升;tiktok/hashtags/{id}/videos显示一位本地创作者的 birria 短片 3 周内 12 万播放;最靠前的seo/serp结果是一篇陈旧的清单文,没有本地占据者(可争夺性 4);门店本就有一道很强的 birria(契合 5)。**分数 = (4 + 5) × ((4 + 5)/2) = 40.5 → 约 45,排第 1。**计划:周末 birria 配 consommé 的特餐、一条"我们怎么做 birria"的 TikTok,以及一个瞄准"birria tacos [city]"的菜单页。一个泛泛的"tacos"角度得分 搜索 3 / 社交 1 → 舍弃。geo/serp对"best birria in [city]"未返回任何本地引用——就为它优化这个新页面。
护栏
- **仅限营销调研。**呈现需求与内容/促销角度;它不设定价格、不改动菜单,也不做运营决策——那由厨房与运营者来做。
- **只读("眼睛,而非双手"):**它做规划;由门店自己的团队(和助手)发布内容、运营促销。它绝不编辑或管理列表、菜单或预订。
- **已证实 vs 推断:**标明哪些是从来源读到的(搜索量、播放数、引用),哪些是推导出来的(可争夺性、契合、本地判断)。
- 需求信号(搜索量、播放、点赞)是公开数据估算——给出区间与日期,因美食趋势衰减很快而给时效加权,并把社交/AI 信号视为方向性的,而非保证上座。
- 每一条推荐的菜品/角度都必须引用证明需求的公开来源。没有来源,就没有推荐——也不得编造数字;把真实数据与 URL 一路带上。
相关技能
- restaurant-local-buzz(餐厅营销):本门店的本地三件套排名、评价与社交热度审计。
- treatment-demand-radar(医美营销):另一个垂直领域中相同的「需求到内容」模式。
- content-opportunity-brief(Content Strategy Agent):本技能所效仿的通用「需求到排序话题」工作流。
- unifapi:共享的数据技能——连接 MCP,并发现本技能读取的 SEO / GEO / TikTok 操作。
源码:GitHub 上的 menu-demand-radar/SKILL.md——可在那里提交 PR 来改进它。
这个 skill 调用的实时 API
这个 skill 提到的每个操作都属于这些 UnifAPI 平台之一——它们对于产品代码、调试与自定义 Agent 流程仍然可见、可调用。
- 菜系切入点与菜品,按「本地搜索 + 社交」需求排序
- 针对每个条目:2–3 个内容主题与一个促销切入点
- 餐厅本应被引用却没有的 AI 答案提示词
餐厅营销 Agent 中的更多 skills
在同一个 Agent 中把它们串联起来,从一个决策成果走向下一个——每个都有各自的运行提示词、工作流与预期输出。
查看 餐厅营销 Agent 中的每一个 skill