GPT-5.6 Sol、Terra、Luna 怎么选?我的素材库项目为什么最终使用 Sol + Medium

TL;DR

场景:OpenAI 在 2026-07-09 发布 GPT-5.6 系列(Sol / Terra / Luna 三层),在 Codex 中又叠加了 effort 档位(Medium / High / xHigh / Max),日常使用和工程化维护需要明确"模型档位 + 推理档位"两个维度的分工。
结论:模型决定能力基础、effort 决定单次投入,两者不能简单线性替换;对一个长期内容素材库来说,日常默认 Sol + Medium、复杂任务升 Sol + High 是稳定的工程选择。
产出:两档(默认 Sol + Medium / 升级 Sol + High)的运行规则 + 升级前"三问"判断清单 + Sol/Terra/Luna 的工程化分工。

版本矩阵

功能 / 特性	状态	说明
GPT-5.6 系列正式发布(2026-07-09)	✅ 已验证	OpenAI 官方与多家媒体确认 2026-07-09 起 GPT-5.6 系列全面开放,登陆 ChatGPT、Codex 与 API
Sol 命名与定位(旗舰)	✅ 已验证	OpenAI 官方与媒体一致:Sol 是旗舰能力层,面向复杂专业工作、代码、Agent、长程任务
Terra 命名与定位(能力-成本平衡)	✅ 已验证	媒体一致:Terra 兼顾能力与成本,适合多数日常工作
Luna 命名与定位(低成本高吞吐)	✅ 已验证	媒体一致:Luna 速度最快、价格最低,面向高频、批量、轻量任务
Sol 标准 API 价格 $5/5 /$ 5/30(输入 / 输出,每百万 Token)	✅ 已验证	多家媒体引用 OpenAI 公布的标准短上下文 API 价格
Terra 标准 API 价格 $2.5/2.5 /$ 2.5/15(每百万 Token)	✅ 已验证	与 OpenAI 公布价格一致,Terra 约为 Sol 的一半
Luna 标准 API 价格 $1/1 /$ 1/6(每百万 Token)	✅ 已验证	与 OpenAI 公布价格一致
`gpt-5.6` 别名指向 `gpt-5.6-sol`	⚠️ 用户自述	作者在事实核验声明中自述该别名行为,以 OpenAI API 文档为准
`max` 是 ChatGPT Work / Codex 产品档位	⚠️ 用户自述	作者在事实核验声明中自述该产品档位关系,需以 OpenAI 官方为准
API 端 `reasoning.effort` 枚举	⚠️ 文档为准	作者明确指出 API 端 `reasoning.effort` 可用值应以对应模型 API 文档为准,不能与 Codex 界面档位直接混用
Cerebras 高速特化(750 tokens/s)	⚠️ 待验证	部分媒体提到 7 月计划在 Cerebras 上线,正式发布时是否落地需以官方为准

事实核验(2026-07-11): GPT-5.6 的 Sol、Terra、Luna 定位、价格和 gpt-5.6 别名已对照 OpenAI 官方发布与模型页。max 是 ChatGPT Work 与 Codex 中的产品档位;API 可用的 reasoning.effort 应以对应模型 API 文档为准,不能把两者视为同一枚举。

2026 年 7 月 9 日,OpenAI 正式发布 GPT-5.6 系列。

这次更新除了提升代码、工具调用、专业知识工作和 Agent 能力,还改变了过去按照 mini、nano 或单一版本号区分模型的方式,引入了三个新的能力层级:

GPT-5.6 Sol
GPT-5.6 Terra
GPT-5.6 Luna

其中,Sol 是旗舰能力模型,Terra 在智能水平与成本之间取得平衡,Luna 则面向低成本、高吞吐量任务。OpenAI 还明确表示,Sol、Terra 和 Luna 不只是临时型号名称,而是可以按照各自节奏持续升级的长期能力层级。(OpenAI)

面对新的模型体系,一个很现实的问题是:

日常使用到底应该选 Sol、Terra 还是 Luna? Medium、High、xHigh 和 Max 又应该怎么设置?

