Prompt Engineering

A prompt is not just the user question. A well-shaped prompt has five named parts, and thinking in those parts makes the difference between a flaky demo and a production feature:

1. System — persona, role, hard constraints, refusal policy, output schema. Sets the rules.
2. Context — retrieved documents, prior turns, tool results, user data. Grounds the response.
3. Task — the actual ask, phrased precisely with success criteria.
4. Format — JSON shape, length, language, bullet vs prose, citation style.
5. Examples — few-shot demonstrations of the desired behavior, especially for edge cases.

Key techniques:

• Be explicit about format. "Return a JSON object with keys {summary, references}" beats "summarize this".
• Show, don't tell. A two-line example of the desired output is more reliable than a paragraph of instructions.
• Order matters. Place the most important instructions at the start or end of the prompt; the middle is weaker (lost in the middle).
• Structured reasoning. For difficult multi-step work, provide clear success criteria and either use the model's reasoning controls or split the task into verifiable stages. A long reasoning trace is not proof of correctness.
• Verification. Ask the model to check the result against explicit criteria, and use external tools or tests when an answer can be measured.

Limits: a prompt can supply new facts for the current context, but it does not persistently update model weights. Retrieval can supply external evidence; fine-tuning changes parameters. Evaluate the simplest approach that meets the task.