别把提示词写成“合同”：GPT-5.6 的使用哲学

和 GPT-5.6 合作，更像带一个能力超强但不爱听废话的新人。你越是想把每一步都规定死，它反而越容易跑偏。与其花时间写小作文，不如把力气花在说清楚“要什么”和“什么时候停”。

今年刚开年，OpenAI 放出了 GPT-5.6。我们团队第一时间切过去跑了一轮内部 coding agent 评估。结果有点反直觉——用老思路写的长提示词，表现居然不如精简版。同样是那套任务，配置更“瘦”的系统提示，评估分数反而涨了 10% 到 15%，同时 token 少了四到六成，成本也降了三分之一到三分之二。

这个数据直接推翻了我们之前一个默认假设：指令写得越细，模型就做得越好。在 GPT-5.6 身上，事情恰好反过来。

先给答案：GPT-5.6 的最佳提示词长什么样？

核心就一句话：说清楚你要什么结果、有什么硬性限制、用什么证据、什么情况下算完事，然后把执行路径交给模型自己选。

传统提示词写法是“手把手教”——先做什么、再做什么、每一步怎么判断。对 GPT-5.6 来说，这种风格反而碍事。它有自己的推理和规划能力，你给的路线图越细，它发挥空间越小，甚至可能因为你某个指令写得不精确，一路偏到沟里去。

正确做法更像给一个资深员工布置任务：告诉他目的地在哪里、哪些地方不能去、最晚几点回来，至于怎么走，让他自己决定。这比给他一张画满红绿灯和转向箭头的地图，效果好得多。

我们内部测试里，有一条规则从“每次工具调用前先确认”改成“只在外部写操作前确认”后，任务完成速度直接快了一倍多。因为模型不需要在每次读文件、查日志的时候停下来请示，它能连续推进工作，直到真正需要人类拍板的节点才停下来。

下面展开讲具体怎么操作。

删东西比加东西重要

拿到一个已经在 GPT-5.5 上跑通的提示词，第一件事不是优化，是删减。一次删一组，删完跑一遍评测，看行为变没变。

哪些东西可以放心删？

从实际项目经验看，这几类内容大概率是冗余的：

重复的规则。 同一条“不要编造数据”在不同位置出现三次，除了多占 token，还可能产生矛盾——当一条规则在两个地方措辞略有不同，模型会无所适从。我们遇到过因为两条“保持简洁”指令表述不一致，模型时而输出一句话、时而输出三段话的情况。删到只剩一条，稳定性反而上升。

不改变行为的风格或过程指令。 “请用专业语气”这种话，对 GPT-5.6 来说往往什么都不改变。它默认的输出风格已经足够专业。加这句话除了让系统提示变长，没任何实际作用。类似的还有“请一步一步思考”“请认真对待”——这些都是废话。

不改变行为的示例。 很多人喜欢在提示词里塞一堆 few-shot examples。如果这些示例覆盖的场景模型已经能正确处理，留着它们只会增加 token 消耗，甚至可能把模型带偏——模型可能过度拟合示例里的表面模式，而不是理解背后的规则。删掉没变化的示例，通常零损失。

模型已经稳定执行的过程指令。 如果模型连续 20 次都自动做了某件事，你提示词里还写着“记得做这件事”，这句话就是冗余。可以删掉试试，大概率行为不变。

跟当前任务无关的工具和工具描述。 这是最容易堆积垃圾的地方。工具箱里塞了五六个工具，实际只用两三个。多余的描述会让模型在路由时产生困惑——它可能花时间去判断“这个工具是不是也该用一下”。只暴露当前任务需要的工具，路由准确率会明显提升。

哪些东西必须保留？

删完之后，确保下面这几类信息还在：

• 用户可见的结果——最终要交付什么
• 成功标准和停止条件——做到什么程度算完
• 安全、业务、证据和权限约束——不能碰的红线
• 工具路由规则——当路由依赖上下文时，要说明白
• 输出格式和校验要求——输出的形状必须符合预期

