想要 JSON 却得到废话？Prompt 工程的三大核心技巧

你希望得到 JSON，模型却给了一段解释文字；你要求表格化输出，它偏要自由发挥；你设计好了工具调用格式，它却说”我会调用 search 工具”——然后输出纯文本。

这不是模型能力的问题，是 Prompt 设计的问题。

做 Agent、自动化流程、知识库问答时，最头疼的往往不是模型”不够聪明”，而是输出格式飘忽不定、行为不可控。下游要解析 JSON、要触发工具、要入库——模型不按格式来，整个链路就断了。

本篇讲三个可落地的技巧：明确角色、思维链进阶、结构化输出。掌握它们，你就能让模型稳定产出可解析的结果。

💡 Prompt 工程是什么，不是什么？

在深入技巧之前，我们需要先澄清一个关键问题：什么是 Prompt 工程？

常见的误解

很多人以为 Prompt 工程就是：

多写一点 — 把问题描述得更详细
描述清楚一点 — 用更准确的语言表达需求
提示模型输出你想要的内容 — 告诉模型”请输出 JSON”

这些做法有一定效果，但不是真正的 Prompt 工程。

Prompt 工程的真正内涵

真正的 Prompt 工程是一个系统化的工程方法，包含以下维度：

类别	说明	对应本篇技巧
角色定位	明确模型应该以谁的身份工作	技巧一：明确角色（Persona Defining）
任务描述	清晰、结构化地说明任务是什么，不是什么	贯穿所有技巧
输入格式	明确用户会提供什么格式的数据	技巧三：结构化输出保障（分隔符）
输出格式	强制模型使用特定结构输出（JSON、表格等）	技巧三：结构化输出保障（Schema）
推理约束（Chain-of-Thought）	控制思考过程，为模型提供思路或限制思路	技巧二：思维链进阶（ReAct）
抗偏差与抗幻觉设计	明确禁止模型编造、要求引用来源、允许拒答	技巧一：明确角色（限制条件）
错误恢复机制	当输入异常时如何自我修正	技巧二：思维链进阶（Self-Correction）

💡 核心理解：Prompt 工程不是技巧，是规范化 + 工程化。

规范化：用统一的标准和模板设计 Prompt

工程化：考虑边界情况、错误处理、可维护性

这就像写代码一样：

❌ 不是：想到什么写什么，能跑就行
✅ 而是：遵循规范、考虑异常、可测试、可维护

🎯 三大核心技巧概览

基于 Prompt 工程的内涵，本篇将介绍 三大核心技巧，帮助你获得稳定、可解析的结构化输出：

明确角色（Persona Defining） — 让模型”入戏”，聚焦专业领域
- 对应：角色定位、抗偏差设计
思维链进阶（Advanced CoT / ReAct） — 外化思考过程，实现可控决策
- 对应：推理约束、错误恢复机制
结构化输出保障（Schema + 分隔符） — 确保机器可读、程序可解析
- 对应：输入格式、输出格式

👑 技巧一：明确角色（Persona Defining）

定义一个清晰、专业的角色，是高质量输出的第一步。

为什么定义角色很重要？

聚焦领域：让模型扮演”资深测试架构师”，它会使用更专业的术语和逻辑。
约束语气：确保输出专业、简洁、不冗长。
减少幻觉：专业角色能减少随意编造信息的可能。

角色定义要点

要点	描述	示例
身份	具体且权威	“你是一位经验丰富的 Python 后端工程师。”
目标	唯一任务目标，消除歧义	“你的目标是生成符合 PEP 8 的代码。”
限制	明确禁止或必须遵守的行为	“禁止在代码块之外添加任何解释性文字。”

完整示例：

System Prompt:
你是一位经验丰富的测试架构师，专注于自动化测试和测试平台开发。

你的职责是：
1. 设计清晰、可维护的测试用例
2. 提供符合最佳实践的测试方案
3. 使用专业术语，保持输出简洁

限制：
- 禁止使用模糊或不确定的表达
- 禁止在代码示例中添加注释（除非必要）
- 输出必须结构化（使用 Markdown 表格或列表）

User Prompt:
请为"用户注册功能"设计测试用例。

模型输出（更专业、更结构化）：
## 测试用例设计

