【大模型提示词工程深度解析：从原理到工业级实践、实践案例】

提示词工程深度解析：从原理到工业级实践

文章标签： #ai #提示词工程 #llm原理 #prompt-engineering #rag #agent

目录

• 引言：提示词工程的本质
• 理论基础：为什么提示词能操控AI
• 来龙去脉：提示词工程的发展史
• 核心方法论深度解析
• 模型差异：不同架构的提示词策略
• 工业级实践案例
• [高级技术：System 2与Meta-Prompting](#高级技术：System 2与Meta-Prompting)
• 评估与优化体系
• 生活日用案例
• 编程专项提示词工程
• 跨行业提示词案例
• 面试题与参考答案

---

引言：提示词工程的本质

提示词工程（Prompt Engineering）不是"怎么跟AI说话"的入门技巧，而是一门控制大规模语言模型条件概率分布的工程技术。

核心认知：

LLM的本质：P(next_token | context)

提示词工程的本质：通过构造context，将模型的条件概率分布
                      从通用空间引导到特定任务空间

质量差异的根源：
- 差的提示词：context信息熵高，模型采样空间大 → 输出随机、偏离目标
- 好的提示词：context信息熵低，约束条件明确 → 输出集中在目标分布

关键洞察 ：提示词工程的效果不取决于"话术"，而取决于信息结构是否匹配模型的概率建模方式。

---

理论基础：为什么提示词能操控AI

1. Transformer架构与上下文学习

注意力机制的数学本质

# 自注意力机制的核心计算
# Q, K, V 分别代表 Query, Key, Value

Attention(Q, K, V) = softmax(QK^T / √d_k) * V

# 提示词的作用：通过token序列构造特定的Q,K,V矩阵
# 使得目标输出的token获得更高的注意力权重

关键理解：

• 每个token的表示是上下文相关的（contextualized embedding）
• 提示词中的每个token都会影响后续token的表示
• 位置编码（Positional Encoding）使得序列顺序至关重要

上下文学习（In-Context Learning, ICL）的涌现

GPT-3论文揭示的现象：模型在预训练后，仅通过提示词中的示例就能学习新任务，无需梯度更新。

ICL的数学解释（Xie et al., 2021）：

预训练数据分布：D = {(x_i, y_i)} ~ P(X,Y)
提示词中的示例：{(x_1,y_1), ..., (x_k,y_k)} 是从某个概念C中采样的

模型行为：P(y|x, examples) ≈ P(y|x, C)

即：模型通过示例隐式推断出底层概念C，然后基于此概念进行推理

工程启示：

• Few-Shot示例质量 > 数量（3-5个高质量示例通常优于20个低质量示例）
• 示例分布应与目标分布一致（分布偏移会导致ICL失效）
• 示例顺序影响注意力权重分布（recency bias）

2. 预训练、SFT、RLHF对提示词的影响

三阶段训练对提示词敏感性的影响：

阶段1 - 预训练（Pre-training）：
- 目标：next token prediction
- 提示词效果：基础语义理解，遵循简单格式
- 特点：对指令不敏感，容易生成无关内容

阶段2 - 监督微调（SFT）：
- 目标：学习(Instruction, Response)映射
- 提示词效果：学会遵循指令格式
- 特点：对明确的指令词敏感（"请解释"、"请总结"）

阶段3 - RLHF（人类反馈强化学习）：
- 目标：对齐人类偏好（helpful, harmless, honest）
- 提示词效果：理解隐含意图，拒绝有害请求
- 特点：对system prompt敏感，对角色设定响应强

关键洞察 ：RLHF后的模型对System Prompt的响应强度 > User Prompt，这是因为RLHF训练中将system message作为环境上下文。

3. 涌现能力（Emergent Abilities）与提示词复杂度

模型规模与提示词效果的关系（Wei et al., 2022）：

小模型（<10B）：
- 仅能实现简单模式匹配
- 对提示词格式极度敏感
- Few-Shot效果有限

中等模型（10B-100B）：
- ICL能力涌现
- 能理解复杂指令结构
- CoT（思维链）效果开始显现

大模型（>100B）：
- 复杂推理能力涌现
- 能理解元指令（meta-instructions）
- 支持多步推理和工具使用

超大规模（>1T，如GPT-5.5, DeepSeek-V4）：
- 涌现Agentic能力
- 能理解System 2思维
- 支持长程规划

---

来龙去脉：提示词工程的发展史

第一阶段：前提示词时代（2018-2020）

BERT/GPT-1时期，没有"提示词工程"概念：

# 2019年的"提示词"（当时叫pattern/template）
# 用于BERT做情感分析

input = "这部电影[MASK]。"  # 期望填入"很棒"或"很差"

# 本质：利用MLM（Masked Language Model）的填空能力
# 局限性：只能做特定格式的任务，不通用

第二阶段：GPT-3革命（2020-2022）

GPT-3论文（Brown et al., 2020）首次系统展示ICL：

GPT-3的关键突破：

1. 规模效应：175B参数首次展现稳定的ICL能力
2. 零样本（Zero-Shot）：直接给指令，无需示例
   "将以下英文翻译成中文：Hello world"
   
3. 少样本（Few-Shot）：提供示例引导
   "英文：Hello → 中文：你好
    英文：World → 中文：世界
    英文：Prompt Engineering → 中文："

4. 提示词即编程（Prompt as Programming）概念诞生

里程碑：2020年，提示词工程从"模板填充"进化为"上下文编程"。

第三阶段：Instruction Tuning时代（2021-2022）

FLAN、T0、InstructGPT等工作的核心思想：

Instruction Tuning的本质：

预训练模型：P(next_token | context)
SFT后模型：P(response | instruction, context)

关键改进：
- 模型学会了"指令-响应"的映射模式
- 提示词从"示例驱动"进化为"指令驱动"
- System Prompt概念引入（OpenAI API）

第四阶段：RLHF与对齐（2022-2023）

ChatGPT（2022.11）引发提示词工程爆发：

RLHF带来的提示词维度扩展：

1. 角色维度：模型学会扮演不同角色
   "你是一位资深Java架构师..."
   
2. 安全维度：模型学会拒绝有害请求
   "我不能帮你写攻击代码，但我可以解释防御原理..."
   
3. 风格维度：模型学会调整输出风格
   "用鲁迅的口吻写一段代码注释..."

4. 推理维度：CoT（Chain-of-Thought）成为标准技巧
   "请逐步思考..."

第五阶段：多模态与Agent时代（2023-2024）

GPT-4V、Claude 3、Gemini带来多模态提示词：

多模态提示词的新挑战：

1. 模态对齐：如何构造跨模态的上下文
   [图片] + "描述这张图片中的架构问题"
   
2. 空间注意力：图片中不同区域的关注度
   "请重点关注图片右上角的红色标记区域"
   
3. 时序提示：视频理解中的时间维度
   "分析视频中第3秒到第8秒的动作"

第六阶段：2026年现状

当前提示词工程的工业级特征：

2026年提示词工程的工业标准：

1. 提示词即代码（Prompt as Code）
   - 版本控制（Git管理提示词）
   - CI/CD流水线测试提示词效果
   - A/B测试框架

2. 动态提示词（Dynamic Prompting）
   - RAG：根据检索结果动态组装提示词
   - Agent：根据工具返回动态调整策略

3. 多模型编排（Multi-Model Orchestration）
   - 不同模型负责不同子任务
   - 提示词路由（Prompt Routing）
   - 模型级联（Model Cascading）

4. 提示词优化自动化
   - DSPy框架：将提示词工程编程化
   - 自动Few-Shot选择
   - 自动CoT优化

---

核心方法论深度解析

1. 信息架构：超越"角色+任务+约束"

低质量提示词的通病：机械套用模板，不理解信息结构。

高质量提示词的信息架构：

┌─────────────────────────────────────────┐
│ System Context（系统上下文）              │
│ - 模型角色定位                           │
│ - 全局约束（安全、伦理、输出规范）         │
│ - 知识边界（模型应该知道什么）             │
├─────────────────────────────────────────┤
│ Task Context（任务上下文）                │
│ - 输入数据                               │
│ - 处理逻辑（显式或隐式）                   │
│ - 输出格式要求                           │
├─────────────────────────────────────────┤
│ Demonstrations（示例）                    │
│ - 输入-输出对（Few-Shot）                 │
│ - 推理路径（CoT示例）                     │
│ - 边界案例（Negative Examples）           │
├─────────────────────────────────────────┤
│ Meta-Instructions（元指令）               │
│ - 思考方式（"逐步思考"、"多角度分析"）      │
│ - 验证要求（"检查你的答案"）               │
│ - 不确定性表达（"如果不确定，请说明"）      │
└─────────────────────────────────────────┘

工程实践 ：将提示词视为软件架构文档，每个部分都有明确的信息职责。

2. Few-Shot的贝叶斯解释与工程实践

Few-Shot有效的数学原理：

贝叶斯视角：
P(task | examples) ∝ P(examples | task) * P(task)

其中：
- P(task)：先验概率（模型预训练中学到的任务分布）
- P(examples | task)：似然（示例在给定任务下的概率）
- P(task | examples)：后验概率（看到示例后的任务推断）

Few-Shot的作用：通过示例大幅提高了P(examples | task)，
                    使得后验概率集中在目标task上

关键发现：

• 示例的标签分布影响先验（label bias）
• 示例的顺序影响注意力权重（primacy & recency bias）
• 示例与目标的相似度决定泛化效果

# 工业级Few-Shot设计原则

# 1. 示例选择策略（基于Embedding相似度）
def select_examples(query, example_pool, k=3):
    query_emb = embed(query)
    similarities = []
    for ex in example_pool:
        ex_emb = embed(ex.input)
        sim = cosine_similarity(query_emb, ex_emb)
        similarities.append((sim, ex))
    
    # 选择最相似的k个，但保持一定多样性
    return diversify_selection(similarities, k)

# 2. 示例顺序策略
# 策略A：相似度从高到低（标准做法）
# 策略B：困难示例放最后（利用recency bias）
# 策略C：随机顺序（避免位置偏见，用于评估）

# 3. 示例格式标准化
example_template = """
## 示例 {i}
输入：{input}
思考过程：{reasoning}  # CoT示例必须包含
输出：{output}
"""

3. Chain-of-Thought的认知科学基础

CoT为什么有效？不仅仅是"让模型一步步想"：

CoT有效的三个层次：

层次1 - 显式推理（Explicit Reasoning）：
- 将隐式的推理过程外化为token序列
- 每一步推理都是下一个推理的条件
- 错误可以被定位到具体步骤

层次2 - 中间监督（Intermediate Supervision）：
- 预训练数据中包含大量推理文本
- CoT触发了模型在预训练中学到的推理模式
- "让我们一步步思考"激活了特定的 attention pattern

层次3 - 计算增强（Computational Augmentation）：
- CoT增加了推理的"思考时间"（test-time compute）
- 更多token → 更多层attention计算 → 更深入的推理
- 类似于人类"在纸上写下中间步骤"的辅助思考

高级CoT技术：

## 标准CoT
"请逐步思考并解答..."

## 自一致性CoT（Self-Consistency）
"请用3种不同的方法解答这个问题，
 然后投票选择最一致的答案"

## Tree-of-Thoughts（ToT）
"对于这个问题，请探索多种解决路径：
 路径1：...
 路径2：...
 路径3：...
 评估每条路径的可行性，选择最佳方案"

## 验证式CoT（Verification）
"解答后，请检查你的答案：
 1. 检查边界条件
 2. 检查单位一致性
 3. 检查极端情况"

4. 结构化输出：约束解码与格式控制

结构化输出的技术本质：

方法1 - 提示词约束（Prompt-level）：
"请按JSON格式输出，包含以下字段..."
- 优点：灵活，无需修改模型
- 缺点：模型可能不严格遵守格式

方法2 - 约束解码（Constrained Decoding）：
在解码过程中限制token选择，确保输出符合语法
- 实现：CFG（Context-Free Grammar）约束
- 示例：Outlines库、Guidance库
- 优点：100%格式正确
- 缺点：需要特定的推理框架支持

方法3 - 后处理验证（Post-processing）：
生成后使用JSON Schema验证，失败则重试
- 优点：简单，通用
- 缺点：增加了延迟和成本

工业级实践：

# 使用Outlines进行约束解码
import outlines

model = outlines.models.transformers("meta-llama/Llama-2-7b")

# 定义JSON Schema
schema = """
{
  "type": "object",
  "properties": {
    "name": {"type": "string"},
    "age": {"type": "integer", "minimum": 0},
    "skills": {"type": "array", "items": {"type": "string"}}
  },
  "required": ["name", "age"]
}
"""

# 生成符合Schema的输出
generator = outlines.generate.json(model, schema)
result = generator("生成一个开发者的信息")
# 保证输出是合法的JSON

---

模型差异：不同架构的提示词策略

1. 架构差异对提示词的影响

Decoder-Only（GPT系列、Claude、LLaMA）：
- 特点：单向注意力，自回归生成
- 提示词策略：
  * 前缀信息（Prefix）决定生成方向
  * System Prompt效果强（作为全局上下文）
  * 对位置敏感（前面的token影响力递减）

Encoder-Decoder（T5、BART）：
- 特点：双向编码 + 自回归解码
- 提示词策略：
  * 输入和提示词在编码阶段融合
  * 更适合翻译、摘要等Seq2Seq任务
  * 对提示词位置不敏感（双向注意力）

Encoder-Only（BERT）：
- 特点：双向注意力，非生成式
- 提示词策略：
  * 模板填充（[MASK]预测）
  * 不适用于开放生成任务

2. GPT系列 vs Claude系列的提示词差异

## GPT系列（OpenAI）特点：

System Prompt权重：⭐⭐⭐⭐⭐
- 对System角色响应极强
- 适合用System Prompt设定全局行为

指令遵循：⭐⭐⭐⭐
- 对明确指令响应好
- 但有时过于"听话"，缺乏质疑

风格控制：⭐⭐⭐⭐
- 对输出风格控制较好
- 但容易陷入"AI腔"

最佳实践：

system_prompt = """

你是一位严谨的Java技术专家。

规则：

1. 所有代码必须包含异常处理

2. 必须解释设计选择的trade-off

3. 不确定时明确说明"不确定"
   """

   Claude系列（Anthropic）特点：

   System Prompt权重：⭐⭐⭐⭐

   • 也响应System Prompt，但权重略低于GPT
   • 更依赖对话历史中的上下文

   指令遵循：⭐⭐⭐⭐⭐

   • 对复杂指令理解更深
   • 擅长处理多条件约束

   风格控制：⭐⭐⭐⭐⭐

   • 自然语言风格更人类化
   • "AI腔"较轻

   最佳实践：

Claude更擅长处理长上下文中的复杂指令

prompt = """

请分析以下代码，并回答三个问题：

1. 性能瓶颈在哪里？（要求给出具体行号和优化方案）
2. 是否存在线程安全问题？（要求分析所有可能的竞态条件）
3. 是否符合SOLID原则？（要求逐条分析，不符合的要给出重构建议）

代码：

... long code ...

"""

3. 国产模型的提示词差异（深度分析）

## DeepSeek（MoE架构）

架构特点：
- 671B总参数，37B激活（MoE）
- 专家路由机制：不同token激活不同专家

提示词影响：
- 长提示词成本更低（只激活部分专家）
- 推理密集型任务需要明确激活"推理专家"

最佳策略：
```markdown
# 激活推理能力的提示词结构
"""
[System] 你是一位精通算法优化的专家

[Task] 优化以下算法

[Reasoning Mode]  
请展示完整的推理过程：
1. 先分析当前复杂度
2. 识别瓶颈操作
3. 提出优化方案并证明正确性
4. 给出复杂度分析

[Code]
...算法代码...
"""
# 明确指定"Reasoning Mode"可以引导MoE路由到推理专家

Kimi（超长上下文）

架构特点：

• 200万字上下文（约2M tokens）
• 针对长文本优化的位置编码

提示词影响：

• 对长文档的"中间部分"也能保持注意力
• 但长上下文中的指令遵循需要更强的信号

最佳策略：

# 长文档分析的提示词结构
"""
[Global Context] 
文档类型：技术设计文档
文档主题：微服务架构重构

[Local Task]
请分析第3章"服务拆分策略"，并回答：
- 拆分依据是否合理？
- 是否有遗漏的依赖分析？
- 与第5章"数据一致性方案"是否有冲突？

[Document]
[粘贴完整文档]
"""
# 关键：提供Global Context帮助模型定位，
#       明确Local Task避免在长文中迷失

GLM（双向注意力 + 自回归）

架构特点：

• GLM（General Language Model）预训练方式
• 双向注意力 + 自回归填空

提示词影响：

• 对中文语序理解更自然
• 对"填空式"提示响应好

最佳策略：

# GLM擅长的提示模式
"""
请完成以下代码填空：

public class Singleton {
    private static Singleton instance;
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        // [请填写：实现线程安全的单例]
    }
}

要求：
- 使用双重检查锁定
- 防止指令重排序
- 添加volatile关键字
"""
# GLM的双向注意力使其在"填空"任务上表现优异

### 4. 模型版本迭代的影响

提示词的"保质期"问题：

GPT-3.5 → GPT-4：

• 简单提示词即可，无需复杂的Few-Shot
• CoT效果大幅提升

GPT-4 → GPT-4o：

• 多模态提示词成为可能
• 对System Prompt的响应进一步增强

GPT-4o → GPT-5.5：

• 涌现Agentic能力
• 提示词可以包含"执行计划"和"工具调用"
• 需要新的提示词范式（Agentic Prompting）

关键原则：

• 提示词需要随模型版本迭代而迭代

• 旧模型有效的技巧在新模型上可能冗余

• 新模型可能需要更抽象的提示词（模型能力越强，需要的约束越少）

  ---

  工业级实践案例

  案例1：RAG系统中的提示词设计

  场景：企业知识库问答系统

  核心挑战：

  • 检索到的chunk可能不相关
  • 多个chunk的信息可能冲突
  • 需要区分"已知"和"未知"

  提示词工程方案：

  RAG_PROMPT_TEMPLATE = """
  ## 系统指令
  你是一位企业知识库助手。基于提供的参考资料回答用户问题。
  严格遵守以下规则：
  1. 只能使用参考资料中的信息，禁止编造
  2. 如果参考资料不足，明确说明"根据现有资料无法回答"
  3. 如果多个参考资料冲突，列出不同观点并说明来源
  4. 回答必须标注信息来源（使用[ref:X]格式）
  
  ## 参考资料
  {retrieved_chunks}
  
  ## 元信息
  - 检索置信度：{retrieval_confidence}
  - 参考资料数量：{chunk_count}
  - 用户问题类型：{question_type}  # factual/analytical/comparative
  
  ## 回答格式
  1. 直接答案（2-3句话）
  2. 详细解释（基于参考资料）
  3. 相关来源标注
  4. 信息完整性评估：
     - [ ] 完全回答
     - [ ] 部分回答（缺少：___）
     - [ ] 无法回答（原因：___）
  
  ## 用户问题
  {user_question}
  """
  
  # 关键设计点：
  # 1. 明确的约束条件（防止幻觉）
  # 2. 元信息注入（帮助模型判断信息质量）
  # 3. 结构化输出（便于后续处理）
  # 4. 自我评估（模型自检信息完整性）

评估指标：

• 忠实度（Faithfulness）：回答是否基于检索内容
• 答案相关性（Answer Relevance）：是否回答了问题
• 上下文精确率（Context Precision）：使用的chunk是否相关

案例2：AI Agent的提示词编排系统

场景：自动化软件工程Agent

核心架构：

Agent提示词编排系统：

┌─────────────────────────────────────┐
│  Planner（规划器）                   │
│  Prompt: "将任务分解为可执行步骤"     │
├─────────────────────────────────────┤
│  Executor（执行器）                  │
│  Prompt: "执行当前步骤，调用工具"     │
├─────────────────────────────────────┤
│  Reflector（反思器）                 │
│  Prompt: "检查结果，识别错误"         │
├─────────────────────────────────────┤
│  Memory（记忆管理）                   │
│  Prompt: "提取关键信息，更新状态"     │
└─────────────────────────────────────┘

Planner提示词设计：

PLANNER_PROMPT = """
## 角色
你是一位资深软件架构师，擅长任务分解和风险评估。

## 任务
将以下复杂开发任务分解为可执行的子任务。

## 分解原则
1. 每个子任务必须是原子的（不可再分）
2. 子任务之间有明确的依赖关系
3. 每个子任务必须可验证（有明确的完成标准）
4. 预估每个子任务的复杂度（1-10）

## 输出格式（JSON）
{
  "tasks": [
    {
      "id": "T1",
      "description": "任务描述",
      "dependencies": [],  # 依赖的任务ID
      "complexity": 5,
      "verification": "验证标准",
      "tools": [" needed tools"]
    }
  ],
  "risks": [
    {
      "description": "风险描述",
      "mitigation": "缓解策略"
    }
  ]
}

## 当前任务
{task_description}

## 可用工具
{available_tools}

## 项目上下文
{project_context}
"""

关键洞察 ：Agent的提示词设计核心是状态管理 和控制流，而非单次问答。

案例3：代码生成管道的提示词优化

场景：AI辅助编程工具（类似GitHub Copilot）

Pipeline设计：

class CodeGenerationPipeline:
    """
    多阶段代码生成管道
    """
    
    def stage1_requirement_analysis(self, user_prompt):
        """阶段1：需求分析"""
        prompt = f"""
        分析以下编程需求，提取关键信息：
        
        需求：{user_prompt}
        
        请输出：
        1. 功能需求（必须实现的功能）
        2. 非功能需求（性能、安全、可维护性）
        3. 输入/输出规范
        4. 边界条件
        5. 依赖分析（需要的库/框架）
        """
        return self.llm.generate(prompt)
    
    def stage2_design(self, requirements):
        """阶段2：架构设计"""
        prompt = f"""
        基于以下需求，设计代码架构：
        
        {requirements}
        
        请输出：
        1. 类/接口设计（UML文本表示）
        2. 数据流图
        3. 关键算法选择及理由
        4. 错误处理策略
        """
        return self.llm.generate(prompt)
    
    def stage3_implementation(self, design):
        """阶段3：代码实现"""
        prompt = f"""
        基于以下设计，生成可运行的代码：
        
        {design}
        
        代码要求：
        - 使用Java 17
        - 遵循Google Java Style
        - 包含完整的Javadoc
        - 包含单元测试（JUnit 5）
        - 处理所有边界条件
        
        请生成完整代码，不要省略任何部分。
        """
        return self.llm.generate(prompt)
    
    def stage4_review(self, code):
        """阶段4：代码审查"""
        prompt = f"""
        审查以下代码，检查：
        1. 是否存在安全漏洞（SQL注入、XSS、越权等）
        2. 是否存在性能问题（N+1查询、内存泄漏等）
        3. 是否符合设计模式最佳实践
        4. 测试覆盖率是否充分
        
        代码：
        {code}
        
        请按严重程度列出问题，并提供修复后的代码。
        """
        return self.llm.generate(prompt)

优化策略：

• 每个阶段有明确的输入/输出契约
• 阶段间通过结构化数据（JSON/XML）传递
• 支持人机协作（在每个阶段允许人工干预）

案例4：多轮对话中的上下文管理

场景：客服对话系统

核心挑战：

• 长对话历史导致上下文窗口溢出
• 早期重要信息被遗忘
• 话题切换时的状态管理

解决方案：

class ConversationContextManager:
    """
    对话上下文管理器
    """
    
    def __init__(self, max_tokens=8000):
        self.max_tokens = max_tokens
        self.summary = ""  # 对话摘要
        self.key_facts = {}  # 关键事实（KV存储）
        self.raw_history = []  # 原始历史
    
    def add_turn(self, user_msg, assistant_msg):
        """添加一轮对话"""
        # 1. 提取关键事实
        facts = self.extract_facts(user_msg, assistant_msg)
        self.key_facts.update(facts)
        
        # 2. 更新摘要
        self.summary = self.update_summary(
            self.summary, user_msg, assistant_msg
        )
        
        # 3. 存储原始历史
        self.raw_history.append((user_msg, assistant_msg))
        
        # 4. 如果超出token限制，压缩历史
        if self.estimate_tokens() > self.max_tokens:
            self.compress_history()
    
    def build_prompt(self, current_query):
        """构建当前提示词"""
        prompt = f"""
## 对话摘要
{self.summary}

## 已知关键信息
{self.format_facts()}

## 最近对话（按时间倒序，最近的在前）
{self.get_recent_history(k=3)}

## 当前用户问题
{current_query}

## 回答要求
- 参考"已知关键信息"，不要要求用户重复已提供的信息
- 保持与"对话摘要"一致的语气和风格
- 如果问题与之前话题相关，保持上下文连贯性
"""
        return prompt
    
    def extract_facts(self, user_msg, assistant_msg):
        """提取关键事实"""
        extract_prompt = f"""
        从以下对话中提取关键事实（用JSON格式）：
        
        用户：{user_msg}
        助手：{assistant_msg}
        
        提取规则：
        - 用户个人信息（姓名、账号、订单号等）
        - 问题状态（已解决/待处理/需要跟进）
        - 承诺事项（回复时间、处理结果等）
        
        输出格式：{{"key": "value"}}
        """
        return json.loads(self.llm.generate(extract_prompt))

---

高级技术：System 2与Meta-Prompting

1. System 2 Prompting（慢思考）

Kahneman的双系统理论在提示词工程中的应用：

System 1（快思考）：
- 直觉、自动、快速
- 对应：标准提示词，直接生成

System 2（慢思考）：
- 分析、努力、缓慢
- 对应：复杂的推理提示词

System 2 Prompting技术：

## 标准提示词（System 1）
"请评估以下架构方案的风险"

## System 2 Prompting
"""
请使用系统2思考方式评估以下架构方案：

步骤1 - 分解：
将架构拆分为独立组件，逐一分析

步骤2 - 多角度分析：
- 安全性角度：...
- 性能角度：...
- 可维护性角度：...
- 成本角度：...

步骤3 - 假设检验：
- 如果用户量增长10倍？
- 如果某个服务宕机？
- 如果数据需要迁移？

步骤4 - 综合评估：
基于以上分析，给出风险等级（高/中/低）和具体理由

架构方案：
[...]
"""

2. Meta-Prompting（提示词生成提示词）

META_PROMPT_TEMPLATE = """
## 任务
你是一个提示词工程专家。请为以下任务生成最优的提示词。

## 目标 task
{original_task}

## 生成要求
请生成一个提示词，该提示词需要：
1. 明确指定AI的角色和专业知识领域
2. 包含具体的任务描述和约束条件
3. 提供输出格式规范
4. 包含质量检查要求
5. 考虑边界情况和错误处理

## 输出格式
请按以下结构输出：

### 角色定义
...

### 任务描述
...

### 约束条件
...

### 输出格式
...

### 质量检查
...

### 示例（可选）
...
"""

# 使用示例：
# 1. 用Meta-Prompt生成任务提示词
# 2. 用生成的提示词执行任务
# 3. 评估结果，如果不好，调整Meta-Prompt
# 4. 迭代优化

3. Prompt Chaining与DAG工作流

from dataclasses import dataclass
from typing import List, Dict, Callable
import networkx as nx

@dataclass
class PromptNode:
    """提示词节点"""
    id: str
    prompt_template: str
    output_parser: Callable
    next_nodes: List[str]

class PromptDAG:
    """提示词有向无环图执行引擎"""
    
    def __init__(self):
        self.graph = nx.DiGraph()
        self.nodes: Dict[str, PromptNode] = {}
        self.context = {}  # 共享上下文
    
    def add_node(self, node: PromptNode):
        self.nodes[node.id] = node
        self.graph.add_node(node.id)
    
    def add_edge(self, from_id: str, to_id: str):
        self.graph.add_edge(from_id, to_id)
    
    def execute(self, start_node: str, initial_input: str):
        """执行DAG"""
        # 拓扑排序确保依赖顺序
        execution_order = list(nx.topological_sort(self.graph))
        
        # 从start_node开始执行
        start_idx = execution_order.index(start_node)
        
        for node_id in execution_order[start_idx:]:
            node = self.nodes[node_id]
            
            # 构建提示词（注入上下文）
            prompt = node.prompt_template.format(
                input=initial_input if node_id == start_node else "",
                context=self.context
            )
            
            # 执行LLM
            raw_output = self.llm.generate(prompt)
            
            # 解析输出
            parsed_output = node.output_parser(raw_output)
            
            # 更新上下文
            self.context[node_id] = parsed_output
            
            # 检查是否需要终止
            if self.should_terminate(parsed_output):
                break
        
        return self.context
    
    def should_terminate(self, output) -> bool:
        """终止条件检查"""
        # 例如：如果输出包含"完成"或"结束"
        return "任务完成" in str(output)

# 使用示例：构建一个代码审查Pipeline
dag = PromptDAG()

# 节点1：代码分析
dag.add_node(PromptNode(
    id="analyze",
    prompt_template="""
    分析以下代码的复杂度：
    {input}
    输出：时间复杂度、空间复杂度、潜在瓶颈
    """,
    output_parser=lambda x: json.loads(x),
    next_nodes=["security", "performance"]
))

# 节点2：安全审查（并行）
dag.add_node(PromptNode(
    id="security",
    prompt_template="""
    检查以下代码的安全漏洞：
    {input}
    已知复杂度：{context[analyze]}
    输出：漏洞列表及修复建议
    """,
    output_parser=lambda x: x,
    next_nodes=["report"]
))

# 节点3：性能优化（并行）
dag.add_node(PromptNode(
    id="performance",
    prompt_template="""
    优化以下代码的性能：
    {input}
    已知复杂度：{context[analyze]}
    输出：优化后的代码及性能提升分析
    """,
    output_parser=lambda x: x,
    next_nodes=["report"]
))

# 节点4：生成报告（依赖security和performance）
dag.add_node(PromptNode(
    id="report",
    prompt_template="""
    综合以下分析结果生成审查报告：
    复杂度分析：{context[analyze]}
    安全审查：{context[security]}
    性能优化：{context[performance]}
    输出：结构化审查报告
    """,
    output_parser=lambda x: x,
    next_nodes=[]
))

# 构建依赖关系
dag.add_edge("analyze", "security")
dag.add_edge("analyze", "performance")
dag.add_edge("security", "report")
dag.add_edge("performance", "report")

# 执行
result = dag.execute("analyze", user_code)

---

评估与优化体系

1. 提示词A/B测试框架

class PromptABTest:
    """提示词A/B测试框架"""
    
    def __init__(self, prompt_a, prompt_b, evaluator):
        self.prompt_a = prompt_a
        self.prompt_b = prompt_b
        self.evaluator = evaluator
        self.results = {"A": [], "B": []}
    
    def run_test(self, test_cases, n=100):
        """
        执行A/B测试
        
        test_cases: [(input, expected_output), ...]
        n: 每个测试用例的采样次数
        """
        for test_input, expected in test_cases:
            for _ in range(n):
                # 随机分配A或B（50/50）
                variant = random.choice(["A", "B"])
                prompt = self.prompt_a if variant == "A" else self.prompt_b
                
                # 执行
                actual = self.llm.generate(prompt.format(input=test_input))
                
                # 评估
                score = self.evaluator.evaluate(actual, expected)
                self.results[variant].append(score)
        
        # 统计分析
        self.analyze_results()
    
    def analyze_results(self):
        """统计分析"""
        from scipy import stats
        
        scores_a = self.results["A"]
        scores_b = self.results["B"]
        
        # t检验
        t_stat, p_value = stats.ttest_ind(scores_a, scores_b)
        
        print(f"Prompt A 平均分: {np.mean(scores_a):.3f} (±{np.std(scores_a):.3f})")
        print(f"Prompt B 平均分: {np.mean(scores_b):.3f} (±{np.std(scores_b):.3f})")
        print(f"t统计量: {t_stat:.3f}, p值: {p_value:.3f}")
        
        if p_value < 0.05:
            winner = "A" if np.mean(scores_a) > np.mean(scores_b) else "B"
            print(f"统计显著！Prompt {winner} 更优")
        else:
            print("差异不显著")

2. 提示词版本管理

# prompt_versions.yaml

system_name: customer_service_bot

versions:
  v1.0.0:
    created: 2024-01-15
    prompt: "你是一个客服助手..."
    model: gpt-3.5-turbo
    metrics:
      accuracy: 0.75
      user_satisfaction: 3.8/5
    
  v1.1.0:
    created: 2024-02-20
    prompt: "你是一位专业的客服代表..."
    model: gpt-4
    metrics:
      accuracy: 0.82
      user_satisfaction: 4.2/5
    changes: "增加了角色设定和输出格式要求"
    
  v2.0.0:
    created: 2024-06-10
    prompt: "system: 你是一位资深客服专家..."
    model: gpt-4o
    metrics:
      accuracy: 0.89
      user_satisfaction: 4.6/5
    changes: 
      - "使用System Prompt分离角色和任务"
      - "增加Few-Shot示例"
      - "增加自我验证要求"
    
  v3.0.0:
    created: 2026-05-01
    prompt: "system: 你是一位多语言客服专家..."
    model: gpt-5.5
    metrics:
      accuracy: 0.94
      user_satisfaction: 4.8/5
    changes:
      - "升级到GPT-5.5"
      - "增加Agentic能力（工具调用）"
      - "动态Few-Shot选择"

# 版本控制最佳实践：
# 1. 使用语义化版本号（MAJOR.MINOR.PATCH）
# 2. 记录每次变更的具体内容和原因
# 3. 保留历史版本的性能指标
# 4. 支持快速回滚

3. 自动化评估指标

class PromptEvaluator:
    """提示词自动化评估器"""
    
    def __init__(self):
        self.metrics = {}
    
    def evaluate(self, predicted, reference, context=None):
        """
        综合评估生成质量
        """
        results = {}
        
        # 1. 语义相似度（基于Embedding）
        results["semantic_similarity"] = self.semantic_sim(predicted, reference)
        
        # 2. 格式正确性（JSON/XML/schema验证）
        results["format_correctness"] = self.check_format(predicted)
        
        # 3. 事实一致性（RAG场景）
        if context:
            results["factuality"] = self.check_factuality(predicted, context)
        
        # 4. 指令遵循度
        results["instruction_following"] = self.check_instructions(predicted)
        
        # 5. 流畅度（困惑度）
        results["fluency"] = self.calculate_perplexity(predicted)
        
        # 6. 安全性（毒性、偏见检测）
        results["safety"] = self.safety_check(predicted)
        
        return results
    
    def semantic_sim(self, pred, ref):
        """基于Embedding的语义相似度"""
        pred_emb = self.embedding_model.encode(pred)
        ref_emb = self.embedding_model.encode(ref)
        return cosine_similarity([pred_emb], [ref_emb])[0][0]
    
    def check_format(self, text):
        """检查输出格式"""
        try:
            json.loads(text)
            return 1.0
        except:
            return 0.0
    
    def check_factuality(self, pred, context):
        """基于NLI的事实一致性检查"""
        # 使用NLI模型判断预测是否被上下文支持
        # entailment: 支持, contradiction: 矛盾, neutral: 不确定
        pass
    
    def check_instructions(self, pred):
        """检查是否遵循了指令要求"""
        # 使用另一个LLM判断
        check_prompt = f"""
        判断以下输出是否遵循了指令要求：
        
        指令：{self.original_instruction}
        输出：{pred}
        
        请输出：遵循/部分遵循/未遵循，并说明理由。
        """
        result = self.llm.generate(check_prompt)
        return self.parse_judgement(result)

---

生活日用案例

场景1：个人财务管理助手

## 角色
你是一位专业的个人财务规划师，擅长家庭预算管理和投资建议。

## 背景信息
- 用户月收入：15000元
- 所在城市：二线城市
- 家庭状况：已婚，无子女，有房贷（月供5000元）
- 现有资产：存款5万元，无投资经验
- 风险承受能力：中等（能接受短期10%以内亏损）

## 任务
请为用户制定一份详细的月度理财规划方案。

## 输出要求
1. 月度收支明细表（分类：必要支出/可选支出/储蓄投资）
2. 3个月、6个月、12个月的储蓄目标
3. 适合新手的投资产品推荐（从低风险到中等风险）
4. 应急资金配置建议
5. 用Markdown表格呈现，语言通俗易懂

## 约束
- 必须保证每月生活质量（餐饮、交通、通讯等基础开支不低于3000元）
- 投资产品必须说明风险和预期收益
- 不要推荐P2P、虚拟货币等高风险产品

场景2：健康管理与饮食规划

## 角色
你是一位注册营养师兼健身教练，擅长根据体质定制健康方案。

## 用户信息
- 性别：男，30岁
- 身高体重：175cm，78kg（BMI约25.4，轻度超重）
- 目标：3个月内减重5kg，同时增肌
- 运动基础：每周跑步2次，每次3km
- 饮食偏好：不吃辣，对海鲜过敏
- 工作性质：程序员，久坐，加班较多

## 任务
请制定一套"可执行"的3个月健康改善计划。

## 输出要求
1. 每周运动计划（具体到时间、项目、强度）
2. 一周食谱（三餐+加餐，标注热量和蛋白质）
3. 办公室微运动建议（每小时的简单动作）
4. 加班场景下的健康饮食方案
5. 进度追踪表模板（每周记录体重、体脂、运动量）

## 特别要求
- 考虑到程序员工作时间不固定，方案要有弹性
- 所有食谱必须是常见食材，容易购买
- 每餐准备时间不超过30分钟

场景3：子女教育规划

## 角色
你是一位有10年经验的教育规划师，熟悉国内教育体系和升学路径。

## 背景
- 孩子年龄：8岁，小学二年级
- 所在地区：一线城市
- 孩子特点：数学思维好，英语薄弱，喜欢画画
- 家庭期望：希望孩子全面发展，不强求顶尖名校，但希望有好的教育基础
- 预算：每年课外教育投入不超过3万元

## 任务
请制定一份从二年级到六年级的长期教育规划。

## 输出要求
1. 各学科能力培养路线图（按年级分解目标）
2. 兴趣班选择建议（结合孩子特点和家庭预算）
3. 英语提升方案（从薄弱到中等偏上的具体路径）
4. 升学准备时间节点（小升初、各类竞赛、证书）
5. 每年的时间分配建议（学习/兴趣/运动/休息）

## 约束
- 必须保证孩子每天有1小时户外活动时间
- 不要推荐超前学习（如二年级学四年级内容）
- 所有建议必须符合"双减"政策要求

场景4：家庭旅行规划

## 角色
你是一位资深旅行规划师，擅长家庭出游的行程设计。

## 需求
- 出发地：北京
- 时间：国庆假期，共7天
- 人数：4人（夫妻+两个孩子，6岁和10岁）
- 预算：总预算2万元（不含购物）
- 偏好：自然风光+轻度人文，避开人挤人的热门景点
- 孩子兴趣：动物、海滩、互动体验项目

## 任务
请设计一套完整的国庆出游方案。

## 输出要求
1. 目的地推荐（2-3个备选方案，说明优缺点）
2. 详细行程（每天上午/下午/晚上安排）
3. 交通方案（含预估费用）
4. 住宿推荐（亲子友好型）
5. 行李清单（按成人/儿童分类）
6. 应急预案（雨天方案、孩子生病处理）

## 特别要求
- 每天车程不超过3小时
- 必须有孩子能参与的体验项目（不只是看风景）
- 住宿地点附近要有便利店/药店

场景5：法律文书初稿生成

## 角色
你是一位熟悉民法典的法律工作者，擅长起草常见法律文书。

## 背景
- 文书类型：房屋租赁合同
- 出租方：个人房东
- 承租方：个人租户
- 房屋信息：两居室，月租金4000元，押一付三
- 租期：1年
- 特殊条款需求：不允许养宠物，不允许转租

## 任务
请起草一份规范的房屋租赁合同。

## 输出要求
1. 合同正文（包含所有必要条款）
2. 补充说明（每个条款的法律依据）
3. 双方权利义务清单
4. 违约责任和争议解决条款
5. 交付清单模板（家具家电清单）

## 约束
- 合同条款必须符合《民法典》规定
- 不得包含无效条款（如"押金不退"等霸王条款）
- 语言正式但通俗易懂
- 标注需要双方协商留空的字段（如身份证号、房屋地址等）

---

编程专项提示词工程

Java后端开发

## 角色
你是一位有8年经验的Java后端架构师，精通Spring Boot、微服务设计和性能优化。

## 任务
请设计并实现一个用户权限管理模块。

## 需求规格
1. 支持RBAC模型（用户-角色-权限）
2. 支持数据权限（行级、字段级）
3. 支持权限缓存（Redis）
4. 支持权限变更实时生效
5. 接口需要支持Spring Security集成

## 技术要求
- Java 17
- Spring Boot 3.x
- MyBatis Plus
- Redis 7.x
- 必须包含完整的单元测试（JUnit 5 + Mockito）

## 输出要求
1. 数据库表设计（DDL + ER图文本表示）
2. 核心实体类（含Javadoc和Validation注解）
3. Service层实现（含事务管理）
4. Controller层（RESTful API + Swagger注解）
5. 权限注解和AOP拦截器
6. 缓存策略和失效机制
7. 单元测试（覆盖率不低于80%）

## 代码规范
- 遵循阿里巴巴Java开发手册
- 所有方法必须有Javadoc
- 使用Lombok减少样板代码
- 异常统一处理（GlobalExceptionHandler）

Python数据分析

## 角色
你是一位资深数据分析师，擅长使用Python进行数据清洗、分析和可视化。

## 任务
分析某电商平台的用户行为数据，找出提升转化率的关键因素。

## 数据说明
- 数据文件：user_behavior.csv（100万行）
- 字段：user_id, action_type, product_id, timestamp, device, channel, amount
- action_type枚举：view, click, add_cart, purchase, refund

## 分析目标
1. 用户转化漏斗分析（从浏览到购买的转化率）
2. 各渠道的转化效率对比
3. 用户行为路径分析（常见的购买路径模式）
4. 高价值用户特征画像
5. 流失用户预警指标

## 输出要求
1. 完整可运行的Python代码（使用pandas + matplotlib/seaborn）
2. 数据清洗和预处理流程
3. 每个分析结果的图表（保存为PNG）
4. 关键发现的文字说明
5. 可落地的业务建议（至少3条）

## 代码规范
- 使用类型注解
- 每个函数有docstring
- 关键步骤添加日志输出
- 内存优化（考虑100万行数据的处理效率）

Go微服务开发

## 角色
你是一位Go语言专家，擅长高并发微服务开发和云原生架构。

## 任务
实现一个分布式订单服务。

## 需求规格
1. 支持订单创建、查询、取消、退款
2. 支持库存扣减（分布式事务）
3. 支持订单状态机（待支付/已支付/已发货/已完成/已取消）
4. 支持订单超时自动取消
5. 支持幂等性（防止重复下单）

## 技术栈
- Go 1.22+
- gRPC + Protocol Buffers
- PostgreSQL + GORM
- Redis（分布式锁 + 缓存）
- Kafka（事件驱动）
- Docker

## 输出要求
1. Proto文件定义
2. 领域模型（DDD风格）
3. Repository层（接口+实现）
4. Service层（含业务逻辑和事务）
5. Handler层（gRPC实现）
6. 分布式锁实现（Redis RedLock）
7. 单元测试（gomock + testify）
8. Dockerfile

## 特别要求
- 使用Go的context处理超时和取消
- 错误处理遵循Go的error best practices
- 包含链路追踪的trace_id传递
- 配置使用Viper管理

前端Vue3开发

## 角色
你是一位前端架构师，精通Vue3、TypeScript和现代化前端工程化。

## 任务
开发一个数据可视化Dashboard。

## 功能需求
1. 实时数据展示（WebSocket推送）
2. 多种图表类型（折线图、柱状图、饼图、地图）
3. 数据筛选和时间段选择
4. 图表联动（点击一个图表，其他图表联动过滤）
5. 响应式布局（适配PC和平板）
6. 暗色/亮色主题切换

## 技术栈
- Vue 3 + Composition API
- TypeScript（严格的tsconfig）
- Vite
- ECharts 5
- Element Plus / Ant Design Vue
- Pinia（状态管理）
- Axios + 请求拦截

## 输出要求
1. 项目结构和文件组织
2. 核心组件（DashboardLayout、ChartCard、FilterPanel）
3. Composable（useWebSocket、useChart、useTheme）
4. Store设计（Pinia模块化）
5. 类型定义（interface + type）
6. 路由配置
7. 关键CSS（CSS变量实现主题切换）

## 代码规范
- 所有组件使用<script setup>语法
- Props使用withDefaults和类型定义
- 使用emit定义组件事件
- 性能优化（useMemo、watchEffect cleanup）

DevOps/SRE脚本

## 角色
你是一位资深DevOps工程师，精通Shell脚本、Python自动化和云原生运维。

## 任务
编写一套生产环境日志分析和告警脚本。

## 需求规格
1. 实时分析Nginx访问日志（每秒请求数、错误率、慢请求）
2. 检测异常模式（IP黑名单、SQL注入特征、爬虫行为）
3. 自动告警（企业微信/钉钉/飞书）
4. 生成日报（Top 10接口、错误分布、性能趋势）
5. 日志归档（按天压缩，保留30天）

## 技术要求
- 主脚本：Python 3.10+
- 辅助：Shell + awk/sed
- 配置：YAML格式
- 告警：Webhook
- 部署：Systemd服务

## 输出要求
1. 主分析脚本（log_analyzer.py）
2. 配置文件（config.yaml）
3. 告警模块（alert.py，支持多种渠道）
4. 日报生成脚本（daily_report.py）
5. 日志归档脚本（archive.sh）
6. Systemd服务文件
7. 部署文档（安装、配置、启动）

## 特别要求
- 支持多进程/多线程处理大日志文件
- 内存使用不超过500MB
- 错误处理完善（不因为单条日志格式错误而崩溃）
- 包含日志轮转（logrotate）配置

---

跨行业提示词案例

产品经理：PRD文档生成

## 角色
你是一位资深B端产品经理，擅长SaaS产品设计和需求文档编写。

## 背景
- 产品：企业级CRM系统
- 目标用户：中小型企业的销售团队（5-50人）
- 竞品：Salesforce、HubSpot、纷享销客
- 差异化：更强的微信生态集成、更低的定价

## 任务
撰写一份"客户跟进管理"模块的PRD文档。

## 输出要求
1. 需求背景和目标（Why）
2. 用户故事（User Stories，至少5个）
3. 功能清单（Feature List，含优先级P0/P1/P2）
4. 核心流程图（用文本流程图表示）
5. 页面原型描述（关键页面的布局、元素、交互）
6. 数据需求（需要存储的数据结构）
7. 非功能需求（性能、安全、兼容性）
8. 验收标准（Acceptance Criteria）
9. 风险评估和应对方案

## 格式要求
- 使用标准PRD模板
- 每个功能点必须有"价值说明"（解决什么痛点）
- 交互描述使用"当...时，系统..."格式
- 标注需要设计团队确认的内容

UI/UX设计师：设计规范生成

## 角色
你是一位资深UI设计师，擅长设计系统（Design System）的构建。

## 背景
- 产品：金融理财App
- 品牌调性：专业、可信赖、现代
- 目标用户：25-40岁，有一定理财需求的白领
- 设计工具：Figma

## 任务
生成一套完整的移动端设计规范文档。

## 输出要求
1. 色彩系统
   - 主色、辅助色、功能色（成功/警告/错误/信息）
   - 每种颜色的Hex值、使用场景、对比度说明
2. 字体规范
   - 中文字体、英文字体
   - 标题/正文/辅助文字的字号、字重、行高
3. 间距系统
   - 8px网格系统
   - 各组件的内边距、外边距标准
4. 组件规范
   - Button（主按钮/次按钮/文字按钮，各种状态）
   - Input（正常/聚焦/错误/禁用）
   - Card（列表卡片、详情卡片）
   - Navigation（底部Tab、顶部导航）
5. 图标规范
   - 风格（线性/面性）
   - 尺寸（16/24/32px）
   - 描边粗细
6. 交互规范
   - 按钮点击反馈（水波纹/缩放）
   - 页面转场动画
   - 加载状态
7. 可访问性要求
   - 最小触摸区域（44x44pt）
   - 颜色对比度（WCAG AA标准）

## 格式
- 用Markdown表格呈现色彩和字体
- 每个组件用文字描述+ASCII示意图
- 标注Figma中的图层命名规范

跨境电商：多语言Listing优化

## 角色
你是一位亚马逊/Shopify运营专家，擅长跨境电商Listing优化和多语言营销。

## 产品信息
- 产品：便携式折叠自行车
- 目标市场：美国、德国、日本
- 售价：$299
- 核心卖点：可折叠（折叠后仅占0.1m³）、重量8.5kg、铝合金车架、7速变速
- 适用人群：城市通勤者、学生、短途出行

## 任务
为三个市场分别优化产品Listing。

## 输出要求（每个市场独立输出）

### 1. 英文Listing（美国市场）
- 标题（200字符以内，含核心关键词）
- 五点描述（Bullet Points，突出卖点和场景）
- 产品描述（A+ Content结构，HTML格式）
- 后台关键词（Search Terms，250字节以内）
- 广告关键词建议（高转化长尾词）

### 2. 德文Listing（德国市场）
- 同上结构，德文输出
- 注意德国消费者偏好（环保、质量认证、详细参数）

### 3. 日文Listing（日本市场）
- 同上结构，日文输出
- 注意日本消费者偏好（细节描述、鞠躬文化、敬语使用）

## 特别要求
- 每个市场的文案风格必须符合当地文化
- 避免直译，要"本土化"
- 包含SEO关键词布局策略
- 标注可能的文化禁忌（颜色、数字、图案等）

量化交易：策略回测框架

## 角色
你是一位量化交易研究员，擅长Python量化策略开发和回测分析。

## 背景
- 交易市场：A股市场
- 数据：日K线数据（OHLCV），包含沪深300成分股
- 回测区间：2020-01-01 至 2024-12-31
- 初始资金：100万元

## 策略需求
开发一个"双均线交叉+成交量确认"的趋势跟踪策略。

## 策略逻辑
1. 短期均线（5日）上穿长期均线（20日）→ 买入信号
2. 买入时要求成交量大于20日均量的1.5倍（确认趋势）
3. 短期均线下穿长期均线 → 卖出信号
4. 止损：买入价下跌8%时强制平仓
5. 仓位管理：每只标的最多投入总资金的10%
6. 最多同时持有10只标的

## 输出要求
1. 完整的Python回测代码（使用Backtrader或VectorBT）
2. 数据获取和预处理模块
3. 策略实现（SignalStrategy）
4. 回测执行脚本
5. 绩效分析报告：
   - 总收益率、年化收益率
   - 最大回撤、夏普比率
   - 胜率、盈亏比
   - 月度收益分布图
   - 回测净值曲线图
6. 参数敏感性分析（不同均线组合的对比）

## 代码规范
- 使用类型注解
- 每个函数有docstring
- 参数外部化（YAML配置文件）
- 包含数据校验（防止未来函数使用）
- 交易记录导出为CSV

医生/医疗：病历辅助整理

## 角色
你是一位有丰富临床经验的内科医生，擅长病历书写和诊疗思路整理。

## 背景
- 患者主诉：反复上腹部疼痛2个月，饭后加重
- 现病史：患者2个月前无明显诱因出现上腹部隐痛，进食后加重，伴嗳气、反酸，无恶心呕吐，无黑便，体重下降约3kg
- 既往史：高血压病史5年，规律服用氨氯地平
- 查体：上腹部轻压痛，无反跳痛，肝脾未触及
- 辅助检查：胃镜示"慢性萎缩性胃炎伴肠化生"，幽门螺杆菌阳性

## 任务
1. 整理成规范的病历格式（SOAP格式）
2. 给出鉴别诊断思路（至少3种可能）
3. 制定诊疗计划
4. 给出患者教育要点

## 输出要求
1. 主诉（Chief Complaint）
2. 现病史（History of Present Illness，按时间顺序整理）
3. 既往史/个人史/家族史
4. 体格检查（重点突出阳性体征）
5. 辅助检查（分门别类列出）
6. 初步诊断（ICD-10编码）
7. 鉴别诊断（含支持点和排除点）
8. 诊疗计划（检查/用药/随访）
9. 患者教育（饮食/生活方式/用药依从性）

## 约束
- 所有医学术语必须准确
- 鉴别诊断要有逻辑性（按可能性排序）
- 用药建议必须说明剂量、疗程、注意事项
- 必须提醒定期复查胃镜（萎缩性胃炎伴肠化生属癌前病变）
- 最后声明："本内容仅供医学学习参考，实际诊疗请遵医嘱"

律师：合同审查清单

## 角色
你是一位擅长商业合同的律师，熟悉《民法典》合同编和公司法律实务。

## 背景
- 合同类型：软件开发外包合同
- 甲方：某互联网公司（委托方）
- 乙方：某软件外包公司（承接方）
- 合同金额：50万元
- 交付物：一个电商小程序
- 工期：3个月

## 任务
请提供一份全面的合同审查清单和风险提示。

## 输出要求
1. 主体资格审查要点
   - 营业执照、资质证书
   - 签约人授权
   - 履约能力评估
2. 核心条款审查
   - 工作范围（SOW）是否清晰
   - 交付标准和验收条件
   - 付款节点和比例
   - 知识产权归属
   - 保密条款
   - 违约责任
   - 争议解决（仲裁/诉讼）
3. 风险识别（高风险/中风险/低风险）
   - 需求变更风险
   - 延期交付风险
   - 质量不达标风险
   - 人员流动风险
   - 数据安全风险
4. 修改建议
   - 针对每个风险点给出具体修改建议
   - 提供修改后的条款范本
5. 谈判要点
   - 哪些条款必须坚持
   - 哪些条款可以妥协
   - 谈判话术建议

## 格式
- 使用表格呈现风险等级和修改建议
- 每个条款都要有"法律依据"说明
- 标注需要向客户确认的事项

---

面试题与参考答案

1. 为什么Few-Shot示例能提升模型性能？从贝叶斯推断角度解释。

参考答案：

贝叶斯视角解释：

P(task | examples) ∝ P(examples | task) × P(task)

其中：
- P(task)：先验概率，模型在预训练中学到的任务分布
- P(examples | task)：似然，示例在给定任务下的概率
- P(task | examples)：后验概率，看到示例后的任务推断

Few-Shot示例的作用：
1. 大幅提高P(examples | task)，使后验概率集中在目标任务上
2. 示例提供了"任务边界"，约束了模型的输出空间
3. 示例的分布帮助模型推断底层概念（Xie et al., 2021的贝叶斯推断框架）

工程启示：
- 示例质量 > 数量（3-5个高质量示例通常优于20个低质量示例）
- 示例分布应与目标分布一致（分布偏移会导致ICL失效）
- 示例顺序影响注意力权重（recency bias）

2. System Prompt和User Prompt在RLHF模型中的权重差异原因是什么？

参考答案：

权重差异的根本原因：训练阶段的角色定位不同

1. 训练数据构造：
   - System Prompt在RLHF训练中被视为"环境上下文"
   - User Prompt被视为"用户请求"
   - 模型学习将System作为行为准则，User作为具体任务

2. 注意力机制层面：
   - System Prompt通常位于序列最前端
   - 在Decoder-only架构中，前端token对所有后续token的注意力权重影响更大
   - 相当于"全局约束" vs "局部请求"

3. 实际应用差异：
   - System：设定角色、全局约束、输出格式 → 影响所有输出
   - User：具体任务、当前输入 → 影响当前轮次输出

4. 工程建议：
   - 将"不变的行为准则"放入System Prompt
   - 将"具体任务"放入User Prompt
   - 对于特别重要的约束，在User中重复强调

3. 在RAG系统中，如何设计提示词以减少模型幻觉？

参考答案：

RAG幻觉的三种类型及对策：

类型1 - 编造不在检索结果中的信息：
对策：
- 明确指令："只能基于提供的参考资料回答，禁止编造"
- 自我验证要求："如果参考资料不足，明确说明'根据现有资料无法回答'"
- 引用标注：要求模型标注每条信息的来源[ref:X]

类型2 - 错误组合检索结果（逻辑错误）：
对策：
- 关系推理提示："分析多个参考资料之间的关系，注意矛盾点"
- 冲突检测："如果多个参考资料冲突，列出不同观点并说明来源"
- 置信度评估：要求模型评估答案的置信度

类型3 - 过度推断（超出检索内容）：
对策：
- 范围限定："不要进行超出参考资料范围的推断"
- 保守回答："不确定时请明确说明，不要猜测"
- 信息完整性检查：输出格式中包含"信息完整性评估"字段

完整提示词结构（见本文RAG案例部分）

4. MoE架构（如DeepSeek-V4）的提示词设计需要考虑哪些特殊因素？

参考答案：

MoE（Mixture of Experts）架构的特殊考虑：

1. 专家路由机制：
   - 不同token激活不同专家子网络
   - 提示词中的关键词会影响路由决策
   - 明确的专业术语更容易激活对应的"专家"

2. 长提示词成本优势：
   - MoE只激活部分参数，长上下文成本更低
   - 可以更充分地提供背景信息
   - 适合长文档分析和复杂任务

3. 推理能力激活：
   - 明确的推理指令（"请展示详细推理过程"）
   - 有助于激活推理相关的专家
   - CoT在MoE模型上效果更明显

4. 多任务提示：
   - MoE天然适合多任务（不同任务激活不同专家）
   - 可以在一个提示词中包含多个子任务
   - 但需注意任务间的干扰

5. 工程建议：
   - 使用专业术语明确激活对应专家
   - 充分利用长上下文能力提供详细信息
   - 复杂任务使用分步提示（step-by-step）

5. 如何评估一个提示词的质量？设计一个自动化评估框架。

参考答案：

"""
自动化评估框架设计（已在本文"评估与优化体系"章节详细说明）

核心指标：
1. 语义相似度：基于Embedding的余弦相似度
2. 格式正确性：JSON/Schema验证通过率
3. 事实一致性：NLI模型判断（支持/矛盾/中立）
4. 指令遵循度：用另一个LLM判断
5. 流畅度：困惑度（Perplexity）
6. 安全性：毒性、偏见检测

评估流程：
1. 准备测试集（input, expected_output, context）
2. 批量执行提示词
3. 多维度自动评分
4. 与基线提示词对比（A/B测试）
5. 生成评估报告

关键原则：
- 评估必须与业务目标对齐
- 使用多个指标综合评估（不要只看单一指标）
- 人工抽样验证自动评估的准确性
- 建立回归测试（防止提示词优化引入新问题）
"""

6. 在多轮对话中，如何管理长上下文以避免信息丢失？

参考答案：

长上下文管理的分层策略：

1. 摘要层（Summary）：
   - 每N轮对话生成一次摘要
   - 保留关键信息，压缩冗余内容
   - 摘要作为后续对话的上下文基础

2. 事实层（Key-Value Store）：
   - 提取结构化事实（如用户名、订单号、偏好设置）
   - 以键值对形式存储
   - 随时可检索，不受上下文长度限制

3. 原始历史层（Raw History）：
   - 保留最近K轮原始对话
   - 提供细粒度的上下文信息
   - K根据模型上下文窗口动态调整

4. 动态压缩策略：
   - 当接近上下文限制时，触发压缩
   - 优先压缩早期的、已摘要的对话
   - 保留最近的完整对话（利用recency bias）

5. 信息优先级：
   - 系统指令（最高优先级，始终保留）
   - 关键事实（高优先级，摘要后保留）
   - 最近对话（中优先级，按需保留）
   - 早期对话（低优先级，优先压缩）

完整实现代码（见本文"多轮对话上下文管理"案例）

7. Prompt Chaining与端到端单次提示的优劣对比？

参考答案：

Prompt Chaining（链式提示）：

优点：
1. 模块化：每个阶段可独立优化、测试、复用
2. 可控性：中间结果可检查、可干预
3. 错误定位：可以定位到具体阶段的错误
4. 成本优化：简单任务用便宜模型，复杂任务用强模型
5. 可解释性：中间结果提供了推理过程的可视化

缺点：
1. 延迟：多阶段调用增加总延迟
2. 错误累积：前一阶段的错误会传递到后续阶段
3. 上下文断裂：阶段间信息可能丢失
4. 成本：多次调用可能比单次调用更贵

端到端单次提示：

优点：
1. 简单：无需设计复杂的Pipeline
2. 延迟低：单次调用即可完成
3. 信息保留：所有信息在一个上下文中
4. 成本低：单次调用通常更便宜

缺点：
1. 黑盒：难以理解和调试
2. 错误难定位：不知道哪个环节出错
3. 模型能力要求高：需要模型一次性完成复杂推理
4. 难以优化：只能整体调整提示词

选择原则：
- 简单任务 → 端到端
- 复杂任务/需要人机协作 → Prompt Chaining
- 生产环境 → 混合使用（Chaining为主，端到端为辅）

8. 不同模型（GPT vs Claude vs 国产模型）对同一提示词的响应差异原因？

参考答案：

差异的根本原因：架构、训练数据、训练目标的不同

1. 架构差异：
   GPT/Claude/Kimi：Decoder-only，单向注意力
   GLM：双向注意力 + 自回归填空
   DeepSeek：MoE架构，专家路由
   
   影响：对提示词位置的敏感度不同

2. 训练数据差异：
   - 数据来源和比例不同（英文/中文、代码/文本比例）
   - 数据质量和清洗策略不同
   - 影响：对特定领域术语的理解能力不同

3. 训练目标差异：
   - 基础预训练目标（next token prediction vs MLM）
   - SFT数据构造方式
   - RLHF的人类偏好数据
   - 影响：对指令风格的响应不同

4. 后处理差异：
   - 安全过滤策略
   - 输出格式化策略
   - 温度/Top-p等解码参数默认值

具体表现：
- GPT：对System Prompt响应强，适合结构化输出
- Claude：对复杂指令理解深，自然语言风格更好
- DeepSeek：代码和推理能力强，适合技术任务
- Kimi：长上下文处理优秀，适合文档分析
- GLM：中文理解自然，适合本土化场景

工程建议：
- 针对不同模型设计专用提示词模板
- 建立模型路由（Model Router）自动选择最优模型
- 使用统一抽象层封装模型差异

---

此文原创，转载请注明出处。