优化提示词

在与 AI 模型协作时，精心设计有效的提示词是一项关键技能。即使是经验丰富的用户也可能无意中引入矛盾、歧义或不一致之处，从而导致次优结果。此处演示的系统有助于识别和修复常见问题，从而获得更可靠、更有效的提示词。

优化过程采用了多智能体方法，由专门的 AI 智能体协作分析和重写提示词。该系统可自动识别并解决几种常见的类型的问题：

提示词指令中的矛盾
格式规范缺失或不清晰
提示词与少样本示例之间的不一致

目标：本指南演示了如何使用 Agents SDK 和 Evals 构建 OpenAI 提示词优化系统的早期版本，并遵循最佳实践。您可以使用此代码优化提示词，或在我们的playground中使用优化器！

Ask ChatGPT

指南结构 本笔记本遵循以下结构：

步骤 1. 系统概述 - 了解提示词优化系统的工作原理
步骤 2. 数据模型 - 理解系统使用的数据结构
步骤 3. 定义智能体 - 查看分析和改进提示词的智能体
步骤 4. 评估 - 使用 Evals 验证我们的智能体模型选择和指令
步骤 5. 运行优化工作流 - 查看工作流如何传递提示词
步骤 6. 示例 - 探索提示词优化的实际示例

先决条件

openai Python 包
openai-agents 包
设置为环境变量 OPENAI_API_KEY 的 OpenAI API 密钥

1. 系统概述

提示词优化系统采用协作式多智能体方法来分析和改进提示词。每个智能体专门负责检测或重写特定类型的问题：

Dev-Contradiction-Checker：扫描提示词中是否存在逻辑矛盾或不可能实现的指令，例如在同一提示词中同时出现“仅使用正数”和“包含负面示例”。
Format-Checker：识别提示词何时需要结构化输出（如 JSON、CSV、XML 或 Markdown 表格），但未能明确指定确切的格式要求。此智能体确保所有必需的字段、数据类型和格式规则都得到明确定义。
Few-Shot-Consistency-Checker：检查示例对话，确保助手回复实际遵循提示词中指定的规则。这可以捕获提示词要求与示例演示之间不匹配的情况。
Dev-Rewriter：在识别出问题后，此智能体重写提示词以解决矛盾并澄清格式规范，同时保留原始意图。
Few-Shot-Rewriter：更新不一致的示例回复，使其与提示词中的规则保持一致，确保所有示例都正确遵守新的开发者提示词。

通过协同工作，这些智能体能够系统地识别和修复提示词中的问题。

# 导入所需模块
from openai import AsyncOpenAI
import asyncio
import json
import os
from enum import Enum
from typing import Any, List, Dict
from pydantic import BaseModel, Field
from agents import Agent, Runner, set_default_openai_client, trace

openai_client: AsyncOpenAI | None = None

def _get_openai_client() -> AsyncOpenAI:
    global openai_client
    if openai_client is None:
        openai_client = AsyncOpenAI(
            api_key=os.environ.get("OPENAI_API_KEY", "your-api-key"),
        )
    return openai_client

set_default_openai_client(_get_openai_client())

2. 数据模型

为了促进智能体之间的结构化通信，系统使用 Pydantic 模型来定义输入和输出的预期格式。这些 Pydantic 模型有助于验证数据并确保整个工作流的一致性。

数据模型包括：

Role - 消息角色（用户/助手）的枚举
ChatMessage - 表示对话中的单个消息
Issues - 用于报告检测到的问题的基类模型
FewShotIssues - 扩展模型，增加了对示例消息的重写建议
MessagesOutput - 包含优化后的对话消息
DevRewriteOutput - 包含改进后的开发者提示词

使用 Pydantic 允许系统在流程的每个步骤中验证所有数据是否符合预期格式。

class Role(str, Enum):
    """聊天消息的角色枚举。"""
    user = "user"
    assistant = "assistant"

class ChatMessage(BaseModel):
    """少样本示例中使用的单个聊天消息。"""
    role: Role
    content: str