| 用例ID | 测试场景 | 前置条件 | 测试步骤 | 预期结果 |
|--------|---------|---------|---------|---------|
| TC001 | 正常注册 | 无 | 1. 打开注册页面<br>2. 输入有效信息<br>3. 点击注册 | 注册成功，跳转登录页 |
| TC002 | 邮箱已存在 | 邮箱已注册 | 1. 输入已注册邮箱<br>2. 点击注册 | 提示"邮箱已存在" |
...

🔧 实战提示：

将角色定义放在 System Prompt 中，以赋予最高权重和持续性

身份要具体：避免”你是一个助手”这样的模糊表达，改为”你是一位测试架构师”

目标要唯一：一个角色只负责一个核心任务，避免职责混乱

限制要明确：用”禁止”、”必须”等明确词汇，避免模糊表达

🔗 技巧二：思维链进阶（Advanced CoT / ReAct）

在复杂任务中，单纯的 Prompt 可能不够。

ReAct（Reasoning + Acting） 能让 LLM 在行动前先思考，再执行工具调用，实现闭环决策。

ReAct 步骤

步骤	内容	作用
Thought	分析任务，决定下一步	激活内部逻辑，将复杂任务拆解
Action	决定调用工具或执行函数	明确执行路径，如 `Search(Query)`
Observation	接收工具结果	为下一次 Thought 提供输入，形成反馈闭环

Prompt 模板示例

你需要按照以下格式输出：

Thought: [你的思考]

Action: [调用的工具名(参数)]

Observation: [工具返回结果]

...重复此循环，直到得到最终答案

Final Answer: [最终答案]

实际应用示例：

System Prompt:
你是一个测试自动化助手，可以通过调用工具来执行测试任务。

User Prompt:
请检查 API 接口 /api/users 是否正常。

模型输出：
Thought: 我需要先调用 API 检查工具来测试这个接口。

Action: check_api(url="/api/users", method="GET")

Observation: {"status": 200, "response_time": 120ms, "data": [...]}

Thought: API 返回 200 状态码，响应时间正常，接口工作正常。

Final Answer: API 接口 /api/users 工作正常，状态码 200，响应时间 120ms。

CoT 与自我修正（Self-Correction）

当 Observation 阶段出现错误，可在下一次 Thought 中要求模型识别并修正错误：


Thought: 上一步调用 API 失败，返回 404，原因是缺失参数"ID"。我需要重新规划 Action，补充缺失参数。

🔹 这让复杂任务更可控，避免错误累积。

自我一致性检查（Self-Consistency）

对于需要高准确性的任务（如代码生成、数学计算），可以要求模型生成多个答案，然后选择最一致的：

System Prompt:
你是一个代码审查助手。对于每个代码片段，请生成 3 个不同的审查意见，然后选择最一致、最准确的作为最终答案。

输出格式：
审查意见1: [意见]
审查意见2: [意见]
审查意见3: [意见]
最终审查意见: [选择最一致的]

💡 适用场景：适合需要高准确性的任务，但会增加 Token 消耗，需要权衡成本。

🧱 技巧三：确保结构化输出（Schema + 分隔符）

这是最关键的一环，尤其当下游程序需要 JSON / YAML / XML 时。

核心方法：使用 Schema 约束

定义：Schema 描述输出数据结构（JSON Schema、Pydantic 等）
作用：不仅告诉模型”输出 JSON”，还规定字段名、类型、必选项

示例

步骤	方法	Prompt 片段
1. 格式声明	明确仅输出 JSON	“你的输出必须且只能是 JSON 格式，不要添加任何解释性文字。”
2. 注入 Schema	将 JSON Schema 文本加入 Prompt	`{"type":"object","properties":{"user_id":{"type":"integer"},"task_list":{"type":"array","items":{"name":"string","status":"string"}}}}`
3. 使用工具	高级：调用 `function_call` / `tool_call`	模型直接输出符合 Schema 的函数对象

完整示例：

System Prompt:
你是一个测试用例生成器。你的输出必须且只能是 JSON 格式，不要添加任何解释性文字。

输出格式必须符合以下 Schema：
{
  "type": "object",
  "properties": {
    "test_cases": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {"type": "integer"},
          "title": {"type": "string"},
          "steps": {"type": "array", "items": {"type": "string"}},
          "expected": {"type": "string"}
        },
        "required": ["id", "title", "steps", "expected"]
      }
    }
  }
}

User Prompt:
为"用户登录功能"生成 3 个测试用例。

