从想法到上线:一个宠物食谱查询工具的诞生
起因
养狗的人大概都有过这种时刻:站在厨房,手里拿着一块鸡胗,脑子里转着三个问题——这东西狗能吃吗?要怎么处理?上次喂是什么时候来着?
网上搜一圈,说法互相矛盾。问 AI,回答看着挺像那么回事,但你不敢拿毛孩子的健康赌它没有幻觉。
所以我想做个小工具:不靠 AI,靠结构化的知识库,查食材、记喂食、提醒下次什么时候能喂。自己用,简单就好。
方案讨论:三条路线怎么选
最开始我列了三条路线:
| 路线 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| A | 结构化知识库 + 搜索 | 答案可控、准确 | 只能查预设内容 |
| B | AI 问答(RAG) | 能回答开放问题 | 可能编造信息,喂错出事 |
| C | 混合:知识库做底座 + AI 做交互 | 既准确又灵活 | 开发量最大 |
最后选了 路线 A。理由很简单:
- 宠物喂食出错可能害了动物,准确性是第一优先级,幻觉风险不可接受。
- 自己用,不需要回答"我家狗 15kg 怎么过渡到自制粮"这种开放问题。
- 不用配 LLM API key,省事。
但我加了一个关键功能:喂食记录 + 间隔提醒。这把工具从一个静态查询变成了一个喂食助手——查完就记,记完提醒,形成闭环。
技术选型
自己用的工具,越简单越好:
- Streamlit:几行 Python 就是一个 Web 界面,不用碰 HTML/CSS
- SQLite:单文件数据库,零配置,随身带
- Python 3.9:sqlite3 是标准库,实际依赖只有 streamlit 一个
数据模型
两张表,够用了:
ingredients(食材知识库)
├── 名称、适用宠物、安全等级
├── 处理方法、建议间隔天数
├── 建议单次量、营养说明
└── 注意事项、分类
feeding_log(喂食日志)
├── 日期、食材ID
├── 重量(g)、宠物名
└── 备注
"下次什么时候能喂"的逻辑就一行:
今天 - 上次喂食日期 ≥ 建议间隔天数 → 可以喂了
预填充数据:22 种常见食材
这是前期主要工作量——不是写代码,是整理知识。我预填了 22 种狗的常见食材:
肉类:鸡胸肉、牛肉、鸭肉、三文鱼
内脏:鸡胗、鸡肝、羊肝、鸡心
蔬菜:南瓜、胡萝卜、西兰花、红薯
水果:苹果、蓝莓
其他:鸡蛋、酸奶、白米饭
危险食材:巧克力、葡萄、洋葱、大蒜、木糖醇
每种食材都录入了安全等级(可吃/有条件/禁止)、处理方法、建议间隔天数、建议喂食量、营养说明和注意事项。
比如羊肝:安全等级"有条件",建议间隔 7 天,长期过量致维生素 A 中毒。这就是"多久喂一次"问题的答案——不是"偶尔",而是至少隔 7 天。
开发过程
用 CodeArts(华为云的 AI 编程助手)生成代码。我给了详细的 prompt,包括数据库设计、22 条食材数据、5 个页面的功能描述。CodeArts 依次创建了:
requirements.txt— 依赖清单seed_data.py— 22 条预填充数据database.py— 数据库初始化和操作函数app.py— Streamlit 主应用(5 个页面)
中间遇到一个 Python 环境冲突:沙箱里 PYTHONPATH/PYTHONHOME 指向了一个有问题的 Python 3.12,导致 import io 都报错。CodeArts 自己排查到了,用 env -u PYTHONPATH -u PYTHONHOME 清除环境变量后解决。
Streamlit 安装也费了点劲,默认 pip 源太慢,切到清华镜像后搞定。
反思
做对了的:
- 选了路线 A 而不是 B。对于宠物喂食这种安全敏感场景,结构化知识库比 AI 问答靠谱。准确性 > 灵活性。
- 加了喂食记录功能。静态查询谁都能做,但"查→记→提醒"的闭环才是工具的价值所在。
- 预填充了 22 种食材。工具的价值在数据,不在代码。空壳工具没人会用。
还可以改进的:
- 目前只有狗的数据,猫的还没加。数据模型里留了
species字段,加猫不用改结构。 - 建议间隔是固定天数,没有考虑宠物体重、年龄、健康状况等因素。比如 7kg 的柯基和 30kg 的金毛,肝脏的代谢能力肯定不一样。
- 没有营养均衡分析。如果一天喂了鸡胸肉 + 南瓜 + 苹果,蛋白质和纤维够不够,目前回答不了。这需要路线 C(混合方案)才能做好。
但作为 v1,够用了。先跑起来,用着,缺什么再加。
- 点赞
- 收藏
- 关注作者
评论(0)