把生意参谋做成 AI 能调用的 Skill，我踩过的坑
之前做了一个小项目：把淘宝生意参谋里的数据，封装成一组 AI 可以调用的 skill。
目标很简单。
用户不用再自己打开后台、切页面、筛时间、导数据。只要问一句：
分析下牙刷类目最近怎么样？
AI 就能自己判断需要哪些数据，然后去调用对应的 skill，比如关键词分析、商品排行、商品详情，最后把结果整理成一份可读的分析。
这篇文章简单记录一下这个项目怎么做的，以及真正花时间的地方在哪里。
为什么要做这个
生意参谋的数据很有用，但对 AI 来说，它默认是拿不到的。
它不知道店铺今天卖了多少，也不知道哪个关键词最近在涨，更不知道哪些商品转化变差了、哪些活动可以报名。
这些数据都在淘宝后台里，而且没有一个能直接给 AI 调用的公开接口。
所以我做的事情不是让 AI "凭空分析"，而是先把后台数据封装成结构化能力，再让 AI 按需调用。
简单说就是：
先把生意参谋变成工具，再让 AI 去用这些工具。
我封装了哪些 Skill
目前主要做了 7 个：
- 关键词分析——查询某个关键词的相关词、修饰词、搜索趋势等。
- 商品排行——按销售额、访客、转化等维度查看店铺商品表现。
- 商品详情——查看单个商品的 SKU、流量、转化、退款等细分数据。
- 核心看板——获取店铺整体核心指标，比如成交、访客、转化、客单价等。
- 广告计划——查看直通车、万相台等推广计划的数据。
- 平台活动——查询当前可报名、适合店铺参与的官方活动。
- 登录维护——负责检测登录状态、维护浏览器会话，避免其它 skill 调用时全部失效。
每个 skill 都有自己的描述，包括它能做什么、需要什么参数、返回什么结果。
AI 运行时会根据用户的问题，自己判断要调用哪个 skill。
比如用户问：
最近店铺哪个商品值得重点推？
AI 可能会先调用核心看板，看整体趋势；再调用商品排行，找表现好的商品；最后调用商品详情，看它的转化、退款和 SKU 表现。
这样出来的结论就不是"拍脑袋分析"，而是基于真实后台数据。
真正难的不是封装接口
一开始我以为主要工作是找接口、包参数、调数据。
后来发现，接口本身反而不是最麻烦的。
真正麻烦的是：这些 skill 要稳定运行，不能每次都靠人盯着。
这里主要有几个坑。
第一个坑：登录态会过期
生意参谋是后台系统，必须有登录态。
首次登录可以扫码，但扫码之后的会话不是永久有效的。过一段时间登录态失效，所有 skill 都会跟着失效。
所以我单独做了一个登录维护层。
它会在其它 skill 请求前先检查当前会话是否有效。如果有效，就直接复用。如果失效，就走重新登录流程，尽量把状态恢复回来。
这部分看起来不起眼，但它很关键。
因为只要登录态不稳定，后面做再多 skill 都没意义。AI 调一次失败一次，整个系统就不可用。
第二个坑：滑块验证
登录过程中有时会遇到验证。
这部分很脏，也很耗时间。
不是写一段逻辑就能稳定过，而是要不断测试不同情况下的行为，尽量让流程接近真实用户操作。
这块我没有把它做成什么"高级算法"，更多是工程上的反复调试：什么时候触发、失败后怎么重试、重试几次、什么时候转人工处理。
最后我的处理思路是：能自动处理的自动处理，处理不了的尽快暴露出来，不让系统一直卡死。
第三个坑：接口签名
生意参谋后台的接口不是普通 HTTP 请求。
请求里有 cookie、签名、上下文参数，还有一些反爬相关逻辑。
如果直接逆向签名算法，短期可能能跑，但维护成本很高。平台一改，前面做的就可能全部失效。
所以我没有选择硬逆向签名。
我的做法是维护一个真实的已登录浏览器上下文，然后通过 Playwright 在这个上下文里发请求。
这样请求还是在真实登录环境里完成，cookie、页面上下文、部分动态参数都由浏览器自己处理。
这个方案的缺点是：系统会比纯接口请求重一些，需要维护浏览器会话。
但优点也很明显：稳定性更好，不需要每次平台小改动都重新逆向一遍。
对我这个场景来说，稳定比"看起来优雅"更重要。
第四个坑：原始数据不能直接给 AI
生意参谋返回的数据很大，也很乱。
如果把完整 JSON 直接丢给 AI，会有两个问题：
第一，token 消耗很高。
第二，AI 不一定能抓住重点。
所以每个 skill 后面都加了一层数据清洗。
我会把原始数据整理成更适合 AI 使用的结构，比如：
- 核心指标只保留成交、访客、转化、客单价等关键字段
- 商品排行只保留商品名、销售额、访客、支付转化率、退款等字段
- 关键词分析只保留关键词、搜索热度、变化趋势、竞争情况
- 商品详情按流量、转化、SKU、退款几个模块拆开
这样 AI 拿到的不是一大坨后台 JSON，而是已经压缩过、结构清楚的数据。
这一步很重要。
很多时候 AI 分析质量差，不是模型不行，而是你喂给它的数据太乱。
最后怎么接给 AI
整体接入用的是 OpenClaw 的 skills 动态加载。
每个 skill 都是一份独立能力，有自己的说明、参数和返回格式。
用户提出问题后，AI 会先理解问题，再决定调用哪些 skill。
比如用户问：
牙刷类目最近还能不能继续投？
AI 可能会拆成几个动作：
- 查核心看板，看店铺整体趋势
- 查商品排行，看牙刷相关商品表现
- 查关键词分析，看搜索词有没有上升
- 查广告计划，看投放 ROI 是否还能撑住
- 汇总数据，给出是否继续投、投哪些商品、避开哪些词的建议
这样 AI 就不是简单聊天，而是真的在调用业务系统里的数据做判断。
做完后的感受
这个项目做下来，我最大的感受是：
AI 接业务系统，难点不在 AI，而在数据通道。
模型本身已经很强了。
但如果它拿不到真实数据，分析就只能停留在泛泛而谈。
如果拿到的是一堆没清洗的脏数据，结果也不会好。
如果登录态、验证、接口稳定性没处理好，系统根本跑不起来。
所以真正花时间的地方不是"写 7 个 skill"，而是这些更底层的东西：
- 登录状态怎么续
- 请求怎么稳定发出去
- 验证失败怎么处理
- 原始数据怎么清洗
- 返回结构怎么设计
- AI 怎么知道什么时候该调用哪个 skill
这些处理好之后，AI 才能真正接进业务流程里。
现在这个系统还不是最终形态，但已经能完成最核心的事情：
用户说一句业务问题，AI 自动去后台拿数据，再给出一份有依据的分析。
对我来说，这比单纯做一个数据看板更有价值。
因为看板是人去找数据，AI skill 是 AI 主动帮你找数据、读数据、组织结论。
这就是我做这个项目的主要原因。