llm-prompt-optimizer

LLM 提示词优化器

概述

此技能可将薄弱、含糊或不一致的提示词转化为经过精心设计的精确指令，从而稳定地从任意大模型（Claude、Gemini、GPT-4、Llama 等）中获得高质量输出。它运用系统化的提示词工程框架，涵盖从零样本到少样本、思维链和结构化输出模式。

何时使用此技能

• 提示词返回的结果不一致、含糊或存在幻觉时
• 需要大模型稳定输出结构化内容或 JSON 时
• 为 AI Agent 或聊天机器人设计系统提示词时
• 希望在不牺牲质量的前提下降低 Token 用量时
• 为复杂任务实现思维链推理时
• 提示词在一个模型上有效、在另一个模型上失效时

分步指南

1. 诊断薄弱的提示词

优化之前，先确定适用的问题模式：

问题	症状	修复方法
过于含糊	回答泛泛而谈，缺乏帮助	添加角色、上下文和约束
缺少结构	输出未经格式化，难以解析	明确指定输出格式
幻觉	自信地给出错误答案	添加“如果不确定，就说不知道”
不一致	每次运行的答案都不同	添加少样本示例
过长	回答冗长、充斥赘述	添加长度限制

2. 运用 RSCIT 框架

每个优化后的提示词都应包含：

• R — 角色：AI 在此次交互中扮演什么角色？
• S — 情境：它需要哪些上下文？
• C — 约束：规则和限制是什么？
• I — 指令：它具体应该做什么？
• T — 模板：输出应是什么样子？

之前（薄弱的提示词）：

Explain machine learning.

之后（优化后的提示词）：

You are a senior ML engineer explaining concepts to a junior developer.

Context: The developer has 1 year of Python experience but no ML background.

Task: Explain supervised machine learning in simple terms.

Constraints:
- Use an analogy from everyday life
- Maximum 200 words
- No mathematical formulas
- End with one actionable next step

Format: Plain prose, no bullet points.

3. 思维链（CoT）模式

对于推理任务，应要求提供简洁的解释、关键假设和可核验的结果，而不是私有的内部思维链：

Solve the problem and give the final answer with a concise explanation of the key steps and verification.

Problem: [your problem here]

Thinking process:
Step 1: [identify what's given]
Step 2: [identify what's needed]
Step 3: [apply logic or formula]
Step 4: [verify the answer]

Final Answer:

4. 少样本示例模式

提供 2-3 个示例，以明确模式：

Classify the sentiment of customer reviews as POSITIVE, NEGATIVE, or NEUTRAL.

Examples:
Review: "This product exceeded my expectations!" -> POSITIVE
Review: "It arrived broken and support was useless." -> NEGATIVE  
Review: "Product works as described, nothing special." -> NEUTRAL

Now classify:
Review: "[your review here]" ->

5. 结构化 JSON 输出模式

Extract the following information from the text below and return it as valid JSON only.
Do not include any explanation or markdown — just the raw JSON object.

Schema:
{
  "name": string,
  "email": string | null,
  "company": string | null,
  "role": string | null
}

Text: [input text here]

6. 减少幻觉模式

Answer the following question based ONLY on the provided context.
If the answer is not contained in the context, respond with exactly: "I don't have enough information to answer this."
Do not make up or infer information not present in the context.

Context:
[your context here]

Question: [your question here]

7. 提示词压缩技巧

在不降低效果的前提下减少 Token 数量：

# Verbose (expensive)
"Please carefully analyze the following code and provide a detailed explanation of 
what it does, how it works, and any potential issues you might find."

# Compressed (efficient, same quality)
"Analyze this code: explain what it does, how it works, and flag any issues."

最佳实践

• ✅ 应该： 始终指定输出格式（JSON、markdown、纯文本、项目符号列表）
• ✅ 应该： 使用分隔符（```, ---）将指令与内容分开
• ✅ 应该： 使用边界情况测试提示词（空输入、异常数据）
• ✅ 应该： 在源代码控制中为系统提示词添加版本
• ✅ 应该： 对数学、逻辑或多步骤任务添加“逐步思考”
• ❌ 不应该： 只使用否定式指令（“不要冗长”），应补充积极的替代要求
• ❌ 不应该： 假设模型了解你的代码库上下文，应始终将其包含在提示词中
• ❌ 不应该： 不经测试就在不同模型上使用同一提示词——它们的行为各不相同

提示词审查清单

在生产环境中使用提示词之前：

• 是否有清晰的角色或人设？
• 是否明确规定了输出格式？
• 是否处理了边界情况（空输入、含糊的数据）？
• 长度是否合适（不过长或过短）？
• 是否使用 5 个以上不同的输入进行过测试？
• 对于事实类任务，是否考虑了幻觉风险？

故障排除

问题： 模型忽略格式说明
解决方案： 在可用时使用受支持的结构化输出／架构约束，并使用解析器验证响应。仅靠提示词无法保证生成有效的 JSON；请限制重试次数，并处理拒绝响应或输出截断。

问题： 多次运行的结果不一致
解决方案： 降低温度设置（事实类任务设为 0.0-0.3）。添加更多少样本示例。

问题： 提示词在 playground 中有效，但在生产环境中失败
解决方案： 检查系统提示词是否正确发送。确认没有超出令牌限制（使用令牌计数器）。

问题： 输出太长
解决方案： 明确指定字数／句子数限制：“恰好用 3 个项目符号作答，每项不超过 20 个词。”

局限性

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为针对特定环境进行验证、测试或专家审核的替代品。
• 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。