Ein Flugzeughandbuch von 1986 hat meinen Anti-Slop-Skill repariert

Mein Anti-Slop-Skill hatte längst Regeln, bevor das hier anfing. Ein Register, das zu halten war, eine Tabelle verräterischer Muster mit je einer Korrektur, und fünf Regeln zu Interpunktion, Struktur, Vokabular, Haltung und Formatierung. Entwürfe kamen damit besser zurück als ohne. Das war nicht nichts.

Es war allerdings komplett meins. Ich hatte es aus einem Jahr Verärgerung über Entwürfe geschrieben, eine Formulierung nach der anderen, und gegen nichts getestet.

Die Lücke habe ich lange nicht gesehen, weil sie strukturell ist und nicht eine fehlende Regel. Fast alles darin beschrieb etwas zum Entfernen. Streiche den Gedankenstrich. Weg mit der Absicherung. Lösche den Räusper-Einstieg.

Selbst die Vokabelregel, die einer echten Anweisung am nächsten kam, war eine Liste von Wörtern, die man meiden soll. Dazu kam eine angetackerte Warnung: weiche einem verbotenen Wort nicht in etwas noch Verrenkteres aus.

So sieht das Problem aus, an einem echten README-Einstieg, den ein Modell für eine fiktive Caching-Bibliothek geschrieben hat:

Traditional caches miss constantly in LLM workloads because users rarely phrase the same question identically — fluxcache solves this by embedding incoming prompts and matching them against previously cached queries within a configurable similarity threshold. It ships with sensible defaults so you can get semantic caching running in a few lines of code, while exposing the knobs — similarity thresholds, TTLs, namespacing, custom scoring — that real applications need as they scale. Whether you're building a chatbot, a RAG pipeline, or an agentic workflow, fluxcache is designed to slot into your existing stack with minimal friction and no vendor lock-in.

Wörtlich zitiert, Gedankenstriche inklusive, weshalb dieser Absatz die einzige Stelle auf dieser Seite ist, an der du einen findest.

Meine alten Regeln greifen hier durchaus. Die Gedankenstriche sind die erste Zeile meiner Tabelle, und "whether you're building a chatbot" ist die Zeile zur falschen Inklusivität. Der Skill arbeitete also.

Jetzt streich beides weg. Korrigier die Striche, benenne das echte Publikum, und lies erneut. Ein Eröffnungssatz mit 34 Wörtern. "Sensible defaults." "Minimal friction and no vendor lock-in." "Designed to slot into your existing stack."

Jeder Teilsatz behauptet weiter einen Nutzen, den niemand gemessen hat, und keine meiner Regeln fasste irgendetwas davon an. Ich hatte die Formulierungen katalogisiert, die mich störten, und nie gefragt, wie man einen Satz baut.

Das ist der Unterschied zwischen einer Reparaturliste und einem System. Eine Reparaturliste findet nur, woran du vorher schon gedacht hast.

Jemand hat das tatsächlich gemessen.¹ Ein Test über mehrere Modelle hinweg ließ sechs realistische Schreibaufgaben unter vier Bedingungen laufen. Die Aufgaben waren ein README, eine PR-Beschreibung, API-Dokumentation, eine Fehlermeldung, ein Getting-Started-Guide und ein Deprecation-Hinweis. Die Bedingungen waren eine schlichte Baseline, eine Verbotsliste, Orwells sechs Regeln und ein Skill auf Basis einer kontrollierten Sprache. Ein heuristischer Linter zählte dann Verstöße pro 100 Wörter.

Bei Claude senkte die Verbotsliste den Slop um 3 Prozent. Die kontrollierte Sprache senkte ihn um 74 Prozent.

Die ehrliche Fußnote zählt genauso viel wie die Schlagzeile. Bei GPT senkte dieselbe Verbotsliste 40 Prozent, "Wörter verbieten bringt nichts" ist also ein Ergebnis für ein Modell und kein Gesetz. Die Stichprobe sind sechs Aufgaben und zwei Modelle, bewertet von einer Heuristik. Sie zeigt eine Richtung, sie beweist keine.

