先把客服原话当成“线索”而不是“素材”:保留可复用的需求结构,抹掉能指向具体人的信息,删掉与需求无关的对话噪音。判断标准不是这句话听起来像不像选题,而是去掉隐私和无关细节后,剩下的是不是一类人共有的问题。
客服原话里通常混着三类内容。需求信号是“用户想解决什么”,比如反复询问某项操作为什么失败、某个结果为什么不一致。个体标识是姓名、联系方式、订单号、账号、单位、地址、特定日期。场景噪音是寒暄、情绪表达、与问题无关的抱怨、客服自己的口头语。
选题只取第一类,第二类必须删,第三类按是否影响理解决定去留。一个实用动作是:把原话逐句拆开,在每句后面标“需求”“标识”“噪音”。标完之后只看“需求”句,如果它们能拼成一个完整问题,就说明提炼成功;如果拼不出来,说明你删掉了必要前提,需要补回中性条件,而不是补回隐私。
当原话描述的是通用操作、通用规则或通用结果差异,且不依赖某个账号、某次订单、某个地区才能成立时,可以保留问题主干。例如“提交后提示失败,但不知道错在哪一步”这类描述,去掉具体账号和时间后仍然成立。保留时只留问题,不留原句,避免把客服的表述习惯当成用户语言。
如果需求只有在特定条件下才出现,就不能直接照搬,而要把条件抽象成可讨论的类别。比如原话是“我上周三用某张卡支付时没成功”,改写方向是“某类支付方式在特定状态下失败时,用户会卡在哪一步”。改写的前提是你能说清抽象后的条件边界,否则会变成编造一个并不存在的普遍问题。
改写后要检查两件事:一是去掉具体标识后,问题是否还能被复述;二是这个复述是否指向一个可验证的答案。两项都成立,才适合进入选题池。
当需求无法脱离具体人、具体账号、具体纠纷或具体时间而成立时,应退出选题流程。退出不等于浪费,可以把它归入“不进入公开内容”的类别,只作为内部改进线索。判断依据是:如果换一个人、换一个时间,这个问题就不存在,那它就不是可公开复用的选题。
不要只做“打码”,打码后的片段仍可能通过上下文被还原。更稳的做法是三层处理:
做完这三步后,把结果读一遍:如果还能推断出是谁、在哪、什么时候,就继续删。这个动作的结果会直接影响下一步——只有当文本不再指向任何个体时,才适合拿去做选题归类。
假设客服原话是:“张先生说他昨天用尾号1234的卡付款,页面一直转圈,他同事用另一张卡就成功了。”这里的需求信号是“付款页面一直转圈,换卡后成功”;个体标识是姓名、尾号、时间;场景噪音是“同事”这个对比。
处理方式:删掉姓名、尾号、具体时间;保留“付款页面持续加载,更换支付方式后结果不同”这一结构;把“同事”改为“另一种支付方式”。得到的选题方向是“支付页面持续加载时,更换支付方式为什么可能改变结果”。这个方向不指向任何个人,也不需要编造具体数据。下一步可以围绕这个方向去查证可公开的通用原因,而不是回到原话里找细节。
个别样本成立,不代表可以无限套用。规模化提炼时常见的例外有两类:一类是原话里的条件被过度抽象,导致问题变得无法回答;另一类是多个样本指向同一现象,但原因并不相同,强行合并会写出错误结论。
处理边界时,可以给每个选题加一行“适用前提”,写明它在什么条件下成立、在什么条件下不成立。例如“仅适用于用户能自主更换支付方式的场景”,或者“不适用于账号本身被限制的情况”。这行前提不是免责声明,而是帮助后续写作判断是否需要补充其他条件。
如果某个现象在多个样本里反复出现,但每个样本的触发条件不同,正确动作不是取交集,而是拆成多个选题,或者先记录为待验证线索。请求量、抓取量或某项统计归零,不能单独证明你的处理正确,也可能只是样本减少、渠道变化或记录方式改变。把现象和原因分开记录,才能避免把相关当成因果。
第一个问题:去掉所有个体标识后,这个问题还能被一个陌生人理解吗?第二个问题:回答它是否需要依赖某个具体人的具体信息?如果第一个是“能”,第二个是“不需要”,就可以进入写作;否则退回改写或退出。
这两个问题不保证内容一定有效,但能稳定地把隐私和无关细节挡在选题之外。真正影响下一步的,是你能否在保留需求结构的同时,让文本不再指向任何个体——做到这一点,选题才具备公开讨论的基础。