Claude-systeemprompts: hoe u toongrenzen instelt voor technische documentatie

Technische documentatie faalt vaak op subtiele manieren voordat deze feitelijk faalt. Een concept kan accuraat zijn, maar te informeel, te promotioneel, te uitgebreid, te vaag over onzekerheid, of inconsistent met de rest van een documentatieset. Als u Claude gebruikt om API-gidsen, artikelen voor probleemoplossing, releasenotes, interne runbooks of ontwikkelaarsdocumentatie te produceren, is de systeemprompt een van de beste plekken om die permanente schrijfgrenzen te definiëren.

Er is ook een actuele wijziging in het modelgedrag die het vermelden waard is. Sinds september 2026 staat in de depreciatiedocumentatie van Anthropic dat temperature, top_p en top_k verouderd zijn voor Claude Opus 4.7 en nieuwer en Claude Mythos Preview, waarbij prompten wordt aanbevolen voor gedragscontrole. Dit maakt expliciete systeemstijlinstructies belangrijker dan oudere recepten die probeerden de toon voornamelijk te vormen via bemonsteringsparameters. Zie de richtlijnen voor model- en API-depreciatie van Anthropic.

Wat moet een “toongrens” daadwerkelijk regelen?

Een toongrens moet het communicatiegedrag definiëren dat stabiel blijft over vele documentatieverzoeken heen. Het is niet alleen “klink professioneel”. Een nuttige grens dekt meestal vijf dingen: doelgroep, stem, detailniveau, aanvaardbare taal voor onzekerheid en opmaakgewoonten.

Een documentatieassistent voor ontwikkelaars kan bijvoorbeeld worden verteld om in een professionele en neutrale toon te schrijven, onbekende termen bij het eerste gebruik uit te leggen, directe zinnen boven marketingtaal te prefereren, bevestigde feiten te onderscheiden van aannames, en koppen en codeblokken alleen te gebruiken wanneer ze de navigatie verbeteren.

De huidige prompt-richtlijnen van Anthropic raden expliciet duidelijke en directe instructies aan, context over waarom een gedrag belangrijk is, voorbeelden voor toon en structuur, en XML-tags wanneer een prompt verschillende soorten informatie mengt. Ook staat erin dat het geven van een rol aan Claude in de systeemprompt helpt om het gedrag en de toon te focussen. Zie de beste praktijken voor prompten van Anthropic.

Moeten toonregels in de systeemprompt of de gebruikersprompt staan?

Plaats duurzame regels in de systeemprompt en taakspecifieke instructies in de gebruikersprompt. De systeemprompt is de juiste plek voor regels zoals “schrijf voor softwareontwikkelaars”, “vermijd marketingclaims”, “geef onzekerheid aan in plaats van te gokken” en “gebruik beknopte technische proza”. Het gebruikersbericht moet de huidige taak beschrijven: bijvoorbeeld “Schrijf een migratiegids van versie 4 naar versie 5 met behulp van deze releasenotes”.

Deze scheiding vermindert herhaling en maakt uw documentatiepijplijn eenvoudiger te testen. Het voorkomt ook dat een enkel taakverzoek uw hele redactionele stem herdefinieert.

Een eenvoudig patroon voor de systeemprompt

<role>
U bent een schrijver van technische documentatie.
</role>

<audience>
Schrijf voor softwareontwikkelaars en systeembeheerders.
Ga uit van algemene technische geletterdheid, maar leg productspecifieke termen uit bij het eerste gebruik.
</audience>

<tone>
Gebruik een professionele, neutrale, directe toon.
Prefereer concrete taal boven hype of promotionele claims.
Vermijd jargon, vulwoorden, emoji’s en overdreven zekerheid.
Houd zinnen redelijk kort en paragrafen gefocust.
</tone>

<accuracy>
Verzin geen commando’s, functies, versies, benchmarks of gedrag.
Onderscheid geverifieerde feiten van aannames of aanbevelingen.
Als vereiste informatie ontbreekt, geef dan aan wat onbekend is.
</accuracy>

<format>
Gebruik beschrijvende koppen.
Gebruik lijsten alleen voor echt discrete stappen of controles.
Gebruik codeblokken voor commando’s en code.
Voeg geen conclusie toe die het artikel alleen herhaalt.
</format>

Dit werkt omdat elke sectie één taak heeft. Anthropic raadt specifiek consistente, beschrijvende XML-tags aan voor complexe prompts, zodat het model instructies, context, voorbeelden en invoer betrouwbaarder kan onderscheiden.

Hoe specifiek moeten de toonregels zijn?

