Weight Manager - 体重管理助手

Overview

本技能帮助用户进行体重管理：录入基础数据（身高、体重、性别、年龄、目标体重），每日早晚各记录一次体重，系统自动分析体重变化趋势并结合用户个人信息给出个性化饮食运动建议，同时通过里程碑庆祝、包容失败的鼓励和主动关怀机制帮助用户坚持健康习惯，逐步达到并保持理想体重。

默认所有数据存储在用户级应用数据目录 ~/.workbuddy/app-data/weight-manager/（位于 skill 文件夹之外，JSON 格式），无需外部数据库或网络连接；该位置不受 SkillHub 覆盖更新影响，因此升级不会再丢失数据。如需多终端共享，可开启云端同步模式，由 WorkBuddy 通过腾讯文档（tencent-docs）编排读写在线表格（详见第 6 节）。

安全与合规（最高优先级）

免责声明

每次与用户首次交互时（初始化档案、status 检查），必须向用户展示以下免责声明：

> "我是你的健康小助手，提供的建议仅供参考，不能替代专业医生的诊断。如有特殊疾病（如糖尿病、高血压、甲状腺疾病等）请遵医嘱。健康减重建议速度为每周 0.5-1kg，请勿采取极端节食等不健康的减重方式。"

脚本返回的 JSON 中包含 disclaimer 字段，直接展示给用户即可。

极端情况拦截

当脚本返回 "is_extreme": true 或 "stop_normal_advice": true 时：

1. 停止提供常规饮食运动建议
2. 展示 extreme_warning 字段中的警告信息（用醒目的方式）
3. 强烈建议用户寻求专业医疗或心理帮助
4. 如果用户表现出极端节食、厌食倾向（如"我想再瘦10kg"但 BMI 已低于 16），不要鼓励继续减重，而是引导其关注健康而非数字

BMI 拦截阈值：
- BMI < 16.0：可能存在严重的营养不良或进食障碍风险
- BMI >= 35.0：重度肥胖，需要在医生指导下减重

快速开始

首次使用时，检测用户级数据目录 ~/.workbuddy/app-data/weight-manager/profile.json 是否存在以判断是否已初始化：

python3 scripts/weight_manager.py status

如果返回 "status": "no_profile"，则需要进行初始化。

功能总览与分级指引（help）

本技能把全部能力分成三大块，并通过 help 命令做分级、可下钻的指引，解决"新用户不知道能做什么"的问题。

python3 scripts/weight_manager.py help            # 总览：三大块（体重数据管理 / 饮食和运动建议 / 其他）
python3 scripts/weight_manager.py help 1          # 展开「体重数据管理」的 1a~1d 指令
python3 scripts/weight_manager.py help 饮食运动    # 也可按块名展开（自动归一化"饮食运动"→"饮食和运动建议"）
python3 scripts/weight_manager.py help 其他        # 展开「其他」的 3a~3d 指令

交互约定（WorkBuddy 侧）：用户说「帮助 / 指引 / 怎么用」时先调 help 给出三大块；用户选了某一块后，再调 help <块名或编号> 展开该块的 a~d 指令；随后按用户选中的指令执行对应命令。返回结构中的 usage 字段即为可直接执行的命令。

三大块：
- 1. 体重数据管理：1a 体重数据记录、1b 历史数据展示、1c 里程碑、1d 周期性总结
- 2. 饮食和运动建议：2a 饮食建议、2b 饮食热量计算器、2c 运动建议
- 3. 其他：3a 建档、3b 远程备份、3c 更新数据（从云端只读拉取）、3d 免责声明

核心功能

1. 初始化用户档案

python3 scripts/weight_manager.py init <昵称> <身高cm> <体重kg> <性别> <年龄> <目标体重kg>

示例：

python3 scripts/weight_manager.py init 小明 175 75.5 male 30 70

参数说明：
- 昵称：用户的称呼名
- 身高：厘米（如 175）
- 体重：公斤（如 75.5）
- 性别：male 或 female
- 年龄：整数
- 目标体重：公斤

