ZhangYanXiong/wechat-mp

WeChat Official Account Content Factory

Automatisierung der mühsamen Handarbeit nach dem Schreiben: Layout, Bilder, Compliance, Auslieferung.

Das Schreiben selbst übernimmt das Modell; dieses Skill sorgt dafür, dass ein Artikel tatsächlich veröffentlicht werden kann, gut aussieht und keine Fallstricke enthält.

Funktionsumfang

Ebene	Fähigkeit	Beschreibung	Abhängigkeiten
L0 Material-Ebene	ingest.py Materialaufnahme	PDF/docx/pptx/Webseite/Langtext → zitierfähiges, strukturiertes Material	pypdf, python-docx, python-pptx
L1 Einfüge-Ebene	md2wx.py Markdown → Inline-Style HTML	4 Themes, Ausgabe direkt in den Editor einfügbar	Reine Standardbibliothek
L2 Entwurfs-Ebene	cover.py Titelbilder, lint.py Schreib-Tor, check.py Compliance-Prüfung, preview.py Layout-Bestätigung	900×383 / 1080×1080 / 200×200; Validierung während des Schreibens möglich	Pillow, Chrome
L3 Direktveröffentlichung	Entwurfsordner-API Direktveröffentlichung	Nicht implementiert, Schnittstellenvertrag in references/api.md	AppID + AppSecret + verifiziertes Konto

Die vollständige Erstellung liefert standardmäßig L1 + L2 aus; Teilaufgaben werden gemäß dem Anfrageumfang ausgeliefert, ohne die gesamte Palette zu erzwingen. L3 erfordert ein verifiziertes Konto mit Zugriff auf AppSecret – nicht verifizierte Abonnementkonten haben keine Entwicklerschnittstelle, daher bleibt es bei L2 (manuelles Einfügen). Dies muss vorher mit dem Benutzer geklärt werden; nicht einfach annehmen.

Schnellstart

Die Reihenfolge ist wichtig: Zuerst Vorschau, dann Prüfung, zuletzt Arbeitsmappe generieren. Die Arbeitsmappe ist ein Schnappschuss; wenn sie zu früh generiert wird, ist sie nach Änderungen am Artikel veraltet.

Die vollständige Erstellung wird anhand der drei Titelbildformate dieses Skills überprüft. Wenn ein veröffentlichungsbereites Layout explizit angefordert wird, müssen auch die Titelbilder überprüft werden; lint --out out --publish stuft fehlende oder falsch dimensionierte Bilder als „muss repariert werden“ ein. Normale „nur Layout“, „nur Prüfung“, „nur Vorschau“ erzwingen keine Titelbilder. Die drei Formate sind der Lieferstandard dieses Projekts und ersetzen nicht die aktuellen Anforderungen der WeChat-Oberfläche oder die tatsächliche Bildprüfung.

# 0. Bei vorhandenen Materialdateien zuerst aufnehmen (PDF/docx/pptx/Webseite)
python3 scripts/ingest.py material.pdf -o out/ingest

# 1. Vollständige Erstellung generiert Titelbilder gemäß Projektspezifikation: 900×383 Hauptbeitrag + 1080×1080 quadratisch + 200×200 Unterbeitrag
python3 scripts/cover.py --md article.md --all -o out/cover

# 2. Zuerst Vorschauseite generieren (dieser Schritt erzeugt keine Arbeitsmappe); das Ausgabeverzeichnis wird automatisch erstellt, falls es nicht existiert
python3 scripts/md2wx.py article.md -o out/article.html

# 3. Layout-Bestätigung (falls Browser nicht verfügbar, dies ehrlich angeben)
python3 scripts/preview.py out/article.html -o out/preview.png --height 4000

# 4. Doppelte Prüfung (zuerst eine Runde laufen lassen; bei Problemen zuerst den Artikel korrigieren, dann wiederholen)
python3 scripts/lint.py article.md --cards out/materialkarten.md --outline out/gliederung.md --strict
python3 scripts/check.py article.md --html out/article.body.html --strict

# 5. Nach bestandener Prüfung zuletzt Arbeitsmappe generieren und Schnappschuss erstellen (Build-Fingerprint wird in die Artefakte und build.json geschrieben)
python3 scripts/md2wx.py article.md --sheet --snapshot -o out/article.html

# 6. Endkontrolle vor Auslieferung: Artefakte müssen mit der aktuellen Quelle übereinstimmen, und alle Titelbilder müssen vorhanden sein (--publish)
python3 scripts/lint.py article.md --out out --publish --strict
python3 scripts/check.py article.md --html out/article.body.html --strict

Alle Befehle werden im Skill-Stammverzeichnis ausgeführt. python3 muss 3.9+ sein; cover.py benötigt Pillow. Führen Sie die Schritte nacheinander aus und überprüfen Sie die Exit-Codes; ignorieren Sie keine Fehler und fahren Sie nicht fort. Bei Batch-Ausführung zuerst set -e aktivieren. Wenn keine Materialkarte oder Gliederung vorhanden ist, lassen Sie die entsprechenden Parameter weg und dokumentieren Sie den nicht geprüften Bereich; wird ein Parameter explizit übergeben, aber die Verarbeitung schlägt fehl, darf dies nicht als „nicht bereitgestellt“ gewertet werden. Ein vollständiger Schnappschuss erfordert, dass lokale Bilder bereits im Ausgabeverzeichnis abgelegt sind. Nur Layout erzwingt weder Schnappschuss noch Titelbilder.

