概览
餐厅的盈利能力由菜单决定，而几乎没有人认真分析过菜单。经营者知道哪些菜卖得好——收银机每天都在说——并且对食材成本有个大致概念。他们没有的，是这两个数字放在一起、按每道菜来算、并随着食材价格变动而保持更新。
把受欢迎程度和毛利放到同一页上，菜单就裂成四组，每一组需要不同的动作。一道既卖得好又赚得好的菜，应该被保护起来、并让人更容易找到。一道卖得好却赚得差的，是危险的那一道——很忙、感觉很成功，然后悄悄成了这个月不赚钱的原因。一道赚得好却很少被点的，是摆放位置和菜品描述的问题，是整栋楼里最便宜的一处修补。一道两样都不占的，正在占着菜单版面、冰箱空间和备菜时间。
真正让这件事变难的，是配方成本只在这道菜被创造出来的那一次算过，之后再也没算过。一道两年前按 28% 成本率定下来的菜，今天可能已经是 41%，而这门生意里没有任何东西会告诉你这件事。
这个智能体按当前价格给每道菜重新核算成本，给菜单分类，并按当前销量把每一处改动值多少钱算出来。它不定任何价格、不下架任何一道菜：两者都是关于你的客人和你的口碑的决定，而两者都不是算术。
价值
不涨价也能找到毛利
其中大部分是分量、损耗和配方漂移。
菜单上的每个位置都对得起自己
每道菜都由它的贡献来证明自己该留下。
你不再是「很忙但不赚钱」
而那是经营一家厨房最令人泄气的一种状态。
功能说明
按今天的价格重新核算成本
配方成本在一道菜被创造时定下来，之后再也没被回看过。一道按 28% 定下来的菜可能已经是 41%，而没有任何东西会说出来。
受欢迎程度与毛利并置
分开看，这两样都已经是知道的。放在一起看，菜单就裂成四组，对应四种不同的动作。
找出那道很忙却在亏钱的菜
危险的那一道。它感觉很成功，而它正是这个月不赚钱的原因。
报告贡献额，而不是百分比
一道配菜 78% 的毛利率，价值低于一道主菜的 62%。百分比会把决定引向错误的方向，而所有人都在用它。
按当前销量给每处改动定价
修好这道菜每个月值多少钱，让力气花在钱在的地方。
不定任何价格
价格是一项关于你的客人和你的定位的决定。它给你的是价格背后的算术。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 给每道菜重新核算成本，并把毛利摆到受欢迎程度旁边。
- 目前由谁完成
- 老板，一次，在菜单被写出来的时候。
- 多久一次
- 本该每月一次。实际上几乎从不。
- 通常的人工投入
- 每一份配方都要按当前食材价格重新核算，再乘以实际客单数。
为什么偏偏是餐饮服务。配方成本只算过一次，之后再也没算过。一道按 28% 定下来的菜今天可能是 41%，而这门生意里没有任何东西会说出来——而它通常还是一道畅销菜。
无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
菜单毛利分析代理 没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-sonnet-5，并自动回退
- 3工具extract_structured_data
- 4权限自动执行 READ 级操作；更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"dishes": [],
"period": "August 2026",
"currency": "USD"
}输出
{
"dishes": [
{
"dish": "Slow-braised short rib",
"group": "fix-the-cost",
"action": "Your second best seller, and it was costed at 29% when it was written. Beef has moved 56% since. Nothing in the business would have told you.",
"coversSold": 412,
"currentCost": 12.6,
"fullyCosted": true,
"recordedCost": 8.1,
"sellingPrice": 28,
"worthPerMonth": 1854,
"foodCostPercent": 45,
"costDriftPercent": 55.6,
"totalContribution": 6345,
"contributionPerDish": 15.4
},
{
"dish": "Heritage tomato salad",
"group": "improve-placement",
"action": "Strong margin, almost nobody orders it. It sits last in a section of nine. This is a menu design fix, not a kitchen one.",
"coversSold": 61,
"currentCost": 3.1,
"fullyCosted": true,
"recordedCost": 3,
"sellingPrice": 14,
"worthPerMonth": 980,
"foodCostPercent": 22.1,
"costDriftPercent": 3.3,
"totalContribution": 665,
"contributionPerDish": 10.9
}
],
"escalate": true,
"wasteGap": [
"Theoretical food cost across the menu is 31%. Actual is 36.4%. That 5.4 points is 9,100 a month and it is not a pricing problem."
],
"costBasis": "actual-with-waste",
"disclaimer": "An analysis of your own recipes, prices and sales. No price has been set or changed, no dish removed, no recipe or portion altered, and no ingredient cost was estimated where one was missing.",
"partlyCosted": [
"Two specials have no complete recipe, so they are excluded rather than estimated."
],
"escalationReason": "Food cost on the second best seller is 45%, above threshold, with 56% cost drift; and the waste gap is 5.4 points.",
"sharedIngredientRisk": [
"Butter appears in 14 of 31 dishes. A 10% move there costs more than any single recipe change would recover."
]
}使用条件
集成
无需集成。
开始之前
- 菜品及其售价与配方
- 当前食材成本
- 该期间各菜品的销售数量
- 损耗记录，如果你有在记的话
- 需要 入门版 套餐或更高
使用场景
菜单改版
在付印之前，哪些菜配得上它的位置。
供应商涨价之后
哪些菜动了，动了多少。
换季
上一季实际赚了多少，一道菜一道菜地看。
上座不错、月底却持平
通常是菜品结构问题，而不是客流问题。
价格
常见问题
它会改价格或下架菜品吗？
不会。两者都是关于你的客人、你的口碑和你的定位的决定。它给你数字，以及每个选项值多少钱。
我们需要精确的配方成本吗？
它用你手上有的。配方不完整的地方，它会把这道菜报为部分核算，而不是绕着缺口去估——一个编出来的食材成本，会成为整份报告里最容易被引用、也最不可靠的数字。
它会把损耗算进去吗？
凡是你有记录的地方，会，而且那往往就是那条发现。你没有记录的地方，它会说这个成本是理论值而不是实际值——而两者之间的差距，通常就是那块消失的毛利所在。
评价
客户运行过该智能体后，评价功能将开放。
需要这个智能体换一种做法？
告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。
定制此智能体