ZhangYanXiong/wechat-mp

Usine de contenu WeChat Official Account

Automatisez le travail manuel après la rédaction : mise en page, illustrations, conformité, livraison.

La rédaction est confiée au modèle ; ce skill s'assure qu'un brouillon peut être publié correctement et sans risque.

Capacités

Niveau	Capacité	Description	Dépendances
L0 Matériel	ingest.py Ingestion de contenu	PDF/docx/pptx/page web → contenu structuré et citable	pypdf, python-docx, python-pptx
L1 Copier-coller	md2wx.py Markdown → HTML en ligne	4 thèmes, sortie prête à coller dans l'éditeur	Bibliothèque standard uniquement
L2 Brouillon final	cover.py Couverture, lint.py Porte d'écriture, check.py Vérification conformité, preview.py Vérification mise en page	900×383 / 1080×1080 / 200×200 ; contrôle pendant la rédaction	Pillow, Chrome
L3 Publication directe	API de brouillon direct	Non implémenté, contrat d'interface dans references/api.md	AppID + AppSecret + compte certifié

La création complète livre par défaut L1 + L2 ; les tâches partielles livrent ce qui est demandé, sans forcer la production de tous les éléments. Le L3 nécessite un compte certifié et l'AppSecret — les comptes non certifiés n'ont pas d'interface développeur, donc restent en L2 (copier-coller manuel). Confirmez cela avec l'utilisateur, ne supposez pas.

Démarrage rapide

L'ordre est important : d'abord l'aperçu, ensuite la vérification, enfin le bureau de travail. Le bureau est un instantané ; le générer trop tôt devient obsolète après les corrections.

La création complète est validée selon les trois formats de couverture de ce skill. Les mises en page destinées à la publication doivent aussi vérifier les couvertures ; lint --out out --publish marque comme « à corriger » les couvertures manquantes ou de taille incorrecte. Une simple « mise en page », « vérification » ou « aperçu » n'oblige pas à compléter les couvertures. Les trois tailles sont une spécification de livraison de ce projet, et non une exigence actuelle du back-office WeChat.

# 0. S'il y a des fichiers de contenu, ingestion (PDF/docx/pptx/web)
python3 scripts/ingest.py contenu.pdf -o out/ingest

# 1. Création complète : génération des couvertures selon les spécifications : 900×383 titre + 1080×1080 carré + 200×200 miniature
python3 scripts/cover.py --md article.md --all -o out/cover

# 2. D'abord l'aperçu (cette étape ne génère pas le bureau) ; le répertoire de sortie est créé automatiquement
python3 scripts/md2wx.py article.md -o out/article.html

# 3. Confirmation de la mise en page (si le navigateur n'est pas disponible, expliquez-le)
python3 scripts/preview.py out/article.html -o out/preview.png --height 4000

# 4. Double vérification (d'abord ; si des problèmes sont trouvés, corrigez le brouillon, puis recommencez)
python3 scripts/lint.py article.md --cards out/fiche_contenu.md --outline out/plan.md --strict
python3 scripts/check.py article.md --html out/article.body.html --strict

# 5. Si tout est bon, générez le bureau de travail et prenez un instantané (l'empreinte de construction est écrite dans les fichiers et build.json)
python3 scripts/md2wx.py article.md --sheet --snapshot -o out/article.html

# 6. Contrôle final avant livraison : les fichiers doivent correspondre au brouillon actuel, et les couvertures doivent être complètes (--publish)
python3 scripts/lint.py article.md --out out --publish --strict
python3 scripts/check.py article.md --html out/article.body.html --strict

Toutes les commandes s'exécutent dans le répertoire racine du skill. python3 doit être 3.9+ ; cover.py nécessite Pillow. Exécutez les étapes dans l'ordre et vérifiez les codes de sortie ; n'ignorez pas les échecs pour continuer ; activez set -e pour les exécutions groupées. Si vous n'avez pas de fiche contenu ou de plan, omettez les paramètres correspondants et notez la portée non vérifiée ; si les paramètres sont explicitement fournis mais que l'analyse échoue, ne traitez pas cela comme une omission. L'instantané complet nécessite que les images locales soient dans le répertoire de sortie ; une simple mise en page n'oblige pas à prendre un instantané ou à générer des couvertures.

Avant d'écrire : rédigez d'abord le frontmatter

Les métadonnées (titre, résumé, auteur, thème) ne sont écrites qu'une seule fois, en en-tête du fichier Markdown, et partagées par trois scripts :

