Public cible : Développeurs utilisant des outils de programmation IA (tels que Cursor, Windsurf, trae...) et responsables techniques manquant de sensibilisation aux coûts de l'IA.

Point central : Les Tokens ne sont pas seulement une simple unité de facturation, mais une « ressource d'attention » et une « monnaie de puissance de calcul ». L'utilisation abusive du mode Agent et la négligence de la gestion du contexte reviennent à masquer une paresse stratégique (ne pas réfléchir soi-même) par une diligence tactique (laisser l'IA faire n'importe quoi).

Vos « dépenses en IA » pourraient être supérieures à votre salaire

Il y a quelques jours, j'ai vérifié ma facture de Tokens. J'ai été un peu surpris en voyant le chiffre : 10 millions de Tokens. Attention, ce n'est pas la consommation d'un mois, c'est une journée.

Je pensais que c'était déjà énorme. Plus tard, j'ai publié une courte vidéo sur le calcul des Tokens.

Résultat, la section des commentaires m'a montré ce que signifie « il y a toujours plus fort que soi ».

L'image ci-dessous est une capture d'écran de l'enregistrement de la consommation de deux cents millions de Tokens en une journée par l'internaute « La routine de Lao K » :

Au début, je pensais que c'était peut-être un cas isolé, mais lorsque de nombreux internautes ont laissé des messages disant qu'ils consommaient 100 millions de Tokens par jour, j'ai compris que c'était un phénomène très courant.

Que représente un milliard de Tokens ? Si l'on calcule selon le niveau de facturation courant des « modèles commerciaux grand public » (facturation séparée de l'entrée/sortie, estimation grossière d'environ 10 dollars US / million de Tokens), cela représente 1000 dollars US brûlés en une journée. 7000 yuans RMB brûlés en une journée. Le salaire mensuel de nombreux programmeurs débutants pourrait ne pas suffire à l'IA pour « réfléchir » pendant cette journée.

(Remarque : les différences de prix entre les différents modèles/fournisseurs sont importantes, et le prix unitaire de l'entrée et de la sortie est souvent différent. Le but ici n'est pas de calculer avec précision jusqu'à la deuxième décimale, mais d'établir d'abord un « sens de l'échelle ».)

Si vous souhaitez recalculer vous-même, voici généralement une formule (en ignorant les règles spéciales telles que la mise en cache/les remises) : Coût ≈ (Nombre de Tokens en entrée / 1 000 000) × Prix unitaire_entrée + (Nombre de Tokens en sortie / 1 000 000) × Prix unitaire_sortie

C'est très contre-intuitif. Nous pensons toujours que l'IA est bon marché, et OpenAI prévoit même de baisser les prix. Mais pourquoi, dans la pratique, la consommation de Tokens explose-t-elle de manière exponentielle ?

Aujourd'hui, nous allons décortiquer en profondeur la logique derrière ce « trou noir de Tokens » et comment nous pouvons arrêter les pertes.

I. Pourquoi les Tokens « explosent-ils de manière exponentielle » ?

Beaucoup de gens n'ont aucune idée du volume de Tokens. Ils pensent : « Oh, ce n'est que l'envoi de quelques lignes de code, combien cela peut-il représenter ? »

1. Calculons clairement

Nous devons d'abord établir une perception quantitative suffisante pour un usage pratique. Soyons clairs : Les Tokens ne sont pas des mots, ni des caractères. Il s'agit de « fragments de codage » après que le modèle a divisé le texte. Différents modèles utilisent différents tokenizer, il ne peut donc y avoir qu'une fourchette, pas une constante « universelle ».

Considérez les chiffres suivants comme des « règles d'estimation » (dans le but de juger l'échelle, d'estimer les coûts et de prendre des décisions d'arrêt des pertes) :