Specifiek genoeg zodat een andere schrijver ze kan volgen zonder te vragen wat u bedoelde. “Wees professioneel” is zwak omdat professionele API-documentatie, architectuurnotities voor het management en installatie-instructies voor eindgebruikers allemaal anders kunnen klinken.

Een sterkere regel beschrijft waarneembaar gedrag:

Positieve instructies zijn meestal eenvoudiger te operationaliseren dan regels die alleen verboden bevatten. In plaats van alleen te zeggen “klink niet promotioneel”, voeg het gewenste alternatief toe: “Beschrijf voordelen in concrete termen gekoppeld aan gebruikersresultaten”.

Hoe voorkomt u dat toonregels de technische nauwkeurigheid schaden?

Laat stijl niet het bewijs overschrijven. Een veelgemaakte fout is vragen om “zelfverzekerde, gezaghebbende schrijfstijl” zonder ook te definiëren wat het model moet doen als bronmateriaal onvolledig is. Dat kan gepolijste onzekerheid in plaats van nuttige documentatie aanmoedigen.

Voeg een nauwkeurigheids grens toe zoals:

Wanneer documentatiebronnen een feit niet vaststellen:
- Leid geen productmogelijkheid af uit naamgeving of UI-weergave.
- Stel dat het gedrag niet geverifieerd kon worden.
- Vraag om de ontbrekende bron wanneer het feit vereist is om de taak te voltooien.
- Maak van aannames geen definitieve instructies.

Voor technische documentatie is deze regel vaak waardevoller dan een generieke instructie om “hallucinaties te vermijden”, omdat deze het verwachte gedrag definieert wanneer bewijs ontbreekt.

Moet u uitgebreidheid specificeren in de systeemprompt?

Ja, als documentlengte en dichtheid ertoe doen. De huidige prompt-richtlijnen van Anthropic merken op dat recente Claude-modellen verschillen in standaard communicatiestijl en uitgebreidheid. De documentatie adviseert specifiek om expliciet om beknoptheid te vragen wanneer nodig, in plaats van aan te nemen dat inspanning of andere modelinstellingen de zichtbare antwoordlengte consistent zullen regelen.

Een praktische documentatiegrens kan dichtheid definiëren in plaats van een vast woordaantal:

Begin met de informatie die nodig is om te handelen.
Gebruik genoeg uitleg om de instructie veilig en ondubbelzinnig te maken.
Herhaal dezelfde aanbeveling niet in de inleiding, de tekst en de conclusie.
Prefereer korte secties voor eenvoudige oplossingen.
Leg bij architectuur- of migratieonderwerpen afwegingen en vereisten dieper uit.

Dit schaalt beter dan een blanket-instructie zoals “schrijf altijd 1.000 woorden”.

Hoeveel voorbeelden moet u opnemen?

Gebruik voorbeelden wanneer prozaregels nog ruimte laten voor interpretatie. Anthropic noemt voorbeelden een van de meest betrouwbare manieren om formaat, toon en structuur te sturen, en de huidige richtlijnen raden aan om ongeveer drie tot vijf relevante, diverse voorbeelden te gebruiken wanneer u vertrouwt op few-shot prompten.

Voor documentatie moeten voorbeelden verschillende gevallen dekken in plaats van één stemmonster te herhalen. Een nuttige set kan een kort antwoord voor probleemoplossing, een API-referentiedeel, een waarschuwing voor gegevensverlies, een versie-afhankelijke notitie en een voorbeeld bevatten waarin het model moet zeggen dat iets niet geverifieerd is.

Maak de voorbeelden niet zo lang dat ze de prompt worden. Hun doel is om het patroon te tonen, niet om een verborgen sjabloon te bieden die elk artikel mechanisch kopieert.

Welke toongrenzen zijn nuttig voor veelvoorkomende documentatietypes?

Wat moet niet worden gecodeerd als “toon”?

Begraven geen bedrijfslogica, beveiligingsbeleid of feitelijke beperkingen in een vage stijlsectie. “Onthul nooit inloggegevens”, “gebruik alleen informatie uit goedgekeurde bronnen” en “voer geen commando’s uit” zijn gedrags- of beveiligingsregels, geen toonvoorkeuren. Geef ze aparte secties zodat ze zichtbaar en testbaar blijven.

Hetzelfde geldt voor uitvoerschema’s. Als een toepassing geldige JSON, exacte sleutels of machineleesbare velden nodig heeft, specificeer dat dan als een uitvoercontract in plaats van het te beschrijven als een stijlvoorkeur.

