Prompt engineering fundamentals

Why prompts matter

A model answers whatever it thinks you asked. When the request is vague, it fills the gaps with the most typical interpretation, which is rarely the one you had in mind. Prompt engineering is the practice of removing those gaps so the model has less to guess.

Three facts make this necessary. Output varies from run to run, models can invent content when they lack information, and different models respond differently to the same wording. A well-built prompt narrows all three problems, although it never removes them completely.

Chat models are trained to follow instructions arranged in messages. The system message sets lasting rules and a role; user messages carry each request. Put stable behaviour, such as tone and audience, in the system message, and the specific task in the user message.

Think of the prompt as a brief for a capable colleague who has never seen your project. Everything you know and they do not, from the reader's age to the purpose of the text, has to be written down, or it will be guessed.

Instructions: say exactly what you want

Name the task with a verb and an object: explain, summarise, translate, list, rewrite. Then add who the answer is for, how long it should be and what tone to use. Explain photosynthesis leaves all of that open; Explain photosynthesis to a 14-year-old in about 100 words does not.

Prefer describing the output you want over listing what to avoid. A model told do not be too technical still has to guess the right level, while use words a 14-year-old knows and define any scientific term gives it a target.

Keep one main task per prompt. A request to explain, quiz and plan in a single message usually does each part worse than three focused requests, and it makes failures harder to locate. Put the instructions near the start, where they are easy to find and change.

Constraints are instructions too. If the answer must fit on a phone screen, mention only material from the notes, or avoid giving away the solution to a homework problem, say so in plain words rather than hoping the model infers it.

• Task: the verb and what it applies to.
• Audience: who reads the answer and what they already know.
• Length and tone: a word count or number of items, and the register.
• Constraints: sources to use, things to leave out, limits on scope.

Context: give the model what it cannot know

The model knows nothing about your course, your level or what you already understand. Supplying that context is often the single biggest improvement you can make, because it turns a generic answer into one that fits your situation.

Context comes in two kinds. Primary content is the material the task works on, such as a page of notes to summarise. Supporting content shapes the answer without being the subject, such as the exam board, the learner's level or a list of terms to emphasise.

Mark clearly where pasted material starts and ends. Triple quotes, a labelled block such as NOTES: or a line of dashes all work. Without delimiters the model can mistake a sentence inside your notes for an instruction, which is also the first step towards the prompt-injection attacks covered later in the course.

Context should be relevant, not exhaustive. Pasting a whole textbook chapter to answer one question adds cost and can bury the important paragraph; pick the passages that matter.

Examples and output format

An example of the answer you want often communicates more than a paragraph of description. Show one input and its ideal output, and the model will copy the structure, length and style. The next lesson goes further with several examples at once.

Fix the output format whenever code or a person will scan the result. Spell out the headings, the number of items, and whether you want a list, a table or JSON. A predictable format lets Study Buddy display answers consistently and lets you check them automatically.

A cue can steer the start of the answer. Ending the prompt with Definition: nudges the model to begin there instead of with a polite preamble.

Turn a prompt that works into a template with placeholders such as {topic} and {notes}. Your code fills the placeholders at run time, so every request gets the same carefully tested wording.

Check that your example matches the format block exactly. When the two disagree, for instance three key points in the description and four in the example, the model has to pick one, and it will not always pick the same one.

Iterate like an engineer

Prompt writing is trial and error, but it does not have to be random. Change one element at a time, run the same few inputs, and compare. If you change the audience, the format and the examples together, you will not know which change helped.

Keep prompts in files under version control rather than inside chat windows or buried in code. A file history shows what changed and when, and it lets you roll back when a new version turns out worse.

Judge a change on several inputs, not one. A tweak that fixes the answer about photosynthesis may break the one about fractions, so rerun the small test set you built in lesson 3 before you keep it.

Write a short note next to each version saying what you changed and why. It takes seconds, and months later it saves you from repeating an experiment you already tried and rejected.

Stop when the prompt meets your bar on the test set. Endless polishing produces wording that is tuned to a few inputs and fragile on new ones; a plain, clear prompt usually travels better between models.