一、本周工作概述

本周重点推进了智能菜单APP中"美食知识库"模块的升级改造。在原有的静态知识浏览功能基础上，设计并实现了"AI驱动的动态知识关联系统"，打通了"菜品识别→知识库检索→AI内容生成→前端展示"的完整链路。现在，用户查看任意一道识别出的菜品时，系统都能自动关联相关名人故事、文化背景和趣味知识，不再是冰冷的静态条目罗列。

二、为什么要把静态知识库做成动态的？

2.1 问题分析

最初的知识库模块更像一个"美食维基百科"——用户可以按分类浏览菜系、食材、烹饪方法，但这种设计有一个明显缺陷：与核心的拍照识别功能是割裂的。用户拍完菜单、识别出菜品后，想了解更多信息，需要手动退出、打开知识库、搜索，体验断层。

改造的核心思路是：让知识库"主动"服务用户。用户只需点击菜品详情页的"AI知识探索"按钮，系统就会自动完成以下流程：用户点击菜品 → 提取菜名/标签/食材 → 多表模糊搜索知识库 
→ 搜索结果作为素材 → AI生成个性化故事 → 结构化卡片展示。

我认为知识库的价值不应该只是"数据库里的条目"，而应该是能为每道识别出的菜品提供"知识化解读"的智能引擎。用户不需要知道"知识库"这个概念，他们只需要在拍完菜单后，能一键了解这道菜背后的故事。

基于这个理解，我确定了自己的核心任务：建立菜品到知识的自动关联机制，让AI基于知识库内容进行个性化创作，最终呈现给用户。

2.2 解决方案

设计"菜品知识关联"功能模块，核心思路：

1. 知识库搜索：根据识别出的菜品名称、标签、食材等信息，在知识库中搜索相关的名人、文化、菜系、烹饪方法等内容

2. AI内容生成：将搜索结果作为参考上下文，调用Qwen大模型生成个性化的美食故事、文化背景、趣味知识等

3. 备用机制：当AI不可用时，自动降级为知识库直接展示，保证功能可用

2.3 技术实现

后端新增文件：backend/services/dish_knowledge_service.py

核心函数设计：

• search_knowledge_base()：在名人美食、饮食文化、菜系、烹饪方法四张表中进行模糊搜索

• build_knowledge_summary()：将搜索结果构建为AI可理解的上下文摘要

• get_dish_knowledge()：主函数，协调搜索和AI生成流程

• _build_fallback_content()：AI不可用时的降级方案

后端修改：在 qwen_service.py 中新增 generate_dish_knowledge_with_ai() 函数，通过精心设计的Prompt让AI生成结构化的美食知识内容。

API接口：在 main.py 中新增 POST /dish-knowledge-link 端点，接收菜品信息返回知识关联结果。

2.4 Prompt设计要点

AI生成内容的结构化要求：

{
    "famous_story": "名人故事/历史典故",
    "cultural_background": "文化背景/起源历史",
    "fun_facts": "3个趣味知识点",
    "eating_etiquette": "食用建议/礼仪",
    "health_tips": "健康提示",
    "related_dishes": "相关菜品推荐",
    "summary": "一句话总结"
}

三、方案设计：如何让知识库"活"起来

3.1 技术方案对比

在设计阶段，我考虑了两种方案：

我的选择：方案B，并设计了降级机制——当AI不可用时自动回退到方案A，兼顾质量与稳定性。

3.2 为什么不能用纯AI生成

有人可能会问：既然有AI，为什么不直接让AI生成内容，还要先搜知识库？

我的理解是：AI容易产生"幻觉"——如果没有知识库提供的真实素材作为约束，AI可能会编造名人故事、虚构历史典故。而我们的应用场景是帮助用户在境外真实就餐，内容的可信度至关重要。因此，知识库搜索结果作为"锚点"，AI在此基础上进行润色和扩展，既能保证信息准确性，又能提升内容的可读性和趣味性。