Most bad model outputs come from bad prompts, not bad models. The model can only work with what you give it. If you leave something out, it fills the gap with its best guess, and that guess may not match what you wanted.
The four parts of a good prompt#
A good prompt says four things explicitly. Check each one before you send.
| Part | What it answers |
|---|---|
| Task | What should the model do? |
| Audience | Who will read the result? |
| Format | What shape should it take: length, bullets or prose? |
| Constraints | What to focus on, and what to leave out? |
A vague prompt and a better one#
Take the vague prompt "Summarize this article." The model doesn't know how long the summary should be or who will read it. It doesn't know whether you want bullet points or prose, or whether some topics are off limits. It guesses all of that.
Here is the same request with all four parts filled in.
Summarize this article in three sentences for a non-technical
audience. Focus on the business impact, not the technical
details. Do not mention specific company names.The task is to summarize. The audience is non-technical. The format is three sentences. The constraints are to focus on business impact and to leave out company names.
Say what to do, not what to avoid#
Phrase instructions positively where you can. A negative instruction tells the model what not to do but leaves the rest of the space open. A positive one closes it.
| Negative (leaves space open) | Positive (closes it) |
|---|---|
| Don't respond in other languages. | Respond only in English. |
Some constraints are naturally negative, like "do not mention company names" above. That is fine when the thing to avoid is specific. Prefer the positive form when you could say the same thing either way.
Trade-offs#
More explicit prompts take more work to write and maintain. A longer system prompt (see Messages) also means more input tokens on every request, which adds to cost.
The practical balance has three parts:
- Be explicit about the things that matter most.
- Let the model use judgment on the rest.
- Handle edge cases in code rather than trying to cover everything in the prompt.
When an output is wrong, ask first whether it is a prompt problem or a model problem. Most of the time, it is the prompt.
Short line#
A good prompt states the task, audience, format and constraints, and says what to do rather than what to avoid. When output is wrong, suspect the prompt first.
Key takeaways#
- Most bad outputs come from bad prompts, because the model only has what you give it.
- State four things: task, audience, format and constraints.
- Missing details are filled by the model's best guess.
- Prefer positive instructions: they close the space, negative ones leave it open.
- Be explicit about what matters most, rely on judgment for the rest, and handle edge cases in code.
- Longer prompts cost more input tokens on every request.