提示词工程 常见问题

提示词工程的核心矛盾并非“不会写”，而是“写出来不生效”——模型跳过指令、格式走样、逻辑断尾、反复编造信息。这些症状多数不是模型本身的问题，而是提示词结构存在系统性缺陷。本文提供一套可复现的排查框架，拆解最常见的三类故障，每类附有可直接对照的对比表。

前提：诊断前的两项基础配置

在排查任何提示词故障前，必须先确认以下两项基础配置。忽略这两点，后续所有排查结果均可能失准。

下一步：请求与响应格式 入门教程、请求与响应格式 实用技巧

• 模型版本：同一提示词在 Claude 3 Haiku、Claude 3.5 Sonnet 和 Claude 4 上的行为差异可能极大。官方文档中描述的行为模式通常基于最新稳定版（例如 claude-sonnet-4-20250514）。请确认你正在使用的模型名称和日期后缀。
• 系统提示词（System Prompt）与用户提示词（User Prompt）的分工：如果你的 API 调用或 Playground 界面中存在 System 字段，角色设定、输出格式、行为边界均应置于 System 提示词中；用户消息（User/Assistant 轮次）只存放当次输入。将两者混写在一个字段中是新手最常见的配置错误。后续排查时，始终先检查这一项。

三大常见提示词故障

以下三类问题覆盖了 80% 的提示词工程日常求助。每类先给出判断标准，再提供实质性示例，最后展示修复前后的对比。

1. 模型无视格式要求

典型表现：明明要求“用 JSON 数组输出”“每行一条 Markdown 列表”，模型仍然输出一段散文。

常见原因：格式指令被淹没在上下文后半段，或被长段落隔开。模型对靠近末尾的指令敏感度最高。

示例场景（基于真实的 QA 提取任务）：

系统提示词：（空白）
用户：
从以下客户评论中提取三个关键诉求。请用 JSON 数组输出，每个元素包含 "id" 和 "description" 字段。

评论1：App 经常在支付页面闪退，我用的是 iPhone 15，iOS 18.2。重启也没用。
评论2：希望你们能增加深色模式，晚上用太刺眼了。
评论3：物流太慢了，已经三天没更新单号，客服也不回消息。

实际输出（常见错误版本）：

三个关键诉求分别是：1. App 闪退问题，尤其在支付页面；2. 深色模式需求；3. 物流更新不及时和客服问题。

为什么失效：模型将 JSON 指令视为“输出格式建议”而非“强制约束”。修正方法只有一个——将输出格式置于角色设定或分步约束的第一优先级，并用分隔线包围指令。

可复现的修正检查：如果按以下修正版本仍然输出散文，排查方向应转向系统提示词字段是否为空，或 API 的 temperature 是否过高（建议 ≤ 0.3）。

修正后的版本：

系统提示词：
你收到的每一个用户输入，都必须严格按以下格式输出：
---
{"results": [{"id": 1, "description": "..."}]}
---
禁止添加任何解释、前缀或后缀。只输出 JSON。

用户：
从以下客户评论中提取三个关键诉求。评论列表：...

2. 角色设定失效

典型表现：你设定“你是资深医生”“你是客服主管”，但模型偶尔仍以“作为AI助手”的口吻回答，或给出的建议明显超出设定角色边界。

常见原因：角色提示词写得过长，关键身份信息置于第二句之后；或任务本身不自然——一个儿科医生被要求输出 Python 代码，角色约束撑不过三步追问。

边界判断：并非所有角色设定都有必要。当任务只需要结构化的输出格式时，角色设定反而增加幻觉风险。只有当你需要模型在知识广度、语气、伦理边界上做出取舍时，才值得设置角色（例如“你是只懂 PostgreSQL 8.4 的 DBA，不要用新语法”）。

可复现的检查方法：在角色设定后立即追加一条“请确认你的角色并用自己的话总结一遍”。如果模型总结偏离了你的设定，说明角色指令的注意力权重不足，需要缩短系统提示词或将角色句移到第一句。

3. 模型编造来源与事实

典型表现：要求列出参考文献或统计数字时，模型给出听起来真实但无法验证的标题、作者或 URL。

