Theo 为什么在 Claude Code 中运行 GPT-5.6 Sol

我一直大量使用 GPT-5.6 Sol，但常常在 Claude Code 而不是 Codex 中使用。这个结果连我自己也感到意外。原因不只是终端界面：运行框架、系统提示词、子代理编排和集成方式都会影响同一个底层模型的行为。

这些是我的实际使用印象，不是条件受控的正面对比。我仍认为 Codex 桌面应用对许多人来说是不错的起点，但我对其 CLI 的一些方面，尤其是子代理编排方式，越来越感到挫败。

在我测试的版本中，Codex 有一种简单的子代理实现：主代理向下一层分配任务；还有一种实验版本，支持嵌套的具名代理、继承上下文和消息传递。我觉得后者功能强大，但复杂且难以预测。

我使用的 Claude Code workflow 功能采用了不同方式：模型编写代码，定义阶段、提示词、子代理和控制流程，然后由运行时执行。我喜欢看到明确的工作结构，而不只是依赖临时委派。

在我的试验中，这些工作流往往更可预测地结束，消耗的额度也远低于我拿来比较的 Ultra 运行。我估计有些情况下输出相近，token 用量约为四分之一，但这只是个案，不是经测量的普遍规律。

这促使我尝试让 Sol 本身在 Claude Code 内完成工作，而不只是让 Claude 模型把 Codex 作为独立工具调用。这样的组合让我探索：换一个运行框架，是否会改变一个我已经熟悉的模型的使用体验。

我展示了两个生成页面：一个由 Claude Code 中的 Sol 制作，另一个由 Codex 中的 Sol 制作。我更喜欢第一个设计，尽管两者都不完美。这个例子促使我调查各环境给模型的指令，但它本身无法单独确定原因。

在我查看的 Claude Code 提示词里，找到的主要前端指令是：宣布工作完成前，运行应用并在浏览器中使用它。这是验证要求，而不是详细的视觉风格指南。

随后我查看了一份缓存的 Codex 提示词。我尤其担心其中很长的前端部分，它对不同界面的设计决策作了规定。我在视频中说，这些指导最近已针对 5.6 改变；这里批评的是历史版本，并不代表所有当前安装都使用同样的内容。

有些建议听起来合理，比如尊重现有设计系统。我的异议在于大量非常具体的默认规则累积在一起：例如要求商业软件采用安静、实用的风格，并限制常见控件和卡片的外观。

画面中的文字规定，除非现有设计系统另有要求，卡片圆角最多为 8 像素，并鼓励使用图标按钮。我担心的是，这类宽泛规则可能把风格偏好变成通用约束，即使产品或用户需要其他设计。

该提示词还在许多情况下不鼓励显示解释文字或制作落地页，同时规定了部分首屏布局。这些约束可能妨碍新用户引导、空状态或无障碍设计。正确选择取决于应用本身，而不是固定模板。

我认为，强模型会遵循收到的规则；当输出看起来千篇一律时，这些规则本身值得审查。我计划编写并评估替代提示词；关于设计差异的原因，这仍是我的假设，不能证明仅由提示词造成。

我还注意到长任务中频繁出现 30 秒等待或更新，并在所查看的版本中发现了要求频繁更新的指令。我怀疑这条指令影响了行为，但视频并不能证明它是唯一原因。

为了获得其他视角，我让几个模型审查这份提示词。其中 Sol 的一份回答分别给它作为特定运行时提示词、通用编程提示词和可移植提示词的表现打了不同分数。这些是模型生成的意见，而非对提示词质量的独立测量。

这份审查反对重复描述运行时细节，也反对把篇幅很长、规定过细的前端部分用于无关任务。它还质疑纯图标控件和对解释文字的宽泛限制，因为触屏界面、新用户引导和错误恢复可能需要可见的说明。

我把持续工作过久、或用户想先探索时就开始实现等行为，与关于持续执行和采取行动的指令联系起来。这是我对提示词和自身体验的解读；要确定因果关系，还需要更严谨的比较。

提示词和产品会因模型及版本而变化。我提到有人告诉我，旧模型的提示词与其训练有关，而较新版本的指导已经改变。我从中得到的教训是检查实际使用的配置，不要把一份提示词当成永远不变。

相比之下，我阅读的 Claude Code 提示词对软件任务给出了更一般性的指导。我喜欢它区分探索性问题和实现请求、倾向于只写有意义的注释，以及强调在浏览器中测试界面改动。

我也重视它对操作可逆性和影响范围的强调：本地编辑与测试，不同于破坏性操作或对外可见的操作。这些是我觉得有用的原则，并不证明任何代理都不可能造成损害。

我建议更仔细地重写并评估 Codex 提示词，包括审查真实交互记录。我更偏好人工撰写全局指导，但无论采用什么起草方式，重要的是看它在有代表性的任务中如何表现。

在 Claude Code 中使用 Sol 也有缺点。有一次文件名冲突后，我以为它没能发布生成的 HTML 报告。仔细检查后发现它确实发布了；只是链接格式不熟悉，我没有注意到。

不过格式问题仍然存在，比如编号列表出现重复数字。这次更正很重要：步骤实际完成了，就不该把它说成模型遗漏；但展示方式仍可能让结果更难理解。

在编排方面，我展示了一个提示词例子：要求工作流使用 Sol、Terra 和 Fable 子代理分析代码库。模型需要充分了解可用名称和工具，才能协调工作。明确要求使用工作流，有助于传达期望的结构。

另一个小差异是报告方式：在我的配置中，5.6 要等任务结束才显示子代理 token 用量，而 Fable 会实时更新。即使底层工作相似，这些细节也会影响可观察性。

为什么不用 Pi 或 OpenCode？我的理由很具体：我在寻找内置的分阶段子代理工作流编排方式。我喜欢 Pi 的某些方面，但需要自己构建更多编排功能；录制时我还没有评估较新的 OpenCode 版本。

在日常工作中，我觉得工作流有用，因为它能表达阶段、依赖关系、模型选择和结束条件。我不认为其他工具无法实现这一点；它只是我当时针对这个需求亲自找到的最佳实现。

我提到一个 CLI 代理，可以把不同服务商和订阅接入我使用的工具。视频没有给出完整配置教程，服务商支持情况、条款和价格也可能变化。尝试集成前应查看当前文档和授权访问条件。

我不是说所有人都应该通过 Claude Code 使用 Codex 订阅。这次实验的效果超出我的预期，也说明模型周围的运行框架可能有多重要。用自己的任务测试这种组合，再自行判断结果。