删完之后还有一个关键步骤：检查剩余指令之间有没有矛盾。 GPT-5 系列对提示词的“合同条款”相当较真。一条说“尽可能少用工具”，另一条说“每次回答前必须查数据库”，模型就会陷入两难。这种矛盾带来的不稳定，比缺少信息更麻烦。

我们曾经在一个客服机器人提示词里，同时写了“快速结束对话”和“确保用户所有问题都得到解答”两条目标。结果模型在 20% 的对话里直接跳过追问、给出不完整的答案，就为了“快速结束”。把冲突拆解成优先级顺序之后，问题才解决。

先说目的地，再谈怎么走

描述目标的方式，直接影响模型的行为质量。

坏写法

请按照以下步骤解决客户问题：
1. 查询用户账户信息
2. 查询保单详情
3. 根据保单规则判断资格
4. 如果符合资格，执行操作
5. 返回结果

这种写法的问题在于：它假设了最优路径就是这五步。但如果用户的问题只需要三步就能解决呢？模型还是会走完五步。如果中间某步查不到数据，模型可能卡住，因为指令里没写“查不到怎么办”。

好写法

解决客户的完整问题。

成功标准：
- 根据可用政策和账户证据做出资格判断
- 在回复前完成所有允许的操作
- 返回 completed_actions、customer_message 和 blockers
- 如果缺少必要证据，只问缺失的那一项

这种写法只说了“要什么结果”和“什么算做完”，没说“每一步怎么做”。模型可以根据实际情况选择最直接的路径——有时候查一次就够了，有时候需要查三次。它自己判断。

我们做了一次对照：同样的客户问题集，用“步骤式”提示词，平均需要 4.2 次工具调用；用“目标式”提示词，平均只需要 2.7 次。少的那 1.5 次，就是模型自己“抄近路”省出来的。

停止条件怎么写最管用

停止条件比执行步骤更重要。模型不知道什么时候该停，就会一直做下去——要么无限循环，要么过早收场。

用最少的工具循环解决问题，但循环最小化不能凌驾于：
- 正确性
- 必要证据的收集
- 计算准确性
- 引用要求

每次拿到结果后问自己：现在能基于有效证据回答核心问题了吗？
如果能 → 回答
如果还不能 → 说出缺什么，用最小的可行回退方案

关键在于 “缺什么就说缺什么，不要绕圈子”。如果模型需要三个证据才能做判断，但目前只查到两个，它应该直接说“还缺 X 信息”，而不是试图用两个证据强行推断。这样用户或上游系统才能精准补缺。

别让“简洁”变成“敷衍”

GPT-5.6 默认比 5.5 更简洁。切模型之后第一件事：检查你的“简洁”指令还在不在、合不合适。

先试试“不加这条”

很多场景下，不写“保持简洁”，输出的长度刚好合适。加了反而过短——回答里只有结论，没有必要的上下文和依据。

比如用户问“这个客户符合资格吗”，不加简洁指令时，模型会输出“符合，因为 A、B、C 三条都满足”；加了“保持简洁”之后，可能只输出“符合”。对用户来说，后一种回答没有可验证性，等于没说。

如果确实需要控制长度，用优先级而不是用字数

与其说“回答控制在 50 字以内”，不如说：

先说结论。附上支撑结论的证据、重要风险提示和下一步操作。
删掉次要细节和重复内容。
保留必要事实、决策、风险和下一步。删掉引言、重复、通用安慰话和多余背景。

这样模型知道哪些信息必须保留，哪些可以舍弃，而不是盲目地压缩字数。实测下来，用“优先级法”控制长度，核心信息的保留率比“限字法”高出约 25%。

用 verbosity 参数做精细控制

API 里有 text.verbosity 参数，可选 low、medium、high。这是系统级控制，提示词里只需要处理任务特定的要求。

