100x-搜索查询

Was macht 100x-搜索查询?

Einleitung

Gib ein Produkt-/Persona-Blatt ein und erhalte 15 englische Suchphrasen pro Plattform (Pinterest / TikTok / Reddit), um visuelle Referenzen, Inspirationsbilder und vergleichbare Inhalte zu finden. Gehört zur 100x-Systemebene L2 (Creative Generation) und entspricht dem Schritt „Suchbegriffe finden“.

Wann wird es ausgelöst

Der Benutzer sagt:

• „Hilf mir, Referenzbilder zu finden“ / „Finde Inspirationsbilder“ / „Wo finde ich Referenzbilder?“ / „Gib mir Suchbegriffe“
• „what should I search on Pinterest“ / „find reference images“
• „need TikTok/Reddit search terms for this product“
• Oder gibt direkt ein Produkt-/Persona-Blatt an und fordert eine Reihe von Suchbegriffen an.

Eingabe

Minimaleingabe (Kategorie A, zwingend erforderlich): category (Kategorie, Freitext, z. B. „Gesundheitsprodukte“ / „Haushalt“ / „Kosmetik & Körperpflege“; siehe auch zukünftige taxonomies/, keine kundenspezifischen Kategorie-Wörterbücher verwenden). product_name ist keine vom Benutzer zwingend bereitzustellende Eingabe – wenn kein konkreter Marken-/Produktname vorliegt, verwende als Platzhalter "[Kategorieanker] <category>" und fahre fort (schema.json verlangt, dass product_name in der Ausgabe ein nicht leerer String ist – das ist eine „Erfüllungsbedingung des Ausgabevertrags“, nicht „Erfüllungsbedingung der Benutzereingabe“; beides ist nicht identisch). Siehe workflow.md Phase 1, Kategorie-A-Validierung.

Optionale Ergänzungen (Kategorie B, bei Fehlen dreistufige Degradierung, siehe workflow.md Phase 1): core_benefit, target_audience, brand_tone, topic_angle (einer von default/aesthetic/pain-driven/sales-push).

Optionale Upstream-Outputs (Kategorie C, bei Fehlen stillschweigend übersprungen, blockieren nicht und erfordern nicht, dass der Benutzer zuerst andere Skills ausführt): Persona-Blatt, Insight-Ergebnisse, Erfolgsfaktor-Ergebnisse. Sofern bereitgestellt, müssen sie die Generierung tatsächlich beeinflussen – in Phase 2C müssen mindestens 6 Ergebnisse die spezifische Zielgruppe/Identitätsperspektive aus dem Persona-Blatt widerspiegeln; es reicht nicht, das Blatt nur entgegenzunehmen, aber die Ausgabe bleibt identisch. Siehe workflow.md Phase 1, Schritt 4 / entsprechenden Abschnitt in Phase 2.

Ausgabe

Struktur gemäß schema.json: queries.pinterest/tiktok/reddit mit je 15 Einträgen {q, intent_cn, stage}, meta.based_on_5a deklariert die 5A-Abdeckung. Wenn Kategorie-C-Eingaben (Persona/Insight) vorliegen, muss meta.persona_informed auf true gesetzt sein und meta.persona_descriptor_terms muss die aus dem Blatt extrahierten spezifischen Zielgruppen-/Identitätsbegriffe auflisten – andernfalls gilt die Ausgabe als nicht konform (Axiom 5); wenn keine Kategorie-C-Eingaben vorliegen, können beide Felder weggelassen werden. Optional können 3 Markdown-Tabellen (eine pro Plattform) mit den Spalten # / query / search_intent_cn / 5a_stage gerendert werden.

Kernbeschränkungen (5 Axiome, siehe axioms.md)