Vor dem Schreiben: Zuerst das Frontmatter schreiben

Meta-Informationen wie Titel, Zusammenfassung, Autor, Thema werden nur einmal geschrieben und am Anfang der Markdown-Datei platziert; drei Skripte nutzen sie gemeinsam:

---
title: Wie ich 150 Wochenberichte vergeigt habe, bis ich verstand: Der Chef will nicht, „was du getan hast“
title_short: Wochenbericht nicht als Einkaufsliste schreiben
summary: Ein Wochenbericht durchläuft drei Übersetzungsstufen, und mit jeder Stufe gehen Informationen verloren. Wenn der Chef keinen Satz daraus kopieren kann, ist deine Arbeit diese Woche gleich null.
author: Cloud Voyager
tag: Beruflicher Aufstieg
theme: growth
---

# Haupttitel

Der Text beginnt hier…

Feld	Erforderlich	Beschreibung
title	Ja	Langer Titel, ≤64 Zeichen; dies wird im Backend eingetragen
title_short	Ja	Kurzer Titel, ≤20 Zeichen; nur zur Überprüfung der Anzeige im Newsfeed, wird nicht im Backend eingetragen
summary	Ja	Zusammenfassung, ≤120 Zeichen
author	Nein	Autorenfeld im Backend + Namensnennung auf dem Titelbild; wenn nicht angegeben, wird standardmäßig „Cloud Voyager“ verwendet
tag	Empfohlen	Label oben links auf dem Titelbild, 2–4 Zeichen
theme	Empfohlen	tech / growth / minimal / elegant
cover_title	Nein	Falls auf dem Titelbild ein anderer Text erscheinen soll; wenn weggelassen, wird title verwendet

Nachdem das Frontmatter geschrieben ist, müssen für die spätere Wiedergabe, Titelbilder und Prüfung keine Parameter mehr übergeben werden.

Namensnennungsregel: Standardmäßig „Cloud Voyager“, wenn der Benutzer eine Angabe macht, wird diese verwendet.

Szenario	Vorgehen
Benutzer macht keine Angabe zur Namensnennung	Nichts schreiben, automatisch „Cloud Voyager“ verwenden; die Arbeitsmappe kennzeichnet es mit „Standard-Namensnennung“
Benutzer gibt eine Namensnennung an	In author im Frontmatter eintragen – Arbeitsmappe, Titelbild und Autorenfeld im Backend lesen alle daraus
Benutzer möchte nur vorübergehend den Text auf dem Titelbild testen	md2wx.py --author / cover.py --author verwenden, um zu überschreiben, ohne es dauerhaft zu speichern

Priorität: --author Befehlszeile > author im Frontmatter > Standard „Cloud Voyager“. Verwenden Sie nicht nur cover.py --author, ohne das Frontmatter zu ändern – das würde dazu führen, dass die Namensnennung auf dem Titelbild und das Autorenfeld in der Arbeitsmappe inkonsistent sind.

Arbeitsablauf

Zuerst Aufgabenast auswählen, dann entsprechende Schritte ausführen. Nur die „vollständige Erstellung“ erfordert die sequentielle Durchführung der gesamten Kette; Teilaufgaben folgen nicht dem gesamten Erstellungsfragebogen.

Aufgabe	Typische Anfrage	Nur Bestätigung erforderlich	Ausführungsroute
Vollständige Erstellung	Einen Artikel schreiben; Material in einen Artikel umwandeln	Nische, Leser, Material, Thema	Schritt 0 → 0.5 (falls Material vorhanden) → 1~7
Nur Layout	Bereits fertiggestellt, nur Layout; in WeChat-HTML umwandeln	Fertige Quelldatei, Thema oder vorhandenes Frontmatter; fehlende Meta-Informationen erst bei geplanter Veröffentlichung ergänzen	Schritt 4 → Schritt 6.2 (Hinweise prüfen, nicht selbst korrigieren) → Schritt 7 (Teilauslieferung)
Nur Titelbild	Nur Titelbild für WeChat	Titelbildtext, Thema/Stil, erforderliche Abmessungen, optionales Label und Namensnennung	Schritt 5 → Manuelle Prüfung des Titelbildtexts → Schritt 7 (Teilauslieferung)
Nur Prüfung	Nur Compliance, Layout oder Zitate prüfen	Zu prüfende Dateien; entsprechende Parameter nur verwenden, wenn HTML, Materialkarten oder Gliederung vorhanden sind	Schritt 6 relevante Prüfungen → Schritt 7 (nur Bericht ausliefern)

Wenn der Aufgabenast nicht bestimmt werden kann (z. B. „Hilf mir mal mit diesem Text“ oder „Schau, ob das veröffentlicht werden kann“): Zuerst Schritt 0 wie bei der vollständigen Erstellung durchführen, aber nur die wichtigste Frage stellen, nicht alle vier auf einmal. Lieber eine Frage mehr stellen, als den falschen Ast zu erraten und sieben Schritte zu gehen.

Teilaufgaben ergänzen nur die für die aktuelle Aufgabe notwendigen Informationen, vorhandene Informationen werden direkt übernommen; der fertige Text oder vorhandene Titel dürfen nicht neu geschrieben werden. Leser, Thema, Gliederung werden nicht erneut bestätigt, und es werden nicht erzwungen fünf Titel-Alternativen angeboten. Nur wenn der Benutzer explizit eine Überarbeitung des Artikels wünscht, wird in den entsprechenden Erstellungsschritt eingestiegen.

