用户声音分析的起点是一份可追溯的样本，而不是一张由模型生成的“十大痛点”。同一个人可能在工单、应用商店和社交平台重复描述一件事；一星评价也可能包含值得保留的优点。本专题用虚构的便携咖啡壶案例，把采集、主题复核和需求排序连成一条能交给产品、运营与售后共同评审的流程。所有数字用于演示，不代表真实客户调查，也不证明差评导致销量变化。
先限定问题、样本与交付物
团队的问题是“为什么首次使用后有人退货”，不是“证明清洗太麻烦”。先确定产品型号、销售地区、固件或批次、观察窗口及纳入渠道，分别记录自家评价、竞品评价、客服工单与问卷开放题。竞品样本用来发现待验证的需求，不能直接算进自家故障比例。
建立三份文件：保留来源的原始表、可修订的编码表、面向评审的机会清单。原始表至少包含 record_id、channel、source_id、collected_at、event_date、product_version、rating、language、text、source_locator 与 acquisition_method。没有评分的工单留空，不能填成零星；没有发生日期的评论保留未知，避免把抓取时间当成故障时间。
交付前约定计数口径：按评论条数、独立反馈事件还是可确认的用户计数。匿名渠道无法可靠跨平台识别人时，只报告可观察的事件数和覆盖限制，不推算精确人数。模型产生的类别、推断和优先级放在派生表，不覆盖原话。
场景一：把多个渠道收进同一张可核对的表
优先使用平台允许的导出、团队有权访问的工单下载和明确许可的接口。公开网页也要检查使用条件、采集范围与频率。遇到登录、分页、动态加载或访问限制，先确认正常授权及完整性；缺权限就记录缺口，改用人工导出，不把绕过限制当成采集技巧。
先抽取一个小批次，逐条核对来源、日期、原文和分页边界，再扩大范围。保存每个渠道的请求条件、预期条数与实际条数。导出有三十条而界面显示五十条时，先排查过滤条件、已归档内容和时间范围，不让后续聚类掩盖遗漏。新增批次用稳定 source_id 去重；文本相同但来源不同先标记疑似重复，保留审计依据。
例如工单 T-17 与评价 R-08 都写“盖子关不紧”。如果只有相似文字，没有可信关联证据，不能认定是同一个人。记录 duplicate_candidate，而不是立即删除其中一条。若有经授权保留的同一事件编号，则建立合并关系，并保留两个来源指针。删除电话、邮箱、订单明细等分析不需要的字段后，再把副本交给外部模型。
这一阶段的产物是 ingestion-log 和清洁语料副本。检查总行数、空文本、异常日期、缺失来源、编码损坏及各渠道占比。Exploratory Data Analysis 可用于本步分析明确指定的本地 CSV、TSV 或 JSON 的缺失值和分布。它需要可运行的 Python 环境及相应依赖；只给脱敏文件和输出目录。它不是评论抓取器，也不提供跨平台用户身份识别。
场景二：把情绪、故障与原因分开编码
先从不同渠道、评分和语言各取样建立小型编码手册。为每类写定义、纳入条件、排除条件和代表句。例如“清洁负担”指拆洗步骤、残留或耗时；“密封异常”指按说明装配后仍漏水；“配送损伤”单独编码。每条可以多标签，情绪倾向与问题类型分别记录，另设 unknown 与 needs_review，允许模型承认没有足够信息。
“味道不错，但拆洗很费劲”应保留正向体验和清洁负担两个维度。“根本没法用”如果没有细节，不能擅自归为电池故障。中文反话、表情、英文口语和混合语言要人工复核，不套用一个没有本批数据支持的固定误判率。翻译只作辅助，原话与译文并列，防止把“难装回”误写成“损坏”。
模型先提出主题与证据编号，人再看代表例、反例和边界样本。请两位评审独立编码一部分相同记录，记录分歧及裁决原因；只记录一致率还不够，还要检查是否都把困难样本放进“其他”。修改手册后给新版本号，对受影响的旧记录重跑或重审，防止同一主题在不同批次含义漂移。
主题不等于根因。漏水可能来自零件公差、安装步骤、配送损伤或说明不清。建立 hypothesis、supporting_ids、contradicting_ids、next_check 四列，安排复现实验或售后回访。没有复现前写“疑似与装配有关”，不写“已证实设计缺陷”。输出主题卡要同时给样本覆盖、原话、未知项与验证负责人。
实操：从一句投诉走到可以验证的改进
假设脱敏后的六十个独立反馈事件中，十八个提到清洁，七个提到漏水，其中三个同时提到两者。这些是虚构的已复核事件数，两类不能相加后宣称二十五位不同用户，更不能用十八除以全部订单数当投诉发生率，因为当前表只收集了主动反馈。
针对清洁主题，先提出两个候选动作：改写拆洗说明，或调整滤网结构。让售后按现有说明完成一次拆装，记录在哪一步需要额外解释；让产品团队用相同条件比较旧说明与改写版。若主要问题是步骤顺序不明，先做小范围说明试验；若残留在正常清洗后仍反复出现，保留结构改造假设。一次改动只改变清晰指定的变量，记录参与条件和失败情况。
给 Agent 的任务可写成：“仅使用 feedback-clean.csv 与 codebook-v1。为每条建议零到多个主题并给 record_id；不要推断人口属性。输出待复核列表、主题计数与证据表。单独列出无法解释的评论和与主结论相反的例子。不得联系客户、修改工单或发布回复。”先接受十条试编码，再处理剩余数据，能更早发现格式和口径错误。
场景三：按影响和证据排序，再交给需求评审
机会清单每项包含问题陈述、适用群体、受影响事件、严重程度、证据强弱、业务相关性、实现成本与下一步验证。把观察和判断分栏：十八个事件是观察；“会降低复购”是待验证判断；“先改说明”是决策。少量严重问题可以优先调查，不能让提及次数淹没潜在的安全问题。
如果使用分数，公开各维度定义和权重，缺值标为未知，不给模型自由补满。分别试算偏重严重程度和偏重覆盖范围的两套权重；排名一变就说明决策敏感，需要更多证据。工程估时由了解系统的人给范围，不能因为模型写了精确数字就当成承诺。看板上保留暂缓项及原因，避免只有支持既定路线的反馈被留下。
把选中的机会转成一页需求卡：背景、可追溯证据、目标、非目标、用户步骤、异常情况、可验收结果、负责人和回访日期。例如说明优化应让读者在指定测试条件下完成正确拆洗，明确观察方法、失败定义及目标门槛由团队在试验前商定。不要用“用户更满意”代替验收，也不要把相关性写成销售增长保证。最终交付包括编码表版本、机会清单及评审决定，方便下次追踪是否真的解决了问题。
选择 Skill 与开源标注方式
本流程只关联已经能核验用途的数据质量技能，不把原文列出的六个名称直接换成未经核实的安装链接。若以后找到抓取、主题编码或需求排序候选，分别检查来源仓库、版本、许可证、依赖、访问权限与输出示例，再用同一份脱敏样本试跑；通过后才补到对应步骤。安装成功、被 Agent 发现、按方法执行和结果验收是四件事，均需各自证据。
GitHub 上的 Argilla 提供人工标注与协作数据集能力，Apache-2.0 许可，可作为多人复核的参考。其仓库已说明以稳定维护和修复为主，选择前要考虑维护模式、部署及权限成本。小团队先用带版本的表格即可，不必为了分析几十条评论新建服务。这里参考其人工反馈工作方式，没有安装、部署或宣称它已经是 SkillPI 中可安装的技能。
故障排查与 FAQ
为什么每次得到的主题不同？先固定样本、手册、提示和模型版本，比较变动记录；语义相近的类别合并须有人复核并保留映射。为什么某渠道问题特别多？先检查渠道样本量、主动反馈偏差、活动期间和产品版本，不能直接比较原始条数。
数据很少能做吗？可以做质性问题清单与后续访谈问题，但不要输出市场发生率或稳定排名。只有差评能判断整体满意度吗？不能，补充中性与正向反馈、主动询问样本及产品使用数据，并分别说明来源限制。
电商运营也适用吗？可以把已核实主题用于说明页、包装指引与售后培训；竞品吐槽只形成验证方向，不冒充自家客户证据。是否保证免费或数据不离开本地？不保证，技能许可、模型调用、平台接口和部署各有条件；执行前检查实际工具与传输路径。更新后如何保鲜？定期用固定小样本复核关联 Skill 的来源和能力，同时抽查新版本产品反馈，撤下失效链接并记录变更原因。