Field Notes / Working with AI

How to Prompt an AI Model Well

Most people treat a prompt like a wish. The ones who get reliable output treat it like a structured instrument, with parts that each do a job.

Most people treat a prompt like a wish: they type roughly what they want and hope the model reads their mind. The people who get consistently good output treat a prompt like a structured instrument. It has parts, each part does a job, and when the output is weak you can usually name the part that failed and fix just that.

This is a working reference. It covers the anatomy of a strong prompt, the habits that separate reliable results from lucky ones, and a demonstration prompt at the end you can adapt.

A prompt is a structured instrument

Think of a prompt the way you would think of a brief you hand to a capable but literal new hire. They will do exactly what you say, fill gaps with reasonable defaults, and take your tone as permission. Vague in, vague out. Precise in, precise out.

A strong prompt is built from a small number of clauses, each carrying weight. You will not need all seven every time. But when output disappoints, the missing clause is almost always one of these.

RoleTell the model who it is. "You are a senior financial analyst" produces sharper, better calibrated output than no framing, because it sets vocabulary, depth, and standard.
ContextGive it the situation and the person it serves. Who is asking, what they know already, what the output is for. This is where most thin prompts fall down.
TaskState plainly what you want done. One clear instruction beats three hedged ones.
ConstraintsBoundaries the output must respect: length, tone, what to avoid, what to prioritise when goals compete.
FormatHow the answer should be shaped. Prose, a table, a ranked list, a specific structure. If you care about the shape, specify it.
ExamplesOne or two demonstrations of good output, and where useful, one of bad output. Examples teach faster than description.
Reasoning instructionFor anything hard or numerical, tell it to reason step by step, then check its own answer against a criterion before committing.

Be firm, not tentative

Softening language invites half measures. "Try and be objective" and "maybe give me some options" tell the model that partial effort is acceptable. Prompts work as instructions, not as polite requests.

Write "Be objective, even when it means telling me something I do not want to hear." Write "Give me your recommended option first, with reasoning, then two alternatives." Firm phrasing raises the floor on quality.

Show, do not just tell

A single worked example does more than a paragraph of adjectives. If you want a certain style, paste a short sample of it. If a particular failure keeps recurring, show the model an example of the wrong output labelled as wrong, alongside the right one. Contrast sharpens the target. This is the cheapest quality upgrade available and the most underused.

Make hard tasks reason, then self check

For multi step logic, calculations, or anything where a wrong answer is easy to produce and hard to spot, two moves catch errors that otherwise slip through. First, ask the model to reason through the problem before giving a final answer, so the working is visible. Second, ask it to check that answer against an explicit criterion. "Solve this, then verify your result satisfies the original constraints and correct it if not." Errors that survive the first pass often die on the second.

The part that actually separates people: treat it as a loop

This is the habit that matters most, and it is method rather than cleverness. Prompting is a loop, not an incantation.

Define what good looks like before you judge the output. If you cannot say what a strong answer would contain, you cannot tell whether you got one.
Test on a genuinely hard case. One easy success proves nothing. Push it on the case most likely to break.
Read the failure to find the weak clause. The symptom usually names the fix. Wrong tone points at the role or constraints. Missing context points at the context clause. Rambling points at format.
Change one lever at a time. Change everything at once and you learn nothing about what worked.
Version your prompts like code. Keep the ones that work. You will want to go back.
Trim to the smallest prompt that still works. Every extra clause is cost and another chance to confuse the model. Cut anything that does not earn its place.

Most "the AI is not good enough" moments are prompt shaped. The output is a mirror of the instruction, and the loop is how you improve the instruction rather than blaming the mirror.

One caveat: guidance is model specific

Prompting advice shifts between model generations. Techniques that helped older models can hurt newer ones. In particular, the aggressive "CRITICAL: you MUST" style that older models needed tends to backfire on newer ones, which respond better to clear, calm instruction than to shouting. When you are tuning something in production, check the current guidance for the specific model you are calling rather than assuming last year's tricks still apply.

Worked example: a reusable advisor prompt

Here is a generic prompt that puts the anatomy above into practice. It is written for a "personal advisor" use case, but the structure transfers to almost anything. Adapt the bracketed parts.

You are my personal advisor. Your role is to give me sharp, specific, actionable guidance across work, personal development, and life decisions. Who I amI am [role and situation, for example: a founder scaling a small business]. My top priority for the next [timeframe] is [primary goal]. Relevant background: [anything the advisor should factor in, such as constraints, commitments, or working style]. How I think and workI value efficiency above everything. Be direct and concise. Never pad responses. I want to grow not only in output but in judgement and clarity over time. How to advise meBe objective, even when that means telling me something I may not want to hear. Prioritise specificity over generality. Default to short, structured answers unless depth is clearly needed. When I ask for options, give me your recommended one first with reasoning, then the alternatives. For anything involving numbers or multi step logic, reason it through and check your answer before giving it to me.

Read it back against the anatomy. The first line sets the role, "Who I am" supplies context, "How I think and work" fixes constraints and format, and "How to advise me" combines task, constraints, and a reasoning instruction. That is the skeleton, filled in. Start here, run it against a hard question, read where it falls short, and adjust one clause at a time.