CASE STUDY · 合餐点菜谈判桌
Dining Agent
有人忌口的饭局，
也能一次点出整桌菜
每位食客在自己的私有 Agent 里填写忌口和预算，不必当众解释原因。安全、价格、份量和整桌组合由确定性代码决定，大模型只负责理解和协商。
- 我的职责
- 问题定义 · 安全边界设计 · 评测设计 · 真实饭局观察（借助 AI 编程工具实现）
- 交付形态
- 手机 H5（可在微信内打开）
- 当前阶段
- 已做一次真实饭局观察，修复待部署
50／50 注入用例通过
覆盖过敏伪安全、未知误放行、价格篡改、隐私泄漏。
跨食客隐私泄漏 0
每位食客的评估独立运行，汇总方只看到脱敏结果。
真实饭局发现最严重的问题
测试全绿，最后一道人工安全防线却被走了过场。
01 / 问题定义
先拆掉伪需求，再找真正的痛
最初的想法是「多人聚餐点菜麻烦，用 AI 帮大家点」，照这个做会得到又一个「收集偏好、推荐三套菜单」的工具。我按四条标准逐个判别：是否高频且后果严重、现有做法是否够好、用户会不会花时间、AI 是否真的比不用好。
少聊几分钟，快点决定吃什么
伪需求
朋友间商量本身是社交的一部分，几分钟讨论不构成痛点。
AI 推荐三套方案让大家挑
伪需求
增加决策负担，还要再投票；产品只给一张主订单。
AI 告诉我这道菜绝对安全
危险的伪需求
仅凭菜名或图片无法保证；只能说已知冲突、需要确认、当前证据未发现冲突。
有忌口的人不用当众解释，也能确定有菜吃
真需求（待访谈验证）
后果严重、每次聚餐重复发生，现在靠别人的记性和自己开口。
知道哪些菜要问服务员，而且问得完
真需求（有真实证据）
第一次真实聚餐中，问题清单太长，组织者问了几道就开始自己勾选。
目标用户：经常组织或参加固定饭局、桌上至少一人有过敏或稳定饮食限制的成年人。
02 / 方案
Agent 协商，代码拍板
每人一个私有 Agent
只填三项结构化信息；每位食客的评估单独运行，看不到别人的资料。
汇总方只看脱敏结果
Supervisor 拿到的是去标识的决策和一个总预算上限。
安全门先过滤
已知冲突直接排除，规则由代码判断，不交给模型。
整桌求解
在预算和份量约束下组合整桌菜，只求解结构化、已校验的输入。
独立复核，再由人批准
另一套确定性检查复算一遍，组织者确认后才出单。
block
已知冲突
菜里含有食客明确不能吃的东西，直接排除。
conditional
证据不足
菜单没写清配料，需要问服务员确认，不能默认放行。
pass
当前证据未发现冲突
不说「安全」，只说在已有证据里没发现冲突。
三种状态用图标加文字区分，不只靠颜色；通用知识只能增加风险判断，永远不能单独判定 pass。
03 / 真实饭局复盘
测试全绿，人工防线却被走了过场
发生了什么：2026-10-16 的一次真实聚餐，4 位成年人。第一次求解失败，因为菜单不写过敏原，有一位参与者没有任何一道菜能确认。系统生成「问餐厅」清单，组织者问了前几个，后面太多问不过来，也不好意思一直麻烦服务员，就自己勾了几个提交。订单页随后显示绿色的「当前证据未发现冲突」。
根因：清单针对整份菜单（98 道菜）生成，远超一个人在餐厅里能如实问完的量。问题不在组织者，而在我假设「人会如实操作」，把人在回路当成了免费的安全保证。
怎么发现的：日志只能看到「第一次失败、72 秒后成功」，看不出有没有真的去问；靠事先定好判定标准的观察和事后追问才发现。这次违反忌口为 0，是运气，不是系统可靠。
修复 1
只问候选订单里的菜
先求出一份假设订单，只针对其中的菜提问；测试中 40 道菜的菜单只问了 5 道以内。
修复 2
每题三选一，不能批量勾
餐厅说含有／餐厅说不含／没问到，默认「没问到」；没问到仍然算未知，照常拦截。
修复 3
如实标注证据来源
依据口头答复的菜改为黄色「依据餐厅口头答复」，提示上菜前再确认一次。
不变的底线与防复发
安全门代码没有改动：没问到的未知永远进不了订单，有测试覆盖「不回答就重新求解，仍然失败，问题也不变」。
新增事件记录问题数、三种回答各自数量和耗时，以后「大量没问到」或「很短时间内答完很多题」这类走过场能直接从日志看出来。下一次真实聚餐会专门验证新流程能不能被如实问完。
04 / 验证与现状
能证明的写清楚，证明不了的也写清楚
诚实边界：演示用的是合成数据，界面上持续标注。测试只能证明代码按设计运行，证明不了设计本身对；微信真机、备案域名和更多真实饭局观察，仍要靠外部证据补齐。
Demo 部署后会在这里开放体验。