Die Richtung war klar genug. Jede Bedingung, die dem Modell ein System gab, schlug die, die ihm nur eine Liste zu meidender Wörter gab. Meine eigenen Regeln waren nicht diese Liste, aber sie waren auch nie im Test. Niemand hatte sie je bewertet, ich eingeschlossen.

Das System heißt ASD-STE100, Simplified Technical English. Die europäische Luftfahrtindustrie begann Ende der 1970er damit und veröffentlichte 1986 den ersten Leitfaden, für Wartungshandbücher, die von Mechanikern gelesen wurden, deren Muttersprache oft nicht Englisch war. Einen Satz an einer Hydraulikleitung falsch zu verstehen ist kein Stilproblem, also ist der Standard ungewöhnlich streng darin, was ein Satz überhaupt tun darf.

Er ist kein Museumsstück. Eine Pflegegruppe in Brüssel betreut ihn bis heute, Issue 9 erschien im Januar 2025, und im selben Jahr erreichte er den Rang eines internationalen Standards.²

Der Standard hat zwei Teile: einen Satz Schreibregeln, 53 in der aktuellen Ausgabe, und ein Wörterbuch mit rund 900 zugelassenen Wörtern.³

Das Wörterbuch ist der Teil, der die meisten überrascht. Jedes zugelassene Wort trägt genau eine Bedeutung und eine Wortart, und die Alternativen sind nicht bloß unerwünscht, sie sind nicht verfügbar:

Bleib kurz bei der Zeile "check". Als Substantiv erlaubt, als Verb verboten, denn "check the valve" kann prüfen, testen oder abstellen heißen. Ein Mechaniker unter Zeitdruck sollte nie raten müssen. Das ist die ganze Philosophie in einem Eintrag, und es ist das Gegenteil dessen, worauf ein Sprachmodell trainiert ist, nämlich auf Abwechslung.

Die Satzregeln funktionieren genauso. Die Bedingung steht vor der Anweisung, damit niemand die erste Hälfte eines Satzes ausführt, bevor er die zweite erreicht:⁴

If hot oil touches your skin, injuries can occur.

Der Rest der Mechanik ist genauso unverblümt. Aktiv mit benanntem Akteur, also "der Parser liest die Datei" statt "die Datei wird gelesen". Ein Verb für eine Handlung, also "analysiere das Log" statt "führe eine Analyse des Logs durch". Kein Perfekt, also "wir erhielten die Berichte" statt "wir haben die Berichte erhalten". Beschreibende Sätze sind bei 25 Wörtern gedeckelt, prozedurale bei 20. Ein Thema pro Absatz, höchstens sechs Sätze.

Nichts davon erwähnt KI. Der Standard ist älter als das Web, und er diente Menschen, deren Job es war, nichts falsch zu verstehen. Genau deshalb lässt er sich übertragen.

Dasselbe Modell, derselbe Prompt, dieselbe fiktive Bibliothek, diesmal mit diesen Regeln davor:

A normal cache matches requests by exact text. A small change in wording then causes a cache miss. fluxcache compares the meaning of a new prompt with the prompts already in the cache. If two prompts are close enough in meaning, fluxcache returns the stored response instead of a new call to the model. This lowers the number of calls to the model and cuts the cost and response time of the application.

Das ist die Version, die ich ausliefern würde. Kürzer, sie erklärt den Mechanismus statt einen Nutzen zu behaupten, und sie greift nie nach "seamless". Die Regeln haben ihr keines dieser Wörter verboten. Sie haben ihr gesagt, wie lang ein Satz sein darf und dass jeder Satz einen handelnden Akteur braucht. Danach hatte die Werbestimme keinen Platz mehr.

Nachdem ein geliehener Standard funktionierte, suchte ich einen weiteren und landete beim Microsoft Writing Style Guide.⁵ Er betreibt eine der größten Doku-Landschaften der Softwarebranche, und er ist öffentlich.

