---
url: /practices/prompt-patterns.md
description: >-
  把 prompt
  当成写给同事的接口文档：角色设定真正固定了什么、指令怎么具体到格式与长度、示例为何比讲道理有效、思维链的适用边界、结构化输出的可靠做法与兜底，以及改
  prompt 之前为什么必须先有评测集。
---

# 提示工程模式：从角色设定到结构化输出

模型很聪明，但不了解你的项目：字段叫什么、文案多长、用户屏幕上看见的是哪一段。prompt（提示词）就是你写给它的接口文档——写清楚了，它像靠谱同事；写含糊了它只能猜，猜错的地方往往上线才暴露。这篇把前端日常最常用的几个模式拆开讲：角色设定、指令具体化、给示例、思维链、结构化输出、正面表述、上下文顺序，以及一件比所有技巧都重要的事：先有评测集。

## 角色设定（system prompt）到底改变了什么

system prompt（系统提示词）不是「把它变成另一个人」，而是把默认值提前钉死：语言、称呼、代码风格、能碰哪些数据。写成「你是一名前端工程师，用中文回答，代码用 TypeScript，不输出开场白」，比每次在用户消息里重复一遍更省 token，也更稳定。但它补不上知识缺口：模型没见过的接口，换人设也答不对。

```ts
const system = '你是一名前端工程师。用中文回答，代码用 TypeScript，不给多余解释。'
```

## 指令要具体到「输出格式 + 长度 + 语气」

「帮我优化这个函数」和「把它重写成 TypeScript，保留入参签名，去掉 any，不超过三十行，不写注释」是两个物种。按清单过一遍：输出格式（Markdown、纯代码、JSON）、长度上限、语气。

## 给示例比讲道理有效

规则写再多也说不清边界，给两三个「输入到期望输出」的例子，模型照着模仿，这就是 few-shot（少样本提示）。原因不玄学：示例具体无歧义，而形容词要靠模型自己解释——「简洁一点」到底多简洁，没人知道。示例要覆盖异常输入，否则它只学会主流程。

## 思维链（CoT）在什么任务上有用

CoT（Chain-of-Thought，思维链）指让模型先写推理过程再给结论。它在多步推理上有用：梳理逻辑分支、判断边界条件、在多个约束里取舍。在纯翻译或格式转换上，它只增加延迟和 token。推理过程别和结果塞进同一个 JSON 字段。

## 结构化输出：别靠运气

让模型吐 JSON，首选 API 自带的结构化输出。OpenAI 的 Structured Outputs 通过 `response_format` 里的 `json_schema` 配合 `strict: true`，用约束解码把输出限制在符合 schema 的词元上；只开 JSON mode 则仅保证「是合法 JSON」，不保证字段符合你的 schema。没有这层保障时，就在 prompt 里贴完整 schema 和示例，再用 zod 之类校验，失败重试一次。

```ts
try {
  return Schema.parse(JSON.parse(text))
} catch {
  return retry(/* 带上错误信息再问一次 */)
}
```

## 「不要做什么」改写成「要做什么」

「不要输出解释」通常不如「只输出代码块」。否定指令只排除了一个方向，剩下无数个方向依然合法；正面指令直接收窄了输出空间。同理，「不要用 any」不如「类型不确定时用 unknown 并补类型守卫」。

## 上下文里信息的顺序会影响结果

长上下文里，开头和结尾的信息更容易被用上，夹在中间的最容易被漏掉，这就是 lost in the middle 现象。工程做法：参考资料放前面，任务指令和输出格式放最后，关键约束首尾各写一次。

## 最重要的一条：先有评测集

没有评测集，你改的是感觉，不是 prompt。攒二三十条真实输入（掺几条故意刁难的），写清期望输出，每改一版跑一遍对比。否则你只能凭「这条看起来好多了」下结论，而它可能同时改坏了另外五条。

::: warning
什么时候调 prompt 没用：模型完全不知道的事实（去补资料或上 RAG）、需要精确计算（交给代码）、模型能力本身不够（换模型）。prompt 也不是安全边界：它挡不住提示注入，涉及权限的动作必须在代码里校验。
:::