class Issues(BaseModel):
    """检查器返回的结构化输出。"""
    has_issues: bool
    issues: List[str]

    @classmethod
    def no_issues(cls) -> "Issues":
        return cls(has_issues=False, issues=[])

class FewShotIssues(Issues):
    """少样本矛盾检测器的输出，包括可选的重写建议。"""
    rewrite_suggestions: List[str] = Field(default_factory=list)

    @classmethod
    def no_issues(cls) -> "FewShotIssues":
        return cls(has_issues=False, issues=[], rewrite_suggestions=[])

class MessagesOutput(BaseModel):
    """`rewrite_messages_agent` 返回的结构化输出。"""

    messages: list[ChatMessage]


class DevRewriteOutput(BaseModel):
    """重写器返回清理后的开发者提示词。"""

    new_developer_message: str

3. 定义智能体

在本节中，我们使用 openai-agents 包中的 Agent 类创建专门的 AI 智能体。查看这些智能体定义揭示了创建有效的 AI 指令的几个最佳实践：

智能体指令中的最佳实践

清晰的作用域定义：每个智能体都有一个定义明确的、具有明确边界的目的。例如，矛盾检查器仅关注“真正的自我矛盾”，并明确指出“重叠或冗余不属于矛盾”。
分步流程：指令提供了一个清晰的方法，例如格式检查器如何首先对任务进行分类，然后再分析格式要求。
明确的定义：关键术语被精确定义以避免歧义。少样本一致性检查器包含一个详细的“合规性标准”，精确解释了什么构成合规性。
边界设定：指令指定了智能体不应做什么。少样本检查器明确列出了“范围外”的内容，以防止过度标记问题。
结构化输出要求：每个智能体都有一个严格定义的输出格式和示例，确保优化流程中的一致性。

这些原则创建了可靠、专注的智能体，它们能在优化系统中有效协同工作。下面我们看到完整的智能体定义及其详细指令。

