Prompt Does Not Define the Intended Audience

Q: Where in the prompt should the audience go?

At or near the top, as a labeled `## Audience` section before the task. The model reads it as a standing constraint that applies to everything after it, rather than as one instruction buried mid-prompt that competes with the rest.

No audience in the prompt means the model writes for an imaginary average reader and pleases no one. Fix it with a one-line audience block that calibrates vocabulary, depth, and tone.

Published: May 20, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

You asked the model to “explain how Postgres connection pooling works”. The output is 800 words pitched at… someone. It defines what a connection is (too basic for the senior engineer you wanted), says “client/server architecture” without ever naming PgBouncer (too vague for the DBA reviewing this), and skips the operational tuning advice you actually needed. The model wrote for an imaginary average reader, which is no reader, which pleases nobody.

Audience is the load-bearing constraint that calibrates vocabulary, depth, examples, and tone. Omit it and the model picks a middling default that wastes both the basics and the depth.

Fastest fix: add a 5-line ## Audience block to the top of your prompt naming the reader’s role, what they already know, what they should skip, and what they will do next. That one block calibrates everything below it. Google’s own technical-writing guidance says a good prompt identifies three things — a role, a target audience, and a document type (Google for Developers). Audience is the one people forget.

One caveat worth knowing up front: a decorative persona like “You are a world-class expert” does almost nothing on modern models, and controlled tests on thousands of factual questions found generic role labels did not reliably improve accuracy. What moves the needle is audience detail that actually changes the output — vocabulary, depth, what to skip. Specify the reader to change the writing, not to flatter the model.

Common causes

1. Prompt focuses on the subject, not the reader

You wrote “explain X” without saying “to whom”. The model defaults to a generic educated-but-not-expert reader. That reader does not exist.

How to spot it: the prompt names the topic but not the person.

2. Audience implied via context but not stated

“Our users” or “the team” leaves the model guessing who that is. Your team and the model’s training-set “team” are different.

How to spot it: audience referenced obliquely (“for us”, “internally”, “the usual readers”).

3. Multiple audiences in one piece

Trying to serve juniors and seniors with the same paragraph means each paragraph compromises. The output becomes “tutorial-with-too-much-jargon” or “reference-with-too-many-basics”.

How to spot it: you have several stakeholders, each unhappy with a different part.

4. No “what the audience does next”

If you do not say what the reader will do after reading, the model defaults to “comprehensive understanding”, which is too broad. Reader purpose is what calibrates depth.

How to spot it: the prompt has no verb for the reader.

5. No example of acceptable tone for the audience

You named the audience but did not anchor the voice. The model picks a default tone that may not match how your real audience prefers to be addressed.

How to spot it: tone is off even though the audience is correct.

Which bucket are you in

Symptom in the output	Most likely cause	Go to
Explains things your reader already knows	No audience / audience too broad (1, 2)	Steps 1-2
Right facts, wrong words (jargon missing or over-explained)	Vocabulary not calibrated (1)	Step 3
Each reviewer flags a different half	Multiple audiences in one piece (3)	Step 5
Comprehensive but not actionable	No “next action” for the reader (4)	Step 1 (Next action line)
Audience correct, voice feels wrong	No tone anchor (5)	Step 4

Before you change anything

Identify the actual reader in five words: role + experience + current task.
Find what they already know (so you can tell the model to skip it).
Identify what they will do after reading.
Find one sentence of writing they would call “in their voice”.
For multi-audience pieces, decide the primary audience.

Information to collect

The current prompt.
The output that was wrong-pitched (keep it as a counter-example).
Your real audience: role, level, context.
What they should be able to do after reading.
Any prior content they liked or disliked, to use as a tone anchor.

Shortest path to fix

Step 1: Add an audience block

## Audience
Role: senior backend engineer at a fintech
Knows: SQL well, runs production Postgres, has tuned pools before
Does not know: PgBouncer internals
Next action: choose between PgBouncer transaction-mode and session-mode
Tone: peer-to-peer, no hand-holding, terminology assumed

(For the rest of the prompt: write accordingly.)

