VI EN
Tips

6 core Claude prompting principles from Anthropic: clarity, reasons, examples, XML

Binh 4 min read Đọc bài này bằng tiếng Việt

TL;DR

Good prompts need no magic words: be explicit about scope, explain why, give 3–5 diverse examples, separate parts with XML tags, set a role and state what to do rather than what not to do.

Bad prompts rarely lack a "magic phrase". Mostly the writer forgets that the model doesn't know what's in their head: the context, the reasons, the desired format, how far to go. Anthropic's Prompting best practices doc has a memorable image: treat Claude as a very capable new employee who doesn't yet know your conventions and processes. This post summarises the core principles that apply to all current Claude models, with before/after examples.

The colleague test

Hand your prompt to a colleague who knows little about the task and ask them to follow it. If they're confused, Claude will be too. This test is cheap and catches 80% of prompt mistakes.

6 core principles

PrincipleInstead ofWrite
Be clear and direct"Create an analytics dashboard""Create an analytics dashboard with as many useful interactions as possible, going beyond the basics"
Give the reason"NEVER use ellipses""The reply will be read by text-to-speech, so don't use ellipses because the engine can't pronounce them"
Use examplesDescribing the tone with adjectives3–5 real, diverse examples wrapped in <example>
Structure with XML tagsMixing instructions, data and examplesSeparate <instructions>, <context>, <input>
Assign a roleNo system promptOne role sentence in the system prompt
Say what to do"Don't use markdown""Write in flowing paragraphs"

1. Be clear and state the scope

Newer models tend to do exactly what's asked, without extras. If you want the full version, say so. When order or completeness matters, write steps as a numbered list. State the output format and constraints (length, language, audience).

2. Explain "why"

When Claude knows the reason, it generalises to situations you didn't anticipate. In the text-to-speech example above, Claude not only drops ellipses but also avoids other symbols that are hard to read aloud. An all-caps rule with no reason works worse than one ordinary sentence of explanation.

3. Examples are the most reliable way to steer output

  • Realistic: taken from your real data.
  • Diverse: covering edge cases, different enough that Claude doesn't copy an accidental detail (for example all three samples opening with the same sentence).
  • Structured: wrapped in <example>/<examples> to separate them from instructions.

Tip: ask Claude itself whether your example set is diverse enough, or have it generate more from a few seeds.

4. XML tags for multi-part prompts

<context>
The company sells POS software for coffee shops; customers are shop owners.
</context>
<instructions>
1. Read the customer email in the <email> tag.
2. Draft a short, friendly reply, at most 120 words.
3. If it's a payment issue, suggest calling the hotline.
</instructions>
<email>{{EMAIL}}</email>

Use consistent tag names across prompts; nest tags when there's a natural hierarchy (several <document> inside <documents>).

5. Controlling format

  • Say what to do rather than forbid: "write in flowing paragraphs" works better than "don't use markdown".
  • Match the prompt to the output: the prompt's style influences the reply's style. Removing markdown from the prompt reduces markdown in the output.
  • Want a summary after tool use? Ask explicitly, because newer models summarise less on their own and go straight to the next step.

Notes when moving to newer models

  • Prompts written for older models often have lots of "CRITICAL" and "MUST". Newer models respond more strongly to the system prompt, so over-emphasis (especially "you must use tool/skill X") can lead to tool overuse. The docs recommend softening the wording: replace "CRITICAL: You MUST…" with a normal sentence.
  • Each model has its own quirks (such as default response length). The docs recommend re-checking with your own evals rather than assuming every technique carries over.
  • "Think step by step" is now just ordinary text; thinking depth is controlled by the effort parameter.

How to apply it

  • Dev: Standardise a prompt template with <context>, <instructions>, <examples>, <input>. Replace every "NEVER…" with a description of what to do plus the reason.
  • Tech Lead: Keep prompts in the repo, review them like code, with a small eval set to compare before/after each change.
  • PM: The "context" and "why" are your domain knowledge. Writing them down is the PM's biggest contribution to the quality of AI features.

Sources & references

  1. Prompting best practices — Claude Docs
More on Tips