• Nur Layout ruft cover.py nicht auf, es sei denn, der Benutzer wünscht gleichzeitig ein Titelbild. Vorhandenes Thema wird bevorzugt übernommen; wenn keine Präferenz besteht, wird tech verwendet und begründet, ohne den Ablauf zu blockieren.
• Nur Titelbild erfordert keine Zusammenfassung, keinen Text, keine Materialkarten oder Gliederung; es wird auch kein Artikel gefälscht, um eine vollständige Prüfung durchzuführen. Gemäß references/compliance.md wird nur der tatsächliche Titelbildtext überprüft, und der Prüfumfang wird angegeben.
• Nur Prüfung ändert die geprüften Dateien nicht. Wenn nur Markdown vorhanden ist, wird --html nicht übergeben; wenn nur HTML ohne Markdown-Quelle vorhanden ist, wird nur eine manuelle HTML-Kompatibilitätsprüfung durchgeführt und der Umfang angegeben; es wird kein falscher Text erstellt. Fehlen Materialkarten, wird darauf hingewiesen, dass Zitate und Zahlen nicht vollständig überprüft werden können.
• Wenn Pillow oder der Browser fehlen, wird nicht selbst installiert oder so getan, als sei der Schritt abgeschlossen; die abgeschlossenen Teile werden ausgeliefert und die fehlenden Teile aufgeführt. Ein Teilabschluss bedeutet nicht, dass der gesamte Artikel veröffentlicht werden kann.

Schritt 0 · Eingabe bestätigen (nur vollständige Erstellung)

Für die vollständige Erstellung werden vier Dinge bestätigt; vorhandene Antworten werden direkt übernommen; nur wenn notwendige Informationen fehlen, wird nachgefragt; es wird nichts erfunden:

1. Nische: Technik/Produkt oder Beruf/Persönlichkeitsentwicklung (bestimmt Thema und Stil)
2. Leser: Wer sind sie, wo hängt es, was können sie nach dem Lesen tun?
3. Material: Gibt es reale Belege, Daten, Code, Screenshots?
4. Themenpräferenz: Standardmäßig nach Nische (siehe „Themenauswahl“)

Gleichzeitig wird bestimmt, welcher Ausgangspunkt vorliegt, da unterschiedliche Wege gegangen werden:

Ausgangspunkt	Typische Formulierung	Welcher Weg
Material gegeben	„Mach aus diesem PDF / Wochenbericht / dieser Webseite einen WeChat-Artikel“	Schritt 0.5 → Schritt 1
Thema gegeben	„Schreib einen Artikel über X“	Schritt 0.5 überspringen, direkt Schritt 1
Beides vorhanden	„Schreib auf Basis dieses Berichts einen Artikel über Y“	Schritt 0.5 → Schritt 1

Schritt 0.5 · Material aufnehmen (nur wenn der Benutzer Dateien oder Links gegeben hat)

Lesen Sie references/ingest.md und führen Sie es aus. Überspringen Sie diesen Schritt nicht und beginnen Sie nicht sofort mit dem Schreiben – direktes Lesen des Originaltexts führt zu überflogenem Lesen, übersehenen Schlussfolgerungen und falsch gemerkten Zahlen.

python3 scripts/ingest.py material.pdf meeting-minutes.docx -o out/ingest

Es werden drei Dateien ausgegeben (bereinigter Text / Strukturgerüst / Kandidaten für zitierbare Sätze). Anschließend gemäß ingest.md §2 Materialkarten extrahieren:

Präfix	Typ
F	Fakt (objektive Aussage)
D	Daten (Zahl + Einheit + Bezugsgröße)
O	Meinung (Behauptung des Autors, kein Fakt)
?	Zweifelhaft (widersprüchlich / ohne Quelle / prüfbedürftig)

Das Ergebnis dieses Schritts ist eine Tabelle der Materialkarten + eine Liste von Lücken, die dem Benutzer zur Bestätigung vorgelegt wird, bevor es weitergeht.

Drei rote Linien (ingest.md §3): Keine Zahlen ändern, keine Bezugsgrößen ändern, keine Vermutungen als Tatsachen ausgeben. Wenn für eine Kennzahl mehrere Werte gefunden werden, in die ?-Karte gehen und den Benutzer fragen, nicht stillschweigend einen auswählen.

Schritt 1 · Themenerweiterung und Gliederung

• Benutzer hat Material gegeben: Aus den Materialkarten mögliche Blickwinkel ableiten (references/topic-expand.md §3)
• Benutzer hat nur ein Thema vorgegeben: topic-expand.md §1–§3 durchgehen und einen einzelnen Satz zu einem Argumentationsbaum erweitern

Dann in Kombination mit references/writing-playbook.md §1 (Nischen-Baseline) und §4 (5 Strukturvorlagen) ein Gerüst auswählen und eine Gliederung mit Wortanzahl-Aufteilung erstellen, die dem Benutzer zur Bestätigung vorgelegt wird.

Jedes Argument in der Gliederung muss mit einer Materialkarten-ID verknüpft sein ([F1] [D2]). Argumente, die nicht verknüpft werden können, werden direkt gelöscht, auch wenn dies die strukturelle Vollständigkeit beeinträchtigt (topic-expand.md §4).

Schritt 2 · Titel und Zusammenfassung schreiben

Lesen Sie references/writing-playbook.md §2 und §6:

• Langen Titel (≤64 Zeichen, für das Backend-Feld) + kurzen Titel (≤20 Zeichen, für die Anzeige im Newsfeed) erstellen
• Einmal 5 Kandidaten vorlegen, jeweils mit der verwendeten Formel, den Benutzer auswählen lassen
• Zusammenfassung ≤120 Zeichen, 1–2 Versionen anbieten

