opendraft – 18-stufige KI-Pipeline zur Erstellung wissenschaftl…

opendraft

Wandelt einen Themenvorschlag in eine fertige wissenschaftliche Arbeit mit echter Literaturbasis um.

Portiert von OpenDraft (github.com/federicodeponte/opendraft, MIT), das ursprünglich als gehosteter Dienst lief. Hier bist du die Engine: achtzehn Stufen, jede ein Prompt in agents/, plus fünf Skripte, die die Teile erledigen, die ein Sprachmodell nicht von Hand machen darf.

Du bist das Modell. Kein API-Key, kein Dienst, kein Konto. Die einzigen Netzwerkaufrufe gehen an Crossref, OpenAlex und DataCite – alles offene Endpunkte.

Der eine Befehl

Schreibe eine Arbeit über <Thema>

Alles Weitere ergibt sich daraus. Bitte den Benutzer nicht, die Stufen selbst auszuführen; führe sie aus.

Frage zuerst vier Dinge ab

Vor Stufe 5, falls der Benutzer es nicht bereits gesagt hat, frage nach:

1. Zielpublikation, oder „keine, allgemein wissenschaftlich“.
2. Gesamtwortzahlbegrenzung.
3. Zitierstil, einer der sechs in references/citation-styles.md.
4. Dokumententyp, einer der Typen in references/paper-types.md.

Dies sind vier Fragen in einer Nachricht, kein Interview, und sie sind die einzigen Fragen, die die Pipeline stellt. Alles andere entscheidet sie selbst.

Frage, weil die Kosten des Ratens am Ende anfallen und dort nicht mehr beglichen werden können. Eine Publikation mit einer strikten Obergrenze von 150 Wörtern für die Zusammenfassung wird in Stufe 6 oder gar nicht durchgesetzt: Wenn Stufe 17 die Zusammenfassung schreibt, ist das Wortbudget, gegen das jeder Abschnitt entworfen wurde, bereits falsch. Ein an der Pforte gewählter Zitierstil (statt in Stufe 6) bedeutet, dass der gesamte Entwurf gegen die falsche Markierungsdichte geschrieben wurde.

Wenn der Benutzer die Antwort verweigert oder sagt „such du aus“, fahre mit den Standardeinstellungen in references/paper-types.md fort, schreibe sie in den Formatblock der Publikation in Stufe 6 und teile in einem Satz mit, welche Standardeinstellungen du verwendet hast. Gehe niemals von einer unausgesprochenen Annahme aus, die du dem Benutzer nicht gezeigt hast.

Vier Dinge, die die Skripte besitzen – und du nicht

Ein Sprachmodell ist gut im Urteilen und schlecht in der Buchhaltung. Diese Trennung ist beabsichtigt, und sie zu überschreiten ist der Grund, warum die Ausgabe fehlschlägt. Jedes dieser Dinge wird von einem Skript durchgesetzt, das mit einem Fehlercode ungleich Null beendet wird – sie sind also an der Pforte keine Frage der Meinung.

Schreibe niemals einen gerenderten Zitierverweis von Hand. Nicht [3], nicht (Smith, 2020). Während des Schreibens schreibst du {cite_<doi>} inline an der genauen Stelle der Behauptung. scripts/citations.py compile wandelt diese in Markierungen um und erstellt das Literaturverzeichnis per Wörterbuchsuche. Es ist deterministisch, sodass die Zuordnung zwischen Fließtext und Literaturverzeichnis mechanisch und nicht auswendig gelernt ist.

Erfinde niemals eine Quelle für eine Behauptung, die du nicht belegen kannst. Wenn eine Behauptung real ist und du keine Quelle dafür findest, schreibe {cite_MISSING: kurze Beschreibung der Behauptung} und fahre fort. compile weigert sich, sie zu rendern, benennt sie und wird mit einem Fehlercode beendet, und integrity.py zählt sie als kritisch, sodass sie nicht in einer fertigen Arbeit überleben kann. Das ist der Sinn: Es ist kein Weg, eine unbelegte Behauptung zu versenden, sondern ein Weg, beim Schreiben ehrlich zu sein, anstatt die Behauptung stillschweigend zu löschen oder an eine erfundene DOI anzuhängen. Räume jede Behauptung vor der Pforte aus, indem du mit sources.py find eine echte Quelle findest oder die Behauptung absichtlich streichst.

Füge die Abschnitte niemals von Hand in den Entwurf ein. scripts/assemble.py erledigt das in numerischer Reihenfolge und weigert sich, etwas in die Arbeit einzufügen, das kein nummerierter Abschnitt ist. Eine manuelle Zusammenführung, die einen Abschnitt auslässt, ist der Fehler, den niemand bemerkt, bis ein Leser es tut.

