yuruyi-ling/douyin-image-check

TikTok (Douyin) Produkt-Hauptbild-Vorprüfung

Ziel: Bevor ein Händler Hauptbilder hochlädt, potenzielle Verstöße identifizieren, die zu Ablehnung, Traffic-Drosselung oder Bestrafung durch TikTok E-Commerce führen könnten. Die Begründung klar darlegen und eine direkt ersetzbare Formulierung anbieten.

Es gibt zwei wichtige Voraussetzungen, die man immer im Hinterkopf behalten und im Bericht dem Nutzer mitteilen sollte:

• Dies ist eine Vorprüfung, nicht die offizielle Plattformprüfung. Die Plattform entscheidet basierend auf dem gesamten Werbekontext, den tatsächlichen Produktparametern und den vom Händler vorgelegten Nachweisen. Derselbe Satz kann mit einem Prüfbericht konform sein, ohne jedoch als Verstoß gewertet werden. Daher hängen viele Schlussfolgerungen von der tatsächlichen Situation des Nutzers ab – diese muss man erfragen oder klar kennzeichnen.
• Regeln haben ein Datum. Die in diesem Skill zusammengestellten Regeln stammen vom 2026-11-07 (siehe rules-updated im Frontmatter). TikTok aktualisiert seine Regeln häufig. Bei Unsicherheiten oder Nutzerfragen gelten die aktuellsten Originaltexte im TikTok E-Commerce Learning Center (Link in references/sources.md).

Regeldateien

Nach Bedarf lesen, nicht alle auf einmal:

Datei	Wann lesen
references/main-image-rules.md	Immer lesen. Hauptbild-Spezifikationen, Anforderungen an das erste Bild, verbotene Darstellungen
references/claim-rules.md	Immer lesen. Textliche Verstöße: Wirkungsversprechen, Superlative, beweispflichtige Werbung, Preise, Abwerbung zu externen Seiten
references/cases.md	Immer lesen. Bestätigte Ablehnungsfälle, gleiche Schreibweise direkt als Referenz
references/private-cases.md	Lesen, wenn die Datei existiert. Vom Nutzer selbst gesammelte Ablehnungsfälle, nur lokal gespeichert
references/category-security-camera.md	Lesen, wenn das Produkt eine Kamera, Überwachungskamera oder Sicherheitsvorrichtung ist
references/category-template.md	Lesen, wenn für eine neue Kategorie Regeln erstellt werden sollen
references/sources.md	Wenn ein Link zu den Regelquellen benötigt wird oder der Nutzer nach der „Grundlage" fragt

Derzeit sind nur die spezifischen Regeln für die Kategorie Sicherheitsüberwachung erfasst. Für andere Kategorien zuerst mit den allgemeinen Regeln prüfen und im Bericht vermerken: „Spezifische Regeln für diese Kategorie wurden noch nicht erfasst." Dem Nutzer empfehlen, die aktuellsten Branchenmanagementstandards im Learning Center zu prüfen. Falls Sie online sind, können Sie anbieten, eine neue Kategorieregeldatet für den Nutzer zu erstellen.

Prüfablauf

1. Prüfobjekt klären

Aus dem Gespräch diese Informationen sammeln. Fehlendes mit Standardwerten ersetzen – nicht aufhören zu prüfen, nur weil etwas fehlt:

• Kategorie: Aus dem Bild ableiten. Falls nicht möglich, kurz nachfragen, aber gleichzeitig mit den allgemeinen Regeln prüfen.
• Bildnummer: Wenn der Nutzer keine Angabe macht, in der Reihenfolge des Erhalts prüfen. Bild 1 nach den Standards für das erste Bild prüfen. Die Anforderungen an das erste Bild sind am strengsten.
• Tatsächliche Produktparameter: Z.B. Auflösung und Pixel, Akkukapazität, ob ein Solarpanel enthalten ist, Konfiguration der einzelnen SKUs, Traffic- und Cloud-Speicher-Richtlinien, ob ein Prüfbericht vorliegt. Viele Aussagen sind nur dann ein Verstoß, wenn sie nicht der Realität entsprechen. Wenn der Nutzer keine Angaben macht, entsprechende Punkte mit 🟡 kennzeichnen und am Ende des Berichts unter „Zu bestätigen von dir" auflisten.
• Ist es das Originalbild? Bilder, die im Chat eingefügt werden, können komprimiert, beschnitten oder konvertiert sein. Schlussfolgerungen zu Größe, Seitenverhältnis oder Format, die nicht auf dem Originalbild basieren, auf ⚪ herunterstufen und den Nutzer darauf hinweisen, dass die beim Upload in den TikTok-Shop verwendeten Originalbilder maßgeblich sind.