Schritt 3 · Haupttext schreiben

Markdown gemäß Gliederung schreiben, dabei beachten:

• Einleitung gemäß §3 mit einem Haken schreiben, die ersten 3 Zeilen müssen den Leser packen
• Jeder Absatz eine Sache, einzelner Absatz ≤5 Zeilen (ca. 260 Zeichen)
• Ende gemäß §5, mit „Frage als Abschluss / Serienvorschau / Zusammenfassung des Mehrwerts“, keine „Teilen“-Aufforderungen schreiben
• Nach dem Schreiben mit der 24-Punkte-Liste aus §7 auf „KI-Geruch“ prüfen, alle Übergangswörter löschen, die das Verständnis nicht beeinträchtigen

Schritt 4 · Layout-Rendering

Das theme aus dem Frontmatter oder das vom Benutzer explizit angegebene Thema verwenden; wenn keine Präferenz besteht, nach Nische auswählen, bei Teil-Layout standardmäßig tech:

python3 scripts/md2wx.py article.md -o out/article.html

Das übergeordnete Ausgabeverzeichnis wird automatisch erstellt; es werden zwei Dateien ausgegeben:

• out/article.html — Vorschauseite (mit weißem Hintergrund-Container, wie eine mobile Leseseite) → zum Anschauen
• out/article.body.html — reiner Textfragment → alternative Einfügelösung

Dieser Schritt erzeugt keine Arbeitsmappe; die endgültige out/sheet.html wird in Schritt 7 generiert, um zu vermeiden, dass vor Abschluss des Titelbilds und der endgültigen Textversion ein verfrühter Datei-Schnappschuss gespeichert wird.

Nach dem Rendern mit preview.py einen Screenshot erstellen und selbst zuerst ansehen, bevor man ihn dem Benutzer übergibt (wird der Titel unschön umgebrochen, ist die Tabelle zu breit, werden Codeblöcke abgeschnitten). Wenn der Browser nicht verfügbar ist, das HTML manuell prüfen und ehrlich angeben, dass kein Screenshot erstellt wurde; den Benutzer nicht bitten, den Artikel neu zu schreiben.

Schritt 5 · Titelbild generieren (bei Veröffentlichung Pflicht)

Ein WeChat-Artikel ohne Titelbild kann nicht veröffentlicht werden. Dieser Schritt ist bei „vollständiger Erstellung“ und „zu veröffentlichendem Layout“ keine Option.

python3 scripts/cover.py --md article.md --all -o out/cover

Drei Formate auf einmal: cover.png 900×383 (Hauptbeitrag 2.35:1), cover-square.png 1080×1080 (quadratisch), cover-thumb.png 200×200 (Unterbeitrag). Falsche Abmessungen werden von der Plattform beschnitten; lint --publish validiert dies.

Parameter werden standardmäßig aus dem Frontmatter gelesen (Titel, Label, Autor, Thema); normalerweise müssen keine weiteren Parameter übergeben werden:

• --style: gradient (Standard, dunkler Hintergrund) / minimal (weißer Hintergrund, für meinungsbasierte Artikel) / band (Farbband, für Markenartikel)
• --all generiert die drei Formate: Hauptbeitrag 900×383, quadratisch 1080×1080, Unterbeitrag 200×200
• Der Titeltext auf dem Bild verwendet standardmäßig title (der lange Titel hat mehr Haken); um einen anderen Text zu verwenden, cover_title im Frontmatter hinzufügen

Schritt 6 · Doppelte Prüfung (zwei Tore, jedes prüft seinen Bereich)

Die vollständige Erstellung führt beide Tore aus; bei nur Layout oder nur Prüfung werden gemäß der Eintrittstabelle die entsprechenden Prüfungen ausgewählt, ohne fehlende Materialien zu erzwingen oder den Originaltext zu ändern. Fehlende Meta-Informationen, Materialkarten oder Screenshots werden dokumentiert; die Teilauslieferung wird nicht als veröffentlichungsfähige vollständige Prüfung deklariert.

6.1 Schreibtisch-Tor – Prüft „hat die Meinung eine Grundlage, woher kommen die Zahlen“

python3 scripts/lint.py article.md --cards out/materialkarten.md --outline out/gliederung.md

Dieser Schritt ist ein hartes Tor, kein Vorschlag:

Prüfung	Regel	Konsequenz bei Nichtbestehen
Leere Referenz	[F1] im Text muss in der Materialkarte existieren	„Muss repariert werden“
Zweifelhafte Karte	[?N] darf nicht im Text erscheinen	„Muss repariert werden“ – überprüfen oder löschen
Zahl ohne Quelle	Jede „Zahl+Einheit“ im Text muss in F/D-Karten gefunden werden	„Muss repariert werden“
Argument ohne Beleg	Jede Stütze in der Gliederung muss ≥1 [F]/[D] haben	„Muss repariert werden“
Qualität des Hauptarguments	Kein bloßer Satz (wie „Caching ist wichtig“)	„Muss repariert werden“
Meinungskarte	Wenn [O] zitiert wird, darf es nicht als Hauptbeleg dienen	„Sollte bestätigt werden“
Lückenliste	Gliederung muss P0/P1/P2-Lücken enthalten	„Hinweis“

