academic-humanizer: ein Redaktionsdurchgang für KI-gestützte Paper- und Grant-Entwürfe

Das Problem: Präzision geht beim Glätten als Erstes verloren

Das Repository beschreibt eine Ausgangslage, die viele Arbeitsgruppen kennen. KI-gestützte Entwürfe kommen generisch und weitschweifig heraus, mit "In recent years..." als Einstieg, aufgeblähten Formulierungen und überlangen Sätzen. Gleichzeitig entfernen sie sich von der Stimme der Autorin oder des Autors. Die README nennt das den eigentlichen Grund für das Projekt: vorhandene Humanizer seien für Blogs und Marketing gebaut, und auf einem Paper oder einem NSF-Antrag glätteten sie die Präzision gleich mit. Die sorgfältige Wortwahl, auf der wissenschaftliches Schreiben beruht, sei das Erste, was dabei verloren gehe. Der Adressatenkreis ist damit klar umrissen: Forschende, die bereits mit KI-Unterstützung entwerfen und den Text danach in eine publizierbare oder einreichbare Form bringen müssen, ohne Zahlen, Zitate und Abschwächungen anzufassen. Die README betont ausdrücklich, dass es nicht um das Umgehen von Detektoren oder um erfundene Neuheit geht, sondern um Klarheit und Stimme.

Sechs Schichten, vom allgemeinen KI-Tell bis zum Förderantrag

Die README beschreibt den Aufbau als sechs Schichten: ein allgemeiner Katalog von KI-Schreibmustern, ein akademikspezifischer Katalog, das Bewahren wissenschaftlicher Konventionen, den Abgleich von Behauptung und Beleg, die Kalibrierung auf Stimme und Zielvenue sowie einen Modus für Förderanträge. Diese letzte Schicht ist auf die Struktur von NSF- und NIH-Anträgen zugeschnitten, mit Schwerpunkt auf den ersten Seiten, weil dort nach Einschätzung der Autoren die Bewertung fällt. Der Ablauf ist als Audit-dann-Rewrite-Schleife in SKILL.md festgehalten. Wichtig für die Einordnung: Layer 1 stammt laut Danksagung aus blader/humanizer und wurde für wissenschaftliche Prosa erweitert. Wer den allgemeinen Tell-Katalog schon kennt, gewinnt hier vor allem die akademischen Schichten und den Grant-Modus, nicht die Grundidee.

Was der Durchgang anfasst und was er in Ruhe lässt

Die Eingriffe sind konkret benannt. Entfernt werden laut README Wendungen wie "paves the way", "extensive experiments", "to the best of our knowledge", "In recent years...", dazu delve, underscore und tapestry, Dreierketten, sehr lange Sätze und Gedankenstriche. Bei den Behauptungen gilt eine Regel, die sich leicht nachprüfen lässt: kein Verb, das stärker ist als die Daten, also "prove" wird zu "show empirically". Vage Größenangaben werden zu zugeordneten Bereichen. Auf der anderen Seite steht eine Liste von Dingen, die unangetastet bleiben: beleggebundenes Hedging, Passiv, wo es passt, das Wir, Definitionen, Symbole und jede Zitation. Keine Zahl und keine Referenz wird verändert. Das ist der eigentliche Unterschied zu einem allgemeinen Humanizer: Der Text wird nicht auf ein Zielprofil hin geglättet, sondern gegen den eigenen Belegstand geprüft. Die README liefert dazu ein Vorher-Nachher-Paar, in dem aus einem Satz über "a transformative paradigm that will revolutionize the field" eine knappe Aufzählung von drei Arbeitsfeldern mit zwei Anwendungsdomänen wird.

Installation und Aufruf

Die Installation besteht aus einem Klon in das Skill-Verzeichnis von Claude Code: git clone https://github.com/AIScientists-Dev/academic-humanizer ~/.claude/skills/academic-humanizer. Das Projekt ist nach eigener Beschreibung nichts weiter als eine SKILL.md plus Beispiele, also auch als Skill oder System Prompt für Codex und MorphMind nutzbar; dort zeigt man den Agenten auf SKILL.md. Der Aufruf erfolgt als /academic-humanizer, danach fügt man einen Abschnitt ein oder verweist auf main.tex. Optional lassen sich zwei Angaben mitgeben: "match my voice from prior_paper.pdf" und "target venue: ICLR". Die Zielvenue-Angabe ist der Hebel für die Kalibrierungsschicht, und die Voice-Referenz ist der Hebel für alles, was mit Stil zu tun hat. Ohne diese beiden Angaben arbeitet das Skill mit den Standardregeln des Repositories, die nach Aussage der Autoren die Stimme einer einzelnen Gruppe widerspiegeln.

Die Grenze: die Regeln sind die Stimme eines fremden Teams

