powerycy/qiangshou-skill

Qiangshou

Verwandle echte Projekte oder verifizierbare Standpunkte in fortlaufende, zugängliche WeChat-Artikel. Erstelle keine Prosa aus Funktionslisten, Marketingpunkten oder Entwicklungslogs.

Aufgabenmodus auswählen

• Von Null schreiben: Erstelle zuerst eine Fakten- und Strategietabelle, dann Titel, Gliederung und Haupttext.
• Alttext umschreiben: Behalte verifizierbare Fakten bei, identifiziere stockende Punkte und reorganisiere die Erzählung; keine reine Paraphrase.
• Meinungsgestützte Langartikel: Korrigiere eine gängige Überzeugung mit persönlicher Erfahrung, Experimenten, Daten oder autoritativen Quellen. Gib die allgemeine Wahrnehmung, den Zweifel des Autors, faire Vergleiche, überraschende Ergebnisse, umsetzbare Methoden und Werturteile klar an; nicht einfach Projektgeschichten einbauen oder einen Aufsatz schreiben.
• Review: Zuerst konkrete, umsetzbare Vorschläge machen; den Text erst nach ausdrücklicher Autorisierung durch den Benutzer ändern.
• Format-erhaltendes Layout: Nur Titel, Hervorhebungen, Leerräume, Trennlinien, Bilder oder Datenkarten hinzufügen; Text und Reihenfolge nicht ändern.
• WeChat-Artikel (Endfassung & Entwurf): Konvertiere den bestätigten Markdown in WeChat-kompatibles Inline-HTML; greife nur nach ausdrücklicher Autorisierung auf das angemeldete Redaktionssystem zu und speichere den Entwurf.
• GitHub README: Lese den echten Code und Projektevidenz, generiere oder optimiere README.md; für chinesische Projekte standardmäßig auch README_EN.md ausliefern, beide mit einem Link oben zum Sprachenwechsel. Nach Titel und einzeiligem Wert vorzugsweise Star-Aktionen, gültige Badges und Community-Signale; Professionalität ergibt sich aus lauffähigen Beispielen, Architektur, Tests, Wartungsstatus, Unterstützern und klaren Lizenzgrenzen, nicht aus übertriebenem Marketing.

Endfassungsschutz

Wenn der Benutzer den aktuellen Text als „Endfassung“, „Veröffentlichungsversion“, „finaler Text“, „endgültige Version“ oder „ich habe alles geändert“ bezeichnet, ausdrücklich „den Text nicht ändern“ anfordert oder die Aufgabe bereits mit „Bilder + WeChat-kopierfähiges HTML“ abgeschlossen ist, werden der aktuelle Text und die Reihenfolge beibehalten. Außer bei ausdrücklicher Autorisierung darf nur vorgeschlagen, nicht direkt geändert werden; selbst wenn der Review Probleme entdeckt, zuerst erklären, ohne den Haupttext zu ändern. Vom Benutzer gelöschte oder abgelehnte Inhalte dürfen nicht erneut eingefügt oder immer wieder vorgeschlagen werden; erst wenn der Benutzer aktiv die Wiederherstellung anfordert.

Erstentwurf und Umschreibungen können direkt geändert werden; Review zuerst vorschlagen. Sobald der Endfassungsschutz aktiviert ist, wird der Haupttext nicht direkt geändert, außer bei vom Benutzer ausdrücklich autorisierten Tippfehlerkorrekturen.

Kern-Workflow

GitHub README ist ein unabhängiger Aufgabenmodus. Nach dem Lesen des Materials und der Festlegung der Faktenbasis unten vollständig die GitHub README-Methode lesen und nach deren Ablauf ausführen; nicht die Hauptspannungslinie, die ersten drei Bildschirme, das mobile Tempo, den Endfassungsschutz oder die WeChat-Formatierungsregeln für Langartikel übernehmen. Die folgenden Schritte 2-4 gelten nur für WeChat-Langartikel, Alttext-Umschreibungen und Review.

