원본 캡처
verified · type: reference · [meta, raw]

I now have strong primary and secondary confirmation across all subtopics. I have enough to write the reference. Since the task is to produce a research reference document (not to modify the user's ERP codebase), I'll return structured markdown directly as my final output — this is a research deliverable for the calling script, not a file to write into the repo.

Let me compile the complete reference.

Prompting Patterns & Techniques — Practical LLM Reference (2026)

Orientation note (2026): The novelty cycle on new prompting techniques has slowed. What matters now is operational discipline over a small, stable pattern set plus per-model calibration. The single biggest 2026 shift: reasoning/"thinking" models invert several classic prompting rules — techniques that helped standard models (verbose CoT, few-shot scaffolding) can actively hurt reasoning models. Every technique below is tagged for model-specificity where it matters.

1. Zero-shot vs Few-shot

Zero-shot — instruction only, no examples. Default for capable 2026 models on well-specified tasks.

Classify the sentiment as positive, negative, or neutral.

Text: "The delivery was late but support fixed it fast."
Sentiment:

Few-shot — 1–5 labeled examples demonstrating the pattern. Still one of the fastest ways to raise output quality: a small set of well-chosen examples gives better control than piling on more instructions, because examples show the model what "good" looks like in a copyable form. Reported gains of ~20–40% accuracy on many benchmarks with 1–5 examples.

Classify sentiment as positive, negative, or neutral.

Text: "Loved it, would buy again." → positive
Text: "Package arrived crushed." → negative
Text: "It's a phone. It works." → neutral
Text: "The delivery was late but support fixed it fast." →

When to use few-shot: format/style is hard to describe but easy to show; edge-case disambiguation; enforcing a specific tone or label taxonomy.

⚠ Model-specific: On reasoning models (o-series, GPT-5.x thinking, Claude extended-thinking, Gemini Thinking, DeepSeek-R1), few-shot examples often degrade performance — the model over-imitates the example's reasoning shape instead of reasoning freely. Start zero-shot; add examples only for output format, not reasoning steps.

Anti-pattern: Few-shot pollution — stale examples that contradict current instructions. This is the single most common silent-failure source in production prompts. Audit examples every time you change the instructions.

2. Chain-of-Thought (CoT) & Reasoning

Classic CoT — elicit intermediate steps before the answer. The canonical trigger:

Q: A cafeteria had 23 apples. They used 20 for lunch and bought 6 more.
   How many apples do they have?
A: Let's think step by step.

Few-shot CoT — show worked reasoning in the examples (strongest on standard models for arithmetic/logic).

Production pattern that actually works — reason internally, answer in a fixed format externally. Prevents the reasoning trace from polluting downstream parsing:

Think through the problem step by step inside <scratchpad> tags.
Then give ONLY the final answer inside <answer> tags as a single number.

<scratchpad>...your reasoning...</scratchpad>
<answer>9</answer>

⚠ Model-specific (important): - Standard models (GPT-4o-class, Claude non-thinking, Gemini Flash): explicit "think step by step" and few-shot CoT still help materially. - Reasoning models: they already reason internally. Adding "think step by step" or long CoT scaffolds is redundant to counterproductive. OpenAI's official guidance: "Give the model the task, constraints, and desired output format" — don't prescribe intermediate steps. Tasks that used to need 500-line CoT prompts now work with a plain instruction. Use the reasoning.effort knob (below) instead of prompt-level CoT.

3. Role / System Prompts

Put stable, identity-level instructions in the system (or developer, for o-series) message: persona, domain, constraints, output contract, refusal boundaries. Keep the user message task-specific.

System:
You are a senior tax accountant specializing in US small-business filings.
- Cite the specific IRS form or publication for every claim.
- If a question needs facts you don't have, ask before answering.
- Never invent form numbers. Output plain prose, no markdown headers.

User:
Can an LLC deduct home-office expenses for a single member?

Best practice: a role sharpens perspective and vocabulary; it does not add knowledge the model lacks. Use roles to shape judgment and tone, not as a magic accuracy lever.

Anti-pattern: persona-stuffing — "You are a world-class 10x genius rockstar expert…". Empty superlatives add tokens and noise without improving output. State the functional role and the concrete constraints instead.

⚠ Model-specific: OpenAI o-series/GPT-5.x use a developer message role (higher priority than user, below platform/system). Anthropic uses a dedicated top-level system parameter. Functionally similar; the priority hierarchy differs.

4. Structured Output (JSON Schema, XML tags)

JSON via schema-constrained decoding (preferred when available)

Both OpenAI (Structured Outputs) and others support supplying a JSON Schema the model is guaranteed to conform to — eliminating invalid/truncated JSON. This is the most reliable structured-output method in the 2026 stack.

// OpenAI Structured Outputs (response_format)
{
  "type": "json_schema",
  "json_schema": {
    "name": "extraction",
    "strict": true,
    "schema": {
      "type": "object",
      "properties": {
        "company":   { "type": "string" },
        "amount_usd":{ "type": ["number", "null"] },
        "confidence":{ "type": "string", "enum": ["high","medium","low"] }
      },
      "required": ["company", "amount_usd", "confidence"],
      "additionalProperties": false
    }
  }
}

Rule: make every field either required or explicitly nullable, and give the model an "unknown"/null escape hatch for every field — otherwise it hallucinates values to satisfy the schema.

XML tags (Anthropic-favored, works broadly)

Claude is specifically trained to respect XML tags. Use them to delimit inputs, separate instructions from data, and structure output.

<document>
{{RAW_CONTRACT_TEXT}}
</document>

<instructions>
Extract every payment obligation. Return one <obligation> block per item
with <party>, <amount>, and <due_date>. If a field is absent, write "not stated".
</instructions>

⚠ Model-specific: XML-tag structuring is strongest on Claude. JSON-Schema strict mode is native on OpenAI and Gemini. All modern models handle both, but pick the one your provider trained on for maximum reliability.

5. Prompt Chaining

Break one complex task into a sequence of focused LLM calls where each step's output feeds the next, each with a single bounded responsibility. More reliable than one mega-prompt because each step is independently testable and debuggable.

Step 1 (extract):  raw email  → structured {intent, entities, urgency}
Step 2 (route):    structured → chosen department + priority
Step 3 (draft):    context    → customer-ready reply
Step 4 (verify):   reply      → pass/fail against policy checklist

Self-Refine variant (generator → critic → reviser, same model, three passes) reports ~20% average improvement across tasks:

1. Draft an answer to: {task}
2. Critique your draft: list every factual, logical, or style flaw.
3. Rewrite the answer fixing every flaw you found.

When to chain vs. single-prompt: chain when steps need different tools/models, when you need intermediate validation, or when a single prompt is accumulating contradictory instructions. Don't chain trivial tasks — each hop adds latency and cost.

6. ReAct (Reason + Act)

Interleaves reasoning traces with tool actions in a live loop: Thought → Action → Observation → Thought → …. The backbone of most 2026 tool-using agents. On the ALFWorld benchmark ReAct beat imitation/RL baselines by ~34% absolute success; ~10% on WebShop.

Question: What's the current CEO's age divided by the founding year's last two digits?

Thought: I need the current CEO and the founding year. I'll search.
Action: web_search("company X current CEO")
Observation: Jane Doe, age 52.
Thought: Now the founding year.
Action: web_search("company X founding year")
Observation: Founded 1998.
Thought: 52 / 98 = 0.53.
Action: finish("0.53")

⚠ Model-specific / 2026 note: With native function-calling models you rarely hand-write the ReAct loop as raw text anymore — the model emits structured tool calls and you feed back tool results. The pattern (reason, act, observe, repeat) is unchanged; the plumbing is now the tool-calling API. On reasoning models, let the model's internal reasoning replace verbose "Thought:" text and just orchestrate the Action/Observation cycle.

7. Self-Consistency

Sample multiple diverse reasoning paths (temperature > 0) for the same question, then take the majority-vote answer. Boosts CoT accuracy on arithmetic/commonsense tasks. Canonical example:

"When I was 6 my sister was half my age. Now I'm 70, how old is my sister?" Path A → 67 · Path B → 67 · Path C → 35 · Majority vote → 67

# Pseudocode
answers = [call(prompt, temperature=0.7) for _ in range(5)]
final   = most_common(extract_answer(a) for a in answers)

Trade-off: N× cost and latency. Reserve for high-value, verifiable-answer tasks (math, extraction with a single correct value). ⚠ Model-specific: largely redundant on strong reasoning models, which already explore/verify internally — pay the N× cost only if evals show it helps.

8. Prompt Caching Strategy

Cache the stable prefix of your prompt so repeated calls skip re-processing it. Documented savings of 59–90% on input cost; one agent went $720 → $72/mo by adding three cache markers.

Provider mechanics (2026): | Provider | Mechanism | Discount | |---|---|---| | OpenAI | Automatic for prefixes ≥ 1,024 tokens | ~50% off cached input | | Anthropic | Explicit cache_control breakpoints | ~90% off reads; writes cost 1.25× (5-min TTL) / 2.0× (1-hr), reads 0.1× | | Gemini | Explicit context caching | varies |

The one rule that governs caching: stable first, variable last.

[ system prompt        ]  ← most stable      ┐
[ tool definitions     ]  ← stable/version   │ cacheable prefix
[ long static context  ]  ← stable           │
[ slowly-changing docs ]  ← semi-stable      ┘
[ current user message ]  ← most variable  ← everything AFTER a
                                              variable element won't cache

Gotchas: - A timestamp (or any per-request token) injected at the top invalidates the entire cache. Never put volatile data before stable data. - Anthropic only scans the last ~20 content blocks for prior cache entries — in conversations > 20 turns, add a cache_control breakpoint roughly every 15 blocks or the oldest cached context falls out of the lookback window. - Monitor it: track cache_read_input_tokens / (cache_read + cache_creation); alert if hit-rate drops below ~70% — that's your early warning for silent prompt drift.

9. Anti-Patterns & Failure Modes

Anti-pattern What goes wrong Fix
Instruction stacking Quality degrades monotonically — each added rule erodes attention on prior ones Keep instruction sets small; move rules into examples or chained steps
Few-shot pollution / example contamination A stale example contradicts current instructions → silent wrong outputs Re-audit every example whenever instructions change
Persona-stuffing Empty superlatives ("genius 10x rockstar") add noise, not accuracy State the functional role + concrete constraints only
Negation-heavy prompts "Don't do X" is weaker than positive instruction; models still drift toward X Say what TO do: "Respond in ≤3 sentences" not "Don't be verbose"
Lost-in-the-middle Instructions buried in the middle of long context get ignored Put critical instructions at the start and end; keep key data near the edges
Contradictions Conflicting rules → model picks unpredictably Grep the prompt for mutually exclusive instructions
Format-via-example only Relying on examples for format instead of a schema → occasional drift Use JSON-Schema/XML contracts as the source of truth
CoT on reasoning models "Think step by step" on o-series/thinking models is redundant→counterproductive Give task + constraints + output format; use the effort knob
Silent degradation A demo-perfect prompt decays in prod for months; outputs still look plausible while accuracy drifts Eval suite + cache-hit monitoring — the only real defense

The two defenses (2026 consensus): (1) name the failure mode, (2) back every prompt with an automated eval suite. Prompts without evals rot invisibly.

10. Prompting Reasoning Models vs Standard Models

This is the most model-specific area — get it wrong and you pay more for worse output.

Standard models (GPT-4o-class, Claude non-thinking, Gemini Flash) Reasoning models (o3/o4, GPT-5.x thinking, Claude extended-thinking, Gemini Thinking, DeepSeek-R1)
CoT scaffolding Helps — "think step by step", few-shot CoT Redundant → counterproductive; model reasons internally
Few-shot examples Often help accuracy Often hurt reasoning (over-imitation); use only for output format
Prompt style Explicit, step-by-step, spell out the process Minimal brief: clear goal + hard constraints + output contract; let it find the approach
Depth control Prompt wording A parameter: OpenAI reasoning.effort (none→max); Anthropic thinking token budget; Gemini thinking budget
Best tasks Fast Q&A, translation, extraction, classification, chat Multi-step math, deep code debugging, planning, scientific/logical reasoning
Cost/latency Low High — do not default to reasoning models for simple tasks (higher cost, no accuracy benefit)

How to prompt a reasoning model (OpenAI's own guidance): 1. Define success — state what "done" looks like and how to verify it. 2. Set constraints — boundaries + explicit output format. 3. Don't over-specify — omit intermediate steps; let it discover the approach.

# GOOD reasoning-model prompt (minimal brief, no CoT hand-holding)
Goal: Find the off-by-one bug causing the pagination test to fail.
Constraints: Change only pagination.py. Keep the public API identical.
Output: The corrected function, then one sentence naming the root cause.
reasoning.effort = "high"

Provider-specific depth knobs: - OpenAI o-series / GPT-5.x: reasoning.effort — low for tool-use/planning/multi-step, medium default, high/xhigh for hard debugging/agentic work. Treat effort as a tuning knob, not the first fix for quality. - Anthropic Claude (extended thinking): allocate a thinking token budget; the thinking block is separately budgeted and inspectable. - DeepSeek-R1: transparent chain-of-thought exposed in output. - Gemini Deep Think: explores multiple hypotheses in parallel.

Routing rule of thumb (2026): default to a fast standard model; route only the hard problems to a reasoning model. Don't pay reasoning-model prices for extraction, translation, or simple Q&A.

Quick-Reference: technique → when to reach for it

  • Zero-shot — well-specified task, capable model. Default.
  • Few-shot — need to show format/style/edge-cases (standard models). Format-only on reasoning models.
  • CoT — hard reasoning on standard models. Skip on reasoning models.
  • Role/system prompt — set perspective, constraints, output contract. Always.
  • Structured output — anything a program consumes. JSON-Schema (OpenAI/Gemini) or XML tags (Claude).
  • Prompt chaining — complex task decomposable into testable steps.
  • ReAct — tool-using agents; use native function-calling plumbing.
  • Self-consistency — high-value, single-correct-answer tasks; standard models. N× cost.
  • Prompt caching — any repeated stable prefix. Stable-first, variable-last.
  • Eval suite — non-negotiable underneath all of the above.

Model-specific effectiveness flags (summary)

  • Few-shot & CoT: help standard models, can hurt reasoning models.
  • XML tags: strongest on Claude. JSON-Schema strict mode: native on OpenAI/Gemini.
  • Depth control is a parameter, not a prompt, on reasoning models — and the parameter differs per provider.
  • Self-consistency: mostly redundant on reasoning models.
  • Developer-message role (OpenAI) vs system parameter (Anthropic): same idea, different priority hierarchy.

Sources