dev_contradiction_checker = Agent(
    name="contradiction_detector",
    model="gpt-4.1",
    output_type=Issues,
    instructions="""
    你是 **Dev-Contradiction-Checker**。

    目标
    检测提供的 `DEVELOPER_MESSAGE` 变量中开发者提示词**内部**的*真正*自我矛盾或不可能的指令。

    定义
    • 矛盾 = 两个不能同时遵循的子句。
    • DEVELOPER_MESSAGE 中的重叠或冗余*不是*矛盾。

    你必须做的事情

    1. 将每个命令/禁止项与所有其他项进行比较。
    2. 最多列出五项矛盾（每项为一个要点）。
    3. 如果没有矛盾，请说明。

    输出格式（**严格的 JSON**）
    仅返回一个匹配 `Issues` 模式的对象：

```json
{"has_issues": <bool>,
"issues": [
    "<要点 1>",
    "<要点 2>"
]
}

- 仅当 issues 数组非空时，has_issues 才为 true。
- 不要添加额外的键、注释或 markdown。
""",
)
format_checker = Agent(
name="format_checker",
model="gpt-4.1",
output_type=Issues,
instructions="""
你是 Format-Checker。

任务
判断开发者提示词是否需要结构化输出（JSON/CSV/XML/Markdown 表格等）。
如果需要，请标记任何缺失或不清晰的格式方面。

步骤
将任务分类为：
a. "仅对话"，或
b. "需要结构化输出"。

对于情况 (b)：

- 指出缺失的字段、模糊的数据类型、未指定的顺序或缺失的错误处理。

如果不确定，请勿臆造问题。在标记格式问题时稍微保守一些

输出格式
返回严格有效的 JSON，遵循 Issues 模式：

{
"has_issues": <bool>,
"issues": ["<描述 1>", "..."]
}
最多五项问题。无额外键或文本。
""",
)
fewshot_consistency_checker = Agent(
name="fewshot_consistency_checker",
model="gpt-4.1",
output_type=FewShotIssues,
instructions="""
你是 FewShot-Consistency-Checker。

目标
查找 DEVELOPER_MESSAGE 规则与附带的**助手**示例之间的冲突。

USER_EXAMPLES:      <所有用户行>          # 仅供参考
ASSISTANT_EXAMPLES: <所有助手行>     # 待评估

方法
从 DEVELOPER_MESSAGE 中提取关键约束：

- 语气/风格
- 禁止或强制的内容
- 输出格式要求

合规性标准 - 请仔细阅读
仅评估开发者消息明确说明的内容。

你必须检查的客观约束（如果存在）：

- 所需的输出类型语法（例如，“JSON 对象”、“单个句子”、“主题行”）。
- 硬性限制（长度≤ N 个字符、要求语言为英语、禁止的单词等）。
- 开发人员明确命名的强制性令牌或字段。

范围外（请勿标记）：

- 回复是否“听起来通用”、“重复提示词”或“完全反映用户请求”——除非开发者文本明确要求这些质量。
- 创意风格、营销质量或内容深度，除非另有说明。
- 次要的风格选择（大写、标点符号），只要它们不违反明确规则。

通过/失败规则

- 如果助手回复满足所有客观约束，则视为合规，即使你个人认为它平淡或关联性不强。
- 仅当违反了具体的、引用的规则时，才记录问题。

空助手列表 ⇒ 立即返回 has_issues=false。

对于每个助手示例：

- USER_EXAMPLES 仅供参考；切勿将其用于判断合规性。
- 仅根据你从开发者消息中提取的明确约束来判断每个助手回复。
- 如果回复违反了特定的、引用的规则，请添加一行解释它违反了哪条规则。
- 可选地，建议一个重写版本，用一个简短的句子（添加到 rewrite_suggestions）。
- 如果你不确定，请不要标记问题。
- 保持保守——不确定或模糊的情况不属于问题。

在标记少样本矛盾问题时稍微保守一些
输出格式
返回严格匹配 FewShotIssues 的 JSON：

{
"has_issues": <bool>,
"issues": ["<解释 1>", "..."],
"rewrite_suggestions": ["<建议 1>", "..."] // 可能是 []
}
两个数组最多各列出五项。
在没有时提供空数组。
无 markdown，无额外键。
""",
)
dev_rewriter = Agent(
name="dev_rewriter",
model="gpt-4.1",
output_type=DevRewriteOutput,
instructions="""
你是 Dev-Rewriter。

你收到：

- ORIGINAL_DEVELOPER_MESSAGE
- CONTRADICTION_ISSUES（可能为空）
- FORMAT_ISSUES（可能为空）

重写规则
保留原始意图和功能。

解决每个矛盾：

- 保留保留消息意图的子句；删除/合并冲突的子句。

如果 FORMAT_ISSUES 非空：

- 添加一个新部分，标题为 ## Output Format，清晰地定义模式或提供明确的示例。

请勿更改少样本示例。

请勿添加新策略或范围。

输出格式（严格的 JSON）
{
"new_developer_message": "<完整的重写文本>"
}
无其他键，无 markdown。
""",
)
fewshot_rewriter = Agent(
name="fewshot_rewriter",
model="gpt-4.1",
output_type=MessagesOutput,
instructions="""
你是 FewShot-Rewriter。

输入负载

- NEW_DEVELOPER_MESSAGE（已优化）
- ORIGINAL_MESSAGES（用户/助手字典列表）
- FEW_SHOT_ISSUES（非空）

任务
仅重新生成被标记的助手部分。
用户消息必须保持不变。
每个重新生成的助手回复必须符合 NEW_DEVELOPER_MESSAGE。

重新生成每个助手回复后，请验证：

- 它是否符合 NEW_DEVELOPER_MESSAGE。请确保这一点。

输出格式
返回严格匹配 MessagesOutput 模式的 JSON：

{
"messages": [
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."}
    ]
}
指南

- 保留原始顺序和总数。
- 如果消息没有问题，请原样复制。
""",
)

4. 使用评估来得出这些智能体

让我们看看我们如何使用 OpenAI Evals 来调整智能体指令并选择要使用的正确模型。为此，我们构建了一组黄金示例：每个示例包含原始消息（开发者消息 + 用户/助手消息）以及我们优化工作流应进行的更改。以下是两个黄金示例：