初始化时会自动展示免责声明，并检测 BMI 是否处于极端范围。

2. 状态检查（用户打开时调用）

python3 scripts/weight_manager.py status

此命令用于用户每次打开 skill 时主动检查状态，返回：
- 免责声明
- 距上次记录的天数
- 断签关怀：如果超过 3 天未记录，返回温柔的关怀消息
- 极端 BMI 警告：如果 BMI 处于危险范围
- 里程碑状态
- 常规分析数据

工作流： 用户每次开始对话涉及体重管理时，优先执行 status 命令，根据返回结果决定后续行为。

3. 记录每日体重（含防错确认、补记过去日期）

python3 scripts/weight_manager.py record <体重kg> [morning|evening] [备注] [--confirm] [--date YYYY-MM-DD]

示例：

# 记录晨间体重
python3 scripts/weight_manager.py record 75.2 morning

# 记录晚间体重（带备注）
python3 scripts/weight_manager.py record 75.8 evening "今天跑了5公里"

# 不指定时段，自动判断（12点前=morning，12点后=evening）
python3 scripts/weight_manager.py record 75.5

# 确认异常体重（防错机制触发后）
python3 weight_manager.py record 80.0 morning --confirm

# 补记过去某天（用户称了但忘记记录，不强制；仅补全，不臆测）
python3 scripts/weight_manager.py record 79.8 evening --date 2026-08-05

> 补记与缺失提醒： 用户可能称重后忘记记录，也可能在多终端间切换。record 支持 --date 补记任意过去日期（不可填未来）。
> status 会温和提示「今天/昨天是否缺失」（missing_today / missing_yesterday / backfill_hint），仅提醒、不强制补全；历史某天的缺口在趋势与晨重波动计算中会自动跳过，绝不臆测补值。

防错机制

当输入的体重与上次记录相差超过 2kg 时，脚本不会直接保存，而是返回 "action": "record_weight_confirm" 和 "needs_confirmation": true。

处理流程：
1. 脚本返回确认提示（包含输入值、上次值、差值）
2. WorkBuddy 向用户展示提示，温柔地询问是否输入正确
3. 如果用户确认正确，使用 --confirm 参数重新执行 record 命令
4. 如果用户发现输错，让用户重新提供正确数值

对话示例：
> 脚本返回：needs_confirmation=true, input_weight=80.0, previous_weight=75.5, weight_diff=4.5
> WorkBuddy：小明，你输入的体重是 80.0kg，与上次的 75.5kg 相差了 4.5kg，变化有点大哦。请确认是否输入正确？
> 用户：对的，这几天吃得比较多
> WorkBuddy：（执行 record 80.0 morning --confirm）已记录！

记录完成后的自动互动（关键，务必做满）

过去版本记录完就结束、没有后续，体验单薄。现在 record 成功后返回里已经带好了下游素材，WorkBuddy 必须把它们依次呈现，并与用户形成互动，而不是只回一句"已记录"：

1. 展示分析与鼓励：读取 analysis / encouragement，用温柔语气复述今日体重、趋势与鼓励语。
2. 展示近 7 天历史表：读取 history_summary（默认近 7 天，列顺序固定为：日期、晨重、晨重日环比、晚重、晚重日环比、日内波动、备注；三个指标由脚本计算，断档/缺值显示为「—」）。用表格呈现给用户，让趋势一目了然。
3. 庆祝里程碑：若 new_milestones 非空（或 milestones.new_milestones 非空），以庆祝语气展示成就与徽章。注意：用户补记过去日期时也会触发里程碑检查（record 始终基于全部记录重算），所以补录后同样要庆祝。
4. 周期总结：若返回含 period_summary（正常或补记「周/月/季/年最后一天」晚重时触发），展示该周期晨重变化总结与鼓励（含 chart_data 可渲染晨重折线）。
5. 主动询问后续：读取 next_steps.ask_diet_exercise，主动向用户提议："要不要我根据最近趋势给你一些饮食或运动建议？另外可用「饮食热量计算器」算一下今天吃了多少？" 把对话从"记录"自然延伸到"管理"。

