上市后市场反馈收集与分析

上市后反馈为何难处理

产品上线后，市场反馈往往分散在客服记录、应用商店评论、社交媒体讨论和销售数据中。这些信息格式不统一、来源不可控，人工整理不仅耗时，还容易遗漏关键信号。更麻烦的是，反馈的价值并不在于"收集了多少条"，而在于能否快速定位高频问题、区分偶发 bug 与系统性体验缺陷，并为下一轮迭代提供可验证的输入。

技能如何组织工作流

本技能采用授权门禁 + 受保护指令的执行模型，核心逻辑封装在 scripts/auth.py 与 scripts/protected.py 中。使用时首先执行授权检查，脚本会读取包内 _meta.json 的 slug（如 BT_E4CC2BDC）作为服务端 skillCode，并优先使用本地凭证缓存完成校验。

• 授权通过时：输出 AUTH_OK，随后通过 scripts/protected.py 拉取云端 protected instructions，严格按照返回内容执行反馈收集与分析。
• 授权未通过时：脚本输出 AUTH_REQUIRED、AUTH_INVALID 或 CREDENTIALS_* 信号，具体错误细节通过 stderr 给出。此时必须停止业务推理，调用 WorkBuddy 的 connect_cloud_service 获取 JWT，并通过 --bind-jwt 完成绑定。绑定成功后输出 AUTH_BIND_OK，需重新执行授权检查确认 AUTH_OK。

关键约束是鉴权与业务输出互斥：未拿到 protected instructions 时，不得凭本地提示或历史上下文继续生成。这意味着技能不会在授权失败时"降级"输出一份看似可用的分析报告。

使用边界与注意点

• 重试上限：CREDENTIALS_MISSING、CREDENTIALS_INVALID 或 HTTP 401/403 等鉴权类错误最多重试 1 次。两次失败应告知用户"数据服务暂时不可用"，不得继续尝试。
• 错误区分：需根据 stderr 关键字区分网络问题与鉴权问题，避免将服务端不可达误判为凭证失效。
• 密钥保护：禁止向用户展示或拼接 AppKey / AppSecret 明文，错误报告中密钥字段必须打码。
• 反馈质量：技能提供的是受控的分析工作流，反馈数据的来源质量和标签体系仍需使用者在业务侧提前规划。