我如何设计能携带上下文并处理失败的 AI 生成阶段

创始人不应被迫去整合这些答案

我围绕“了解产品但仍需决定如何推广”的创始人来设计 Launcherry 的产品工作流。定位塑造受众，受众塑造信息，渠道塑造交付物。如果各个 AI 输出忽略了这些依赖关系，创始人就必须自行调和这些答案。这种整合工作正是我希望通过工作流来解决的问题。

Launcherry 通过将商业上下文从产品 URL 或简介带入营销分析和活动筹备中来解决这一问题。我设计了其 AI 工作流编排，使其围绕具有明确输入、输出和检查机制的关联阶段展开。目标是生成一个创始人可以审查的活动方案，且早期工作的推理过程和约束条件仍能对其产生影响。

本项目包含两个工作流。一个在 Launcherry 内部生成产品输出；另一个指导围绕构建过程的 AI 实施。本文关注的是产品工作流；开发工具包则描述了我如何组织修改它的工作。

区分商业事实与生成的建议

我从 URL 或简介开始产品工作流。该输入为工作流提供了需要推理的商业实体。同时也引入了一个边界：关于企业的已提供或检索信息与关于创始人下一步该做什么的 AI 建议具有不同的地位。

我将这种区分视为一种架构要求。活动筹备需要有关产品的相关事实，而分析则可以提出定位、受众或渠道建议。一篇有说服力的草稿不能确立其自身主张的真实性。事实依据应归属于生成草稿的工作流及其周围的检查机制中。

考虑一个通用示例：分析建议以服务的快速周转作为卖点。该建议并不能确立具体的交付保证。后续的文案需要为其做出的任何承诺提供支持。这是一个说明性的决策边界，而非针对特定 Launcherry 客户或活动的声明。

我在每次交接时提出的问题都是：下一阶段有权将什么视为已知。这使得研究与写作之间的关系更加明确，并为审查提供了识别无支持添加内容的依据。

赋予每个生成阶段特定的职责

在当前开发实现中，生成是分阶段的，包括事实 grounding（基础支撑）和有界修复。商业分析指导活动筹备；渠道需求塑造交付物；检查机制决定输出是否可以继续。每个阶段的存在是因为它有特定的任务要完成。

我利用这些阶段职责来定位故障。一个活动方案可能存在角度薄弱、写作不当或资产方向不完整等问题。将整个输出视为一个未加区分的整体答案，会使得理解何处需要更改指导或实施变得更加困难。清晰的阶段职责使调查更加聚焦。

渠道技能库符合这一结构。其指导涵盖规划、写作和资产，并在各渠道间共享标准。这些阶段在生成过程中消耗相关的专业知识。特定于渠道的材料与工作相连接，而不是作为文档留在一旁。

我并不假设增加阶段就能改善工作流。每次交接都增加了上下文漂移的可能位置，每次模型调用都会增加运营成本和时间等待。一个阶段需要通过其独特的职责以及关于结果的事实证据来证明其存在的合理性。

在设计成功路径的同时设计失败路径

当输出未能满足要求时，工作流也需要相应的响应。Launcherry 的生成实现包括检查机制和有界修复。其目的是在受控过程中纠正特定的失败，同时保持产品要求的完整性。

广告文案的长度提供了一个有用的示例。我拒绝了为了迎合平台限制而截断生成文本的做法，因为这可能会将一个完整的思想变成技术上可接受的碎片。我将修改重点放在生成和验证环节，使工作流能够在保留要求的同时处理过长的文案。

我从约束条件和含义两个维度来评估修复效果。一个更短但丢失了有用信息的回复并没有解决产品问题；一个辞藻华丽但仍超出字段限制的回复同样没有解决问题。接受决策需要关于这两方面的证据。

对于另一个产品，我会尽早确立停止条件：哪些故障可以被修复、结果将如何评估，以及当修复无法产生可接受的输出时会发生什么。这是一项设计建议。具体的实施路径必须契合产品的风险以及其实现所能支持的行为。

让创始人做出关键决策

已实现的 Launcherry 流程连接了产品输入、分析、活动审查和导出。审批通过使活动准备好进行导出。下载和支持的平台交付仍然是独立的选择，Launcherry 无法自动激活付费媒体。

我为生成工作流设定了明确的目标：为创始人评估做准备。成功的模型响应并不授权交付。即使活动通过了技术检查，仍需决定其信息、受众和意图是否适合该业务。

我还考虑了可用性条件。代码中的交付模块并不能保证每位创始人都能使用该提供商。界面和服务器条件决定了哪些选项是可用的。我在设计交付前的人工审批时，解释了用户旅程及这些区别。

衡量完整的工作流并保留证据的范围

我根据产品要求评估生成的输出，使用回归覆盖率和真实模型评估。生产成本、延迟和缓存需要单独的观察指标。评估桥可以在不复制生产提供商的经济状况或时间成本的情况下，支持对真实生成管道的迭代。

对于这个项目，新技能和流程改进继续在本地开发中进行。公开产品和当前的本地实现是相关的，但它们不是可互换的证据。在描述工作流和决定何时发布时，我保留了这一区别。

我对 AI 工作流架构的实践起点是一个单一的用户结果。追踪它所需的信息、涉及的转换、交接处的检查以及允许行动的决策。这赋予了架构超越连接工具的目的。Launcherry 的案例研究展示了我是如何将这种方法带入到一个实际产品中的。

最初发表于 ivanped.ai：AI 工作流编排：从分析到活动。更多我的作品：ivanped.ai