我最近正好在用 Codex 管理一个长期内容素材库,因此结合实际项目,把这套模型选择逻辑完整梳理了一遍。

最终得到的结论很简单:

日常默认使用 GPT-5.6 Sol + Medium。遇到复杂任务时,将推理等级调整为 High。

这套方案不一定是所有项目成本最低的方案,但对于需要长期维护、持续理解上下文、处理杂乱输入的知识库和内容仓库来说,它足够稳定,也足够简单。

一、先理解 GPT-5.6 的两个选择维度

选择 GPT-5.6 时,实际上需要同时决定两个参数:

使用哪一个模型:Sol、Terra 或 Luna;
在 Codex 中使用什么 effort 档位。

这两个维度解决的不是同一个问题。

可以将它们简单理解为:

模型决定能力基础和能力上限。推理等级决定模型在当前任务上投入多少计算和验证。

例如:

Sol + Medium
Sol + High
Terra + Medium
Terra + High

虽然都属于 GPT-5.6 系列,但它们不是简单的线性大小关系。

Terra 调整到 High,并不会自动变成 Sol。它只是让 Terra 在当前能力基础上投入更多推理。

同样,Sol 使用 Medium,也不意味着它只能处理普通问题。Sol 本身依然是 GPT-5.6 系列中能力最强的旗舰层级,只是在 Medium 下不会为每个任务都进行最高强度的探索和验证。

OpenAI 发布说明确认,ChatGPT Work 和 Codex 可以为 GPT-5.6 选择 effort 档位,其中 max 是这两个产品中的可选档位。API 则使用 reasoning.effort,可用值应以具体模型的 API 文档为准,不能把 Codex 界面中的 max 直接当成通用 API 枚举。(OpenAI)

本文的实践主要讨论 Codex 中的 Medium 和 High;这是针对内容仓库工作负载的工程选择,不是 OpenAI 对所有场景的统一推荐。

所以,选择模型不能只看"High 是不是更强",而应该先判断:

当前任务需要更高的基础能力,还是需要在固定能力下投入更多推理?

二、Sol、Terra 和 Luna 分别是什么

1. GPT-5.6 Sol:旗舰能力层

Sol 是 GPT-5.6 系列的旗舰模型,面向复杂专业工作、深度推理、编程、工具调用和长程 Agent 任务。

OpenAI 官方 API 文档将它描述为面向复杂专业工作的前沿模型,并建议在复杂推理和编码任务中优先从 Sol 开始。gpt-5.6 这个默认别名本身也会指向 gpt-5.6-sol。(OpenAI Developers)

Sol 更适合以下任务:

大型代码仓库理解;
多步骤软件工程任务;
长时间运行的 Agent;
跨文件修改与验证;
系统架构设计;
深度研究;
复杂工具调用;
模糊需求理解;
高价值专业内容生产;
需要长期保持一致性的知识管理。

对于素材库项目来说,Sol 的价值不只是"生成一段更好的文字",而是它更适合作为仓库的长期管理者。

它需要理解的不只是当前输入,还包括:

仓库为什么采用这种结构;
某个素材为什么应该进入这个目录;
新素材和历史素材是什么关系;
哪些内容应该合并;
哪些内容只是表面相似;
哪些素材值得进入选题池;
哪些改动可能破坏已有规则。

这类任务高度依赖稳定判断,而不仅仅依赖输出长度或推理次数。

2. GPT-5.6 Terra:能力与成本平衡层

Terra 是 GPT-5.6 系列中的平衡型号。

它比 Sol 成本更低,但仍然具备较强的代码、推理和 Agent 能力。OpenAI 将 Terra 定位为在智能水平和成本之间取得平衡的模型。(OpenAI)

Terra 适合:

已经有明确流程的日常工作;
结构化信息提取;
固定规则下的代码修改;
常规内容处理;
批量文档转换;
具有明确验收条件的 Agent 任务;
对成本较敏感的生产任务。

如果一个素材库已经运行稳定,目录、Schema、标签和导入脚本都已经固定,那么 Terra 完全可以承担大量日常处理工作。

它的核心优势是:

在保持较强能力的同时,降低大规模调用成本。