模型输出（仅 JSON）：
{
  "test_cases": [
    {
      "id": 1,
      "title": "正常登录",
      "steps": ["打开登录页面", "输入正确用户名和密码", "点击登录按钮"],
      "expected": "登录成功，跳转到首页"
    },
    {
      "id": 2,
      "title": "错误密码登录",
      "steps": ["打开登录页面", "输入正确用户名和错误密码", "点击登录按钮"],
      "expected": "显示错误提示：密码错误"
    },
    {
      "id": 3,
      "title": "空用户名登录",
      "steps": ["打开登录页面", "不输入用户名，只输入密码", "点击登录按钮"],
      "expected": "显示错误提示：用户名不能为空"
    }
  ]
}

💡 关键点：

明确格式要求：在 System Prompt 中强调”仅输出 JSON”

提供完整 Schema：不仅告诉模型”输出 JSON”，还要规定字段名、类型、必选项

禁止解释文字：避免模型在 JSON 前后添加说明

使用分隔符

分隔符帮助模型专注核心任务，区分指令、上下文和用户输入：


请总结 <<<用户输入>>> 中的内容，并以 YAML 输出摘要和关键词。

<<<用户输入>>>

[用户粘贴的文本]

<<<END>>>

🏗️ 工程化实践：从技巧到系统

掌握了三大核心技巧后，我们需要将 Prompt 设计工程化，实现可复用、可维护、可测试。

核心检查清单：角色是否明确？输出格式是否用 Schema/分隔符约束？是否有 Few-Shot 示例？边界与异常是否有说明？

模板工程（Template Engineering）

将 Prompt 设计成可复用、可维护的模板，就像代码中的函数一样。

为什么需要模板？

一致性：确保相同任务使用相同的 Prompt 结构
可维护性：修改模板即可影响所有使用该模板的地方
可测试性：可以针对模板进行测试和优化

模板设计示例：

# Prompt 模板
TEST_CASE_TEMPLATE = """
你是一位经验丰富的测试架构师。

任务：为以下功能设计测试用例

功能名称：{feature_name}
功能描述：{feature_description}

输出格式：必须符合以下 JSON Schema
{schema}

约束：
- 禁止使用模糊或不确定的表达
- 测试用例必须覆盖正常流程和异常流程
- 每个测试用例必须包含：id、title、steps、expected
"""

# 使用模板
prompt = TEST_CASE_TEMPLATE.format(
    feature_name="用户登录",
    feature_description="用户通过用户名和密码登录系统",
    schema=json.dumps(test_case_schema)
)

工程化结构（Prompt as Code）

什么是 Prompt as Code？

就像写代码一样管理 Prompt：模块化、版本控制、可测试、可复用。

💡 比喻理解：

传统方式：每次都在聊天框里写 Prompt，像写临时脚本

Prompt as Code：把 Prompt 写成代码文件，像写正式项目

为什么要这样做？

可复用：一次写好，多处使用
可维护：修改一处，全局生效
可测试：验证 Prompt 效果，确保质量
可协作：团队共享，统一标准

1. 模块化设计：像搭积木一样组合 Prompt

问题：如果每个 Prompt 都写完整的角色、约束、格式，会重复且难维护。

解决：把 Prompt 拆成小模块，按需组合。

示例：

# 第一步：创建可复用的组件（像函数一样）

# prompts/components/persona.py
# 角色定义模块
PERSONA_TEST_ARCHITECT = "你是一位经验丰富的测试架构师，专注于自动化测试和测试平台开发。"

# prompts/components/constraints.py
# 约束条件模块
CONSTRAINT_NO_HALLUCINATION = "禁止编造信息，如果信息不确定，请明确说明'信息不足'。"

# prompts/components/format.py
# 输出格式模块
FORMAT_JSON_ONLY = "你的输出必须且只能是 JSON 格式，不要添加任何解释性文字。"

# 第二步：组合成完整的 Prompt（像调用函数一样）

# prompts/templates/test_case.py
from prompts.components import (
    PERSONA_TEST_ARCHITECT, 
    CONSTRAINT_NO_HALLUCINATION,
    FORMAT_JSON_ONLY
)

def build_test_case_prompt(feature_name, feature_description, schema):
    """构建测试用例生成的 Prompt"""
    return f"""
{PERSONA_TEST_ARCHITECT}

{CONSTRAINT_NO_HALLUCINATION}

{FORMAT_JSON_ONLY}

任务：为以下功能设计测试用例

功能名称：{feature_name}
功能描述：{feature_description}

输出格式必须符合以下 Schema：
{schema}
"""

