

























Connector项目通过Sync Doctor功能彻底改变了用户处理同步报错的体验。面对TikTok与Shopify对接中晦涩的技术错误码,产品团队用AI翻译成可执行解决方案,不仅让客服工单骤降60%,更实现了35%的用户自主修复率。本文将揭秘这套诊断系统如何从Prompt设计到交互形态,重构SaaS工具的异常处理逻辑。

connector项目值得关注的两个数据:一是同步失败率,二是客服工单量。这两者往往呈正相关——用户看到“Error Code: 30045, Msg: Invalid params”时,第一反应是截图发给客服,第二反应是“这工具真难用”。
直到我们上线了同步异常智能诊断(Sync Doctor),情况才发生改变。客服工单下降了60%,用户自主修复率提升了30%,得到了用户的一致好评。
Connector的核心场景很简单:把Shopify的商品同步到TikTok,把TikTok的订单同步回Shopify。但简单场景背后,是复杂的API对接和层出不穷的报错。
翻看客服聊天记录,我们发现一个规律:80%的工单是因为用户看不懂报错。
比如TikTok API返回:
{ “code”: 40012, “message”: “attribute value is invalid. material must be one of [Cotton, Polyester, Silk]”}
用户看到的是一串英文,而实际问题是:商品的材质属性写了“100% Good Cotton”,但TikTok只接受固定的枚举值“Cotton”。用户需要知道:①哪个字段错了;②正确的值是什么;③去哪里修改。
当时我们的系统只是原样透传这个错误,用户只能复制错误码去搜文档,或者找客服。客服再找到开发查错误日志,来回至少两小时。
这不是用户的问题,是我们的产品没把报错翻译成人话。
我们给这个功能定了三个核心指标:
要实现这些,诊断助手必须做到三件事:
我们不想做一个单独的“AI问答框”,而是希望诊断能力无缝融入现有流程。
在“同步日志”列表页,每条失败记录后面加了一个AI Diagnose按钮。用户点击后,弹窗显示诊断报告。
弹窗分三块:
一键修复:如果问题属于文本映射类(比如属性值标准化),直接显示“AI一键修复”按钮,点击后系统自动修正并重试
我们还参考了另外两种AI交互形态,未来可以扩展:
但诊断助手我们选择“触发式弹窗”,因为用户只有在遇到失败时才需要,平时不打扰。
和技术同学对齐可行性和成本后,我们评估了几种方案:
我们选了LLM方案。技术架构如下:

以下是精简后的系统提示词:
You are a Sync Doctor for a Shopify-TikTok connector.
Analyze the error log and product data. Return a valid JSON with:
-human_reason: clear explanation in user’s language
-solution_steps: list of actionable steps
-auto_fix_available: boolean
-auto_fix_suggestion: if auto_fix_available, the corrected value
Error Log: {error_json}
Product Data: {product_json}
为了验证想法,我搭了一个极简Demo:
核心代码片段:
@app.post(“/api/diagnose”) async def diagnose(task_id: int): task = get_task_by_id(task_id) prompt = build_prompt(task.error_log, task.product_data) response = openai.ChatCompletion.create( model=”gpt-3.5-turbo”, messages=[ {“role”: “system”, “content”: SYSTEM_PROMPT}, {“role”: “user”, “content”: prompt} ], temperature=0.3 ) result = json.loads(response.choices[0].message.content) return result
下面是我结合AI开发的一个demo:


上线三个月后,我们复盘数据:
更重要的是,用户的抱怨变成了认可。
几点反思:
同步诊断助手只是第一步。我们正在把这种能力扩展到更多场景:
本文由 @产品小葵 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。