商务接待排座（付费版）
商务宴请与商务出行座次安排：座次推理在端侧完成（免费），HTML 座位图渲染通过付费 API 交付（0.01 元/次）。
0. 目录结构
business-reception-seating-pay/
├── SKILL.md # 本文件
├── scripts/
│ └── call_seating_api.py # 付费 API 客户端（纯标准库，无第三方依赖）
├── references/
│ ├── rules.md # 座次规则库（排座推理依据）
│ └── assets/ # 参考配图
└── examples/ # 请求体示例 JSON
> 本版本不内置本地 HTML 生成器，座位图统一由云端付费接口生成。
1. 何时使用
当用户提到以下任意场景或关键词时，立即加载本 skill：
- 商务宴请 / 商务饭局 / 吃饭排座位
- 坐车排座位 / 乘车座次 / 轿车座次 / 商务车座次
- 商务接待座次 / 饭局座位图
- 主陪、副陪、主宾、副主宾、三宾、四宾、三陪、四陪
- 圆桌座次 / 长条桌座次 / 八仙桌座次 / 公司聚餐座位
2. 核心规则来源
详细规则、角色定义、车型规则见 references/rules.md。排座推理必须以该规则库为准。
3. 交互流程
第一步：确认场景
先问用户：
> 您好，需要安排哪种座次？
> 1. 商务宴请/饭局（圆桌/长条桌/八仙桌）
> 2. 商务乘车（轿车/SUV/商务车/中巴）
> 3. 都要
第二步：收集信息
场景 A：商务宴请/饭局
请用户依次提供：
- 桌子类型：圆桌 / 长条桌 / 八仙桌 / 不确定
- 总人数
- 出席人员名单，以及每个人的身份/职务
- 区分我方与对方：哪些是东道主（我方），哪些是客人（对方）
- 尊贵程度排序：请用户确认客人内部的高低顺序，以及我方人员的高低顺序
- 特殊需求：是否有人不喝酒、需要翻译、女士/长者优先、是否由副陪代劳买单等
场景 B：商务乘车
请用户依次提供：
- 车型：轿车 / SUV / 面包车（中巴）/ 7 座商务车（GL8 等）
- 驾驶方式：专职司机 / 主人或领导亲自开车
- 总人数
- 人员名单与身份
- 区分我方与对方
- 尊贵程度排序
- 特殊需求：是否需要秘书/翻译坐副驾/靠近首长服务
第三步：排座并说明理由（端侧，不产生费用）
根据 references/rules.md 进行排座：
- 圆桌：主陪面门、主宾在主陪右手边第一位、副主宾在主陪左手边第一位、副陪背门。
- 长条桌：远门侧为客席（A 席），近门侧为主方席（B 席），A1/B1 居中面对正门。
- 轿车（专职司机）：后排右座 > 后排左座 > 副驾驶（秘书/随员）> 司机。
- 轿车（主人自驾）：副驾驶 > 后排右 > 后排左 > 后排中。
- 面包车/中巴：首长坐司机正后方一排左侧，秘书坐同排右侧。
- 7 座商务车：中排右侧 > 中排左侧 > 后排 > 副驾驶。
排完后，先用文字向用户简要说明每个人的位置及原因，征得用户同意后再调用付费接口生成座位图。
第四步：调用付费 API 生成 HTML 座位图
请求体格式
将排座结果写为 JSON 文件（例如 plan.json），格式与示例见 examples/ 目录：
圆桌（seats 必须按顺时针顺序从 12 点钟方向（主陪位置）开始排列）：
{
"type": "round_table",
"title": "商务宴请圆桌座次方案",
"table_label": "商务宴请",
"seats": [
{"label": "张总", "role": "主陪", "side": "host", "note": "东道主，正对大门"},
{"label": "孙董", "role": "主宾", "side": "guest", "note": "最尊贵客人，主陪右手边"},
{"label": "李董", "role": "副主宾", "side": "guest", "note": "主陪左手边第一位"},
{"label": "陈副总", "role": "副陪", "side": "host", "note": "背门，负责催菜倒酒"}
],
"reasons": [
"主陪张总正对大门，符合面门为尊原则。",
"主宾孙董安排在主陪右手边第一位，体现右高左低。"
]
}
长条桌（side_a 为客席、side_b 为主方席，均按从左到右顺序填写）：
{
"type": "long_table",
"title": "长条桌会议座次方案",
"table_label": "长条桌",
"side_a": [{"label": "李主任", "role": "A1"}, {"label": "郑译员", "role": "A3"}],
"side_b": [{"label": "张总", "role": "B1"}, {"label": "黄副总", "role": "B2"}],
"reasons": ["A1/B1 居中面对正门。"]
}
乘车（car_type：sedan5 轿车 / suv / van 面包车中巴）：
{
"type": "car",
"title": "轿车乘车座次方案",
"car_type": "sedan5",
"seats": [
{"seat_id": "driver", "label": "王师傅", "role": "司机"},
{"seat_id": "front", "label": "周秘书", "role": "秘书"},
{"seat_id": "rear_right", "label": "赵董", "role": "1号首长"}
],
"reasons": ["1 号首长赵董坐后排右座，是轿车最尊位。"]
}
轿车/SUV 的 seat_id：driver、front、rear_left、rear_right；
面包车/中巴另有：mid_left、mid_right、rear_left、rear_right。
调用方式
方式一：运行内置客户端脚本（推荐，纯 Python 标准库）：
python <skill根目录>/scripts/call_seating_api.py -i plan.json -o result.html
方式二：直接 HTTP 调用：
POST https://seating.atanai.cn/api/seating
Content-Type: application/json
<plan.json 内容>
该接口接入支付宝 AI 按量付费（402 协议），单价 0.01 元/次：
- 首次请求返回
HTTP 402+Payment-Needed响应头（Base64URL 账单），由宿主智能体运行时的支付能力自动完成支付； - 携带支付凭证重新请求后返回
HTTP 200； - 若运行时未开通支付能力，请提示用户开通后再试。
成功响应（HTTP 200）
{
"resource_id": "/api/seating",
"content": {
"status": "success",
"service_type": "BUSINESS_RECEPTION_SEATING",
"seating_type": "round_table",
"title": "商务宴请圆桌座次方案",
"html": "<!DOCTYPE html> ...完整 HTML 座位图..."
},
"trade_no": "2026xxxxxxxxxxxxxxxxx",
"out_trade_no": "A2M...",
"fulfillment_confirmed": true
}
把 content.html 字段的内容写入 result.html 文件后展示给用户（智能体可用 present_files 等方式打开预览）。
错误码：400 INVALID_PLAN（请求体不是合法 JSON 方案）、500 CONFIG_ERROR（服务端配置异常，请稍后重试）。
服务端支付保障（402 协议完整实现）
付费资源服务端按支付宝 AI 按量付费规范完整实现，包含以下保障，调用方无需重复实现，但重试时必须遵守幂等约定：
- 账单签发：
HTTP 402+Payment-Needed（Base64URL），账单含out_trade_no、amount、currency、resource_id、pay_before（30 分钟支付时限）与RSA2卖家签名（字段按字典序签名）。 - 验付调用（payment.verify）：服务端收到携带
Payment-Proof的请求后，先调用支付宝alipay.aipay.agent.payment.verify接口验付，校验通过才交付资源；验付失败或凭证过期会重新下发 402 账单。 - 履约确认（fulfillment.confirm）：资源交付后服务端立即调用
fulfillment.confirm回执，成功响应中fulfillment_confirmed恒为true。 - 订单持久化与幂等：每笔账单在签发时即持久化（SQLite，
out_trade_no唯一约束）。重试约定：
- 携同一张账单（同一out_trade_no）的重复请求：验付通过后直接返回已交付资源，响应中already_fulfilled: true，不会重复扣费、不会重复计费；
- 重新发起全新请求会签发新的账单（新的out_trade_no），视为新的一笔交易；
- 因此客户端支付后重试时应复用同一账单对应的请求，不要丢弃账单重新请求。 - 金额防篡改：凭证中的交易金额与账单金额不一致时拒绝交付。
第五步：展示结果
- 用简洁文字总结：主陪/主宾/副陪分别是谁、坐在哪里，1-2 条核心排座理由。
- 展示
result.html座位图。 - 如用户有后续调整，继续对话修改方案；确认后可再次调用 API 重新出图（每次调用计费一次）。
4. 多轮调试说明
- 用户如果只说"帮我排个座位"，不要直接给结果，先收集人员和场景信息。
- 如果用户对某个位置不满意，可以单独调整：例如"让王总坐主宾旁边""让秘书坐副驾"。
- 方案调整阶段（文字确认）不计费；只有最终确认出图时才调用付费 API。
- 如果用户提供的身份排序与你推断的不一致，以用户最终确认的顺序为准。
- 鼓励用户上传餐厅包厢照片或车型照片，以便更准确判断门向/上菜口方向。
5. 边界情况
- 人数极少（如 3-4 人）：圆桌可能只需主陪、主宾、副陪即可，其余位置留空。
- 主人自驾：必须切换为"副驾驶最尊"规则，并在输出中说明。
- 7 座商务车 vs 中巴：7 座商务车（GL8/奥德赛）最尊位通常是中排右侧；中巴/面包车最尊位是司机正后方左侧。请根据用户实际车型选择。
- 长条桌非会议场景：商务饭局用长条桌时，远门侧为客席、近门侧为主方席。
6. 输出风格
- 语气专业、礼貌、简洁。
- 理由要引用具体原则：面门为尊、右高左低、主客分明、远门为尊。
- 座位图由云端接口渲染，保持统一的深蓝渐变风格。
