怎样处理公关危机：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f8d77344df06.html
📄
怎样处理公关危机：把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要写“特殊情况人工处理”，而要写清例外的识别条件、判断依据和默认动作。人工经验里最值钱的部分往往不是主流程，而是“什么情况下主流程不适用”。如果脚本需求只描述正常路径，自动化一旦遇到例外就会做错，反而放大危机。是否把某类例外写进脚本，取决于它出现的频率、误判代价、以及当前有没有稳定的判断信号。
先分清三种例外，再决定保留、改写还是退出
人工处理危机时，常见的例外有三类。第一类是信号冲突：比如舆情监测显示负面提及上升，但业务数据没有变化，人工会先观望。第二类是对象特殊：涉及监管、媒体、大客户或已进入法律程序的账号，不能按普通用户话术回复。第三类是动作越界：脚本准备执行的删除、置顶、批量回复等动作，在特定情境下会激化矛盾。
对这三类，取舍条件不同。信号冲突类通常适合改写：把“发现负面就升级”改成“同一来源在短时间内重复出现，且带有具体指控关键词时才升级”。对象特殊类适合保留人工：只要命中预设标签，脚本只做归档和提醒，不自动回复。动作越界类应退出自动流程：脚本识别到争议升级迹象时，停止批量动作，转人工确认。判断标准很实际——如果误判一次的成本远高于人工处理全部例外的成本，就不要急着自动化。
描述例外时，用“条件—证据—动作”三段式
人工经验常以“感觉不对劲”存在，脚本需求必须把它翻译成可观察的条件。建议每个例外都写成三段：触发条件、需要核验的证据、默认动作。例如：
- 触发条件：同一账号在短时间内多次发布同一负面表述。
- 需要核验的证据：该账号历史互动是否正常、内容是否包含可核实的事实指控。
- 默认动作：标记为待人工复核，暂停自动回复，保留原始截图。
这样写的好处是，开发能实现判断逻辑，运营能在复核时知道看什么。反过来，如果只写“恶意攻击时人工介入”，脚本无法判断什么叫恶意，最终要么全部拦截，要么全部放行。
一个假设例子：把“先观察”写成可执行条件
假设某团队原本靠人工判断“这条负面要不要回应”。人工经验是：如果只是个别用户抱怨，先观察；如果多个渠道同时出现相似说法，就准备统一回应。写成脚本需求时可以这样描述：
当同一说法在两个以上不同渠道出现，且时间间隔在设定的观察窗口内，脚本将该说法归入“扩散中”队列，并通知负责人；如果只在一个渠道出现，脚本仅记录，不通知。这里的“两个以上渠道”和“观察窗口”都是假设参数，需要团队根据自身业务量确定，不能直接照搬。
这个动作的结果会影响下一步：进入“扩散中”队列后，人工需要判断是否统一回应；如果判断为否，应把该说法移出队列并记录原因，否则脚本会反复提醒。很多脚本需求失败，不是判断条件写错，而是缺少“人工否决后如何反馈给脚本”这一步。
变化前后要采取不同决策的条件
当关键前提发生变化时，原来的例外描述可能失效。需要重新评估的条件包括：
- 渠道结构变化：原来只在单一平台处理，现在扩展到多个渠道，原来“单渠道出现即观察”的条件可能不再适用。
- 业务阶段变化：平时可以慢处理，重大活动或敏感时期需要更快升级，观察窗口应相应缩短。
- 判断信号变化：原来靠某个关键词识别，现在该词被正常讨论大量使用，继续沿用会制造大量误报。
这些条件变化时，不要只改参数，要重新确认例外是否仍然成立。如果某个例外在新前提下几乎不会出现，可以从脚本中退出，改为纯人工处理；如果出现频率上升但判断信号稳定，可以改写为更细的条件；如果误判代价变高，应保留人工兜底而不是扩大自动范围。
验证改动时要注意比较口径
调整例外描述后，判断效果不能只看“处理量是否下降”。一次改动前后比较要考虑季节、搜索需求变化和数据采集差异。例如负面提及数量下降，可能是处理更准，也可能是这段时间本身讨论就少。更稳妥的做法是：固定观察同一类事件，比较改动前后误判次数和人工复核耗时，而不是只看总量。请求量或抓取量归零也不能单独证明处理正确，它可能只是采集链路出了问题。
最终，脚本需求里的例外描述应达到一个标准：一个不了解背景的人读完，能判断在什么条件下应该停下来找人，而不是自己猜。做到这一点，人工经验才算真正变成了可执行的规则。
