一. 表达要直接明确GPT-4.1会逐字执行你的指令，所以你必须清楚地说出你想要的结果。具体一点。提示词模糊 = 回答模糊。
GPT-4.1 被训练得比以往的版本更严格地、更字面地执行指令，而不像之前的模型那样更宽松地从用户或系统的提示中推测意图。这也意味着，只要提示明确，GPT-4.1 的可控性和响应性都非常高——如果模型的行为与你预期不符，只需一句清晰明确地说明你期望的行
为，几乎总是足以让模型重新回到正确轨道上。

二. 做任务时请用“智能代理模式”如果你在构建机器人或智能代理：告诉它持续执行： ：“继
续完成任务，直到全部完成。不要半途而废。”告诉它可以用工具：“如果你不知道答案，就使用你的工具——不要猜。”你也可以加上规划指令：“在使用工具之前和之后，请先逐步思考。＂
持续性：
你是一个智能代理，请持续执行，直到用户的请求被完全解决后，再结束本轮回应并将控制权交还给用户。只有在你确认问题已经解决时，才可以结束你的回应。
调用工具：
如果你不确定用户请求所涉及的文件内容或代码结构，请使用你的工具读取文件并收集相关信息：不要猜测或编造答案。

三. 想要更强的逻辑推理?开口说出来 GPT-4.1默认并不会进行内部推理。但你可以引导它思考，比如说：“在回答前，请逐步思考。”这对做计划、做决策、解决复杂问题特别有帮
助。
规划：
在每次调用函数之前，你必须进行充分的规划，并在继续执行之前，深入反思上一次函数调用的结果。

四. 处理超长文档（支持 100 万 Tokens!)
GPT-4.1 可以处理非常长的输入内容。尽量把指令放在开头和结尾各一次。还要说明它是否应该只用输入的内容，还是也可以使用自身的知识：只使用输入内容时：“不要猜。如果资料里没有，就说‘我不知道’。”允许参考自身知识时：“请参考输入内容，但也可以补充简单的空白信息。

提示词结构安排
尤其是在使用长文本上下文时，指令和上下文的位置会影响模型的表现。如果你的提示词中包含较长的上下文，理想情况下应，因为我们发现这种方式。如果你只想放一次指令，那放在上下文比放在下方效果更好。

五. 链式思维提示法 遇到复杂问题时请使用：
比如说：“首先分解题目在问什么，然后列出需要的文档，最后总结答案。”用结构化的推理方法，把过程分成几步
理解问题 分析每份文档的相关性一基于最相关的信息做出判断。

此外，为其他模型优化过的现有提示词，可能无法直接适用于这个模型，因为在这个模型中，现有的指令会被更严格地执行，而那些隐含的规则则不会再被强烈地推断出来。

六. 精准执行指令的方法 专门写一个“#指令部分”。使用项目符号或编号列表。针对难以理解的要求提供真实的例子。如果模型行为出错，请检查：-是否有指令冲突-是否缺少示例-是否描述太多或太少
从整体上提供一个“响应规则”或“操作指令”部分，包含高层级的指导内容和项目符号说明。
如果模型行为仍未如预期那样运行，请按照以下步骤排查：

  1. 检查是否存在冲突的、不明确的或错误的指令和示例。如果存在冲突的指令，GPT-4.1
    通常会倾向于遵循提示词中靠近结尾的那一条。
  2. 添加能够展示期望行为的示例；确保示例中体现的任何重要行为，也在规则中明确说明。

七. 使用工具时，请通过 AI 字段添加 添加工具时，请使用 AP提供的专用字段（不要直接塞进提示词里）。工具名称要清晰，并简洁说明用途。用法示例请放在提示词末尾，不要放在工具说明内部。

与之前的模型相比，GPT-4.1 在如何高效使用工具方面接受了更多训练，这些工具会作为参数传递进 OpenAI 的API 请求中。我们鼓励开发者仅通过 tools 字段传递工具，而不要手动将工具描述写入提示词中，并单独为工具调用编写解析器（这是过去一些人采取的方法）。这种做法是减少错误并确保模型在调用工具时保持稳定输出的最佳方式——在我们的实验中，验证通过率提升了2%。

开发者应清晰命名工具以表明其用途，并在工具的“description”字段中添加清晰详细的说明。同样地，对于每个工具参数，也应采用良好的命名和描述，以确保正确使用。

如果你的工具结构复杂，并希望提供使用示例，我们建议你在系统提示词中创建一个“# Examples”部分，并将示例放在那里，而不要将它们添加进“description”字段中。描述部分应保持详尽但简洁。

提供示例有助于指明在什么情况下应使用工具，是否应在调用工具时加入用户文本，以及针对不同输入应使用哪些参数。
请记得，你可以在 Prompt Playground 中使用 “Generate Anything”功能，来为新的工具定义获取一个良好的起点。

八. 格式建议 分段、列清单请用 Markdown 格式。处理大量文档时，使用 XML 或结构化格式会更好。示例：这是内容 尽量避免用 JSON 处理超大输入，长文本下性能表现不佳。

  1. Markdown：我们建议从这里开始，并使用 Markdown 标题来划分主要部分和子部分（包括更深层级的结构，如H4+)。使用行内反引号或代码块反引号来精确包裹代码，并根据需要使用标准的编号或项目符号列表。
  2. XML：这也表现良好，并且我们已经在该模型中改进了对XML 信息的解析能力。XML 便于精确包裹一个完整部分（包括起始和结束），为标签添加元数据以提供额外上下文，并支持嵌套结构。以下是一个使用 XML 标签嵌套示例的案例，展示了输入和输出：
    、、


    San Francisco
    - SF

  3. JSON 结构严谨，并且在代码场景中模型理解良好。但它相对冗长，并需要进行字符转义，这可能会带来额外的处理负担。

九. 常见错误要避开 工具使用错误：模型可能在信息不足时调用工具。解决方法：“使用前先确认信息是否完整。”回答重复：如果你给了示例句子，它可能会照抄。解决方法：“请多样化你的回答。”解释太哕嗦：如果回答太长太碎，告诉它：“请简洁明了地回答。”

指示模型始终遵循特定行为有时可能会引发不良影响。例如，如果你告诉模型“在回应用户之前必须调用工具”，那么，或者在没有足够信息的情况下用空值调用工具。，可以缓解这种情况。

当提供示例短语时，模型可能会原封不动地使用这些语句，从而听起来对用户重复乏味。

如果没有具体指令，某些模型可能会过于主动地添加额外内容来解释其决策，或。提供清晰的指令和示例，有助于缓解这些问题。

标签: none

添加新评论