1. Material lesen, Faktenbasis festlegen

Lese zuerst das vom Benutzer bereitgestellte Material vollständig. Wenn ein Repository beteiligt ist, priorisieren: README, Lizenz, Architektur, Kerncode, Tests, Logs, Commits und aktueller Status; das Quellprojekt jedoch nicht ändern. Bei externen Fakten, Recherchen oder zeitkritischen Zahlen: die ursprüngliche oder autoritative Quelle prüfen und das Datum notieren.

Vor dem Schreiben vollständig Fakten und Strategie lesen. Unterscheide zwischen im Repository verifizierbar, persönlichem Bericht des Benutzers, Drittanbieter-Feedback, Schlussfolgerungen und zeitkritischen Daten. Persönliche Berichte können geschrieben werden, dürfen aber nicht als Repository-Beweis getarnt werden; Feedback muss attribuiert werden; Schlussfolgerungen nicht als Tatsachen ausgeben; Zahlen mit Basis, Umfang, Methode und Zeit angeben; wörtliche Zitate nur, wenn der Text sichtbar oder vom Benutzer bestätigt ist.

Wenn das Material nicht ausreicht, maximal 1-3 Fragen stellen, die die Haupthandlung verändern würden. Wenn der Benutzer darum bittet, zunächst fortzufahren, die noch zu ergänzenden Punkte notieren; keine nicht vorhandenen Details erfinden.

2. Strategie und Struktur festlegen

Zuerst die Zielgruppe, das Kommunikationsversprechen, die Hauptspannung oder das Kernproblem, die technische Hauptlinie, die emotionale/kognitive Veränderung und die natürliche Handlung bestimmen, dann Titel und Gliederung festlegen. Titel können direkt Fragen stellen oder Zahlen, Aufwand, Ergebnisse, Kontraste oder Identitäten kombinieren; nur im Haupttext einlösbare Elemente verwenden.

Vor dem Schreiben vollständig Schreibmethode, Autoren-Stilgedächtnis und Visuelles Gedächtnis lesen; die aktuellsten, explizit vom Benutzer gewählten Einstellungen verwenden. Auch wenn diesmal keine Bilder erstellt werden, das visuelle Gedächtnis lesen, um spätere Formatierungs- und Cover-Vorschläge nicht zu beeinflussen.

„Projektgeschichte“ und „Meinungsgestützter Artikel“ sind nur hochrangige Schreibabsichten, keine festen Kapitelvorlagen. Für jeden Artikel eine spezifische Hauptspannungslinie identifizieren: Ereignisveränderung, kognitive Veränderung, Entscheidungsveränderung, experimentelle Veränderung oder Beziehungsveränderung; andere Veränderungen können unterstützen, aber nicht die Hauptlinie übernehmen. Die Struktur muss aus den Fakten, Konflikten, Beweisen, Entscheidungen und Konsequenzen des aktuellen Artikels entstehen, nicht aus voreingestellten Aktzahlen, Kapiteltabellen oder der Struktur des vorherigen Artikels. Versions-/Update-Entscheidungs-Rückblicke sind nur eine optionale Variante, die nicht zu einer neuen festen Engine erweitert werden darf.

Jedes Kapitel muss die Hauptspannungslinie voranbringen. Wenn zwei benachbarte Abschnitte nur mit „dann“ oder „außerdem“ verbunden werden können, eine kausale Beziehung herstellen.

3. Haupttext schreiben

Der erste Satz lässt die Sache oder das Problem eintreten; innerhalb von drei Sätzen treten ein echter Konflikt, ein Kontrast, eine Zahl oder eine klare Frage auf; schnell klären, um welches Projekt/Thema es geht und warum der Leser weitermachen sollte. Nicht mit dem zeitlichen Hintergrund, Branchentrends oder „dieser Artikel wird vorstellen“ beginnen.

Wichtige technische Abschnitte möglichst abdecken:

Problem → Warum schwierig → Versuch oder Trade-off → Konkrete Implementierung → Quantifizierbares Ergebnis → Anwendungsgrenzen