---
title: J'ai gâché 150 rapports hebdomadaires pour comprendre : ce que le patron veut, ce n'est pas « ce que tu as fait »
title_short: Ne faites plus du rapport hebdomadaire un simple compte rendu
summary: Le rapport hebdomadaire passe par trois niveaux de transmission, et chaque fois, de l'information est perdue. Si ton chef ne peut pas en extraire une phrase, ta semaine a été inutile.
author: Yun Guang Mitu
tag: Évolution professionnelle
theme: growth
---

# Titre du contenu

Le contenu commence ici…

Champ	Obligatoire	Description
title	Oui	Titre long, ≤64 caractères ; c'est celui saisi dans le back-office
title_short	Oui	Titre court, ≤20 caractères ; utilisé uniquement pour vérifier l'affichage dans le flux, pas saisi dans le back-office
summary	Oui	Résumé, ≤120 caractères
author	Non	Champ auteur du back-office + signature sur la couverture ; par défaut « Yun Guang Mitu »
tag	Recommandé	Étiquette en haut à gauche de la couverture, 2~4 caractères
theme	Recommandé	tech / growth / minimal / elegant
cover_title	Non	À utiliser pour écrire un texte différent sur la couverture ; utilise title par défaut

Une fois le frontmatter rédigé, les rendus, couvertures, vérifications n'ont plus besoin de paramètres.

Règle de signature : par défaut « Yun Guang Mitu », suivez ce que l'utilisateur spécifie.

Scénario	Comment faire
L'utilisateur ne mentionne pas la signature	N'écrivez rien, utilisez automatiquement « Yun Guang Mitu », le bureau indique « signature par défaut »
L'utilisateur spécifie une signature	Écrivez-la dans le frontmatter author — le bureau, la couverture, et le champ auteur du back-office la liront
Test temporaire de la couverture	Utilisez md2wx.py --author / cover.py --author pour surcharger, sans écrire dans le fichier

Priorité : --author ligne de commande > frontmatter author > défaut « Yun Guang Mitu ». Ne vous contentez pas de passer cover.py --author sans modifier le frontmatter — cela rendrait la signature de la couverture incohérente avec le champ auteur du bureau.

Workflow

Choisissez d'abord la branche de tâche, puis exécutez les étapes correspondantes. Seule la « création complète » nécessite le parcours complet ; les tâches partielles n'appliquent pas toutes les questions de création.

Tâche	Demande typique	À confirmer	Parcours d'exécution
Création complète	Écrire un article ; transformer un contenu en article	Domaine, public, contenu, thème	Étape 0 → 0.5 (si contenu) → 1~7
Mise en page uniquement	Brouillon finalisé, seulement mise en page ; convertir en HTML WeChat	Fichier source finalisé, thème ou frontmatter existant ; ne compléter les métadonnées manquantes qu'en vue d'une publication	Étape 4 → Étape 6.2 (lire les conseils, ne pas corriger soi-même) → Étape 7 (livraison partielle)
Couverture uniquement	Faire seulement la couverture WeChat	Texte de couverture, thème/style, taille souhaitée, optionnellement étiquette et signature	Étape 5 → Vérification humaine du texte de couverture → Étape 7 (livraison partielle)
Vérification uniquement	Vérifier seulement la conformité, la mise en page ou les citations	Fichier à vérifier ; utiliser les paramètres correspondants uniquement si HTML, fiche contenu, plan disponibles	Vérifications associées de l'Étape 6 → Étape 7 (livraison seulement du rapport)

Si vous ne pouvez pas déterminer la branche (par exemple : « traite-moi ça », « regarde si ça peut être publié ») : commencez par l'Étape 0 de la création complète, mais ne posez qu'une seule question clé, ne lancez pas quatre questions d'un coup. Mieux vaut poser une question de plus que de deviner la mauvaise branche et d'exécuter sept étapes.

Les tâches partielles ne complètent que les informations nécessaires à la tâche ; réutilisent les informations existantes ; ne réécrivent pas le contenu finalisé ou les titres existants ; ne redemandent pas le public, le sujet, ou le plan ; n'obligent pas à proposer cinq titres candidats. Si l'utilisateur demande explicitement une correction, alors entrez dans les étapes correspondantes.

