Humanizer: KI-Schreibmuster entfernen mit einer Markdown-Fähigkeit
Agentenfähigkeit, die Anzeichen von KI-generiertem Schreiben aus Text entfernt. Es handelt sich um reines Markdown, sodass es in jedem Kabelbaum ausgeführt werden kann, der Anweisungen im Skill-Stil unterstützt.
Auf einen Blick
- Was ist das?
- Wie die Agent-Fähigkeit Humanizer Text nach 35 Mustern aus Wikipedias Signs of AI writing umschreibt: zwei Durchläufe, Sprachkalibrierung per Stilprobe, die Regel gegen Erfindungen und die Grenzen des Musteransatzes.
- Für wen ist es gedacht?
- Humanizer passt für Autoren und Teams, die maschinell erzeugte Entwürfe überarbeiten wollen, bevor sie veröffentlicht werden, und dafür eine Agent-Umgebung mit Fähigkeitsunterstützung nutzen. Es passt nicht als Prüfwerkzeug dafür, ob ein Text inhaltlich stimmt, denn die Fähigkeit korrigiert Stil, keine Fakten.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 9 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Humanizer als Markdown-Fähigkeit: Muster entfernen, Inhalt halten
Humanizer beschreibt sich im README als Agent-Fähigkeit, die KI-typische Anzeichen aus Texten entfernt, damit sie wie von einer Person geschrieben wirken, ohne den Inhalt zu verändern. Das Besondere an der Umsetzung: Die Fähigkeit besteht aus einfachem Markdown und läuft deshalb in jeder Agent-Umgebung, die fähigkeitsartige Anweisungen unterstützt, es gibt keine eigene Laufzeit oder Binärdatei.
Die Grundlage ist Wikipedia-Leitfaden Signs of AI writing, gepflegt vom WikiProject AI Cleanup, aus dem Humanizer 35 Muster übernimmt. Das Repository ist unter MIT lizenziert, zählt 38556 Sterne und 3373 Forks, der Standardbranch ist main. Ein Zitat im README erklärt die Motivation des Ansatzes: Sprachmodelle schätzen das statistisch wahrscheinlichste Fortsetzen, das Ergebnis driftet zum generisch Passenden für den breitesten Fall. Genau diese Drift soll die Fähigkeit rückgängig machen.
Die 35 Muster aus Wikipedias Signs of AI writing: fünf Gruppen
Die Musterliste ist im README in Tabellen mit Vorher-Nachher-Beispielen organisiert und gliedert sich in fünf Gruppen: Inhaltsmuster, Sprach- und Grammatikmuster, Stilmuster, Chatbot-Muster sowie Füllwörter und Absicherungen. Bei den Inhaltsmustern stehen übertriebene Wichtigkeit, Namensfallsammlung zur Bloßstellung von Bedeutung, werbesprachliche Formulierungen und vage Quellenangaben wie Experts believe oben auf der Liste.
Die Sprachmuster betreffen überstrapazierte Wörter, erzwungene Dreiergruppen, Vermeidung einfacher Aussageformen und ausgedachte Spannweiten von X bis Y. Die Stilgruppe listet Gedankenstriche, zu viel Fettung, Titelgroßschreibung, Emojis und geschweifte Anführungszeichen. Die Chatbot-Gruppe zielt auf Reste wie I hope this helps und übertriebene Zustimmung, die Füllgruppe auf Phrasen wie In order to und auf generisch positive Schlusssätze wie The future looks bright. Jedes Muster kommt mit einer konkreten Ersatzformulierung, so dass die Liste auch ohne Agent als Stilprüfung handhabbar bleibt.
Zwei Durchläufe: erste Umschreibung, dann Prüfung gegen die Musterliste
Der Ablauf laut README besteht aus mehreren Schritten. Der erste Durchlauf schreibt den Text um, ohne die ursprüngliche Struktur als fest zu behandeln. Danach prüft die Fähigkeit den Entwurf gegen die 35 Muster und gegen die ursprünglichen Aussagen, und überarbeitet, was noch Bedarf hat.
Ein Detail unterscheidet Humanizer von einem einfachen Umschreibbefehl: Beim Einfügen von Text zeigt die Fähigkeit ihre Arbeit, bevor die Endfassung kommt. Man sieht die erste Umschreibung und eine kurze Kritik an Stellen, die noch künstlich klingen. Diese Transparenz macht die Änderungen nachvollziehbar, man kann einzelne Vorschläge ablehnen, statt eine schwarze Box zu akzeptieren. Die Kritikpassage ist zugleich Lernhilfe, weil sie zeigt, welche Muster im eigenen Text wiederkehren, und damit über mehrere Durchläufe hinweg die Grundlage dafür bildet, sie von Anfang an zu vermeiden.
/humanizer, Dateimodus und Sprachkalibrierung mit einer Stilprobe
Der Aufruf ist bewusst simpel: Der Befehl /humanizer, gefolgt vom eingefügten Text, oder eine normale Aufforderung wie Please humanize this text. Für Dateien reicht eine Pfadangabe, das README nennt als Beispiel Humanize the prose in docs/launch-post.md. Im Dateimodus ändert die Fähigkeit nur die Prosa, Code, Daten, Frontmatter und Linkziele bleiben unangetastet.
Für persönliche Texte gibt es eine Kalibrierung: Wer zwei bis drei Absätze eines eigenen Schreibstubs mitliefert, bekommt eine Fassung, die dessen Rhythmus, Wortwahl, Zeichensetzung und bewusste Eigenheiten folgt, statt der Standardregeln. Technische und Nachschlagetexte bleiben laut README neutral und schlicht. Die Trennung ist sinnvoll, weil ein Blogbeitrag und eine API-Doku unterschiedliche Klangziele haben, dieselbe Musterliste wird also je nach Textart unterschiedlich angewendet.
Die Regel gegen Erfindungen: Namen, Zahlen und Zitate aus der Quelle
Eine harte Grenze formt jede Umschreibung: Humanizer erfindet nichts. Ein Name, eine Zahl, ein Datum, ein Zitat, ein Beleg oder ein anderes Faktendetail muss aus der Quelle oder vom Schreiber stammen. Fehlen solche Details, zum Beispiel der Monat oder das Viertel in einem Reisebericht, wie das vollständige Beispiel im README zeigt, muss die Fähigkeit nachfragen, statt etwas zu ergänzen.
Diese Regel adressiert ein reales Risiko von Umschreib-Agenten: Eine Umformulierung, die plötzlich konkreter klingt als die Vorlage, verleitet zum Auffüllen mit plausiblen, aber unbelegten Details. Humanizer dreht das Verhältnis um, Spezifität ist eine Aufgabe des Autors, die Fähigkeit liefert nur die Form. Der Preis ist sichtbar: Ein KI-Text, der von vornherein ohne Fakten geschrieben wurde, wird durch die Umschreibung nicht besser belegt, er klingt höchstens weniger generisch.
Releases von v2.9.1 bis v2.11.1 und die Grenzen des Musteransatzes
Die Release-Historie zeigt ein aktives Projekt: v2.9.1 erschien am 22. Juli 2026, v2.11.0 und v2.11.1 am 17. und 18. August 2026, nur wenige Tage vor dem Abruf der Daten. Mit 20 offenen Issues bei 38556 Sternen ist das Verhältnis von Aufmerksamkeit zu offenen Problemen ungewöhnlich, das spricht für die Einfachheit des Ansatzes, es gibt technisch wenig, das kaputtgehen kann.
Die Grenzen liegen in der Methode selbst. Eine Musterliste erkennt nur, was auf der Liste steht, ein KI-Text, der keines der 35 Muster zeigt, bleibt unerkannt, und ein menschlicher Text mit untypischen Formulierungen kann fälschlich geglättet werden. Zudem prüft die Fähigkeit keine Fakten, sie behält die Aussagen des Originals, auch wenn diese falsch sind. Wer veröffentlicht, braucht also weiterhin eine eigene Schlussprüfung: erst die Quelle gegen die Aussagen vergleichen, dann die Umschreibung laufen lassen, nicht umgekehrt.
Redaktionelles Fazit
Humanizer passt für Autoren und Teams, die maschinell erzeugte Entwürfe überarbeiten wollen, bevor sie veröffentlicht werden, und dafür eine Agent-Umgebung mit Fähigkeitsunterstützung nutzen. Es passt nicht als Prüfwerkzeug dafür, ob ein Text inhaltlich stimmt, denn die Fähigkeit korrigiert Stil, keine Fakten. Vor dem Einsatz lohnt ein Probelauf mit einem eigenen KI-Text über /humanizer, danach ein Vergleich beider Fassungen mit dem Original, um zu sehen, welche der 35 Muster im eigenen Schreibstil überhaupt eine Rolle spielen.
Community-Notizen