OpenAI 于 2026 年 9 月 22 日发布 GPT‑6 Luna，定位是处理范围清楚、数量大的任务。它的标准 API 文本价为每百万输入/输出 token 0.10/0.50 美元，相较 GPT‑5.6 Luna 当时的促销价 0.20/1.20 美元下降。官方还给 Batch 和 Flex 处理列出标准费率的 50% 价格。发布公告 Luna 模型页
这条新闻对中文内容站的意义，是可以更便宜地处理大量有明确答案的前置工作，例如从商品资料抽取属性、标出旧文章里需要重新核对的日期、给已定义类别的查询词做初分。整篇新闻解读或 SEO 文章还涉及选择可信来源、确定搜索意图和解释例外；低 token 价格没有解决这些判断。团队该量的是一条通过验收的记录用了多少 API 费和人工时间，而不是“生成了多少段文字”。
标准费率下降，批量账单还要看处理方式
假设有 500 条商品资料，每条平均输入 2,000 token、输出 250 token，合计 100 万输入、12.5 万输出。只计普通文本 token，不计缓存、工具、重试和人工复核，则：
| 处理与价格口径 | 计算 | 500 条文本费 |
|---|---|---|
| GPT‑5.6 Luna 当时促销价 | 1×0.20＋0.125×1.20 | 0.35 美元 |
| GPT‑6 Luna 标准价 | 1×0.10＋0.125×0.50 | 0.1625 美元 |
| GPT‑6 Luna Batch/Flex 官方费率 | 标准文本费 × 50% | 0.08125 美元 |
旧版促销价与新版标准价在这组 500 条假设任务中只差 0.1875 美元。所以团队不应为这笔差额单独重建生产流程；当调用量很大，或新版减少了重试与审核，收益才可能变得显著。上表是按公告费率计算的教学账单，不是本站发送了 500 次请求后的实收费用。
Batch/Flex 的交付方式、时效和项目可用性须按实际接口确认；若任务要同步返回结果，先用标准方式估算。模型页还规定，单次提示超过 272,000 输入 token 时，整次请求的输入与缓存费率乘 2、输出费率乘 1.5；搜索等收费工具、区域处理和 fast mode 又有各自价格。把 500 条合成一次超长请求，不一定比拆开更省。模型计费条件
更关键的是人工。即使这批 500 条的模型文本费不足一美元，若审核员平均每条看一分钟，也要 500 分钟，约 8 小时 20 分钟。这同样是教学假设，但揭示了预算重点：让模型输出能被快速自动比对或抽样核查的字段，才可能缩短总工时。把不可追溯的营销描述批量写出来，再由编辑逐句查来源，便宜的调用费可能换来更贵的返工。
一条“合格输出”长什么样：看来源，不补空白
以下是教学示例，不代表对 Luna 的实测。假设源表有三条商品记录；目标是形成可入库的属性数据，而非写一段推销文案。输出至少包含 SKU、字段值、来源位置和是否待核。
| 源表输入 | 应交付的记录 | 不合格输出 |
|---|---|---|
| A17：深蓝、750 ml、不锈钢；保温时长空白 | 颜色=深蓝，容量=750 ml，材质=不锈钢，均注明“商品表”；保温时长=未提供、待核 | 根据同类商品猜“保温 12 小时”，或把“不锈钢”扩写成“316 食品级” |
| B08：商品表写 500 ml，供应商附件写 550 ml | 容量=冲突、待核；同时保留两处来源原值 | 任选一个数入库，或擅自平均为 525 ml |
| C03：两份来源均写 1 L，材质均写玻璃 | 容量=1 L，材质=玻璃，注明两份来源并标可复核 | 为凑卖点增加“耐高温” |
这些是理想输出与拒绝条件，并非模型已经通过的测试。可在系统里要求结构化返回字段值和来源列，再用规则先拦截“输出有值但源字段为空”“两份来源相冲突却给单一确定值”等情况。A17 的空白与 B08 的冲突是两种不同问题：前者可能补资料，后者需要确认哪个来源更新；都不应靠语言模型自行编出答案。
一条记录最终会影响哪张页面
字段提取只是中间步骤。假设这三条 SKU 属于一个正在改版的产品站，A17 的保温时长仍为空，产品详情页就不应出现“保温 12 小时”；B08 的容量冲突未解决，产品详情和“500 ml 水杯”聚合页不能分别写两个数；C03 经来源确认后，才可把玻璃与 1 L 两个事实同步到详情页和真实使用这些属性的筛选入口。聚合页是否需要新增，仍取决于是否有足够商品与独立的用户任务，不能因模型抽出了一个字段就批量造页。
这能形成一条可核对的页面工单：源记录 → 待核字段 → 目标 URL → 页面上实际显示的值 → 发布结论。编辑抽查的不只是 JSON 准确率，还要打开目标页核对可见文案、筛选结果和结构化数据是否一致。若模型把 B08 错归到 500 ml 聚合页，即使 499 条记录正确，这一条也应拦截；错误会直接误导搜索者和采购者。页面任务应先写进SEO 内容 Brief 与大纲，再决定 Luna 负责抽取哪一列。
同样原则适用于 Search Console 查询词分类，但别把“词面分类”误认为真实搜索意图。查询词若同时可能是教程和服务需求，输出“不确定”并交给研究人员查看 SERP 和落地页，比强行塞进一个类别更有用。
降本发生在哪一段，任务就放在哪一段
把内容生产拆开看，Luna 最容易发挥价值的是高频、重复、可核对的中间结果。例如抓取已有表格字段、给变更日志标产品与日期、把已确认来源中的数值提取到待核清单。这里的完成标准可以在任务开始前写清：源字段在哪里、缺失时怎么表示、冲突时是否升级人工。
写一篇 Google 更新解读则不同。编辑要判断“这次更新适用于谁”“来源究竟支持到什么程度”“中文读者应改变哪一步”，即使模型句子流畅，也不能用属性抽取的准确率证明它能完成这种分析。可以让 Luna 整理原文事实和待核问题，再由编辑或更适合复杂判断的模型完成结论。若要比较复杂模型，可看本站 GPT‑6 Sol 更新解读；但不同任务的价格和官方 benchmark 不构成直接的文章质量排名。
OpenAI 的模型选择指南也把模型选择落在任务需求上。实际分流时，先问两件事：输出错误能否由来源字段直接发现？错误若漏过，会不会改变产品事实、搜索更新适用范围或发布结论？前者“能”、后者“低”的任务可优先试 Luna；其他任务要提高来源核验和编辑关口，而非只增加模型调用次数。
先验收一小批，再决定是否处理 500 条
从已人工确认的资料里取一小批，包括完整、空白、冲突和过期资料。事先确定哪些字段必须准确、哪些允许留空、哪些一错就要退回。运行后逐条记下：通过条目、漏字段、编造字段、送人工待核、重试次数和审核分钟数。测试集中必须留住 B08 这种会改错页面归属的反例；如何设计能发现错误的样本，可参考站内的AI 助手评测题设计。
假设 500 条里有 450 条首次通过、50 条需要重新处理，则前文的 0.1625 美元不能直接叫“500 条成品的成本”。应把第二次调用、工具费和审核时间加入，再用总成本除以最终合格条目；若那 50 条恰好是高价值产品，整体通过率也掩盖了业务风险。这是展示计算口径的假设场景，不是本站测得的 Luna 通过率。
API 模型名为 gpt-6-luna。内建工具与函数调用应使用 Responses API；若仍用 Chat Completions，函数调用只在 reasoning_effort 为 none 时受支持。接入前先核对项目权限、配额和处理方式。API 能力说明
ChatGPT 的入口另算：发布时部分付费计划可在 ChatGPT Work 与 Codex 使用，Free/Go 当时可在桌面应用使用，普通 Chat 当时尚未开放。2026年10月11日核对的模型帮助仍将 Work、Codex 与普通 Chat 区分；使用时查看当前账号支持的入口。发布公告
常见问题
Luna 比上一代便宜一半，500 条任务就能省一半吗？
API 普通输入价从 0.20 到 0.10 美元，输出价从 1.20 到 0.50 美元，旧价是当时促销价。实际总额还受输入/输出比例、缓存、处理模式、重试与人工审核影响。文中的 0.1625 美元只是一组固定 token 用量的标准文本费。
可以把整篇 SEO 文章交给 Luna 批量发布吗？
可以让它处理事实提取、清单初分或局部改写；整篇文章仍需要对意图、证据、结论和页面效果负责。先证明每个前置结果可核对，再决定哪些后续步骤能自动化。
Batch/Flex 的半价适合所有工作吗？
它们的模型页费率为标准价的 50%，但任务能否接受对应处理方式与时效，需要在实际 API 项目里核对。需要即时呈现给编辑的交互任务，不能仅看半价就改变处理方式。