核心用法
Diet Tracker 是一款专注于饮食记录与营养分析的个人健康管理技能。其核心工作流程分为三个环节：首先，技能从 USER.md 读取用户基础信息（身高、体重、年龄、性别、活动水平），自动计算每日总能量消耗（TDEE）并设定卡路里目标；其次，当用户输入餐食描述（如"午餐吃了三明治"），技能调用 get_food_nutrition.py 脚本，优先通过 USDA FoodData Central API 查询食物营养数据，API 不可用时回退至本地 food_database.json 数据库；最后，通过 update_memory.py 将餐食记录、营养详情及累计摄入写入按日期命名的记忆文件（memory/YYYY-MM-DD.md），实时反馈剩余卡路里预算及基于热量差值的体重变化预测。
显著优点
1. 权威数据源：直接对接美国农业部（USDA）官方营养数据库，营养信息准确可靠，覆盖超过35万种食品。
2. 智能自动化：无需手动输入卡路里，自然语言描述餐食即可自动识别食物并计算营养，大幅降低记录门槛。
3. 个性化计算：基于 Mifflin-St Jeor 等科学公式计算 TDEE，结合用户活动水平动态调整目标，而非采用一刀切的标准值。
4. 预测性反馈：不仅记录历史摄入，还能基于每日热量盈余/缺口预测体重变化趋势，增强行为激励。
5. 本地化存储：饮食记录以 Markdown 格式保存在本地，用户可随时查阅、导出或进行长期趋势分析。
潜在缺点与局限性
1. 环境依赖性强：脚本中存在硬编码的绝对路径（如 /home/zhaoyh/clawd/...），在不同操作系统或用户环境中部署时可能直接失效，需要手动修改代码。
2. API 限制：默认使用 USDA DEMO_KEY，存在调用频率限制，高频使用场景下可能触发限流；且 API 响应解析存在字段名错误（nutrient vs foodNutrients），可能导致部分查询失败。
3. 食物识别精度：依赖自然语言处理识别食物名称，对于复杂菜品、地方特色小吃或模糊描述（如"妈妈做的红烧肉"）可能识别不准或无法匹配数据库条目。
4. 本地数据库空白：food_database.json 当前为空，API 失效时无有效回退机制，功能将完全中断。
5. 隐私数据集中：用户敏感健康信息（体重、年龄等）集中存储于单一文件，缺乏加密或访问控制机制。
适合的目标群体
- 减脂/增肌人群：需要精确追踪每日热量与宏量营养素摄入的健身爱好者。
- 慢性病管理患者：如糖尿病患者需监控碳水化合物摄入，或高血压患者关注钠含量。
- 健康管理初学者：希望通过简单记录培养饮食意识，但不愿使用复杂专业软件的用户。
- 数据驱动型用户：喜欢查看长期趋势、基于量化反馈调整行为模式的人群。
使用风险
1. 部署失败风险：硬编码路径导致跨平台兼容性差，非 Linux 环境或不同目录结构下需技术能力修复。
2. 数据准确性风险：API 字段解析错误可能导致营养数据获取失败；食物识别偏差会造成记录误差，影响减重决策。
3. 服务中断风险：USDA API 限流或网络波动时，缺乏健壮的本地数据库支撑，核心功能将不可用。
4. 隐私泄露风险：健康数据以明文存储，若设备共享或备份至云端，敏感信息存在暴露可能。