Agree the shape of the answer
Specify the format, structure, length, language and tone of the result, and use a schema when a program will read it.
本课程暂无您所用语言的版本，当前以其他语言（English）显示。
Why it matters
The output contract is the part of the prompt that decides whether you can use the answer. A brilliant analysis in the wrong shape still has to be rewritten; a list of fields in a slightly different format breaks the program that reads it. If you know where the result is going (an email, a slide, a spreadsheet, a database), say what that destination needs.
A full contract covers format (table, list, prose, JSON), structure (sections, columns, order), length, language and tone. The detail people most often forget is the edge case: what should appear when a value is missing, a criterion cannot be judged or an input is empty? Google's guide recommends naming the format explicitly, and Anthropic's suggests describing the form you want positively rather than listing what to avoid.
When a program will read the output, go one step further. Both Anthropic and OpenAI offer structured outputs: you pass a JSON schema with the request and the response is constrained to follow it. OpenAI's documentation notes that JSON mode ensures only valid JSON, while structured outputs also ensure the schema is respected. Write the schema in the prompt as well, so the model understands what each field means.
What good looks like
- 0 — Nothing on form. “Compare the two proposals.”
- 1 — One loose hint. “Compare the two proposals in a table.”
- 2 — Format and rough length. “…a table of at most ten rows, then a one-paragraph recommendation.” Structure, language and tone are still open.
- 3 — Format, structure, length, language and tone. “…columns: criterion, proposal A, proposal B, winner. Write in Portuguese, neutral tone, no preamble.”
- 4 — A complete contract, edge cases included. A schema or template, plus how awkward cases appear: “if a criterion cannot be judged, set winner to ‘tie’ and explain in the recommendation.”
For image prompts, the contract covers composition, style and aspect ratio.
Common mistakes
- Asking for “a table” or “JSON” without saying which columns or fields.
- Leaving the language unstated when the input and the reader use different languages.
- Contradictory length signals, such as “brief” alongside a long list of required sections.
- No rule for missing or ambiguous values, so the model invents them or skips the row.
- Relying on prompt wording alone for machine-read JSON when the API offers structured outputs.
Try it on your own prompt
Paste a prompt into the workspace and picture the answer arriving. Where will you put it, and what would you have to fix before using it? Write those fixes into the prompt as the output contract, including one line for the awkward case. Then compare the output score, and use test drive if you want to see the two answers side by side.
讲解示例
Comparing job offers
Compare these two job offers.
<offer_a>
{{paste the first offer here}}
</offer_a>
<offer_b>
{{paste the second offer here}}
</offer_b>
Compare the two offers above for me.
Output:
- A table with four columns: criterion, offer A, offer B, better for me.
- One row each for salary, pension, commute, holiday, flexibility and progression, in that order.
- Below the table, one paragraph of no more than 80 words with your recommendation.
- British English, plain and neutral; start directly with the table.
- If an offer does not mention a criterion, write "not stated" in that cell and count it for neither offer.
The strong version fixes the template, the row order, the length, the language and tone, and how a missing value appears, so the answer can be read at a glance.
Extracting booking requests
Get the info out of these emails.
<emails>
{{paste the batch of emails here}}
</emails>
For each email above, extract the venue booking request it contains. A program will read your answer, so return only a JSON array, one object per email, with these fields:
- "email_id": the number shown in the email's subject line
- "event_type": one of "wedding", "conference", "party", "other"
- "date": the requested date as YYYY-MM-DD, or null if none is given
- "guests": a whole number, or null if not stated
- "needs_follow_up": true if the date or the number of guests is missing or ambiguous, otherwise false
If an email contains no booking request, still include it, with "event_type": "other" and every other field null except "email_id" and "needs_follow_up".
“The info” could mean anything. The strong version gives field names, types, allowed values and the empty case. Through an API, pass the same schema to the structured-output feature so conformance is enforced, not just requested.
练习
Rewrite this prompt so the model knows the format, length, structure and tone of the newsletter.
Rewrite this prompt with an exact output schema, including what to do when a price is missing.
Rewrite this prompt so the image is specified: composition, style, aspect ratio and what should stay out of the frame.