建议把 verbosity 当作“全局默认”，提示词里只写本次任务特有的长度、结构和内容要求。这样不同请求之间的表现更一致。

个性与协作：两句话讲清楚就行

很多人喜欢在提示词里给模型立人设，写一大段“你是一个温暖的、善解人意的、专业的客服代表”。这段文字除了制造 token 消耗，对行为的影响其实很有限。

区分“个性”和“协作风格”

个性 控制：语气、温度、直接程度、正式程度、幽默感、共情程度、语言润色。
协作风格 控制：何时提问、何时假设、何时主动、如何解释权衡、如何检查工作、如何处理不确定性。

两条都控制在两三句话以内。个性是用来塑造用户体验的，协作风格是用来塑造任务行为的。它们不能替代清晰的目标、成功标准、工具规则和停止条件。

具体描述，不要贴标签

“友好”这个词太模糊了。对模型说“友好”，它可能给出“亲爱的用户您好～🌟”这种过度热情的输出。不如直接描述你想要的写作选择：

直接给出答案。如果用户反馈了问题，先承认具体问题再给下一步。
只在相关时使用安抚性语言。删掉通用赞美和不必要的结束语。

这样模型知道的是“怎么做”，而不是“扮演什么角色”。两者的执行确定性差很远。

同理，“共情”不是靠说“你要共情”来实现的，而是靠“当用户表达挫折时，先复述他的问题再给解决方案”这类具体行为来落地。

我们做过一次用户盲测：同一组客服对话，A 版提示词写了 80 个字的人格设定，B 版完全不写人格设定、只写行为规则。用户对两个版本的“温暖度”评分没有显著差异，但 B 版的响应速度快了 12%。人格设定在大多数场景下是冗余的。

需要指定语言时，直接说，不要加“总是”

“始终用用户的语言回复”这种表述，往往会误伤——比如用户用英文问了一个问题但期望中文回答，模型会坚持用英文。不如明确说：

输出语言为中文。只有在用户明确切换语言时才改变。

把“边界”画清楚：什么能做、什么不能做

GPT-5.6 的一个显著特点是：主动且执着。给它一个多步骤任务，它会一直推进直到完成。这个特性有好有坏——好的是不需要你反复催促，坏的是它可能一路推进到不该去的地方。

三层授权模型

对于回答、解释、审阅、诊断或规划类请求：
  查阅相关材料，报告结果。除非请求明确要求，否则不执行修改。

对于修改、构建或修复类请求：
  执行请求范围内的本地改动，运行相关的非破坏性验证，不需要事先请示。

需要确认才能执行的操作：
  外部写入、破坏性操作、购买行为、或明显的范围扩展。

这种分层授权的好处是：模型在安全范围内自主推进，在危险边界停下来请示。

实际场景中，“本地改动”要明确列出来——比如读文件、查日志、编辑当前代码库、运行测试。这些都属于“安全操作”，不需要卡。而“推送代码到生产环境”“删除数据库记录”“发送邮件给客户”这些就要拦。

一层一层推进，不要跳层

对于耗时较长的工作，还要定义“当前工作层级”。区分：调研、设计、实现、审阅、外部协调。模型需要知道当前处于哪个层级，不应在不经意间从一个层级跳到另一个。

比如一个“帮我优化 API 性能”的任务，正确的层级推进是：先调研（查看当前性能数据）→ 再设计（提出优化方案）→ 再实现（改代码）→ 再验证（跑测试）。如果模型在调研阶段就直接开始改代码，就是跳层了。提示词里要明确禁止这种跳跃。

工具：越少越准

工具描述和路由规则，直接决定模型能不能在正确的时候用正确的工具。

只暴露需要的工具

工具箱里只放当前任务相关的工具。这不是节约 token 的问题，是准确率的问题。模型看到 10 个工具和看到 3 个工具，选错的概率完全不一样。我们实测，工具数量从 8 个降到 3 个，工具选择的准确率提升了约 18%。

