企业集采

要解决什么问题

在企业福利或行政集采场景里，常需要在蛋糕叔叔侧完成选品、选地址并拿到可支付的下单链接。接口走 JSON-RPC 2.0，成功码是 code: 200，业务数据还套在 result.content[0].text 里再解析一层；Windows 下直接用 curl 传中文参数容易乱码，地址字段名也容易写错（区县用 area、详细地址用 addr、搜索与下单用 aid）。本技能把「授权 → 配送 → 搜索 → 下单 → 查单」收成可重复执行的对话流程。

技能如何工作

• 授权与记忆：user_token 必须由当前用户提供，写入本地 dgss_token.md（发布时需加入 .gitignore）。可缓存 default_city、default_aid 以及最近一次订单的 scene、商品与规格，支持「再来一单」、带默认地址直接搜商品。
• 配送前置：城市规范到「市」一级；调用 getAddrList / addAddrList 选定或新增地址，得到 aid 后再搜索。
• 分类与搜索：cat_id 对应蛋糕(1)、零食(5)、鲜花(8)；关键词模糊时先让用户选类，再调 sweets_lst，列表按固定六列原样展示接口字段。
• 下单与查单：生成链接前校验 spec_id 与规格名称一致；getOrderaddr 返回的 data 即为下单 URL。查单优先用 last_order_scene，或识别用户发来的纯数字 scene，走 getOrderStatus。
• 调用方式：首次在 curl / Python / cmd 包裹 Python 间试探成功后，记入 MEMORY.md 的 dgss_exec_method，后续固定复用。

适用边界与注意点

• 仅支持单个 spec_id 下单，不支持多规格叠加；未开通城市、规格下架、区域不可配送等按错误码映射为简短用户话术，不向用户暴露接口名与域名。
• 对话侧遵守精简规则：只呈现当前结果与下一步动作，预设文案一字不差；退款、物流、发票、积分等超纲需求用固定幽默话术回应，不引导去站外自行操作。
• 请求超时按 60 秒 配置，接口偏慢时需有心理预期。