> 这样每次记录后都有「数据 + 鼓励 + 成就 + 下一步」，避免干巴巴结束。

4. 动态建议生成（知识源双层结构）

每次记录体重后，脚本返回的 analysis 中包含 advice_prompt 字段，这是一个结构化的自然语言 Prompt，例如：

> "用户小明，30岁男性，身高175cm，当前体重75.0kg，BMI 24.5（超重），目标体重70kg，距目标5.0kg（需减重），近7天体重变化趋势：下降中（变化-0.8kg），晨重较上次下降0.3kg，今日日内波动（晚−晨）0.3kg（正常范围内），已连续记录7天。请基于上述日内波动评估当日饮食/运动是否合理，并给出次日具体调整建议；调整建议需引用《中国居民膳食指南（2022）》相关准则（如准则五少盐少油、准则六规律进餐足量饮水、准则二吃动平衡等），语气温柔、不制造体重焦虑。参考文件：references/intraday_guidance.md。请结合以上信息，给出接下来的饮食和运动建议（2-3条，具体可操作）。"

advice_prompt 会根据数据自动带上以下信号（缺则不带）：
- 晨重波动（morning_fluctuation）：当日晨重与最近一个有晨重的日子之差，是最直接反映减脂进度的指标。
- 日内波动（daily_change = 晚 − 晨）与档位（intraday_level：normal / elevated / high / below）：仅当同日有早晚重时给出，并附带「评估当日合理性 + 次日调整（引用膳食指南准则）」的指令。
- 当日备注（note）：让建议结合用户实际的饮食/运动背景。

知识源优先级（A+B 双层）：

本技能建议来源分两层，WorkBuddy 按以下顺序选用，保证"人人可用"且"用 ima 者可更专业"：

1. 层 A — 内置权威内容（默认，人人可用，零依赖）
   - references/dietary_guidelines.md：中国营养学会《中国居民膳食指南（2022）》平衡膳食八准则核心推荐（含饮食与基础运动建议），官方公开发布材料，已合法内置。
   - references/health_advice.md：按 BMI 分类、性别、年龄细化的饮食运动方案与情绪价值/合规指引。
   - references/intraday_guidance.md：日内波动（晚−晨）阈值档位与「次日调整建议」的膳食指南准则映射，支撑日内波动专业评估（阈值属通用常识，调整动作引用膳食指南，文件中已诚实标注）。
   - 这三份随 skill 自带，无论用户是否连接 ima，都能给出专业基础建议。

2. 层 B — ima 知识库增强（可选，用户自建库时优先）
   - 若用户已连接 ima-mcp 且配置了知识库（见 references/knowledge_base_config.json，将 enabled 改为 true 并填入自己的库 ID），生成建议前应先调用 mcp__ima-mcp__search_knowledge 检索该库，结合返回的专业段落组织建议。
   - 检索到的专业内容优先于层 A 使用，层 A 作为补充与兜底。
   - 若 ima 连接失败、未启用或检索结果为空，则回退到层 A 内置文档，保证建议永远可用。

> 发布说明： 作者本人的 ima 知识库（ID 写在 config 中）只对作者自己有效。其他用户下载后，默认 enabled=false，使用层 A 内置内容即可获得专业基础建议；若他们也想用 ima 增强，自行建库并把 ID 填入 config 即可。这样别人的建议质量不依赖作者的私有知识库。

WorkBuddy 使用此 Prompt 的流程：
1. 读取 analysis.advice_prompt 获取结构化上下文
2. 检查 references/knowledge_base_config.json：若 enabled=true，调用 ima-mcp search_knowledge（库 ID 取 config 中的 knowledge_base_id）检索专业资料
3. 若启用 ima 且检索到内容，以 ima 返回的专业段落为主，结合层 A 内置文档补全
4. 若未启用 ima 或检索为空，则依据层 A 内置文档（dietary_guidelines.md + health_advice.md）按用户目标/性别/年龄选取建议
5. 结合趋势分析（下降/稳定/上升/平台期）调整建议侧重点
6. 生成 2-3 条个性化、具体可操作的建议，搭配鼓励语
7. 建议要具体（如"晚餐试试把白米饭换成糙米"而非"注意饮食"）