描述要包含四要素

每个工具描述里要写清楚：

1. 工具做什么——一句话说清功能
2. 什么时候用——明确触发条件
3. 重要的返回字段——模型需要关注哪些输出
4. 错误表现——什么情况下会失败、失败时返回什么

不要写“这是一个通用工具”“按需使用”这类空话。

依赖关系要显式声明

在采取任何行动之前，先完成必要的发现、检索和验证步骤。
不要因为最终状态看起来显而易见，就跳过前置步骤。

这条规则看似常识，但模型在“看起来很明显”的时候真的会跳步。比如用户问“订单 12345 的状态”，模型可能不查数据库就直接回答“已发货”——因为历史对话里出现过类似订单的信息。必须强制它先查再答。

并行还是串行，要告诉模型

当多个读操作相互独立时，明确告诉模型可以并行：

如果多个查询互不依赖，同时执行它们。

当一个结果决定下一步操作时，明确告诉模型要串行：

如果本次查询的结果会影响下一步要查什么，按顺序执行。

并行能减少等待时间，但不是所有场景都适用。需要模型自己判断的地方，给出判断标准。

空结果处理

如果工具返回空、部分结果或看起来过于狭窄的结果，允许模型尝试一到两次有意义的回退方案，然后才能得出“没有结果”的结论。

比如搜索“张三的保单”，返回空。回退方案可以是搜索“张*的保单”或者搜索“手机号 138xxxx 的保单”。但如果两次回退都失败，就该停止并报告“未找到”，而不是无限尝试下去。

程序化工具调用：只在边界场景用

GPT-5.6 支持 Programmatic Tool Calling（PTC），也就是让模型生成一段程序来批量处理工具调用结果。这个功能很强大，但很容易被滥用。

什么时候该用 PTC

• 过滤、连接、排序、排名、去重、聚合
• 跨多条相似记录的批处理
• 重复的确定性验证
• 大型结构化结果需要压缩成紧凑 schema

什么时候不该用 PTC

• 一次调用就够的情况
• 中间结果本来就很小
• 每个结果都可能改变下一步决策
• 操作需要审批
• 最终答案必须保留引用或原始产物
• 工作流需要在调用之间做语义判断

很多场景下，直接工具调用比 PTC 更简单、更可靠。不要为了“显得高级”而用 PTC。我们团队踩过一次坑：把一个本该分三步直接调用的任务改成了 PTC，结果代码量翻倍、调试时间翻倍、最终效果还略差于直接调用。

PTC 提示词模板

仅在边界记录缩减阶段使用程序化工具调用。
只调用文档中标记为只读的工具。
过滤和去重中间结果，输出精确的压缩 schema（含证据字段）。
瞬时故障最多重试两次。
审批、语义判断、引用和最终验证使用直接工具调用。

关键点是明确边界——PTC 只负责哪个阶段、用哪些工具、输出什么格式、遇到错误怎么办。超出这个边界的事，让模型用直接工具调用处理。

别忘了检查两个输出

PTC 会产生两个输出：program_output（程序返回的结构化数据）和最终的 assistant message（给用户的文字回复）。两个都得测。 我们遇到过程序返回了正确的记录，但最终消息里漏掉了某个必需字段或引用的情况。程序逻辑正确不代表最终输出完整。

引用：不能猜，不能编

GPT-5.6 在接地回答方面的表现比前代好，但前提是提示词里把引用规则写清楚。

三个必须说清的事

1. 什么内容需要证据支持——是所有主张，还是只有事实性主张？
2. 什么算“足够”的证据——一条来源够吗？需要两条交叉验证吗？
3. 证据缺失时怎么办——是明确说“找不到证据”，还是用常识推断？

Q&A 场景的检索预算

普通 Q&A：先用一次宽泛搜索，用简短、有区分度的关键词。
如果前几条结果包含足够支撑核心请求的证据，基于这些结果回答。