Wo der Luftfahrtstandard ein Regelwerk ist, lehrt Microsoft am Beispiel, und die Beispiele sind der nützliche Teil. Diese sind ihre, nicht meine:⁶

Die dritte Zeile hat verändert, wie ich redigiere. Ihre Anweisung lautet "beginne die Aussage meistens mit einem Verb" und "streiche you can, wenn es nicht nötig ist". Sieh dir an, was das bewirkt: Der Vorher-Satz hat ein Subjekt, das nichts tut ("you can access"), der Nachher-Satz hat drei arbeitende Verben. Dieselbe Regel erledigt den Füllauftakt, aus "es gibt drei Wege, das zu konfigurieren" wird "drei Optionen existieren, Standard ist B".

"Es gibt" und "du kannst" schieben das echte Subjekt ans Satzende und verbrennen den Verbplatz für nichts. Sie zu streichen zwingt dich, den Akteur zu benennen, und das legt meistens die Unschärfe offen, die du versteckt hast.

Die zweite Zeile ist eine stille Lektion über Fehlermeldungen. "Invalid ID" ist technisch korrekt und nutzlos. Die Neufassung zeigt, wie eine gültige aussieht, und mehr wolltest du nie wissen.

Microsoft sagt außerdem "wenn du dasselbe meinst, benutze dasselbe Wort". Das ist die Ein-Name-Regel aus der Luftfahrt, erreicht über ein völlig anderes Argument. Dieselbe Regel zweimal aus zwei Richtungen zu finden ist ein gutes Zeichen dafür, dass du eine echte gefunden hast.

Dann traf ich auf den Teil, den ich nicht eingeplant hatte.

Microsofts Tipp Nummer neun heißt "Don't be spacey" und behandelt die Abstände bei Gedankenstrichen. Ihre empfohlene Fassung lautet:

Use pipelines—logical groups of activities—to consolidate activities that are part of a task.

Das ist der lauteste Marker für generierten Text, den es gibt, veröffentlicht als Hausstil. Tipp Nummer drei heißt "Project friendliness" und verlangt Kurzformen wie it's, you'll und we're. Die Seite zur Markenstimme fordert "warm and relaxed", "less head, more heart", und sagt "occasionally, we're fun".⁷

Mein Skill tötet alle drei sofort.

Mein erster Impuls war, die Teile zu nehmen, denen ich zustimmte, und den Rest still fallen zu lassen. So endet man mit einem Regelwerk, das niemand anwenden kann. Die Begründung fehlt, also kann die nächste Person eine echte Ausnahme nicht von einem Versehen unterscheiden.

Also wurden die Konflikte als Konflikte aufgeschrieben, mit einem Urteil zu jedem und dem Grund dahinter. Microsoft schreibt Consumer-Produkt-UI für ein globales Publikum, wo ein Dialogfeld beruhigend klingen muss. Ich schreibe für Leser, die die Tatsache wollen und Dekoration störend finden. Keiner von uns liegt falsch. Wir haben verschiedene Leser.

Das Urteil lautet, dass mein Register standardmäßig gewinnt, und dass ein dritter Modus für die Fälle existiert, in denen es das nicht sollte. Geht der Text an eine Oberfläche, die Microsoft-Stil bereits folgt, gewinnt das Haus und alle drei Umkehrungen greifen. Kurzformen kommen zurück, Gedankenstriche sind in Ordnung, die Stimme wird wärmer. Jede andere Regel bleibt in Kraft, denn ein Marketing-Adjektiv ist in jedem Haus Slop.

Dieser Modus existiert nur, weil ich die Meinungsverschiedenheit aufgeschrieben habe, statt sie zu glätten.

Derselbe Guide enthält einen großen Abschnitt zu Barrierefreiheit und inklusiver Sprache, und beim Lesen zeigte sich eine Lücke, für die ich keine Regel hatte.

Nimm "der Button oben". Das ist kein Slop. Es ist schlicht, kurz und direkt, und es besteht jede Regel, die ich hatte. Es ist auch nutzlos für jemanden, dessen Screenreader die Seite linear durchläuft, und es bricht erneut, wenn das Layout auf dem Handy umfließt.