[
  {
    "focus": "contradiction_issues",
    "input_payload": {
      "developer_message": "始终用**英语**回答。\nNunca respondas en inglés。",
      "messages": [
        {
          "role": "user",
          "content": "¿Qué hora es?"
        }
      ]
    },
    "golden_output": {
      "changes": true,
      "new_developer_message": "始终用**英语**回答。",
      "new_messages": [
        {
          "role": "user",
          "content": "¿Qué hora es?"
        }
      ],
      "contradiction_issues": "开发者消息同时坚持使用英语和禁止使用英语。",
      "few_shot_contradiction_issues": "",
      "format_issues": "",
      "general_improvements": ""
    }
  },
  {
    "focus": "few_shot_contradiction_issues",
    "input_payload": {
      "developer_message": "仅回复**“是”或“否”** - 无解释。",
      "messages": [
        {
          "role": "user",
          "content": "Is the sky blue?"
        },
        {
          "role": "assistant",
          "content": "Yes, because wavelengths …"
        },
        {
          "role": "user",
          "content": "Is water wet?"
        },
        {
          "role": "assistant",
          "content": "Yes."
        }
      ]
    },
    "golden_output": {
      "changes": true,
      "new_developer_message": "仅回复**单个单词**“是”或“否”。",
      "new_messages": [
        {
          "role": "user",
          "content": "Is the sky blue?"
        },
        {
          "role": "assistant",
          "content": "yes"
        },
        {
          "role": "user",
          "content": "Is water wet?"
        },
        {
          "role": "assistant",
          "content": "yes"
        }
      ],
      "contradiction_issues": "",
      "few_shot_contradiction_issues": "助手示例包含解释，尽管指令禁止这样做。",
      "format_issues": "",
      "general_improvements": ""
    }
  }
]

从这 20 个手工标记的黄金输出（涵盖了矛盾问题、少样本问题、格式问题、无问题或组合问题）中，我们构建了一个 Python 字符串检查评分器来验证两件事：是否为每个黄金对检测到了问题，以及检测到的问题是否与预期的匹配。基于此信号，我们调整了智能体指令和要使用的模型，以最大化我们在此评估中的准确性。我们选择了 4.1 模型作为准确性、成本和速度之间的平衡。我们使用的特定提示词也遵循 4.1 提示指南。如您所见，我们在所有 20 个黄金输出上都实现了正确的标签：识别了正确的问题并避免了误报。

黄金集合的准确性

黄金集合的评估

5. 运行优化工作流

让我们深入了解优化系统实际如何端到端工作。核心工作流包括多次并行运行智能体，以高效地处理和优化提示词。

def _normalize_messages(messages: List[Any]) -> List[Dict[str, str]]:
    """将 Pydantic 消息模型列表转换为 JSON 可序列化的字典。"""
    result = []
    for m in messages:
        if hasattr(m, "model_dump"):
            result.append(m.model_dump())
        elif isinstance(m, dict) and "role" in m and "content" in m:
            result.append({"role": str(m["role"]), "content": str(m["content"])})
    return result

