Betere prompts schrijven: eerst de meetlat, dan techniek

Betere prompts schrijven begint niet bij de prompt. Leg eerst vast wanneer een antwoord goed is, bouw dan een reeks testgevallen die dat nakijkt, en sleutel daarna aan de formulering. Die cyclus staat volgens de documentatie van Anthropic centraal in prompt engineering [S-084]. Zonder meetlat is een nieuwe prompt alleen anders.

Dit is voor een marketing manager of teamlead die AI dagelijks laat meeschrijven en merkt dat de kwaliteit per keer verschilt. Geen acroniem, geen rij voorbeeldprompts: de technieken zoals de leverancier van het model ze documenteert, plus de lus eromheen.

Hoe weet je of een prompt beter is geworden?

Alleen als je dat vóór het sleutelen hebt vastgelegd. De documentatie zet het in deze volgorde: eerst heldere succescriteria, dan evaluaties die daaraan meten, en die cyclus is de kern van prompt engineering [S-084]. De formulering komt als laatste.

Dat is omgekeerd aan de gangbare uitleg, die begint bij de opbouw van een prompt en eindigt bij “en dan heb je een beter resultaat”, zonder manier om dat vast te stellen.

Scherper nog: de prompt-engineering-gids van Anthropic gaat ervan uit dat drie dingen er al zijn vóór je begint. Een heldere definitie van de succescriteria, een manier om er empirisch tegen te testen, en een eerste versie van de prompt die je wilt verbeteren. Ontbreken die, dan is het advies daar eerst tijd in te stoppen [S-085].

Voor een marketingteam betekent dat iets onaangenaams. De uren die nu in het herschrijven van prompts gaan, horen eerst naar twee andere dingen: opschrijven wanneer een uitvoer bruikbaar is, en echte gevallen klaarzetten. Succescriteria en evaluatie zijn geen eindcontrole, ze zijn het startpunt.

Wat is een succescriterium dat je kunt nakijken?

Een criterium dat specifiek, meetbaar, haalbaar en relevant is. De documentatie noemt als voorbeeld dat je niet “goede prestatie” opschrijft maar “nauwkeurige sentimentclassificatie”, en dat zelfs veiligheid te kwantificeren is: niet “veilige uitvoer”, maar “minder dan 0,1 procent van de uitvoer in 10.000 pogingen wordt door het contentfilter op toxiciteit gemarkeerd” [S-087].

Dat getal hoort bij de taak uit de documentatie. De vorm is wat je overneemt, omgezet naar werk dat een marketingteam dagelijks door een model haalt:

• Niet “de e-mail moet goed klinken”, maar: de e-mail noemt elk veld uit het CRM dat erin hoort en bevat geen bewering die niet in het dossier staat.
• Niet “een goede samenvatting”, maar: de samenvatting past zonder inkorten in het veld van de nieuwsbrief en noemt de beslissing uit de notulen bij naam.
• Niet “een betere productbeschrijving”, maar: de beschrijving gebruikt alleen specificaties uit de feed.

Zo’n criterium kun je nakijken zonder discussie, en dat is het hele punt: wat je niet kunt nakijken, kun je niet verbeteren.

Hoe zet je een testreeks op die iets zegt?

Met drie ontwerpregels, waarvan de laatste tegen je gevoel ingaat. De documentatie geeft ze zo [S-088]:

1. Taakspecifiek. Laat de reeks de echte verdeling van gevallen weerspiegelen, randgevallen inbegrepen. Dus niet drie nette briefings, maar ook die ene met een half aangeleverde productnaam.
2. Automatisch beoordelen waar het kan. Een beoordeling die een mens met de hand doet, draait in de praktijk één keer.
3. Volume boven kwaliteit. Meer vragen met automatische beoordeling en iets minder signaal is beter dan minder vragen die met de hand zijn nagekeken.

Die derde regel is de reden dat testreeksen stranden: teams bouwen tien zorgvuldig nagekeken gevallen en stoppen, terwijl honderd ruwere gevallen meer vertellen.

Voor het beoordelen noemt de documentatie drie manieren, in volgorde van voorkeur [S-089]:

Manier	Wat hij oplevert	Waar hij tekortschiet
Met code	snelst en betrouwbaarst, extreem opschaalbaar	mist nuance
Door een mens	flexibelst, hoogste kwaliteit	langzaam en duur; “vermijd het als het kan”
Door een taalmodel	snel, flexibel, geschikt voor complexe afweging	eerst op betrouwbaarheid testen

Laat je een model nakijken, dan hangt de uitslag aan de beoordelingsopdracht. De documentatie vraagt een gedetailleerd beoordelingsschema, een empirische of specifieke uitvoer (alleen “correct” of “incorrect”, of een cijfer van 1 tot 5, want kwalitatieve beoordelingen zijn niet op schaal te wegen) en een beoordelaarsmodel dat stap voor stap laat denken [S-090].

Welke prompttechnieken maken echt verschil?

Een handvol, met gewone namen. Dit is de volgorde die de documentatie zelf aanhoudt, van de goedkoopste ingreep naar de meest structurele:

1. Duidelijk en direct zijn [S-091]. De gouden regel: laat je prompt lezen door een collega met minimale context op de taak en laat die hem uitvoeren. Raakt die collega in de war, dan Claude ook. Wees specifiek over uitvoerformaat en beperkingen, geef genummerde stappen waar de volgorde telt, en vraag gedrag boven het minimum expliciet. Praktisch: “schrijf een nieuwsbrieftekst” wordt “schrijf de inleiding, zo lang als in de template past, met de aankondiging in de eerste zin”.
2. De reden achter een instructie meegeven [S-092]. Uitleg waarom gedrag belangrijk is helpt het model je doel begrijpen, en het generaliseert vanuit die uitleg. Het voorbeeld in de documentatie: “gebruik NOOIT puntjes” tegenover “je antwoord wordt voorgelezen door een spraaksynthese, die puntjes niet kan uitspreken”.
3. Voorbeelden meegeven (few-shot) [S-093]. Voorbeelden zijn een van de betrouwbaarste manieren om vorm, toon en structuur van de uitvoer te sturen. Ze horen relevant te zijn (dicht bij het echte geval), divers (randgevallen gedekt, genoeg variatie zodat het model geen onbedoeld patroon oppikt) en gestructureerd: elk voorbeeld in <example>-tags, meerdere in <examples>. Drie tot vijf voorbeelden is volgens de documentatie het beste aantal. Praktisch: drie goedgekeurde mails zeggen meer dan drie alinea’s uitleg over jullie toon.
4. Structuur met XML-tags [S-094]. Tags helpen Claude een complexe prompt ondubbelzinnig te lezen, vooral als instructies, context, voorbeelden en wisselende invoer in één prompt staan. Zet elk type inhoud in zijn eigen tag, gebruik consistente en beschrijvende tagnamen, en nest waar de inhoud een natuurlijke hiërarchie heeft. Praktisch: de briefing in <context>, de merkregels in <instructions>, de ruwe tekst in <input>.
5. Een rol in de systeemprompt [S-095]. Een rol richt het gedrag en de toon op jouw gebruiksgeval, en volgens de documentatie maakt zelfs één zin verschil. Praktisch: één regel in de systeemprompt die zegt voor wie het team schrijft.

Dezelfde levende referentie behandelt ook stap voor stap laten denken (chain-of-thought, het model zijn afweging laten uitschrijven) en prompt chaining, waarbij je een taak over meerdere prompts opsplitst [S-096]. Wat die technieken opleveren in één concrete toepassing staat in Claude AI voor copywriting.

Wat hier niet staat, is een acroniem. Elke uitleg op internet verzint er een eigen, en die verschillen per pagina. De documentatie gebruikt gewone namen, en die zijn makkelijker over te dragen dan een letterwoord dat niemand buiten jullie kent.

Wanneer is het geen promptprobleem?

Vaker dan je denkt. De documentatie is daar expliciet over: niet elk succescriterium en niet elke falende evaluatie is het beste met prompt engineering op te lossen, en latency en kosten zijn soms eenvoudiger te verbeteren door een ander model te kiezen [S-086].

WeAdapt ziet daarnaast drie varianten die op een promptprobleem lijken:

