Prompt Engineering Foundations

A production prompt usually has several parts. The system role defines durable behavior and boundaries. The user role carries the current request and task-specific input. The assistant role can provide prior examples in a conversation or represent model outputs that become context for later turns.

Within those roles, a strong prompt separates instructions, background context, examples, the actual input, and the required output format. This separation matters because it reduces ambiguity and makes it easier to test which part caused a failure. If the prompt is one long paragraph, debugging becomes guesswork.

System messages should hold stable rules: identity, safety boundaries, style, tool policy, and what to do when evidence is missing. User messages should hold the immediate task, user-provided data, and any fresh constraints. Assistant messages represent prior model outputs and should be treated as conversational state, not a place to hide permanent policy.

This priority model is central to prompt injection defense. A user can ask the model to ignore instructions, but the application should put trusted policy in a higher-priority role and put untrusted content inside clearly labeled context. Good role design does not eliminate attacks, but it makes the desired hierarchy explicit.

In zero-shot prompting, you give the task and constraints but no examples. It works well for familiar tasks such as summarization, classification, or rewriting when the expected style is simple. It is fast to author and cheaper in tokens, but it can be underspecified.

In few-shot prompting, you include examples of inputs and ideal outputs. The model learns the pattern from context without updating its weights, which is called in-context learning. Few-shot examples are especially useful when the output style, edge cases, labels, or formatting rules are hard to describe abstractly.

Specific prompts reduce the search space. Name the audience, task, constraints, evidence source, acceptable assumptions, output shape, and success criteria. If the answer should be JSON, list the fields. If uncertainty is acceptable, tell the model to say I do not know when the provided context is insufficient.

Ambiguous prompts force the model to infer the missing requirements from pretraining and conversation context. That can look helpful in a demo, but it is fragile in production. The more important the task, the more the prompt should make hidden requirements explicit.

For multi-step work, asking the model to think step by step can improve planning and reduce skipped steps. In production, however, it is often better to ask for a concise rationale, checklist, or final answer with key assumptions rather than a full chain of thought. Full reasoning traces can be verbose, misleading, or inappropriate to expose to end users.

Use reasoning-capable models when the task requires long planning, mathematical proof, multi-hop analysis, or careful tradeoff evaluation. Prompting a smaller non-reasoning model to reason harder cannot fully replace a model trained and served for deeper reasoning. Self-consistency, where you sample several reasoning paths and choose the most common or best-supported answer, can help on hard questions at higher cost.

Grounding means telling the model which source of information is authoritative for the current answer. In a RAG prompt, the retrieved passages are the evidence, not the model memory. Clear delimiters around evidence, user input, and examples help the model avoid blending instructions with data.

Delimiters are not a security boundary by themselves. A retrieved document can still contain prompt injection text such as instructions to ignore the system message. The application should combine delimiters with role separation, retrieval filtering, output validation, and explicit instructions to treat retrieved text as data rather than commands.

Delimiters help because they make structure visible. Instead of relying on the model to infer where instructions end and data begins, you label each section: task, context, examples, input, and output rules. This is especially important when user-provided text contains quotes, commands, or content that looks like instructions.

The delimiter itself is not special. Headings, XML-like tags, numbered sections, or plain labels can all work. The value comes from consistent separation and from telling the model how to treat each section. For example, retrieved context should be used as evidence, not followed as instructions.

A few-shot prompt teaches the model the desired mapping from input to output. The examples should be close to production inputs and should include edge cases, not just perfect examples. If you want the model to return I do not know when evidence is missing, include an example where that is the correct behavior.

The tradeoff is token cost and maintenance. Examples consume context window budget and can become stale as policy changes. Keep examples minimal, representative, and versioned alongside the prompt.

Prompts that only say what not to do often leave the desired behavior underspecified. Instead of saying do not be vague, say answer in three bullets, each with a claim, evidence, and action. Instead of saying do not hallucinate, say use only the provided context and write I do not know when the context does not support the answer.

Positive instructions define the target behavior. Negative instructions are still useful for boundaries, but they should be paired with an explicit replacement behavior the model can follow.

Reasoning instructions and reasoning models can improve hard answers, but they are not free. More reasoning can increase latency, tokens, and sometimes verbosity. On routine extraction or rewriting tasks, a precise schema and examples often matter more than asking the model to think longer.

For difficult analysis, use staged prompting: first extract facts, then compare options, then produce the final recommendation. This decomposition gives you checkpoints to validate and reduces the chance that one long prompt hides an early mistake.

Log the prompt version, model version, parameter settings, retrieval source ids, and validation result for each request. Without this metadata, a quality regression is difficult to reproduce. Prompt changes should go through review and rollout like product logic.

If downstream code expects JSON or specific fields, validate the model output before using it. When validation fails, retry with a repair prompt or fall back to a safer path. Do not assume that specifying a format guarantees the model will always produce valid structure.

A prompt is not a security boundary. Use server-side authorization, tool allowlists, retrieval filtering, and data access controls. Prompt instructions can reduce accidental misuse, but they cannot safely grant or deny access to sensitive operations by themselves.

Take a vague request and add the missing contract: task, audience, evidence, constraints, and output format. The goal is not to make the prompt longer; it is to make the expected behavior observable.

A prompt should be tested against examples before it ships. This simple harness tracks expected output properties instead of relying on one demo result.