客户投诉分析 Skill：把散落的抱怨，变成可执行的改进清单
很多团队不是没有客户反馈，而是反馈太多、太散、太难整理。客服聊天里有一句，差评里有一段，退款备注里又有一个原因。老板开会问“最近投诉最多的到底是什么”，大家只能凭印象回答：好像是物流、好像是包装、也可能是客服话术。这是很多团队的真实写照。
问题在于，客户投诉不是简单摘要。它背后通常连着商品质量、页面承诺、仓储发货、客服响应、售后规则和运营策略。只靠人工复制粘贴，最后很容易变成一份“情绪汇总”，看着热闹，却不知道谁要改、什么时候改、怎么验收。
客户投诉分析 Skill 要解决的，就是把散落反馈变成结构化复盘：先归类，再判断风险，再找根因，最后输出可以分派的行动清单。告别模糊的“凭感觉”决策，让每一次投诉都驱动产品与服务的真实提升。
场景痛点：从“情绪汇总”到“可执行清单”
先看两个场景，感受一下这个Skill的实战效果。
案例一：电商团队每周售后复盘
没有 Skill 时：运营同事从平台后台导出差评、退款原因和客服聊天，手工合并到表格。最后只能写出“物流慢、包装破损、客服回复不及时”这类结论。会议上大家继续争论：是仓库问题，还是快递问题，还是页面承诺写得太满？但真正落地的整改动作呢？往往拖到下周。
使用 Skill 后：Agent 会按模板输出“投诉主题、样本证据、影响模块、风险等级、根因判断、行动项”。举个例子，物流延迟 34 条，集中在华东仓发货后 48 小时无轨迹；风险等级为高；影响模块为履约体验和退款时效；建议动作是新增异常包裹日报、页面补充偏远地区时效说明、客服话术增加主动解释节点；复核事项是核对近 7 天快递揽收时间和承诺送达时间是否冲突。你看，每个动作都有明确指向。
案例二：SaaS 或小程序团队整理用户吐槽
没有 Skill 时：产品经理翻着群聊、工单和用户反馈表，容易把所有问题都写成“用户觉得不好用”。研发侧不知道是 Bug、需求、体验问题还是使用门槛；客服侧也不知道该优先解释哪类问题。
使用 Skill 后：Agent 会把反馈拆成“功能缺陷、体验卡点、文案误解、价格疑问、账号权限、数据异常”等类别，并输出优先级。比如，数据导入失败 18 条，其中 11 条来自表头字段不一致；风险等级为中；产品动作是增加导入前预检；客服动作是补充一键示例表；技术动作是把错误提示从“导入失败”改成具体字段缺失；运营动作是更新帮助文档和新手指引。每个方向的改什么、谁来改，一目了然。
Skill 核心机制：固定口径，稳定输出
这个Skill不是一个简单的提示词，而是一套完整的处理框架。它的核心在 SKILL.md 里。里面会明确告诉 Agent：先识别输入来源，再把原始内容统一成字段，然后按投诉分类表归类，最后按固定报告模板输出。这样做的好处是，每次处理材料时不会临场发挥。
渐进式加载的思路也很重要。Agent 不需要一开始读完所有资料，而是先读取 SKILL.md 里的任务边界；当需要判断投诉类别时，再加载 references/category_taxonomy.md；当需要输出报告时，再调用 templates/complaint_report_template.md；如果遇到表格材料，再参考 scripts 里的字段清洗逻辑。这种设计避免了信息过载，也让协同工作变得高效。
普通提示词的问题是：你说“帮我分析投诉”，模型可能今天按情绪分类，明天按业务模块分类，后天又只给你一段摘要。Skill 则把“分类口径、风险标准、输出格式、复核提醒”固定下来，让 Agent 更像一个稳定执行的工作流。
它的工作流可以拆成五步：收集材料、去重合并、投诉归类、风险分级、生成行动清单。每一步都要求保留证据句，避免把用户原话过度概括。真正的价值不是替代人工判断，而是把“第一轮梳理”做得更稳定、更完整。
使用方式：适配主流平台，低门槛调用
这个Skill可以灵活应用于不同的Agent平台。
在 ChatGPT 中，可以把 Skill 包和投诉材料一起上传，然后说明本次要输出日报、周报还是专项复盘。适合小团队快速做一次投诉整理。
在 Claude 中，可以把 SKILL.md、模板和原始表格放入项目知识或会话附件，再让 Claude 按 Skill 规则输出报告。适合长文本聊天记录和大量用户反馈。
在 Hermes 中，可以把 Skill 作为任务目录，让 Agent 读取输入文件、执行分类、生成报告，并把中间结果保存下来。适合周期性投诉复盘。
在 OpenClaw 中，可以把它作为一个可复用 Skill，配合固定输入目录和输出目录，让客服或运营同事用更低门槛的方式调用。
使用时不需要写复杂提示，只要说清楚三件事：材料来自哪里、希望按什么业务口径分析、最终要给谁看。
避坑指南：让投诉分析真正落地
经验教训告诉我们，做好投诉分析，需要避开几个坑。
