“Prompt engineering” sounds more mystical than it is. In practice: the clearer you state the job, the less the model wanders. Not much mystique left after that.
What a prompt is doing
Instructions, questions, and context you send the model are all prompts. Images and PDFs get encoded into vectors in multimodal setups—roughly, they’re speaking too, just in another channel.
There are precise attention-level explanations online. The mental model I use day to day is simpler: treat semantics like points in a space; nearby points are easier to retrieve together; the model is doing probability prediction. A precise prompt makes it more likely to land where you want. That’s a working metaphor, not a paper claim.
So the job is usually: be more accurate, hallucinate less, keep the format stable, and occasionally watch cost and latency.
The word “engineering” matters to me because of repeatability—can I reuse the pattern, fix it when tests fail, and handle edge cases? Pretty prose that only works once isn’t engineering.
How I assemble prompts
I don’t fill every slot every time, but these are the parts I keep in mind:
- Task: required. What should it actually do?
- Steps / conditionals: add them as soon as the job gets branching; otherwise the model invents a process.
- Constraints and prohibitions: what to do and what never to do. Fine to merge when simple.
- Format / template: essential for structured output; put real filled examples inside the template.
- Examples: beat adjectives. One good sample outperforms “be professional and thorough.”
- Role / persona: optional. Useful for medicine or law; skip the “senior expert” costume for plain extraction.
Background too—include it when you have it, don’t invent filler. Cut distractors and repetition. When the payload gets dense, Markdown sections help the model as much as they help you.
Examples I’ve actually used
1. A narrow goal is enough
In a spreadsheet automation flow:
From OCR text, extract dollar amounts starting with
$and return the absolute value.
Input: USD: $280.37; CNY: ¥1953.73; → 280.37. No role, no essay. The task was already narrow.
2. Get the conditionals right
This is where drafts quietly lie to themselves. I’ve seen rules that said “if progress isn’t 100%, mark completed”—which contradicts the examples. The coherent version is:
- task count = 0 →
cancelled - count ≠ 0 and progress = 0% →
not started - count ≠ 0 and progress = 100% →
done - otherwise →
in progress - return exactly one label, no commentary
So 85% / 12 → in progress; 0% / 0 → cancelled; 0% / 5 → not started. A wrong rule beats any amount of model obedience.
3. Naming helper: rules + examples
Translate terms, propose camelCase / PascalCase / snake_case (both cases), suggest abbreviations, flag ambiguity. Pin the output shape with examples and demand “results only, no reasoning.” That pattern has been stable across several chat models I’ve tried.
4. Small local models need hard templates
On a local qwen2.5-7b I’ve done TCM vs Western diagnosis classification and history-field extraction. A light clinician role helps; forcing TSV and rejecting anything else helps more. With smaller models, templates and prohibitions usually outperform “please be professional.”
If you want something more systematic, push toward Skills—separate steps, constraints, templates, and examples. I keep a private note on that: How to write a Skill that outputs stably.
Closing
My order is fixed by now: task first, then conditionals and constraints, then examples or templates for the shape. Adjectives last, if at all.
There’s no silver bullet—just feel. Feel comes from repeatedly replacing “I assumed it would understand” with “I wrote it down so it could.”