• Mise en page uniquement n'appelle pas cover.py, sauf si l'utilisateur demande aussi une couverture. Si un thème existe, conservez-le ; si pas de préférence, utilisez tech et expliquez-le, sans bloquer.
• Couverture uniquement n'oblige pas à fournir un résumé, un contenu, une fiche contenu ou un plan ; ne créez pas d'article fictif pour lancer une vérification complète. Suivez references/compliance.md pour ne vérifier que le texte de couverture effectif, et expliquez la portée de la vérification.
• Vérification uniquement ne modifie pas le fichier vérifié. Si seulement du Markdown, ne transmettez pas --html ; si seulement du HTML sans source Markdown, faites uniquement une vérification humaine de la compatibilité HTML et expliquez la portée. Si la fiche contenu est absente, expliquez que les citations et les chiffres ne peuvent pas être complètement vérifiés.
• Si Pillow ou le navigateur manque, n'installez pas vous-même, n'usurpez pas l'étape comme accomplie ; livrez les parties déjà réalisées et listez les éléments manquants. Partiel ne signifie pas publiable.

Étape 0 · Confirmer les entrées (création complète uniquement)

Pour une création complète, confirmez quatre éléments ; réutilisez les réponses existantes ; ne posez des questions qu'en cas d'informations manquantes, n'inventez pas :

1. Domaine : technique/produit, ou professionnel/développement personnel (détermine le thème et le style)
2. Public : qui sont-ils, où bloquent-ils, que peuvent-ils faire après lecture
3. Contenu : y a-t-il des cas réels, des données, du code, des captures d'écran
4. Préférence de thème : par défaut selon le domaine (voir « Sélection du thème »)

Déterminez aussi le point de départ de cette fois-ci, pour suivre un chemin différent :

Point de départ	Formulation typique	Chemin à suivre
Contenu fourni	« Transforme ce PDF / rapport / page en article WeChat »	Étape 0.5 → Étape 1
Sujet donné	« Écris un article sur X »	Sautez 0.5, allez directement à l'Étape 1
Les deux fournis	« Selon ce rapport, écris un article sur Y »	Étape 0.5 → Étape 1