2. Bild ansehen, Text vollständig auslesen

Bei jedem Bild drei Dinge tun:

1. Spezifikationen: Wenn Sie Befehle ausführen können, die tatsächlichen Pixelabmessungen und das Dateiformat mit einem beliebigen Tool auslesen. Falls nicht, überspringen und im Bericht „Originalbild-Spezifikationen nicht ausgelesen" vermerken.
2. Darstellung: Wo ist das Produkt? Wie viel Platz nimmt es ein? Ist es ein echtes Foto, ein Rendering oder ein KI-Bild? Gibt es QR-Codes, Wasserzeichen, Rahmen, Play-Buttons, Personen, Größenvergleichsobjekte, Karten, Logos anderer Marken oder Plattformen, sensible Elemente? Bei Effekt-Darstellungs- und Vergleichsbildern besonders darauf achten, ob es sich um echte Aufnahmen des Geräts handelt. Auch Symbole beachten – sie werden ebenfalls als Werbung gewertet (z.B. ein 4G-Kamera mit einem WiFi-Symbol).
3. Text: Den gesamten Text auf dem Bild Bereich für Bereich (oben links, Mitte, rechts, unterer Balken …) Wort für Wort abschreiben, einschließlich Beschriftungen, Kleingedrucktem und Texten neben Symbolen. Unleserliche Schrift als „[unleserlich]" notieren – nicht raten. Ein falsch geratenes Zeichen kann die Schlussfolgerung umkehren.

3. Regel für Regel prüfen

• Jede Aussage mit der claim-rules.md und der kategoriespezifischen Datei abgleichen.
• Darstellung und Spezifikationen jedes Bildes mit der main-image-rules.md abgleichen.
• Text-Bild-Abgleich: Ist die Werbeaussage mit den Abbildungen, Schritt-für-Schritt-Darstellungen und Parametertabellen im selben Bild konsistent? Z.B. „Bohrfrei" in großer Schrift, aber in der Montageanleitung werden Schrauben und Dübel verwendet.
• Bildübergreifender Abgleich: Ist die gleiche Aussage in verschiedenen Bildern konsistent? Ist die im Hauptbild dargestellte Konfiguration (z.B. „Dual-Kamera", „mit Solarpanel", „8000mAh") bei jedem SKU vorhanden? Fehlt sie beim günstigsten SKU, handelt es sich um einen Preisverstoß („Betrug mit günstigem SKU").
• Abgleich mit Fällen: Textstellen, die in cases.md oder private-cases.md bereits als abgelehnt dokumentiert sind, als 🔴 einstufen und mit „Ähnlich wie Fall XXX" kennzeichnen.

4. Einstufung

Einstufung nach „Härte der Grundlage", nicht nach „Schwere des Problems":

• 🔴 Klare Regelverstöße, wenn mindestens eine der folgenden Bedingungen erfüllt ist:
  • Der Wortlaut, die Schreibweise oder die Darstellung sind im Originaltext der Regel oder in offiziellen Beispielen explizit verboten.
  • Es werden absolute, garantierte Versprechen zu Wirkung, Leistung oder Service ohne Einschränkungen gemacht. Die „Richtlinie zu irreführender Werbung" 4.2 verbietet diese Kategorie explizit, z.B. „Nie wieder Stromausfall", „Keine toten Winkel", „100% Erkennung".
  • Die Abbildungen, Schritte oder Parameter im Bild beweisen, dass die Aussage nicht zutrifft.
  • Die Schreibweise ist identisch mit einem bereits bestätigten Ablehnungsfall.
• 🟡 Erfahrungsrisiko: Die Regel benennt es nicht explizit, aber es gehört zur gleichen Risikokategorie; oder ob es ein Verstoß ist, hängt davon ab, ob der Nutzer einen Nachweis vorlegen kann (Prüfbericht, Patentnummer, Genehmigung, Übereinstimmung der Parameter). Anmerken: „Mit Nachweis behaltbar, ohne Nachweis als 🔴 ändern."
• ⚪ Mögliche Fehleinschätzung: Unsichere Fälle, z.B. unleserliche Schrift, möglicherweise irrtümlich beanstandete branchenübliche Begriffe, Begriffe, die nur in inoffiziellen Wortlisten im Internet vorkommen, Spezifikationsschlussfolgerungen, die auf nicht originalen Bildern basieren.

Wenn ein Satz gleich mehrere Regeln verletzt, in einer Zeile zusammenfassen und alle Grundlagen nennen. Nicht normale Beschreibungen als Probleme darstellen, nur um vollständig zu wirken: Zu viele Fehlalarme führen dazu, dass der Nutzer die wirklich zu ändernden Stellen übersieht.

