Kutesmart C 站上下文解析

要解决的问题

海外运营场景里，C 站的商品浏览、下单等后续接口都依赖一组上下文：站点 URL、所属用户 userId、来源标识 originSign/source，以及支付侧信息。问题在于这些信息散落在不同查询接口中，入口也不统一——有时你只有一个域名，有时只拿到一个 docking token，有时手里只有 B 账号的 bid。手工拼装容易漏字段、串站点，尤其当同一用户名下有多套站点配置时。

核心能力

技能把 https://www.kutetailor.com/api/fabric 下的查询接口整理成一组可按场景选择的 action：

• public_website_info：用域名或 URL 查公开建站信息，不需要 token。
• get_user_id_by_url / get_user_id：把 URL 映射到站点所属用户。
• csite_docking / csite_payment：按 userId 查 C 站链接与支付信息。
• docking_by_token / docking_by_user：分别用 docking token 或 userId 取链接配置。
• website_by_bid：按 B 账号 bid 反查网站信息。

请求约定固定：最外层只放 params；公开接口可不带 token；内部配置接口建议带 Authorization。

典型流程

1. 输入是域名或 URL：先 public_website_info，再 get_user_id_by_url，拿到 userId 后继续查站点链接。
2. 输入是 docking token：直接走 docking_by_token。
3. 需要支付展示：调 csite_payment，只取可用字段，不外传密钥。
4. 把解析出的 userId、站点 URL 和 originSign/source 交给商品浏览与详情 skill 复用。

边界与注意点

技能只做查询上下文，不执行任何写配置类接口，也不保存或修改建站配置、支付配置、模板与字体。返回中若包含支付密钥、API token 或其他敏感配置，默认只展示脱敏值。无法解析站点时，应明确说明缺少 URL、token 还是 userId，不要凭空补一个站点上下文。