Prompt 工程最佳实践 · 运维手册
适用场景：为 LLM 应用设计高效 Prompt，提升输出质量和一致性。
1. Prompt 设计原则
1.1 五要素框架
示例：
你是一位资深运维专家（角色）。
请分析以下 Nginx 502 告警，给出根因和修复建议（任务）。
上下文信息：{{context}}（上下文）。
请以 JSON 格式输出，包含 fields: root_cause, steps, severity（格式）。
回答不超过 200 字，不要编造信息（约束）。
1.2 常见错误
| 错误类型 | 反面例子 | 正确做法 |
|---|---|---|
| 模糊不清 | "帮我看看这个问题" | "分析以下 Prometheus 告警，判断是否误报" |
| 缺乏上下文 | "这个错误怎么办？" | "Pod 状态 CrashLoopBackOff，日志显示 OOMKilled，如何排查？" |
| 格式自由 | "回复我" | "输出 JSON: {\"status\": \"...\", \"action\": \"...\"}" |
| 过于复杂 | 超长段落混排 | 分段清晰，重点突出 |
2. 结构化 Prompt 模板
2.1 故障诊断模板
DIAGNOSIS_PROMPT = """
# 角色
你是一位资深 SRE 工程师，擅长 Kubernetes 和 Docker 故障排查。
# 任务
分析以下故障信息，定位根因并给出修复方案。
# 故障信息
# 输出格式
请以 JSON 格式输出：
{{"root_cause": "根因分析",
"severity": "P0/P1/P2/P3",
"steps": ["排查步骤1", "排查步骤2"],
"solution": "修复方案",
"prevention": "预防措施"}}
# 约束
- 基于提供的故障信息，不要编造
- 如果信息不足，明确说明需要补充什么
- 修复方案要考虑生产环境影响
"""
2.2 工单生成模板
TICKET_PROMPT = """
# 角色
你是一位 ITIL 认证的运维工程师。
# 任务
将以下告警信息转化为标准运维工单。
# 告警信息
{{alert_data}}
# 输出格式
{
"title": "工单标题（简明扼要）",
"description": "详细描述",
"severity": "P0/P1/P2/P3",
"category": "基础设施/网络/数据库/应用",
"assigned_to": "自动分配规则",
"sla_hours": 24,
"suggested_actions": ["行动1", "行动2"],
"related_knowledge": "相关文档链接"
}
# 约束
- 标题不超过 50 字
- 描述包含时间、影响范围、症状
- 按 SLA 规定分配优先级
"""
2.3 代码审查模板
REVIEW_PROMPT = """
# 角色
你是一位注重代码质量的 DevOps 工程师。
# 任务
审查以下 Dockerfile，找出潜在问题。
# 代码
\`\`\`dockerfile
{{dockerfile_content}}
\`\`\`
# 审查维度
1. 安全性（基础镜像、权限、敏感信息）
2. 性能（层缓存、镜像大小）
3. 可维护性（注释、可读性）
4. 最佳实践（多阶段构建、healthcheck）
# 输出格式
- 严重问题（必须修复）
- 警告（建议修复）
- 建议（可选优化）
- 总体评分（1-10）
"""
3. Few-Shot 示例策略
3.1 示例选择原则
✅ 好示例：
- 覆盖不同场景（正常/异常/边界）
- 难度递增
- 输出格式统一
- 与目标任务高度相关
❌ 坏示例：
- 全部是成功案例
- 输出格式不一致
- 过于简单或过于复杂
- 与目标任务差异大
3.2 故障诊断 Few-Shot
````python FEWD_SHOT_EXAMPLES = """ 【示例 1】 用户：Pod CrashLoopBackOff，日志显示 OOMKilled 助手：{"root_cause": "容器内存超限被系统杀掉", "severity": "P1", "steps": ["查看 Pod 内存限制", "检查应用内存使用", "调整 resources.limits"], "solution": "增加 memory limit 或优化应用内存", "prevention": "设置 HPA 自动扩缩容"}
【示例 2】 用户：Nginx 502，上游端口不通 助手：{"root_cause": "上游服务未启动或端口被占", "severity": "P1", "steps": ["curl 上游端口确认", "检查服务状态", "查看端口冲突"], "solution": "重启上游服务或释放端口", "prevention": "添加健康检查和自动重启"}
【示例 3】 用户：Prometheus 存储打满 助手：{"root_cause": "TSDB 保留期过长或指标量激增", "severity": "P2", "steps": ["检查存储使用率", "分析指标增长趋势", "清理过期数据"], "solution": "调整 retention.time 或升级存储", "prevention": "设置存储告警阈值 80%"} ""``
4. 链式推理（Chain-of-Thought）
4.1 基本模式
```python COT_PROMPT = """ 请逐步分析以下问题：
问题：{{question}}
请按以下步骤思考： 1. 理解问题：复述问题的核心 2. 收集信息：列出已知条件和待确认项 3. 分析原因：逐个排查可能原因 4. 验证假设：设计验证方法 5. 得出结论：给出最终判断
输出格式： {{"thinking": ["步骤1", "步骤2", ...], "conclusion": "最终结论", "confidence": 0.95}} """ ```
4.2 自我验证
```python SELF_CHECK_PROMPT = """ 你生成的答案： {{answer}}
请验证： 1. 答案是否直接回应了问题？ 2. 是否有事实性错误？ 3. 是否遗漏关键信息？ 4. 格式是否符合要求？
验证结果：{{"pass": true/false, "issues": [...]}} """ ```
5. 输出控制
5.1 JSON Schema 约束
```python from pydantic import BaseModel, Field from typing import Literal
class IncidentReport(BaseModel): root_cause: str = Field(..., description="根因分析") severity: Literal["P0", "P1", "P2", "P3"] steps: list[str] = Field(..., min_length=1, max_length=10) solution: str prevention: str
在 Prompt 中加入 schema
schema_prompt = f""" 输出格式必须符合以下 JSON Schema： {IncidentReport.model_json_schema()} """ ```
5.2 温度与采样参数
| 场景 | temperature | top_p | best_of |
|---|---|---|---|
| 故障诊断 | 0.1-0.3 | 0.9 | - |
| 创意写作 | 0.7-1.0 | 1.0 | - |
| 代码生成 | 0.2-0.4 | 0.95 | 2-4 |
| 数据提取 | 0.1 | 0.9 | - |
6. 效果评估
6.1 测试集构建
python
TEST_CASES = [
{
"input": "Pod OOMKilled，如何排查？",
"expected": {"root_cause": "...", "severity": "P1", ...},
"keywords": ["memory", "limit", "kubectl"]
},
{
"input": "Nginx 502 错误",
"expected": {"root_cause": "...", "severity": "P1", ...},
"keywords": ["upstream", "connection refused"]
}
]
6.2 评估指标
| 指标 | 计算方法 | 目标 |
|---|---|---|
| 格式符合度 | JSON 解析成功率 | > 95% |
| 信息完整性 | 关键字覆盖率 | > 80% |
| 答案准确性 | 人工评分 | > 4/5 |
| 响应延迟 | P99 耗时 | < 3s |
7. 常见问题排查
问题 1：输出格式不稳定
解决： - 添加明确格式要求 - 使用 JSON Schema 约束 - 增加 output_parser 验证
问题 2：幻觉严重
解决： - 提供充足上下文 - 添加"基于给定信息"约束 - 启用 self-check 机制
问题 3：响应过长
解决： - 明确字数限制 - 使用 bullet points - 简化示例