Practical examples

Three short drills: rewrite the contract, feed a parser, write an agent constitution. Paste them into any chat box. With an API, split system / user as commented.


Example 1: one vague prompt, three valid rewrites

Do not use this as-is:

Take a look at this function.

Assume the function is parse_order on the checkout path. Three readers, three contracts—do not merge them into “detailed but only one sentence.”

Rewrite A — code review (for the author)

Role: backend reviewer. Reader: the author.
Task: review parse_order only. List correctness / failure handling / complexity issues.
Constraints: no code edits; mark unevidenced items “guess”; at most 6 items.
Output: Markdown table with columns severity (high/medium/low), location, issue, suggestion.

Rewrite B — teach a new teammate

Role: mentor. Reader: new to the team, knows Python, not the business.
Task: in one short section, explain parse_order inputs, outputs, and who owns failures.
Constraints: no language-syntax 101; no service names that are not in the docs.
Output: three paragraphs: what it does, how it fails, which file to read next (give a path).

Rewrite C — risk list only (for a ticket system)

Task: extract actionable risks in parse_order.
Constraints: each item must work as a ticket title; no style nits.
Output: a JSON array of {"title": str, "severity": "high"|"medium"|"low"}. No text outside JSON.

Treat A/B/C as three prompt versions in your gold set. Same function, different contracts, non-interchangeable outputs—that is the behavior evals should lock.


Example 2: extract JSON from an email

system:

You extract support tickets. Do not invent order IDs or owners.
priority is low, medium, or high (high only if the text says “today” or production is down).

user:

Extract a Ticket from <email>. Schema:
title, priority, order_id (string|null), owner (string|null)

<email>
Hi, checkout spins forever on order 8891. Prod reports this morning too. Please have Platform look. — Lina
</email>

Expected (sample):

{
  "title": "Checkout spinner on order 8891",
  "priority": "high",
  "order_id": "8891",
  "owner": "Platform"
}

On the API, use the Pydantic class in Structured output, not a regex salvage. Add a gold question where the email has no order id and order_id must be null.


Example 3: repo-level agent instructions

Put this at repo root as AGENTS.md (or a Cursor rule, Claude Code CLAUDE.md, LangChain system_prompt). Users state the task only; they do not repeat policy.

# Agent instructions (this repo)

You are a coding assistant for this tutorial site. Read before you edit.

## Scope
- Docs live in `docs/zh/` and `docs/en/`. If you change Chinese, update English unless the user asks for one locale.
- Do not touch `node_modules/`, build artifacts, or secret files.

## Tools
- Use the browser only when you must verify a page; do not replace in-repo copy with training memory.
- Shell is PowerShell 7; do not assume bash.
- Do not `git push` or change git config unless the user says so.

## Quality
- Match nearby Markdown headings and tables.
- Treat official docs as source for APIs; do not invent CLI flags that are not there.

## When you finish
Bullets: paths changed, how to preview locally, what you did not do.

This is Tools and agents made concrete. In Cursor, Claude Code, and LangChain, only the container changes—not the four blocks.


Exercises

  1. Take a recent failed chat, split it into A/B contracts like example 1, same input.
  2. Add three gold questions to example 2 (missing fields, injection noise, mixed language).
  3. Write an AGENTS.md ≤ 40 lines for your current repo; delete every adjective you cannot test.

Next steps

评论