prompt

In depth

It conditions, it does not command

Technically, a prompt orders nothing: it conditions. The model produces the most plausible continuation of the text submitted to it, and the prompt is the part of that text you write. This is why form counts as much as content: an example of the expected output steers more than an abstract instruction, and a prohibition leaves more latitude than a positive instruction. Nothing in the mechanism guarantees that an instruction will be followed: it is influential, not binding.

Three things under one word

Everyday vocabulary calls three different things a prompt. The system prompt is written by whoever designs the product and holds for every exchange, the user prompt is your message, and the effective prompt is everything actually sent to the model, context included. The confusion is expensive in an organisation, where the user’s message gets optimised while the troublesome behaviour comes from a permanent instruction. Nor do these layers carry the authority attributed to them: they are told apart by convention, and a text inserted further along can compete with them.

Judging on one attempt

The most frequent trap is to judge a prompt on one successful try. A model produces variable outputs, and two close wordings can give very different results: a serious prompt is compared on a set of cases, never on an impression. The second trap is fragility: an instruction tuned to one particular model warps as soon as you change model, which makes a prompt an asset to revise rather than a settled gain. The third belongs to security: since everything reaches the model as text, a document or a page consulted along the way can carry instructions that compete with yours.