Wenn keine Materialkarte vorhanden ist, wird automatisch herabgestuft: Es wird nur darauf hingewiesen, dass „Zahlen nicht validiert werden können“, und alle Zahlen mit Einheiten werden zur manuellen Durchsicht aufgelistet.

Artefakt-Versionsprüfung: Mit --out <Artefakt-Verzeichnis> wird der Build-Fingerprint in den Ausgaben mit dem aus der aktuellen Quelle berechneten Fingerprint verglichen.

python3 scripts/lint.py article.md --out out --publish --strict

--publish bedeutet Prüfung auf Veröffentlichungsbereitschaft; erfordert --out zur Angabe des Artefaktverzeichnisses; Fehlen des Verzeichnisparameters führt zu einem Fehler. Es prüft die Existenz der Dateien und die Breite/Höhe aus dem PNG-Header gemäß den drei Projektspezifikationen, dekodiert Bilder nicht vollständig und validiert weder den Text auf dem Titelbild, noch Uploads oder WeChat-Oberflächenanforderungen.

Situation	Bewertung
Artefakt-Fingerprint == aktueller Quell-Fingerprint	Bestanden
Artikel bearbeitet, aber nicht neu gerendert	„Muss repariert werden“: Vorschauseite/Arbeitsmappe sind alte Versionen
build.json aufgezeichneter Quell-Auszug stimmt nicht überein	„Muss repariert werden“: Quelle wurde nach der Generierung geändert
article.body.html wurde ersetzt oder manuell bearbeitet	„Muss repariert werden“: Umgeht die Prüfung durch den Text-Fingerprint in build.json
Artefakt hat keinen Fingerprint	„Sollte bestätigt werden“: Von altem Skript generiert oder manuell geändert
Titelbild fehlt / falsche Abmessung (--publish)	„Muss repariert werden“: Erfüllt nicht die Veröffentlichungsspezifikation für Titelbilder dieses Projekts

Dieser Schritt ist die einzige mechanische Absicherung gegen „Artikel geändert, aber vergessen, neu zu rendern, und die alte Version veröffentlicht“; vor der Auslieferung zwingend ausführen.

6.2 Veröffentlichungsprüfung – Prüft „kann veröffentlicht werden“

python3 scripts/check.py article.md --html out/article.body.html --strict

Titellänge, Zusammenfassungslänge werden automatisch aus dem Frontmatter übernommen, müssen nicht erneut übergeben werden.

Harte Bestehenskriterien:

Kriterium	Anforderung
lint „Muss repariert werden“	Muss 0 sein
Hohes Risiko	0 ungelöste hohe Risiken; manuell bestätigte Fehlalarme müssen mit Beweisen und Prüfprotokoll dokumentiert werden
Meta-Informationen	title, title_short, summary sind Pflichtfelder und dürfen nicht leer sein; nur key: value einzeilige Felder werden unterstützt
Titelzeichenanzahl	Langer Titel ≤64, kurzer Titel ≤20; der tatsächlich veröffentlichte Titel und die wichtige Einleitung müssen dennoch manuell geprüft werden
Zusammenfassungszeichenanzahl	≤120
Externe Bilder	Vor der Veröffentlichung hochladen oder durch für WeChat nutzbare Bilder ersetzen und in der Editor-Vorschau bestätigen
Fach- oder vertrauliche Inhalte	Müssen manuell/rechtlich endgeprüft werden; Löschen von Schlüsselwörtern, Umschreiben oder Anonymisierung ersetzen keine Prüfung und Autorisierung

Beide --strict können in CI verwendet werden: Exit-Code ist 1, wenn „Muss repariert werden“ oder hohes Risiko vorliegt. check.py stuft fehlende/zu lange Meta-Informationen, nicht unterstützte mehrzeilige Feldwerte und explizit angegebene, aber nicht existierende HTML als hohes Risiko ein; ohne --strict werden Probleme dennoch gemeldet, aber der Exit-Code ist 0.

Die Veröffentlichungsprüfung scannt title, title_short, summary, cover_title, author, tag und den Text zeilenweise; Code im Text wird dennoch maskiert, Backticks in Meta-Informationen umgehen die Prüfung nicht. Das field im JSON-Finding gibt die Quelle an; die line im Text bezieht sich weiterhin auf den Text. Befehlszeilen-Override-Werte für Titel/Zusammenfassung sind das endgültige Prüfobjekt.

Bestandene Prüfung bedeutet nicht automatisch Veröffentlichungserlaubnis. Hohe Risiken werden gemäß references/compliance.md §0 als „Wartet auf Überprüfung / Bestätigter Fehlalarm / Abgeschlossene Überarbeitung / Veröffentlichung abgelehnt“ protokolliert; Skripte können manuelle Prüfprotokolle nicht lesen oder ersetzen; bestätigte Fehlalarme lassen --strict nicht automatisch bestehen. Bei ungelösten fachlichen, autorisierten oder vertraulichen Problemen wird pausiert und nicht als veröffentlichungsfähiger Artikel ausgeliefert. Mittel- und niedrigrisiko Beibehaltungen, manuell bestätigte Elemente und deren Begründung werden ebenfalls erläutert.

Wenn die Nutzungsberechtigung oder Quelle von Material unklar ist, zuerst die Berechtigung/Quelle ergänzen oder das Material ausschließen; es wird keine Größenordnung geändert und keine externe Meinung in eine persönliche Erfahrung des Autors umgewandelt. Nach der Materialaufnahme wird separat eine Berechtigungen_und_Einschränkungen.md erstellt, die Quelle, Namensnennung, Nutzungsumfang, anwendbare Grenzen und Autorisierungsstatus dokumentiert.