Die zweite Zeile begegnet einem überall. Assistive Software kann die Links einer Seite ohne Kontext auflisten, und eine Seite voller "hier klicken" wird zu einer Liste identischer Einträge, die niemand auseinanderhalten kann. Die letzte Zeile scheitert für alle, die die Farbe nicht unterscheiden können, weshalb die Korrektur den Button benennt statt ihn zu beschreiben.

Ihre Begründung zu Richtungswörtern lohnt das Zitat, weil sie konkreter ist als "sei barrierefrei". Links, rechts, oben, unten "aren't very useful for people who use screen-reading software", also lautet die Anweisung, "das erste Element der folgenden Liste" oder "in der Toolbar" zu schreiben.⁸ Derselbe Abschnitt rät von Verben wie click und swipe ab, weil sie eine Maus oder einen Touchscreen voraussetzen und jede andere Eingabeart ausschließen. Er bittet sogar darum, and, plus und about auszuschreiben statt &, + und ~ zu benutzen, weil Screenreader sie falsch vorlesen oder überspringen.

Der Abschnitt zu vorurteilsfreier Sprache ist ebenso konkret. Eine Ersetzungstabelle, kein Vortrag:⁹

Und zum generischen "er" ihr eigenes Vorher-Nachher: Aus "If the user has the appropriate rights, he can set other users' passwords" wird "If you have the appropriate rights, you can set other users' passwords". Die zweite Person löst es ohne jede Verrenkung, und genau das ist der Punkt. Umschreiben ist leichter als die "er/sie"-Konstruktionen, zu denen die meisten greifen.

Der Abschnitt geht weiter als meine Tabelle. Nenne den Menschen vor der Behinderung, und streiche Wörter, die Mitleid transportieren, wie "stricken with" oder "suffering from". Erwähne eine Behinderung gar nicht erst, wenn sie nicht relevant ist.

Nichts davon liest sich generiert. Alles davon ist ein Defekt, und ein Agent, der Dokumentation in Menge produziert, baut ihn schneller ein als ein Mensch. Das Material hat nichts mit KI-Slop zu tun und gehörte trotzdem in den Skill.

Regeln, die ein Agent ignorieren kann, sind Vorschläge. Also schrieb ich einen kleinen Linter für die mechanische Teilmenge, und er gibt Verstöße pro 100 Wörter aus.

Hier ist er auf dem Baseline-README aus jenem Experiment, das ein Modell ganz ohne Schreibanweisung produziert hat:

$ node slop-lint.mjs baseline.md

baseline.md  words=97  violations=8  score=8.20/100w  longest=35w  (flavored)
  em_dash                      3  L1 "—", L1 "—", L1 "—"
                                  -> period, comma, colon, or parentheses
  long_sentence(>25w)          3  L1 "34 words", L1 "35 words", L1 "28 words"
                                  -> split it, one idea per sentence
  false_inclusivity            1  L1 "Whether you're"
                                  -> say who it is actually for
  passive_voice                1  L1 "is designed"
                                  -> name the actor and make it active

Jeder Treffer trägt Zeilennummer, Fundstelle und Korrektur. Derselbe Prompt, dasselbe Modell, mit angewandtem Schreibsystem:

$ node slop-lint.mjs ste.md

ste.md  words=73  violations=0  score=0.00/100w  longest=25w  (flavored)

Null Verstöße und 25 Prozent weniger Wörter, bei gleicher Aussage.

Nur die Differenz bedeutet etwas. Linten, überarbeiten, erneut linten, und der Abfall sagt dir etwas. Die absolute Zahl tut das nicht, und mein eigenes Repo beweist es:

