Snack 16 – Constraints, Roles & Rubric-based Prompting

Wenn du in einer Exam‑Frage (oder in der Praxis) „zuverlässigen Output“ brauchst, ist der größte Hebel nicht mehr „netter Text“, sondern Steuerung über Rollen, harte Constraints und eine Bewertungsrubrik. Das Ziel: Der Output wird prüfbar (du kannst objektiv sagen: erfüllt/nicht erfüllt) und dadurch reparierbar.

1) Roles: Verantwortung und Perspektive festnageln

„Role prompting“ heißt nicht „tu so als wärst du …“ aus Spaß, sondern: Welche Verantwortung hat das Modell in diesem Schritt? Beispiel:

• *„Du bist Sicherheitsreviewer“* → Fokus auf Risiken, Angriffsflächen, least privilege.
• *„Du bist Build-Engineer“* → Fokus auf Reproduzierbarkeit, Commands, deterministische Schritte.

In agentischen Workflows ist das besonders wichtig, weil du oft mehrere Schritte hast (Plan → Ausführung → Validierung). Jede Rolle kann andere Prioritäten haben. Exam‑typisch ist die Frage: Welche Rolle/Schicht sollte welche Entscheidung treffen? (z.B. Tool‑Layer darf nicht über Policies „diskutieren“, sondern muss sie enforce’n.)

2) Constraints: harte Leitplanken statt Wunschzettel

Constraints sind nicht „bitte mach es kurz“, sondern messbare Regeln:

• Format: „Antworte als JSON gemäß Schema X“
• Grenzen: „Max. 6 Bulletpoints“ / „Keine externen Links“
• Verhalten: „Wenn Information fehlt: stelle genau 2 Rückfragen“
• Sicherheit: „Keine Secrets ausgeben; wenn entdeckt → redaction + Hinweis“

Wichtig: Constraints sollten priorisiert sein. Wenn alles „must“ ist, ist nichts „must“. Gute Prompts unterscheiden:

• **Hard constraints (MUST):** Format/Policy/Verbote
• **Soft goals (SHOULD):** Stil, Ton, Kürze

Praktischer Trick: Pack die MUSTs kompakt an eine Stelle („Constraints“) und wiederhole sie nicht 5× im Prompt.

3) Rubric-based Prompting: Qualität objektivierbar machen

Eine Rubrik ist eine kleine Checkliste mit Kriterien, nach denen Output bewertet wird. Damit erzwingst du zwei Dinge:

1) Das Modell „denkt“ in Kriterien statt in freien Text.

2) Du kannst einen Validation‑Step bauen: „Bewerte deine Antwort anhand der Rubrik, nenne Verstöße, repariere.“

Beispiel‑Rubrik (für eine Architektur-Skizze):

• Abdeckung der Anforderungen (A)
• Security/least privilege (B)
• Failure handling (C)
• Observability (D)
• Kosten/Latenz (E)

Exam-Mehrwert: In Szenariofragen ist oft nicht nur die Lösung wichtig, sondern die Begründung entlang klarer Kriterien (Trade-offs!). Rubrics helfen dir, deine Antwort strukturiert zu argumentieren.

Typische Anti-Patterns

• „Role“ ohne Aufgabe: *„Du bist ein Experte“* (bringt wenig)
• Zu viele Constraints ohne Priorität → Modell bricht irgendwo
• Rubrik ohne Reparaturschritt → du misst zwar, verbesserst aber nicht
• Rubrik, die nicht zum Ziel passt (z.B. „kreativ“ bei Compliance‑Text)

3 Takeaways

1. Roles definieren Verantwortung pro Schritt (Plan/Ausführung/Review) und reduzieren Zielkonflikte.

2. Constraints müssen messbar und priorisiert sein: MUST (Format/Policy) vor SHOULD (Stil).

3. Rubrics machen Qualität prüfbar und ermöglichen Validierung + Auto‑Repair statt „hope and pray“.

Mini-Testfrage

Du sollst von Claude eine kurze Security-Einschätzung zu einem geplanten Tool schreiben lassen, die später automatisch geprüft wird. Welche Prompt-Bausteine würdest du verwenden (Role, Constraints, Rubrik) und warum?

Lösung

Setze die Rolle auf „Security-Reviewer“ (klare Perspektive), definiere harte Constraints (z.B. JSON-Format, keine Secrets, max. N Findings, bei fehlenden Infos genau 2 Rückfragen) und füge eine Rubrik hinzu (z.B. least privilege, injection defense, data handling, logging/audit). Damit wird die Antwort maschinenprüfbar und du kannst einen zweiten Schritt „Rubrik-Check + Reparatur“ zuverlässig automatisieren.