Entscheide niemals nach Augenmaß, ob die Arbeit in sich schlüssig ist. scripts/integrity.py prüft dies und wird mit einem Fehlercode beendet. Führe es aus und lies den Exit-Code.

Einrichtung

mkdir -p research sections review

Kein API-Key, kein Konto, kein Installationsschritt: Die Skripte verwenden nur die Python-Standardbibliothek. Es gibt eine optionale Umgebungsvariable, und sie ist die einzige, die hier irgendetwas liest. Setze OPENDRAFT_CONTACT_EMAIL auf deine eigene Adresse und sources.py hängt sie an seinen User-Agent an, wodurch Crossref-Anfragen in den höflichen Pool mit besseren Ratenlimits verschoben werden. Ist sie nicht gesetzt, läuft trotzdem jede Stufe; es ist keine Adresse fest codiert, da eine ausgelieferte Standardeinstellung alle Installationen in eine Identität zusammenfassen und ihre Ratenlimit-Probleme an das Postfach eines Fremden weiterleiten würde.

Die Pipeline schreibt in feste Pfade, und jede Stufe liest, was frühere Stufen geschrieben haben. Die Pfade sind der Vertrag zwischen den Stufen:

research/sources.md        research/sources.json     research/summaries.md
research/gaps.md           research/citations.json   research/citation-notes.md
outline.md                 outline_formatted.md
sections/*.md              full_draft.md             final.md
review/thread.md           review/narrator.md        review/skeptic.md
review/verifier.md         review/referee.md         review/voice.md
review/entropy.md          review/polish.md

Vier Regeln zu diesen Pfaden, und jede von ihnen wurde schon gebrochen:

• sections/ enthält nur Papierabschnitte und sonst nichts. Jede Datei darin wird von scripts/assemble.py in die fertige Arbeit eingefügt. Ein dort abgelegter Stufenbericht landet in der Thesis eines anderen. Berichte gehören in review/.
• research/sources.json ist Maschineneingabe, research/sources.md ist für Menschen zum Lesen. Stufe 1 schreibt beide. citations.py build liest die JSON-Datei.
• Nichts Handgeschriebenes kommt jemals in research/citations.json. Sie wird von citations.py build erstellt und nur durch erneutes Ausführen von build geändert. Die Ermessensentscheidungen, die kein Skript treffen kann (Quellen ohne DOI, überprüfungsbedürftige Einträge, Erwähnungen, die nicht in einen Platzhalter umgewandelt werden konnten), kommen in research/citation-notes.md, das Fließtext ist und niemals von einem Skript gelesen wird. Eine von Hand bearbeitete Datenbank ist der Weg, wie ein verified-Flag umgedreht wird, um die Pforte zu passieren, und wie eine unaufgelöste DOI im Literaturverzeichnis landet und überprüft aussieht.
• Nach Stufe 9.5 ist full_draft.md der einzige Entwurf. Nichts stromabwärts liest sections/*.md erneut, sodass das Bearbeiten einer Abschnittsdatei nach der Zusammenführung nichts ändert und die Änderung stillschweigend verloren geht.

Die Pipeline

Führe sie in der richtigen Reihenfolge aus. Jede Stufe bis auf eine ist eine Datei in agents/: Lese diese Datei, befolge ihre Anweisungen, schreibe die benannte Ausgabe und fahre fort. Die Ausnahme ist Stufe 9.5, die ein Skript ist, das du ausführst. Überspringe keine Stufe, nur weil das Thema einfach aussieht.

#	Stufe	Agentendatei oder Skript	Schreibt
1	Quellen finden	agents/01-scout.md	research/sources.md, research/sources.json
2	Lesen und zusammenfassen	agents/02-scribe.md	research/summaries.md
3	Die Lücke finden, die es wert ist, gefüllt zu werden	agents/03-signal.md	research/gaps.md
4	Zitationsdatenbank aufbauen	agents/04-citation-manager.md	research/citations.json, research/citation-notes.md
5	Argument gliedern	agents/05-architect.md	outline.md
6	Publikationsformat und Wortbudgets anwenden	agents/06-formatter.md	outline_formatted.md
7	Jeden Abschnitt schreiben	agents/07-crafter.md	sections/*.md, hängt an research/gaps.md an
8	Abschnittsübergreifende Konsistenz prüfen	agents/08-thread.md	Korrekturen in sections/*.md, review/thread.md
9	Stimme vereinheitlichen	agents/09-narrator.md	Korrekturen in sections/*.md, review/narrator.md
9.5	Abschnitte zu einem Entwurf zusammenfügen	scripts/assemble.py	full_draft.md
10	Argument angreifen	agents/10-skeptic.md	review/skeptic.md, dann Korrekturen
11	Behauptungen gegen Quellen prüfen	agents/11-verifier.md	review/verifier.md, dann Korrekturen
12	Peer Review simulieren	agents/12-referee.md	review/referee.md, dann Korrekturen
13	Stimme des Autors anpassen (optional)	agents/13-voice.md	Korrekturen in full_draft.md, review/voice.md
14	Prosarhythmus variieren	agents/14-entropy.md	Korrekturen in full_draft.md, review/entropy.md
15	Grammatik und finale Politur	agents/15-polish.md	full_draft.md, review/polish.md
16	Anhänge hinzufügen (optional)	agents/16-enhancer.md	full_draft.md
17	Zusammenfassung schreiben	agents/17-abstract.md	Vorangestellt an full_draft.md
18	Titel schreiben	agents/18-titlemaker.md	Vorangestellt an full_draft.md

Stufe 7 wird einmal pro Abschnitt ausgeführt, nicht einmal pro Arbeit. Stufen 10 bis 12 erstellen Problemlisten; eine Problemliste, die niemand anwendet, ist eine Nulloperation, also wende die Korrekturen an und führe die Stufe erneut aus, bis kein kritisches Problem mehr übrig ist.

Stufe 12 hat eine Zahl, kein Gefühl. Stoppe, wenn eine neue Ausführung null kritische Probleme und eine Gesamtbewertung von mindestens 3,0 von 5 meldet, wobei keine einzelne Dimension unter 3 liegt, es sei denn, du dokumentierst den Grund in review/referee.md. „Gut genug zum Abschicken“ ist keine Abbruchbedingung, da ein Modell, das aufgefordert wird, seinen eigenen Entwurf zu beurteilen, ihn beim dritten Durchgang immer für gut genug befinden wird.

Stufe 13 ist die einzige Stufe mit einer Eingabe, die die Pipeline nie selbst produziert. Sie gleicht den Entwurf an die eigene Prosa des Autors an und liest diese Prosa aus einem samples/-Verzeichnis im Arbeitsverzeichnis: zwei oder drei frühere Arbeiten, Kapitel oder längere Beiträge als .md oder .txt. Nichts erstellt dieses Verzeichnis und nichts fragt dich danach, daher überspringt ein Durchlauf, der nie eines erstellt, Stufe 13 sauber, was der normale Ausgang und kein Fehler ist. Lege vor dem Durchlauf deine eigenen Schriften dort ab, wenn die Arbeit so klingen soll, als hättest du sie geschrieben.

Stufe 9.5 ist als halber Schritt nummeriert, weil es ein Skript und kein Agenten-Prompt ist, und weil die achtzehn Agentenstufen die Nummern behalten, die sie bereits hatten. Sie ist nicht optional. Stufen 1 bis 9 arbeiten auf sections/*.md; Stufen 10 bis 18 arbeiten auf full_draft.md; nichts erzeugt diese Datei außer diesem Befehl:

python3 scripts/assemble.py sections -o full_draft.md

Er führt die Abschnittsdateien in numerischer Reihenfolge zusammen, weigert sich, eine Datei einzufügen, die kein nummerierter Abschnitt ist, und bricht bei einer Nummerierungslücke, einer doppelten Nummer oder einem leeren Verzeichnis mit einem Fehlercode ab. --check zeigt an, was er tun würde, ohne etwas zu schreiben.

Er überspringt auch jede nummerierte Datei, deren Name report, review, notes, checklist oder log enthält – das ist der Mechanismus, der verhindert, dass ein alter Stufenbericht in einer Thesis landet. Das ist eine Dateinamen-Heuristik, daher hat sie eine scharfe Kante: Ein echter Abschnitt namens „Review of the literature“ würde übersprungen werden, und du würdest ihn nur als „Übersprungen“-Zeile auf stdout sehen, nicht als Fehler. Nenne diesen Abschnitt stattdessen related-work oder literature. Lies die Übersprungszeilen; ein Abschnitt, der hier verschwindet, verschwindet stillschweigend.

Ein erneutes Ausführen, nachdem full_draft.md bereits existiert, benötigt --force, und --force verwirft alle Bearbeitungen, die Stufen 10 und später am Entwurf vorgenommen haben. Führe die Zusammenführung also nur dann erneut durch, wenn du neu von den Abschnitten beginnen möchtest.

Skalierung

Passe die Pipeline an das an, was gefragt wurde. Die Stufen sind dieselben; die Tiefe nicht.

• Ein kurzes Stück, 1.500 bis 3.000 Wörter. Stufen 1 bis 7, dann 9.5, 10, 11, 15. Zehn bis fünfzehn Quellen.
• Ein vollständiges Papier, die Voreinstellung. Alle achtzehn plus 9.5. Fünfundzwanzig bis fünfzig Quellen, oder fünfzig und mehr, wenn das Papier eine Literaturübersicht ist, deren eigene Untergrenze gilt, wo immer sie höher ist (references/paper-types.md).
• Ein Thesis-Kapitel oder eine lange Übersicht. Alle achtzehn plus 9.5, Quellen in den Fünfzigern oder mehr, und Stufe 7 einmal pro Unterabschnitt statt pro Abschnitt.

Stufe 9.5 ist in jeder dieser Listen enthalten. Es gibt keine Größenordnung, bei der sich ein Papier von selbst zusammenfügt.

Die zwei Referenzdateien

• references/paper-types.md enthält das Abschnittsskelett, das Wortbudget und die Quellenanzahl für jeden Dokumententyp. Lese es in Stufe 5.
• references/citation-styles.md zeigt die tatsächliche kompilierte Ausgabe aller sechs Stile, Inline-Markierung und Referenzeintrag, sodass du einen für die Publikation auswählen und wissen kannst, wie er aussehen wird. Lese es in Stufe 6 und noch einmal vor der Pforte, wenn eine Zitierung in einer unerwarteten Weise gerendert wird. Es gibt auch an, was der Compiler nicht unterstützt: keine Band-, Heft- oder Seitenzahlen, keine Zeitschriftenabkürzung. Wenn ein Betreuer diese verlangt, ist dies der Ort, der es ehrlich sagt, und nicht der Ort, an dem du es hinterher herausfindest.

Keine der Dateien ist eine optionale Lektüre, die als Referenz getarnt ist. Ein Stil, der ohne Lesen der zweiten Datei ausgewählt wird, ist ein aus dem Gedächtnis gewählter Stil, und der Compiler implementiert nicht deine Erinnerung an APA.

Die Skripte

python3 scripts/sources.py find "<Abfrage>" --n 15        # Crossref plus OpenAlex
python3 scripts/sources.py find "<Abfrage>" --json        # maschinenlesbar
python3 scripts/sources.py verify <doi> <doi> ...       # Crossref plus DataCite

python3 scripts/citations.py build research/sources.json -o research/citations.json
python3 scripts/citations.py verify -d research/citations.json
python3 scripts/citations.py compile full_draft.md -d research/citations.json --style apa -o final.md
python3 scripts/citations.py bibtex -d research/citations.json -o refs.bib

python3 scripts/assemble.py sections -o full_draft.md
python3 scripts/assemble.py sections -o full_draft.md --check

python3 scripts/integrity.py final.md -d research/citations.json --target 8000
python3 scripts/integrity.py final.md -c research/summaries.md   # beratende Wortanzahlprüfung
python3 scripts/export.py final.md --format docx -o final.docx

Jedes von ihnen wird bei einem Fehler mit einem Exit-Code ungleich Null beendet. Dieser Exit-Code ist das Signal; lies ihn, anstatt die Ausgabe zu überfliegen.

sources.py find wird mit 1 beendet, wenn überhaupt keine API erreicht werden konnte – das ist etwas anderes, als sie zu erreichen und keine Treffer zu erhalten. agents/01-scout.md ist die Autorität dafür, wie dieser Exit-Code zu lesen ist und welcher Quellenuntergrenze Stufe 1 anhält, statt fortzufahren; lies es dort, anstatt einem leeren Ergebnis zu vertrauen.

citations.py build erwartet das JSON-Array, das Stufe 1 in research/sources.json geschrieben hat, nicht das Markdown in research/sources.md. Ihm die Markdown-Datei zu füttern ist ein Fehler, und es wird das mitteilen.

Suche auch zwei oder drei engere Unterabfragen, wenn der erste Durchlauf dünn ist. Ein Papier mit fünf Quellen liest sich wie eines mit fünf Quellen.

Verifikation und was sie beweist (und was nicht)

citations.py verify versetzt jede DOI in einen von vier Zuständen, und unknown wird niemals stillschweigend in absent umgewandelt:

• resolved. Crossref oder DataCite hat den Datensatz zurückgegeben. Zitiere ihn.
• absent. Beide haben 404 zurückgegeben. Entferne ihn. Repariere ihn nicht, rate keine Ersatz-DOI, geh nicht dorthin zurück…