Advanced Prompt Engineering: Structured Prompt Design

Many people tune prompts by "changing a few words, running it, and submitting it if it feels better." This is like "debugging by feel": it is not reproducible, collaborative, or regression-testable. The mark of mature prompt engineering is treating a prompt as a specification to be written and maintained, not as an incantation to be recited.

1. The Six Elements of a Structured Prompt

A robust system prompt usually contains six sections, and their order matters:

1. Role        Who you are (defines capability boundaries and tone)
2. Task        What to accomplish (objective + success criteria)
3. Context     Relevant background (domain knowledge and input data sources)
4. Constraints Requirements and prohibitions (must do, must not do, boundaries)
5. Format      Output format (structure, fields, length)
6. Examples    Examples (input→output pairs, the most powerful alignment tool)

Not every prompt needs all six sections, but wherever a section is missing, the model is free to improvise. The most common failures are omitting Format, causing the model to alternate between Markdown and plain text, and omitting Constraints, causing it to "helpfully" do things you never requested.

An anti-pattern → improved version:

❌ Summarize this article for me.

✅ 【Role】You are an expert in technical summaries.【Task】Condense the input technical article into three key points.【Constraints】Each point must be ≤40 characters, retain key figures, and contain no fabrication.【Format】A JSON array with a point field.【Context】The readers are backend engineers.

The latter virtually eliminates uncertainty.

2. Several Advanced Techniques

1. Chain-of-Thought (CoT). Have the model "think before answering." A sentence such as "reason step by step before giving the conclusion" or "think step by step" can immediately improve multistep reasoning tasks. Claude models can use <thinking>...</thinking> to separate reasoning from the final answer and prevent the reasoning from corrupting the output format.

2. Few-shot examples. One to three high-quality "input→output" pairs align the model far more effectively than lengthy instructions. Example quality > example quantity: three good examples outperform twenty mediocre ones. Make sure the examples cover boundaries such as empty input, invalid values, and format variations; otherwise, the model learns only how to handle the "standard case."

3. XML-delimited sections. Anthropic's models align well with XML-delimited sections. Wrapping different information in <context>, <rules>, and <document> helps the model determine more reliably "what to find where" and makes sections easier to locate in a long prompt:

<context>Background goes here</context>
<rules>Constraints go here</rules>
<document>Content to process goes here</document>
Process <document> according to <rules>.

4. Self-consistency. For reasoning tasks with well-defined answers, running the prompt multiple times and taking a majority vote can reduce the randomness of a single reasoning attempt. The cost is tokens ×N, so this is suitable for offline or high-value tasks.

5. Have the model restate the task first. Before a complex task, ask the model to "first restate your understanding of the requirements and your plan in one sentence." This exposes many misunderstandings before generation begins, which is far cheaper than discovering afterward that the answer went off topic.

3. Defensive Prompting

Models are "helpful," and that helpfulness is both an advantage and a risk. Several defensive principles matter:

• Explicitly state what not to do. "Do not fabricate sources," "do not invoke tools that are not listed," and "ask if information is insufficient; do not guess" are negative constraints that close gaps more effectively than positive instructions alone.
• Enforce formats with hard constraints. When requesting JSON, provide the complete schema and emphasize "output JSON only, with no explanatory text." Combine this with application-side JSON parsing + retries on failure.
• List boundary conditions separately. Define one handling rule each for empty input, excessively long input, a non-target language, and harmful requests. Otherwise, the model will rely on its "default behavior," which is often not what you need.
• Guard against unauthorized actions. If the model can invoke tools, state in the prompt that "dangerous operations require confirmation first," and enforce another layer in code. A prompt is not a security boundary; code is.

4. A Reproducible Debugging Method

The key to turning prompt optimization from "mysticism" into "engineering" is a reproducible loop:

1. Build an evaluation set. Create 20–50 input → expected output/expected properties cases. Without one, every change is based on intuition.
2. Change one variable at a time. Modify only one thing per iteration, such as adding an example or revising a constraint, then run the full evaluation set and compare the results.
3. Look at bad cases, not the average score. An average score of 90 with one catastrophic output is often worse than a stable average of 85.
4. Version prompts. Commit prompt changes to git and include a commit message explaining "why it changed and the evaluation results before and after." You will thank yourself three months later.

A lightweight approach is to extract the prompt into a standalone file or constant, write an eval.ts that runs and scores the evaluation set, and optionally add it as a CI check.

5. Prompt Layering and Reuse

In production applications, prompts usually have two layers:

• System prompt: Stable over the long term and defines the role, rules, and format. It remains almost unchanged across turns, making it suitable for prompt caching to save tokens.
• User/template prompt: Contains the input data that changes each turn. Assemble it with a template engine, keeping variables separate from instructions.

In templates, put instructions first and data second ("Process this text according to the following rules: [rules]. Text: [data]."). This is more reliable than "data + rules" because the model reads the rules first and already has a framework when it processes the data.

Summary

The essence of prompt engineering is translating "ambiguous requirements" into "a specification the model can execute precisely." The six elements provide structure, CoT/few-shot/XML provide alignment, defensive prompting provides safety, and evaluation sets support iteration. Together, they turn prompts from "inspiration-driven work" into "engineering work."

One final point: A good prompt is not a long prompt, but one that eliminates uncertainty as thoroughly as possible. Length is never the goal; reproducibility, maintainability, and regression testability are.