如何处理提示词优化中的常见问题？比如输出不准确、不完整、格式错误
- 标签：Prompt、问题诊断
🏛 业务架构师
提示词优化中的常见问题对症下药，我按三类症状给解法：
1. 输出不准确（答非所问/胡编）：
- 任务描述有歧义 → 重写为"输入-输出-判断标准"三要素明确的规格式指令；
- 上下文不足 → 补背景与领域口径（"按 2026 年新会计准则"）；
- 缺知识依据 → 接 RAG，别让模型凭记忆答专业问题；
- 加自检指令："回答前先确认每个要求都已满足"。
2. 输出不完整（漏要点/截断）：
- 要求清单化输出："必须覆盖以下 N 个方面，逐项作答"——把隐式期待变成显式清单；
- 分步处理："先列提纲确认覆盖面，再逐项展开"（任务分解）；
- 输出长度受限 → 检查 max_tokens 设置（最常见的"低级事故"）与格式冗余（废话占用了预算）。
3. 格式错误（JSON 解析失败/结构跑偏）：
- 给出精确的格式模板和 1~2 个标准示例（Few-shot 锁格式比描述格式有效）；
- 使用结构化输出能力（JSON Schema 约束解码），从机制上保证合法；
- 提示里强调"不要输出任何格式之外的内容（包括解释性文字）"；
- 兜底：解析失败自动带着错误信息重试一次。
通用纪律：每次只改一处、跑评测集对比（无评测不优化）；把稳定有效的约束沉淀进团队模板库；格式类问题优先用机制（结构化输出、解析重试）解决而不是无限堆提示词——提示词是软约束，工程是硬约束。
🏗 系统架构师
提示词常见问题我按症状 → 诊断 → 处方的三段式讲：
症状一：输出不准确（答非所问/编造）：
- 诊断：任务定义模糊？缺上下文？还是知识不在模型能力内？
- 处方：量化约束（"500 字内"而非"简短"）；提供依据材料 + "仅根据资料回答"；加 few-shot 示例钉住判断标准；关键事实走 RAG 而不是指望模型知道。
症状二：输出不完整（截断/漏要点）：
- 诊断：max_tokens 太小（截断的硬原因，先查这个）；任务过载（一次要太多东西）；指令位置不对。
- 处方：调 max_tokens；任务分解（先列要点再逐项展开，或模板链分步）；关键要求放 Prompt 首尾（attention 位置敏感）；要求"先列清单再逐项回答"自查完整性。
症状三：格式错误（JSON 解析失败/字段漂移）：
- 诊断：格式说明模糊；模型能力档位不足；示例与要求不一致。
- 处方：结构化输出（JSON Schema + 受限解码）是根治方案；格式示例必须与要求严格一致（示例的权重高于文字描述）；温度调低；解析层加重试 + 修复回喂（auto-fix：错误信息 + 原输出回模型重生成）。
通用工程纪律：每次只改一个变量 + 回归集验证（100~200 条金标）——没有评测集的提示词优化是玄学；badcase 归类沉淀（同类问题的修法可复用）；版本化 + 灰度上线。80% 的"模型不行"最后归因都是"提示词没把任务说清楚"。
💻 全栈开发专家
提示词优化三大常见问题的对症处理（都是修过的方法）：
1. 输出不准确（内容错/幻觉）：
- 根因多是「依据不足」：补上下文（RAG 检索）、few-shot 给正确示范；
- 加约束锚点：「仅根据提供的资料」「不确定时回答不知道」；
- 降 temperature（0~0.3）；
- 复杂问题拆链：先抽取再生成，别让一个 prompt 干两件事。
2. 输出不完整（截断/偷懒）：
max_tokens不够（最直白的原因）——调大或分次生成（「继续」拼接）；- 「简洁」类指令砍伤内容：改成结构化要求（「每个字段一行，共 N 个字段必须齐全」）；
- 长任务用「先列提纲再逐节展开」的链式生成，单次生成内容越长越容易烂尾；
- 输出前自查：加「输出前检查是否覆盖了所有要点」的指令（模型自检有效）。
3. 格式错误（JSON 解析失败/格式漂移）：
- 结构化输出/API 约束解码（治本）：
with_structured_output、JSON mode、schema 约束——格式合法率接近 100%； - 解析容错（兜底）：先抽首个
{...}块再 parse；失败自动重试并把报错信息回喂（RetryOutputParser）：
python
chain = prompt | llm | parser.with_retry(
retry_if_exception_type=OutputParserException)- few-shot 给标准格式示例；明确「只输出 JSON，无其他文本」；
- 复杂 schema 拆两次调用（先抽取字段再组装），小模型一次吃不下深嵌套。
方法论：三类问题都要靠评测集定位（错误率分类统计）而不是凭感觉改——每次改动单变量、跑回归，提示词优化是实验科学。