Schritt 7 · Auslieferung

Bei Aufgaben, die HTML/Arbeitsmappe erfordern, vor der Auslieferung einheitlich die endgültige Arbeitsmappe neu generieren. Nachdem der endgültige Text, die Meta-Informationen, das Thema und die angeforderten Titelbilder abgeschlossen sind, mit derselben Quelle und denselben Thema/Ausgabeparametern ausführen:

python3 scripts/md2wx.py article.md --sheet -o out/article.html

Dies aktualisiert gleichzeitig die Vorschauseite, das Textfragment und sheet.html; die Arbeitsmappe liest die endgültigen cover.png, cover-square.png, cover-thumb.png aus demselben Verzeichnis. Es ist ein statischer Datei-Schnappschuss; das Aktualisieren des Browsers generiert die Arbeitsmappe nicht neu. Wenn danach Text, Meta-Informationen, Thema oder Bilder geändert werden, die entsprechenden Artefakte neu generieren und die entsprechenden Prüfungen und Vorschauen wiederholen; keine alten Schnappschüsse ausliefern.

Build-Fingerprint und Rollback:

• Der Fingerprint umfasst den Rendering-Code, die Quelle, das zusammengeführte Thema, die tatsächlichen Titel/Namensnennung/Thema-Overrides und Ausgabeoptionen, lokale Bilder und Titelbildinhalte; Änderungen an Meta-Informationen und lokalen Assets machen alte Builds ungültig.
• build.json verwendet Schema 2, deklariert die tatsächlich angeforderten Dateien und führt für jede einzelne eine vollständige SHA256 auf; der Prüfer validiert anhand der tatsächlichen Rendering-Parameter, daher sollte ein explizites -t-Override des Themas keinen Fehlalarm auslösen. Fehlende Dateien, ersetzter Inhalt oder beschädigte Struktur blockieren den Vorgang.
• article.body.html bleibt rein und trägt keine Markierungen; es wird zusammen mit der Vorschau/Arbeitsmappe separat über die Auflistungsauszüge validiert, nicht nur über das Fingerprint-Tag im HTML. Wenn die alte Auflistung nicht vollständig validiert werden kann, wird eine Neuberechnung empfohlen.
• Vollständige Erstellung fügt beim letzten Rendern --snapshot hinzu und speichert die Quelle, das angeforderte HTML, lokale Bilder und Titelbilder in out/.builds/<fingerprint>/. Ein Schnappschuss mit demselben Fingerprint kann nicht überschrieben werden; fehlende lokale Bilder können keinen vollständigen Schnappschuss vortäuschen. Bilder müssen relative Pfade innerhalb des Ausgabeverzeichnisses sein; der Schnappschuss ruft keine entfernten Bilder ab.
• md2wx.py --list-builds --out-dir out zeigt die Historie an; md2wx.py --rollback <fingerprint> --out-dir out stellt die Quelle, Artefakte, lokale Bilder und Titelbilder am ursprünglichen Pfad wieder her und bereinigt Ausgaben aus der vorherigen Auflistung, die diese Version nicht benötigt. Vor dem Vorgang die Rollback-Absicht bestätigen, da er die aktuelle Quelle und deklarierte Assets überschreibt; nur vertrauenswürdige lokale Schnappschüsse verwenden.
• Rollback validiert zuerst alle Dateien und Auszüge; beschädigte oder gefährliche Pfade werden nicht zur Hälfte wiederhergestellt. Der Schnappschuss stellt keine Rendering-Skripte oder globalen Theme-Konfigurationen wieder her; nach solchen Änderungen muss neu gerendert und überprüft werden. Ein stdin-Schnappschuss stellt die Quelle als article.md im Ausgabeverzeichnis wieder her.
• Nur Layout verwendet den obigen Befehl ohne --snapshot; die vollständige Erstellung verwendet:

python3 scripts/md2wx.py article.md --sheet --snapshot -o out/article.html

Selbstprüfungs-Checkliste vor Auslieferung (jeden Punkt einzeln bestätigen, nicht „Befehl ausgeführt“ als „Datei angesehen“ missbrauchen):

• Vollständige Erstellung: lint.py article.md --out out --publish --strict bestanden – Artefakte entsprechen der aktuellen Quelle und Titelbilder erfüllen die Projektspezifikation
• check.py article.md --html out/article.body.html --strict bestanden – keine hohen Risiken
• article.html oder preview.png persönlich angesehen (Titelumbruch, Tabellenbreite, Codeblock-Abschnitte)
• Titel/Kurztitel/Zusammenfassung/Autor in sheet.html stimmen mit dem überein, was im Backend eingetragen wird
• Drei Titelbilder vorhanden und Kopfabmessungen korrekt (--publish bereits geprüft); Bilder separat öffnen, um zu bestätigen, dass sie dekodierbar sind und der Text nicht abgeschnitten ist
• Lokale Bilder im Text als „müssen manuell hochgeladen werden“ aufgeführt
• Auslieferungshinweis enthält: welche mittleren/niedrigen Risiken beibehalten wurden, was nicht erledigt wurde

Jedes Element einzeln an den tatsächlichen Ausgabedateien prüfen; fehlende Titelbilder oder Screenshots auflisten, nicht die Ausführung des Befehls als Dateibestätigung missbrauchen; bei vollständiger Erstellung ungelöste Fehlstellen nicht als vollständige Auslieferung deklarieren. Die Markdown-Quelldatei wird zusammen mit dem tatsächlichen Pfad bereitgestellt; die Originaldatei des Benutzers darf nicht verschoben oder überschrieben werden.