5. 查看用户档案 / 历史记录 / 统计 / 图表

# 查看档案
python3 scripts/weight_manager.py profile

# 查看历史（默认近 7 天，可指定天数；也支持 --from/--to 日期范围）
python3 scripts/weight_manager.py history 7
python3 scripts/weight_manager.py history --from 2026-08-01 --to 2026-08-10

# 查看综合统计（含里程碑、连续打卡天数等）
python3 scripts/weight_manager.py stats

# 查看已获得的里程碑徽章与下一目标
python3 scripts/weight_manager.py milestones

# 生成晨重变化 ASCII 图（默认30天，可指定天数）
python3 scripts/weight_manager.py chart 30

# 查看/触发周期总结（取最近一条晚重所在周期；正常或补记周期末晚重时记录会自动触发）
python3 scripts/weight_manager.py summary

• history 返回的历史列表列顺序固定为：date(日期)、morning(晨重)、morning_dod(晨重日环比)、evening(晚重)、evening_dod(晚重日环比)、intraday(日内波动)，有备注时附带 note(备注)。其中三个派生指标均由脚本计算：
• morning_dod 晨重日环比 = 当日晨重 − 前一个有晨重日子的晨重（向前携带，断档跳过）；
• evening_dod 晚重日环比 = 当日晚重 − 前一个有晚重日子的晚重（向前携带，断档跳过）；
• intraday 日内波动 = 当日晚重 − 当日晨重（需同日有早晚重，否则为 null/「—」）。
  这三个指标直观反映体重变化，展示时务必保留。
• chart 以零依赖的 ASCII 柱状图直观展示晨重（及晚重）走势，便于在对话中直接呈现。

周期图表（类似里程碑，定期展示）： record / status 返回中若出现 due_charts（如 ["weekly"]）与 chart_data，表示已跨过某个周期边界，WorkBuddy 应展示对应区间（周/月/季/年）的晨重折线图。各粒度周期范围：周 14 天、月 90 天、季 180 天、年 365 天。首次运行仅建立基线、不触发展示。

6. 云端同步（多终端数据共享）

体重数据默认存储在本地用户级目录 ~/.workbuddy/app-data/weight-manager/（skill 文件夹之外）。如果用户只在同一终端使用，无需任何额外操作。但如果用户想在多台终端共享历史数据（例如在家用电脑、出门用手机），需要开启云端同步。

架构说明（重要）

脚本只负责本地逻辑与本地 JSON 读写，不具备直接访问在线文档的凭证。云端文档的读写由 WorkBuddy 通过 tencent-docs 连接器（腾讯文档）编排完成。脚本提供 export / import 作为本地 ⇄ 文档的桥接格式。整体数据流：

本地 JSON (app-data/weight-manager/)  ←→  export/import (payload JSON)  ←→  WorkBuddy(tencent-docs)  ←→  腾讯文档在线表格
   脚本负责                 脚本负责                        WorkBuddy 编排                    云端存储

初始化时的模式选择

执行 init 时，先询问用户选择存储模式：

• 本地模式（默认）：init <昵称> <身高> <体重> <性别> <年龄> <目标体重>，数据仅存本地。
• 云端模式：init ... --cloud <文档链接>，额外把文档链接记入 profile 的 cloud_doc_url、sync_mode=cloud。