5. Verbesserungsvorschläge geben

Die Verbesserungsvorschläge müssen direkt kopiert und verwendet werden können. Die Richtung entspricht den Anforderungen der Plattform an die Händler: „Schreib, was es ist."

• Versprechen in Beschreibungen umwandeln, absolute Aussagen in konditionale Aussagen umwandeln. Z.B. aus „Nie wieder Stromausfall bei Regen" wird „8000mAh großer Akku, bei Regen vom Akku gespeist (Laufzeit wetter- und nutzungsabhängig)".
• Daten angeben, Daten und Testbedingungen nennen; wenn keine Daten vorliegen, dieses Verkaufsargument weglassen, nicht künstlich auffüllen.
• Inhalte, die einen Nachweis erfordern (Prüfbericht, Patent, Genehmigung, Auszeichnung), den Nutzer darauf hinweisen, den Nachweis in die Detailseite aufzunehmen.
• Die Hauptbilder können nur wenig Text aufnehmen. Die Verbesserungsvorschläge müssen kurz und für die Darstellung auf dem Bild geeignet sein.

Nicht vorschlagen, die Überprüfung mit Homophonen, Pinyin, Sonderzeichen, Worttrennungen, Verdeckungen oder Unschärfen zu umgehen. Die Plattformregeln besagen klar, dass solche Umgehungsmethoden zu einer verschärften Bestrafung führen. Auch nicht vorschlagen, „das Versprechen in großer Schrift und die Einschränkungen in kleinem Text in der Ecke" zu platzieren: Die Plattform hat in der Ankündigung zur Bekämpfung von Sicherheitskameras klargestellt, dass diese Schreibweise weiterhin als nicht konform gilt.

6. Bericht ausgeben

Der Bericht sollte so kurz wie möglich sein. Nutzer senden oft 5 oder mehr Bilder auf einmal – sie müssen ihn auf einen Blick erfassen können: Unabhängig von der Anzahl der Bilder sollte der Bericht etwa 15 Zeilen umfassen.

• Nach Problem zusammenfassen, nicht nach Bild aufschlüsseln. Jedes Problem nur einmal schreiben und kennzeichnen, in welchen Bildern es auftritt, z.B. „(Bild 1, 4)".
• Jedes Problem in einer Zeile mit festem Format: „Originaltext" (Bildnummer) → Ändern in | Grund (Kurzbezeichnung der Regel). Grund nicht länger als 10 Zeichen.
• 🔴 Alle auflisten. 🟡 Maximal 5 auflisten, sortiert nach Auswirkung: Zuerst das, was zur Sperrung des Produkts führen kann (gesetzlich verboten, Abwerbung), dann irreführende Werbung, zuletzt das, was nur die Konformität oder den Traffic beeinträchtigt. Probleme gleicher Art zusammenfassen, z.B. mehrere Stellen, die „Prüfbericht erforderlich" sind; nicht Passendes in einer Zeile zusammenfassen: „Weitere N leichtere Fälle: …"
• ⚪ In einer Zeile zusammenfassen.
• Zu bestätigen von dir maximal 4 Punkte, die die Schlussfolgerung am stärksten beeinflussen, in einer Zeile.
• Nicht schreiben: was in Ordnung ist, den vollständigen Text auf dem Bild, die Spezifikationen jedes Bildes. Unleserliche Schrift und Spezifikationsprobleme in ⚪ einordnen. Wenn gar keine Probleme vorliegen, nur „Keine Probleme festgestellt" schreiben.
• Wenn der Nutzer detaillierte Aufstellungen für jedes Bild und jeden Punkt oder den erkannten Volltext wünscht, separat ausgeben oder als CSV exportieren (siehe Schritt 7).

Vorlage:

## Hauptbild-Prüfung: N Bilder｜🔴 X｜🟡 X｜⚪ X

**🔴 Muss geändert werden**
1. „365 Tage im Jahr, nie wieder Stromausfall" (Bild 1, 3) → Solarpanel + 8000mAh Akku Dual-Versorgung | Garantieversprechen (Irreführende Werbung 4.2)
2. …

**🟡 Sollte geändert werden**
- „Hocheffiziente Umwandlung", „Schnellladung" (Bild 1, 2) → Solarpanelleistung angeben, sonst löschen | Keine Daten, übertrieben (Irreführende Werbung 4.2)
- Weitere 2 leichtere Fälle: „Keine Angst vor Wind und Regen", Hauptbildtext etwas viel

**⚪ Bitte prüfen**: Bild 3 „Bei Regen nie wieder [unleserlich]" vermutlich Tippfehler; 4 Bilder sind WEBP, Originalbild maßgeblich

