用拒收日志定位 LLM 工作流故障

上一篇文章介绍了决策日志：我的 n8n 审核队列中，每个被拒绝的 LLM 输出都会打上一个标签——prompt、fixture、model 或 data——然后每周统计一次。这周，我真正坐下来，仔细看了三周的统计结果。呈现出的规律兑现了 SOP 的承诺：把模糊的感觉变成了具体的工单。下面就是统计结果告诉我的事，以及我采取的行动。

统计结果是什么样的

三周的审核队列，共有 31 个被拒绝的输出，每个输出只打一个标签：

Prompt：55%。Fixture：23%。Model：16%。Data：6%。

SOP 规定，某个标签的占比超过 50%，问题就出在那里。现在，结果已经摆在眼前：超过一半的拒绝案例，原因是我自己的 prompt，而不是模型，也不是数据。“这周模型变笨了”——这句 LLM 运维中代价最高的话——连续三周都说错了。

解读 prompt 集群：是漂移，不是设计问题

17 个 prompt 标签，并不意味着 prompt 写得差，而是意味着 prompt 发生了漂移。判断依据是：W1 的 prompt 拒绝案例，大多是在抱怨措辞，比如层层叠加的保留措辞，以及千篇一律的“In summary”；到了 W3，大多变成了范围问题：回答在技术上是正确的，却回答了一个相近但不同的问题。失败类型不同，标签相同，中间只隔了一周。这就是漂移：工作流的输入变了，比如新增了一个来源字段，或工单格式略有变化，而 prompt 没有跟着调整。

对应的工单是：每次提升版本号之前，都固定检查一次 prompt diff。SOP 原本就要求在每次版本升级前跑一遍审核队列；现在，它还会展示自上次统计以来 prompt 的 diff，我会像做 code review 一样审查它。W3 的 7 个 prompt 标签中，有 2 个问题本可以通过阅读我自己的 diff 提前发现：我加了一个新字段，却没有更新使用该字段的指令。

解读 fixture 集群：W2 的问题 fixture

W2 很有意思：fixture 标签在一周内从 2 个增加到 4 个，而且这 4 个都指向同一个 fixture——回归测试套件中的“愤怒客户”工单样本。质量关卡的升级处理路径开始把一些真实输出转交给人工审核，但这些输出完全不像生产环境中的失败案例，反而和那个 fixture 一模一样。

对应的工单是：我用一张真实工单重建了这个 fixture，重新跑了一遍测试套件，误触发的升级处理就停止了。fixture 集群的诊断成本很低，修复成本更低——前提是你给它们打了标签。没有标签，“质量关卡太敏感了”就会变成一个下午的配置调参。有了标签，事情就变成了花 20 分钟重建 fixture。

model 标签：在形成规律之前，都只是噪声

三周里共有 5 个 model 标签，分散在不同的 prompt、fixture 和日期中。没有规律，也没有集群。面对零散的 model 标签，正确的应对方式就是：什么都不做。观察趋势，不要对单个数据点作出反应。

我把这条规则写在了墙上：model 标签连续两周增长，才算模型问题；只增长一周，就当是天气变化。因为某一周表现不好就调整 temperature 或切换模型，相当于拿一个已知系统换成一个未知系统。统计的意义，就是在数据提供足够依据之前，让我别去碰模型的调节旋钮。

统计让流程发生了什么变化

只改了一处流程，而且刻意保持很小：

周一，15 分钟。每周一早上，在一周的工作开始之前，复盘统计结果。最多开一张工单：给最大的集群安排一个具体修复，其他问题继续留在日志里。这个限制很重要：没有工单数量上限的统计表，最后会变成一张让人内疚的电子表格。

就这些。没有新增 dashboard，也没有新增脚本。前两篇文章中的脚本负责机械层面的约定；10 分钟的 SOP 负责文字说明；每周统计负责判断该把问题归因到哪里。三个层次，每层都只有一个明确的职责。

本系列下一篇：统计结果表明，我的 prompt 每三周就会发生一次漂移。所以，我正在编写能阻止这种漂移的东西——一个 prompt 契约测试，当 prompt 与它的 fixture 不一致时，就让构建失败。审核队列一直在教脚本该怎么做。

我正在构建 AI Automation Lab——一套用于 AI 自动化的 n8n 工作流模板——同时在 GitHub 上维护一个免费的实验室。我也会不定期发送关于 n8n 可靠性模式的笔记：可以在这里订阅。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。