按照 OpenAI 公布的标准短上下文 API 价格,Sol 的输入和输出价格分别为每百万 Token 5 美元和 30 美元;Terra 分别为 2.5 美元和 15 美元;Luna 分别为 1 美元和 6 美元。Terra 的标准价格大约是 Sol 的一半。(OpenAI Developers)

因此,当系统进入真正的大规模自动化运行阶段,Terra 会具有明显的经济优势。

3. GPT-5.6 Luna:高吞吐执行层

Luna 是三个模型中速度最快、价格最低的型号,主要面向成本敏感和高吞吐量工作。(OpenAI)

它更适合:

批量分类;
固定字段提取;
文档格式转换;
Front matter 生成;
文件重命名;
简单摘要;
已有标签映射;
JSON、YAML 和 Markdown 互转;
大量结构相似的文本处理;
确定性较高的流水线任务。

Luna 不适合成为复杂素材库的最高决策者。

例如,Luna 可以按照明确规则,为 500 篇文章补充统一的 YAML 字段;但不适合独立决定整个素材库的分类体系是否需要重构。

它更像一个执行效率很高的批处理节点,而不是负责制定规则的总管。

三、我的素材库项目是什么情况

这个项目并不是一个简单的文件夹。

它的目标是建立一个长期运行的内容素材系统,将书籍、文章、新闻、论文、GitHub 项目、产品资料、个人想法和技术实践统一整理起来,为后续内容创作提供支持。

当前素材库包含或者计划包含:

大约 200 本已经经过整理和提取的书籍;
AI、LLM 和 Agent 相关资料;
实时语音、ASR、TTS 和机器人资料;
Coding Agent 和开发者工具资料;
独立开发、SEO 和增长资料;
商业、科技趋势与产品机会资料;
GitHub 项目;
论文和技术报告;
新闻与版本更新;
网页收藏;
零散想法;
已发布文章;
待写选题;
长期内容规划。

这个系统需要完成的,也不只是"把文件放进目录"。

完整流程包括:

text 复制代码

素材进入 Inbox
    ↓
识别来源和素材类型
    ↓
提取元数据
    ↓
清洗和标准化
    ↓
检查重复和语义相似
    ↓
分类和打标签
    ↓
建立与历史素材的关联
    ↓
判断内容价值
    ↓
进入知识库或选题池
    ↓
更新索引和仓库状态
    ↓
运行校验
    ↓
提交处理报告

这意味着,日常维护同时包含三种不同性质的工作:

第一类是机械执行,例如格式转换、字段补齐和索引更新。

第二类是语义判断,例如判断两份资料是不是在讨论同一问题。

第三类是内容决策,例如判断某个素材是否值得发展成一篇文章,应该以什么角度写,以及和已有文章是否重复。

真正困难的通常不是第一类,而是后两类。

四、仓库初始化阶段应该怎么选

我当前经历的第一个阶段是:

仓库初始化,同时导入之前已经由 ChatGPT Pro 整理完成的约 200 本书。

表面看,这只是批量入库。

实际上,这个阶段会确定整个仓库未来的基础规则,包括:

目录结构;
文件命名;
唯一 ID;
元数据 Schema;
标签体系;
主题分类;
素材生命周期;
书籍和知识卡片之间的关系;
重复检测规则;
索引结构;
导入脚本;
校验脚本;
错误日志;
幂等机制;
回滚方式。

如果这些规则在一开始设计错误,那么错误会被批量复制到 200 本书中。

更麻烦的是,一旦后续已经基于这些数据继续积累文章、素材和选题,再修改底层 Schema,就会变成一次全库迁移。

因此,仓库初始化阶段不应该只追求便宜或速度。

更合理的配置是:

text 复制代码

模型:GPT-5.6 Sol
推理等级:High

Sol + High 负责:

理解现有书籍提取产物;
分析不同文件之间的结构差异;
确定最终 Schema;
编写导入和校验脚本;
先导入一小批样本;
根据样本暴露的问题修正规则;
执行完整导入;
对全库进行一致性检查。

这里最重要的原则是:

先验证规则,再扩大处理规模。

