prompt-engineering

提示工程

概述

使用此技能来设计清晰、可测试且可复用的提示词系统。 其中涵盖提示词起草、优化、评估，以及面向生产环境的少样本提示、推理工作流、模板和系统提示词模式。

将主要工作流保留在此文件中，并且仅在应用特定模式时加载相应的参考文件。

适用场景

在以下情况下使用此技能：

• 用户要求编写、改写或改进提示词
• 提示词需要更好的结构、可靠性或输出格式
• 需要少样本示例或推理脚手架
• 需要创建系统提示词或可复用的提示词模板
• 现有提示词需要可衡量的优化和测试

需要深入了解特定模式时，请阅读 references/ 中的相关文件。

核心模式

1. 少样本学习

示例选择策略

• 使用 references/few-shot-patterns.md 获取全面的选择框架
• 在示例数量（3-5 个为最佳）与上下文窗口限制之间取得平衡
• 在示例集中纳入边缘案例和边界条件
• 优先选择能覆盖问题空间不同变化情况的多样化示例
• 按从简单到复杂的顺序排列示例，以便逐步学习

少样本示例（情感分类）

Classify the sentiment as Positive, Negative, or Neutral.

Text: "I love this product! It exceeded my expectations."
Sentiment: Positive
Reasoning: Enthusiastic language, positive adjectives, satisfaction

Text: "The app keeps crashing when I upload large files."
Sentiment: Negative
Reasoning: Complaint about functionality, frustration indicator

Text: "It arrived on time, as described."
Sentiment: Neutral
Reasoning: Factual statement, no strong emotion either way

Text: "{user_input}"
Sentiment:
Reasoning:

2. 思维链推理

实施模式

• 参阅 references/cot-patterns.md，了解详细的推理框架
• 使用“Let's think step by step”启动零样本思维链
• 在少样本思维链演示中提供完整的推理过程
• 通过采样多条推理路径实现自一致性
• 在推理链中加入验证和确认步骤

思维链模板结构

Let's approach this step-by-step:

Step 1: {break_down_the_problem}
Analysis: {detailed_reasoning}

Step 2: {identify_key_components}
Analysis: {component_analysis}

Step 3: {synthesize_solution}
Analysis: {solution_justification}

Final Answer: {conclusion_with_confidence}

3. 提示词优化

优化流程

• 使用 references/optimization-frameworks.md 获取全面的优化策略
• 在尝试优化前衡量基线性能
• 每次只改变一个变量，以便准确归因
• 跟踪指标：准确率、一致性、延迟、令牌效率
• 使用统计显著性检验进行 A/B 验证
• 记录优化迭代及其影响

跟踪以下指标：准确率、一致性、令牌效率、鲁棒性、安全性。测量工具请参阅 references/optimization-frameworks.md。

4. 模板系统

模板设计原则

• 参阅 references/template-systems.md，了解模块化模板框架
• 使用清晰的变量命名约定（例如 {user_input}、{context}）
• 针对不同场景处理方式实现条件区段
• 为特定用例设计基于角色的模板
• 创建分层模板组合模式

模板结构示例

# System Context
You are a {role} with {expertise_level} expertise in {domain}.

# Task Context
{if background_information}
Background: {background_information}
{endif}

# Instructions
{task_instructions}

# Examples
{example_count}

# Output Format
{output_specification}

# Input
{user_query}

5. 系统提示词设计

系统提示词组件

• 使用 references/system-prompt-design.md 获取详细的设计指南
• 明确角色定义和专业能力边界
• 规定输出格式要求和结构约束
• 纳入安全指南并遵守内容政策
• 为背景信息和领域知识设定上下文

系统提示词框架

You are an expert {role} specializing in {domain} with {experience_level} of experience.

## Core Capabilities
- List specific capabilities and expertise areas
- Define scope of knowledge and limitations

## Behavioral Guidelines
- Specify interaction style and communication approach
- Define error handling and uncertainty protocols
- Establish quality standards and verification requirements

## Output Requirements
- Specify format expectations and structural requirements
- Define content inclusion and exclusion criteria
- Establish consistency and validation requirements

## Safety and Ethics
- Include content policy adherence
- Specify bias mitigation requirements
- Define harm prevention protocols

实施工作流

工作流 1：根据需求创建新提示词

