简体中文
← Back to all posts
Article

How to Write Better AI Prompts: A Beginner's Check-and-Revise Method

Turn a vague request into a useful, faithful, and checkable AI prompt by defining the task, supplying relevant context, preserving boundaries, and revising the result.

An open task folder holding a target, source page, boundary marker, and checked result card

Suppose you give an AI this instruction:

Write a follow-up email from these meeting notes.

The reply sounds polished. It thanks everyone, lists three decisions, and assigns the next steps. There is only one problem: the notes contain two proposals, not two decisions, and nobody has agreed who will own one of the tasks.

The wording is good. The email is not ready to send.

This is where many beginners conclude that they need a longer prompt, a special formula, or an impressive role such as “world-class communications expert.” The more useful diagnosis is simpler: the AI was not told how to distinguish a usable answer from a fluent but inaccurate one.

A better prompt works like a checkable task brief. It tells the AI what job to do, supplies the information needed for that job, protects boundaries the answer must not cross, and makes the result easy for a person to inspect. You do not need every part for every request, and your first message does not have to be perfect.

What makes one prompt better than another?

For an everyday task, use three practical tests:

  • Useful: Can the result support the next action you have in mind?
  • Faithful: Does it preserve the important facts, distinctions, and uncertainties in your material?
  • Checkable: Can you tell what to compare the answer against before relying on it?

“Make it professional” might influence tone, but it does not answer any of those questions. “Separate confirmed decisions from open questions, and do not invent an owner” does.

This article uses a fictional meeting-note exercise to build one prompt in stages. The meeting, people, and project are not real.

1. Give AI one clear job

Start with the result you need, not with a role for the AI.

Vague:

Help me with these meeting notes.

Clearer:

Draft a follow-up email from the meeting notes below for the project team.

The second request identifies the action, the source material, the artifact, and its readers. A useful test is to imagine giving the instruction to a capable colleague who did not attend the meeting. Would they know what to deliver?

Before you write more, decide what “done” means. In this example, the email should let the team see what was decided, what someone has agreed to do, and what still needs an answer. If it blurs those categories, it has failed even if the prose is excellent.

This idea also appears in Anthropic’s guidance for prompt development: define success criteria and a way to test them before spending time optimizing wording. For an ordinary chat, you do not need an evaluation system. A short mental checklist is enough.

2. Add context that can change the result

An AI cannot infer your private meeting record from the sentence “write a follow-up email.” Include the source material and any background that changes how it should be used.

For this exercise, the necessary context is:

Meeting notes

- The team confirmed a September 18 pilot for the new help page.
- Mei will prepare the first draft by September 8.
- The group discussed adding a video, but made no decision.
- Someone needs to check captioning cost; no owner or deadline was assigned.
- The client still needs to confirm whether its support team can review the draft.

The recipient and purpose matter too: this is an internal follow-up that should make commitments visible. The history of every earlier project meeting probably does not.

Four visual building blocks—a target, source page, boundary marker, and result card—feed into one prompt bubble

A prompt can combine a task, necessary material, boundaries, and the result you need. Use only the parts that change the work.

Relevant context is not the same as maximum context. A study of long-context language models found that, in its tested retrieval and question-answering tasks, models did not use all positions in long inputs equally reliably. Models and their capabilities continue to change, so this is not a universal limit. It is still a good reason to organize the important material instead of burying it in unrelated text.

Ask of each detail:

If I remove this, could a correct answer change?

If yes, it may be necessary. If no, consider leaving it out. Before sending, also remove names, contact details, account information, internal records, or other sensitive material that the task does not require. Check the current data policy of the tool you are using when the material is confidential.

3. Protect facts, constraints, and unknowns

Context tells the AI what it can use. Boundaries tell it what it must not silently change.

In the meeting notes, these categories are different:

  • A fact is recorded information, such as the September 18 pilot date.
  • A constraint is a rule for the result, such as preserving confirmed dates.
  • An unknown is a gap that the AI cannot responsibly fill, such as the owner of the captioning-cost check.

Add those distinctions to the request:

Keep confirmed decisions, assigned actions, proposals, and open questions separate.
Do not invent an owner, deadline, decision, or client response.
If the notes do not contain a needed detail, mark it as "to be confirmed."

This instruction is more valuable than asking the AI to sound authoritative. Authority in the prose cannot turn a proposal into a decision or make a missing owner appear.

Positive instructions are often easier to apply than a long list of prohibitions. Instead of only saying “do not mix things up,” specify the categories the answer should use. Keep the negative boundary for the failures that would make the result unsafe or unusable.

4. Ask for an output you can inspect