• De gegevens staan er niet in. Het model kan niets zeggen over een klant waarvan het dossier niet in de prompt zit. Geen formulering repareert een ontbrekend veld.
• De taak vraagt een koppeling, geen formulering. Moet het antwoord uit een live systeem komen, dan ben je aan het bouwen en niet aan het schrijven. Welke keuzes daar liggen staat in AI koppelen aan eigen systemen.
• Niemand heeft het proces vastgelegd. Beoordelen twee collega’s een goede uitvoer anders, dan is er geen prompt die het goed doet. Dan is de stap een procesanalyse, geen betere instructie.

De test is simpel. Zou een nieuwe medewerker met dezelfde informatie en dezelfde instructie het goed doen? Nee? Dan zit het probleem niet in de prompt.

Werkt een techniek op elk model?

Niet automatisch, en dat is de reden dat een lijstje van internet weinig waard is. Anthropic publiceert per model een eigen prompt-pagina en schrijft dat een techniek die een specifiek model noemt, gelezen moet worden als op dát model gemeten, en opnieuw tegen je eigen evaluaties gecontroleerd voor je hem elders toepast [S-096].

Dat geldt ook voor de techniekpagina’s zelf: de losse pagina’s over voorbeelden, XML-tags en systeemprompts zijn samengebracht in één levende referentie [S-096]. Een werkwijze uit een oud blogartikel verwijst dus al snel naar een pagina die niet meer bestaat. Je eigen testreeks is het enige wat daartegen beschermt, want die is op jouw model, jouw taak en jouw criteria gemeten.

Waarom hier geen cijfers over promptwinst staan

Omdat ze geen bron hebben. Over promptwinst circuleren getallen die van pagina naar pagina worden overgenomen zonder meting eronder; geen van de twintig zoekresultaten die WeAdapt voor dit artikel naliep verwijst naar een primaire bron. Dit artikel neemt ze daarom niet over.

Dat is ook het bewijs voor de kern van dit stuk: winst op een prompt is per taak, per model en per criterium anders, dus een algemeen percentage kan niet bestaan. Wat wel bestaat is jouw cijfer, uit jouw eigen reeks. Een team dat die reeks één keer samen opzet, breidt hem daarna zelf uit; dat is wat een training of workshop oplevert.

Veelgestelde vragen

Hoe schrijf je een goede prompt? In deze volgorde: schrijf op wanneer de uitvoer goed is, zet echte gevallen klaar om dat te testen, en pas dan de formulering. Loop daarna de technieken af van duidelijk en direct, via de reden achter een instructie en voorbeelden, naar XML-structuur en een rol in de systeemprompt [S-084, S-091].

Hoeveel voorbeelden moet je meegeven? De documentatie noemt drie tot vijf voorbeelden als beste aantal. Belangrijker dan het aantal is dat ze relevant zijn (dicht bij het echte geval) en divers, met randgevallen erbij en genoeg variatie zodat het model geen onbedoeld patroon oppikt. Zet elk voorbeeld in <example>-tags [S-093].

Heb je XML-tags nodig in een gewone chat? Alleen als je prompt instructies, context, voorbeelden en wisselende invoer door elkaar heeft staan. Dan verkleinen tags de kans dat het model de onderdelen verwart [S-094]. Bij een korte vraag levert het niets op; begin daar bij duidelijk en direct zijn.

Waar begin je als je nog geen criteria en geen testreeks hebt? Daar, niet bij de prompt. De gids van Anthropic gaat ervan uit dat de criteria, een manier om er empirisch tegen te testen en een eerste prompt er al zijn, en adviseert anders daar eerst tijd in te stoppen [S-085]. Begin bij één taak die je team vaak doet.

Moet iedereen in het team dit kunnen? Nee. Eén iemand die de succescriteria en de testreeks beheert is genoeg; de rest gebruikt de prompts die daaruit komen. Hoe je een team zover krijgt dat het die prompts ook gebruikt, staat in medewerkers meekrijgen met AI.

Wil je weten welke van jullie taken een betere prompt nodig heeft en welke een koppeling? Dat onderscheid legt WeAdapt als eerste op tafel: plan een gesprek, of lees eerst de veelgestelde vragen.