Der Fachjargon-Eliminator: Verwandeln Sie Dichte Technische Dokumentation in Etwas, Das Ein Nicht-Ingenieur Nutzen Kann
Warum dieser Prompt wichtig ist
Sales reps who can't accurately explain technical safeguards either underclaim value and lose the deal to a competitor with a slicker pitch, or overclaim capabilities the system doesn't actually have — creating a support and legal liability once the client discovers the gap after signing. Teams without a fast way to translate documentation end up pulling an engineer into every sales call, or losing deals to less-technical, better-explained competitors.
Wofür wir ihn verwenden
A backend engineer just shipped documentation for a new authentication API covering JWT rotation and idempotent retries. The sales team needs to explain these safeguards to a healthcare client asking pointed questions about session security and duplicate-charge protection during a live demo call in two hours — and they can't parse terms like “idempotent” or “token rotation” fast enough to answer confidently.
Prompt
Role: Act as a technical communication specialist who translates engineering documentation for non-technical stakeholders without losing accuracy or introducing false confidence. Context: - Source documentation: [PASTE TECHNICAL DOCUMENTATION HERE] - Original audience this was written for: [E.G., "backend engineers integrating with our API"] - Target audience who now needs to understand it: [E.G., "the sales team and a non-technical product manager"] - What the target audience needs to DO with this understanding: [E.G., "explain the feature's security guarantees to a healthcare client on a live call, without overpromising"] Task: 1. Identify every term, acronym, or concept in the documentation that would likely be unfamiliar to [TARGET AUDIENCE]. 2. For each one, write a one-line plain-English definition, using an analogy from the target audience's own domain where possible. 3. Rewrite the full documentation in plain English, preserving every accuracy-critical detail. Do not oversimplify to the point of being factually wrong. 4. Separately flag any place where a technical nuance is important enough that glossing over it could cause [TARGET AUDIENCE] to make a costly mistake (overpromise a capability, misstate a limit, or reassure a customer incorrectly). Constraints: - Do not delete information just because it's hard to explain — find a way to explain it instead. - Do not add marketing language, hype, or claims that are not present in the original documentation. - Keep the plain-English rewrite roughly the same length as the original, or shorter. - Preserve exact numbers, limits, versions, and thresholds precisely as given — do not round or approximate them. Output Format: 1. **Glossary** — term → one-line plain-English definition, one per line. 2. **Plain-English Rewrite** — the full rewritten documentation. 3. **Where to Be Careful** — a bullet list of the accuracy-critical nuances identified in Task step 4, phrased as "don't say X, say Y" where useful.
Ergebnis
Glossary
- JWT (JSON Web Token): A digital ID badge your app carries around to prove it's allowed to make requests, without logging in again every time.
- Token rotation: The system automatically swaps old ID badges for new ones on a schedule, so a stolen badge only works for a limited window.
- Idempotent retry: If a request accidentally gets sent twice (like during a network hiccup), the system recognizes the duplicate and processes it only once.
- Refresh token: A longer-lived backup badge used only to request a new short-lived ID badge, never to make actual requests directly.
Plain-English Rewrite
Our authentication system issues each connected app a temporary access badge (JWT) that expires every 15 minutes. Instead of forcing a full re-login every 15 minutes, apps use a separate, longer-lived refresh badge to quietly request a new access badge in the background — customers never notice the swap happening.
If a customer's action, like submitting a payment, gets sent to our servers twice because of a shaky internet connection, our system recognizes it's the same request and only processes it once. This means customers can safely retry an action that seems to have failed without worrying about being double-charged or creating a duplicate order.
Where to Be Careful
- Don't say retries are “instant” — there's a brief window, usually under two seconds, where a retry landing in that exact window could still create a duplicate. Say “extremely reliable,” not “guaranteed.”
- The 15-minute token expiry is fixed and cannot be extended per customer request. If a prospect asks for longer sessions, the answer is no — not “we can configure that.”
- Refresh tokens can be revoked instantly (for example, if a device is reported stolen), but the currently active access token will still work for up to 15 minutes after revocation. Don't promise instant logout across every device.
Technische Dokumentation und die Menschen, die danach handeln müssen, sind normalerweise zwei verschiedene Zielgruppen, und die meisten Übersetzungsversuche scheitern auf eine von zwei vorhersehbaren Arten: Entweder vereinfachen sie zu stark, bis die Erklärung technisch falsch ist, oder sie bewahren jede Nuance und enden genauso dicht wie das Original. Dieser Prompt wurde entwickelt, um beide Fehlermodi zu vermeiden.
Warum die Struktur wichtig ist
Der Glossar-Abschnitt existiert, weil unbekannte Begriffe das Erste sind, was einen Leser aufgeben lässt. Die Umschreibung in einfacher Sprache ist bewusst auf ungefähr die ursprüngliche Länge begrenzt: unbeschränkte KI-Modelle neigen dazu, Erklärungen mit beruhigendem Füllmaterial aufzublähen.
Der dritte Abschnitt, Wo Vorsicht Geboten Ist, ist derjenige, den die meisten Jargon-Vereinfachungsversuche komplett überspringen, und er ist wohl der wichtigste. Eine technische Erklärung zu vereinfachen bedeutet fast immer, eine Nuance zu verlieren.
Warum die Kontextfelder in Klammern wichtig sind
Der Prompt fragt nach der Zielgruppe und was sie mit den Informationen TUN muss, nicht nur, wer sie ist.
Wo dieser Prompt seinen Wert beweist
Dies ist am nützlichsten für API-Dokumentation, Sicherheits- und Compliance-Berichte, Infrastruktur-Runbooks und jede interne technische Spezifikation, nach der ein nicht-technisches Team handeln muss, ohne auf eine Live-Erklärung eines Ingenieurs zu warten.