$ node slop-lint.mjs references/*.md

inclusive-and-accessible.md  words=417   violations=0   score=0.00/100w
microsoft-style.md           words=458   violations=0   score=0.00/100w
ste.md                       words=1441  violations=20  score=1.40/100w
prose.md                     words=1194  violations=74  score=6.20/100w

Die letzte Datei ist das schlechteste Dokument, das ich habe, und sie ist korrekt. prose.md ist der Katalog schlechten Schreibens, eine Seite voller Vorher-Nachher-Paare. Jedes "Vorher" ist Slop mit Absicht. Ein Linter kann Zitat nicht von Geständnis unterscheiden.

Dieselbe Einschränkung gilt am kurzen Ende. Unter etwa fünfzig Wörtern liest sich ein Treffer als zehn pro hundert, ein zweisätziger Deprecation-Hinweis sieht also aus wie eine Katastrophe.

Ihn auf meine eigenen Dateien loszulassen war trotzdem lehrreich. Er fand ein Semikolon in einem Dokument, zwei Abschnitte unter der Regel, die Semikolons verbietet. Beim Schreiben der Barrierefreiheits-Regeln benutzte ich die Formulierung "die drei Konflikte oben", im selben Commit, der die Regel gegen Richtungsangaben ergänzte. Beides war meins, beides Minuten alt, und Lesen hätte keines davon gefunden.

Der Skill ist besser, aber die nützlichere Lehre betrifft die Herkunft der Regeln.

Ich erfand Regeln aus meiner eigenen Verärgerung, eine Formulierung nach der anderen. Über die geliehenen Standards haben Menschen mit echtem Einsatz jahrzehntelang gestritten: ein Mechaniker, der eine Prozedur nicht falsch verstehen darf, ein Doku-Team, das hundert Sprachräume bedient. Sie kommen erprobt an, sie erklären sich selbst, und sie decken Fälle ab, auf die ich allein nie gekommen wäre. Die Regeln zur Barrierefreiheit sind das klarste Beispiel. Verärgerung über das Wort "delve" bringt sie nie hervor.

Der Widerspruch zwischen ihnen war am Ende genauso viel wert wie die Übereinstimmung. Zwei glaubwürdige Systeme, die beim Gedankenstrich uneins sind, zwangen mich laut zu sagen, für wen ich schreibe. Das hatte ich vorher nie wirklich aufgeschrieben.

All das repariert die Form von Slop, nie die Substanz. Ein Text kann null erreichen und trotzdem nichts sagen. Die Regeln machen einen hohlen Absatz kürzer, schlichter und lesbarer, und er bleibt hohl, denn kein Linter weiß, ob eine Behauptung stimmt oder es wert ist, gemacht zu werden.

Dieser Teil bleibt mein Job. Er ist nur leichter zu sehen, jetzt wo das Rauschen drumherum weg ist.

• ASD-STE100 Simplified Technical English

  Die kontrollierte Sprache selbst, seit Januar 2025 in Issue 9. Nach einem kurzen Anfrageformular frei herunterladbar.

• ASD-STE100 FAQ

  Die klarste kurze Erklärung der zwei Teile, des rund 900 Wörter großen Wörterbuchs und warum ein Wort genau eine Bedeutung bekommt.

• TechScribe über Simplified Technical English

  Durchgearbeitete Vorher-Nachher-Beispiele von einem technischen Redakteur, der den Standard beruflich einsetzt.

• Microsoft Writing Style Guide

  Öffentlich, gründlich und meinungsstark. Die Abschnitte zu Barrierefreiheit und vorurteilsfreier Sprache sind die Teile, die die meisten Style Guides auslassen.

• Top 10 tips for Microsoft style and voice

  Die verdichtete Fassung und die Quelle der hier zitierten Vorher-Nachher-Paare. Auch die Heimat der Gedankenstrich-Empfehlung.

• Writing for all abilities

  Warum Richtungswörter und Hier-klicken-Links mit Screenreadern brechen, samt den konkreten Ersatzformulierungen.

• The cure for AI slop is a 1986 aircraft manual

  Das modellübergreifende Experiment hinter den 3 und 74 Prozent, mit den Rohausgaben und dem Bewertungsskript.

• saschb2b/skills

  Das offene Skills-Repo. no-slop liegt unter productivity, mit seinen Referenzen und dem Linter.