prompt-engineering

提示词工程模式

高级提示词工程技术，用于最大化大模型的性能、可靠性与可控性。

核心能力

1. Few-Shot 学习

通过展示示例而非解释规则来教会模型。包含 2-5 个输入-输出对，以演示期望的行为。当你需要一致的格式、特定的推理模式或处理边缘情况时使用。更多示例可提高准确率，但会消耗 token——根据任务复杂度进行平衡。

示例：

Extract key information from support tickets:

Input: "My login doesn't work and I keep getting error 403"
Output: {"issue": "authentication", "error_code": "403", "priority": "high"}

Input: "Feature request: add dark mode to settings"
Output: {"issue": "feature_request", "error_code": null, "priority": "low"}

Now process: "Can't upload files larger than 10MB, getting timeout"

2. 思维链提示

在给出最终答案前请求逐步推理。添加“Let's think step by step”（零样本），或包含示例推理轨迹（少样本）。用于需要多步逻辑的复杂问题、数学推理，或当你需要验证模型思维过程时。可将分析类任务的准确率提高 30-50%。

示例：

Analyze this bug report and determine root cause.

Think step by step:

1. What is the expected behavior?
2. What is the actual behavior?
3. What changed recently that could cause this?
4. What components are involved?
5. What is the most likely root cause?

Bug: "Users can't save drafts after the cache update deployed yesterday"

3. 提示词优化

通过测试与改进，系统地提升提示词。从简单开始，衡量性能（准确率、一致性、token 用量），然后迭代。在包括边缘情况的多样化输入上进行测试。使用 A/B 测试比较不同变体。对于一致性和成本至关重要的生产提示词而言，这一点尤为关键。

示例：

Version 1 (Simple): "Summarize this article"
→ Result: Inconsistent length, misses key points

Version 2 (Add constraints): "Summarize in 3 bullet points"
→ Result: Better structure, but still misses nuance

Version 3 (Add reasoning): "Identify the 3 main findings, then summarize each"
→ Result: Consistent, accurate, captures key information

4. 模板系统

构建可复用的提示词结构，包含变量、条件区块和模块化组件。用于多轮对话、基于角色的交互，或同一模式适用于不同输入时。减少重复，并确保相似任务之间的一致性。

示例：

# Reusable code review template
template = """
Review this {language} code for {focus_area}.

Code:
{code_block}

Provide feedback on:
{checklist}
"""

# Usage
prompt = template.format(
    language="Python",
    focus_area="security vulnerabilities",
    code_block=user_code,
    checklist="1. SQL injection\n2. XSS risks\n3. Authentication"
)

5. 系统提示词设计

设置在整个对话中持续生效的全局行为和约束。定义模型的角色、专业水平、输出格式和安全准则。将系统提示词用于不应逐轮变化的稳定指令，从而释放用户消息 token 用于可变内容。

示例：

System: You are a senior backend engineer specializing in API design.

Rules:

- Always consider scalability and performance
- Suggest RESTful patterns by default
- Flag security concerns immediately
- Provide code examples in Python
- Use early return pattern

Format responses as:

1. Analysis
2. Recommendation
3. Code example
4. Trade-offs

关键模式

渐进式披露

从简单提示词开始，仅在需要时增加复杂度：

1. 第 1 级：直接指令

   • “总结这篇文章”

2. 第 2 级：添加约束

   • “用 3 个要点总结这篇文章，重点关注关键发现”

3. 第 3 级：添加推理

   • “阅读这篇文章，找出主要发现，然后用 3 个要点进行总结”

4. 第 4 级：添加示例

   • 包含 2-3 个带有输入-输出对的示例总结

指令层级

[System Context] → [Task Instruction] → [Examples] → [Input Data] → [Output Format]

错误恢复

构建能够优雅处理失败的提示词：

• 包含回退指令
• 请求置信度分数
• 在不确定时要求提供替代解释
• 指明如何表示信息缺失

最佳实践

1. 明确具体：含糊的提示词会产生不一致的结果
2. 展示而非讲述：示例比描述更有效
3. 广泛测试：在多样化且具有代表性的输入上进行评估
4. 快速迭代：小改动可能产生大影响
5. 监控性能：在生产环境中跟踪指标
6. 版本控制：将提示词视为代码并进行适当版本管理
7. 记录意图：解释提示词为何如此构建

常见陷阱

• 过度工程：在尝试简单提示词之前就从复杂提示词开始
• 示例污染：使用与目标任务不匹配的示例
• 上下文溢出：因示例过多而超出 token 限制
• 指令含糊：留下多种解释的空间
• 忽视边缘情况：未在不寻常或边界输入上进行测试