Hoe moet u een systeemprompt voor documentatie testen?

Beoordeel het niet op basis van één succesvol voorbeeld. Bouw een kleine evaluatieset die normale taken en randgevallen bevat. Een nuttige testset kan het volgende bevatten:

• Een eenvoudig “hoe installeer ik dit?”-verzoek.
• Een migratiegids met breaking changes.
• Een brondocument met veel marketingtaal dat niet mag lekken in de uiteindelijke toon.
• Een prompt met onvolledige versie-informatie.
• Een technische vraag waarvan het antwoord niet vaststaat door de aangeleverde bron.
• Een verzoek om een lange uitleg waarbij beknoptheid behouden moet blijven.
• Een gebruikersinstructie die om een stijl vraagt die conflicteert met het documentatiebeleid van uw organisatie.

Beoordeel de uitvoeren tegen expliciete criteria: juiste doelgroep, neutrale toon, geen ongegronde claims, passende details, consistente terminologie, duidelijke onzekerheid en bruikbare structuur. De prompt-richtlijnen van Anthropic raden ook aan om duidelijke succescriteria te definiëren en resultaten te verifiëren in plaats van alleen op intuïtie te vertrouwen.

Hoe voorkomt u dat de systeemprompt opgeblazen wordt?

Houd regels op het niveau van stabiel redactioneel beleid. Als één zin meerdere gevallen afdekt, vervang die dan niet door twaalf smalle verboden. De huidige Anthropic-richtlijnen voor recente modellen waarschuwen ook tegen over-prompten: sterkere instructieopvolging kan agressieve legacy-woordkeuze zoals herhaalde “CRITICAL” of “MUST”-regels overmatig laten triggeren op gedrag dat nieuwere modellen al zouden volgen met normale formuleringen.

Een goede onderhoudsregel is om een systeemprompt-instructie pas toe te voegen nadat u de terugkerende fout kunt benoemen die deze voorkomt. Als een regel alleen voor één artikel bestaat, plaats die dan in de gebruikersprompt voor dat artikel.

Herbruikbare systeemprompt voor technische documentatie

<role>
U bent een senior schrijver van technische documentatie.
</role>

<audience>
Schrijf voor de doelgroep die in het gebruikersverzoek is gespecificeerd.
Als er geen doelgroep is opgegeven, ga dan uit van technisch geletterde beoefenaars.
Leg ongebruikelijke productspecifieke terminologie uit bij het eerste gebruik.
</audience>

<tone>
Gebruik duidelijk, professioneel, neutraal Amerikaans-Engels.
Begin met de informatie die nodig is om te handelen.
Vermijd hype, informele vulwoorden, grappen, emoji’s, overdreven zekerheid
en zinnen die klinken als marketingtekst.
Gebruik directe uitspraken wanneer feiten geverifieerd zijn.
</tone>

<accuracy>
Verzin nooit productgedrag, commando’s, UI-labels, versies,
benchmarks, beperkingen of testresultaten.
Scheid geverifieerde feiten, conditioneel gedrag, aanbevelingen
en onbekende zaken.
Als het bewijs onvoldoende is, zeg dat dan expliciet.
</accuracy>

<structure>
Gebruik beschrijvende koppen die helpen bij de navigatie.
Prefereer korte, gefocuste paragrafen.
Gebruik genummerde stappen alleen voor geordende procedures.
Gebruik bullets voor echt discrete controles of opties.
Gebruik codeblokken voor commando’s en code.
Vermijd repetitieve samenvattingen.
</structure>

<examples>
Geef 3–5 taakrelevante voorbeelden in de productieprompt
wanneer toon of formaat nog ambigu is.
</examples>

<quality_check>
Verifieer voordat u definitief maakt dat de respons overeenkomt met de
gevraagde doelgroep, consistente terminologie gebruikt, ongegronde claims
vermijdt en het gevraagde uitvoerformaat volgt.
</quality_check>

Het doel is niet om elk document identiek te laten klinken. Het doel is om de grenzen stabiel te maken: nauwkeurigheid wordt geen enthousiasme, onzekerheid wordt geen gokwerk, technische diepte wordt niet onnodig jargon, en beknoptheid verwijdert geen vereisten of veiligheidsinformatie.

Een goed ontworpen Claude-systeemprompt werkt het beste als een redactioneel beleidslaag. Houd de permanente stem- en kwaliteitsgrenzen daar, houd artikel-specifieke vereisten in de gebruikersprompt, en gebruik een kleine evaluatieset om te verifiëren dat beide lagen documentatie blijven produceren waar uw lezers op kunnen vertrouwen.