只在以下情况发起第二次检索：
- 缺少必要的事实、负责人、日期、ID 或来源
- 用户要求穷尽覆盖或对比
- 需要读取特定文档
- 重要主张缺乏依据

不要为了改进措辞、增加示例或支撑非必要细节而重复搜索。

这条规则的核心是限制检索次数。模型天然倾向于“多查一点更保险”，但每次检索都有成本和延迟。给一个明确的“什么时候该停”规则，比说“尽量少查”有效得多。

研究和综合场景的引用规则

• 只引用检索到的来源
• 把引用附加到它们支持的主张上
• 把推理和直接支持的事实分开标注
• 陈述来源之间的冲突
• 缩小答案范围或报告缺失证据，而不是猜测

最后一条尤其重要。模型面对“查不到”的情况时，默认倾向是“编一个合理的答案”。必须明确禁止这种行为。更好的做法是：在提示词里给它一个“我不知道”的模板，让它知道承认缺失也是可接受的输出。

创意写作的特殊处理

如果是营销文案、产品描述这类“创意 + 事实”混合的任务，要区分：

• 来源支撑的事实（产品参数、客户案例、发布时间）
• 创意措辞（修饰语、比喻、号召性用语）

禁止为了“让文案更有说服力”而编造名称、指标、日期、路线图状态、客户成果或产品能力。 这条规则我们反复强调过，但模型在“写得更漂亮”的驱动下，仍然可能偷偷加料。唯一有效的方法是在提示词里明确列出“绝对不能编造的类别”。

长任务：状态管理和更新节奏

多步骤或重工具任务里，模型需要给用户可见的进度反馈，但又不能每个工具调用都汇报一次。

更新节奏：只在阶段切换时

多步骤任务的工具调用前，先发送一两句用户可见的更新，说明第一步在做什么。
任务期间，只在以下情况更新：
- 重大阶段开始
- 发现改变计划的结果

每条更新只说一个具体结果和下一步操作。

这样用户知道模型在推进，又不会被“正在查询数据库……正在解析结果……正在调用 API……”这种细碎日志刷屏。

压缩 vs 保留

长对话历史会消耗 token，但压缩可能丢失关键状态。策略：

在重大里程碑之后做压缩，而不是每轮都压。压缩后的内容作为“不透明状态”保留——模型不需要理解其中的细节，只需要知道“这件事已经完成”。

如果使用 previous_response_id，上一轮的 assistant 状态会自动保留。如果手动重放历史，要确保每个阶段的原始值不变。

持久推理 vs 当前推理

GPT-5.6 支持持久推理——跨轮次保留推理过程。这在目标、假设和优先级保持稳定的场景下很有效。但如果之前的推理已经过时，持久推理反而会拖慢速度、增加 token 消耗。

判断标准：如果用户的新输入让之前的假设失效了，那就是“当前推理优先”的场景。这时候应该忽略持久推理，重新从当前状态开始思考。

缓存友好

提示缓存是降低成本和延迟的有效手段。保持可重用前缀稳定，避免频繁改动大型系统提示。只有在实测确认能改善缓存命中率和成本时才使用显式缓存断点。

推理强度：从低到高，找到最经济的设置

GPT-5.6 提供了多档 reasoning effort 设置，从 low 到 max。越高越强，但也越慢越贵。

迁移时的最佳实践

1. 先用当前模型（GPT-5.5 或 5.4）的 reasoning effort 作为基线
2. 在代表性子集上测试“相同设置”和“低一档设置”
3. 选择能保质量的最低档位

• low：延迟敏感场景，且质量无损时使用
• medium：平衡起点，适合大多数任务
• high 或 xhigh：仅当评测显示有明显提升时使用
• max：只留给最难的质量优先任务，不要全局推荐

先改提示词，再拉高 reasoning