不要一开始直接让 Agent 修改全部 200 本书。

更合理的执行顺序是:

text 复制代码

设计规则
→ 导入 5 本
→ 检查异常
→ 修正规则
→ 导入 20 本
→ 再次检查
→ 全量导入
→ 全库审计

这个阶段使用 Sol + High,不是因为 200 本书本身有多难,而是因为它们共同依赖同一套底层规则。

五、进入日常维护后,应该使用 Sol Medium 还是 Terra High

仓库初始化完成后,最让我纠结的是两个配置:

text 复制代码

GPT-5.6 Sol + Medium

和:

text 复制代码

GPT-5.6 Terra + High

Terra + High 看起来很合理。

Terra 成本更低,而 High 可以让它投入更多推理。对于日常分类、归档和选题任务,似乎已经足够。

但最终我选择了:

日常默认使用 GPT-5.6 Sol + Medium。

原因不是 Terra + High 无法完成,而是 Sol + Medium 更符合这个项目的长期运行方式。

原因一:日常输入并不稳定

这个素材库未来接收的不是一种固定格式,而是各种杂乱内容:

一篇网页;
一段聊天记录;
一份 PDF;
一个 GitHub 仓库;
一份 Release Notes;
一段临时想法;
一批 EPUB 提取结果;
一个尚未验证的技术方案;
一篇已经过时但仍有参考价值的文章。

这些输入的结构、质量和价值完全不同。

模型需要先理解内容,再决定如何处理。

这并不是标准化流水线,而是长期存在模糊判断的知识工作。

原因二:日常任务也会影响仓库整体

一次普通归档看似影响很小,但如果模型:

将素材放错分类;
创建了重复标签;
将不同概念错误合并;
没有识别已有素材;
将低价值内容误判为高优先级;
修改了不应该修改的索引;
忽略了已有文章的关系;

这些小错误会在长期运行中不断累积。

素材库最危险的问题不是某一次处理失败,而是分类和语义逐渐漂移。

因此,日常总管更需要稳定的基础判断能力。

原因三:Medium 已经是合理的默认推理档位

对这个素材库而言,Medium 是能力、时延和消耗之间更合适的日常起点。是否切换到 High,应该通过代表性任务的准确率、返工率、校验失败率和总消耗来判断。

素材库日常任务通常已经具备:

固定目录;
明确 Schema;
已有标签体系;
稳定导入脚本;
校验规则;
Git 历史;
操作边界。

这意味着模型不需要每次重新设计系统。

它需要做的是理解当前素材,并在已有规则下完成判断和执行。

Sol + Medium 正好适合这种状态:

使用更强的基础模型,保持适中的推理投入。

原因四:减少模型切换本身也是一种优化

实际使用中,最麻烦的往往不是模型成本,而是不断判断:

这个任务应该用 Terra High 吗?
要不要换 Sol Medium?
这次算不算复杂?
需不需要 xHigh?
批处理是否应该换 Luna?

如果每次任务都先进行一次模型选择,使用成本反而增加了。

因此,我最终将系统简化为两档:

text 复制代码

默认:GPT-5.6 Sol + Medium
复杂:GPT-5.6 Sol + High

基础模型保持不变,只调整推理等级。

这样可以减少模型之间的行为差异,也更容易积累稳定的提示词、Agent 规则和仓库操作习惯。

六、什么任务属于 Medium

在我的素材库项目中,以下任务默认使用 Sol + Medium。

1. 日常素材入库

例如将网页、技术文章、聊天记录、GitHub 项目和零散想法放入 Inbox 后,让 Agent 完成:

类型识别;
元数据提取;
格式清洗;
基础去重;
标签生成;
分类归档;
索引更新;
Git 提交。

2. 已有规则下的语义整理

例如:

判断新素材和哪个已有主题相关;
将素材关联到现有知识卡片;
检查是否已经存在相似内容;
修正明显错误的分类;
合并完全重复的条目。

3. 普通选题发现

例如从最近新增素材中生成:

本周可写选题;
适合做常青内容的主题;
可以补充旧文章的材料;
适合博客、CSDN 或小红书的内容角度;
素材完整度较高的候选主题。

