GPT-5.6 提示词与模型使用指南

记录日期：2026-07-27

官方来源：Using GPT-5.6 / Prompting best practices

本文是面向本项目的中文提炼，不替代官方 API 文档。

1. 模型定位

• gpt-5.6 默认指向旗舰能力模型 gpt-5.6-sol。
• gpt-5.6-terra 面向能力与成本平衡。
• gpt-5.6-luna 面向高吞吐、成本敏感任务。
• GPT-5.6 强调 Token 效率、复杂生产流程、意图理解和前端设计质量。

选择原则：

• 高价值复杂分析、代码实现和审查：优先 Sol。
• 大批量但仍需较强质量：评估 Terra。
• 高频简单流程：评估 Luna。
• 不凭模型名称猜效果；在代表性任务上比较质量、延迟、Token 和成本。

2. 主要新增能力

Programmatic Tool Calling（PTC）

模型可编写 JavaScript，在托管运行时中调用允许的工具、传递结果并压缩中间输出。适合边界明确的：

• 过滤、Join、排序、去重；
• 聚合、批量验证；
• 多次工具调用后只需返回小型结构化结果的流程。

以下情况优先使用普通工具调用：

• 单次调用即可完成；
• 每次结果都会改变下一步判断；
• 操作需要用户审批；
• 必须保留原生引用或工具产物。

Multi-agent（Beta）

一个 GPT-5.6 实例可以并行协调多个子 Agent，再综合结果。适合可以清晰拆成独立工作流的复杂任务；不适合强依赖、无法并行的短任务。

显式 Prompt 缓存

• 可明确标记可复用 Prompt 前缀的缓存断点。
• 隐式缓存仍可继续使用。
• 显式缓存写入价格高于普通输入，读取有折扣；必须观察 cached_tokens 和 cache_write_tokens 后判断净收益。

持久化推理

• reasoning.context=auto：使用模型默认策略。
• all_turns：目标和假设长期稳定时，结合 previous_response_id 复用此前推理。
• current_turn：此前推理已无关时，只使用当前轮。

Max effort 与 Pro mode

• reasoning.effort 支持 none / low / medium / high / xhigh / max。
• reasoning.mode: "pro" 会增加模型内部工作，提升困难任务的可靠性，但增加延迟和成本。
• Pro mode 与 effort 独立，不存在单独的 Pro 模型名称。
• 只有代表性评测证明质量提升值得额外成本时才启用 Pro。

3. Prompting 最佳实践

3.1 Prompt 要更精简

官方内部编码 Agent 样例中，更精简的系统 Prompt 获得了更高评测分数，同时显著降低 Token 和成本；具体幅度因任务而异，不能直接外推。

执行方式：

1. 从已经可用的 Prompt 和工具集开始。
2. 每次只移除一组重复指令、示例或工具。
3. 在同一组代表性任务上复测。
4. 每条规则只写一次。
5. 只暴露当前任务需要的工具，描述保持短而精确。
6. 只有确实表达产品要求或修复已测问题的示例才保留。

不要为了“显得严谨”不断叠加同义规则。长会话会放大重复 Prompt 和工具说明的成本与干扰。

3.2 明确定义自主性和审批边界

模型需要知道一次请求授权到哪一步：

• 回答、解释、审查、诊断、规划：只检查和报告；除非用户同时要求修改，否则不实施。
• 修改、构建、修复：完成范围内本地改动并运行非破坏性验证，无需反复询问。
• 外部写入、破坏性操作、购买、明显扩展范围：必须确认。

把安全本地动作写清楚，例如读取文件、检查日志、编辑范围内代码和运行测试。审批规则集中放在一个位置，不要反复写“先问我”。

3.3 精确控制回答长度和语气

• 使用 text.verbosity=low / medium / high 设置默认细节等级。
• Prompt 只补充当前任务特有的篇幅、结构和必含内容。
• 要求短回答时，明确哪些内容不能删：结论、证据、重大限制和下一步。
• 优先删除重复背景、泛化安慰、套话和非必要铺垫。
• 不只写“友好”“有同理心”，应描述具体写法：直接回答、何时承认问题、是否需要安慰或结尾。

推荐表达：

先给结论。保留支撑结论的证据、重大限制和下一步行动。
优先删除重复、套话、泛化安慰和可选背景。

4. Pro mode 使用规则

