GPT-5 可操控性（Steering）

作为目前最易操控的模型，GPT-5 对提示中关于冗长度、语气及工具调用行为的指令极为敏感。

冗长度（Verbosity）

除了像上一代推理模型那样可调 reasoning_effort，GPT-5 还新增 API 参数 verbosity，用于控制最终答案的长度（而非思考链长度）。官方博客对此有更详尽说明。值得强调的是：虽然 API 级 verbosity 是全局默认，但 GPT-5 训练后支持在提示中用自然语言覆盖该默认值，以应对特定场景。上文 Cursor 的做法就是范例：全局设低冗长度，再单独对代码工具指定高冗长度。

指令遵循（Instruction following）

与 GPT-4.1 类似，GPT-5 对提示指令的遵循堪称“手术级”精准，使其能无缝嵌入各种工作流。然而，正因它“过于认真”，若提示本身存在矛盾或含糊，其危害比其他模型更大——它会花费大量推理 token 试图调和矛盾，而非随机选择一条执行。

下面给出一个“对抗性”示例，这类提示常破坏 GPT-5 的推理链：表面上看似一致，实则包含冲突指令。

“绝不在未获得患者明确同意（已记录在病历中）的情况下为其预约”

与

“作为降低风险的第一步，自动分配当日最早时段，无需联系患者”

互相矛盾。

提示接着要求：

“任何操作前必须先查患者档案，确认其为老患者”，

但又说：

“若症状显示高度紧急，立即升级为急诊，并指示患者拨打 911，此步骤优先于任何预约流程。”

CareFlow Assistant 指令（冲突已消除、逻辑一致版）


角色  
你是 CareFlow Assistant，一家医疗初创的虚拟管理员，负责根据优先级和症状为患者安排预约。


总体流程  
1. 先 lookup-patient 确认是老患者。  
2. 根据症状 → PriorityLevel（红 2 h、橙 24 h、黄 3 d、绿 7 d）。  
3. 若症状属于高紧急（红/橙）：  
   • 立即 escalate 为 EMERGENCY，指导患者拨打 911，**不再继续后续步骤**。  
4. 非紧急患者：  
   • find-provider → 匹配网络内医生。  
   • 验证保险、首选诊所、病历中是否已记录明确同意。  
   • 若同意状态未知：先 schedule-appointment（tentative hold），再 notify-patient 要求确认。  
   • 若无合适时段：waitlist-add + notify-patient。  


工具  
schedule-appointment | modify-appointment | waitlist-add | find-provider | lookup-patient | notify-patient


关键规则  
• 红/橙紧急：直接 911，**不 lookup，不预约**。  
• 非紧急：必须 lookup-patient 后才行动。  
• 无明确同意 → 不得最终确认预约（可先占槽）。

通过消除指令层级冲突，GPT-5 的推理变得更高效、性能更优。我们采取了以下两项关键修正：

• 将“先自动分配当日最早时段再联系患者”改为“先通知患者再自动分配当日最早时段”，使其与“仅在获得同意后才正式预约”保持一致。
• 新增“在紧急情况下无需查询患者档案，直接引导拨打 911”，让模型明确在紧急场景可跳过 lookup-patient 步骤。

我们深知提示工程是一个持续迭代的过程，许多提示文档会由不同利益方不断更新；正因如此，更需要彻底审查其中措辞不当或自相矛盾的地方。已有大量早期用户在复盘核心提示库时发现了类似歧义，修正后 GPT-5 的表现立刻大幅简化并提升。建议使用我们的提示优化器工具进行测试，以快速识别并修复这类问题。