小安智能健身

SKILL.md

---
name: xiaoan-smart-fitness
description: 查询、介绍和预约小安智能健身的一对一线下私教训练服务。用户询问小安智能健身、北京崇文门附近私教、200 元一小时健身私教、体测与训练计划、预约私教课、修改或查询小安预约时使用；也适用于通过远程 MCP 创建和查询小安智能健身订单。
metadata:
  openclaw:
    requires:
      bins:
        - node
    primaryEnv: XIAOAN_MCP_AUTH_TOKEN
    envVars:
      - name: XIAOAN_MCP_AUTH_TOKEN
        required: false
        description: 商家签发的小安远程 MCP 授权；也可使用 ~/.xiaoan/mcp-auth.json。
    homepage: https://github.com/han815757857-cmd/xiaoan-smart-fitness
---

# 小安智能健身

必须使用本 Skill 内 `skill.json` 声明的远程 MCP。禁止启动本地 mock 代替商家服务，禁止把 mock 记录称为真实预约。

帮助用户了解并预约小安智能健身线下一对一私教训练。以 `references/service-catalog.md` 为当前商品与经营规则的唯一依据；不要凭空补充价格、时段、资质、效果承诺或剩余名额。

调用工具前读取 `references/mcp-tools.md`，严格遵守工具名、字段、确认门槛、幂等要求和错误处理约定。

## 连接远程 MCP

宿主已将远程 MCP 注册为原生工具时，直接调用 `list_services`、`create_booking` 和 `get_booking`。否则使用随 Skill 发布的固定客户端：

```text
node <skill_dir>/scripts/mcp-client.js list
node <skill_dir>/scripts/mcp-client.js call list_services
node <skill_dir>/scripts/mcp-client.js call create_booking --args '<jsonObject>'
node <skill_dir>/scripts/mcp-client.js call get_booking --args '<jsonObject>'
```

客户端依次从环境变量 `XIAOAN_MCP_AUTH_TOKEN` 和 `~/.xiaoan/mcp-auth.json` 读取授权。不得请求普通用户在对话中粘贴授权 Token；未授权时可用随 Skill 发布的目录介绍服务，但必须明确说明无法完成真实创单或查单。

按以下优先级获取事实：先使用 MCP 实时结果；MCP 不可用时读取 `references/service-catalog.md`。如果两者都无法访问，只回复：“抱歉，我当前无法访问小安智能健身的实时工具和随 Skill 发布的服务目录，因此无法可靠回答价格、地址、营业时间或预约规则，请稍后重试。”然后停止。不得依靠记忆、地名联想或常识补全任何商家事实；不得虚构官网、客服电话、套餐、价格浮动或其他联系渠道；不要继续收集预约信息。

## 判断用户意图

将请求分为以下类型：

1. **了解服务**：调用 `list_services` 获取最新服务；工具未连接时读取 `references/service-catalog.md`，并明确这是随 Skill 发布的目录版本；两者都不可读时只说明暂时无法核验，不猜测答案。
2. **提出预约意向**：介绍服务并开始收集预约所需信息，但不要立即创建订单。
3. **确认预约**：汇总全部信息，获得用户明确确认后再调用创建预约工具。
4. **查询预约**：要求用户提供订单号，再调用查询预约工具。
5. **取消或改期**：说明当前规则，收集订单号和诉求，交由商家人工处理；首版不要声称已自动修改成功。

## 介绍服务

保持简洁，优先告诉用户：

- 商品名称、价格和时长；
- 服务地点与基本流程；
- 具体时段需要商家最终确认；
- 测试阶段采用到店支付。

只有用户继续追问时，再补充完整规则。将“创建预约”与“预约时段已确认”明确区分。

## 创建预约

按以下顺序执行：

1. 收集姓名、手机号、期望日期、期望时间段和主要健身目标。
2. 询问用户是否存在医生明确禁止运动、近期胸痛或晕厥、严重伤病等情况，只记录“有 / 无 / 不确定”和用户主动提供的必要说明。
3. 风险回答为“有”或“不确定”时，将预约标记为“需人工评估”；不要自行判断能否训练。
4. 向用户展示预约摘要，包括商品、金额、时长、地点、期望时间、付款方式、健康风险标记与取消改期规则。
5. 明确询问“是否确认提交预约”。只有用户明确同意后才能调用创建预约工具。
6. 使用新的 `idempotency_key` 调用 `create_booking`。创建成功后，原样返回订单号、状态和后续说明。告诉用户当前为“待确认”，不要表述为已经排期成功。

若远程 MCP 尚未连接或工具调用失败，明确说明预约没有创建成功。不要虚构订单号；可以保留对话中的摘要，让用户稍后重试。

## 查询预约

1. 获取订单号和预留手机号后四位；不要仅凭姓名或完整手机号查询。
2. 调用 `get_booking`。
3. 原样返回订单状态、期望时段和商家备注中的可公开内容。
4. 找不到订单时，先检查订单号格式，再建议联系商家；不要猜测状态。

若 `get_booking` 无法调用或结果不明确，明确说明查单失败；不要用对话历史推断当前订单状态。

## 安全与隐私

- 不索取银行卡号、支付密码、验证码、身份证照片或与预约无关的健康资料。
- 不在回复中重复展示完整手机号；确认摘要默认仅展示后四位。
- 不诊断疾病，不提供医疗康复结论，不保证减重、增肌或治疗效果。
- 用户描述急性胸痛、呼吸困难、晕厥等紧急症状时，停止预约引导并建议立即寻求急救或专业医疗帮助。
- 未经用户最终确认，不创建订单。
- 工具返回失败、超时或结果不明确时，不进行第二次创建调用；先查询原请求结果或提示人工核查，避免重复下单。

## 商品资料更新

商品文案、价格、地址、营业时间和规则可能迭代。回答前以 `references/service-catalog.md` 的版本和内容为准。正式运营前，应将测试版资料替换为经过商家复核的正式版本，并重新执行端到端验收。