**Zu bestätigen von dir** : Akkukapazität und gemessene Laufzeit, Solarpanelleistung, ob jedes SKU ein Solarpanel enthält

> Vorprüfungsergebnis, nicht offizielle Plattformprüfung; Regeln Stand 2026-11-07.

Als Grundlage die folgende Kurzbezeichnung verwenden. Bei Rückfragen des Nutzers den vollständigen Namen nennen, Original-Link in der sources.md:

Kurzbezeichnung	Vollständiger Regelname
Irreführende Werbung 4.1 / 4.2 / 4.3	„Richtlinie zu irreführender Werbung"
Hauptbildnorm	„Veröffentlichungsnorm für Produkthauptbilder"
Preisverstoß	„Behandlungsrichtlinie zu Preisverstößen"
Abwerbung	„Behandlungsrichtlinie zu Lockvogel für Dritte"
Gesetzlich verboten	„Behandlungsrichtlinie zur Veröffentlichung gesetzlich verbotener Waren/Informationen"
Sicherheitsankündigung	„Spezielle Bekämpfungsankündigung für Sicherheitskameras"
Branchennorm	„Branchenmanagementnorm für Haushaltsgeräte und Elektrogeräte" oder „Branchenmanagementnorm für 3C-Digitalgeräte"
Fall XXX	Fall in cases.md oder private-cases.md

7. CSV-Detailübersicht exportieren

CSV in zwei Fällen exportieren: 1. Batch-Prüfung (gleichzeitige Prüfung mehrerer Produkte oder des gesamten Ordners des Nutzers); 2. Der Nutzer möchte eine detaillierte Aufstellung für jedes Bild und jeden Punkt. Der Bericht im Gespräch bleibt kurz, die vollständige Detailübersicht in der CSV-Datei, damit der Nutzer die Änderungen in Excel verteilen kann:

• Dateiname Hauptbildprüfung_YYYYMMDD_HHMM.csv, im Ordner mit den Bildern speichern; bei Unsicherheit im aktuellen Arbeitsverzeichnis. Nach Fertigstellung den vollständigen Pfad mitteilen.
• Kodierung UTF-8, am Dateianfang ein BOM (U+FEFF) hinzufügen. Ohne BOM wird Chinesisch in Excel nicht korrekt angezeigt.
• Erste Zeile ist die Kopfzeile: Produkt,Bilddatei,Bildnummer,Stufe,Originaltext oder Darstellung,Position,Problem,Grundlage,Vorschlag zur Änderung
• Jedes Problem in einer Zeile. Auch für Bilder ohne Problem eine Zeile mit Stufe „Bestanden", um zu überprüfen, ob keines übersehen wurde.
• Wenn ein Feld Kommas, doppelte Anführungszeichen oder Zeilenumbrüche enthält, das gesamte Feld in doppelte Anführungszeichen setzen; doppelte Anführungszeichen im Feld durch zwei doppelte Anführungszeichen ersetzen.

In Umgebungen, in denen keine Dateien erstellt werden können, den CSV-Inhalt in einen Codeblock setzen und den Nutzer bitten, die Datei selbst als .csv zu speichern.

8. Ablehnungsfälle dokumentieren, um die Prüfung immer genauer zu machen

Wenn der Nutzer ein abgelehntes Hauptbild und den Ablehnungsgrund schickt:

1. Nach obigem Ablauf prüfen und den Satz oder die Darstellung identifizieren, der/die am wahrscheinlichsten den Verstoß ausgelöst hat. Die Ablehnungsbenachrichtigung nennt meist nur Beispiele, nicht den genauen Satz – daher muss erklärt werden, dass es sich um eine Schlussfolgerung handelt.
2. Diesen Fall an die references/private-cases.md anhängen. Wenn die Datei nicht existiert, neu erstellen, erste Zeile: „Lokale private Fälle, nicht in das öffentliche Repository einchecken." Format wie in der Vorlage in references/cases.md. Shop-Name, Produkt-Link, Bestellnummer helfen nicht bei der Beurteilung, daher nicht notieren.
3. Dem Nutzer mitteilen, dass der Fall notiert wurde und was notiert wurde.
4. In Umgebungen, in denen keine Dateien erstellt werden können, den aufbereiteten Fall an den Nutzer ausgeben und bitten, ihn selbst zu speichern.

private-cases.md wurde bereits in .gitignore aufgenommen und wird nicht mit dem Repository veröffentlicht. Wenn der Nutzer einen Fall mit anderen teilen möchte, darauf hinweisen, zuerst alle identifizierenden Informationen zum Shop zu entfernen, bevor er in cases.md verschoben wird.