核心用法
Water Coach 是一个 hydration 追踪与教练系统，通过统一的 CLI 工具 water_coach.py 提供三大功能模块：
1. 饮水管理（water）
water log <ml>记录饮水量，支持--drank-at回溯时间戳water status实时计算当日累计进度water dynamic智能判断是否需要额外提醒water threshold获取当前小时应达目标百分比water audit <message_id>审计追踪（需手动触发，尊重隐私）
2. 身体指标（body）
body log记录体重、身高、体脂，自动关联饮水目标调整body latest/body history <days>查看历史趋势
3. 分析报表（analytics）
analytics week/analytics month周期性健康简报
关键设计亮点：
- drank_at 强制字段：区分"记录时间"与"实际饮水时间"，避免数据漂移
- 动态提醒（heartbeat）：每30分钟检查进度，而非固定闹钟
- 审计追踪可选启用：message_id 始终保存，但读取对话上下文需显式开启
audit_auto_capture
显著优点
| 维度 | 优势 |
|------|------|
| **数据严谨性** | 时间戳分离设计（logged_at vs drank_at），支持跨天补录；CSV 明文存储，可审计 |
| **智能提醒** | "动态调度"替代固定闹钟，根据实际进度决定是否打扰用户 |
| **隐私可控** | 审计功能默认关闭，显式授权后才读取对话历史，符合最小必要原则 |
| **LLM 友好** | 明确指令：LLM 负责自然语言理解（"两杯"→500ml），计算与存储走 CLI，避免幻觉 |
| **目标灵活性** | 体重×35仅为默认建议，用户可自主设定（如医嘱要求），系统强制确认环节 |
潜在缺点与局限性
1. 依赖外部基础设施：需 Python3、OpenClaw cron、heartbeat 功能，部署门槛较高
2. 无多设备同步：CSV 本地存储，跨设备使用需自行解决数据同步
3. 手动单位换算：用户说"两杯"需 LLM 估算，无内置标准杯量配置，存在个体误差
4. 审计功能摩擦：如需完整上下文，需手动编辑 JSON 开启，对非技术用户不够友好
5. 通知渠道未明确：仅定义"何时发"，未说明通过何种渠道（推送/邮件/语音）触达用户
适合人群
- 需要数据驱动饮水习惯的健康管理用户
- 接受本地 CSV 存储的隐私敏感型用户（相比云端 SaaS 健康应用）
- 已使用 OpenClaw 生态的进阶用户，能配置 cron 和 heartbeat
- 希望自主控制目标而非被算法强制约束的用户
常规风险
| 风险 | 说明 | 缓解措施 |
|------|------|---------|
| 数据丢失 | 本地 CSV 无自动备份 | 建议用户自行配置备份策略 |
| LLM 估算误差 | "一杯"容量因人而异（200-400ml） | 首次使用时校准用户习惯 |
| 隐私误配置 | `audit_auto_capture` 开启后读取对话 | 默认关闭，需手动编辑配置文件 |
| 时间戳滥用 | `--drank-at` 参数可伪造历史记录 | 依赖用户自律，系统无反作弊机制 |
| 目标设定激进 | 用户可能无视建议设过高/过低目标 | 系统仅建议，确认环节由 LLM 代理执行 |