# 第三步：使用（像调用 API 一样简单）

prompt = build_test_case_prompt(
    feature_name="用户登录",
    feature_description="用户通过用户名和密码登录系统",
    schema=json.dumps(test_case_schema)
)

好处：

✅ 修改角色定义时，只需改 persona.py，所有使用该角色的 Prompt 都会更新
✅ 可以轻松替换组件：把 PERSONA_TEST_ARCHITECT 换成 PERSONA_DEVELOPER
✅ 代码清晰，易于理解

2. 版本控制：记录 Prompt 的演进历史

问题：Prompt 改来改去，不知道哪个版本效果好。

解决：像代码一样，用版本号管理 Prompt。

示例：

# prompts/v1/test_case_generator.py
# 第一版：简单版本
SYSTEM_PROMPT_V1 = """
你是一个测试用例生成器。
请为指定功能生成测试用例。
"""

# prompts/v2/test_case_generator.py
# 第二版：增加了角色和约束
SYSTEM_PROMPT_V2 = """
你是一位经验丰富的测试架构师。
请为指定功能生成测试用例。
禁止使用模糊表达。
"""

# prompts/v3/test_case_generator.py
# 第三版：增加了格式要求
SYSTEM_PROMPT_V3 = """
你是一位经验丰富的测试架构师。
请为指定功能生成测试用例。
禁止使用模糊表达。
输出必须是 JSON 格式。
"""

# 使用时可以选择版本
def get_prompt(version="v3"):
    if version == "v1":
        return SYSTEM_PROMPT_V1
    elif version == "v2":
        return SYSTEM_PROMPT_V2
    else:
        return SYSTEM_PROMPT_V3

好处：

✅ 可以对比不同版本的效果
✅ 如果新版本有问题，可以快速回退到旧版本
✅ 记录 Prompt 的改进历程

3. 测试：确保 Prompt 质量

问题：Prompt 改完后，不知道效果如何。

解决：像测试代码一样，测试 Prompt 的输出。

示例：

# tests/test_prompts.py
import json

def test_test_case_prompt():
    """测试：验证 Prompt 生成的测试用例是否符合要求"""
    
    # 1. 构建 Prompt
    prompt = build_test_case_prompt(
        feature_name="用户登录",
        feature_description="用户通过用户名和密码登录系统",
        schema=json.dumps(test_case_schema)
    )
    
    # 2. 调用 LLM
    result = call_llm(prompt)  # 假设这是调用 LLM 的函数
    
    # 3. 验证输出格式（确保是有效的 JSON）
    assert validate_json_schema(result, TEST_CASE_SCHEMA)
    
    # 4. 验证内容完整性（确保至少生成了 3 个测试用例）
    assert len(result["test_cases"]) >= 3
    
    # 5. 验证每个测试用例都有必要字段
    for test_case in result["test_cases"]:
        assert "id" in test_case
        assert "title" in test_case
        assert "steps" in test_case
        assert "expected" in test_case
        assert len(test_case["steps"]) > 0  # 步骤不能为空
    
    print("✅ 测试通过：Prompt 输出符合要求")

# 运行测试
if __name__ == "__main__":
    test_test_case_prompt()

好处：

✅ 修改 Prompt 后，运行测试就知道是否破坏了功能
✅ 可以对比不同版本的效果（A/B 测试）
✅ 确保 Prompt 质量稳定

💡 最佳实践：

使用配置文件：将 Prompt 模板存储在 YAML/JSON 中，便于非技术人员修改

A/B 测试：对比不同版本的 Prompt 效果

监控与日志：记录 Prompt 的使用情况和效果，持续优化

🎯 完整实战案例：三大技巧综合应用

让我们通过一个完整的案例，看看如何将三大技巧结合起来，解决一个实际问题。

场景：自动生成测试用例

需求：根据功能描述，自动生成结构化的测试用例 JSON。

挑战：

输出格式必须严格符合 JSON Schema
需要覆盖正常流程和异常流程
测试步骤要清晰、可执行
需要处理边界情况

解决方案：结合三大技巧

第一步：明确角色（Persona Defining）

System Prompt:
你是一位经验丰富的测试架构师，专注于自动化测试。

你的职责：
1. 设计清晰、可维护的测试用例
2. 确保测试用例覆盖正常流程和异常流程
3. 使用专业术语，保持输出简洁

限制：
- 禁止使用模糊或不确定的表达（如"应该"、"可能"）
- 禁止编造不存在的功能点
- 如果信息不足，请明确说明"信息不足，无法生成完整测试用例"

