IT2026年8月18日

我们的 AI 内容流水线运行在 GPT-5.6 上——而且生成的图片比以前更少了

作者：Andrea Borghi
我们的 AI 内容流水线运行在 GPT-5.6 上——而且生成的图片比以前更少了

我们的 AI 内容流水线运行在 GPT-5.6 上——而且生成的图片比以前更少了

Green Yoga Inc 内容流水线中的每个文本提示现在都面向 GPT-5.6。这部分每个文件只需改一行。真正值得写的是图片生成发生了什么变化——我们已经把它从流水线中完全移除了。

模型实际是在什么地方被选定的

提示词以纯文本文件形式存放在 ai-prompts/ 中，带有头部信息，从不作为 Lambda 源码里的字符串字面量存在。到今天共有 19 个，外加一个用于一次性图片批处理的 JSON 清单。其中 15 个写的是 MODEL: gpt-5.6。

有两个故意不是：

  • 21-content-translation.txt 仍然使用 gpt-5.4-mini。它把网站翻译成八种语言，而在这项工作里，吞吐量比最后一点质量提升更重要。对全部内容做一次完整重译大约只要十美分。
  • 三个 gptimage-* 提示文件根本没有 MODEL: 头部，因为 Lambda 里的任何东西都不会再把它们发送给 OpenAI。下面会详细说明。

两个 Lambda——ai-content-engine 和 yoga-script——都会通过 normalizeModel() 把头部里写的内容解析出来：

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

任何旧 ID——从 gpt-5 到 gpt-5.5，以及旧的 gpt-image-1.5——都会被折叠为 gpt-5.6。一个六个月没人碰过的提示文件不可能调用已弃用的端点；它会静默地改用当前旗舰模型。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：这是一个开发者脚本，由人在工作站上手动运行。它在 1024x1024 分辨率下使用 gpt-5.6 的 image_generation 工具。这是一个本地批处理任务，不是浏览器流量，而且它是有意直接调用 OpenAI 的。

Yoga Sequence Builder 自己管理自己的时间预算

Yoga Sequence Builder 通过 yoga-script Lambda 生成教学脚本，由 GPT-5.6 上的 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() 会把图片提示写入 DynamoDB，并将 S3 key 置为空，然后返回备用内容，而审批邮件会把这个提示发给人工审核。等回复带着图片附件回来后，另一个 media-receiver Lambda 会填入真实资源。

这个提示被存储为三个独立字段——clipL、t5xxl 和 negative——而不是一个整体，因为处理它的人通常并不是在使用 OpenAI。这些是扩散模型的提示槽位，分开存放意味着操作员可以把每一项直接粘贴到正确的输入框里，而不必去拆解一个拼接后的字符串。

为什么更慢的流水线才是正确的流水线

自动封面生成曾是最容易在没人先看一眼的情况下，把尴尬内容放到网站上的功能。文本已经要经过审批邮件。图片没有——它们会被生成、上传并在一次无人值守的流程中直接发布。

移除这一步确实让发布变慢了。但这也意味着本网站上的每一张图片在上线前都被人看过，这才是我们真正想要的属性。模型更强了，而我们让它在无人监督下做得更少。这两者并不矛盾。

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

← 返回博客