0007 AI 能力：先做整句识别，AI 只负责听懂
- 状态：已采纳
- 日期：2026-10-19
- 关联：0003 原生 iOS App 与 monorepo 结构（会员和「之后确定的高级功能」）
背景
- 用户想要「说一句话就出菜」：冰箱里有什么、不吃什么、想怎么做，现在要分别点食材、忌口、口味、厨具。
- 菜谱是人工整理的 600 多道菜，每道都对应一个 B 站视频，这是和通用 AI 助手不同的地方。
- 原则是尽量降低运营成本：免费用户零服务器成本，会员费覆盖云端开销（见 0003）。
- 在中国大陆向公众提供调用大模型的功能，一般要到当地网信办做生成式人工智能服务登记，周期几周到几个月。
- iOS 的 Foundation Models 端侧模型免费，但只支持 iPhone 15 Pro 及更新机型，国行 Apple Intelligence 尚未正式上线。
方案对比
| 方案 | 取舍 |
|---|---|
| AI 生成菜谱、菜品图或做聊天助手 | 可能编出做不成的菜，成本随用户增长，和通用助手同质化 |
| 云端大模型理解整句 | 体验最好，每次约 0.15 分钱（DeepSeek flash），但要登记，免费用户也会产生成本 |
| iOS 端侧模型理解整句 | 免费、离线，但覆盖机型和地区有限，Web 用不了 |
| 词表 + 最长匹配理解整句 | 零成本、两端一致、可测；说法超出词表时认不出 |
决定
- AI 只把用户的话翻译成现有筛选条件（食材、忌口、不辣、厨具、做法、难度），结果仍由推荐逻辑从现有菜谱里挑。不做 AI 编菜谱、菜品图和聊天。
- 第一步不用模型：
parseCookQuery（packages/cook/src/utils/query.ts）按packages/data/query.json的词表做最长匹配，支持「不要 / 不吃 / 过敏」前后置否定、「没有」和「不辣」。用例在packages/data/fixtures/query.json，Web 和 iOS CookCore 都要通过。 - Web 做菜页的输入框接受整句，识别结果写在输入框下方；只列食材时和原来一样。识别成功和失败分别上报
parse_query、parse_query_empty（只有事件名，不含输入内容）。 - 词表识别是两端共有的底线。真正用模型的 AI 功能只做在 iOS 客户端、只用端侧模型；Web 不做：浏览器没有 Foundation Models，要做只能走云端，会带来调用费用和登记。
- 之后按顺序推进，每步看数据再决定：
- iOS 移植
parseCookQuery，接 App Intents（M3）。 - iOS 在支持的设备上用 Foundation Models 把认不出的句子转成同样的结构，作为增强，没有时回落到词表。
- iOS 27 起端侧模型能看图，在支持的设备上做「拍照识别食材」，可以作为会员功能（M4）。
- 我们不提供云端模型。之后可以让用户在设置里填自己的 DeepSeek API Key（自带 Key）：请求从客户端直接发给 DeepSeek，费用由用户自己承担，我们没有服务器，也没有调用费。Key 只存在本机（iOS 放 Keychain），不上传，也不跟着收藏一起同步。iOS 先做；Web 要看 DeepSeek 接口是否允许浏览器跨域调用。这种方式是否需要登记，上线前要确认。
- iOS 移植
- AI 不能挤占原生体验：
- 不新增 Tab、独立 AI 页面或悬浮按钮。入口复用现有的搜索框；拍照识别做成搜索框里的一个小图标。
- 点选食材的主流程不变。只有用户主动输入整句或拍照时才调用模型。
- 模型不可用（机型、地区、没填 Key）时直接隐藏入口，不弹提示，也不引导开通。
- 不阻塞操作：先给出词表识别的结果，模型结果回来后再补充；超时就放弃。
- 识别出的条件全部用现有的标签和筛选项展示，用户可以逐个移除。设置里有一个总开关，可以关掉 AI。
- 不为 AI 引入影响启动速度或包体积的大依赖。
影响
- 新的说法靠补
query.json词表覆盖；parse_query_empty多了说明词表不够，再考虑上模型。 - 改词表或解析规则时要同时改
fixtures/query.json和 CookCore 的实现。 - 忌口和「不辣」与手动勾选一样会一直保留，用户在识别提示里能看到生效的条件。