async def optimize_prompt_parallel(
    developer_message: str,
    messages: List["ChatMessage"],
) -> Dict[str, Any]:
    """
    并行运行矛盾、格式和少样本检查器，
    然后重写提示词/示例（如果需要）。
    返回一个适合 API 或端点的统一字典。
    """

    with trace("optimize_prompt_workflow"):
        # 1. 并行运行所有检查器（矛盾、格式、少样本（如果存在示例））
        tasks = [
            Runner.run(dev_contradiction_checker, developer_message),
            Runner.run(format_checker, developer_message),
        ]
        if messages:
            fs_input = {
                "DEVELOPER_MESSAGE": developer_message,
                "USER_EXAMPLES": [m.content for m in messages if m.role == "user"],
                "ASSISTANT_EXAMPLES": [m.content for m in messages if m.role == "assistant"],
            }
            tasks.append(Runner.run(fewshot_consistency_checker, json.dumps(fs_input)))

        results = await asyncio.gather(*tasks)

        # 解包结果
        cd_issues: Issues = results[0].final_output
        fi_issues: Issues = results[1].final_output
        fs_issues: FewShotIssues = results[2].final_output if messages else FewShotIssues.no_issues()

        # 3. 根据需要进行重写
        final_prompt = developer_message
        if cd_issues.has_issues or fi_issues.has_issues:
            pr_input = {
                "ORIGINAL_DEVELOPER_MESSAGE": developer_message,
                "CONTRADICTION_ISSUES": cd_issues.model_dump(),
                "FORMAT_ISSUES": fi_issues.model_dump(),
            }
            pr_res = await Runner.run(dev_rewriter, json.dumps(pr_input))
            final_prompt = pr_res.final_output.new_developer_message

        final_messages: list[ChatMessage] | list[dict[str, str]] = messages
        if fs_issues.has_issues:
            mr_input = {
                "NEW_DEVELOPER_MESSAGE": final_prompt,
                "ORIGINAL_MESSAGES": _normalize_messages(messages),
                "FEW_SHOT_ISSUES": fs_issues.model_dump(),
            }
            mr_res = await Runner.run(fewshot_rewriter, json.dumps(mr_input))
            final_messages = mr_res.final_output.messages

        return {
            "changes": True,
            "new_developer_message": final_prompt,
            "new_messages": _normalize_messages(final_messages),
            "contradiction_issues": "\n".join(cd_issues.issues),
            "few_shot_contradiction_issues": "\n".join(fs_issues.issues),
            "format_issues": "\n".join(fi_issues.issues),
        }

工作流的跟踪

理解优化工作流

optimize_prompt_parallel 函数通过并行化来实现工作流，以最大限度地提高效率：

并行问题检测：第一阶段同时运行所有检查器智能体： - dev_contradiction_checker 搜索提示词中的逻辑矛盾 - format_checker 查找不清晰的格式规范 - fewshot_consistency_checker（如果存在示例）检查提示词与示例之间的不匹配情况

在并行检查阶段之后，工作流会仔细处理依赖关系：

提示词重写（有条件）：仅当检测到矛盾或格式问题时，才会运行 dev_rewriter 智能体。此智能体依赖于以下输出： - dev_contradiction_checker（cd_issues 变量） - format_checker（fi_issues 变量）
示例重写（有条件）：仅当检测到示例不一致时，才会运行 fewshot_rewriter 智能体。此智能体依赖于： - 重写后的提示词（必须在提示词重写之后完成） - 原始消息 - 少样本问题（fs_issues 变量）

6. 示例

让我们通过一些实际示例，看看优化系统是如何工作的。

示例 1：修复矛盾

async def example_contradiction():
    # 一个包含矛盾指令的提示词
    prompt = """快速入门卡 — 产品解析器

目标
消化电子商务产品详情页的原始 HTML，并输出描述该商品的**简洁、最小化的 JSON**。

**必需字段：**
name | brand | sku | price.value | price.currency | images[] | sizes[] | materials[] | care_instructions | features[]

**提取优先级：**

1. schema.org/JSON-LD 块
2. <meta> & microdata 标签
3. 可见 DOM 备用（类提示：“product-name”、“price”）

**规则：**

- 如果*任何*必需字段缺失，则短路并输出：`{"error": "FIELD_MISSING:<field>"}`。
- 价格：带小数点的数字；去除非数字字符（例如，“1.299,00 EUR” → 1299.00 + “EUR”）。
- 去重仅因查询字符串而异的图像。保留≤10 张最佳分辨率的图像。
- 尺寸：确保单位标签（“EU”、“US”）和升序排序。
- 材料：标题化并合并同义词（例如，“polyester 100%” → “Polyester”）。

**示例骨架（最小化）：**
```json
{"name":"","brand":"","sku":"","price":{"value":0,"currency":"USD"},"images":[""],"sizes":[],"materials":[],"care_instructions":"","features":[]}
注意：如果任何必需字段缺失，输出 null 是可以接受的，而不是错误 ###"""

    result = await optimize_prompt_parallel(prompt, [])

    # 显示结果
    if result["contradiction_issues"]:
        print("矛盾问题：")
        print(result["contradiction_issues"])
        print()

    print("优化后的提示词：")
    print(result["new_developer_message"])