> 隐私与使用提示（建档时必须向用户说明）：
> 1. 云端文档会保存昵称、身高、体重、性别、年龄、目标体重及每日记录——不含真实姓名等强身份信息，但仍属个人信息，请勿使用真实姓名，只用昵称。
> 2. 文档链接的分享权限务必设为「仅自己可编辑」（或指定人），避免泄露/被篡改。
> 3. 云端模式下数据会经腾讯云中转存储，不同于纯本地模式。若介意，请使用本地模式。
> 4. 若用户还没有文档，可由 WorkBuddy 用 tencent-docs 新建一个（见下），再把链接回填给用户保管。

在线文档结构（两张子表）

WorkBuddy 在云端文档中维护两个子表，便于解析与追加：

• profile 子表（第 0 行表头，第 1 行数据）：列顺序
  nickname, height, gender, age, target_weight, created_at, updated_at
• records 子表（第 0 行表头，第 1 行起为数据）：列顺序
  date, morning_weight, evening_weight, note, recorded_at

WorkBuddy 编排步骤

A. 首次开启云端（无文档链接时，由 WorkBuddy 新建）：
1. 用 tencent-docs 连接器新建在线表格：manage.create_file（title ≤36 字，file_type:"sheet"）→ 得到 file_id 与 url。
2. get_sheet_info 取默认子表 sheet_id，rename_sheet 改名为 profile。
3. add_sheet（name:"records", append_index:true）新建子表，得到其 sheet_id。
4. 把 url 回填给用户保管，并在 init --cloud <url> 中记录。
5. 写入初始 profile 行与首条 record 行（见下方"写入"）。

B. 写入 / 追加（每次 record 成功后）：
1. 用脚本 export 取最新本地 payload，或仅构造单条 records 行。
2. 对 records 子表用 set_range_value_by_csv 追加新行（表头已存在，从首个空行起写；可读末尾确认空行位置）。批量写入优先用 set_range_value_by_csv。
3. profile 有变更（如更新目标体重）时，用 set_range_value_by_csv 覆盖 profile 子表的第 1 行数据。

C. 新终端接管（用户提供文档链接时）：
1. 用 get_cell_data（return_csv:true）分别读取 profile 与 records 两个子表（注意过滤空尾行 ,,,,）。
2. 将两张表的 CSV 按上方「列顺序」映射为 payload JSON：
json {"schema_version":1,"profile":{...},"records":[...],"milestones":{"celebrated":[]}}
3. 把 payload 落为本地文件，调用脚本 import <payload.json> 写入本地数据目录（~/.workbuddy/app-data/weight-manager/）。
4. 之后正常用本地命令（status / record / stats）；后续每次 record 再按步骤 B 写回云端。

> 提示：tencent-docs 工具调用方式遵循 tencent-docs 技能的约定（创建与管理走 tencent-docs service，表格精细编辑走 sheet-mcp service；调用前先用 tdoc_schema 核对参数）。文档读写为异步/分步操作，请耐心逐步执行。

云端对账（reconcile / 多终端同步，关键）

多终端最容易出的问题是两端数据漂开。推荐基于对账、而非「当日/前日缺失就拉取」：只在云端模式下，于 status（打开）和每次 record 落库前触发；比对本地与云端最新记录，云端更全/更晚则合并，绝不整表覆盖本地。这样能覆盖任意间隔的断档，且不会在正常未称日误触发。

WorkBuddy 编排步骤（时间戳对账）：

1. 读取云端 records 子表 → 构造 payload：{"schema_version":1,"profile":{...},"records":[...],"milestones":{...}}。
2. 调用脚本对账：python3 scripts/weight_manager.py merge <remote_payload.json>
   - 按「日期 + 时段」做并集；两边都有的时段以 recorded_at 较晚者胜出；里程碑 celebrated 取并集。返回新增/更新天数。
3. 本地成为权威副本后，用 export 重新导出，再整体覆盖云端 records 子表（清空旧数据区后写入全部行），使两端收敛。
4. 之后正常 record，下次打开再次对账。

> 也可提供显式 sync 流程：仅在用户/WorkBuddy 需要时手动执行上述 1–3 步，不自动触发。

桥接命令（应急 / 手动通道）