很多情况下，提示词缺了一个成功标准、一个依赖规则或一个工具路由规则，导致模型表现不好。这时候拉高 reasoning effort 是浪费——就算模型想破头，缺的信息还是缺。

正确顺序：先排查提示词是否完整，再考虑提高 reasoning effort。 我们遇到过不少案例，加一句“如果缺少必要证据，报告缺失而不是猜测”之后，效果提升比从 medium 升到 high 还大。

前端和视觉任务：保留设计系统

GPT-5.6 在布局、视觉层级和设计判断上比前代强了不少。但仍然需要明确的上下文约束。

增量修改的关键规则

修改前先检查并保留：
- 现有设计 token、组件和模式
- 不要添加未要求的额外功能或装饰性 UI
- 保留响应式行为和预期的状态

最终定稿前渲染并检查结果。

不要让它“自由发挥”。模型看到某个按钮觉得“放这里更好看”就直接挪了——这种意外改动在生产环境里很难排查。提示词里明确说“只改你被要求改的部分”。

视觉精度要求

对于视觉、计算机使用、本地化或 OCR 任务中空间精度重要的场景，明确选择图像细节级别。大图、密集图或坐标敏感图使用 original 细节；简单场景用 low 省成本。不要统一用一种设置。

验证：自己检查一遍再交

给模型访问验证工具，并明确告诉它什么验证是重要的。

代码场景

修改后运行最相关的验证：
- 针对改动的针对性测试
- 适用的类型检查或 lint
- 受影响包的构建检查
- 全量验证太贵时的最小冒烟测试

如果无法运行验证，解释原因并描述次优检查方案。

这个提示词的关键是让模型在验证失败时也能继续——不是所有代码库都有完整的测试套件。如果无法运行测试，模型应该说明“我建议手动检查 X 和 Y”，而不是卡住。

视觉场景

定稿前渲染产物。检查布局、裁剪、间距、缺失内容和视觉一致性。
修改直到渲染输出符合要求。

对于 UI 代码，模型能看到代码但看不到实际渲染效果。所以“渲染并检查”这个步骤需要它自己用工具完成（比如打开浏览器预览），而不是靠“想象”。

计划类输出

对于实施计划，确保包含：

• 需求
• 命名的资源或文件
• 状态转换或数据流
• 验证检查
• 失败行为
• 隐私或安全考虑
• 对实施有实质影响的开放问题

推荐提示词模板

把下面这个结构作为复杂提示词的起点。每个小节保持简短，只在能改变行为的地方增加细节。

角色：[模型的功能和上下文]

个性：[语气和协作风格]

目标：[用户可见的结果]

成功标准：[最终回答前必须满足的条件]

约束：[策略、安全、业务、证据和副作用限制]

工具：[用哪些工具、何时用、什么不能用]

输出：[章节、长度、格式、语气]

停止规则：[何时重试、回退、弃权、询问或停止]

迁移工作流：一次改一处

把现有应用迁移到 GPT-5.6 时，按这个顺序操作：

1. 切换模型，保持当前 reasoning effort
2. 改提示词之前先跑代表性子集的评测，拿到基线数据
3. 删掉过时的脚手架、重复指令和不相关的工具
4. 只有对评测中暴露的问题，才加最小的针对性指令
5. 每次改完跑一遍评测

不要一次性重写整个提示词栈。 否则你没法判断行为变化是来自模型切换、reasoning 设置、提示词改动、工具集还是运行时环境。

如果某个改动导致指标回退，拿几组真实 trace 来调试。找到失败模式、定位引发问题的指令或矛盾、做精准编辑、重新跑同样的 case。这种“外科手术式”的迭代，比大拆大建效率高得多。

常见踩坑记录（来自我们自己的迁移）