适合：

• 复杂优化；
• 高价值代码实现或审查；
• 深度分析，且有明确验收标准；
• 边际质量提升会实质影响结果的任务。

不适合：

• 日常简单任务；
• 延迟敏感或高吞吐流程；
• 现有评测看不到明显收益的任务。

Prompt 仍应描述目标、上下文、约束、证据、成功标准和输出格式。无需在文本里要求“多想几遍”或生成多个候选答案。

评测标准：

• 任务是否成功；
• 答案是否完整；
• 必需证据是否齐全；
• 总 Token、延迟和成本；
• 相对标准模式是否有可测量收益。

5. PTC 路由模板

使用 PTC 时必须写清：

• 哪个边界明确的阶段交给 PTC；
• 允许调用哪些工具；
• 输出 schema 和必需证据；
• 并发、重试和停止条件；
• 哪些语义判断、审批或最终验证仍由普通调用完成。

可复用模板：

<tool_orchestration>
仅在【明确阶段】使用 Programmatic Tool Calling，并只调用【允许工具】。
安全时并行独立调用，只使用已记录的输入与输出字段。

压缩处理中间结果，最终严格输出【schema】，保留【必需证据】。
达到【停止条件】后停止；瞬时失败最多重试【R】次。
不要重复已完成调用，不执行有外部副作用的动作。

语义判断、审批与最终验证使用普通工具调用。
</tool_orchestration>

PTC 的 program_output 与最终 assistant message 是两个输出，必须分别检查。调用更少、Token 更低，只有在最终答案仍通过质量评测时才算优化。

6. 通用任务 Prompt 骨架

<goal>
最终要交付什么，以及用户真正想解决的问题。
</goal>

<context>
只提供完成任务需要的事实、文件、数据范围和已有结论。
</context>

<constraints>
不可违反的技术、安全、数据和格式约束；每条只写一次。
</constraints>

<autonomy>
允许直接执行的本地动作；
必须确认的外部、破坏性、付费或扩展范围动作。
</autonomy>

<success_criteria>
完成的可验证标准，以及必须运行的检查。
</success_criteria>

<output>
先给结论；保留证据、重大限制和下一步；删除重复与套话。
</output>

7. 对 VDR 项目的应用

文档与代码工作

• 保持 STATUS.md 为唯一状态源，不在多个文档重复同一批数字。
• 任务规则集中在 Cursor rule 与流程文档，避免每次 Prompt 重复。
• 修改任务直接完成范围内编辑、测试和文档同步；Cloudflare 发布属于外部写入，按既定发布工作流执行并记录链接。
• 子 Agent 仅用于能独立拆分的复杂搜索、交叉审计或并行方案，不为短任务增加编排成本。

数据分析与泄漏审计

• 图片/PDF 哈希、ID Join、批量匹配和聚合适合边界明确的程序化处理。
• 是否构成泄漏、是否允许训练等语义判断必须保留证据，并做最终人工/模型复核。
• 不能因为调用数下降就判定流程更好；最终审计覆盖率和误报/漏报才是核心指标。

模型迁移

• 从现有 reasoning effort 原档位开始，再测试低一档。
• medium 可作为质量与成本平衡起点；max 只用于最难、质量优先的任务。
• 当前 VDR 的 Qwen3.6-27B 合成链路不因本指南自动切换模型；任何迁移都应使用同一批样本比较格式、证据正确率、重复率、延迟和成本。

8. 上线前检查

• [ ] 每条指令只出现一次。
• [ ] 只提供当前任务需要的工具。
• [ ] 目标、约束、审批边界、成功标准明确。
• [ ] 回答长度由 text.verbosity 和任务要求共同控制。
• [ ] reasoning effort 有代表性评测，不盲目使用最高档。
• [ ] Pro mode 的质量提升足以抵消延迟和成本。
• [ ] PTC 只处理边界明确的批量流程。
• [ ] 最终答案与工具/程序输出分别验证。
• [ ] Prompt、模型、effort、质量、Token、延迟和成本均有记录。

9. 事实边界

• 官方文档中的内部评测提升和 Token/成本降幅是方向性参考，不保证在 VDR 工作负载上复现。
• Multi-agent 仍为 Beta，接口和行为可能变化。
• 模型、价格、缓存计费和 API 参数可能更新；实施前以官方页面为准。