A good prompt tells an AI assistant what to do, what information to use, and what a usable answer looks like. This guide shows how to write those instructions, revise weak responses, and avoid confusing polished language with verified facts.
How Do You Write Better AI Prompts?
State one clear task, supply the necessary context, and describe the output you need. Add examples when the desired pattern is difficult to explain, and define what the assistant should do when information is missing. Improve prompts by comparing outputs with specific acceptance criteria rather than adding increasingly elaborate role-play.
Build a prompt around the actual deliverable
Prompting is the practice of supplying instructions and context to a model. It is not a secret vocabulary that unlocks reliable truth. Clear instructions can make an answer more relevant, but factual correctness still depends on the information available and how you check the result.
Start with the deliverable. “Write an email” leaves the audience, purpose, facts, and tone open. “Draft a customer update explaining the delivery delay using only the facts below” establishes a much more useful target. Describe the task before asking for a personality or style.
A role can help set vocabulary and perspective. “Write for a nontechnical operations manager” is often more precise than “act as a world-class expert.” Neither phrase gives the model actual professional credentials or access to information you have not supplied.
OpenAI's prompt-engineering documentation recommends explicit instructions, relevant context, and examples. Treat that as a practical starting point; different models and tasks may respond differently to the same wording.
- Name the action. Why: Vague requests invite the model to choose the job for you. How: Use a concrete verb such as summarize, classify, compare, extract, or draft.
- Name the reader. Why: An engineer and a new customer need different explanations. How: Specify what the audience already knows and what they need to decide.
- Define completion. Why: A fluent answer can still be unusable. How: State the required sections, length range, and any fields that must be present.
Supply context without burying the task
Useful context changes the answer. Include approved facts, relevant terminology, the purpose of the work, and constraints the model cannot infer. Exclude unrelated history and sensitive information that the tool is not approved to process.
Keep instructions visually separate from reference material. Labels such as “Task,” “Source material,” and “Output requirements” make the prompt easier for both people and the model to interpret. If you paste several documents, label their dates and authority so conflicts are visible.
| Prompt element | Useful example | What it prevents |
|---|---|---|
| Task | Extract action items | Unrequested commentary |
| Audience | New support staff | Unexplained specialist terms |
| Source boundary | Use only the supplied notes | Unsupported additions |
| Output | Table with owner and deadline | Inconsistent formatting |
| Missing-data rule | Write “not stated” | Invented details |
| Tone | Direct and courteous | Unwanted promotional language |
- Identify authoritative material. Why: Several sources may disagree. How: State which document controls and ask the assistant to flag unresolved conflicts rather than quietly choosing one.
- State the uncertainty rule. Why: The model may fill gaps with plausible details. How: Require “not provided” for absent facts and a short list of questions when the missing information blocks the task.
Do not assume uploaded files are completely available merely because the interface accepted them. A product may retrieve only selected passages or truncate material. For important work, check that the response cites or reproduces the specific passages needed for the task.
Use examples and output constraints selectively
A zero-shot prompt gives instructions without demonstrations. A few-shot prompt adds examples of inputs and desired outputs. Examples are particularly useful for organization-specific labels, a distinctive writing style, or a transformation with subtle rules.
Choose examples that demonstrate the rule, not just the easiest case. For instance, if you are classifying support requests, include a message containing two issues and show whether it should receive one label or several. Otherwise the model has to infer a policy you never stated.
- Add a small, varied example set. Why: Examples can reveal expectations more clearly than adjectives. How: Include a typical case, an edge case, and a missing-information case when those distinctions matter.
- Check examples against instructions. Why: Conflicting demonstrations create an ambiguous task. How: Ensure the labels, tone, and field names in each example match the written requirements.
Specify structured output when another system will consume it. Ask for a defined set of fields and explain allowable values. However, requesting JSON in a chat does not guarantee valid JSON; an application should parse and validate the result, and use schema-enforcement features where available.
Avoid unnecessary constraints. Requiring an exact sentence count, a rigid tone, exhaustive coverage, and extreme brevity can produce conflicting goals. Decide which requirements are mandatory and which are preferences, then tell the model how to prioritize them.
A worked example: draft a bounded customer update
Imagine a hypothetical service team needs to explain a delayed shipment. The approved facts are that dispatch moved from Tuesday to Thursday and tracking will be sent after dispatch. No delivery date or compensation has been approved.
A weak prompt says, “Write a friendly apology about the order.” It leaves the assistant room to add a delivery promise or a refund. A more useful prompt is:
Task: Draft a customer email about a shipment delay. Audience: a customer awaiting dispatch. Approved facts: dispatch moved from Tuesday to Thursday; tracking will be emailed after dispatch. Use only these facts. Do not invent a delivery date, cause, discount, or refund. Write a subject line and a body under 100 words. Be courteous and direct. If another fact is necessary, list a question after the draft rather than filling the gap.
The reviewer can now check the answer against a concrete list. Does it state Thursday? Does it avoid promising arrival? Does it include tracking without implying the package is already moving? These checks are more useful than asking whether the email sounds impressive.
If the response is too apologetic, change the tone instruction without changing the facts. If it invents compensation, strengthen the boundary and inspect whether an example accidentally suggested a refund. Repeating “be accurate” would not address that specific failure.
Refine prompts with evidence, not magic phrases
Keep the original prompt and record what failed. Distinguish between missing context, misunderstood instructions, unsupported factual claims, and an unsuitable task. Each category suggests a different repair.
- Change one important variable at a time. Why: Multiple simultaneous edits obscure what helped. How: Add a missing rule or replace an example, then rerun the same representative cases.
- Evaluate beyond the favorite example. Why: A prompt can improve one response while making another worse. How: Maintain a small set of normal and difficult inputs with expected characteristics.
OpenAI's evaluation guide describes assessing model outputs against criteria. You can apply the same principle manually: check whether required facts appear, prohibited claims are absent, and the output fits its destination. For important factual work, compare against original sources rather than asking the model to certify its own answer.
A request to “check your work” can produce useful revisions, but it is not independent verification. Ask for a concise explanation of assumptions or supporting evidence when useful; lengthy hidden-reasoning requests are not necessary for a well-specified task. Use calculators, databases, or authoritative documents for checks that those tools can perform directly.
Questions About Writing AI Prompts
Do longer prompts always work better?
No. Length helps only when it adds relevant instructions or evidence. Repetition and unrelated background can make priorities harder to identify. Start with the minimum complete specification, then add material to address an observed failure rather than expanding the prompt automatically.
Should I start a new chat for every request?
Start fresh when earlier context is irrelevant, contradictory, or sensitive. Continue a conversation when prior approved facts and decisions are still useful. For repeated business tasks, keep a reusable prompt template instead of relying on an increasingly long chat history.
Can a prompt guarantee that the model will not invent facts?
No. Source boundaries and missing-information rules reduce opportunities for invention but do not eliminate them. Review consequential statements against evidence. If accuracy depends on current information, provide an approved current source or use a tool that can retrieve one and inspect its citations.
How do I make a reusable prompt template?
Keep stable instructions separate from variable fields such as audience, source text, and deadline. Label placeholders clearly and check that none remain blank before sending. Save the template version alongside examples of acceptable output so later edits can be compared fairly.
Build Prompts Around Clear Outputs
Effective prompting makes expectations explicit and failures easier to diagnose. The goal is a reviewable result, not a clever-sounding instruction.
Next steps: Put prompts inside an AI workflow checklist, learn how language models work, or browse the AI Tools hub.
Sources
- OpenAI — Prompt engineering
- OpenAI — Working with evals
This guide is general education, not professional advice.