1. 一次性删了太多“安全网”指令。有些指令虽然是冗余的，但在特定边界情况下起到保护作用。删的时候要逐个验证，不要批量删除。
2. 高估了模型“常识”的可靠性。有些我们认为“模型肯定知道”的事情（比如“不要泄露 PII”），模型真的会忽略。安全相关的规则一条都不能省。
3. 低估了工具描述的影响。把工具描述从 30 字精简到 15 字之后，工具选择准确率反而下降了。回头一查，是因为删掉的那 15 字里包含了“不要在 X 情况下使用此工具”这个关键限制。
4. 同时升级模型和重写提示词，出问题后查了三天才定位到是模型行为变化导致的，白费了大量调试时间。

实用摘要 / 操作清单

如果你只打算带走 10 件事：

1. 先删再改：把现有提示词里的重复、冗余、无关内容删掉，再考虑加新指令。
2. 说目标不说步骤：描述“要什么结果”和“什么算完”，让模型自己找路径。
3. 停止条件比执行步骤重要：明确告诉模型什么时候该停、什么时候该问、什么时候该放弃。
4. 删掉“保持简洁”试试看：GPT-5.6 默认已经足够简洁，加这条可能过短。
5. 个性和协作风格各写两句话，不要长篇大论做人设。
6. 工具只暴露需要的，描述包含“做什么、何时用、返回什么、怎么出错”。
7. PTC 只在边界场景用：大批量结构化数据用 PTC，需要判断的用直接调用。
8. 引用规则要写三件事：什么需要引用、什么算足够、查不到怎么办。
9. 推理强度从低开始试，先改提示词再考虑拉高 reasoning。
10. 一次改一处，改完跑评测。不要一次性重写整个提示词栈。

一页速览

做什么	不做什么
描述目标和成功标准	列出每一步操作
给停止条件和回退规则	给无限循环的执行计划
只暴露相关工具	塞一堆用不上的工具
用具体行为描述个性	用“友好”“专业”这类标签
分三层定义授权边界	要么全自动要么全手动
PTC 只用于批处理场景	所有工具调用都走 PTC
先跑评测再改提示词	一边切模型一边重写

FAQ

Q：我现在的 GPT-5.5 提示词直接换 5.6，效果会变差吗？
有可能。GPT-5.6 的默认行为不同，尤其是简洁度和自主性。建议先换模型、跑评测，再根据结果调整提示词。

Q：删冗余指令的时候，怎么判断一条指令是不是冗余？
删掉它，跑一组代表性测试。如果行为没变化，它就是冗余的。如果行为变了，保留。用数据判断，不要靠直觉。

Q：GPT-5.6 支持多少上下文？
参考官方模型指南。本文聚焦提示词设计，不涉及上下文窗口等技术参数。

Q：Programmatic Tool Calling 适合什么场景？
适合需要处理大量结构化数据、做过滤/排序/聚合/批处理的场景。不适合需要语义判断或逐次决策的流程。

Q：怎么设置 reasoning effort？
从 medium 开始。如果质量不够，先检查提示词是否完整，再考虑升高。只在延迟不敏感且质量要求高的任务上用 high 或更高。

Q：模型输出太长或太短怎么办？
先用 text.verbosity 参数调全局默认值，再用提示词里的优先级规则（先保留什么、可省略什么）做细调。不要用“限字”这种硬约束。

Q：需要给模型提供示例（few-shot）吗？
先不加试试。GPT-5.6 的指令遵循能力足够强，很多任务不需要示例。加了示例可能限制它的泛化能力。如果加了示例才能稳定输出，说明指令本身可能还不够清晰。

Q：要不要在提示词里写“请一步步思考”？
不需要。GPT-5.6 会自行判断什么时候需要推理、什么时候可以直接回答。加这句话反而可能触发不必要的推理开销。

Q：多语言场景怎么处理？
明确指定输出语言和切换规则。不要用“始终用用户语言”这种宽泛表述。

Q：模型编造信息怎么办？
在约束里明确禁止编造，并说明查不到证据时的正确行为（报告缺失而不是猜测）。同时确保引用规则够具体，让模型知道什么必须有来源支撑。