zz-mv-gongzuotai · Coordination de projet MV en un seul skill

Positionnement

C'est le skill d'entrée unique pour tout projet MV.
Le workbench sert uniquement à la consultation et à la coordination ; la génération est réalisée par l'agent qui appelle les scripts/ de ce skill.
Le processus s'arrête au segment vidéo : pas de montage brut, pas d'assemblage, pas de version finale ; les segments + handoff sont remis à l'étape de montage suivante.

La commande mvwb fait référence à la commande globale installée ; si ~/.local/bin n'est pas dans le PATH, utiliser ~/.agents/skills/zz-mv-gongzuotai/start/mvwb (copié et rendu exécutable lors de l'installation) ; si cela ne fonctionne toujours pas, utiliser python3 ~/.agents/skills/zz-mv-gongzuotai/scripts/mvwb.py.

Workbench et clés (règles strictes)

Le workbench est le fichier statique workbench.html du projet : double-cliquez ou ouvrez avec un navigateur en file://... ; ne démarrez aucun service en arrière-plan.
Interdiction de mvwb server, python -m http.server, ports, versions service. Le workbench est une page de visualisation pure, sans aucune configuration intégrée.
L'utilisateur dit « ouvre le workbench » : exécutez mvwb open [--workspace NOM], cela ouvre uniquement le HTML local.
Au début, seule la clé Router est fournie : l'étudiant place le fichier zz-keys.json envoyé par l'enseignant dans le répertoire racine du projet (il ne contient généralement que {"router": "..."}) ; l'agent exécute mvwb keys import --file <projet>/zz-keys.json --delete-source. Une importation est globale et le fichier source est supprimé après importation.
La clé ne passe pas par le workbench : l'utilisateur importe zz-keys.json, double-clique sur start/setup-keys.*, ou utilise le terminal mvwb keys set ; l'agent exécute mvwb keys import --file <chemin> --delete-source. L'agent guide uniquement, ne demande pas la clé ; en environnement non interactif, n'appelez pas keys set.
Clé de secours via avis B001 : si le Router échoue ≥3 fois en 10 minutes sans clé de secours, l'agent génère un bloc d'avis B001 ; l'étudiant transmet le texte original de l'avis à l'enseignant, qui décide de fournir ou non un zz-keys.json de secours (contenant les champs runninghub/apimart). Une fois fourni, l'importation active la clé et rafraîchit le solde / le workbench. L'agent peut utiliser mvwb keys watch pour éviter une seconde conversation.
Format d'avis unifié : tous les échecs, blocages et avertissements passent par scripts/alerts.py (table des codes dans references/alerts.md), l'étudiant n'a qu'à transmettre le bloc de l'avis original. Interdiction de dire directement « va demander une clé de secours à l'enseignant » ; la clé de secours est toujours décidée par l'enseignant via l'avis B001.
La clé n'est pas écrite dans DATA, HTML, scripts, logs ou captures d'écran ; le fichier importé doit être supprimé après importation. Si l'utilisateur a déjà envoyé la clé dans la conversation, rappelez-lui de l'annuler et de la renvoyer.
Solde/coûts : uniquement le Router (en RMB) : en haut, seul le solde Router est affiché ; tous les coûts sont convertis en ¥ et écrits dans DATA (le taux RHCoin → CNY se trouve dans config/models.json sous fx.rh_coin, maintenu par l'enseignant).
Après chaque génération/remplacement de fichier : mettez à jour data.json → mvwb build → mvwb check --data .... Si check signale un manque, le workbench ne l'affiche pas et l'étape n'est pas considérée comme terminée.

Livraison finale

Un répertoire par MV, la musique, les assets et les segments vidéo y sont rangés :

workspaces/<projet>/
├─ original/
│  ├─ lyric_original.md       Paroles originales du client
│  ├─ story_script.md         Storyboard original du client (non découpé)
│  └─ lyric.json              Mapping des numéros de lignes L01…
├─ workbench.html             Workbench du projet (affichage en lecture seule + import de clé locale)
├─ data.json                  Source de données du workbench (mise à jour par l'agent)
└─ MV001/
   ├─ mv_manifest.json        État des étapes / version / coûts
   ├─ 00_framework.md         Plan musique / assets / segments
   ├─ 01_music/
   │  ├─ song_v1.mp3
   │  └─ timeline_v1.json     Durées de début/fin de chaque phrase (pour le découpage / la livraison)
   ├─ 02_assets/
   │  ├─ assets_v1.json
   │  ├─ role_xxx.png
   │  ├─ scene_xxx.png
   │  └─ prop_xxx.png
   ├─ 03_segments/
   │  ├─ segments_v1.json     G1/G2… version actuelle + historique
   │  ├─ G1_v1.mp4
   │  ├─ G1_v2.mp4            Historique de réexécution après révision
   │  └─ G2_v1.mp4 …
   └─ handoff_v1.json         Liste remise au monteur

handoff_v1.json contient uniquement les champs nécessaires au montage :

{
  "mv_id": "MV001",
  "status": "ready",
  "segments": [
    {
      "segment_id": "G1",
      "line_ids": ["L01", "L02"],
      "music_start": 0.0,
      "music_end": 6.0,
      "duration": 6.0,
      "video_file": "03_segments/G1_v1.mp4",
      "model": "muse-video-ext",
      "resolution": "720x1280",
      "notes": "Version actuelle approuvée"
    }
  ]
}

Contrat d'exécution (à chaque étape obligatoire)

Détails des entrées / sorties / auto-vérifications dans references/step-contract.md. Chaque étape suit cinq actions fixes :

Étape	D'abord demander (uniquement si manquant)	Artefact	Auto-vérification	Porte
0 Initialisation	Nom du projet, nombre, durée, style, ratio, budget	workspace + `data.json` + `workbench.html`	`mvwb check` = 0 manques	Confirmation des paramètres
1 Texte original	Fichiers paroles / storyboard	`original/*` + `lyric.json`	Lignes / ID consécutifs / pas de découpage	Vérification du texte original
2 Workbench vide	Paramètres du batch	DATA + HTML statique	build + check + double-clic ouvrable	Confirmation du workbench
3 Cadre	Avis de révision	manifest + framework + segments	Durée / lignes manquantes / segments ≤10s	Confirmation du cadre + devis
4 Génération	Éléments pointés	Musique / assets / segments vidéo / handoff	Fichier existant / durée / QA / timeline	Verrouillage par élément

La sortie dans la conversation est unifiée : « conclusion + chemin de l'artefact + résultat de l'auto-vérification + en attente de confirmation », pas un bloc JSON complet.
L'auto-vérification doit être réellement exécutée et son résultat cité ; en cas d'échec, l'étape est bloquée, on ne passe pas silencieusement à l'étape suivante.

Quatre étapes

Étape 1 · Texte original

Cherchez d'abord dans original/, données_client/, entrée/ les fichiers paroles / storyboard ; le nom contient paroles, lyric, storyboard, script.
Si trouvé, lisez et stockez sans modification, sans découpage, sans « optimisation ».
Si non trouvé : demandez d'abord à l'utilisateur s'il a des données client ; sinon, guidez-le selon le produit / l'histoire / les personnages / le style / la durée / les références pour générer un brouillon.
Stockage :

original/lyric_original.md   Nom de la chanson / couplets / refrain, texte original
original/story_script.md     Storyboard original, non découpé
original/lyric.json          Mapping des numéros de lignes L01…

Porte : confirmation du texte original. L'utilisateur dit « pas de problème / on garde cette version » → verrouillage ; modifier le texte original = recréer le workbench.

Étape 2 · Workbench vide

mvwb init mon_projet            # Projet vide : original/ à remplir, mvs=[], workbench.html généré
mvwb init demo_projet --demo    # Si un exemple est nécessaire : copie du demo complet
# Après avoir rempli workspaces/mon_projet/original/, laissez l'agent générer le workbench vide

L'agent reconstruit avec templates/workbench.html + DATA.json :

python3 scripts/build_workbench.py \
  --template templates/workbench.html \
  --data workspaces/mon_projet/data.json \
  --out workspaces/mon_projet/workbench.html

Ouvrez le workbench statique :

mvwb open --workspace mon_projet

Après génération, arrêtez-vous et demandez (ce qui manque, chaque élément avec une valeur par défaut) :

Comment s'appelle le projet ? Par défaut nom du client / date.
Combien de MV générer en une fois ? Par défaut 1 échantillon (suggérez d'abord 1–5).
Durée de chaque MV ? Par défaut 30s (15/30/45/60s).
Quel style ? Par défaut selon le pack de référence (3D Pixar / court métrage réel / animé japonais réconfortant / vidéo de référence client).
Ratio ? Par défaut 9:16 portrait (1080×1920).
Références personnages / scènes / produit ? Image si disponible, sinon description textuelle.
Budget maximum ? Si non donné, d'abord un devis, ne soumettez pas.

La sortie ne renvoie que : chemin de l'artefact + résultat de l'auto-vérification + confirmation de ces 7 éléments. Porte : confirmation des paramètres du batch. Cette étape ne coûte rien.

Contrat de durée (objectif utilisateur vs durée réelle de la musique)

Durée	Qui définit	Utilisation
`target_duration`	Utilisateur à l'étape 2 (ex. 45s)	Nombre de secondes demandé pour la musique, durée totale cible du MV, budget / nombre de segments, plan du cadre
`actual_duration` / `timeline_v1.json`	Lecture après génération de la musique	Durée réelle du storyboard / segments vidéo, `seconds` de Muse, nombre d'images H3, handoff

La durée totale suit le réglage de l'utilisateur : lors de la génération de la musique, target_duration est transmis à la 116:value de l'ACE ; la durée totale, le nombre de segments et le budget du cadre sont planifiés en fonction de cette valeur.
La durée de chaque segment suit la musique réelle : une fois la musique générée, lisez actual_duration et la timeline phrase par phrase, mettez à jour la duration du storyboard / segment vidéo ; le segment vidéo est généré selon la durée réelle de la phrase, pas selon la durée planifiée.
Gestion des écarts : si la durée réelle diffère de la cible de >1s ou >2%, faites une pause et demandez à l'utilisateur de choisir « accepter la durée réelle / regénérer la musique / couper en post-production » ; ne générez pas la vidéo en utilisant secrètement la durée planifiée.
Si seule la vidéo est choisie sans musique : utilisez d'abord target_duration pour un plan provisoire ; une fois la musique ajoutée, marquez tous les segments vidéo comme stale et réexécutez-les selon la timeline réelle.
Ainsi, on respecte la durée totale fixée par l'utilisateur tout en garantissant l'alignement image-parole de la musique.

Étape 3 · Cadre textuel du MV

Créez MV001…MV00N, chaque MV :

Ratio par défaut 9:16 portrait (le workbench utilise 1080×1920, Muse sort 720×1280) ; modifiez uniquement si l'utilisateur le spécifie clairement.
Écrivez d'abord le génome : cast_id/outfit_id/face_seed, story_id, music, visual, edit ; règles dans references/variation.md. Au moins 3 dimensions différentes entre deux MV d'un même lot, interdiction d'avoir le même personnage + la même tenue, le même conflit d'histoire, le même genre + BPM + vocal, le même pack de scène.
Sortez un tableau de différenciation (cast/story/music/visual/edit de chaque MV) ; si une combinaison se répète, arrêtez-vous et choisissez la suivante dans le pool, ne commencez pas la production.
mv_manifest.json : stages tous à not_started ; cost/spent=0.
00_framework.md : plan musique, liste d'assets, storyboard standard, plan des segments vidéo ; la duration ici est une valeur planifiée, avec target_duration comme objectif total.
La liste d'assets est destinée à la révision par l'utilisateur : vues de personnage (face / corps / dos), scène vide, accessoires ; elle sert à verrouiller la cohérence visuelle des vidéos suivantes. Ce n'est pas optionnel. Expliquez à l'utilisateur « sans les assets, le personnage / la scène de chaque vidéo dérivera ».
03_segments/segments_v1.json : écrivez d'abord le plan, videos: [].
Mettez à jour DATA.mvs : musique et assets vides, storyboard et segments planifiés ; conservez un snapshot des keys.

Montrez à l'utilisateur un résumé du cadre :

Y a-t-il quelque chose à modifier dans le cadre ? Quelle MV, quel plan, quelle phrase ? Modifiez uniquement les éléments que vous pointez.

Porte : approbation du cadre + confirmation de la portée de la génération / devis.

Étape 4 · Génération et révision

4.0 Pré-vérification

mvwb keys status
mvwb keys import --file workspaces/mon_projet/zz-keys.json --delete-source
mvwb keys watch --timeout 600 --data workspaces/mon_projet/data.json
mvwb keys balance --data workspaces/mon_projet/data.json
mvwb quote --model muse-video-ext --seconds 2

Clé manquante / solde insuffisant / échec de la requête : arrêtez-vous. Devis = nombre × prix unitaire ; ne lancez que si l'utilisateur confirme.

4.1 Ordre : Musique → Timeline → Assets → Segments vidéo

Étape	Commande	Artefact
Musique	`mvwb rh --app 2075301815628943362 ...`	`01_music/song_v1.mp3`
Timeline	`mvwb timeline ...`	`01_music/timeline_v1.json`
Assets	`mvwb rh --app 2116462203997081601 ...`	`02_assets/*` + `assets_v1.json`
Vidéo H3	`mvwb rh --wf 2110943749894402050 ...`	`03_segments/G*_v1.mp4`
Vidéo Muse	`mvwb muse --prompt ... --seconds N --size 720x1280 --out ...`	`03_segments/G*_v1.mp4`
Musique/Assets (Router)	`tokentech_task.py music	image ...`(protocole dans`references/providers/router.md`)
Livraison	Écrire `handoff_v1.json`	Pour le monteur

La musique est verrouillée en premier ; lisez la duration / timeline réelle pour mettre à jour la durée des segments ; les assets suivent le pack de référence ; les segments vidéo sont générés un par un selon la durée réelle de chaque phrase.
Les assets sont générés selon la fiche personnage : les vues du personnage utilisent le template de references/prompts/casting-style.md + pack de style ; la règle MOSS est : case gauche le visage, case centrale le corps entier mais la tête complètement hors cadre, case droite le dos. Pour chaque personnage, générez d'abord 4 candidats, sélectionnez-en 1, puis verrouillez.
Cohérence du personnage au sein d'un même MV : tous les assets et segments vidéo référencent la même fiche personnage de cast_id et le même outfit_id ; le changement de tenue n'a lieu que si l'histoire le nécessite et est enregistré.
Pas de répétition entre MV : les cast_id, histoires, musiques et packs de scène d'un même lot sont différenciés selon le génome ; avant le verrouillage des assets, vérifiez-en deux au hasard pour éviter « la même personne avec une tenue différente = nouveau MV ».
Chaque segment peut générer plusieurs vidéos : la première est la version actuelle, l'historique ajoute G1_v2.mp4.
Les nouvelles versions écrivent *_v{n+1}.json, sans écraser les anciennes.
Mettez à jour stages/status/spent, reconstruisez DATA.
Après reconstruction, une auto-vérification est obligatoire : mvwb build --data ... --out ... && mvwb check --data ... ; le nombre de fichiers manquants doit être 0, sinon corrigez les chemins ou regénérez.
La page est statique en file://, les chemins relatifs sont basés sur le répertoire contenant workbench.html ; ne les convertissez pas manuellement en chemins absolus.

4.2 Cycle de révision

La génération est terminée, que faut-il modifier ? Quelle MV, quel segment vidéo, quelle image / chanson ?

Ne réexécutez que les éléments pointés ; nouvelle version + historique.
Une fois la musique locked, elle ne peut plus être modifiée ; changer de musique = créer un nouveau MV.
Pour un même lot, effectuez d'abord une déduplication approximative de la musique : genre + gamme BPM + vocal ne peuvent pas tous être identiques ; si les 10 premières secondes ressemblent à la même chanson, changez music_id.
Assets qa: pass / warn / fail : fail doit être relancé ; warn nécessite une confirmation de l'utilisateur avant utilisation.
Modification d'un asset → les segments vidéo qui en dépendent sont marqués stale.
Modification du plan storyboard / segment vidéo → les segments vidéo correspondants sont stale.
L'utilisateur dit « version finale / approuvé » → l'étape correspondante est locked.

4.3 Livraison

Une fois tous les segments vidéo locked :

Écrivez handoff_v1.json (ou handoff_v1.csv).
Vérifiez chaque segment : video_file existe, duration ≤10s, music_start/end cohérents avec la timeline.
Projet terminé ; le monteur récupère les segments vidéo et le handoff pour l'étape suivante.

MV suivant : dans le même workbench, continuez avec MV002, réutilisez les règles de musique et d'assets déjà verrouillées, sortez d'abord le cadre puis générez ; pour changer de paroles / client, utilisez mvwb init <nom_du_projet> pour créer un nouveau workspace, ne remplacez pas l'ancien projet.

Règles de révision / version

Statut	Signification	UI
`not_started`	Non généré	Cercle gris
`draft`	Artefact en attente de révision	Cercle ambre
`locked`	Version finale	Cercle vert
`stale`	Élément amont modifié, doit être relancé	Cercle orange
`failed`	Échec	Cercle rouge

Si l'élément amont n'est pas locked, l'élément aval ne commence pas.
Modifiez uniquement les éléments pointés ; les autres sont conservés mot pour mot.
L'historique n'est pas écrasé ; spent cumule le coût historique.
Le workbench n'affiche que la couleur du cercle, pas le texte du statut.

Routage des modèles et des prompts

Étape	Défaut	Référence
Musique ACE-Step	`2075301815628943362`	`references/prompts/ace.md`
Assets MOSS	`2116462203997081601`	`references/prompts/moss.md`
Vidéo H3 multi-param	`2110943749894402050`	`references/prompts/h3.md`
Vidéo Muse (Router)	`muse-video-ext`	`references/prompts/muse.md`
S2V synchronisation labiale	`1979183169033375745`	`references/prompts/h3.md`
API RunningHub	—	`references/providers/runninghub.md`
API / solde Router	—	`references/providers/router.md`
Contrat DATA du workbench	—	`references/workbench-contract.md`
Contrat d'exécution en 4 étapes	—	`references/step-contract.md`
Variation / différenciation / déduplication	—	`references/variation.md`
Distribution / import des clés	—	`references/key-distribution.md`
Table des codes d'avis / alarmes	—	`references/alerts.md`
Fiche personnage / style / beaux gosses / réconfortant	—	`references/prompts/casting-style.md`
Champs de livraison	—	`references/handoff.md`

La vidéo confirme le modèle par segment ; différents segments peuvent utiliser des modèles différents, mais le pack de style / l'étalonnage doit être cohérent pour un même MV.
Images de référence multiples : vues du personnage (pas de vue de dos), planche scène, accessoires, photo produit ; une image par fonction ; exécutez d'abord 1 segment d'échantillon.

Clés

Source unique : ~/.config/mv-workbench/keys.json (0600).
Configuration : mvwb keys set runninghub, mvwb keys set router (saisie masquée dans le terminal).
Solde : mvwb keys balance --data workspaces/<projet>/data.json → mvwb build.
La clé brute n'entre pas dans HTML / DATA / logs ; DATA.keys ne contient que le masque et le snapshot du solde.
Les commandes de génération passent systématiquement par mv_keys.py exec pour l'injection ; ne dépendez pas d'une clé résiduelle dans le shell.

Commandes courantes

mvwb doctor
mvwb open
mvwb open --workspace mon_projet
mvwb init mon_projet
mvwb keys status
mvwb keys import --file workspaces/mon_projet/zz-keys.json --delete-source
mvwb keys watch --timeout 600 --data workspaces/mon_projet/data.json
mvwb keys balance --data workspaces/mon_projet/data.json
mvwb quote --model muse-video-ext --seconds 2
mvwb build --data workspaces/mon_projet/data.json --out workspaces/mon_projet/workbench.html
mvwb check --data workspaces/mon_projet/data.json
mvwb rh --app <id> --name <tag> --overrides <json> --out <dir>
mvwb muse --prompt "..." --seconds 2 --size 720x1280 --out out.mp4
python3 scripts/providers/tokentech_task.py image --prompt "..." --seed 123 --out out.png
python3 scripts/providers/tokentech_task.py music --lyrics "..." --style "..." --seconds 60 --out out.mp3
mvwb timeline <lyric.json> <audio.mp3> --out <dir>

Ce qui n'est pas fait

Pas de montage brut, pas d'assemblage, pas de sous-titres / mixage / version finale.
Pas de révision automatique ; l'utilisateur demande une modification, ne réexécutez que les éléments pointés.
Ne soumettez pas les paroles / storyboard / matériaux du client dans un dépôt public.

Fichiers

SKILL.md          Entrée de l'agent (ce fichier)
start/            Entrée humaine : installation, commande mvwb, configuration des clés en un clic
scripts/          mvwb, keys, alerts, build, timeline, providers
references/       Contrat workbench, contrat des étapes, codes d'avis, prompts, fournisseurs
templates/        workbench.html
contracts/        Contrats timeline / storyboard / segments / mv
demo/             Demo original (ouvrable directement)
config/           Prix des modèles / taux de change fx / exemple de clés
workspaces/       Projets étudiants (un répertoire par projet)

Versions

v0.4.4 (2026-11-14) : Protocole des tâches Router testé en réel (MOSS génération d'image / ACE génération de musique) : POST /v1/responses + metadata.nodeInfoList direct vers le nœud RunningHub ; nouveau scripts/providers/tokentech_task.py ; tous les paramètres (durée / BPM / paroles / style / négatif / seed) sont contrôlables ; facturation selon le temps d'exécution RH.
v0.4.3 (2026-11-14) : Simplification de l'UI du workbench — suppression de la configuration des clés dans la page ; solde affiché en chiffres sans masque ; suppression du logo cumulé en haut du MV ; alignement des états vides musique / assets ; retrait des mentions « Lecture seule » ; ordre de la barre du haut : heure de génération → solde.
v0.4.2 (2026-11-14) : Réorganisation des répertoires — les fichiers d'entrée (installation / mvwb / setup-keys) vont dans start/, les fichiers développeur dans dev/ et docs/ ; l'exemple de clé renommé config/zz-keys.example.json ; le répertoire racine ne contient que SKILL / README / LICENSE / NOTICE.
v0.4.1 (2026-11-14) : Format d'avis unifié (scripts/alerts.py + table des codes references/alerts.md) ; la clé de secours passe par l'avis B001 transmis à l'enseignant ; intégration complète de keys / providers / check / build ; nouvelle section « Transmettez le texte de l'avis à l'enseignant ».
v0.3.9 (2026-11-14) : Le fichier de clé fourni par l'enseignant est systématiquement nommé zz-keys.json ; le watcher reconnaît à la fois mv-keys-import*.json et zz-keys.json.
v0.3.8 (2026-11-14) : Simplification du JSON de fourniture des clés en deux champs {"runninghub":"...","router":"..."} ; issued_to / expires_at / mv_keys_import deviennent facultatifs, nécessaires uniquement pour l'enregistrement ou la collecte automatique par le watcher.
v0.3.7 (2026-11-14) : Nouveau standard de fourniture des clés par l'enseignant : zz-keys.json placé dans la racine du projet, keys import --delete-source ; format exemple et règles de fourniture dans references/key-distribution.md.
v0.3.6 (2026-11-14) : Nouveau mvwb keys watch ; l'agent écoute d'abord le répertoire de téléchargement, l'utilisateur remplit la clé dans le workbench et la télécharge → importation automatique / suppression, optionnellement rafraîchir le solde et reconstruire le workbench.
v0.3.5 (2026-11-14) : « Configurer la clé » en haut à droite du workbench → saisie locale → téléchargement de mv-keys-import.json → agent keys import --delete-source ; sans service, sans réseau.
v0.3.4 (2026-11-14) : setup-keys en un clic (Mac/Win) ; keys set refuse en environnement non interactif (ne fait pas traceback) ; vignette vidéo dans le workbench affiche la première frame ; keys init ajuste l'option --data.
v0.3.3 (2026-11-14) : Nouvelles règles de variation / différenciation et pack de prompts de style personnage (style Xiaohongshu / animé japonais doux / coréen chic / film réconfortant / beaux gosses) ; Étape 3 exige génome et tableau de différenciation.
v0.3.2 (2026-11-14) : Alignement avec le manuel utilisateur : clé saisie localement par l'utilisateur ; ajout du nom du projet / confirmation en trois étapes, verrouillage de la musique et écart de durée, QA des assets, devis en cas de modification majeure, répertoire data.json.
v0.3.1 (2026-11-14) : Installation / mise à jour conserve les workspaces ; init par défaut projet vide (--demo copie le demo) ; build/check avec chemins relatifs revenant au répertoire racine du skill ; documentation allégée dans le package.
v0.3.0 (2026-11-14) : Suppression du service en arrière-plan, le workbench redevient purement statique ; clés / solde passent en CLI ; nouveau contrat d'exécution en 4 étapes et mvwb check ; correction du passage des paramètres.

zz-mv-gongzuotai

Qu'est-ce que zz-mv-gongzuotai ?

Demander à votre IA préférée

Documentation