4. 常规脚本维护

例如:

修复明确的小 Bug;
补充一个字段;
调整索引生成逻辑;
增加日志;
完善测试;
修改已明确的转换规则。

5. 日常内容规划

例如:

根据已有选题池安排本周文章;
整理一篇文章的大纲;
从素材库中选择引用资料;
判断某个选题当前是否具备写作条件。

这些任务虽然需要判断,但主要是在既有体系中运行,不需要重新设计整个体系。

七、什么情况下应该切换到 High

当任务开始涉及规则设计、跨模块影响或不可逆修改时,再将 Sol 从 Medium 调整到 High。

1. 修改仓库 Schema

例如:

新增或删除核心字段;
改变素材卡片结构;
调整书籍、章节和知识点之间的关系;
修改唯一 ID 规则;
更换标签体系。

2. 大规模历史数据迁移

例如:

修改全部书籍文件格式;
重新生成数千条索引;
合并两个长期目录;
将旧版 Front matter 转换为新版;
重建全文检索数据。

3. 跨大量文件的语义去重

普通重复检测可以使用 Medium。

但如果需要判断:

两篇文章是否只是角度不同;
多本书中的知识点是否应该合并;
不同名称是否指向同一个技术概念;
多个选题是否属于同一内容主线;

这类任务更适合 High。

4. 仓库整体审计

例如检查:

分类漂移;
标签膨胀;
孤立文件;
无效链接;
缺失字段;
重复素材;
Schema 不一致;
高价值但未利用的素材;
已经过时的选题;
内容方向上的结构性空缺。

5. 复杂故障和连续修复失败

当一个问题已经尝试修复一次,但仍然出现:

多模块相互影响;
测试结果不稳定;
数据被重复修改;
导入脚本不具备幂等性;
问题难以复现;
修复引入新的错误;

此时应切换到 High,让模型重新检查假设、执行路径和验证结果。

6. 重要内容战略

例如:

月度内容规划;
季度内容方向;
是否进入一个新的技术赛道;
如何平衡热点、SEO、技术深度和商业价值;
如何将零散文章发展成系列、专栏或产品;
哪些内容应该停止投入。

这种任务没有唯一标准答案,需要综合大量信息并做取舍,因此适合 High。

八、为什么不建议长期固定使用 High

既然 High 的推理更多,为什么不一直使用 High?

原因是素材库的大多数日常任务并不需要重新探索整个问题空间。

当任务已经有明确规则时,High 可能带来:

更高的 Token 消耗;
更长的执行时间;
更复杂的中间推理;
对稳定规则进行不必要的重新分析;
产生超出任务范围的修改倾向。

更高推理等级并不代表任何任务都会同比提高质量。

工程上更稳妥的做法,是先为代表性任务建立 Medium 基线,再测试 High 是否带来可测量的质量收益,而不是默认所有任务都使用最高档位。

因此,更合理的原则是:

执行已有规则,使用 Medium。需要设计、修改或重新判断规则,使用 High。

九、Terra 和 Luna 还有没有价值

虽然日常总管最终选择了 Sol + Medium,但 Terra 和 Luna 依然有明确价值。

Terra 适合扩大规模

当素材库流程已经完全稳定,并且开始通过 API 大规模自动处理内容时,可以将部分任务迁移到 Terra。

例如:

每天处理大量新闻;
批量整理 Release Notes;
扫描数百个 GitHub 项目;
生成固定格式的素材卡片;
按已有规则完成初步分类。

这类任务可以采用:

text 复制代码

GPT-5.6 Terra + Medium

如果输入格式比较混乱,但任务边界仍然明确,可以使用:

text 复制代码

GPT-5.6 Terra + High

Terra 更适合解决成本和吞吐量问题,而不是取代 Sol 作为最终决策层。

Luna 适合处理机械流水线

Luna 可以承担:

批量字段提取;
文件格式转换;
固定模板摘要;
Markdown 清洗;
文件重命名;
JSON 和 YAML 生成;
字段完整性扫描;
固定标签映射。

一个成熟的系统可以形成这样的分层:

结论

