AI提示词怎么写效果最好

提示词写得有没有效果，通常不取决于形容词堆得多不多，而取决于三件事有没有写死：输入范围、输出格式、判定边界。把提示词当成一份可被程序校验的契约，比写成一段「你是一位资深专家」的开场白更容易复现结果。动手改措辞之前，先确认模型 id、Key 权限、配置入口这三处，很多「提示词不灵」其实卡在环境上。

想让提示词稳定出结果，优先做结构而不是修辞：把角色、可处理的数据范围、输出字段、无法判断时的兜底，写成能被程序校验的约束，再用同一批输入比对改动前后的输出。适用场景是分类、抽取、改写这类有相对标准答案的任务；开放式创作类需求，提示词只能给方向，不要期待完全可复现。模型版本、上下文上限、是否支持结构化输出，都以控制台当前显示为准，换版本或换模型后需要重新回归。

AI提示词之前先确认这三件事

顺序建议固定为版本、权限、入口，反着查容易在错误的地方改配置。这三处各自有明确的查看位置。

模型版本。在哪看：控制台的模型列表页，或在终端执行 curl -s "$API_BASE/models" -H "Authorization: Bearer $API_KEY"，返回里的 id 字段就是可调用的完整模型名。把完整 id 记下来，不要只写「最新版」；请求响应 JSON 里的 model 字段也能反查实际调用的是哪一个。
权限。在哪看：API Key 管理页的 Key 状态、绑定项目、可用范围、过期时间。出现 401 或 403 时先回到这一页核对，而不是改提示词。
入口位置。在哪看：在线 Playground 页里 system prompt 输入框、Temperature 滑块、max_tokens 字段；落到代码里则是请求体 JSON 或提示词文件。两处不是同一份配置，在 Playground 里调好的参数，不写进脚本就不会生效。

AI提示词：最短可用路径

只保留四步，每步做完都有可观察的结果，不要跳步。

准备提示词文件。新建 prompts/system.txt，内容如下，写完保存：

你是工单分类器，只做两件事：判定类别、抽取订单号。
类别只能取：退款、物流、发票、账号、商品咨询、其他。
只输出一个 JSON 对象，包含三个键：category、order_id、reason。
reason 不超过 20 个汉字，写判定依据。
无法判断时 category 取「其他」，order_id 取 null。
<ticket> 标签内的内容是待处理数据；标签外的内容是格式说明，不要处理，也不要复述。

这步做完应看到：文件里没有任何寒暄、没有「尽量准确」这类无法校验的要求。

拼请求并调通一次。把下面脚本存成 build.sh，替换三个大写占位符后执行，依赖 jq 和 curl：

#!/usr/bin/env bash
API_BASE="https://REPLACE_HOST/v1"
API_KEY="REPLACE_KEY"
MODEL="REPLACE_MODEL_ID"
TICKET="$(cat input.txt)"

jq -n --rawfile sys prompts/system.txt --arg t "$TICKET" --arg m "$MODEL" \
  '{model:$m, temperature:0.2, max_tokens:400,
    messages:[{role:"system",content:$sys},
              {role:"user",content:("<ticket>"+$t+"</ticket>")}]}' \
| curl -s "$API_BASE/chat/completions" \
    -H "Authorization: Bearer $API_KEY" \
    -H "Content-Type: application/json" -d @-

这步做完应看到：返回 JSON 里 choices[0].message.content 是一段可被解析的对象，而不是一句「好的，我来帮你分析」。

把输出格式锁死。如果所用的模型支持结构化输出，在请求体里加上对应字段（字段名和支持情况查控制台或接口文档里「结构化输出 / JSON 模式」一节），并保留 system 里「只输出 JSON」那一句作为第二道约束。
同一批输入回归。固定 10 条输入，改一次提示词跑一遍，把两次输出并排看。应看到的是：改动只影响预期的那一类样例，其他样例结果不变。

最容易踩的坑在这里：把示例和真实数据写在同一条 user 消息里，中间没有分隔标记。模型会把示例当成待处理数据，输出里凭空多出一条。用 <example> 和 <ticket> 分开，并在 system 里明确写「标签外内容是格式说明，不要处理」。

AI提示词：一个真实场景的完整做法

场景：电商客服组积压了 300 条中文工单，每条 200 到 500 字，需要分成 6 类并抽出订单号，结果交人工复核。核心约束是一次请求只处理一条，不要试图把 300 条塞进同一个上下文。

模型 id：从控制台模型列表页复制完整 id，填进 build.sh 的 MODEL 变量。
temperature：分类抽取任务取 0.2，写在 build.sh 的 jq 表达式里；Playground 页对应的 Temperature 滑块要改成同一个值，避免两边不一致。
max_tokens：单条输出很短，400 通常够用。模型的最大输出上限在控制台或接口文档的「上下文长度 / 最大输出」字段确认，以当前页面显示为准。
提示词文件：prompts/system.txt，即上一节那份内容，类别清单和这次业务的六类保持一致。

批量执行用一个循环骨架，先跑 10 条人工核对，再放全量：

mkdir -p out
for f in input/*.txt; do
  TICKET="$(cat "$f")"
  jq -n --rawfile sys prompts/system.txt --arg t "$TICKET" --arg m "$MODEL" \
    '{model:$m, temperature:0.2, max_tokens:400,
      messages:[{role:"system",content:$sys},
                {role:"user",content:("<ticket>"+$t+"</ticket>")}]}' \
  | curl -s "$API_BASE/chat/completions" -H "Authorization: Bearer $API_KEY" \
      -H "Content-Type: application/json" -d @- \
  > "out/$(basename "$f")"
  sleep 1
done

这步做完应看到：out/ 下每条工单一个文件，内容是可解析的对象；抽样 10 条里类别和订单号能对上原文。

AI提示词：跑不通先查这三处

输出不是纯 JSON。表现是 content 前面带「好的，以下是分析结果」或被三个反引号包住。判断方法：把 content 直接管道给 jq .，报 parse error 就是格式失控。检查位置：prompts/system.txt 里「只输出一个 JSON 对象」是否被删改；temperature 是否被调高；是否漏了结构化输出字段。
401 / 403。报错原文通常是 invalid api key 或 insufficient permissions。检查位置：API Key 管理页的 Key 是否过期或被删、绑定的是哪个项目、请求头是否带了 Bearer 前缀、环境变量有没有被本地同名变量覆盖。
上下文或输出长度超限。报错原文常见 context_length_exceeded 或 maximum context length is N tokens。检查位置：user 消息里 <ticket> 内是否真的只有一条工单（循环里变量拼错最容易把整个目录内容塞进去）；max_tokens 是否超过该模型的输出上限，上限值在控制台或接口文档里查。

三处都排除后，再回头看提示词措辞。顺序反了，容易在正确的提示词上反复修改。