Selbstprüfung nach Aufgabenumfang (Selbstprüfung folgt der Anfrage, nicht immer nach vollständiger Erstellung):

• Vollständige Erstellung: gesamte Checkliste Punkt für Punkt durchgehen
• Nur Layout: Quelle, HTML, Textfragment, Arbeitsmappe verwendbar; nur Layout erfordert keine drei Titelbildformate
• Nur Titelbild: Nur Text auf dem Bild und Abmessungen prüfen; kein Text und keine Prüfung erforderlich
• Nur Prüfung: Nur Bericht ausliefern; keine Überarbeitung erforderlich

Teilaufgaben liefern nur die angeforderten Artefakte aus: Nur Layout liefert Quelle, HTML, Textfragment und Arbeitsmappe; nur Titelbild liefert die angeforderten Bildabmessungen und den Textprüfbericht; nur Prüfung liefert den Prüfbericht. Das Auffüllen von Titelbildern, Materialkarten oder Gliederung wird nicht verlangt; Teilprüfungen dürfen nicht als vollständige Veröffentlichungsabnahme gewertet werden.

Die folgende Liste gilt nur für die vollständige Erstellung; der Speicherort der Quelldatei basiert auf dem tatsächlichen Pfad:

out/
├── article.md          Endgültiger Markdown (Quelldatei, inkl. Frontmatter)
├── article.html        Vorschauseite (zum Anschauen)
├── article.body.html   Reiner Textfragment (Alternative)
├── sheet.html          Arbeitsmappe zum Veröffentlichen (zum Veröffentlichen)
├── cover.png           Hauptbeitrag-Titelbild 900×383
├── cover-square.png    Quadratisch 1080×1080
├── cover-thumb.png     Unterbeitrag 200×200
└── preview.png         Layout-Screenshot

Die vollständige Erstellung gibt auch an: Langer Titel / Kurzer Titel / Zusammenfassung / Prüfergebnis (welche mittleren/niedrigen Risiken beibehalten wurden). Teilaufgaben listen nur die vorhandenen Meta-Informationen, die angeforderten Artefakte, den tatsächlichen Prüfumfang und die nicht erledigten Punkte auf; es werden keine neuen Titel, Zusammenfassungen oder Texte geschrieben, um die Liste aufzufüllen.

Veröffentlichung im WeChat Official Account (wichtige Schritte)

Öffnen Sie out/sheet.html; eine Seite erledigt alle Kopiervorgänge:

1. ① Titel → „Kopieren“ klicken → in das Titelfeld im Backend einfügen
2. ③ Zusammenfassung → „Kopieren“ klicken → in das Zusammenfassungsfeld im Backend einfügen
3. ④ Autor → „Kopieren“ klicken → in das Autorenfeld einfügen
4. Text → „Text kopieren“ oben rechts klicken → in den Editorbereich einfügen
5. Bilder im Text → In der Karte „Bilder im Text“ links einzeln behandeln (siehe unten)
6. Titelbild → cover.png hochladen
7. Punkte der „Checkliste vor Veröffentlichung“ einzeln abhaken

Warum Bilder verloren gehen

Der WeChat-Editor übernimmt beim Einfügen nur Text und Formatierungen, nicht aber lokale Bilder. <img src="fig.png"> im Text ist ein lokaler relativer Pfad; nach dem Einfügen in den Editor ist die Bildposition leer – das ist kein Fehler im Layout, sondern eine Einschränkung der Host-Umgebung: Das Bild muss zuerst auf den WeChat-Server (mmbiz.qpic.cn) gelangen, um angezeigt zu werden.

Ohne API-Berechtigung kann dieser Schritt nur manuell erfolgen. Die Arbeitsmappe reduziert dies auf zwei Wege:

Weg	Vorgehen
Bild kopieren	„Bild kopieren“ klicken → an der entsprechenden Stelle im Editor Cmd+V drücken, WeChat lädt es automatisch hoch
Rechtsklick-Kopie	Falls „Bild kopieren“ fehlschlägt, „Original öffnen“ klicken → rechtsklicken „Bild kopieren“ → im Editor einfügen
Notfall	Rechtsklicken „Bild speichern unter“ → im Editor auf die Schaltfläche „Bild“ klicken und hochladen

Die Reihenfolge entspricht der Reihenfolge des Erscheinens im Text (1. Bild, 2. Bild …); beim Einfügen anhand des Textes die Position finden.

Kopieren Sie nicht den .md-Quelltext: md ist reiner Text; nach dem Einfügen bleiben nur # und ** übrig, Bilder und Layout sind nicht vorhanden. Es muss der Rich-Text aus der Arbeitsmappe oder das gerenderte Ergebnis von article.body.html sein.

Prüfen, ob Bilder fehlen: Vor der Veröffentlichung in der Mobilvorschau von Anfang bis Ende durchgehen und prüfen, ob jedes Bild an seinem Platz ist.

Alternative: article.body.html im Browser öffnen → Cmd+A → Kopieren → Einfügen. (Verwenden Sie nicht article.html, da dies die Vorschauseite ist und den äußeren Container mitbringt.)

Themenauswahl