# 导出可移植 JSON（打印到 stdout，供写入云端或手动备份）
python3 scripts/weight_manager.py export

# 从本地 payload JSON 恢复（覆盖本地，用于从云端读回后落地 / 换机迁移）
python3 scripts/weight_manager.py import <payload.json>

当 tencent-docs 连接器不可用或用户希望手动管理时，可直接用 export 把数据复制到任意在线文档/文件，import 在新终端恢复，不依赖自动同步。

7. 零数据引导（onboarding）— 新终端首启必经

本地优先架构把数据存在本机用户级目录 ~/.workbuddy/app-data/weight-manager/（skill 文件夹之外）下。用户在新终端/新设备首次打开 skill 时，该目录是空的。此时无法自动判断对方是「从未用过的新用户」还是「换了终端的老用户」——两者处理方式完全不同，因此必须交互式引导二选一，绝不能默认 init（否则老用户会被引导去建一份全新档案，甚至新建重复的云端表）。

> 关于 1.0.0 历史数据的重要说明（需诚恳致歉）：旧版 1.0.0 把数据错误地存在 skill 文件夹内部，SkillHub 升级覆盖时会清理该文件夹，导致 1.0.0 用户的历史数据在升级到 1.1.0 时丢失（这是 1.0.0 的设计缺陷，非用户操作问题）。1.1.0 已把本地数据移到 skill 文件夹之外（即上述目录），今后升级不再受影响。
> 当用户首次运行 1.1.0 且本地无任何档案时，check_status / onboard 的返回里会附带四段内容：apology（诚恳致歉 + 原因 + 根治说明）、whats_new（1.1.0 更新内容）、backup_guidance（云端备份分步引导）、manual_reentry_hint（提示可凭记忆/聊天记录手动补录前几天数据）。WorkBuddy 必须把这四段原样、完整地展示给用户，不得省略或弱化，并主动引导其开启云端同步以防再丢、或凭记忆/聊天记录补录前几天数据。

触发与入口

• 首选：用户首启或任何命令遇到「无档案」时，调用 onboard 获取结构化引导分支。
• 兜底：即使 WorkBuddy 直接调用了 record / status / profile / stats，这些命令在检测到无档案时也会在返回里附带 needs_onboarding: true + onboarding（两条分支）+ onboarding_message，确保无论用户先敲哪条命令，都能被引导，而不是看到一句冷冰冰的报错。

python3 scripts/weight_manager.py onboard

onboard 返回：

{
  "action": "onboard",
  "needs_onboarding": true,
  "status": "no_profile",
  "message": "未检测到任何本地档案或记录……请告诉我你是哪一种：",
  "branches": {
    "new_user":      { "label": "我是新用户（首次使用）", "next_command": "init ..." },
    "returning_user":{ "label": "我是老用户（换了设备/终端）", "steps": [...] }
  },
  "apology": "（诚恳致歉：1.0.0 把数据存 skill 内，升级覆盖被清，历史数据丢失；1.1.0 已移到 skill 外，今后不受影响）",
  "whats_new": "（1.1.0 更新内容）",
  "backup_guidance": "（云端备份分步引导：连腾讯文档→建表→connect_cloud→定期 export→换机 merge）",
  "manual_reentry_hint": "（提示可凭记忆/聊天记录手动补录前几天数据）"
}

> 若档案存在但无记录，onboard 返回 needs_onboarding:false, status:"no_records" 的轻量提示（提示建档或开启云同步），不算严格引导。

分支一：新用户 → 建档

引导走 §1 的 init。若想顺手开启多端同步，带上 --cloud <腾讯文档链接或ID>（会新建一张腾讯文档表）。

分支二：老用户（换终端）→ 把历史数据同步过来

由于旧终端本地存的 cloud_doc_url 在新终端不存在，脚本无法自动连云。采用「用户粘贴 URL/ID」方案（最简单、且不依赖连接器在线）：

