IT2026年8月18日

我们的 AI 内容流水线现由 GPT-6 Sol 驱动——生成的图片比过去更少

作者：Andrea Borghi
我们的 AI 内容流水线现由 GPT-6 Sol 驱动——生成的图片比过去更少

我们的 AI 内容流水线现由 GPT-6 Sol 驱动——生成的图片比过去更少

更新于 2026 年 9 月 24 日：本文最初介绍的是运行在 GPT-5.6 上的流水线。现在，流水线运行在 GPT-6 Sol 上，翻译工作则由 GPT-6 Luna 负责，以下提到的模型名称和代码也都已相应更新。

Green Yoga Inc 流水线中的每个内容生成提示词现在都使用 GPT-6 Sol。这部分只需在每个文件中改一行。真正值得写下来的是图像生成的变化：我们已将它从流水线中彻底移除。

模型实际上是在哪里选择的

提示词以纯文本文件的形式存放在 ai-prompts/ 中，并带有文件头；它们从不以字符串字面量的形式写在 Lambda 源代码里。目前共有 23 个提示词文件，另有一个用于临时图像批次的 JSON 清单。其中 16 个文件标有 MODEL: gpt-6-sol。

其余文件则是有意不标注：

  • 21-content-translation.txt 使用较小的 GPT-6 模型 gpt-6-luna。它负责将网站翻译成八种语言；对这项工作来说，处理量比质量的最后一点提升更重要。
  • Lambda 仍会读取的三个 gptimage-* 提示词文件都没有 MODEL: 文件头，因为 Lambda 中现在已没有任何内容会把它们发送给 OpenAI。下文会详细说明。
  • 剩下的三个文件包括两个会插入其他提示词的上下文片段，以及一个使用其他服务提供商的图像转视频提示词。

两个 Lambda——ai-content-engine 和 yoga-script——都会通过 normalizeModel() 解析文件头指定的模型：

function normalizeModel(raw?: string): string {
  if (!raw) return "gpt-6-sol";
  // Legacy GPT-5.x ids -> current model
  if (m === "gpt-5" || m === "gpt-5.1" || ... || m === "gpt-5.6" || m === "gpt-image-1.5") {
    return "gpt-6-sol";
  }
  if (m === "gpt-4o" || m === "gpt4o") return "gpt-4o";
  return m;
}

任何旧版模型 ID——从 gpt-5 到 gpt-5.6，以及旧版 gpt-image-1.5——都会统一转换为 gpt-6-sol。即使某个提示词文件已经六个月无人修改，它也无法调用已退役的模型，而是会静默地使用当前模型。gpt-4o 和 gpt-4o-mini 则保持原样，因为仍有一条代码路径需要有意使用 gpt-4o。

两个 Lambda 都使用 Chat Completions

两个 Lambda 都通过 POST /v1/chat/completions 生成文本。如果你读过我们四月发布的文章，就会发现这是一次方向调整：我们之前已统一使用 Responses API，现在又改了回来。对于这两个函数的实际工作——接收系统提示词和用户提示词，然后返回文字内容——Chat Completions 是一种简单可靠、广为人知的接口。

现在仅有开发人员在工作站上手动运行的脚本还会调用 POST /v1/responses。scripts/generate-pose-images.mjs 使用 gpt-6-sol 上的 image_generation 工具，以 1024x1024 的尺寸生成图像；另外两个一次性图像脚本则以 1536x1024 的尺寸执行相同操作。这些都是本地批处理任务，不是浏览器流量，而且它们有意直接调用 OpenAI。

Yoga Sequence Builder 会为自身执行时间做预算

瑜伽序列生成器 通过 yoga-script Lambda 生成教学脚本，该 Lambda 使用基于 GPT-6 Sol 的 05-yoga-script-generator.txt 提示词。脚本生成速度较慢且耗时不定，因此 Lambda 的大部分逻辑都用于时间计算，而不是提示词处理：

  • 单次主要尝试最多运行七分钟，避免一次缓慢调用耗尽整个执行时段
  • 预留最后 25 秒，用于序列化并返回响应
  • 设有 gpt-4o 备用方案，但只有在至少还剩两分钟余量时才会运行

最后这条规则最重要。如果主要尝试在较晚阶段失败，而剩余时间不足，Lambda 就不会启动备用方案，而是返回明确的错误信息：Skipping gpt-4o fallback: insufficient Lambda time remaining。启动一个无法完成的调用，只会把清晰的错误变成超时问题，让调试变得更困难。

我们不再自动生成图像

这是自四月以来真正的变化。

ai-content-engine 中的 generateImage() 现在是一个空操作桩函数。它接收参数但不作处理，并返回备用封面图：

/** Kept as a no-op stub for callers that still reference it directly. */
async function generateImage(imagePrompt: string, s3Key: string): Promise<string> {
  void imagePrompt;
  void s3Key;
  return FALLBACK_COVER_IMAGE;
}

取代它的不是另一个模型，而是一个人。generateOrReuseImage() 会将图像提示词连同空的 S3 key 写入 DynamoDB，并返回备用封面图；审批邮件则会将该提示词发送给人工审核者。收到带有图像附件的回复后，另一个独立的 media-receiver Lambda 会补上实际素材。

提示词存储为三个独立字段——clipL、t5xxl 和 negative——而不是合并成一大段文本，因为负责生成图像的人通常不会使用 OpenAI。这些字段对应扩散模型的提示词输入栏；分开保存后，操作人员就能将每项内容分别粘贴到正确的输入框中，而不必从拼接后的字符串里再拆分。

为什么较慢的流水线才是正确的选择

自动生成封面，是最有可能在无人事先查看的情况下，把令人尴尬的内容放上网站的功能。文字内容本来就需要经过审批邮件，而图像不需要——它们会在无人值守的单次流程中生成、上传并发布。

移除这项功能确实让发布速度变慢了。但这也意味着，网站上的每张图片在发布前都经过人工查看，而这正是我们真正想要的。模型能力增强了，我们反而减少了它在无人监督时要做的事。这两者并不矛盾。

提示词位于 ai-prompts/；Lambda 位于 lambda/ai-content-engine 和 lambda/yoga-script。如果你希望为自己的 AI 内容流水线设计审批流程，联系我们。

← 返回博客