1. 分析需求

   • 确定任务复杂度和推理要求
   • 判断目标模型的能力和局限
   • 定义成功标准和评估指标
   • 评估是否需要少样本学习或 CoT 推理

2. 选择模式策略

   • 对分类或转换任务使用少样本学习
   • 对复杂推理或多步骤问题应用 CoT
   • 实现可复用提示词架构的模板系统
   • 针对一致的行为要求设计系统提示词

3. 起草初始提示词

   • 采用结构清晰、逻辑连贯的提示词分节
   • 加入相关示例或推理演示
   • 指定输出格式和质量要求
   • 纳入安全指南和约束条件

4. 验证和测试

   • 使用至少 3 个输入进行测试：一个正常用例、一个边缘用例和一个对抗性用例
   • 根据定义的成功标准衡量准确率和令牌用量
   • 每次只更改一个变量，重新测试，并且只保留能改善指标的更改
   • 记录优化决策及其理由

工作流 2：优化现有提示词

1. 性能分析

   • 衡量当前提示词的性能指标
   • 找出失败模式和错误模式
   • 分析令牌效率和响应延迟
   • 评估多次运行的结果是否一致

2. 优化策略

   • 通过单变量更改进行系统化 A/B 测试
   • 使用少样本学习提高任务遵循度
   • 对复杂任务组件实施 CoT 推理
   • 优化模板结构，提升清晰度

3. 实施和测试

   • 使用步骤 1 中的相同测试用例，重新测试优化后的提示词
   • 如果准确率 < 基线，则撤销更改并尝试其他假设
   • 如果准确率 >= 基线但 < 90%，则返回步骤 2 并采用新策略
   • 记录有效更改及其测得的影响

工作流 3：扩展提示词系统

1. 模块化架构设计

   • 将复杂提示词拆分为可复用组件
   • 创建模板继承层级
   • 实现动态示例选择系统
   • 构建自动化质量保证框架

2. 生产环境集成

   • 实现提示词版本管理和回滚功能
   • 创建性能监控和告警系统
   • 构建用于提示词验证的自动化测试框架
   • 建立更新和部署工作流

质量门槛

• 发布前，在 10 个以上的不同测试用例中达到 >90% 的准确率
• 3 次以上重复运行的结果方差 <5%
• 妥善处理所有边缘用例和对抗性输入
• 每个测试用例的输出格式都符合规范

最佳实践

• 每次只优化一个变量，以便明确归因结果
• 明确说明提示词中的任务、上下文、约束条件和输出格式
• 优先采用少量高质量示例，而不是大量重复示例
• 使用正常用例、边缘用例和对抗性输入测试提示词
• 将较长的模式细节移至 references/，避免 SKILL.md 过于臃肿

约束和警告

• 不要认为提示词越长越好；额外细节往往会增加歧义
• 如果简洁的理由已足够，则避免暴露隐藏的推理要求
• 在有代表性的输入上验证提示词后，再宣称其有所改进
• 明确说明特定于模型的假设，因为不同模型的行为各不相同

与其他技能的集成

此技能可与以下技能无缝集成：

• langchain4j-ai-services-patterns：基于接口的提示词设计
• langchain4j-rag-implementation-patterns：上下文增强提示
• langchain4j-testing-strategies：提示词验证框架
• unit-test-parameterized：系统化提示词测试方法

资源和参考资料

• references/few-shot-patterns.md：全面的少样本学习框架
• references/cot-patterns.md：思维链推理模式和示例
• references/optimization-frameworks.md：系统化的提示词优化方法
• references/template-systems.md：模块化模板设计与实现
• references/system-prompt-design.md：系统提示词架构和最佳实践

常见问题及解决方案

问题	修复方法
输出格式错误	在提示词末尾添加一个具体的输出示例
答案不一致	添加 2-3 个展示预期推理方式的少样本示例
幻觉	添加“如果不确定，就说‘我不知道’”+ 限定答案范围
过于冗长	添加明确的字数/句数限制 + “简洁作答”指令
遗漏边缘情况	添加一个边缘情况的少样本示例

约束

• 在目标模型上进行测试——不同模型的能力和令牌限制各不相同
• 少样本示例控制在 3-5 个，以控制上下文用量
• 在投入生产前，使用特定领域的测试用例进行验证