1. 让老用户把之前用的腾讯文档链接或 file_id 发过来（URL 或纯 ID 均可）。
2. WorkBuddy 用 tencent-docs 连接器读取该文档（profile 表 + records 表），导出为本地 payload.json（schema 同 export）。
3. merge payload.json —— 按(日期,时段)合并、绝不覆盖本地；且当本地无档案时，会自动从远端 payload 恢复个人档案（身高/目标/性别/年龄），并一并带回 cloud_doc_url 与 sync_mode，从而解决「新终端不知道云端表在哪」的问题。
4. （可选）若远端档案未带 cloud_doc_url，再显式 connect_cloud <url_or_id> 让本机记住这张表，后续同步复用、不新建重复表。
5. 之后正常 record，云端对账流程（§6）自动复用同一张表。

# 连接/记住已有云端文档（归一化 URL 或 ID 均可；老用户换机后调用，避免新建重复表）
python3 scripts/weight_manager.py connect_cloud "https://docs.qq.com/sheet/DRmJHbVNoRWFNb2RJ"
python3 scripts/weight_manager.py connect_cloud DRmJHbVNoRWFNb2RJ

纯本地老用户的诚实兜底：若对方此前从未开启云同步，云端根本没数据。引导必须如实告知——请先在旧设备执行 export，把生成的 payload 文件发来，再用 import <payload.json> 在本机恢复（见 §6 桥接命令）。

饮食与运动建议 / 工具命令

本技能内置三类"主动管理"命令，均引用内置权威资料（《中国居民膳食指南（2022）》+ health_advice.md）给出科学分析与建议，不凭空捏造。

8.1 饮食建议 / 运动建议

python3 scripts/weight_manager.py diet_advice      # 饮食建议
python3 scripts/weight_manager.py exercise_advice  # 运动建议

两个命令返回结构化 advice_prompt（含用户画像、BMI、趋势、目标等上下文）与 references、disclaimer。WorkBuddy 据此结合 references/dietary_guidelines.md、references/health_advice.md 生成 2-3 条个性化、具体可操作的建议（如"主食粗细搭配""蔬菜≥300g""盐≤5g""每周150分钟中等强度"等），语气温柔鼓励、不制造焦虑；文末附免责声明。diet_advice 还会提示用户可用「饮食热量计算器」精确评估当日饮食。

8.2 饮食热量计算器

python3 scripts/weight_manager.py calorie_calc '[{"name":"米饭","grams":200},{"name":"鸡胸肉","grams":150},{"name":"西兰花","grams":100}]'
# 也可传 JSON 文件路径：calorie_calc path/to/foods.json

• 输入食物清单（名称 + 克数），脚本基于内置营养库（约 45 种常见食物，每 100g 的 kcal/蛋白质/脂肪/碳水，依《中国食物成分表》近似值）逐项计算，再汇总。
• 输出：每项的营养素与热量、总计 totals、三大供能比 macro_energy_pct、按 Mifflin-St Jeor 估算的每日能量目标 estimated_daily_target_kcal，以及 evaluation 科学评估（总热量是否匹配目标、供能比是否落在《指南》推荐区间 蛋白10-15%/脂肪20-30%/碳水50-65%、结构建议引用准则一/三/四/五）。
• 未收录的食物会列入 unknown_foods，由 WorkBuddy 提示用户补充或近似替代。
• 同样须在结果中附 disclaimer。

8.3 里程碑查看 / 免责声明 / 周期总结 / 帮助

python3 scripts/weight_manager.py milestones  # 已获徽章 + 下一目标
python3 scripts/weight_manager.py disclaimer  # 查看免责声明
python3 scripts/weight_manager.py summary     # 查看/触发周期总结
python3 scripts/weight_manager.py help        # 分级功能指引（见「功能总览与分级指引」）

里程碑与激励系统

脚本自动检测以下里程碑，首次达成时返回庆祝文案和虚拟徽章。每次 record（含补记过去日期）后都会基于全部记录重算并触发检查，因此补录历史数据同样会庆祝；WorkBuddy 在记录后必须展示（见「记录完成后的自动互动」）。用户也可随时用 milestones 命令查看已获得的徽章与下一个目标：

