prompt-engineering

提示词工程模式

核心能力

1. 少样本学习

通过展示示例来教会模型，而不是解释规则。包含 2-5 组输入-输出示例，展示期望的行为。需要统一的格式、特定的推理模式或处理边缘情况时，适合使用此方法。更多示例能提高准确性，但会消耗令牌，因此应根据任务复杂度权衡。

示例：

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. 提示词优化

通过测试和改进系统性地优化提示词。从简单的提示词开始，衡量性能（准确性、一致性、令牌用量），然后迭代。使用包括边缘情况在内的多样化输入进行测试。通过 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. 系统提示词设计

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

示例：

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. 记录意图：说明提示词为何采用当前结构

常见陷阱

• 过度设计：尚未尝试简单提示词，就从复杂提示词开始
• 示例污染：使用与目标任务不匹配的示例
• 上下文溢出：示例过多，超出令牌限制
• 指令含糊：留下多种解读空间
• 忽略边缘情况：未使用异常或边界输入进行测试

内容与社交媒体提示词

设计内容生成提示词时：

• 多平台适配：设计可适用于文章、社交媒体帖子和视频脚本的提示词
• 品牌语气：加入语气和风格约束，确保生成内容风格一致
• SEO 与互动：在优化信号与真实、有吸引力的语言之间取得平衡
• 结构化输出：为批量内容工作流使用 JSON 或 markdown 模式
• 验证标准：在提示词中加入质量检查和评分标准

任务示例：

• 设计一个用于根据长篇文章生成 Twitter 串文的提示词模板
• 为生成符合品牌风格的 LinkedIn 帖子创建系统提示词
• 构建内容再利用提示词流程（文章 → 社交媒体 → 邮件）

适用场景

当用户希望改进提示词、学习提示策略、调试 Agent 行为或设计内容生成工作流时启用。

优化现有提示词时（/prompt 命令的用途）：遵循 references/prompt-optimization.md 中的系统化 4-D 工作流——拆解、诊断、开发、交付。

限制

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