Output requirements are not decoration. They should make the answer easier to use and easier to check.

For the email, add:

Use this structure:

1. A two-sentence meeting summary.
2. Confirmed decisions.
3. Assigned actions, including only owners and dates stated in the notes.
4. Open questions and unassigned actions.
5. A closing request asking recipients to correct anything inaccurate.

Keep the email under 250 words and use direct, neutral language.

The sections expose omissions. A separate “open questions” section makes it harder for an unresolved issue to disappear inside a smooth paragraph. The word limit prevents the draft from expanding into a meeting transcript.

Examples can help when a desired format, classification, or tone is difficult to describe. OpenAI, Google, and Anthropic all document examples as a way to steer outputs. But examples are optional evidence of what you mean, not a compulsory ingredient. A familiar task with a clear request may need none.

The complete prompt

The assembled request now reads:

Draft an internal follow-up email from the meeting notes below for the project team.
The email should make confirmed decisions, assigned actions, and unresolved questions easy to see.

Keep confirmed decisions, assigned actions, proposals, and open questions separate.
Do not invent an owner, deadline, decision, or client response.
If the notes do not contain a needed detail, mark it as "to be confirmed."

Use this structure:
1. A two-sentence meeting summary.
2. Confirmed decisions.
3. Assigned actions, including only owners and dates stated in the notes.
4. Open questions and unassigned actions.
5. A closing request asking recipients to correct anything inaccurate.

Keep the email under 250 words and use direct, neutral language.

Meeting notes
- The team confirmed a September 18 pilot for the new help page.
- Mei will prepare the first draft by September 8.
- The group discussed adding a video, but made no decision.
- Someone needs to check captioning cost; no owner or deadline was assigned.
- The client still needs to confirm whether its support team can review the draft.

This prompt is longer than the original because the task contains distinctions worth preserving. A request such as “Give me five names for this folder” would not need the same structure. Prompt length is a consequence of the task, not a quality score.

5. Check the answer against the source

Do not judge the draft only by whether it sounds natural. Compare it with the meeting notes and the success criteria you set at the beginning.

Check in this order:

  1. Coverage: Did the answer include every decision, assigned action, and open question that matters?
  2. Fidelity: Did it change a date, owner, commitment, or degree of certainty?
  3. Unsupported additions: Did it introduce a reason, name, deadline, fact, or citation that the source does not provide?
  4. Usefulness: Could the team act on the email without first untangling its structure?

For current facts such as prices, laws, schedules, product behavior, or technical compatibility, the relevant source may be an official page rather than text you pasted into the chat. Open that source and check it. Asking the AI “Are you sure?” is not independent verification.

NIST describes confidently presented false content as a known generative-AI risk and recommends reviewing sources and citations in generated outputs. The risk matters precisely because an inaccurate answer can still sound complete.

6. Revise the specific failure

If the first result is wrong, you usually do not need to discard the whole prompt. Name the failure, restore the boundary, and ask for the affected part to be revised.

For example:

The captioning-cost check has no assigned owner or deadline. Move it to “Open questions and unassigned actions,” remove the name you added, and keep the rest of the email unchanged. Then check that every date and owner still matches the notes.

That follow-up is useful because it identifies an observable problem. “Try again” gives the AI no comparable information.

A prompt result passes under a magnifying glass, reveals a missing piece, and returns through a revision arrow

Prompting is a loop: inspect the result against the task, describe the gap, and revise what failed.

You can use the same pattern when the problem is tone, length, format, or missing evidence:

  • “The summary is for specialists. Rewrite only the opening for a reader who does not know the project.”
  • “The comparison does not use the same criteria for both options. Rebuild the table using price, access, and cancellation terms for each.”
  • “Two claims have no source. Remove them or link the current primary source that supports each one.”

This is why a good prompt is better understood as a working process than a perfect sentence. Google describes prompt design as iterative, and current OpenAI guidance recommends testing prompt behavior as models and prompts change. For a beginner, iteration can be as simple as checking one output, naming one defect, and trying the corrected instruction.

A starter frame you can shorten

Use this when a task has enough risk or complexity to deserve a brief:

Task:
Use [material] to produce [specific result] for [reader or situation].

Necessary context:
[Only the information that can change a correct answer.]

Must preserve:
[Facts, distinctions, requirements, or boundaries.]

Do not assume:
[Unknowns the AI must leave open or mark for confirmation.]

Output:
[The sections, format, length, or checks that make the result usable.]

Delete any field that does not help the current task. Then, before relying on the result, ask: Is it useful, faithful, and checkable? The prompt helps describe the job. You still own the source check, the final judgment, and the real-world action.

References