One block calibrates vocabulary, depth, examples, and tone. The Next action line does the heavy lifting — it tells the model the purpose, which is what bounds depth. Keep this block as a labeled section; structured, headed prompts are the 2026 norm for a reason (the model treats ## Audience as a constraint, not as prose it can paraphrase away).

Step 2: State what to skip

Do not:
- Explain what a database connection is.
- Walk through what SQL means.
- Use the phrase "let's start from the basics".
- Compare to MongoDB.

Do:
- Use Postgres-specific terms (WAL, MVCC, prepared statements) without defining them.
- Reference PgBouncer config parameters by name (pool_mode, default_pool_size, max_client_conn).
- Give line-level config recommendations, not prose.

Negative constraints prevent the basics from sneaking back in. They are more reliable than positive ones here, because “write for an expert” still leaves the model room to over-explain, while “do not explain what a connection is” closes that door.

Step 3: Calibrate vocabulary

Match the reader’s vocabulary explicitly:

Experts: use jargon without defining it. Defining it signals you think they need it, which insults the audience.
Non-experts: define each term on first use.
Mixed: define in a footnote or a labeled glossary section so experts can skim past it.

If you are not sure which terms the audience knows, list 5-6 candidate terms in the prompt and tell the model which to assume and which to gloss.

Step 4: Anchor with a voice sample

Tone anchor (this is how the audience writes and reads):
"We hit pool exhaustion under load. Moved to PgBouncer transaction mode,
dropped p99 by 40%. Watch out for prepared-statement compatibility."

Match this tone: direct, specific, no fluff.

A two-sentence sample of real writing your audience produced beats any adjective (“professional”, “friendly”, “technical”). The model imitates the sample far more reliably than it follows a tone label.

Step 5: For multiple audiences, split

Audience: primary = senior engineers, secondary = junior engineers

Section 1 (for senior): operational tuning, pool-sizing math
Section 2 (for junior, labeled): glossary of terms used above

The explicit label makes the piece usable for both without forcing either paragraph to compromise. If the gap between audiences is wide, produce two outputs instead — see “If it still fails” below.

Step 6: Validate with a real reader

Before you reuse the prompt at scale, send one output to a person in the actual audience. If they say “this is for me”, you have landed. If they say “this is obviously for someone else”, your audience block is still too vague — go back to Step 1 and add the missing role/level/task detail.

How to confirm the fix

A real reader from the target audience reads the output and says it is calibrated for them.
Vocabulary matches what they actually use.
Skipped basics are skipped; assumed knowledge is assumed.
The reader can take the next action (the verb you specified) without follow-up questions.
Output tone matches your anchor sample.

If it still fails

The audience description is still too vague. Get more specific on role + level + task. “Engineer” is vague; “senior backend engineer who runs production Postgres” is not.
No tone anchor. Add a real sample of writing the audience likes; the model imitates examples better than it follows adjectives.
Audience scope too wide. Narrow it. A narrower audience produces a more sharply calibrated output. “Everyone” is the worst possible audience.
The persona is doing the work instead of the detail. If you only added “You are an expert” and nothing changed, that is expected — a bare role label rarely shifts a modern model’s output. Move the specificity into what to skip, what vocabulary to assume, and the next action.
Genuinely two audiences. Produce two outputs and let each be sharp. Merging is usually worse than running the prompt twice with different audience blocks.

FAQ

Does telling the model “You are an expert” actually help? On its own, rarely. Controlled tests across thousands of factual questions found generic role labels did not reliably improve accuracy, and on capable 2026 models the effect is near zero. What helps is concrete audience detail that changes the writing — what to skip, which terms to assume, what the reader does next. Use the persona to set up that detail, not as a substitute for it.

Where in the prompt should the audience go? At or near the top, as a labeled ## Audience section before the task. The model reads it as a standing constraint that applies to everything after it, rather than as one instruction buried mid-prompt that competes with the rest.

How specific does the audience need to be? Specific enough that the description would change the output. “Senior backend engineer who has tuned Postgres pools before” tells the model to skip the basics and name PgBouncer parameters. If swapping the audience line would not change a single sentence, it is too vague.

What if I genuinely have two audiences? Pick a primary audience and serve it well, with a clearly labeled secondary section (for example a glossary) for the other. If the two are far apart in level, generate two separate outputs. One paragraph cannot serve a junior and a senior without short-changing both.

The audience is right but the tone is still off — now what? Add a tone anchor (Step 4): two sentences of real writing the audience produces or admires. A concrete sample steers the model far more reliably than tone adjectives like “professional” or “friendly”.

Is “audience” the same as “persona prompting”? No. Persona prompting assigns the model a role (“act as a lawyer”). Audience specification tells the model who the reader is. The reader is the one that calibrates vocabulary and depth, and it is the more reliable lever of the two.

Prevention

Default: every content-generation prompt names the audience in one line.
Save audience profiles for recurring readers (senior engineer, founder, designer) and paste them in.
Audit your last five prompts: how many named the audience? Under five is your habit gap.
For team workflows, build audience profiles as a shared, reusable resource.
Treat “general audience” as a smell. It usually means “I have not figured out who this is for”.
When in doubt, ask the model to propose three audience candidates and pick one.

Tags: #Troubleshooting #Prompt #Prompt quality #Prompt engineering