第二步：结构化输出（Schema + 分隔符）

输出格式：必须且只能是 JSON 格式，不要添加任何解释性文字。

输出必须符合以下 Schema：
{
  "type": "object",
  "properties": {
    "feature_name": {"type": "string"},
    "test_cases": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {"type": "integer"},
          "title": {"type": "string"},
          "priority": {"type": "string", "enum": ["高", "中", "低"]},
          "precondition": {"type": "string"},
          "steps": {
            "type": "array",
            "items": {"type": "string"}
          },
          "expected": {"type": "string"}
        },
        "required": ["id", "title", "priority", "steps", "expected"]
      }
    }
  },
  "required": ["feature_name", "test_cases"]
}

第三步：使用分隔符明确输入

User Prompt:
请为以下功能设计测试用例：

<<<功能描述>>>
功能名称：用户登录
功能描述：
- 用户通过用户名和密码登录系统
- 用户名支持邮箱和手机号两种格式
- 密码长度要求 6-20 位
- 连续 5 次密码错误后，账户将被锁定 30 分钟
<<<END>>>

要求：
- 至少生成 5 个测试用例
- 必须覆盖正常登录、错误密码、账户锁定等场景
- 测试步骤要清晰、可执行

第四步：思维链（ReAct）处理复杂场景

如果功能描述复杂，可以要求模型先分析，再生成：

System Prompt（增强版）:
你是一位经验丰富的测试架构师。

请按照以下步骤工作：

1. 分析功能描述，识别需要测试的场景
2. 为每个场景设计测试用例
3. 确保测试用例覆盖正常流程和异常流程

输出格式：
Thought: [分析功能，识别测试场景]
Test Cases: [JSON 格式的测试用例]

最终输出必须是有效的 JSON，符合以下 Schema：
{...schema...}

完整 Prompt 示例

System Prompt:
你是一位经验丰富的测试架构师，专注于自动化测试。

职责：
1. 设计清晰、可维护的测试用例
2. 确保测试用例覆盖正常流程和异常流程
3. 使用专业术语，保持输出简洁

限制：
- 禁止使用模糊或不确定的表达
- 禁止编造不存在的功能点
- 如果信息不足，请明确说明"信息不足"

输出格式：必须且只能是 JSON 格式，不要添加任何解释性文字。

输出必须符合以下 Schema：
{
  "type": "object",
  "properties": {
    "feature_name": {"type": "string"},
    "test_cases": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {"type": "integer"},
          "title": {"type": "string"},
          "priority": {"type": "string", "enum": ["高", "中", "低"]},
          "precondition": {"type": "string"},
          "steps": {"type": "array", "items": {"type": "string"}},
          "expected": {"type": "string"}
        },
        "required": ["id", "title", "priority", "steps", "expected"]
      }
    }
  },
  "required": ["feature_name", "test_cases"]
}

User Prompt:
请为以下功能设计测试用例：

<<<功能描述>>>
功能名称：用户登录
功能描述：
- 用户通过用户名和密码登录系统
- 用户名支持邮箱和手机号两种格式
- 密码长度要求 6-20 位
- 连续 5 次密码错误后，账户将被锁定 30 分钟
<<<END>>>

要求：
- 至少生成 5 个测试用例
- 必须覆盖正常登录、错误密码、账户锁定等场景

预期输出

{
  "feature_name": "用户登录",
  "test_cases": [
    {
      "id": 1,
      "title": "正常登录-使用邮箱",
      "priority": "高",
      "precondition": "用户已注册，邮箱已验证",
      "steps": [
        "打开登录页面",
        "输入正确的邮箱地址",
        "输入正确的密码（6-20位）",
        "点击登录按钮"
      ],
      "expected": "登录成功，跳转到首页"
    },
    {
      "id": 2,
      "title": "正常登录-使用手机号",
      "priority": "高",
      "precondition": "用户已注册，手机号已验证",
      "steps": [
        "打开登录页面",
        "输入正确的手机号",
        "输入正确的密码（6-20位）",
        "点击登录按钮"
      ],
      "expected": "登录成功，跳转到首页"
    },
    {
      "id": 3,
      "title": "密码错误",
      "priority": "高",
      "precondition": "用户已注册",
      "steps": [
        "打开登录页面",
        "输入正确的用户名",
        "输入错误的密码",
        "点击登录按钮"
      ],
      "expected": "显示错误提示：用户名或密码错误"
    },
    {
      "id": 4,
      "title": "连续5次密码错误后账户锁定",
      "priority": "中",
      "precondition": "用户已注册",
      "steps": [
        "打开登录页面",
        "输入正确的用户名",
        "连续5次输入错误的密码并点击登录",
        "第6次尝试登录"
      ],
      "expected": "显示错误提示：账户已被锁定，请30分钟后再试"
    },
    {
      "id": 5,
      "title": "密码长度不符合要求",
      "priority": "中",
      "precondition": "用户已注册",
      "steps": [
        "打开登录页面",
        "输入正确的用户名",
        "输入长度小于6位的密码",
        "点击登录按钮"
      ],
      "expected": "显示错误提示：密码长度必须在6-20位之间"
    }
  ]
}

