Humaniser les sorties
Créez un travail utile dans son contexte réel, pas seulement un contenu qui ressemble à une réponse soignée. Considérez « l'odeur d'IA » comme un problème de qualité de la sortie : contexte manquant, preuves faibles, structure générique, langage ornemental ou décisions irréalistes. N'affirmez jamais que le style prouve la paternité de l'IA.
Principes fondamentaux
- Contexte avant modèle : adaptez-vous au lecteur, à la tâche, au dépôt, au support et aux contraintes avant de choisir une structure.
- Clarté avant sophistication : préférez le langage le plus précis que le public puisse comprendre.
- Fond avant forme : supprimez le contenu qui n'aide personne à décider, agir, implémenter ou vérifier.
- Preuve avant affirmation : sourcez, qualifiez ou étiquetez les affirmations ; n'inventez pas de faits, de statistiques, de citations, d'API ou de capacités.
- Finalité avant convention : n'utilisez les titres, tableaux, cartes, motifs et abstractions que lorsqu'ils aident la tâche.
- Jugement humain avant automatisation : considérez les résultats du lint comme des invites à la révision, pas comme des verdicts automatiques.
Choisissez un mode
Utilisez le mode Génération par défaut. Appliquez ces principes en produisant l'artefact demandé, puis effectuez une brève vérification de livraison avant de répondre.
Utilisez le mode Révision lorsque l'utilisateur fournit un artefact existant, demande explicitement une critique/révision, ou que la tâche est à enjeux élevés. Diagnostiquez les problèmes importants, révisez l'artefact directement si vous y êtes autorisé, et validez le résultat.
Flux de travail
- Établissez le contrat de sortie à partir du contexte disponible :
- public et objectif pratique ;
- support et format demandés ;
- conventions et contraintes du projet ;
- preuves ou vérifications attendues ;
- ce que signifie « prêt à l'emploi ». Ne demandez que lorsqu'une réponse manquante modifierait matériellement le résultat. Sinon, faites la plus petite hypothèse sûre et énoncez-la brièvement si pertinent.
- Sélectionnez le domaine principal et lisez uniquement son fichier de référence. N'ajoutez un second domaine que pour un artefact véritablement mixte.
- Produisez ou inspectez l'artefact selon cinq questions :
- Répond-il à la demande réelle plutôt qu'à une version générique de celle-ci ?
- Chaque affirmation importante est-elle étayée, qualifiée ou marquée pour vérification ?
- La structure reflète-t-elle les priorités et le flux de travail plutôt qu'un modèle standard ?
- Le langage, la profondeur technique et la conception sont-ils adaptés au public ?
- Le résultat peut-il être utilisé ou vérifié sans combler des lacunes évidentes ?
- Révisez en supprimant le bruit avant d'ajouter du contenu. Préservez la terminologie précise, la structure utile, la voix de l'auteur et les conventions du projet.
- Effectuez la vérification de livraison et renvoyez l'artefact demandé. N'ajoutez pas d'essai de révision à moins qu'il n'aide l'utilisateur ou qu'il ne l'ait demandé.
Routage par domaine
| Artefact | Fichier à lire |
|---|---|
| Issue GitLab/GitHub, tâche, exigence, critère d'acceptation | references/issue.md |
| README, guide d'API, documentation technique ou générale | references/documentation.md |
| Proposition d'architecture, ADR, conception système, choix technologique | references/architecture.md |
| Code, commentaires, nommage, abstractions, plan d'implémentation | references/code.md |
| UI/UX, console d'administration, tableau de bord, spécification de composant ou de page | references/ui-ux.md |
| Diapositives, briefing technique, revue de projet, plan de présentation | references/presentation.md |
| Réponse de chat, explication, recommandation, Q&R quotidien | references/conversation.md |
Pour les symptômes linguistiques transversaux, consultez aussi references/language.md lorsque le wording lui-même est un problème central. Ne chargez pas chaque référence par défaut.
Sévérité de la révision
- P0 — Bloquant : erreur factuelle, preuve ou citation fabriquée, problème de sécurité/sûreté, ou flux principal cassé. À corriger avant livraison.
- P1 — Majeur : instructions inutilisables, décision centrale non étayée, contexte critique manquant, ou exigence principale floue. À corriger avant livraison.
- P2 — Qualité : formulation générique, répétition, abstraction inutile, design décoratif, ou résidu visible de motif IA qui affaiblit l'artefact. À corriger généralement.
- P3 — Préférence : choix stylistique optionnel sans effet significatif. Ne forcez pas le changement.
En mode Révision, ne signalez que les résultats significatifs. Utilisez ce format compact lorsqu'un rapport est utile :
### P1 — [problème spécifique]
- Preuve : [citation ou décision visible]
- Impact : [pourquoi cela empêche l'artefact de remplir son rôle]
- Correction : [changement concret]
- Révision : [texte de remplacement ou direction d'implémentation, si utile]
Jugement linguistique
Ne transformez pas l'humanisation en un exercice d'interdiction de mots. Des termes comme « gating », « convergence », « orchestration » ou leurs équivalents chinois peuvent être exacts dans le bon domaine. Conservez un terme lorsqu'il est standard pour le lecteur visé et plus précis qu'un substitut en langage simple.
Adaptez la langue du livrable demandé. Pour une sortie en chinois, privilégiez l'ordre naturel de l'information chinoise et l'usage technique chinois établi ; ne conservez pas la structure de phrase anglaise simplement parce qu'elle est grammaticalement traduisible. Lisez references/language.md pour des vérifications spécifiques au chinois lorsque le wording est une préoccupation centrale. Conservez les abréviations standard comme API, ADR, SSO et UI/UX lorsqu'elles sont plus claires pour les lecteurs visés que des traductions forcées.
Recherchez des regroupements plutôt que des éléments isolés : cadres vides, langue de traduction, affirmations théâtrales, conclusions répétées, titres excessifs, listes uniformes en trois parties et verbes gonflés peuvent se combiner en une voix générique. Réécrivez la pensée sous-jacente, pas seulement le mot signalé.
Le linteur optionnel utilise data/zh-output-smells.json pour identifier les candidats. Il inclut des règles lexicales et syntaxiques chinoises, des suggestions de réécriture, la sévérité et des exemptions contextuelles pour un usage technique légitime :
python scripts/humanize_lint.py <fichier> [<fichier> ...]
python scripts/humanize_lint.py --list
python scripts/humanize_lint.py <fichier> --format json --fail-on P2
Le seuil de sortie par défaut est P1. N'utilisez --fail-on P2 que lorsque un projet traite délibérément la sortie générique comme un critère de livraison ; utilisez --fail-on none pour des scans consultatifs. Les blocs de code et le code en ligne sont ignorés sauf si --include-code est fourni.
Inspectez chaque résultat dans son contexte. Lisez sa context_note avant de modifier des termes techniques comme « 门控 », « 收敛 », « 原语 » ou « 心智模型 ». Ne réécrivez jamais uniquement pour que le linteur passe.
Vérification de livraison
Avant de renvoyer le résultat :
- Confirmez que le format et le périmètre demandés sont satisfaits.
- Supprimez les affirmations non étayées, les détails inventés, les espaces réservés, les conclusions répétées et les sections de modèle inutilisées.
- Confirmez que les exemples, commandes, API, conceptions ou recommandations sont plausibles dans l'environnement indiqué ; testez-les lorsque la tâche le permet.
- Vérifiez que l'ouverture atteint le point utile et que la conclusion fournit la décision, l'action ou le résultat nécessaire.
- Préférez l'artefact lui-même aux commentaires sur la qualité de sa rédaction.
Consultez examples/before-after.md pour des exemples d'Issue, d'architecture et d'UI. Utilisez-les comme exemples de raisonnement, pas comme modèles.