Prompt工程实战指南：如何为大模型构建可复用的提示词模板体系

Prompt工程为什么需要模板化管理

Prompt工程的核心目标不是写出一个惊艳的提示词，而是建立一套可维护、可复用、可测试的提示词体系。生产环境中，大模型应用的稳定性80%取决于Prompt的一致性。散落在各处的硬编码提示词，会导致输出质量不可控、迭代成本高、团队协作困难。

构建模板体系的思路：将提示词拆分为系统指令（System Prompt）、任务描述、上下文注入、输出约束四个独立模块，通过变量占位符实现动态组装。这比每次手写完整提示词的维护成本低一个数量级。

系统指令模板设计

系统指令定义模型的角色和行为边界，在整个会话中保持不变。一个可用的模板结构如下：

SYSTEM_PROMPT = """
你是一个{role_description}。

行为规则：
1. 只回答与{domain}相关的问题
2. 如果不确定，回复"信息不足，无法判断"
3. 输出格式必须为JSON
4. 回复长度不超过{max_tokens}个token

禁止行为：
- 不得编造事实
- 不得输出与任务无关的内容
- 不得在回复中包含推理过程
"""

关键点在于行为规则要具体到可验证的程度。”回答简洁”这种模糊约束几乎没有效果，”回复长度不超过200个token”才是可执行的指令。

Few-Shot示例的选择策略

Few-Shot示例的质量比数量重要。3个精心选择的示例通常优于10个随机示例。选择策略遵循三条原则：

• 覆盖边界情况而非常规情况——模型对常规输入已有足够先验知识
• 示例之间保持差异性——避免模型从相似示例中过拟合特定模式
• 每个示例展示一种输出约束——不要在一个示例中混合多种格式要求

示例的格式化方式直接影响模型的输出结构。将示例放在System Prompt之后、用户输入之前，用明确的分隔符标记：

FEW_SHOT_TEMPLATE = """
--- 示例 ---
输入: {example_input_1}
输出: {example_output_1}

输入: {example_input_2}
输出: {example_output_2}
--- 示例结束 ---

输入: {user_input}
输出:
"""

Chain-of-Thought提示的场景适配

Chain-of-Thought（CoT）不是万能的。对于简单分类任务，CoT反而会增加token消耗和延迟，不改善准确率。以下场景适合使用CoT：

• 多步推理任务（数学计算、逻辑推导）
• 需要中间状态的复杂决策
• 输出质量对推理深度敏感的任务

CoT的实现方式有两种：Zero-Shot CoT（在提示词末尾加上”让我们一步一步思考”效果较差，改用”请先分析再给出结论”）和Few-Shot CoT（在示例中展示推理过程）。生产环境推荐Few-Shot CoT，因为推理路径可控。

COT_TEMPLATE = """
问题: {question}

分析过程:
1. 首先识别问题的关键变量: {variables}
2. 计算中间结果: {intermediate}
3. 验证中间结果的合理性: {validation}

结论: {answer}
"""

变量注入与转义处理

动态注入用户输入是Prompt工程的高风险环节。如果用户输入中包含指令性语言，可能导致Prompt注入攻击。防护措施：

def safe_inject(user_input: str, template: str) -> str:
    # 转义用户输入中的特殊标记
    sanitized = user_input.replace("---", "- - -")
    sanitized = sanitized.replace("```", "` ` `")
    # 用XML标签包裹用户输入，明确边界
    return template.replace("{user_input}", f"{sanitized}")

用XML标签包裹用户输入是有效的边界标记方式。主流大模型对XML标签的理解能力强于自由文本分隔符，能更准确地区分指令和数据。

输出结构化约束与JSON解析

让模型输出JSON是工程实践中最常见的需求。硬约束方式是在提示词中明确JSON Schema：

OUTPUT_CONSTRAINT = """
输出必须为合法JSON，格式如下：
{{
  "category": string,  // 分类名称
  "confidence": number,  // 置信度0-1
  "reasoning": string  // 判断理由（50字以内）
}}

不要输出JSON以外的任何内容。不要使用markdown代码块标记。
"""

实际工程中，模型偶尔会在JSON外附加解释文字。防御方案是在解析阶段做容错处理：

import json, re

def parse_llm_json(text: str) -> dict:
    # 尝试直接解析
    try:
        return json.loads(text)
    except json.JSONDecodeError:
        pass
    # 提取第一个JSON对象
    match = re.search(r'\{.*\}', text, re.DOTALL)
    if match:
        return json.loads(match.group())
    raise ValueError(f"无法解析JSON: {text[:200]}")

提示词版本管理与A/B测试

提示词应该纳入版本控制，和代码一样管理。推荐的做法是将提示词模板存储为独立的YAML文件，包含版本号、变更说明和评估指标：

# prompt_v3.yaml
version: 3
description: 产品分类提示词，v3增加了边界情况处理
metrics:
  accuracy: 0.92
  latency_ms: 340
  token_cost: 180
changes:
  - 增加了"信息不足"的输出路径
  - 将Few-Shot示例从5个减少到3个
system_prompt: |
  ...

A/B测试时，将不同版本的提示词分配给相同流量比例，比较准确率、延迟和token消耗三个核心指标。评估数据集至少包含200条标注样本，覆盖常见输入和边界输入。只看准确率不够——如果v3的准确率比v2高2%但token消耗增加50%，在成本敏感场景下可能不值得升级。

提示词调试的常见陷阱

调试提示词时容易踩的坑：

• 过度迭代单个case——为修复一个边界case而添加约束，可能降低整体准确率。每次修改后必须在完整评估集上回归测试。
• 忽视温度参数的影响——temperature=0时提示词的微小变化不会改变输出，但temperature=0.7时同样的变化可能导致输出剧烈波动。调试时先在temperature=0下确认逻辑正确性。
• 混淆模型能力与提示词质量——当模型输出不符合预期时，先排查是否是提示词表述歧义，而非模型能力不足。可以通过将同一提示词输入不同模型对比输出来判断。

Prompt工程的本质是精确表达需求。每一个词都应该有存在的理由，每一条约束都应该可验证。把提示词当作代码来写——有版本、有测试、有文档、有评估指标，才能在生产环境中稳定运行。