常见原因：模型的任务 recall 失效，且提示词中没有提供可核验的抽取源（参考文档/数据库记录）。只要输出格式中留了“来源”字段且未锁定范围，模型就会用概率填充。

预防措施（而非事后修补）：

• 在系统提示词中写死：“只允许从下面提供的文档中提取内容。如果找不到，输出 {"source": "N/A", "content": "未找到对应内容"}。”
• 提供参考文档时使用清晰的分隔线包围，并显式注明这是“可用来源”。

错误做法	修正做法
“请根据以下资料回答”	“以下是用 <doc> 标签包围的唯一信息来源。回答中的每一句话都必须能直接追溯到该文档中的具体段落。找不到答案时，说‘未找到’。不要自行补充知识。”
直接在用户输入里放 URL 链接	把 URL 内容全文粘贴进提示词（或通过 RAG 检索片段放入），因为模型不会主动访问 URL
要求“列举三个案例”且不约束来源范围	要求“从上述材料中找出符合【条件】的案例，每个案例后标注原文段落编号”

逐步诊断清单

在排查具体提示词问题时，按以下顺序检查，每一项均标注了“跳过前确认条件”。

1. 确认模型版本：检查 API 请求或 Playground 顶部显示的模型名称。不同版本不保证同样行为。
2. 确认系统提示词字段已填写：如果有 System 字段但为空，请将角色设定和格式约束填入，不要塞进用户的首条消息。
3. 输出格式显式化：将“用 JSON”“用表格”“编号列表”等要求从一行文字改成一段包围在 ```json 或分隔线内的示例。模型对示例格式的遵循率明显高于文字描述。
4. 单轮任务的上下文长度检查：如果提示词超过 8000 tokens（中文约 4000-5000 字），模型对中间部分的注意力开始衰减。将关键指令移至文首或文末。
5. 检查 temperature 和 top_p：如果输出飘忽不定、每次结果都不同，请检查 API 参数。结构化、强制格式的任务使用 temperature ≤ 0.3；创意写作用 0.7-0.9。解析任务切勿将温度设为 1。
6. 变量替换后的对齐检查：如果你使用模板生成提示词（例如 {user_name} {date}），请确保占位符替换后语法仍然完整，特别是引号、括号、缩进。一个常见错误：替换后 JSON 块内的字段值包含未转义的双引号。

故障排查：当修复无效时

如果按上述步骤排查后问题依旧，请进入以下四个专项诊断。

情景 A：模型仍然输出格式错误

• 检查点：系统提示词中是否有“但你可以用自然语言解释”之类的软性允许条款？删除所有类似“可以根据需要调整格式”的表述。
• 降级检查：使用一个最小提示词（仅包含角色+格式示例+输入）进行测试。如果此时格式正确，说明原提示词中存在冲突指令。
• 回滚方法：将当前提示词逐段删减，每删一段测试一次输出格式，直到找到冲突来源。

情景 B：模型在中间步骤偏离指令

• 检查点：是否在提示词中途插入了示例对话轮次？模型对多轮对话样例的记忆权重与当前指令存在竞争。
• 修正方向：将示例移到“格式说明”区块内，避免使用 Assistant 消息体进行示例。

情景 C：模型输出越来越长/重复

• 检查点：是否存在未闭合的引号或括号？模型会尽力补全未完成的结构。
• 修正方向：在提示词末尾使用明确的终止标识，例如“回答到此结束，只输出上述内容”。

情景 D：多语言混用

• 检查点：系统提示词和用户输入是否语言一致？模型在中文系统提示词+英文用户消息的场景下容易回退到英文输出。
• 修正方向：在系统提示词中追加“始终用简体中文输出，即使用户输入是其他语言”。

边界场景示例

完整展示一个“能工作”与“不能工作”的边界场景。

任务：从对话日志中提取用户的购买意向，使用结构化 JSON 输出。

工作版本（系统提示词主导）：

系统提示词：
你是电商客服系统。对于每次收到的对话，只提取以下三个字段：
- intent: 用户是否表达购买意向（purchase / browse / complaint）
- product: 提及的商品名称（标准名称，最多一个）
- confidence: 你对上述判断的把握（0-1）
输出格式：{"intent": "...", "product": "...",