• 1 caractère chinois : généralement 1 à 2 Tokens (les caractères à haute fréquence sont plus proches de 1, les caractères/combinaisons rares sont plus susceptibles d'atteindre 2 à 3)

• 1 mot anglais : généralement environ 1,2 à 1,5 Tokens (une estimation grossière de 1,3 est également possible)

• 1 ligne de code ≈ 10 à 50 Tokens (y compris l'indentation, les commentaires, les déclarations de type)

• Logique métier simple ≈ 12 à 20 Tokens

• Avec annotations de type, interface, JSDoc, indentation de 4 espaces ≈ 20 à 35 Tokens

• Avec beaucoup d'importations / décorateurs / commentaires ≈ 30 à 50+ Tokens

• 1 fichier source (400 à 600 lignes, projet TS/Java moderne) ≈ 4 000 à 24 000 Tokens est courant (médiane ≈ 12 000 à 18 000)

• 1 projet de taille moyenne (100 à 200 fichiers source, en ne comptant que src/, sans node_modules/ / code généré)

• « Lire attentivement » le code source principal représente souvent au moins un million de Tokens

• Si vous ajoutez les tests, la configuration, les scripts, les déclarations de dépendances et les journaux, il n'est pas rare d'atteindre des dizaines de millions de Tokens

Les projets front-end actuels sont tous en TypeScript, remplis de définitions d'interface complexes ; ou en Java, avec des dizaines de lignes d'importations. Ce « code passe-partout » est en fait un tueur de Tokens. Un projet de taille moyenne, s'il comporte 100 fichiers, le simple fait de laisser l'IA « lire le code » peut directement consommer 1 million de Tokens.

2. L'effet « boule de neige » des tokens

La consommation de Tokens la plus terrible n'est pas une conversation unique, mais l'accumulation du contexte dans les conversations multiples.

Le mécanisme du LLM est sans état. Pour que l'IA se souvienne de ce que vous avez dit précédemment, le système regroupe généralement « l'invite système + l'historique des conversations + les fichiers/extraits de code que vous avez référencés + la sortie de l'appel d'outil (par exemple, les résultats de recherche, les journaux d'erreurs) » et l'envoie au modèle. Vous pensez que vous n'avez posé qu'une seule question, mais vous payez en fait à plusieurs reprises pour « l'ensemble du paquet de contexte ».

• 1er tour : envoi de 10 000 Tokens, l'IA répond avec 1 000.

• 2e tour : envoi de (10 000 + 1 000 + nouvelle question), l'IA répond...

• 10e tour : votre contexte peut déjà avoir gonflé à 200 000 Tokens.

À ce stade, même si vous ne posez qu'une seule question « aidez-moi à modifier un nom de variable », vous consommez également les frais de 200 000 Tokens. C'est pourquoi vous avez l'impression de n'avoir rien fait, mais votre facture monte en flèche.

Plus grave encore : le mode Agent « lit activement les fichiers ». Vous dites « aidez-moi à optimiser le module utilisateur », il peut d'abord parcourir les répertoires associés, puis remonter aux dépendances, puis à la configuration, puis aux tests... Il ne s'agit pas de paresse, mais de « s'acquitter de ses responsabilités selon la stratégie par défaut », et la stratégie par défaut est souvent : lire plus, essayer plus, itérer plus.

II. Deux types de « paresse » ruinent vos compétences en ingénierie

Après avoir analysé les « gars à un milliard » dans la section des commentaires, j'ai découvert que la racine de l'explosion des Tokens n'est pas seulement le problème du mécanisme de consommation de l'IA, mais aussi étroitement liée à la paresse des gens.

Voici deux types typiques de « paresse de la pensée ».

Paresse 1 : Le type « je me décharge de tout »

Avez-vous aussi cet état d'esprit :

• « Ce vieux projet est trop désordonné, je suis trop paresseux pour regarder la logique, je vais simplement le donner à l'IA. »

• « Cursor a sorti le mode Agent, c'est génial, laissez-le corriger les bugs lui-même. »

Vous donnez donc l'ensemble du dossier src à l'Agent et donnez une instruction vague : « Aidez-moi à optimiser le module utilisateur. » L'Agent commence à travailler :

• Il lit 50 fichiers (consommation de 500 000).

• Il découvre qu'il fait référence à utils, et va lire les classes d'outils (consommation de 200 000).

• Il essaie de modifier, il y a une erreur, il lit les journaux d'erreurs (consommation de 100 000).

• Il essaie de réparer, il y a encore une erreur...

Il essaie et échoue frénétiquement, consommant frénétiquement des Tokens. Et vous ? Vous faites défiler votre téléphone, pensant que vous êtes vraiment efficace. La vérité est : vous échangez une « pseudo-efficacité » contre de l'argent, produisant un tas de code que vous ne pourrez pas maintenir plus tard.

Plus professionnellement, il y a deux types de pertes ici :

• Couche de coût : l'entrée de Tokens devient plus importante, le nombre d'itérations augmente, les coûts s'additionnent linéairement

• Couche d'ingénierie : vous perdez le contexte et le pouvoir de décision, et il ne reste plus qu'un système incontrôlable « qui fonctionne »

Paresse 2 : Le type « tout mélanger »

Lorsque vous rencontrez un bug, comment le donnez-vous à l'IA ? Copiez-vous directement l'ensemble de la console d'erreurs avec Ctrl+A, ou laissez-vous directement l'IA trouver elle-même avec @Codebase ?

C'est ce qu'on appelle « tout mélanger ». Vous êtes trop paresseux pour localiser le cœur du problème, trop paresseux pour filtrer les extraits de code clés. Vous donnez à l'IA 99 % d'informations invalides (bruit) et 1 % d'informations valides (signal) en même temps.

L'IA est comme un amplificateur.

• Vous lui donnez une logique claire (signal), elle amplifie votre sagesse, consomme moins de Tokens et a un bon effet.

• Vous lui donnez de la confusion et du flou, elle amplifie votre confusion, les Tokens montent en flèche et produisent des déchets.

III. Solution : Comment utiliser l'IA efficacement et réduire la consommation de Tokens

Pour protéger votre portefeuille, il est plus important de protéger votre pouvoir de contrôle de l'ingénierie, nous devons changer notre mode de collaboration avec l'IA.

1. Principe du contexte minimal

C'est le principe fondamental de la programmation IA. Ne donnez jamais à l'IA que l'ensemble de code minimal correspondant au problème actuel à résoudre.

Dans Cursor, utilisez bien ces opérateurs :

• @File : ne référencez que les fichiers pertinents, pas l'ensemble du dossier.

• Ctrl+L** Sélectionner le code** : n'envoyez que les 50 lignes de code sélectionnées par le curseur au Chat, pas l'ensemble du fichier.

• @Docs : pour les bibliothèques tierces, référencez la documentation au lieu de la laisser deviner.

Voici un SOP structuré et réutilisable que j'utilise souvent (si vous le suivez, les Tokens diminueront visiblement) :

Ce paragraphe signifie : lors de la collaboration avec l'IA, il faut faire attention à l'efficacité et à la précision. Les pratiques spécifiques sont les suivantes :

• Définir d'abord l'objectif : indiquer brièvement et clairement à l'IA le problème actuel et le résultat souhaité, ne pas la laisser deviner elle-même.

• Simplifier la reproduction du problème : utiliser la méthode la plus simple pour reproduire le problème au lieu d'une méthode complexe, coller le code le plus petit et le plus critique, ne pas empiler un tas de contenu non pertinent.

• Fournir le minimum d'informations nécessaires : ne donner que 1 à 3 fichiers pertinents, les fonctions clés et les premières lignes de la pile d'erreurs, pas toutes les informations.

• Demander le retour des points de modification : demander à l'IA de ne vous dire que où modifier et pourquoi modifier, ne pas la laisser réécrire tout le code en long et en large.

• Enfin, vous vous en occupez vous-même : effectuez la vérification la plus simple pour vous assurer que les modifications n'affectent pas d'autres endroits.

En bref, il s'agit d'utiliser le moins d'informations possible et les plus critiques pour faire travailler l'IA, et de conserver le pouvoir de contrôle et de jugement final.

2. Et le plus important : réfléchir d'abord, puis Prompt, planifier d'abord, puis agir

Avant d'appuyer sur Entrée, forcez-vous à vous arrêter pendant 10 secondes et posez-vous trois questions :

• Quel problème suis-je en train de résoudre ? (Définir les limites)

• Quels sont les modules principaux concernés par ce problème ? (Filtrer le contexte)

• Si je devais l'écrire moi-même, comment l'écrirais-je ? (Fournir des idées)

Vous êtes le 1, l'IA est le 0 derrière. Si le 1 ne tient pas debout, peu importe le nombre de 0 derrière, ce n'est qu'une consommation inutile.

Quelques mots du fond du cœur

L'histoire de « un milliard de Tokens par jour » ne se produira peut-être pas pour tout le monde. Mais le gaspillage de Tokens est une expérience que presque tous les programmeurs utilisant la programmation IA ont vécue.

Bien que l'IA rende la programmation plus simple, il existe toujours des obstacles. Ceux qui savent vraiment l'utiliser seront comme un tigre avec des ailes.

Auparavant, le code de mauvaise qualité que vous écriviez ne faisait qu'« énerver » vos collègues. Maintenant, la paresse que vous volez se transformera directement en chiffres sur la facture, vous punissant avec des coûts qui montent en flèche.Alors, ne soyez pas un « laissez-faire ». Soyez un architecte IA qui pense en profondeur, s'exprime avec précision et planifie avant d'agir. C'est aussi notre plus grande irremplaçabilité à cette époque.