Thema	Geeignet für	Visuell
tech Tech-Blau	Technische Analysen, Produktanalysen, Engineering-Praxis	Blaue Hervorhebungen, H2-Senkrechtbalken, dunkle Codeblöcke
growth Wachstums-Orange	Berufserfahrung, Wachstums-Rückschauen, Methoden	Warme Orange-Hervorhebungen, H2-Farbblöcke, größerer Zeilenabstand
minimal Minimalistisch Schwarz-Weiß	Meinungskommentare, tiefgehende Gedanken	Schwarz-Weiß, H2-Unterstriche
elegant Business-Marineblau	Markenartikel, formelle Veröffentlichungen, Branchenanalysen	Serifenschrift, marineblaue Hervorhebungen, H1-zentriert

Prinzip: Je härter der Inhalt, desto schlichter das Thema. Im Zweifelsfall tech verwenden.

Neue Themen können durch Hinzufügen einer JSON-Datei in scripts/themes/ erstellt werden; Feldbeschreibungen in references/layout-spec.md §13.

Befehlsübersicht

Befehl	Funktion	Wichtige Parameter
ingest.py <dateien...>	Material → strukturierter Text + zitierbare Satzkandidaten	-o Ausgabeverzeichnis, --json
md2wx.py <md>	Markdown → WeChat-HTML	--sheet Arbeitsmappe, --snapshot Schnappschuss, -t Thema, -o Ausgabe, --no-body, --check
md2wx.py --list-builds	Historische Builds anzeigen	--out-dir
md2wx.py --rollback <fingerprint>	Eine bestimmte Version von Artefakten wiederherstellen	--out-dir
cover.py	Titelbilder	--md liest automatisch Frontmatter, --style, --all; --title/--tag/--author/--theme zum Überschreiben
lint.py <md>	Schreibtisch-Tor + Artefakt-Versionsprüfung	--cards, --outline, --out, --json, --strict
check.py <md>	Prüfung vor Veröffentlichung	--html, --json, --strict; --title/--summary können Frontmatter überschreiben
preview.py <html>	Screenshot zur Layoutbestätigung	-o, --width, --height

Titel, Zusammenfassung, Autor, Thema werden standardmäßig aus dem Frontmatter gelesen; Befehlszeilenparameter dienen nur zur temporären Überschreibung.

--strict ist für CI/Automatisierung gedacht: Exit-Code ist 1 bei hohem Risiko.

Häufige Fallstricke (müssen bekannt sein)

Falle	Phänomen	Behandlung
Externe Links nicht anklickbar	https://... im Text reagiert nicht	In Textbeschreibung umwandeln oder unter „Originaltext lesen“ platzieren
Bildplatzhalter	Bilder von externen Domains werden als Platzhalter/graue Blöcke angezeigt	Manuell im Editor hochladen oder L3-Materialschnittstelle verwenden
Instabile Leerzeilen	Leerzeilen als Absatzabstand, clientseitig inkonsistent	margin für Abstand verwenden, md2wx.py behandelt dies bereits
Code-Zeilenumbruch	Langer Code wird automatisch umgebrochen, nicht lesbar	Einzelblock ≤30 Zeilen, bei Überlänge in Fragmente aufteilen
Tabelle überbreit	Tabelle mit 5+ Spalten horizontal scrollbar	Spaltenanzahl ≤4, sonst in zwei Tabellen aufteilen
Titel abgeschnitten	Newsfeed zeigt nur ca. 20 Zeichen an	Kurztitel-Version muss vorhanden sein
Ohne Titelbild nicht veröffentlichbar	Hauptbeitrag-Titelbild im Backend ist Pflichtfeld, Überspringen bedeutet Abgabe unmöglich	Vollständige Erstellung muss cover.py --all ausführen, vor Auslieferung mit lint --out --publish prüfen
Alte Version ausgeliefert	Artikel geändert, aber nicht neu gerendert, alte Version veröffentlicht	Vor Auslieferung lint --out out --strict ausführen; Fingerprint-Unterschiede stoppen den Vorgang

Referenzdokumente (nur bei Bedarf laden, nicht auf einmal lesen)

Dokument	Wann lesen
references/ingest.md	Schritt 0.5: Materialaufnahme, Extraktion von Materialkarten, Wiedergabetreue-Regeln, Bezugsgrößenkonflikte, Lückenliste
references/topic-expand.md	Schritt 1: Themenerweiterung, Argumentationsbaum, Disziplin gegen Wässerung
references/writing-playbook.md	Schritt 2~3: Titelformeln, Einleitungs-Haken, Strukturvorlagen, KI-Geruch entfernen
references/compliance.md	Schritt 6: Compliance-Wortliste, Verstoßarten, alternative Formulierungen
references/layout-spec.md	Wenn Layout angepasst, Themes hinzugefügt oder visuelle Probleme beurteilt werden müssen
references/api.md	Wenn der Benutzer die automatische L3-Veröffentlichung wünscht

Abhängigkeiten

Abhängigkeit	Verwendet für	Wenn nicht vorhanden
Python 3.9+	Alle Skripte	Zwingend erforderlich
Pillow	cover.py	Dieser Schritt für Titelbilder schlägt fehl, der Rest funktioniert
pypdf	ingest.py PDF-Parsing	Bereits in scripts/vendor gebündelt, keine separate Installation erforderlich
python-docx	ingest.py DOCX-Parsing	Bereits in scripts/vendor gebündelt, keine separate Installation erforderlich
python-pptx	ingest.py PPTX-Parsing	Bereits in scripts/vendor gebündelt, keine separate Installation erforderlich
chrome/chromium	preview.py Screenshot	Nur Screenshot-Schritt nicht verfügbar, andere Skripte laufen normal; HTML kann trotzdem manuell geöffnet werden