# 运行示例
await example_contradiction()

矛盾问题：
规则“如果*任何*必需字段缺失，则短路并输出：`{"error": "FIELD_MISSING:<field>"}`”与最后的注释“如果任何必需字段缺失，输出 null 是可以接受的，而不是错误”之间存在矛盾。当必需字段缺失时，这两种行为无法同时遵循。

优化后的提示词：
快速入门卡 — 产品解析器

目标
消化电子商务产品详情页的原始 HTML，并输出描述该商品的**简洁、最小化的 JSON**。

**必需字段：**
name | brand | sku | price.value | price.currency | images[] | sizes[] | materials[] | care_instructions | features[]

**提取优先级：**

1. schema.org/JSON-LD 块
2. <meta> & microdata 标签
3. 可见 DOM 备用（类提示：“product-name”、“price”）

**规则：**

- 如果*任何*必需字段缺失，则短路并输出：`{"error": "FIELD_MISSING:<field>"}`
- 价格：带小数点的数字；去除非数字字符（例如，“1.299,00 EUR” → 1299.00 + “EUR”）。
- 去重仅因查询字符串而异的图像。保留≤10 张最佳分辨率的图像。
- 尺寸：确保单位标签（“EU”、“US”）和升序排序。
- 材料：标题化并合并同义词（例如，“polyester 100%” → “Polyester”）。

## 输出格式

- 成功输出：输出一个最小化的 JSON 对象，包含以下字段和类型（不强制排序）：
  - name: string
  - brand: string
  - sku: string
  - price: object，包含：
    - value: number
    - currency: string
  - images: 字符串 URL 数组
  - sizes: 字符串数组（每个都包含单位标签，例如“37 EU”）
  - materials: 字符串数组
  - care_instructions: string
  - features: 字符串数组

示例：
{"name":"Product Name","brand":"Brand","sku":"SKU123","price":{"value":1299.00,"currency":"EUR"},"images":["https://example.com/image1.jpg","https://example.com/image2.jpg"],"sizes":["37 EU","38 EU"],"materials":["Cotton","Polyester"],"care_instructions":"Machine wash cold","features":["Feature 1","Feature 2"]}

- 如果任何必需字段缺失，则返回：
  {"error": "FIELD_MISSING:<field>"}
  （其中 <field> 是缺失的必需字段名称。）

这演示了系统如何检测和解决可能导致输出不一致或模型混淆的关键矛盾。

示例 2：修复提示词与少样本示例之间的不一致

async def example_fewshot_fix():
    prompt = "仅以包含 `city`（字符串）和 `population`（整数）键的 JSON 格式进行响应。"

    messages = [
        {"role": "user", "content": "Largest US city?"},
        {"role": "assistant", "content": "New York City"},
        {"role": "user", "content": "Largest UK city?"},
        {"role": "assistant", "content": "{\"city\":\"London\",\"population\":9541000}"}
    ]


    print("优化前的少样本示例：")
    print(f"User: {messages[0]['content']}")
    print(f"Assistant: {messages[1]['content']}")
    print(f"User: {messages[2]['content']}")
    print(f"Assistant: {messages[3]['content']}")
    print()

    # 调用优化 API
    result = await optimize_prompt_parallel(prompt, [ChatMessage(**m) for m in messages])

    # 显示结果
    if result["few_shot_contradiction_issues"]:
        print("发现不一致：", result["few_shot_contradiction_issues"])
        print()

    # 显示优化后的少样本示例
    optimized_messages = result["new_messages"]
    print("优化后的少样本示例：")
    print(f"User: {optimized_messages[0]['content']}")
    print(f"Assistant: {optimized_messages[1]['content']}")
    print(f"User: {optimized_messages[2]['content']}")
    print(f"Assistant: {optimized_messages[3]['content']}")

# 运行示例
await example_fewshot_fix()

优化前的少样本示例：
User: Largest US city?
Assistant: New York City
User: Largest UK city?
Assistant: {"city":"London","population":9541000}