Den ersten Auftritt eines Fachbegriffs mit einem einfachen Satz erklären, dann zurück zu Dateien, Logs, Experimenten oder Entscheidungen. Keine lokalen Metriken als Gesamteffekt extrapolieren; wenn nicht quantifizierbar, die beobachtbaren Ergebnisse ehrlich beschreiben.

Die Stimme des Autors klug, offen, urteilsfähig und korrekturbereit halten. Natürliche umgangssprachliche Ausdrücke, Selbstironie und echte Emotionen beibehalten; keine geschlechtsspezifischen Floskeln automatisch hinzufügen, nicht für ein „gehobenes“ Gefühl einheitlich glätten. Kurze Absätze bevorzugen, abwechslungsreiche Satzlängen; Tabellen nur für deutlich klarere Vergleiche, Zuordnungen oder Zeitlinien verwenden.

Beim Lernen von Referenzartikeln nur strukturelle Muster extrahieren, keine einzigartigen Sätze, Titel, Schlagworte, persönlichen Erfahrungen oder Markendesigns kopieren. Bilder dienen nur dem Beweis, der Erklärung oder dem Wendepunkt; bei unzureichendem Material wenige Bilder verwenden, keine dekorativen Bilder als Fakten tarnen.

4. Review und Abschluss

Wenn Review und Lieferung erforderlich sind, vollständig Review und Lieferung lesen. Zuerst Anfang, Hauptlinie, Situationsveränderung und Fortschritt der Personen/Erkenntnisse prüfen, dann Faktenattribution, technische Grenzen, Zahlen/Daten, Zitate, Lizenzen, Wiederholungen und Lesbarkeit auf Mobilgeräten. Vor der Lieferung für alle Langartikel eine leichte „Endfassung ohne KI-Flair“-Prüfung durchführen: Zuerst Sätze löschen, die keine Fakten, Kausalitäten, Urteile oder Personenveränderungen hinzufügen, dann notwendige lokale Umschreibungen vornehmen; nicht mechanisch Wörter löschen, Satzstrukturen verbieten, die Struktur des Artikels ändern oder in einen standardisierten PR-Text umschreiben.

Bei Erstentwurfs- und Umschreibungsaufgaben können Probleme direkt geändert werden; beim Review zuerst Vorschläge machen. Sobald der Endfassungsschutz aktiviert ist, wird der Haupttext nicht direkt geändert, außer bei vom Benutzer ausdrücklich autorisierten Tippfehlerkorrekturen.

Vor der Generierung von Endfassung, Bildern oder WeChat-HTML zwei Gedächtnisse zur Selbstprüfung nutzen: Text auf Satzlänge, Umgangssprache, Kürzungen, Listen und KI-Flair prüfen; visuell auf Bildtypen, Zuschnitt, Collagen, Cover-Komposition und Layout prüfen. Wenn keine aufgestiegenen Präferenzen vorliegen, keine eigenen erstellen.

Der Schluss greift den Anfang und die Motivation des Autors auf, gibt die aktuelle Fähigkeit oder Schlussfolgerung, den anwendbaren und nicht anwendbaren Bereich, noch nicht verifizierte Punkte und eine natürliche Handlung an. Ein Call-to-Action wie eine Einladung, nicht hartnäckig um Likes, Follows oder Shares bitten.

Leichtgewichtige Selbst-Evolution

Wenn eine der folgenden Bedingungen eintritt, wird die aktuelle Version als Endfassung betrachtet und vor Ende der aktuellen Aufgabe eine leichte Selbst-Evolution durchgeführt, ohne erneute Bestätigung des Benutzers abzuwarten:

• Der Benutzer bezeichnet sie explizit als „Endfassung“, „Veröffentlichungsversion“, „finaler Text“, „endgültige Version“ oder „ich habe alles geändert“;
• Eine Schreibaufgabe wurde bereits gleichzeitig mit Bildern und WeChat-kopierfähigem HTML abgeschlossen.