Der Abschnitt "Make it yours" ist die ehrlichste Stelle der README. Dort steht, dass die Regeln die Stimme einer Gruppe abbilden und man das Repository forken und an die eigene anpassen soll, indem man es auf einige eigene frühere Arbeiten zeigt. Das ist keine Fußnote, sondern eine Einschränkung des Nutzens. Wer das Skill unverändert auf ein Manuskript in einem anderen Fach, in einer anderen Sprache oder mit anderem methodischem Vokabular anwendet, bekommt einen Text, der nach der Referenzgruppe klingt, nicht nach der eigenen. Dazu kommt ein zweiter Punkt: Das Skill erzeugt keine Befunde, erfindet keine Daten und ändert keine Zitate, kann also auch keine inhaltlichen Lücken schließen. Ein Entwurf mit schwacher Argumentation bleibt nach dem Durchgang schwach, nur lesbarer. Und die Disclosure-Pflicht bleibt bestehen; die README verweist dafür auf die Regeln der jeweiligen Venue. Wer auf Detektor-Umgehung hofft, ist hier falsch, das sagt die README selbst.

Abgrenzung zu blader/humanizer und koaeraser/ARMS

Die Danksagung nennt zwei Referenzprojekte mit unterschiedlicher Reichweite. blader/humanizer (MIT) zielt auf allgemeine KI-Schreibmuster in Blog-, Alltags- und enzyklopädischen Texten; academic-humanizer übernimmt daraus den Tell-Katalog der ersten Schicht und erweitert ihn um wissenschaftliche Muster. koaeraser/ARMS ist eine autonome Pipeline für Statistik- und Methodenpapiere, die von der Idee bis zum überarbeiteten Manuskript läuft. Der Unterschied liegt im Umfang: ARMS deckt den gesamten Entstehungsprozess ab, academic-humanizer ist laut eigener Beschreibung das schmalere Stück, ein einzelner Redaktionsdurchgang. Wer noch keinen Entwurf hat, braucht ARMS oder etwas Vergleichbares. Wer einen fertigen Entwurf hat und nur Klarheit und Belegbindung nachziehen will, greift zu diesem Skill. Die beiden schließen sich nicht aus, überlappen aber auch nicht.

Pflege, Lizenz und was die Angaben hergeben

Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im Juli 2026, Releases wurden nicht abgerufen. Die README nennt Version 0.3.2 und MIT als Lizenz, die Metadaten des Repositories führen dagegen NOASSERTION. Diese Abweichung sollte man vor einer Weitergabe klären, denn sie betrifft die Frage, ob und unter welchen Bedingungen ein Fork veröffentlicht werden darf. Da Layer 1 aus einem MIT-lizenzierten Projekt stammt, ist die Herkunft der Regeln nachvollziehbar, aber die Kombination mit den eigenen Schichten und Beispielen macht die Lizenzlage des Gesamtwerks nicht automatisch eindeutig. Für die Pflege gilt: Es gibt keine Release-Historie, an der man Upgrades festmachen könnte, und der Inhalt ist eine einzelne Markdown-Datei. Ein Upgrade bedeutet in der Praxis, die Datei neu zu klonen und die eigenen Anpassungen erneut einzutragen. Wer das Skill forkt und die Regeln auf die eigene Stimme zuschneidet, trägt die Pflege dieses Forks selbst; das Repository liefert nur die Ausgangsfassung.

Für wen sich der Durchgang lohnt

Der Nutzen steht und fällt mit der Referenzbasis. Wer akzeptierte Paper und geförderte Anträge als Vergleichsmaterial hat, kann das Skill darauf kalibrieren und bekommt einen Durchgang, der die eigene Stimme trifft statt einer fremden. Wer diese Basis nicht hat, arbeitet mit den Standardregeln einer anderen Gruppe und sollte das Ergebnis entsprechend skeptisch lesen. Der Grant-Modus ist der Teil, der sich am wenigsten durch ein allgemeines Werkzeug ersetzen lässt, weil er auf die Struktur von NSF- und NIH-Anträgen und auf die Gewichtung der ersten Seiten zugeschnitten ist. Die README verweist für aktuelle, verbindliche Anforderungen ausdrücklich auf die PAPPG und die NIH-Anleitung, weil Layer 6 nur die stabile Struktur destilliert und keine Seitenlimits oder Formatvorgaben kennt. Wer die Belegbindung im Manuskript überprüfen will, sollte mit dem Vorher-Nachher-Material unter examples/before-after.md beginnen, dort liegen ein allgemeines Beispiel, eine NIH Specific Aims Page und eine geförderte NSF-CAREER-Zusammenfassung.

Redaktionelles Fazit

Sinnvoll ist das Skill für Forschende, die bereits akzeptierte Arbeiten und geförderte Anträge als Referenz vorliegen haben und den Durchgang auf die eigene Stimme kalibrieren wollen. Wer keine solche Textbasis besitzt oder erwartet, dass ein generisches Filterprofil die eigene Schreibweise trifft, sollte es nicht einsetzen. Vor dem ersten Lauf ist zu prüfen, ob die sechs Schichten in SKILL.md zu Fach und Sprache des eigenen Manuskripts passen, ob die Beispiele unter examples/before-after.md die eigene Vorstellung von gutem Stil treffen und ob die Lizenzangabe nach dem Klonen tatsächlich MIT lautet.

Offizielle Quellen

1. AIScientists-Dev/academic-humanizer on GitHub
2. Issues
3. Project website
4. README