如果模型不可用，用户就不能完成任务，那么 AI 不是增强能力，而是新的单点故障。
这个判断来自一个很小的产品
“今天吃啥”解决的是一个具体问题：饭点没有耐心浏览，希望尽快决定这一顿吃什么。它不是找店、地图或外卖平台，也不需要登录、定位和实时商家数据。
最初很容易想到一个“更 AI”的方案：把预算、口味和天气都交给模型，再让模型返回菜品。问题是，模型未配置、网络超时、输出越界或服务限流时，最基本的决定也会消失。
先定义不依赖 AI 的最小可用结果
第一版把 96 道内置菜作为离线兜底，并提供五种场景。预算、忌口、场景与近期排除先做确定性过滤，餐段、喜欢和近期重复再做本机排序。页面先显示一个候选，后台 AI 才有机会做辅助排序或生成解释。
后续真实反馈把系统推到了更大的 V5 菜库和更具体的行动层：441 道是当前发布物规模，但仍待云端激活与真机复验；其中 60 道已经补齐做法步骤或外卖搜索词。规模变大没有改变主路径，离线兜底必须先工作。
AI 可以知道什么，也要先写清楚
只在需要增强时提供已经过滤后的候选和最低必要上下文。
身份、城市、精确天气、自定义菜和完整使用历史不发送给模型。
隐私边界不是“以后加一个设置”。它直接影响架构：越少数据进入 AI 路径，本机主路径越容易独立验证，失败时也越容易回退。
降级不是一句 try-catch
| 失败 | 页面行为 | 不可接受的结果 |
|---|---|---|
| AI 未配置 | 直接使用本机推荐 | 要求用户先配置模型才能吃饭 |
| 请求超时 | 保留当前结果，不阻塞交互 | 长时间 loading 或清空候选 |
| 返回非法菜品 | 忽略增强结果 | 展示不在候选集或违反忌口的内容 |
| 天气不可用 | 移除天气权重 | 把旧天气当成当前事实 |
| 本地存储失败 | 本次仍可决定，提示状态未保存 | 把写入失败伪装成成功 |
这套方法不等于“不要 AI”
AI 仍然有价值。它可以在候选范围内提供更自然的理由，发现本机规则难以表达的软偏好，也可以帮助验证规则是否过于僵硬。但它必须在一个已经可用的产品上增加价值，而不是用不确定性替换基础能力。
先让用户在无网络和无模型时完成核心任务。
限定输入、输出集合、超时和回退行为。
用用户行为判断增强是否值得保留，而不是默认越多越好。
当前证据到哪里为止
小范围真实试用已经产生“重复”“没胃口”“推荐后不知道下一步”等定性反馈，并推动轮换、口味调整、行动菜、盲盒和“我的食光”迭代。145 项自动化测试已经通过；45 秒仍是目标，不是测得的平均值，10 人连续 7 天正式验证、V5 云端激活、公开上线和效果数据仍未完成。
先写出无 AI 时的最小结果，再列出模型未配置、超时、越界、限流和数据失败时的页面行为。任何一项只能用“请稍后重试”回答，说明产品主路径还没有独立。