你的 GPT-5.3-Codex-Spark 用量一直是 0？把它变成 Sub Agent 才算真正用起来
公众号名称：徐导AI笔记
作者名称：三只橘喵
发布时间：2026-06-06 20:08
Spark 不是拿来替代 5.5 的，它更适合当一个小工。
很多人打开 Codex 之后，会看到一个奇怪的现象：GPT-5.3-Codex-Spark 的用量一直是 0。
这通常不是额度没开，也不是模型不能用，而是你平时一直在用 5.5 处理所有任务。
但 Spark 本来就不应该被当成主力模型。
Spark 的正确用法，不是替代 5.5，而是变成 5.5 身边的一个小工。
1. Spark 是什么模型
GPT-5.3-Codex-Spark 是 Codex 里的轻量 coding 模型。
它的官方定位不是复杂任务主控，而是 near-instant、real-time coding iteration。简单说，就是低延迟、小步快改。
所以不要问：Spark 能不能替代 5.5？
更应该问：哪些任务不值得动用 5.5，但又很适合交给一个快模型？
比如一个按钮间距、一个卡片高度、一个空状态文案、一个小组件拆分、一个已经定位清楚的小 bug。
这些任务不难，但很碎。人工做烦，5.5 做又有点重。Spark 的位置就在这里。
2. 为什么最好把它放进 Sub Agent
如果每次都要手动切模型，Spark 很容易继续闲着。
今天写代码时，你大概率还是会顺手选 5.5。因为它稳，因为它强，因为你懒得想这个任务到底该不该切。
更好的方式，是让 5.5 继续做主线程，负责理解需求、拆任务、判断风险；然后把某些明确的小任务交给 Spark sub agent。
模型分工可以这样理解：
5.5：主脑，负责规划、判断、跨文件理解、复杂推理。
Spark：小工，负责 UI 微调、小 bug、小重构、小文案、小测试。
人：负责验收，决定是否合并。
Sub Agent 的价值，不是让 AI 更自动，而是让不同模型各干各的活。
3. 怎么配置一个 Spark Sub Agent
可以在项目里建一个 agent 配置文件，比如：
.codex/agents/ui_fixer.toml
里面可以先放一个最小可用版本：
name = “ui_fixer”
description = “Small targeted UI fixes only.”
model = “gpt-5.3-codex-spark”
model_reasoning_effort = “medium”
developer_instructions = """
Make the smallest defensible UI change.
Do not redesign the screen.
Do not change navigation, data model, persistence, or unrelated files.
Keep existing components and design tokens.
After editing, report changed files and manual checks.
"""
这段配置里最重要的是四个东西。
第一，model 指定 Spark。这样这个小工不会再默认走 5.5。
第二，description 要写清楚它适合什么任务。Codex 需要知道什么时候该叫它。
第三，developer_instructions 要限制它不要越界。不要改业务逻辑，不要碰数据模型，不要顺手重构一堆无关文件。
第四，改完必须报告。它改了哪些文件，行为有没有变化，哪些地方需要你手动检查，都要说清楚。
4. 怎么调用它
配好之后，不是把整个任务都丢给 Spark。
正确方式是在 5.5 主线程里明确点名：
Use the ui_fixer agent to adjust only the paywall hero spacing.
Main task stays with you.
Delegate only the small UI patch to ui_fixer.
After it returns, review the diff before finalizing.
这句话的关键，不是“用 Spark”，而是“只把一个小任务交给 Spark”。
Spark sub agent 不是自动驾驶，它是被主线程点名调用的小工。
5. 三个最实用的场景
场景一：UI 微调
这是 Spark 最舒服的位置。
比如按钮间距、卡片高度、paywall hero 区域、icon 大小、空状态文案、移动端断点。
这些改动不需要模型重新理解整个系统。它只需要看懂当前页面，做一个 focused edit，然后停下来。
把一个视觉 note 变成一个小 patch，这是 Spark 最适合干的事。
场景二：小 bug 的最小修复
Spark 适合修已经定位范围的问题。
比如某个 modal 保存失败，某个列表状态不刷新，某个按钮 disabled 条件不对，某个字符串没有走本地化。
这里最好先让 5.5 做判断，找出大概问题位置，再让 Spark 做小 patch。
不要一上来就让 Spark 全项目排查。它不是这个定位。
场景三：小范围重构和清理
比如抽一个小组件，删除重复代码，统一一个文件里的命名，补一个小测试，改一段 Localizable strings。
但提示词一定要收窄：
Only refactor this file.
Do not change architecture.
Do not change the data model.
Keep behavior identical.
Spark 的价值是快，不是让它顺手把整个项目翻一遍。
6. 不要把这些任务交给 Spark
架构设计、跨模块重构、新功能整体实现、大型 bug 排查、复杂测试修复、支付逻辑、权限逻辑、数据迁移，这些任务都不应该让 Spark 做主力。
这些还是让 5.5 做主控。
Spark 可以参与，但只适合做其中某个明确的小块。
Spark 适合快，不适合重。它适合局部执行，不适合全局判断。
结尾
以后看 Codex，不要只问哪个模型最强，而要问这个任务需要主脑，还是只需要一个小工。
规划、判断、架构、跨文件理解，用 5.5；小修、小改、小 polish，用 Spark sub agent。
如果你每天都有一堆小改动，却从来没让 Spark 参与，那就是浪费了一个很适合快改的工具。
如果这篇文章对你有一点帮助，欢迎点个赞，也点个在看。
内容效果不满意？点此反馈