关键成功因素

角色明确：测试架构师的身份让模型使用专业术语，输出更规范
格式严格：JSON Schema 确保输出可解析
输入清晰：分隔符让模型明确知道哪里是功能描述
约束到位：禁止模糊表达、禁止编造，确保输出质量

💡 实战提示：

如果输出不符合 Schema，检查是否在 System Prompt 中强调了”仅输出 JSON”

如果测试用例覆盖不全，在 User Prompt 中明确要求”必须覆盖 XX 场景”

如果步骤不够清晰，在角色定义中强调”测试步骤要清晰、可执行”

🔍 总结：Prompt Engineering 的设计哲学

目标	原则	技巧
高质量输出	限制自由度，聚焦专业	明确角色（Persona）
复杂任务分解	外化思维过程，便于检查与修正	ReAct 范式
程序化对接	确保机器可读、可验证	Schema + 分隔符

三大技巧结合使用，你的 Prompt 从模糊提问升级为精确指令。

⚠️ 常见错误与修正

在实际使用中，经常会遇到以下问题。了解这些错误及其修正方法，可以帮你快速定位和解决问题：

错误	原因	修复方式
输出太随意	没有输出格式约束	使用 JSON Schema 或明确格式要求
幻觉严重	没有限制与拒绝条件	加入禁止推测、要求引用来源、允许拒答
内容缺失	输入不规范	声明输入格式，使用分隔符区分输入区域
格式混乱	Prompt 太自由	使用固定模板，明确每个部分的作用
多轮对话偏移	没有保持上下文	用 System Prompt 设置全局约束，在每轮对话中重申关键要求

💡 关键理解：大多数 Prompt 问题都可以通过明确约束和结构化设计来解决。

🔧 进阶优化技巧

掌握了核心技巧和工程化实践后，我们还需要掌握一些进阶优化技巧，让 Prompt 更高效、更稳定。

1. 调试技巧：如何定位和修复 Prompt 问题

当 Prompt 效果不理想时，如何快速定位问题？

方法一：逐步简化法

原理：从最简单的 Prompt 开始，逐步增加复杂度，找出问题所在。

步骤：

1. 最简版本：只保留核心任务
   "请生成3个测试用例"

2. 增加角色：看看角色是否有帮助
   "你是一位测试架构师。请生成3个测试用例"

3. 增加格式要求：看看格式约束是否生效
   "你是一位测试架构师。请生成3个测试用例，输出 JSON 格式"

4. 增加详细要求：逐步添加约束
   "你是一位测试架构师。请生成3个测试用例，输出 JSON 格式，必须覆盖正常和异常流程"

好处：能快速定位是哪个部分导致的问题。

方法二：对比测试法

原理：同时测试多个版本的 Prompt，对比效果。

示例：

# 测试不同版本
prompts = {
    "v1": "请生成测试用例",
    "v2": "你是一位测试架构师。请生成测试用例",
    "v3": "你是一位测试架构师。请生成测试用例，输出 JSON 格式"
}

results = {}
for version, prompt in prompts.items():
    result = call_llm(prompt)
    results[version] = {
        "output": result,
        "token_count": count_tokens(prompt + result),
        "quality_score": evaluate_quality(result)
    }

# 对比结果，选择最佳版本

💡 实战提示：

先用逐步简化法定位问题：找出是哪个部分导致的问题

再用对比测试法优化效果：对比不同版本，选择最佳方案

遇到具体错误时：参考常见错误与修正部分，快速找到修复方法

2. Token 成本优化：在保证效果的同时减少消耗

Token 消耗直接影响成本，如何在保证效果的同时减少 Token？

