核心用法
Diet Tracker 是一款专为体重管理设计的自动化饮食日志工具。它允许用户通过自然语言描述日常饮食（例如“我午餐吃了鸡胸肉沙拉和一杯橙汁”），技能会立即调用 USDA FoodData Central 官方营养数据库，查询并匹配每一款食物的热量和三大宏量营养素（蛋白质、碳水、脂肪）数据，并自动更新到当日的饮食日志文件中。
技能还集成了定时提醒 cron 任务，在午餐（约12:30）和晚餐（约18:00）时段自动检查用户是否已记录餐食，若未记录则推送提醒，帮助用户建立规律记录习惯。除了事后记录，用户也可随时查询当日剩余热量预算、各项营养素剩余额度，以及基于热量缺口/盈余预测的体重变化趋势。
该技能内置 TDEE（每日总能量消耗）计算器，基于用户身高、体重、年龄、性别和活动水平，自动生成科学的热量目标（默认为1650千卡）。所有饮食数据以标准格式保存在本地 memory 目录下的 Markdown 文件中，结构清晰，既可用于自我回顾，也支持通过 Git 同步到个人 Obsidian 知识库。
显著优点
- 权威数据源支撑：直接调用美国农业部官方 FoodData Central API，确保营养数据来源可靠、可追溯。
- 精细化的宏量营养素追踪：不仅记录热量，更同步追踪蛋白质、碳水、脂肪克数，满足增肌减脂等精细化营养调配需求。
- 主动式行为引导：通过定时 cron 提醒，将“事后补录”转变为“即时记录”，显著提升饮食日志的完整性和坚持率。
- 行为与功能高度一致：安全审查报告确认，技能行为与声明功能完全一致，无后门程序、无数据外泄、无 Agent 注入等严重威胁。
- 本地化数据主权：饮食记录全部保存在用户本地 memory 文件内，结合 Git 同步功能，用户对自身数据拥有完整掌控权。
潜在缺点与局限性
- 需提前配置用户档案：技能高度依赖 USER.md 中的身高、体重、性别、活动水平等参数。初次使用者需花时间准确填写这些信息，否则热量目标计算会不准确。
- 非专业级营养分析：该技能定位为自助式饮食追踪，不提供专业营养师级别的膳食指导，也不分析食物血糖生成指数或微量元素。
- 提醒依赖 cron 运行环境：用餐提醒功能要求 Agent 平台拥有稳定的 cron 任务调度能力，若运行环境不支持 cron 或调度失败，提醒服务将失效。
- 数据库覆盖局限性：部分非常见食物或地方特色菜肴在 USDA 数据库中可能查询不到，系统只能使用近似食物或要求用户手动估算，影响数据精确度。
- 路径配置硬编码：当前代码将数据存储路径硬编码为
/root/clawd/，这既降低了跨环境可移植性，也默认要求 root 权限运行，存在一定安全与兼容性隐患。
适合的目标群体
- 正在进行体重管理的自助用户：有明确减重、维持体重或增肌目标，并且希望通过量化记录保持执行动力和方向感的人。
- 已养成数字记录习惯的极客：习惯使用 Markdown、Obsidian、Git 等工具构建个人知识库的数字化生活爱好者，diet-tracker 能无缝融入其现有工作流。
- 对饮食结构有基本认知的健康人士：能够大致识别食物中的蛋白质和碳水来源，希望通过数据追踪调优自身饮食结构，而非完全依赖 AI 指导的用户。
- 习惯“被动提醒”模式的用户：容易忘记主动记录饮食，需要一个定时唤醒机制来辅助养成记录习惯的人。
使用该技能可能存在的常规风险
- 低来源可信度风险（T3）：该技能由个人开发者 yonghaozhao722 维护，未提供开源仓库地址或组织背书。SKILL.md 中缺少开源许可证声明，长期可用性与维护支持存在不确定性。
- subprocess 调用的潜在隐患：代码使用 subprocess.run 执行 Git add/commit/push 操作。虽然当前所有参数均已硬编码且避免了 shell 注入，但若未来版本维护者在 commit message 中引入外部输入，就可能带来命令注入风险。
- API 调用的速率与稳定性风险：当前使用 USDA 公开 DEMO_KEY，每小时仅限 30 次请求。在频繁记录或测试场景下容易触发限流，导致营养查询失败。此外，代码中未设置请求超时参数，在网络不佳时可能长时间阻塞。
- 数据管理功能缺失：技能目前仅支持写入记录，缺少用户数据导出或删除接口。这在 GDPR 等严格隐私法规地区可能构成合规短板。
- 硬编码 root 路径风险：代码默认在 /root/ 目录运行，这一方面强制要求 root 权限（违背最小权限原则），另一方面降低了在不同操作系统和用户环境中的部署灵活性。