Sortie claire
Aidez le lecteur à comprendre avec précision, à examiner les preuves et à décider quoi faire avec moins d’effort. Identifiez ce que le lecteur doit comprendre ou vérifier, puis choisissez la représentation avant de peaufiner le libellé. Considérez le temps passé à lire, explorer et vérifier la sortie. Cette compétence s’applique à la tâche en cours ; n’en faites pas un mode de conversation permanent sauf demande de l’utilisateur.
Choisir la langue avant le libellé
- Suivez les exigences explicites de l’utilisateur concernant la langue et le format de sortie.
- Lors de l’édition d’un artefact existant, préservez sa langue sauf si une traduction est demandée. Les explications concernant la modification peuvent utiliser la langue de la conversation.
- Sinon, suivez la conversation en cours. Suivez un changement de langue clair dans la demande de l’utilisateur. Les citations, les journaux, le code, les résultats d’outils et la langue de cette compétence ne changent pas eux-mêmes la langue de réponse.
- Préservez les termes techniques et le contenu littéral en langues mixtes. Ne traduisez pas un échange de débogage en anglais en chinois simplement parce que cette compétence prend en charge le chinois.
- Si l’utilisateur demande du JSON, un bloc de code ou un modèle particulier, respectez ce contrat. N’ajoutez aucune annonce de compétence ni préfixe de statut.
Préserver le sens
Pour une réécriture, utilisez la source et le contexte explicitement fourni comme limite factuelle. Préservez :
- les acteurs, objets, portée, conditions, exceptions et ordre, y compris les actions qui doivent se produire ensemble ;
- les valeurs, unités, bornes, approximations, dates, identifiants et relations causales ;
- la différence entre fait, hypothèse, recommandation, obligation, permission et capacité.
Ne transformez pas may en will, should en must, about 5 seconds en 5 secondes, ou 尽快 en une date limite inventée. Ne choisissez pas une interprétation d’une borne ou d’un pronom ambigu sans preuve. Gardez l’ambiguïté visible ou identifiez exactement quelle information manque. Une réécriture peut rester plus longue pour préserver ces distinctions.
Pour une nouvelle explication, un contexte pertinent et des exemples sont utiles. Séparez les hypothèses des faits établis ; étiquetez les exemples hypothétiques si nécessaire. N’impliquez pas qu’une action ou un test a été effectué sans preuve.
Préservez exactement le code, les commandes, les chemins, les noms de champs, les journaux, les chaînes d’erreur et les citations fixes lorsqu’ils sont repris dans la sortie. Si la tâche demande explicitement d’éditer l’un d’eux, effectuez cette modification dans son périmètre ; les règles de prose ne justifient pas de modifications supplémentaires.
Choisir une représentation qui fait le travail utile
Envisagez activement un visuel lorsque le lecteur doit reconstruire mentalement des relations, comparer plusieurs dimensions, suivre des états changeants ou explorer une variable. Si le visuel rend ce travail matériellement plus facile, créez-le dans le cadre de la tâche autorisée sans attendre une demande distincte de diagramme. Gardez les réponses directes courtes en prose lorsque cela sert déjà la tâche.
| Ce que le lecteur doit faire | Forme de départ utile |
|---|---|
| Obtenir un fait, une réponse brève ou une modification de phrase fidèle | Texte |
| Comparer des options selon les mêmes critères | Tableau |
| Tracer des embranchements, dépendances, participants ou ordre des messages | Diagramme de flux, de dépendance ou de séquence |
| Comprendre une disposition spatiale ou une caractéristique visible | Image annotée ou schéma |
| Voir un modèle dans les données numériques fournies | Graphique avec étiquettes, unités et une échelle appropriée |
| Explorer comment les entrées modifient un résultat | Explication interactive fonctionnelle avec des contrôles significatifs |
| Suivre un mouvement, une évolution ou une séquence d’enseignement par étapes | Animation ou vidéo explicative lorsque cela est faisable et utile |
Ce sont des points de départ, pas un classement où la vidéo gagne toujours. Un petit artefact personnalisé peut être utile pour une seule question. Préférez la forme qui réduit suffisamment le travail du lecteur pour justifier le temps de génération, la navigation et l’interaction. Respectez les demandes explicites de texte brut, JSON, d’un format de fichier existant ou d’absence d’artefacts.
Livrez la forme sélectionnée, pas seulement une offre de la créer. Utilisez les capacités de rendu disponibles et inspectez le résultat ; testez les interactions pertinentes. Si les outils de rendu ou de média ne sont pas disponibles, fournissez une alternative prise en charge utilisable et dites exactement ce qui a été produit. La source d’un diagramme, un storyboard et une vidéo rendue sont des livrables différents. N’exigez pas un fournisseur particulier et ne publiez, téléchargez ou n’utilisez pas de services payants uniquement parce qu’un visuel serait utile.
Préservez également le sens dans les encodages visuels : étiquetez les branches et les significations des flèches, gardez les actions simultanées simultanées, marquez les hypothèses et les données manquantes, et maintenez des unités et une échelle honnêtes. Un diagramme soigné ne doit pas impliquer une cause non étayée ou un test terminé. Rendez les étiquettes lisibles ; ne vous fiez pas uniquement à la couleur. Fournissez un bref résumé ou un équivalent textuel lorsque le contrat de sortie le permet, sans répéter toute l’explication sous plusieurs formes.
Pour un diagramme, un graphique, une explication interactive ou une animation, lisez references/output-forms.md pour obtenir des conseils de sélection et de vérification.
Adapter la structure à la tâche
- Explication : répondez d’abord à la question principale, puis donnez le raisonnement nécessaire pour la comprendre. Gardez des exemples utiles, des liens de causalité et des nuances.
- Débogage : distinguez observation, hypothèse, vérification et action suivante. Dites ce qu’un contrôle a établi et où l’incertitude demeure. Posez une vraie question lorsqu’un fait manquant change l’action.
- Procédure : placez les conditions nécessaires avant l’action concernée. Utilisez des étapes numérotées lorsque l’ordre compte. Séparez les actions humaines du comportement automatique du système. Gardez les actions simultanées ou inséparables ensemble. Lors de l’identification d’informations opérationnelles manquantes, vérifiez quel objet ou acteur est visé ainsi que les quantités, unités, références de mesure et conditions de début/fin. Demandez ce qui est nécessaire pour utiliser l’instruction ; ne fournissez pas vous-même les faits manquants.
- Réécriture ou révision : améliorez uniquement le périmètre demandé. Si un passage fonctionne déjà, conservez-le. Fournissez des explications sur les modifications uniquement lorsqu’elles sont demandées ou lorsqu’une ambiguïté non résolue nécessite l’attention du lecteur.
Préférez des phrases courtes et explicites, des verbes concrets et des noms stables pour le même concept. Préservez les distinctions entre les différents concepts. N’appliquez pas de listes noires de mots aux parties de termes techniques, comme 闭环控制 ou request validation.
La longueur des phrases, la voix passive, les synonymes et la politesse sont des choix contextuels, pas des erreurs automatiques. L’anglais peut nécessiter une construction passive ou un temps parfait. Le chinois peut nécessiter un sujet omis lorsque l’acteur est déjà clair. Conservez 可能, 建议, 约, may et approximately lorsqu’ils portent une information.
Vérifier avant de retourner
Comparez une réécriture avec sa source pour détecter les faits modifiés, les conditions perdues, la modalité changée, la précision inventée et les littéraux endommagés. Pour un visuel ou un artefact, vérifiez les mêmes faits dans ses étiquettes, arêtes, états et calculs. Vérifiez que la langue et le format correspondent toujours à la tâche et que le livrable annoncé existe réellement. Supprimez ensuite les répétitions qui n’apportent aucune information.
Les vérifications de style ne peuvent pas prouver l’équivalence sémantique. Signalez un problème concret non résolu au lieu de déclarer le texte certifié ou entièrement vérifié.
Pour les réécritures délicates impliquant la modalité, le mélange de langues ou des faits manquants, lisez references/edge-cases.md.
Pour une réécriture substantielle, une demande de validation explicite ou un glossaire de projet fourni, utilisez le vérificateur local facultatif lorsqu’il peut détecter une erreur concrète. Lisez references/checks.md pour ses entrées et ses limites. Sélectionnez en, zh ou mixed à partir de la tâche, pas du texte cité. Fournissez la source uniquement pour les réécritures fidèles, et encodez les littéraux exacts ou les contraintes JSON uniquement lorsque la tâche les exige. Les réponses simples ne nécessitent pas de script.
Considérez les résultats du vérificateur comme des preuves de portée limitée : corrigez les contrats explicites violés, révisez les changements de sens par rapport à la source et n’utilisez les suggestions de style que lorsqu’elles aident. Préservez les modifications autorisées. Ne réécrivez pas pour supprimer tous les avertissements et ne considérez pas une liste de résultats vide comme une preuve d’équivalence. Après les corrections, revérifiez les contraintes affectées ; si une ambiguïté persiste, signalez-la au lieu de réécrire à plusieurs reprises. Gardez les diagnostics hors d’une réponse demandée en JSON/code uniquement.
Lorsque l’utilisateur pose des questions sur la version ou les mises à jour de cette compétence, lisez references/updates.md. Les tâches d’écriture normales ne déclenchent pas de vérifications réseau des mises à jour et ne modifient pas la compétence installée.