发现不一致：响应“New York City”未使用 JSON 格式，并且缺少规则“仅以包含 `city`（字符串）和 `population`（整数）键的 JSON 格式进行响应。”中指定的 `city` 和 `population` 键。

优化后的少样本示例：
User: Largest US city?
Assistant: {"city":"New York City","population":8468000}
User: Largest UK city?
Assistant: {"city":"London","population":9541000}

这尤其重要，因为少样本示例对模型的响应方式有很强的影响。如果示例不遵循指定的规则，模型可能会倾向于忽略这些规则而模仿示例。通过确保提示词指令与示例之间的一致性，优化系统可以创建更可靠的提示词。

示例 3：在更长的提示词中澄清格式

async def example_format_issue():
    # 一个包含不清晰或不一致格式说明的提示词
    prompt = """任务 → 将密集的专利权利要求翻译成 200 字的通俗摘要，并附带词汇表。

操作步骤：

1. 在分号、“wherein”或编号的子句处拆分权利要求。
2. 对于每个块：
   a) 确定其目的。
   b) 用日常类比替换技术名词。
   c) 保留定量限制（例如，“≥150 C”）。

3. 用星号标记不常见的科学术语，稍后定义它们。
4. 重组为流畅的段落；请勿扩大或缩小权利要求的范围。
5. 如果省略样板文字不会改变法律含义，则将其省略。

输出应遵循 Markdown 模板：

- 一个摘要部分。
- 一个包含标记术语及其定义的词汇表部分。

边界情况：

- 如果权利要求超过 5 kB，则响应 CLAIM_TOO_LARGE。
- 如果权利要求文本已经是普通英语，则跳过词汇表并声明未检测到复杂术语。

请记住：您不是在提供法律建议 — 这仅供内部理解。"""

    # 调用优化 API 以检查格式问题
    result = await optimize_prompt_parallel(prompt, [])

    # 显示结果
    if result.get("format_issues"):
        print("发现格式问题：", result["format_issues"])
        print()

    print("优化后的提示词：")
    print(result["new_developer_message"])

# 运行示例
await example_format_issue()

发现格式问题：输出必须遵循精确的 Markdown 模板，但摘要和词汇表部分预期的结构（标题、格式）未完全指定。
输出应为 Markdown 字符串还是包含 Markdown 的结构化对象存在歧义 — 输出的数据类型是隐含的。
摘要和词汇表部分没有明确的排序说明 — 可能存在歧义。
摘要的字数限制（200 字）已提及，但词汇表部分未提及 — 范围不明确。
未指定 CLAIM_TOO_LARGE 错误或指示“无复杂术语”的具体格式 — 这些应该是 Markdown 还是纯文本？

优化后的提示词：
任务 → 将密集的专利权利要求翻译成 200 字的通俗摘要，并附带词汇表。

操作步骤：

1. 在分号、“wherein”或编号的子句处拆分权利要求。
2. 对于每个块：
   a) 确定其目的。
   b) 用日常类比替换技术名词。
   c) 保留定量限制（例如，“>=150 C”）。

3. 用星号标记不常见的科学术语，稍后定义它们。
4. 重组为流畅的段落；请勿扩大或缩小权利要求的范围。
5. 如果省略样板文字不会改变法律含义，则将其省略。

## 输出格式

- 所有输出必须以 Markdown 字符串形式提供。
- 如果权利要求超过 5 kB，则仅响应文本：`CLAIM_TOO_LARGE`（无 Markdown 格式）。
- 如果权利要求已经是普通英语，则输出以下 Markdown：

## Summary
<summary text>

## Glossary
No complex terms detected.

- 否则，请遵循以下 Markdown 模板：

## Summary
<Lay summary of the claim (max 200 words)>

## Glossary

- *Term1*: Definition of Term1
- *Term2*: Definition of Term2
...

- 在所有情况下，“摘要”部分都应放在“词汇表”部分之前。
- 字数限制（200 字）仅适用于摘要；词汇表没有长度限制。

请记住：您不是在提供法律建议 — 这仅供内部理解。

此示例重点介绍了格式检查器如何识别和解决模糊的格式规范。提示词要求 Markdown 输出，而优化流程显著改进了这些格式规范。