How to Write Effective Prompts for AI Models

A prompt is the text you send to a language model. The model reads that text and predicts what should come next, so the wording you choose shapes the answer you get. Two requests that mean the same thing to a person can produce very different results, and a small change in structure often matters more than a clever trick.

This post explains why prompts work the way they do and gives a practical structure you can reuse for most tasks.

Why wording matters

A large language model does not look up an answer in a database. It generates text one token at a time, choosing each next token based on everything before it, including your prompt. The prompt sets the context. If the context describes a careful expert writing for beginners, the continuation tends to look like careful expert writing for beginners. If the context is vague, the model fills the gap with the most common patterns it saw during training.

This explains why a prompt that says "explain this" often gives a generic answer, while "explain this to a second-year nursing student, in five bullet points, focusing on side effects" constrains the output a lot. You are not giving the model new knowledge. You are narrowing the set of plausible continuations.

The parts of a clear prompt

Most useful prompts contain some combination of five elements. You do not need all five every time, but they cover the common gaps.

1. Role or perspective. Who the model should act as, such as a code reviewer or a tax preparer. This sets vocabulary and level of detail.
2. Task. The specific action, stated as a verb: summarize, compare, rewrite, extract, classify.
3. Context. The material the model needs, such as the text to summarize or the audience and purpose.
4. Format. The shape of the answer: a table, a numbered list, JSON, a word limit.
5. Constraints. What to avoid or include, such as "do not invent sources" or "use only the attached text."

Writing these out in plain language, one per line or short paragraph, makes the request easier to check. If a part is missing, the answer often reveals it.

Zero-shot and few-shot prompting

A zero-shot prompt gives the task with no examples. Modern models handle many common tasks this way, especially when the instruction is precise. A few-shot prompt includes two or three examples of the input and desired output before the real input. Examples are powerful for unusual formats, such as a particular label style or a house tone, because they show the pattern instead of describing it.

Examples also cost tokens and can bias the model toward their content. If the examples all have the same length or topic, the model may copy that pattern even when it does not fit. Good examples vary in surface detail while sharing the rule you want the model to follow.

Asking for step-by-step reasoning

For arithmetic, logic and multi-step questions, asking the model to show its reasoning often improves accuracy. A 2022 study by Wei and colleagues showed that prompting large models with worked examples that included intermediate steps, known as chain-of-thought prompting, raised scores on several math and commonsense benchmarks. The effect was strongest on the largest models.

In practice, a simple instruction such as "work through the steps before giving the final answer" captures much of the benefit. For tasks where the reasoning itself is not needed, such as formatting a list, extra steps only add length.

A comparison of common prompt patterns

Pattern	Best for	Main risk
Direct instruction	Simple, well-defined tasks	Generic answers when context is missing
Role plus task	Tone and expertise	Overconfident persona with weak facts
Few-shot examples	Custom formats and labels	Copying example details
Step-by-step request	Math, logic, planning	Longer answers, slower replies
Output schema	Data extraction, code, tables	Valid-looking but wrong values

No pattern wins everywhere. Most good prompts combine a clear task with one or two of the others.

Common mistakes

The first common mistake is asking for too much in one message. A request to research, summarize, critique and rewrite a document at once often produces a shallow version of each step. Splitting it into separate prompts usually gives better results and makes errors easier to find.

The second is leaving out the audience. The same explanation of a concept can be correct for an engineer and useless for a student. Naming the reader is one of the cheapest improvements you can make.

The third is trusting specifics without checking. Models can produce fluent citations, dates, numbers and quotes that do not exist. For anything that matters, ask for the source text, check it yourself, and treat unsupported specifics as unverified. Asking the model to say when it is unsure can reduce this problem but does not remove it.

Iterating like an engineer

Treat a prompt as a draft. Run it, read the output, and identify the first thing that is wrong. Then change one element, such as adding a constraint or an example, and run it again. Changing several things at once makes it impossible to know which change helped.

Keep a short log of prompts that work for recurring tasks. A reusable template with placeholders for the input, audience and format saves time and makes results more consistent across sessions.

A before and after example

Consider the vague request "Tell me about my resume." The model has no role, no target job, no format and no rule about evidence, so it will produce a generic review that could apply to anyone. A stronger version looks like this: "You are a hiring manager at a mid-sized software company. Review the resume below for a backend engineer role. List three strengths and three gaps, each in one sentence, and quote the line that supports each point. If a claim is unclear, say so instead of guessing." Each part does a job. The role sets the perspective, the target sets the standard, the format limits length, the quoting rule ties claims to the text, and the last sentence gives the model permission to admit uncertainty.

The second version is longer, but it is far easier to check. You can see at a glance whether each point is supported, and you can rerun it with a different job description without rewriting the whole request.

Giving the model permission to be uncertain

Models tend to produce a confident answer by default, because confident text is common in their training data. Telling the model that "I do not know" is an acceptable answer changes this pattern for many questions. Asking it to mark which statements come from the text you supplied and which come from general knowledge also helps you see where to verify. None of these instructions guarantees accuracy, but they make the uncertain parts easier to find.

Key takeaways

A prompt steers a language model by setting the context for its next-token predictions. Clear prompts state a role, a task, the relevant context, the desired format and any constraints. Examples help with unusual formats, and step-by-step requests help with reasoning-heavy problems.

Prompting is not magic, and it does not give the model knowledge it lacks. Check important facts against real sources, split large jobs into smaller ones, and change one thing at a time when you refine a prompt. Those habits matter more than any single phrase.