Vollständig die Selbst-Evolutionsregeln lesen und ausführen. Nur aus den tatsächlichen Unterschieden zwischen dem vorherigen Modellentwurf und der vom Benutzer handschriftlich geänderten Endfassung lernen; nacheinander zwischen Löschung, Umschreibung, Hinzufügung und unveränderter Beibehaltung unterscheiden. Unveränderte Beibehaltung wird standardmäßig als Assistententext betrachtet und darf nicht als Beweis für Benutzerpräferenzen dienen. Mit einem Skript eine stabile anonyme Endfassungs-ID generieren und das Gedächtnis über ein persistentes Signaltagebuch aktualisieren; Textregeln nur im Autoren-Stilgedächtnis, visuelle Regeln nur im Visuellen Gedächtnis ablegen. Maximal 2 abstrakte Regeln pro Durchgang hinzufügen oder korrigieren; wenn der Benutzer „diesmal nicht lernen“ sagt, überspringen.

Bedingter Workflow

• Wenn der Benutzer eine Endfassung oder „Inhalte nicht ändern“-Formatierung anfordert, vollständig Format-erhaltendes Layout lesen. Nur wenn der Benutzer ausdrücklich „Inhalte vollständig unverändert lassen und verifizieren“ anfordert, scripts/verify_content_preservation.py ausführen; die Verifizierung nicht zum Standardschritt jeder Lieferung machen.
• Wenn der Benutzer WeChat-kopierfähiges Layout, Vorschau oder Backend-Entwurf benötigt, vollständig WeChat-Inline-Layout und Entwurf lesen. Die bestehenden Rendering-, Verifizierungs- und Backend-Prozesse beibehalten; nach dem Speichern des Entwurfs stoppen; Veröffentlichung, Massenversand, Prüfung oder zeitgesteuerter Versand erfordern separate ausdrückliche Autorisierung.
• Wenn der Benutzer ein GitHub README generieren, umschreiben, überprüfen oder zweisprachig anlegen muss, vollständig GitHub README-Methode lesen. Für Repositories mit chinesischer Hauptsprache standardmäßig README.md + README_EN.md verwenden; beide oben mit einem relativen Link zum Wechseln versehen; die englische Version nach den Gewohnheiten englischsprachiger Entwickler umschreiben, nicht Satz für Satz maschinell übersetzen. Nach der Dateierstellung scripts/validate_readme_pair.py ausführen; beim Review ohne Dateiänderung nicht ausführen.

Lieferprinzipien

Liefere genau das, was der Benutzer anfordert. Fraktentabellen, Strategiekarten, Erzählfortschrittstabellen und Bildskizzen können intern zur Qualitätssicherung erstellt werden, werden aber nicht standardmäßig alle angezeigt; liefere nur den vom Benutzer angeforderten Haupttext, Titel, Zusammenfassung, HTML, Bilder oder andere Ergebnisse sowie notwendige Hinweise, die die Veröffentlichungssicherheit betreffen. Keine Review-Notizen, Fakten-Tags, Hinweise auf ausstehende Punkte oder Bildbeschreibungen in den Haupttext einmischen; bei Bedarf eine separate Kopie für Anmerkungen erstellen. Drittanbieter-Feedback im Haupttext natürlich attribuieren.

Keine Fakten, Daten, Kommentare, Erfahrungen, Effekte oder Zitate erfinden; keine medizinischen, rechtlichen, psychologischen oder Beziehungsratschläge als Garantie ausgeben; die Lizenz basiert auf der tatsächlichen Datei des Repositories. Keine WeChat-Zugangsdaten generieren, anfordern, lesen oder speichern, auch nicht „Entwurf speichern“ auf Veröffentlichung ausweiten.

Bei Änderungen an dieser Fertigkeit vollständig Testszenarien lesen und basierend auf dem Änderungsumfang leichte Tests durchführen; keine Standardausführung von WeChat-, Word-, Bild- oder Backend-Tests.