title: Prompt Engineering Best Practices — Production Guide description: LLM Prompt design methodology: structured templates, few-shot examples, chain-of-thought reasoning, output control. Original tutorial with 5 production-grade templates. lang: en tags: [ai, prompt, engineering, llm] date: 2026-10-23 original: true faq: - q: "How to write high-quality prompts?" a: "Five elements: ① Role definition (You are a senior SRE) ② Task description (Analyze the following alert) ③ Context (Provide metrics data) ④ Output format (JSON structure) ⑤ Constraints (Max 200 words). Each element reduces ambiguity and improves output quality." - q: "How to select few-shot examples?" a: "Choose 3-5 representative cases covering different scenarios (success/failure/edge cases). Examples should be accurate, concise, and consistent with the target task style. Avoid extreme or atypical cases that could bias the model." - q: "Is there a prompt length limit?" a: "Yes, typically 4K-32K tokens depending on the model. For long prompts, use a segmented strategy: system prompt + knowledge base summary + current question. Exceeding limits causes truncation or errors." - q: "How to evaluate prompt effectiveness?" a: "Build a test set (50-100 cases), use human scoring + automated metrics (format compliance, information completeness, answer accuracy). Run regular A/B tests when iterating on prompts." - q: "How to prevent prompt injection attacks?" a: "Input filtering (detect injection patterns), context isolation (separate user input from system prompt), output validation (check for unexpected instructions). Use dedicated safety models like NeMo Guardrails for real-time detection."
Prompt Engineering Best Practices — Production Guide
Use Case: Design effective prompts for LLM applications to improve output quality and consistency in production.
1. Core Prompt Design Principles
1.1 Five-Element Framework
Example:
You are a senior SRE engineer (Role).
Please analyze the following Nginx 502 alert and provide root cause and fix recommendations (Task).
Context: {{alert_context}} (Context).
Output as JSON with fields: root_cause, steps, severity (Format).
Keep response under 200 words, do not fabricate information (Constraints).
1.2 Common Mistakes
| Mistake Type | Bad Example | Better Approach |
|---|---|---|
| Vague | "Help me look at this issue" | "Analyze the following Prometheus alert and determine if it's a false positive" |
| Missing context | "What should I do about this error?" | "Pod status is CrashLoopBackOff, logs show OOMKilled, how to troubleshoot?" |
| Free format | "Reply to me" | "Output JSON: {\"status\": \"...\", \"action\": \"...\"}" |
| Overly complex | Long paragraphs mixed together | Clear sections with highlighted key points |
2. Structured Prompt Templates
2.1 Incident Diagnosis Template
DIAGNOSIS_PROMPT = """
# Role
You are a senior SRE engineer specializing in Kubernetes and Docker troubleshooting.
# Task
Analyze the following incident information, identify the root cause, and provide a fix plan.
# Incident Information
{{incident_report}}
# Output Format
Please output in JSON format:
{{"root_cause": "Root cause analysis",
"severity": "P0/P1/P2/P3",
"steps": ["Troubleshooting step 1", "Troubleshooting step 2"],
"solution": "Fix solution",
"prevention": "Preventive measures"}}
# Constraints
- Base your analysis only on the provided information, do not fabricate
- If information is insufficient, explicitly state what needs to be added
- Fix solutions must consider production environment impact
"""
2.2 Ticket Generation Template
TICKET_PROMPT = """
# Role
You are an ITIL-certified operations engineer.
# Task
Convert the following alert information into a standard operations ticket.
# Alert Information
{{alert_data}}
# Output Format
{
"title": "Ticket title (concise)",
"description": "Detailed description",
"severity": "P0/P1/P2/P3",
"category": "infrastructure/network/database/application",
"assigned_to": "Auto-assignment rule",
"sla_hours": 24,
"suggested_actions": ["Action 1", "Action 2"],
"related_knowledge": "Related documentation link"
}
# Constraints
- Title must be under 50 characters
- Description must include time, impact scope, symptoms
- Assign priority according to SLA requirements
"""
2.3 Code Review Template
REVIEW_PROMPT = """
# Role
You are a DevOps engineer focused on code quality.
# Task
Review the following Dockerfile and identify potential issues.
# Code
\`\`\`dockerfile
{{dockerfile_content}}
\`\`\`
# Review Dimensions
1. Security (base image, permissions, sensitive information)
2. Performance (layer caching, image size)
3. Maintainability (comments, readability)
4. Best practices (multi-stage builds, healthcheck)
# Output Format
- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (optional optimization)
- Overall score (1-10)
"""
3. Few-Shot Learning Strategy
3.1 Example Selection Principles
✅ Good examples:
- Cover different scenarios (normal/abnormal/edge cases)
- Difficulty progresses from easy to hard
- Consistent output format
- Highly relevant to the target task
❌ Bad examples:
- All success cases
- Inconsistent output formats
- Too simple or too complex
- Significantly different from target task
3.2 Few-Shot Examples for Incident Diagnosis
FEWD_SHOT_EXAMPLES = """
【Example 1】
User: Pod CrashLoopBackOff, logs show OOMKilled
Assistant: {"root_cause": "Container memory exceeded limit and was killed by OS", "severity": "P1", "steps": ["Check Pod memory limits", "Analyze application memory usage", "Adjust resources.limits"], "solution": "Increase memory limit or optimize application memory", "prevention": "Set up HPA for auto-scaling"}
【Example 2】
User: Nginx 502, upstream port unreachable
Assistant: {"root_cause": "Upstream service not started or port occupied", "severity": "P1", "steps": ["curl upstream port to confirm", "Check service status", "Look for port conflicts"], "solution": "Restart upstream service or free the port", "prevention": "Add health checks and auto-restart"}
【Example 3】
User: Prometheus storage full
Assistant: {"root_cause": "TSDB retention period too long or metric volume surged", "severity": "P2", "steps": ["Check storage usage", "Analyze metric growth trends", "Clean expired data"], "solution": "Adjust retention.time or upgrade storage", "prevention": "Set storage alert threshold at 80%"}
"""
4. Chain-of-Thought Reasoning
4.1 Basic Pattern
COT_PROMPT = """
Please analyze the following problem step by step:
Problem: {{question}}
Please think through these steps:
1. Understand the problem: Restate the core of the question
2. Collect information: List known conditions and items to confirm
3. Analyze causes:排查 each possible cause one by one
4. Verify hypotheses: Design verification methods
5. Draw conclusions: Provide final judgment
Output format:
{{"thinking": ["Step 1", "Step 2", ...],
"conclusion": "Final conclusion",
"confidence": 0.95}}
"""
4.2 Self-Verification
SELF_CHECK_PROMPT = """
Your generated answer:
{{answer}}
Please verify:
1. Does the answer directly address the question?
2. Are there any factual errors?
3. Is any key information missing?
4. Does the format meet requirements?
Verification result: {{"pass": true/false, "issues": [...]}}
"""
5. Output Control
5.1 JSON Schema Constraint
from pydantic import BaseModel, Field
from typing import Literal
class IncidentReport(BaseModel):
root_cause: str = Field(..., description="Root cause analysis")
severity: Literal["P0", "P1", "P2", "P3"]
steps: list[str] = Field(..., min_length=1, max_length=10)
solution: str
prevention: str
# Add schema to prompt
schema_prompt = f"""
Output format must match the following JSON Schema:
{IncidentReport.model_json_schema()}
"""
5.2 Temperature and Sampling Parameters
| Scenario | temperature | top_p | best_of |
|---|---|---|---|
| Incident diagnosis | 0.1-0.3 | 0.9 | - |
| Creative writing | 0.7-1.0 | 1.0 | - |
| Code generation | 0.2-0.4 | 0.95 | 2-4 |
| Data extraction | 0.1 | 0.9 | - |
6. Effect Evaluation
6.1 Test Set Construction
TEST_CASES = [
{
"input": "Pod OOMKilled, how to troubleshoot?",
"expected": {"root_cause": "...", "severity": "P1", ...},
"keywords": ["memory", "limit", "kubectl"]
},
{
"input": "Nginx 502 error",
"expected": {"root_cause": "...", "severity": "P1", ...},
"keywords": ["upstream", "connection refused"]
}
]
6.2 Evaluation Metrics
| Metric | Calculation | Target |
|---|---|---|
| Format compliance | JSON parse success rate | > 95% |
| Information completeness | Keyword coverage rate | > 80% |
| Answer accuracy | Human scoring | > 4/5 |
| Response latency | P99 latency | < 3s |
7. Common Troubleshooting
Issue 1: Unstable Output Format
Fix: - Add explicit format requirements - Use JSON Schema constraints - Increase output_parser validation
Issue 2: Severe Hallucination
Fix: - Provide sufficient context - Add "based on given information" constraints - Enable self-check mechanism
Issue 3: Response Too Long
Fix: - Specify word limit clearly - Use bullet points - Simplify examples