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

Point de vue central : Un Token n'est pas seulement une simple unité de facturation, mais une « ressource d'attention » et une « monnaie de puissance de calcul ». L'abus 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 s'agiter inutilement).

Vos « dépenses en IA » pourraient être plus élevées que 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. Puis j'ai publié une courte vidéo sur le calcul des Tokens.

Résultat, les commentaires m'ont fait découvrir 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 Old K » :

Au début, je pensais que c'était un cas isolé, mais lorsque de nombreux internautes ont commenté 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 se base sur l'échelle de facturation courante de « certains modèles commerciaux courants » (facturation séparée de l'entrée/sortie, estimation grossière combinée à 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 une « sensation d'é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 va même baisser les prix. Mais pourquoi, dans l'ingénierie pratique, la consommation de Tokens explose-t-elle de manière exponentielle ?

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

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

Beaucoup de gens n'ont aucune idée de la quantité de Tokens. Ils pensent : « Oh, ce n'est que quelques lignes de code, combien cela peut-il faire ? »

1. Calculons clairement

Nous devons d'abord établir une perception quantitative suffisante pour l'ingénierie. Soyons clairs : Un Token n'est pas un nombre de mots, ni un nombre de caractères. C'est un « fragment de codage » après que le modèle a divisé le texte. Différents modèles utilisent différents tokenizer, donc on ne peut donner qu'une fourchette, pas une constante « universelle ».

Considérez les chiffres suivants comme des « règles d'estimation » (le but est 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 convient également)

• 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 annotation 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 très courant (médiane ≈ 12 000–18 000)

• 1 projet de taille moyenne (100–200 fichiers sources, 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'Import à chaque fois. Ces « codes passe-partout » sont en fait des tueurs 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 chose la plus terrible concernant la consommation de Tokens n'est pas une seule conversation, mais l'accumulation du contexte dans plusieurs tours de conversation.

Le mécanisme du LLM est sans état. Afin de permettre à l'IA de se souvenir de ce que vous avez dit dans la phrase précédente, le système regroupe généralement « l'invite système + l'historique des conversations + les fichiers/fragments 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 ».

• Tour 1 : Envoi de 10 000 Tokens, l'IA répond avec 1 000.

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

• Tour 10 : Votre contexte peut déjà avoir gonflé à 200 000 Tokens.

À ce stade, même si vous ne posez qu'une seule question « Aidez-moi à changer 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 d'« accomplir son devoir 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 examiné les « gars à un milliard » dans la section des commentaires, j'ai constaté que la racine de la flambée des Tokens n'est pas seulement un problème de mécanisme de consommation de l'IA, mais est également étroitement liée à la paresse des gens.

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

Paresse 1 : Type de gestionnaire absent

Avez-vous aussi cet état d'esprit :

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

• « Cursor a sorti le mode Agent, c'est génial, laissons-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 constate que utils est référencé, et va lire les classes d'outils (consommation de 200 000).

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

• Il essaie de réparer, une autre erreur se produit...

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 votre efficacité est vraiment élevée. La vérité est : vous échangez de la « 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 niveaux de pertes ici :

• Niveau de coût : L'entrée de Tokens augmente, le nombre d'itérations augmente, les coûts s'additionnent linéairement

• Niveau 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 « peut fonctionner »

Paresse 2 : Type fourre-tout

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

C'est ce qu'on appelle « fourre-tout ». Vous êtes trop paresseux pour localiser le cœur du problème, trop paresseux pour filtrer les fragments 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, moins de Tokens sont utilisés, et l'effet est bon.

• 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 efficacement l'IA 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 passage signifie : Lorsque vous collaborez avec l'IA, vous devez faire attention à l'efficacité et à la précision. Les méthodes spécifiques sont les suivantes :

• Définissez d'abord l'objectif : Dites à l'IA de manière concise et succincte le problème actuel et le résultat souhaité, ne la laissez pas deviner elle-même.

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

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

• Demandez le retour des points de modification : Laissez l'IA vous dire seulement où modifier et pourquoi modifier, ne la laissez pas réécrire tout le code en long et en large.

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

En bref, utilisez le moins d'informations possible et les informations les plus critiques pour faire travailler l'IA, et conservez le contrôle et le jugement finaux.

2. Et le plus important : Réfléchissez d'abord, puis invitez, planifiez d'abord, puis agissez

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 sincères

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 facile, il existe toujours des obstacles. Ceux qui savent vraiment comment l'utiliser seront comme un tigre avec des ailes.

Auparavant, le code médiocre que vous écriviez ne faisait qu'« écoeurer » 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 simple « gestionnaire absent ». 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.