当营销中的 AI 工作流失败：实际发生了什么

我要告诉你 Prova 的冲刺审核系统以一种具体而令人尴尬的方式崩溃的经历，因为我认为这比抽象的失败模式列表更有用。

Prova 的冲刺审核是程序运作方式的核心。学习者提交成果物——工作流规范、可运行的原型——AI 审核员根据该冲刺的标准对其进行评估。审核员提供结构化反馈。学习者修改或通过。这就是"我读过这个"和"我构建了被评估的东西"之间的区别。

早期版本中发生的事情是：AI 审核员收到的关于用户当前所在冲刺的上下文不一致。系统正在将冲刺信息传递到审核提示词中，但数据有时是过时的——来自上一个会话的缓存值，或者用户在没有正确更新状态的情况下在冲刺之间导航的会话。

结果是审核员有时会拿错误 sprint 的标准来评估提交内容。提交 Sprint 3 作品的用户，会收到按 Sprint 1 校准的反馈——那里的标准更简单，预期成果物也更初级。反馈听起来很有把握，也前后一致。问题是，它在评估错误的东西。

用户收到了矛盾的信号。一些人在应该需要更多工作的提交上轻松通过了。一些人收到了指出另一个冲刺的缺失元素的反馈。最糟糕的是，反馈在两种情况下听起来都很权威。

我没有立即发现它，因为审核没有明显破损——它们是微妙地出错了。语言流畅。结构正确。被应用的标准只是属于不同冲刺的。

真正是什么原因导致的

不是模型。是上下文。

AI 审核员只能看到调用时传进提示词里的 sprint 信息。当这些信息不正确——过时、路由错误，或被会话 bug 覆盖——审核员就只能按手上的信息工作。它没法知道上下文错了，因为提示词里没有要求它把 sprint ID 和用户当前状态核对。

系统信任输入而不验证它。输入有时是错误的。输出总是以与输入相同的方向自信地出错。

这是营销中 AI 工作流失败最常见的方式，不仅仅是我构建的东西：不一致的输入数据流入听起来自信的 AI 输出，中间没有审核。

为什么解决方案不是更好的模型

当这种失败发生时，直觉是看向 AI。也许模型不够聪明。也许不同的工具会发现它。

它不会。模型无法验证它没有被给予的上下文。更有能力的模型会产生更流畅的错误答案，实际上更难发现。

真正的解决方案在工作流设计中：这个提示词的每次调用需要什么上下文，以及你如何确保该上下文始终是最新和正确的？

在 Prova，解决方案是在每个审核提示词的开头添加一个结构化的上下文块，明确包含冲刺 ID、当前标准集和用户针对该冲刺的以前提交历史。不从缓存获取。在调用时新鲜获取。提示词还包括一条明确的指令："如果冲刺 ID 或标准集丢失或被标记为未知，不要继续审核——返回请求正确上下文的错误。"

最后那行很重要。它给了审核员处理不确定输入的明确行为，而不是默认基于错误数据给出自信的输出。

一般模式

按顺序，导致营销中 AI 工作流失败的四件事：

1. 输入不一致。 工作流在不同时间收到不同的数据结构，提示词无法处理变化。模型用它收到的东西尽力而为。
2. 发布前没有输出审核。 有人自动化了生成步骤但没有自动化审核步骤。输出在没有人工阅读的情况下到达客户、领导报告或已发布页面。
3. 提示词漂移。 原始提示词对它设计的用例有效。六个月后，输入略有变化，用例演变，但提示词没有变化。它仍在运行。它不再根据它接收到的内容进行校准。
4. 没有失败文档。 出了什么问题，它被悄悄修复了。团队不记录发生了什么、原因是什么或修复是什么。三个月后，另一个人将相同的错误构建到不同的工作流中。

如何构建有效的审核检查点

审核检查点不是让人工阅读每个输出——那会破坏自动化的目的。它是一套明确的决策规则：哪些输出需要审核，以及某个环节失败时应该发生什么。

对于任何产生触达客户或领导层输出的 AI 工作流，定义：可疑输出是什么样的？什么触发人工审核？如果审核失败，后备方案是什么？这些答案在系统上线之前属于工作流设计文档。

根据我的经验，检查点被触发的次数大约是实际问题次数的两倍。大多数时候，输出没问题。但检查点的存在，才让团队愿意信任这个 workflow——因为他们知道失败模式已经被处理。

这对构建意味着什么

AI 构建者的现实检验 文章涵盖了开始构建时比看起来更难的事情的更广泛模式。本文是关于一个特定机制的：不一致的输入数据流入听起来自信的 AI 输出，它们之间没有审核。

写这篇文章的不适感就是重点。我构建了它。它以我应该更早设计规避的具体且可预测的方式崩溃了。来自具体失败的教训比来自假设性警告的更可信。

当你为营销设计第一个 AI 工作流时，审核检查点不是可选的。从一开始就把它内置进去。无论收到什么，模型都会产生自信的输出。检查点是系统中唯一知道差异的部分。

Cheers, Chandler