诺心蛋糕

要解决什么问题

在对话里订诺心（lecake）蛋糕，往往卡在几件事：用户自己的 user_token 不能混用；配送城市必须规范到「市」一级；地址 ID（aid）要和搜索、下单接口对齐；商品列表字段多，规格（spec_id）选错会直接串单。本技能把蛋糕叔叔 WorkBuddy 侧的一串 JSON-RPC 调用收成固定流程，让助手按步骤问人、调接口、回表格和支付链接，而不是让用户自己去拼参数。

技能如何工作

后端统一走 https://www.dangaoss.com/dsapi/workbuddy/mcp_server，协议为 JSON-RPC 2.0，业务参数放在 params.arguments 里；成功以业务层 code: 200 为准，响应是双层 JSON（外层 result.content[0].text 再解析内层 {code, data, msg}）。渠道号固定 brand_lecake，商品搜索额外带 brand_id = 101528。

典型路径可以概括为：

• 鉴权：由当前用户主动提供 token，写入本地 dgss_token.md（发布技能时需把该文件加入 .gitignore）。
• 配送上下文：读或写 default_city / default_aid；无缓存则先问城市，再 getAddrList 选地址或 addAddrList 新建（区县字段名是 area，详细地址是 addr）。
• 选品下单：仅用 brand_sweets_lst 搜诺心商品，列表按固定六列原样展示；下单前校验序号对应的 spec_id 与规格名，再调 getOrderaddr 拿 URL，从链接里抽出 scene 便于后续查单。
• 查单与快捷指令：getOrderStatus 用 scene 查状态；支持「再来一单」「换地址」「换 token」等基于 dgss_token.md / MEMORY.md 的复用逻辑。

执行层会根据环境记住 curl 或 Python 脚本方式（Windows 上中文参数易乱码，文档要求用脚本），请求超时设为 60 秒以适配慢接口。

适用边界与注意点

• 品类与渠道：只处理诺心相关蛋糕，不引导零食、鲜花，也不提供官网、小程序、门店等外链引流。
• 下单形态：一次只支持单个 spec_id；对用户回复刻意精简，接口异常统一友好话术，不向用户暴露内部接口名与原始错误栈。
• 易错字段：地址用 aid 而非 addr_id；下单返回的支付地址在 data 字符串字段，不是嵌套的 order_url。