Prompt工程实战：结构化提示词与思维链控制大模型输出质量

Prompt工程是开发大模型应用时投入产出比最高的环节之一。同样的模型，提示词结构不同，生成质量可能相差一大截。对AI工具链开发者和大模型应用工程师来说，把提示词当成接口规范来设计，配合思维链（CoT）与Few-shot示例，能显著提升生成结果的稳定性和可解析性。本文围绕结构化提示词、思维链推理、Few-shot示例与输出格式约束四个环节，给出可落地的构建方法与代码示例。

结构化提示词：拆分任务与上下文，让模型各司其职

结构化提示词一般包含角色、任务、上下文、输出格式、约束条件五个模块，用明确的标记符隔开，模型更容易逐条遵守。下面是一个后端代码审查场景的提示词模板：

system = """你是后端代码审查助手，只输出JSON，不输出其他文字。
任务：审查给定的Go代码并输出审查结果。
输出格式：
{"issues":[{"line": 行号, "level": "error|warning", "message": "问题描述"}]}
约束：不讨论代码之外的内容，不使用Markdown。"""

user_prompt = "请审查以下代码：
" + code_snippet

这种写法在AI工具链的批量处理场景中很常用。输出被约束为JSON后，下游程序直接解析，省去二次加工。角色设定要与任务目标一致，否则模型会带上无关的语气和假设。

2. 思维链（Chain-of-Thought）：让复杂推理分步求解

面对数学计算、逻辑判断、多步决策类问题时，模型直接回答容易出错。思维链方法要求模型先生成推理步骤，再给出结论。实现上只需要在提示词里明确要求：

def build_reasoning_prompt(question):
    return f"""请按以下步骤回答问题：
1. 列出题目中的关键条件
2. 推导每一步计算过程
3. 给出最终结论

问题：{question}"""

一个实用细节：提示”先列出关键步骤再计算”比”请仔细思考”有效得多。推理过程会占用输出token，因此在解析结果时要把推理部分和结论部分分开处理，结论格式单独约定，推理过程不参与下游逻辑。

3. Few-shot示例：用样例分布约束输出习惯

示例比文字描述更能约束模型的行为。做意图分类或信息抽取时，每个类别至少给一个示例，边界模糊的场景给两个示例。示例要与线上真实输入分布一致，否则模型会学会示例里的偏差。

examples = [
    ("退款到账失败", "资金问题"),
    ("App无法登录", "账号问题"),
    ("搜索接口返回500", "系统故障"),
]
prompt = "请把用户反馈分类到：资金问题/账号问题/系统故障/其他
" + "\n".join(
    f"输入：{q}\n分类：{a}" for q, a in examples
) + "\n输入：" + user_input + "\n分类："

示例数量一般取3到10个。超过这个范围，token成本与延迟会明显上升，收益趋缓；实际项目中先在小批量评测集上对比不同示例数量的准确率再定。

4. 输出格式约束：用JSON结构固化机器可读输出

需要机器解析的场景，直接在提示词中给出目标JSON的结构示例，并注明字段含义。对模型的格式依赖更强时，可以配合JSON Schema描述：

schema = {
    "type": "object",
    "properties": {
        "title": {"type": "string"},
        "keywords": {"type": "array", "items": {"type": "string"}},
        "summary": {"type": "string"}
    },
    "required": ["title", "keywords", "summary"]
}

提示词里写明”严格按以上结构输出”，同时在解析侧做兜底：JSON解析失败时重试一次或返回结构化错误，而不是让流程崩溃。

5. Prompt质量排查清单

模型输出不稳定时，按以下顺序检查：一是提示词是否缺少约束条件；二是示例与真实输入分布是否一致；三是输出格式要求是否在开头与结尾都出现一次；四是temperature是否过高（结构化输出建议调到0）；五是是否需要在后处理环节补一层规则校验。按这套流程排查，多数输出质量问题在提示词层就能解决，不需要更换模型。