1. Pro Plattform genau 15 Einträge, alle in englischem ASCII. Fehlt einer oder es ist Chinesisch enthalten → ungültig.
2. Plattformdifferenzierung zwingend: Pinterest-ästhetische Begriffe / TikTok-Hashtags + Memschlagwörter / Reddit-Schmerzpunktfragen. Vertauschung ungültig.
3. Generierung basierend auf 5A-Intent-Layering. meta.based_on_5a muss zwingend ausgefüllt sein; 45 Einträge decken ≥ 3 Phasen ab.
4. Jeder Eintrag muss eine chinesische Suchintent-Erläuterung von ≤ 20 Zeichen enthalten. Format: „[Geschlossener Kategorielabel] + reine chinesische Erläuterung“ (bekannte Einschränkung: Dies ist eine Formatsvalidierung, die „komplette Sätze aus der englischen Übersetzung kopieren“ verhindert, aber nicht den subtileren Fall „legitimes Label, aber Inhalt immer noch wörtliche Übersetzung“ abdeckt – z. B. könnte eine wörtliche Übersetzung mit einem „Frage:“-Präfix versehen und bestehen. Dies ist eine bekannte semantische Lücke, keine Garantie gegen wörtliche Übersetzung – siehe axioms.md, Axiom 4, TODO).
5. Wenn Persona/Insight-Eingaben vorliegen, müssen sie in der Ausgabe sichtbar sein: Bei persona_informed=true müssen mindestens 6 der 45 Einträge die in persona_descriptor_terms deklarierten spezifischen Zielgruppen-/Identitätsbegriffe treffen – andernfalls ungültig (bekannte Einschränkung: Der Wortlisten-Check verhindert nicht, dass „einige zu breite Begriffe ausgewählt werden, um die Mindestanzahl zu erfüllen“, er verhindert nur „keine Verwendung“ – siehe axioms.md, Axiom 5).

Grenze (ausnahmslos): Unabhängig von der Quellsprache des Produkttexts (Englisch, Spanisch und andere mehrsprachige Eingaben werden unterstützt) sind die Suchbegriffe immer auf Englisch – dies ist eine direkte Ableitung aus Axiom 1, keine zusätzliche Einschränkung. Es gibt keine nicht-englische Ausgabeoption: Die Ausgabe unterliegt der strengen ASCII-Validierung gemäß schema.json. Es gibt keinen Zweig für nicht-englische Ausgaben.

Dreiphasiger Ablauf

Siehe workflow.md: Phase 1 (Empfang + Validierung Kategorien A/B/C) → Phase 2 (5A-Zuordnung → Plattform-Bucket-Generierung → Einzelprüfung → Batch-Prüfung) → Phase 3 (Benutzerinitiierte Nacharbeit: L1 Einzeleintrag / L2 Einzelbucket / L3 Gesamt; kein L4 – Axiom 1 macht keine Ausnahme für nicht-englische Ausgaben, siehe oben „Grenze“).

Garantie für eigenständigen Aufruf

Fehlt Kategorie A (d. h. category fehlt – fehlender konkreter Markenname bei product_name gilt nicht als Kategorie-A-Fehler, siehe „Eingabe“ oben) → Feste Rückfrage, keine Annahmen oder Erfindungen. Es wird niemals verlangt, dass der Benutzer „erst andere Skills ausführt“. Fehlt Kategorie B → Dreistufige Degradierung (vollständig → eine Rückfrage → Inline-Schätzung + Hinweis in meta.warnings). Fehlt Kategorie C → Stillschweigend übersprungen.

Verbotene Begriffe