Étape 0.5 · Ingestion du contenu (seulement si l'utilisateur a fourni un fichier ou un lien)

Lisez references/ingest.md et exécutez-le. Ne sautez pas cette étape pour commencer à écrire — lire le texte brut fait sauter des lignes, oublier des conclusions, et mal retenir des chiffres.

python3 scripts/ingest.py contenu.pdf compte_rendu.docx -o out/ingest

Production en trois couches (texte nettoyé / squelette structurel / citations candidates), puis extrayez la fiche contenu selon ingest.md §2 :

Préfixe	Type
F	Fait (affirmation objective)
D	Donnée (chiffre + unité + contexte)
O	Opinion (revendication de l'auteur, pas un fait)
?	Doute (contradiction / sans source / à vérifier)

Le livrable de cette étape est le tableau de fiche contenu + la liste des lacunes, à confirmer par l'utilisateur avant de continuer.

Trois lignes rouges (ingest.md §3) : ne modifiez pas les chiffres, ne modifiez pas le contexte, n'écrivez pas des suppositions comme des faits. Si plusieurs valeurs pour un même indicateur sont trouvées, mettez-les dans la carte ? et demandez, ne choisissez pas silencieusement.

Étape 1 · Extension du sujet et plan

• L'utilisateur a fourni du contenu : déduisez les angles possibles à partir de la fiche contenu (references/topic-expand.md §3)
• L'utilisateur a seulement donné un sujet : suivez topic-expand.md §1–§3, développez une phrase en arbre d'arguments

Combinez avec references/writing-playbook.md §1 (lignes de base par domaine) et §4 (5 modèles de structure) pour sélectionner le squelette, et produisez un plan avec répartition du nombre de mots à confirmer par l'utilisateur.

Chaque argument du plan doit être lié à un numéro de fiche contenu ([F1] [D2]), les arguments sans correspondance sont directement supprimés, ne les inventez pas pour compléter la structure (topic-expand.md §4).

Étape 2 · Écrire le titre et le résumé

Lisez references/writing-playbook.md §2 et §6 :

• Proposez un titre long (≤64 caractères, pour le champ back-office) + titre court (≤20 caractères, pour l'affichage dans le flux)
• Donnez 5 candidats à la fois, en indiquant la formule utilisée pour chacun, laissez l'utilisateur choisir
• Résumé ≤120 caractères, donnez 1~2 versions

Étape 3 · Écrire le contenu

Écrivez en Markdown selon le plan, en notant :

• Début selon les crochets du §3, accrochez-vous dès les 3 premières lignes
• Chaque paragraphe traite un sujet, ≤5 lignes par paragraphe (environ 260 caractères)
• Fin selon le §5, utilisez « question de conclusion / annonce de série / résumé de valeur », n'écrivez pas d'incitation à partager
• Après l'écriture, passez en revue la « saveur AI » avec la liste de 24 points du §7, supprimez tous les mots de transition qui n'affectent pas la compréhension

Étape 4 · Rendu de mise en page

Utilisez le theme du frontmatter ou le thème explicitement spécifié par l'utilisateur ; si pas de préférence, choisissez selon le domaine ; par défaut pour une mise en page partielle : tech

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

Le répertoire parent de sortie est créé automatiquement ; deux fichiers sont produits :

• out/article.html — page d'aperçu (avec conteneur de fond blanc, comme une page de lecture mobile) → pour voir
• out/article.body.html — fragment de contenu pur → solution de collage alternative

Cette étape ne génère pas le bureau ; le out/sheet.html final est généré à l'Étape 7, pour éviter de sauvegarder un instantané prématuré avant la fin des couvertures et du brouillon final.

Après le rendu, utilisez preview.py pour prendre une capture d'écran, regardez-la vous-même avant de la montrer à l'utilisateur (le titre a-t-il un saut de ligne inesthétique, le tableau est-il trop large, le bloc de code a-t-il été tronqué). Si le navigateur n'est pas disponible, ouvrez le HTML pour une vérification humaine et expliquez l'absence de capture, sans exiger de réécrire l'article.

Étape 5 · Générer la couverture (obligatoire pour la publication)

Sans couverture, l'article ne peut pas être publié sur WeChat ; cette étape n'est pas optionnelle pour la « création complète » et la « mise en page destinée à la publication ».

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

Trois formats en un coup : cover.png 900×383 (titre 2.35:1), cover-square.png 1080×1080 (carré), cover-thumb.png 200×200 (miniature). Si les tailles sont incorrectes, la plateforme les recadrera ; lint --publish les vérifiera.

Les paramètres sont lus par défaut dans le frontmatter (titre, étiquette, auteur, thème), généralement pas besoin d'en passer :

• --style : gradient (par défaut, fond sombre) / minimal (fond blanc, article d'opinion) / band (bande de couleur, article de marque)
• --all produit trois formats : titre 900×383, carré 1080×1080, miniature 200×200
• Le titre de la couverture utilise par défaut title (le titre long a un meilleur crochet) ; pour changer le texte, ajoutez cover_title dans le frontmatter

Étape 6 · Double vérification (deux portes, chacune son domaine)

La création complète exécute les deux portes ; mise en page uniquement et vérification uniquement choisissent la vérification correspondante selon le tableau d'entrée, sans forcer la création de matériel manquant, et sans modifier le brouillon original. Si des métadonnées, fiche contenu ou captures d'écran manquent, notez les limitations et ne marquez pas la livraison partielle comme publiable complet.

6.1 Porte d'écriture — vérifie « les arguments ont-ils une base, d'où viennent les chiffres »

python3 scripts/lint.py article.md --cards out/fiche_contenu.md --outline out/plan.md

Cette étape est une porte dure, pas un conseil d'écriture :

Vérification	Règle	Conséquence si échec
Citation vide	La citation [F1] dans le texte doit exister dans la fiche contenu	Signaler « à corriger »
Carte de doute	[?N] ne doit pas apparaître dans le texte	Signaler « à corriger » — vérifier ou supprimer
Chiffre sans source	Chaque « chiffre+unité » doit pouvoir être trouvé dans une carte F/D	Signaler « à corriger »
Argument sans support	Chaque soutien du plan doit être lié à au moins une [F]/[D]	Signaler « à corriger »
Qualité de l'argument principal	Ne peut pas être une phrase courte (type « le cache est important »)	Signaler « à corriger »
Carte d'opinion	[O] citée : avertir qu'elle ne doit pas être l'argument principal	« À confirmer »
Liste des lacunes	Le plan doit avoir des lacunes P0/P1/P2	« Indication »

Sans fiche contenu, déclassement automatique : indiquez seulement « les chiffres ne peuvent pas être vérifiés » et listez tous les chiffres avec unités pour un examen humain.

Vérification de version des fichiers : avec --out <répertoire_sortie>, comparez l'empreinte de construction dans les fichiers livrés avec celle calculée à partir du brouillon actuel.

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

--publish signifie une validation selon la portée « prêt à publier », nécessite --out pour spécifier le répertoire de sortie ; une absence de paramètre de répertoire provoque une erreur. Elle vérifie l'existence des fichiers et les dimensions dans l'en-tête PNG selon les trois spécifications de ce projet, sans décoder complètement l'image, sans vérifier le texte de la couverture, ni les exigences de téléchargement ou du back-office.

Situation	Jugement
Empreinte du fichier == empreinte du brouillon actuel	Réussi
Brouillon modifié mais pas ré-rendu	« À corriger » : page d'aperçu/bureau de travail sont obsolètes
Résumé du brouillon enregistré dans build.json ne correspond pas	« À corriger » : le brouillon a été modifié après génération
article.body.html a été remplacé ou édité manuellement	« À corriger » : via la vérification de hachage additionnelle dans build.json
Le fichier n'a pas d'empreinte	« À confirmer » : généré par un ancien script ou modifié manuellement
Couverture manquante / taille incorrecte (avec --publish)	« À corriger » : la couverture n'atteint pas les spécifications de publication de ce projet

Cette étape est la seule garantie mécanique avant livraison pour éviter d'envoyer une version antérieure après des corrections.

6.2 Vérification de publication — vérifie « peut-il être publié »

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

La longueur du titre et du résumé est lue automatiquement dans le frontmatter, pas besoin de les passer à nouveau.

Critères de validation stricts :

Indicateur	Exigence
« À corriger » de lint	Doit être 0
Éléments à haut risque	0 élément non résolu à haut risque ; les faux positifs confirmés manuellement doivent être documentés avec preuves et enregistrement de vérification
Métadonnées	title, title_short, summary obligatoires et non vides ; seuls les champs sur une ligne key: value sont pris en charge
Nombre de caractères du titre	Titre long ≤64, titre court ≤20 ; l'information clé de début du titre publié doit encore être vérifiée manuellement
Nombre de caractères du résumé	≤120
Images externes	Doivent être téléchargées ou remplacées par des images utilisables par WeChat avant publication, et vérifiées dans l'aperçu de l'éditeur
Contenu professionnel ou sensible	Doit passer une validation humaine/juridique finale ; la suppression de mots clés, la réécriture ou l'anonymisation ne remplacent pas la vérification et l'autorisation

Les deux --strict peuvent être utilisés en CI : en cas de « à corriger » ou de risque élevé, le code de sortie est 1. check.py traite les métadonnées manquantes/trop longues, les valeurs sur plusieurs lignes non prises en charge, et les HTML explicitement spécifiés mais inexistants comme à haut risque ; sans --strict, les problèmes sont signalés mais le code de sortie est 0.

La vérification de publication scanne champ par champ title, title_short, summary, cover_title, author, tag et le contenu ; le code dans le contenu est toujours filtré, mais les backticks dans les métadonnées ne peuvent pas contourner la vérification. Le champ field de la sortie JSON indique la source, la ligne line du contenu reste relative au contenu. Les valeurs de surcharge de titre/résumé en ligne de commande sont l'objet final de la vérification.

Le scan réussi n'équivaut pas à une autorisation de publication. Les éléments à haut risque sont enregistrés selon references/compliance.md §0 avec « en attente de vérification / faux positif confirmé / révision terminée / refus de publication » ; les scripts ne peuvent pas lire ou remplacer l'enregistrement de vérification humaine ; un faux positif confirmé ne fait pas passer --strict automatiquement. Si les problèmes professionnels, d'autorisation ou de confidentialité ne sont pas résolus, suspendez, ne livrez pas comme publiable. Les éléments à risque moyen ou faible conservés, les éléments confirmés manuellement et leurs justificatifs sont également expliqués.

Si les droits d'utilisation ou la source du contenu ne sont pas clairs, commencez par obtenir l'autorisation/la source ou excluez ; ne changez pas d'échelle, ne transformez pas une opinion externe en expérience personnelle de l'auteur. Après l'ingestion, conservez séparément licence_et_limites.md, avec la source, la signature, le périmètre d'utilisation, les limites et le statut d'autorisation.

Étape 7 · Livraison

Pour les tâches nécessitant du HTML/bureau de travail, régénérez uniformément le bureau final avant livraison. Une fois le brouillon finalisé, les métadonnées, le thème et les couvertures demandées confirmés, exécutez avec la même source et les mêmes paramètres de thème/sortie :

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

Cela met à jour la page d'aperçu, le fragment de contenu et sheet.html en même temps ; le bureau lit les cover.png, cover-square.png, cover-thumb.png finaux dans le même répertoire. C'est un instantané de fichier statique ; rafraîchir le navigateur ne régénère pas le bureau. Si vous modifiez ensuite le contenu, les métadonnées, le thème ou les images, régénérez les fichiers correspondants et revérifiez ; ne livrez pas un ancien instantané.

Empreinte de construction et retour en arrière :

• L'empreinte inclut le code de rendu, le brouillon source, le thème fusionné, les surcharges effectives de titre/signature/thème et les options de sortie, ainsi que les images locales et le contenu de la couverture ; les changements de métadonnées et d'actifs locaux invalident l'ancienne construction.
• build.json utilise le schéma 2, déclare les fichiers réellement demandés et enregistre le SHA256 complet de chaque élément ; le vérificateur valide selon les paramètres de rendu effectifs, donc une surcharge explicite -t du thème ne doit pas provoquer de faux positif. Les fichiers manquants, le contenu remplacé ou une structure endommagée bloquent l'opération.
• article.body.html reste pur, sans aucun marquage ; il est vérifié par hachage de liste séparément de l'aperçu et du bureau, ne se fie pas uniquement à l'étiquette d'empreinte dans le HTML. Si l'ancienne liste ne peut pas être entièrement vérifiée, demandez une regénération.
• La création complète ajoute --snapshot lors du dernier rendu, sauvegardant le brouillon source, le HTML demandé, les images locales et les couvertures dans out/.builds/<empreinte>/. L'instantané d'une même empreinte ne peut pas être écrasé ; l'absence d'images locales ne peut pas simuler un instantané complet. Les images doivent être des chemins relatifs dans le répertoire de sortie ; l'instantané n'acquiert pas d'images distantes.
• md2wx.py --list-builds --out-dir out pour voir l'historique ; md2wx.py --rollback <empreinte> --out-dir out restaure le brouillon source à son chemin d'origine, les fichiers produits, les images locales et les couvertures et nettoie les sorties de la version précédente qui ne sont plus nécessaires. Avant l'opération, confirmez l'intention de revenir en arrière, car cela remplacera le brouillon source actuel et les actifs déclarés ; n'utilisez que des instantanés locaux fiables.
• Le retour en arrière vérifie d'abord tous les fichiers et leurs hachages ; les fichiers endommagés ou aux chemins dangereux ne sont pas restaurés à moitié. L'instantané ne restaure pas les scripts de rendu ou la configuration globale du thème ; après ces modifications, un re-rendu et une revérification sont nécessaires. Le brouillon source d'un instantané stdin est restauré en article.md dans le répertoire de sortie.
• La mise en page uniquement utilise la commande ci-dessus sans --snapshot ; la création complète utilise :

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

Liste de vérification avant livraison (confirmez point par point, ne remplacez pas par « les commandes ont été exécutées » par « les fichiers ont été vérifiés ») :

• Pour la création complète, lint.py article.md --out out --publish --strict passe — les fichiers correspondent au brouillon actuel et les couvertures respectent les spécifications du projet
• check.py article.md --html out/article.body.html --strict passe — aucun élément à haut risque
• Vous avez personnellement vérifié article.html ou preview.png (sauts de ligne du titre, largeur du tableau, troncature des blocs de code)
• Les titres/titre court/résumé/auteur dans sheet.html correspondent à ce qui doit être saisi dans le back-office
• Les trois formats de couverture existent et leurs dimensions d'en-tête sont correctes (vérifiés par --publish) ; ouvrez les images pour confirmer qu'elles sont décodables et que le texte n'est pas tronqué
• Les images locales dans le contenu sont listées comme « nécessitant un téléchargement manuel »
• Les instructions de livraison indiquent : les éléments à risque moyen/faible conservés, les tâches non réalisées

Vérifiez les fichiers de sortie réels un par un ; si des couvertures ou des captures d'écran manquent, listez-les ; ne remplacez pas la vérification des fichiers par l'exécution de commandes ; si des éléments manquants ne sont pas résolus pour un brouillon complet, ne marquez pas comme livraison complète. Le Markdown source est fourni avec le chemin réel, sans exiger de déplacer ou d'écraser le brouillon original de l'utilisateur.

Vérification selon la portée de la tâche (les éléments de vérification suivent la demande, n'appliquez pas toujours la validation complète de création) :

• Création complète : parcourez toute la liste point par point
• Mise en page uniquement : le brouillon source, le HTML, le fragment de contenu, le bureau de travail suffisent ; la mise en page uniquement n'exige pas les trois formats de couverture
• Couverture uniquement : vérifiez seulement le texte et les dimensions de la couverture, pas le contenu ni la vérification
• Vérification uniquement : livrez seulement le rapport, pas de correction

Les tâches partielles ne livrent que les fichiers demandés : mise en page uniquement livre le brouillon source, le HTML, le fragment de contenu et le bureau de travail ; couverture uniquement livre les images aux dimensions demandées et la conclusion de la vérification du texte ; vérification uniquement livre le rapport. N'exigez pas de compléter les couvertures, la fiche contenu ou le plan ; ne considérez pas une vérification partielle comme une validation de publication complète.

La liste suivante s'applique uniquement à la création complète ; le chemin du fichier source est le chemin réel :

out/
├── article.md          Brouillon final Markdown (fichier source, avec frontmatter)
├── article.html        Page d'aperçu (à visualiser)
├── article.body.html   Fragment de contenu pur (solution de secours)
├── sheet.html          Bureau de travail (pour publier)
├── cover.png           Couverture titre 900×383
├── cover-square.png    Carré 1080×1080
├── cover-thumb.png     Miniature 200×200
└── preview.png         Capture d'écran de mise en page

La création complète donne aussi : titre long / titre court / résumé / conclusion de vérification (éléments à risque moyen/faible conservés). Les tâches partielles listent seulement les métadonnées existantes, les fichiers demandés, la portée de vérification effective et les éléments non réalisés ; n'écrivez pas de titre, résumé ou contenu pour compléter la liste.

Publier sur WeChat Official Account (étapes clés)

Ouvrez out/sheet.html ; une page pour toutes les opérations de copie :

1. ① Titre → cliquez sur « Copier » → collez dans le champ titre du back-office
2. ③ Résumé → cliquez sur « Copier » → collez dans le champ résumé
3. ④ Auteur → cliquez sur « Copier » → collez dans le champ auteur
4. Contenu → cliquez sur « Copier le contenu » en haut à droite → collez dans la zone d'édition
5. Images du contenu → dans la carte « Images du contenu » à gauche, traitez chaque image (voir ci-dessous)
6. Image de couverture → téléchargez cover.png
7. Suivez la « Liste avant publication » point par point

Pourquoi les images disparaissent

Le collage dans l'éditeur WeChat ne reçoit que le texte et les styles, il ne télécharge pas les images locales. L'élément <img src="fig.png"> dans le contenu est un chemin relatif local ; après collage dans l'éditeur, l'espace de l'image est vide — ce n'est pas un problème de mise en page, c'est une limitation de l'environnement hôte : l'image doit d'abord être sur le serveur WeChat (mmbiz.qpic.cn) pour s'afficher.

Sans autorisation API, cette étape ne peut être que manuelle. Le bureau la simplifie en deux chemins :

Méthode	Opération
Copier l'image	Cliquez sur « Copier l'image » → Cmd+V à l'emplacement correspondant dans l'éditeur, WeChat télécharge automatiquement
Copie via clic droit	Si « Copier l'image » échoue, cliquez sur « Ouvrir l'originale » → clic droit « Copier l'image » → collez dans l'éditeur
Solution de secours	Clic droit « Enregistrer l'image sous… » → bouton « Image » de l'éditeur pour télécharger

L'ordre suit l'apparition dans le contenu (1ère image, 2ème image…) ; lors du collage, trouvez l'emplacement en vous référant au contenu.

Ne copiez pas le fichier .md source : le md est du texte brut, il ne resterait qu'une collection de # et **, sans image ni mise en page. Vous devez copier le texte enrichi du bureau, ou le résultat rendu de article.body.html.

Vérifiez s'il manque des images : avant publication, parcourez l'aperçu mobile du début à la fin pour voir si chaque image est à sa place.

Solution de secours : ouvrez article.body.html dans le navigateur → Cmd+A → copier → coller. (Ne pas utiliser article.html, c'est une page d'aperçu qui inclut un conteneur externe.)

Sélection du thème

Thème	Applicable	Visuel
tech Bleu technologique	Analyse technique, analyse de produit, pratique d'ingénierie	Accentuation bleue, barre verticale H2, bloc de code sombre
growth Orange croissance	Expérience professionnelle, réflexion sur la croissance, méthodologie	Accentuation orange chaud, bloc de couleur H2, interlignage plus lâche
minimal Noir et blanc minimaliste	Commentaire d'opinion, réflexion approfondie	Noir et blanc, soulignement H2
elegant Bleu marine professionnel	Article de marque, publication officielle, analyse sectorielle	Police avec empattement, accentuatin bleu marine, H1 centré

Principe : Plus le contenu est dense, plus le thème est sobre. En cas de doute, utilisez tech.

Pour ajouter un thème, placez simplement un fichier JSON dans scripts/themes/, les détails des champs sont dans references/layout-spec.md §13.

Références rapides des commandes

Commande	Rôle	Paramètres clés
ingest.py <fichiers...>	Contenu → texte structuré + citations candidates	-o répertoire de sortie, --json
md2wx.py <md>	Markdown → HTML WeChat	--sheet pour le bureau, --snapshot pour l'instantané, -t thème, -o sortie, --no-body, --check
md2wx.py --list-builds	Voir l'historique des constructions	--out-dir
md2wx.py --rollback <empreinte>	Restaurer une version	--out-dir
cover.py	Image de couverture	--md lit automatiquement le frontmatter, --style, --all ; --title/--tag/--author/--theme peuvent surcharger
lint.py <md>	Porte d'écriture + vérification de version des fichiers	--cards, --outline, --out, --json, --strict
check.py <md>	Vérification avant publication	--html, --json, --strict ; --title/--summary peuvent surcharger le frontmatter
preview.py <html>	Capture d'écran pour confirmer la mise en page	-o, --width, --height

Par défaut, le titre, le résumé, l'auteur et le thème sont lus dans le frontmatter ; les paramètres de ligne de commande ne sont utilisés que pour une surcharge temporaire.

--strict est utilisé pour CI/automatisation : en cas de risque élevé, le code de sortie est 1.

Pièges courants (à connaître absolument)

Piège	Phénomène	Traitement
Lien externe non cliquable	Cliquer sur https://... ne fait rien	Remplacez par une description textuelle, ou mettez-le dans « Lire l'original »
Image vide	Les images externes s'affichent comme espace réservé/bloc gris	Téléchargez manuellement dans l'éditeur, ou utilisez l'interface matérielle L3
Ligne vide instable	Utiliser des lignes vides pour l'espacement des paragraphes ; comportement client incohérent	Utilisez margin pour l'espacement, md2wx.py le gère déjà
Code à la ligne	Code long automatiquement replié, illisible	Bloc ≤30 lignes, pour les très longs, divisez en fragments
Tableau trop large	Tableau de 5 colonnes ou plus avec défilement horizontal	Colonnes ≤4, divisez en deux si nécessaire
Titre tronqué	Le flux n'affiche qu'environ 20 caractères	Vous devez avoir une version courte du titre
Impossible de publier sans couverture	La couverture titre du back-office est obligatoire ; sauter cette étape = pas de livraison	Pour la création complète, exécutez cover.py --all ; avant livraison, vérifiez avec lint --out --publish
Livraison d'une version antérieure	Vous avez modifié le brouillon mais pas re-rendu ; la version publiée est l'ancienne	Avant livraison, exécutez lint --out out --strict ; si l'empreinte ne correspond pas, le processus bloque

Documents de référence (à charger selon les besoins, ne lisez pas tout en une fois)

Document	Quand le lire
references/ingest.md	Étape 0.5 : ingestion de contenu, extraction de fiche contenu, règles de fidélité, conflits de contexte, liste des lacunes
references/topic-expand.md	Étape 1 : extension du sujet, arbre d'arguments, discipline anti-dilution
references/writing-playbook.md	Étape 2~3 : formules de titre, crochets d'accroche, modèles de structure, suppression de la saveur AI
references/compliance.md	Étape 6 : liste de mots de conformité, types de violations, formulations de remplacement
references/layout-spec.md	Quand vous devez ajuster la mise en page, ajouter un thème, juger des problèmes visuels
references/api.md	Quand l'utilisateur veut faire une publication automatique L3

Dépendances

Dépendance	Utilisée pour	En son absence
Python 3.9+	Tous les scripts	Obligatoire
Pillow	cover.py	La génération de couverture échoue, le reste fonctionne
pypdf	ingest.py pour analyser les PDF	Déjà inclus dans scripts/vendor, pas besoin d'installer

(Suite du texte tronquée pour la traduction)