What a prompt really is
A prompt is the text you give a language model to continue or respond to. The model has no memory of your project and no knowledge of what you meant beyond what appears in that text, plus whatever it absorbed during training. So the prompt carries your whole specification. Vague specifications produce vague, variable results; clear ones tend to produce more consistent behaviour, though never a guarantee.
It helps to treat a prompt the way you would treat any other piece of project code: write it deliberately, test it, and keep a record of changes.
Be clear about the task
State what you want done in plain terms. Compare these two requests:
- “Tell me about this sensor log.”
- “Read the sensor log below and list any readings where the temperature changes by more than five degrees between consecutive lines. Give the line number and both values.”
The second names the input, the operation, the condition and the output. The model has far less room to guess. A good habit is to start with the action you want, such as summarise, extract, classify, rewrite or compare, and then add the details.
Supply the context the model cannot know
The model does not know your device, your units, your audience or your definitions. Include what it needs:
- Role or setting: for example, that it is helping with a hobby electronics project.
- Background facts: the units used, what the columns mean, what a term refers to.
- The audience: a beginner needs different wording than an experienced builder.
- The source material itself: if the answer must come from a document, paste the relevant part rather than hoping the model remembers it.
Supplying the source text is also one of the most effective ways to reduce invented answers, since the model can draw on what is in front of it. It does not remove the risk entirely, which is why the checking habits below matter, and why it is worth understanding model hallucinations.
Add constraints
Constraints narrow the space of acceptable answers. Useful ones include:
- Length: “no more than three sentences”.
- Scope: “use only the information in the text below”.
- Format: “answer as a list”, or “respond with valid JSON containing these fields”.
- Tone or reading level.
- What to do when unsure: “If the text does not say, reply with ‘not stated’ rather than guessing.”
That last constraint is especially valuable. Models tend to produce a plausible answer even when they lack the information, so giving an explicit, acceptable way to decline helps. Whether it is followed reliably depends on the model, so test it.
Use examples
Showing is often clearer than describing. Including a few worked examples of input and the desired output, sometimes called few-shot prompting, helps the model infer the pattern, format and style you want.
Some pointers:
- Choose examples that cover the range of cases, including a tricky one.
- Keep them consistent in format; inconsistent examples confuse the pattern.
- Do not make every example nearly identical, or the model may copy it too closely.
- Keep the examples accurate. A wrong example teaches a wrong pattern.
Examples take up space in the prompt, so balance their benefit against length and cost.
Ask for structure when software will read the answer
If a program consumes the output, free-form prose is fragile. Ask for a defined structure, such as a fixed set of labelled fields or a machine-readable format. Then validate it in code: check that the response parses, that required fields are present, and that values fall within allowed ranges. If validation fails, you can retry or fall back to a default. Treating the output as untrusted input, the way you would handle data arriving through web APIs, avoids many surprises. This is where coding habits like automated testing and readable code pay off.
Break big jobs into steps
A single prompt that asks for many things at once tends to give uneven results. Splitting the job into stages, such as extract the facts, then classify them, then write the summary, makes each step easier to specify and check. Intermediate results can be inspected, which helps with debugging strategy when something goes wrong.
You may also ask a model to explain its reasoning, which can help on some tasks, but the explanation it gives is generated text and is not always a faithful account of how the answer arose. Do not treat it as proof of correctness.
Check the results
Prompting reduces errors; it does not eliminate them. Build checking into the process.
- Test on a fixed set of inputs. Keep a small collection of example inputs with known good outputs and rerun them whenever you change the prompt or the model. This is the same idea as automated testing for ordinary code.
- Include awkward cases: empty input, very long input, unexpected languages, contradictory data, and attempts to override your instructions.
- Verify facts independently when they matter, against the source, a datasheet or a trusted reference.
- Expect variation. Many systems have a setting that controls randomness. Lower randomness usually gives more repeatable answers, but even then exact repeatability is not promised across versions or providers.
- Keep a human in the loop for anything with real consequences.
Watch for injected instructions
If your prompt includes text you did not write, such as an email, a web page or a user’s message, that text might contain instructions aimed at the model. Separate your instructions clearly from the supplied content, tell the model to treat the content as data, and do not give the model the power to take consequential actions on its own on the strength of such text. No wording of a prompt fully prevents this, so limit what the system is able to do.
Treat prompts as versioned assets
Store prompts in files, not scattered through code, and track changes with version control. Note which model and settings each version was tested with, since a prompt that works on one model may behave differently on another. Hosted models can also be updated, so retest periodically.
Where the prompt sends sensitive material to an online service, remember the points in cloud AI privacy. If you run the model yourself, as in running language models on local hardware, the same prompt principles apply, though smaller models may need simpler, more explicit instructions.