模型策略最终必须回到任务风险、可验证性和长期维护成本。固定一个稳定默认值,再为高影响任务设置清楚的升级门槛,比频繁追逐最高档位更可靠。

错误速查卡

症状	根因	定位	修复
把 Sol + Medium 当成"保守配置",一开始就上 Sol + High 跑日常	误以为 effort 越高收益越大;忽略 High 会带来更长时延、更高 Token 消耗和对稳定规则的过度重新分析	看单任务 Token 消耗、时延、校验失败率;代表性任务跑 Medium vs High 对比	日常回退 Sol + Medium,把 High 留给 Schema 修改、历史迁移、全库去重、复杂故障、内容战略
日常用 Terra + High,想"省钱 + 投更多推理"代替 Sol	混淆模型档位与 effort 档位:Terra + High 不等于 Sol,Terra 的能力上限本身低于 Sol	看分类漂移率、归档返工率、复杂模糊输入的判断质量	日常回 Sol + Medium;Terra 留给已稳定可批量化的任务
仓库初始化阶段就用 Luna 跑批量入库 200 本书	把高吞吐执行层当成最高决策层:Luna 适合机械流水线,不适合制定规则	看样本导入后是否出现分类错位、Schema 不一致、字段缺失	初始化阶段切回 Sol + High,先小批试运行,验证规则后再扩量
API 调用时把 Codex 里的 `max` 档位直接当成 `reasoning.effort` 值传	混淆产品界面档位与 API 枚举:Codex `max` 是产品档位,API 端 `reasoning.effort` 应以对应模型 API 文档为准	看 API 报错或模型对该值的接受情况	按 OpenAI API 文档传入正确的 `reasoning.effort` 枚举值
短上下文成本估算只算输入 Token,忽略输出 30 / 15 / 6 美元/M 的价格差	Sol/Terra/Luna 的输出价格分别是输入的 6 倍、6 倍、6 倍,长输出任务成本被低估	算单次任务总 Token × 各自输出价格;看月度账单	长输出任务考虑用 Luna 或 Terra;或压缩 prompt 让模型输出更短
每条新素材都先在三个模型之间切换选档	模型档位 + effort 档位组合过多,使用成本不降反升	看是否每个任务都先做"选哪个模型 + 哪个 effort"判断	简化为两档:默认 Sol + Medium,复杂 Sol + High,机械任务 Luna
把 Luna 推到内容战略、Schema 设计、复杂故障修复	Luna 适合确定性流水线,长程推理和跨文件判断不是它的设计目标	看任务是否依赖稳定判断 vs 确定性转换	战略与设计类任务用 Sol,必要时 High;不要让 Luna 决定规则
用 High 处理已有规则下的常规分类,反而修改了不该改的索引	High 倾向于重新探索问题空间,容易"越界"修改	看 Git diff 中是否有超出任务范围的修改	已稳定规则下回到 Medium,只读不写或加显式边界约束
默认所有任务都用 `xHigh` 或 `max`,账单爆炸但质量没可测收益	推理档位越高,边际收益递减,Token 与时延线性增长	跑代表性任务 baseline vs `xHigh` 对比质量;看总 Token 与时延	回到默认 Medium;按"升级前三问"判断是否真要升档
把 GPT-5.6 别名 `gpt-5.6` 误用成别的能力层	`gpt-5.6` 默认别名指向 `gpt-5.6-sol`,不是 Terra / Luna	看 API 调用实际命中的模型	显式指定 `gpt-5.6-sol` / `gpt-5.6-terra` / `gpt-5.6-luna` 别名
一次"全库去重"用 Sol + Medium,P99 准确率很差	全库去重跨大量文件,需要稳定判断而不是按规则执行	看是否出现误合并、误拆分、角度不同的内容被错误判定	升 Sol + High;用校验与报告做闭环
仓库审计只跑一次,过了半年没人复核分类漂移	长期内容仓库的真正风险是"分类与语义逐渐漂移",不是单次失败	看月度/季度是否有审计与回滚记录	把仓库审计纳入固定周期,异常时升 Sol + High 重跑

作者:武子康的个人博客