策略一：精简 Prompt 内容

原则：保留必要信息，删除冗余描述。

❌ 冗余版本（约 200 Token）：
你是一位经验非常丰富、在软件测试领域深耕多年、对自动化测试和测试平台开发有深入理解的资深测试架构师。你的职责是设计清晰、可维护、高质量的测试用例...

✅ 精简版本（约 50 Token）：
你是一位测试架构师，专注于自动化测试。职责：设计清晰的测试用例，确保覆盖正常和异常流程。

优化技巧：

删除重复描述（如”经验丰富”、”资深”等）
用列表代替长段落
合并相似的要求

策略二：使用 Few-Shot 而非 Many-Shot

原则：Few-Shot（1-3 个示例）通常足够，Many-Shot（5+ 个示例）成本高但效果提升有限。

# Few-Shot（推荐）
示例1: [输入] → [输出]
示例2: [输入] → [输出]

# Many-Shot（不推荐，除非必要）
示例1-10: [输入] → [输出]

策略三：压缩历史对话

方法：将历史对话压缩为摘要，而不是完整保留。

# 完整保留（消耗大量 Token）
历史对话：
用户：请生成测试用例A
助手：[...完整回复...]
用户：请生成测试用例B
助手：[...完整回复...]

# 压缩摘要（节省 Token）
历史摘要：
- 已生成测试用例A（用户登录功能，5个用例）
- 已生成测试用例B（购物车功能，6个用例）

策略四：使用分隔符而非长描述

方法：用分隔符标记输入区域，而不是用长段落描述。

❌ 长描述版本：
请为以下功能设计测试用例。功能名称是用户登录，功能描述是用户通过用户名和密码登录系统，用户名支持邮箱和手机号两种格式...

✅ 分隔符版本：
请为以下功能设计测试用例：

<<<功能描述>>>
功能名称：用户登录
功能描述：用户通过用户名和密码登录系统...
<<<END>>>

💡 成本对比：

精简 Prompt：可节省 30-50% Token

使用 Few-Shot：可节省 40-60% Token（相比 Many-Shot）

压缩历史对话：可节省 70-90% Token（长对话场景）

3. 不同模型的 Prompt 适配技巧

不同模型对 Prompt 的响应有差异，如何针对不同模型调整 Prompt？

GPT-4 / GPT-4 Turbo

特点：

对 System Prompt 响应好
结构化输出能力强
对长 Prompt 理解好

适配技巧：

✅ 可以使用详细的 System Prompt
✅ 可以使用复杂的 JSON Schema
✅ 可以使用长 Few-Shot 示例

示例：

System Prompt（详细版，适合 GPT-4）:
你是一位经验丰富的测试架构师，专注于自动化测试和测试平台开发。
你的职责是设计清晰、可维护的测试用例...
[详细描述...]

Claude 3 / Claude 3.5

特点：

对 System Prompt 响应好
对格式要求理解准确
对长上下文处理能力强

适配技巧：

✅ 可以使用详细的 System Prompt
✅ 可以使用 XML 标签（Claude 推荐）
✅ 可以使用长 Few-Shot 示例

示例：

System Prompt（适合 Claude）:
<role>你是一位测试架构师</role>
<task>设计测试用例</task>
<constraints>禁止模糊表达，输出 JSON 格式</constraints>

开源模型（Llama、Mistral 等）

特点：

System Prompt 支持可能较弱
对复杂格式理解有限
需要更明确的指令

适配技巧：

⚠️ System Prompt 要简洁
⚠️ 格式要求要明确且简单
⚠️ 使用 Few-Shot 而非 Zero-Shot
⚠️ 避免过于复杂的 JSON Schema

示例：

User Prompt（适合开源模型）:
你是一位测试架构师。请为"用户登录"功能生成测试用例。

要求：
1. 输出 JSON 格式
2. 至少3个测试用例
3. 每个用例包含：id, title, steps, expected

示例：
输入：功能名称
输出：{"test_cases": [{"id": 1, "title": "...", "steps": [...], "expected": "..."}]}

现在请为"用户登录"生成测试用例。

通用适配原则

模型类型	System Prompt	格式要求	Few-Shot	建议
GPT-4	详细	复杂 Schema	3-5 个	充分利用能力
Claude	详细	XML 标签	3-5 个	充分利用能力
开源模型	简洁	简单格式	1-3 个	降低复杂度

💡 实战提示：

先设计通用 Prompt：适用于大多数模型

