GPT-5.6 的核心叙事很直接：每个 token 提供更多智能、每美元获得更强性能，并且在最难的工作上可以按需调用更高能力。对工程团队来说，这不只是“模型更聪明”这么简单，而是会影响提示词设计、路由策略、成本预算和任务拆分方式。
每个 token 更值钱，提示词也要更克制
“More intelligence from every token”意味着你不应该继续把上下文当垃圾桶。模型能力增强后，真正有价值的是把问题边界、输入数据和输出契约写清楚，而不是堆满背景材料。
可以把提示词从“讲给模型听”改成“给模型执行规格”：
你是一个资深后端工程师。请审查下面的 API 设计，输出 JSON。
目标：发现会导致线上事故、数据不一致、权限绕过的问题。
输入：
- OpenAPI 片段
- 认证模型说明
- 数据库约束
输出 JSON schema：
{
"risk_level": "low|medium|high",
"findings": [
{
"title": "string",
"impact": "string",
"evidence": "string",
"fix": "string"
}
]
}
约束：
- 不要输出泛泛建议。
- 找不到问题时 findings 为空数组。
- 不要输出 Markdown。
这种写法的好处是减少 token 浪费，也更容易做自动化解析。模型越强，越应该让它面对清晰任务，而不是猜测你的真实意图。
按美元性能更强，重点在“路由”而不是全量升级
来源摘要强调 stronger performance per dollar。落到系统里，不建议把所有请求无脑切到最强模型。更现实的做法是：普通任务走便宜路径，复杂任务按需升级。
可以这样实践：给任务加一个轻量分级器，根据任务复杂度选择模型。下面示例使用 OpenAI 风格的 Chat Completions API；运行前把 OPENAI_API_KEY 和模型名替换成你实际可用的名称。
import os
import json
import requests
API_KEY = os.environ["OPENAI_API_KEY"]
API_URL = "https://api.openai.com/v1/chat/completions"
# 按你的供应商实际模型名调整。
FAST_MODEL = "gpt-5.6-mini"
FRONTIER_MODEL = "gpt-5.6"
def chat(model, messages, temperature=0):
resp = requests.post(
API_URL,
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
},
json={
"model": model,
"messages": messages,
"temperature": temperature,
},
timeout=60,
)
resp.raise_for_status()
return resp.json()["choices"][0]["message"]["content"]
def classify_task(user_request):
prompt = f"""
请判断任务复杂度，只输出 JSON：
{{"level":"simple|hard", "reason":"一句话"}}
simple：摘要、改写、格式转换、短问答。
hard：代码审查、系统设计、多约束推理、故障分析、长上下文综合。
任务：{user_request}
""".strip()
raw = chat(
FAST_MODEL,
[{"role": "user", "content": prompt}],
)
return json.loads(raw)
def answer(user_request):
route = classify_task(user_request)
model = FRONTIER_MODEL if route["level"] == "hard" else FAST_MODEL
return chat(
model,
[
{"role": "system", "content": "回答要具体、可执行，必要时说明假设。"},
{"role": "user", "content": user_request},
],
)
if __name__ == "__main__":
task = "审查这个支付回调接口设计，找出幂等性和权限风险。"
print(answer(task))
这个模式的关键不是分类器多聪明，而是把预算控制放进架构里。你可以记录每次路由的输入长度、模型、延迟、成本和人工反馈，再逐步调阈值。
最难的工作需要“按需能力”，不是一次性大提示词
“More capability on demand for your hardest work”更像是在提醒我们：复杂任务要拆成工作流，而不是把所有材料塞进一个请求。
例如代码迁移、合规审查、事故复盘这类任务，通常可以拆成四步：
- 收集事实：读取日志、PR、配置、指标。
- 建立假设：列出可能原因或改造路径。
- 验证假设：要求模型引用证据，不能只给结论。
- 生成交付物：补丁、报告、测试清单或运行手册。
可以这样改造提示词，让模型在高能力模式下更可控：
任务：分析一次生产故障。
你必须分阶段输出：
阶段 1：事实表
- 只列出日志、指标、变更记录中明确出现的信息。
- 每条事实必须带来源片段。
阶段 2：候选原因
- 给出最多 5 个候选原因。
- 每个原因标注支持证据和反证。
阶段 3：下一步验证
- 给出可以在 30 分钟内执行的命令或查询。
- 不要建议“大规模重构”。
阶段 4：对外说明
- 写一版给工程团队的技术说明。
- 写一版给客户成功团队的非技术说明。
模型能力越强，越要给它检查点。否则你得到的可能是流畅但不可验证的长答案。
工程接入清单：别只看分数，也看运行形态
评估 GPT-5.6 这类 frontier 模型时，建议从一组真实任务开始，而不是只看公开 benchmark：
- 选 20 到 50 个高价值任务：代码审查、SQL 修复、客服升级工单、需求拆解、故障分析。
- 给每个任务定义验收标准：正确性、引用证据、可执行性、格式稳定性。
- 同时记录成本和延迟：按任务类型看每美元产出，而不是只看单次调用价格。
- 保留人工复核：尤其是安全、财务、法律、生产变更相关任务。
- 设计降级路径：高能力模型不可用或超预算时，系统应该返回可解释状态，而不是静默失败。
GPT-5.6 的价值不在于让每个按钮都调用最强模型，而在于把更难、更贵、更需要判断力的部分交给它。成熟的接入方式，是让模型能力随着任务难度扩展，同时让成本、证据和失败模式都留在工程师能控制的范围内。