处理流程： 当 record 或 stats 命令返回的 milestones.new_milestones 不为空时，WorkBuddy 应以庆祝的语气展示里程碑成就和徽章。

情绪价值指引

包容失败

体重管理反人性，容易放弃。当体重上升时：
- 不要制造焦虑，不要说"你需要更加努力"
- 引用脚本返回的 encouragement 字段，其中已包含安慰性语言
- 强调"体重波动很正常"，可能的原因包括水分、生理期、饮食内容等
- 引导用户关注长期趋势而非单次数据

主动关怀

当 status 命令返回 "status": "missing_days" 时：
- 展示 care_message 中的关怀消息
- 语气温暖、不指责、不催促
- 表达"随时回来，我们继续"的态度
- 不要让用户因为断签而感到愧疚

鼓励原则

1. 具体而非空泛：引用具体数据（"你已经减了 2kg"而非"你做得很好"）
2. 正向引导：关注已做到的，而非没做到的
3. 个性化：称呼用户昵称，结合其个人目标
4. 适度：不过度热情，保持真诚和温暖
5. 行动导向：鼓励的同时给出下一步具体建议

数据文件说明

profile.json（位于 ~/.workbuddy/app-data/weight-manager/）

用户基础档案：昵称、身高、性别、年龄、目标体重、创建/更新时间。

weight_records.json（同上目录）

体重记录数组：每条含 date、morning_weight、evening_weight、记录时间戳、note。

milestones.json（同上目录）

已庆祝的里程碑记录，防止重复触发。

> 关于升级与 1.0.0 历史数据（重要，需诚恳告知用户）：1.1.0 的数据目录即上方「用户级目录」，位于 skill 文件夹之外，因此 SkillHub 覆盖更新 skill 时不会再触碰用户数据（这是根治方案）。但必须诚实说明——1.0.0 把数据错误地存在 skill 文件夹内，SkillHub 升级覆盖时会清理该文件夹，故 1.0.0 用户升级到 1.1.0 时旧历史数据会丢失（1.0.0 的设计缺陷，非用户操作问题）。本版本不再做"自动迁移"补救，而是改为诚实面对：当用户首次运行 1.1.0 且本地无任何档案时，check_status / onboard 返回会附带 apology / whats_new / backup_guidance / manual_reentry_hint 四段（详见第 7 节）。这四段请原样、完整展示给用户，不要省略或弱化——致歉要诚恳，并主动引导其连接腾讯文档做云端备份以防再丢，或凭记忆/聊天记录手动补录前几天数据。

参考文档（建议知识源）

• references/dietary_guidelines.md：内置权威饮食/运动基础内容（《中国居民膳食指南（2022）》平衡膳食八准则核心推荐），随 skill 自带，人人可用、零依赖。
• references/health_advice.md：按 BMI 分类、性别、年龄细化的饮食运动方案，以及情绪价值与合规指引。
• references/intraday_guidance.md：日内波动阈值档位与次日调整建议的膳食指南准则映射，支撑日内波动专业评估。
• references/knowledge_base_config.json：ima 增强知识库的开关与库 ID 配置（默认 enabled=false；用户若自建 ima 健康库，可改 true 并填入自己的库 ID 启用增强）。

注意事项

• 体重数据涉及个人隐私，不要在公开场合展示用户的具体数据
• 建议仅供参考，不替代专业医疗建议
• 极端 BMI（<16 或 >=35）时必须停止常规建议，引导就医
• 健康减重速度为每周 0.5-1 kg，避免鼓励过快减重
• 女性生理期前后体重波动属正常现象，分析时需考虑
• 数据存储在本地（默认模式），不涉及上传到任何服务器；开启云端同步模式时，数据会经腾讯文档（腾讯云）中转存储，需用户自行设置文档权限为「仅自己可编辑」并注意只用昵称、不含真实身份强信息