再针对特定模型优化：根据实际使用的模型调整

使用 A/B 测试：对比不同 Prompt 在不同模型上的效果

注意：详细的模型对比和选型建议将在第 5 篇《评估与选型》中深入讲解。

📚 延伸阅读（含可直接访问链接）

以下资源按主题分类，每个资源都附有简要说明，帮助你选择合适的学习材料。

🎭 Persona Defining（角色定义）

System Prompt Best Practices（System Prompt 最佳实践）：OpenAI 关于 System Prompt 的最佳实践指南。强烈推荐，适合所有开发者。
Prompt Engineering for Claude（Claude Prompt 指南）：Anthropic 关于 System Prompt 的详细指南。适合使用 Claude 的开发者。
Prompt Engineering Guide（提示工程综合指南）：社区维护的 Prompt 工程综合指南，包含角色定义、Few-Shot 等多种技巧。适合想系统学习的读者。

🔗 ReAct & Chain-of-Thought（思维链与推理行动）

ReAct: Synergizing Reasoning and Acting in Language Models（ReAct 原始论文）：ReAct 范式的开创性论文，展示了如何结合推理和行动。必读论文，适合所有读者。
Chain-of-Thought Prompting Elicits Reasoning in Large Language Models（CoT 原始论文）：CoT 的开创性论文，展示了如何通过思维链提升模型推理能力。必读论文，适合所有读者。
Self-Correction Mechanisms in LLMs（自我修正机制）：研究 LLM 如何识别和修正错误的论文。适合想实现自我修正功能的开发者。
Tree of Thoughts: Deliberate Problem Solving with Large Language Models（思维树）：CoT 的进阶方法，通过树状结构探索多种推理路径。适合想处理复杂推理任务的读者。

🧱 Schema & Structured Output（结构化输出）

Pydantic 官方文档：Python 中最流行的数据验证库，常用于定义 LLM 输出的 Schema。强烈推荐，适合 Python 开发者。
OpenAI Function Call 文档：OpenAI 官方的 Function Calling 指南，展示了如何使用 Schema 约束模型输出。必读，适合使用 OpenAI API 的开发者。
Anthropic Tool Use（Claude 工具使用）：Anthropic 关于工具调用和结构化输出的指南。适合使用 Claude 的开发者。
JSON Schema 规范：JSON Schema 的官方规范，用于定义数据结构。适合需要深入理解 Schema 的开发者。

📖 Prompt Engineering 综合指南

OpenAI Prompt Engineering Guide（OpenAI 官方指南）：OpenAI 官方的 Prompt 工程指南，涵盖基础技巧和最佳实践。强烈推荐新手阅读，内容全面且实用。
Prompt Engineering Guide（社区指南）：社区维护的 Prompt 工程综合指南，包含大量示例和技巧。适合想系统学习的读者，内容更新及时。
Anthropic Prompt Engineering（Claude 指南）：Anthropic 官方的 Prompt 工程指南，特别针对 Claude 模型优化。适合使用 Claude 的开发者。

🛠️ 实战工具与框架

LangChain Prompt Templates（LangChain Prompt 模板）：LangChain 的 Prompt 模板系统，方便构建复杂 Prompt。适合使用 LangChain 的开发者。
LangChain Output Parsers（LangChain 输出解析器）：LangChain 的输出解析器，帮助将模型输出转换为结构化数据。适合使用 LangChain 的开发者。
PromptLayer（Prompt 管理工具）：Prompt 版本管理和分析工具，帮助优化 Prompt 效果。适合需要管理大量 Prompt 的团队。
OpenAI Evals（评估框架）：OpenAI 开源的 Prompt 评估框架，帮助测试和优化 Prompt。适合需要系统评估 Prompt 的开发者。

🇨🇳 中文资源

Prompt Engineering 中文指南：Prompt Engineering Guide 的中文版本，内容全面。适合中文读者。
LLM 应用开发实践（中文博客）：Lilian Weng 的 Prompt Engineering 博客文章，有中文翻译版本。适合中文读者，内容深入。

🔔 系列说明

本文是《🧠 LLM/Agent 从入门到精通：告别浅尝辄止》系列第 3 篇。上一篇：理解 LLM 的”语言”：Prompt、上下文与 In-Context Learning。下一篇：RAG 机制：解决大模型幻觉的核心技术 —— 如何让 LLM 访问最新信息？如何理解私有文档？检索 → 分块 → 重排 → 融合的完整流程。