Lass mich / ich hoffe / vielleicht / wahrscheinlich / möglicherweise / eventuell / lass uns; KI-Kundendienst-Ton (as an AI / I'd be happy to / feel free to); wirkungslose ästhetische Begriffe attractive/beautiful/stunning/serene/pristine/elegant/cinematic/professional/studio/flawless; keine erfundenen Subreddits (dieses Skill fügt standardmäßig kein r/xxx-Präfix hinzu, siehe axioms.md TODO); keine erfundenen Ergebnisse/Zertifizierungen/Kundenberichte.

Erkennung von Signalen sensibler Kategorien (Inhaltspolicy-Wall, bekannte Einschränkungen, kein Axiom)

Dieses Skill scannt category/product_name sowie alle generierten q/intent_cn-Felder. Wenn gleichzeitig ein „Signal einer sensiblen Kategorie“ (z. B. Begriffe zu sexueller Gesundheit/Intimpflege und deren Synonyme/euphemistische Formulierungen) und ein „Signal einer Autoritätsbehauptung“ (z. B. erfundene FDA/Arzt/Experten-Zertifizierungsbegriffe und deren Synonyme) erkannt werden, wird die Generierung nicht abgelehnt, aber es wird zwingend ein fester Warnhinweis in das meta.warnings-Feld der Ausgabe eingefügt. Die Kriterien finden sich in workflow.md Phase 1, Schritt 6, die Signalwortliste in scripts/validate.js.

Bekannte Einschränkungen (ehrlich dargelegt, nicht „vollständig gelöst“): Dies ist eine feste Schlüsselwortlisten-Prüfung, keine semantische Prüfung, und hat von Natur aus zwei Einschränkungen: ① Die Liste deckt nur gängige Synonyme/euphemistische Formulierungen ab; neu erfundene Begriffe oder Umschreibungen, die nicht in der Liste enthalten sind, können umgangen werden. ② Es können nur die Felder gescannt werden, die im endgültigen JSON-Output vorhanden sind (category/product_name/alle q/alle intent_cn); der vollständige Original-Eingabetext, der in Phase 1 gelesen wurde und nicht in diese Felder eingeflossen ist, bleibt unsichtbar. Entwurfshinweis: Der Scanbereich für beide Signale ist vereinheitlicht und umfasst alle Textfelder (category/product_name sowie alle generierten q und intent_cn-Texte). Die Wortliste wurde um gängige Synonyme erweitert (dies verkleinert die Lücke, schließt sie aber nicht). Es kann nicht behauptet werden, „durch Tabellenerweiterung die Lücke zu schließen“ – für eine stärkere Garantie wäre eine semantische Erkennung erforderlich, was dasselbe Problem ist wie das „Formatsperre vs. Semantiksperre“-Problem in Axiom 4, TODO.

Routing (Empfehlung, keine zwingende Abhängigkeit)

• Vorhandenes Produkt, aber fehlende Kategorie/Leistungsprofil → Skill für Persona/Profil (falls vorhanden)
• Gefundene Referenzen in Generierungsprompts umwandeln → Prompt-Assemblierungs-Skill (falls vorhanden)
• Mediensplitting statt Referenzsuche → Skill für visuelles Splitting (falls vorhanden)
• Zurück zum Haupteinstieg für Neusortierung → 100x-System-Haupteinstieg (falls vorhanden)

Alle oben genannten Punkte sind „optionale Empfehlungen nach der Ausgabe“, keine Voraussetzungen. Wenn die entsprechenden Skills noch nicht erstellt sind, hat dies keine Auswirkungen auf die eigenständige Arbeit dieses Skills.

Werksinterne Selbstprüfung

Führe node scripts/validate.js --selftest zur Validierung aus. Axiom 2/3 sind plattformübergreifende Aggregationsregeln, die in schema.json (Vanilla JSON Schema) nicht darstellbar sind; die tatsächliche Durchsetzung erfolgt durch scripts/validate.js:

node scripts/validate.js <bundle.json> [bundle2.json ...]   # Validierung der Ausgabe
node scripts/validate.js --selftest                          # Ausführung der integrierten Regressionstests

Quellen

Die Methodik dieses Skills basiert auf dem Suchmethodik-Framework für Inspiration. Es verwendet ein eigenständiges Design (enthält axioms.md, workflow.md, sources.md, schema.json und Validierungsskripte), ist unabhängig von externen privaten Pfaden und enthält keine privaten Daten. Eine detaillierte Entwicklungsbeschreibung findet sich in sources.md.