怎么处理一次误发事故How to Handle a Misfire Incident

第一步是止血不是分析：撤回或更正已发内容、关掉触发入口、列出已扩散范围，分析放到第二步。

定影响范围要有依据：时间窗、受影响的用户或文件清单、有没有对外发布。列不出清单就写「范围未知」，不要估一个数顶上去。

留证据：原始输入、模型与提示版本、完整输出、当时的调用日志，按事件编号存档；后面所有判断都靠这几样。

分层归因：是模型输出错、检索到的材料错、指令本身有歧义，还是流程里没有复核点——同一种现象对应四种不同修法，别默认是模型的问题。

复盘要落到「改哪一条控制」：新增复核点、收紧权限、把该场景写进边界说明或样本集，每条带负责人和验证方式，而不是写「以后注意」。

举个例子（虚构情境）：输入是自动回复机器人给客户发出的含错误退款期限的邮件 → 处理是按事件流程先关闭该自动回复通道、再清点同时间窗的发送日志 → 结果判断是把模型输出与现行退款条款逐条比对，确认错误来自检索命中了一份过期政策文档 → 下一步是把政策文档版本纳入发布检查、在出口加一道期限字段核对，并记下验证方式。

Step one is containment, not analysis: retract or correct what went out, close the triggering entry point, list what has spread. Analysis comes second.

Scope must rest on evidence: time window, list of affected users or files, whether anything was published externally. If you cannot produce a list, write "scope unknown" instead of estimating a number.

Preserve evidence: original input, model and prompt versions, full output, the call logs of that moment, filed under an incident ID. Every later judgement depends on these.

Attribute by layer: model output wrong, retrieved material wrong, the instruction itself ambiguous, or no review step in the process - the same symptom has four different fixes, so do not assume it is the model.

The review must land on "which control changes": add a review point, tighten permissions, write the scenario into the boundary notes or the sample set - each with an owner and a verification method, not "be more careful".

Worked example (fictional scenario): input is an automated reply that sent a customer the wrong refund deadline -> processing closes the automated-reply channel first, then counts the send log for the same window -> the check compares the output against current refund terms and finds the retrieval hit an outdated policy document -> next step: put policy document versions into the release check, add a deadline-field validation at the exit, and record how you will verify it.