Zusammenfassung
- Ein Versuchsbericht (Zero-context, N=5) zeigt, dass der Tokenverbrauch von KI deutlich sank, nachdem die Codestruktur (Strategie-/Factory-Pattern, Dateiaufteilung, Bereinigung von
.cursorrules) mit einem einzeiligen Prompt refaktoriert und anschließend derselbe Prompt zur Funktionserweiterung ausgeführt wurde. Die im Experiment verwendeten Prompts und der Quellcode sind veröffentlicht und damit reproduzierbar.
Kerndaten
-
Claude-4 Sonnet: im Durchschnitt 390,159 → 242,265 Tokens (−37.91%)
-
GPT-5: im Durchschnitt 315,839 → 233,634 Tokens (−26.03%)
-
Grundlage: die von Cursor angezeigten Total Tokens. Ein Vergleich der absoluten Werte zwischen den Modellen ist nicht aussagekräftig (unterschiedliche Zählweise je Modell).
Setup (Kurzfassung)
-
IDE Cursor 1.6.6, Modelle GPT-5 / Claude-4 Sonnet
-
Alle Prompts im Zero-context, bei jeder Runde vollständiger Neustart des Editors
-
Erfolgskriterium: Als Erfolg gewertet wurde, wenn die Anforderungen mit einem einzelnen Prompt umgesetzt wurden
Warum das wichtig ist
-
„Gute Codestruktur“ ist nicht nur für Menschen besser lesbar, sondern hat auch messbaren Einfluss auf Tokens, Kosten und Zeit bei KI
-
Durch die Veröffentlichung von Prompt und Repository ist die Reproduzierbarkeit gesichert (direkt nutzbar für den Praxiseinsatz und Folgeexperimente)
Persönliche Einschätzung
- Als Cursor-Nutzer halte ich das für eine hervorragende Methodik, die einen zentralen Ansatz zur Kostensenkung bietet.
- Wie auch im Haupttext erwähnt, ist die etwas geringe Stichprobengröße allerdings bedauerlich.
34 Kommentare
Haben Sie eine Schlagzeilen-Akademie besucht …
Das Experiment fand ich sehr interessant.
Danke.
Unabhängig vom Inhalt wirkt es wohl noch stärker so, weil der Titel mit der „einzeiligen Prompt“ etwas anderes erwarten lässt als das, worum es im Text tatsächlich geht.
Ja, ich denke genauso. schluchz
Entschuldigung ;;
Vielen Dank für das große Interesse an diesem Beitrag. Da der Hauptzweck offenbar die Verbreitung im Ausland ist, wurde der Artikel auf Englisch verfasst, wodurch wohl verschiedene Probleme entstehen.
Daher teile ich hier einen auf Koreanisch zusammengefassten Beitrag.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Ich fasse ergänzend die Inhalte zu dem verwendeten Prompt zusammen.
Offenbar ist das besonders für Entwickler vorteilhaft, wenn sie Prompts zur Verbesserung der Struktur schreiben. Da jedes Programm unterschiedliche Eigenschaften hat, ist für hocheffiziente Optimierungen ein gewisses Maß an Entwicklungswissen erforderlich.
Das bedeutet jedoch nicht, dass Vibe-Coder ohne Entwicklerhintergrund diese Methode nicht nutzen können. Die Effizienz mag unterschiedlich ausfallen, aber selbst mit einfachen Anweisungen wie „Bitte räume den Projektcode etwas auf. Entferne ungenutzten Code.“ trennt und organisiert die AI Dateien und Klassen.
Allerdings kann der Unterschied im Detailgrad der Strukturverbesserung zu Effizienzunterschieden führen, daher ist beim Referenzmaterial Vorsicht geboten.
Man sollte im Prompt nur das Wesentliche logisch formulieren. Heißt das also, je mehr man diesem und jenem in den Prompt packt, desto mehr Rauschen entsteht und desto komplexer und rauschbehafteter wird auch der daraus resultierende Code?
Der Kern der Aussage ist, dass nach der Anweisung an die AI, die Codestruktur zu refaktorieren, der Tokenverbrauch gesunken ist.
Umgekehrt könnte man auch erklären, dass der Tokenverbrauch steigt, wenn man Befehle in einem Zustand mit strukturellen Mängeln im Code weiterführt.
Zusammengefasst geht es darum, dass die Struktur des Quellcodes verbessert werden muss; es bedeutet nicht, dass der Prompt nur die Kernaussagen logisch verdichtet enthalten sollte.
Auch ich fand diese Einleitung und den Originaltext viel zu weitschweifig und hatte den Eindruck, als wäre er von jemandem geschrieben worden, der nicht besonders gut schreibt, weshalb das Lesen schwierig war.
Der Kern ist
„Füge eine einzeilige Anweisung hinzu, die strukturelle Beschränkungen zur Reduzierung von Tokens enthält.“
so in etwa.
Da dieser Text eher den Charakter einer Studie zum Thema „Experiment“ hat,
liegt der Fokus aller in diesem Text enthaltenen Zahlen darauf, dass alle, die diesen Text lesen, die Ergebnisse „reproduzieren“ können.
Daher wurden sowohl der verwendete Original-Source-Code als auch sämtliche im Test verwendeten Verfahren vollständig dokumentiert,
sodass der Inhalt darauf ausgerichtet ist, Informationen bereitzustellen, mit denen alle Versuchspersonen dieselben Ergebnisse erzielen können.
Wenn ich die Stimmung in den Kommentaren betrachte, habe ich das Gefühl,
ich sollte künftig vielleicht zwei getrennte Texte schreiben: einen mit der Tendenz zu einer Zusammenfassung in drei Zeilen
und einen weiteren für Menschen, die die Details wissen möchten.
Wenn Sie mir mitteilen, welcher Teil dieses Textes als übermäßig komplex oder zu ausführlich empfunden wurde,
würde mir das beim Verfassen künftiger Texte sehr helfen.
Das habe ich ähnlich empfunden.
Ich verstehe zwar die Absicht des Autors, aber im Verhältnis zu dem, was gemacht wurde, wirkt der Text übermäßig komplex.
Vermutlich wurde er so geschrieben, weil möglichst viele der im Experiment verwendeten Details in den Text einfließen sollten.
Wenn Sie aber nur die Kernaussagen knapp herausziehen, werden Leser, die sich für so ein Thema interessieren, es wahrscheinlich trotzdem verstehen.
Wenn Sie mutig Details weglassen und nur das Wesentliche zusammenfassen, wäre es meiner Meinung nach besser.
Ich fand die Absicht des Autors und auch das Ergebnis selbst interessant.
Die Hauptthese ist, dass besserer Sourcecode zu geringerem Token-Verbrauch führt,
und dazu scheint ein entsprechendes Experiment entworfen und durchgeführt worden zu sein.
Wenn ich nur das aufzähle, was ich vom Experiment verstanden habe:
So scheint es zu sein.
Und wenn ich es richtig verstanden habe, lautet das Fazit, dass der per Prompt vorverarbeitete Sourcecode insgesamt weniger Tokens verbraucht.
Ein interessantes Fazit, aber meine Meinung zum Experiment ist wie folgt.
Kein fairer Vergleich
Zahlenmäßig scheint der Verbrauch zwar gesunken zu sein, aber eigentlich müsste man die gesamte Token-Zahl vergleichen, die für die Verarbeitung des Sourcecodes benötigt wurde.
Anders gesagt sollten auch die Tokens berücksichtigt werden, die für die Vorverarbeitung verbraucht wurden.
Wenn die dafür verwendete Token-Zahl übermäßig groß war, wurde in Wirklichkeit insgesamt mehr verbraucht und das Ganze wäre damit bedeutungslos. Und selbst wenn sie gering war, dürfte der tatsächliche Unterschied beim Token-Verbrauch deutlich kleiner sein, als es der Text vermuten lässt.
Ein Vergleich des Sourcecodes vor und nach der Vorverarbeitung ist nötig.
Wenn man die für die Vorverarbeitung verwendeten Tokens ausklammert, scheint der Token-Verbrauch bei der Anfrage tatsächlich signifikant gesunken zu sein.
Wenn man aber analysiert, welcher genaue Unterschied im Sourcecode zu diesem Effekt führt, würde der Beitrag deutlich an Aussagekraft gewinnen.
Denn das würde bedeuten, dass sich der Vorverarbeitungs-Prompt optimieren lässt, um genau diese Unterschiede zu maximieren.
Der Autor sagt, dass das Refactoring der Code-Struktur zu diesem Ergebnis geführt habe, aber ich stimme dem nicht zu und denke, dass man das noch nicht wissen kann.
Denn auch wenn man die KI nicht zum Refactoring, sondern zur Verbesserung anderer Aspekte einsetzt, könnte der Token-Verbrauch sinken.
Es braucht vielfältigere Experimente
Ich denke, derselbe Versuch sollte nicht nur mit dem aktuellen Code, sondern auch mit anderen Codebasen durchgeführt werden.
Denn man muss beurteilen können, ob das konsistent gute Ergebnisse liefert oder nicht.
Ich verstehe allerdings, dass das in der Praxis schwer zu testen sein kann, daher würde ich das nur als Hinweis betrachten.
Dem stimme ich voll und ganz zu. Solche Formen der Kritik begrüße ich sehr.
Man lebt nicht allein auf der Welt, und die Fähigkeiten oder Umstände jedes Einzelnen sind unterschiedlich.
Auch ich bin letztlich nur ein Entwickler und kann nicht alle Tests auf eigene Kosten durchführen.
Ich hoffe, dass dieser Beitrag als Samen dient, viele Menschen positiv beeinflusst und zum Ausgangspunkt für viele weitere Forschungen wird.
Der Untertitel passt nicht ganz zum Inhalt. Wenn man es neu ordnet, scheint „Es ist eine Analyse klarerer Faktoren nötig, die zur Token-Reduktion führen“ als Untertitel passender zu sein.
Diesem Inhalt stimme ich in vielen Punkten zu. Allerdings hat dieser Artikel auch den Charakter, den Menschen, die ihn lesen, realistische Anwendungsmethoden vorzuschlagen.
Schon an den Kommentaren unter diesem Artikel lässt sich die Stimmung erkennen; auch ich habe erst vor Kurzem erfahren, dass es unter den AI-Nutzern vermutlich viele Nicht-Entwickler gibt, die als Vibe-Coder unterwegs sind.
Wenn durch vom Autor direkt angepassten Code, also ohne den Einsatz von AI, ein herausragendes Ergebnis erzielt wird,
wirkt das leicht so, als wolle der Autor seine Entwicklungsfähigkeiten zur Schau stellen und die Fähigkeiten von AI herabsetzen.
Daher wurde als Element das „Prompt“ gewählt, das auch andere Vibe-Coder nutzen können, und es wurden Beispiele behandelt, bei denen jeder das Ergebnis nachvollziehen kann.
Ich fände es gut, wenn im Anschluss an diese Untersuchung weitere Studien folgen würden, die die Faktoren, welche den AI-Token-Verbrauch beeinflussen, differenzierter aufschlüsseln.
Wenn durch eine einmalige strukturelle Überarbeitung die Token-Nutzungsrate von n Prompts gesenkt wird, dann spiegelt sich diese Reduktion über alle n identisch ausgeführten Durchläufe hinweg wider.
Dabei ist n ein Wert, der durch Ziel und Funktionsumfang des Projekts sowie durch Menge und Komplexität des dafür nötigen Codes bestimmt wird.
Außerdem gab es zuletzt bei Cursor- und Claude-Code-Agenten Updates, die die Ausführungseinheiten kleiner halten, um Probleme wie Endlosschleifen oder den unkontrollierten Token-Verbrauch durch KI zu lösen.
Ich halte es daher für richtig, Studien zum n-Wert in Bezug auf die Projektkomplexität getrennt durchzuführen.
Was man an dieser Stelle nicht übersehen darf, ist, dass eine Verbesserung der Struktur niemals ein Vorgang ist, der absolut unabhängig von der eigentlichen Codeentwicklung stattfindet.
Sie kann bereits über den ersten Prompt oder über Einschränkungen wie ein KI-Regelwerk (
.cursorrules) als Base Context Einfluss nehmen.Und eine einzige strukturelle Verbesserung kann im Verlauf des Projektentwicklungszyklus nicht alle Probleme auf einmal lösen.
Mit anderen Worten: Statt Codeverbesserungen in festen Intervallen zu planen, ist es sinnvoller, als Base Context von Anfang an die richtige Struktur anzuleiten.
Außerdem erscheint es sinnvoll, die Untersuchung getrennt danach durchzuführen, ob es als Base Context Regeln zur strukturellen Anleitung gibt oder nicht.
Zur Zusammenfassung von Punkt 1:
ist die Behauptung irreführend, man müsse den Token-Verbrauch eines einzelnen Prompts zur strukturellen Verbesserung zusätzlich aufschlagen und so berechnen.
Ich verstehe nicht ganz, was Sie in Ihrem Kommentar sagen wollen. Mein Punkt war, dass man zum fairen Vergleich der beiden Methoden nicht die insgesamt verbrauchte Token-Anzahl vergleichen sollte? Verbraucht auch Refactoring nicht Tokens?
Außerdem scheint Ihre zusätzliche Antwort weder im Artikel zu stehen noch experimentell überprüft worden zu sein. Sie meinen offenbar nicht den Token-Vergleich pro einzelner Anfrage, sondern dass sich bei mehreren Anfragen der Refactoring-Overhead verringert und sich daraus durch die geringere erwartete Token-Anzahl pro Anfrage ein Vorteil bei der Gesamtzahl der Tokens ergibt. Das wäre aber nur dann zutreffend, wenn diese Kostenreduktion bei mehreren Anfragen tatsächlich so bestehen bleibt, wie Sie annehmen, und das wirkt auf mich wie eine sehr ideale Annahme. Es gibt keine Garantie dafür, dass die Kostensenkung durch Refactoring unabhängig von der Anzahl der folgenden Anfragen erhalten bleibt, und ohne Experiment kann man das auch nicht einfach voraussetzen. Wenn Sie genau diese Aussage vertreten wollen, müssten Sie die Kostensenkung über mehr als eine Anfrage hinweg experimentell zeigen. Aber haben Sie nicht nur ein einziges Experiment durchgeführt und darauf basierend verglichen?
Ergänzend: Das ist nur meine eigene Annahme, aber wenn man für dasselbe Ziel (ein ideales Endergebnis) die Anfragen unendlich oft wiederholt, dann sollte der Code im Idealfall unabhängig davon, ob Refactoring stattfindet oder nicht, gegen dieselbe Form konvergieren. (Das ideale Endergebnis ist eindeutig.)
Wenn diese Annahme vernünftig ist, dann dürfte mit zunehmender Zahl an Anfragen der Unterschied mit oder ohne Refactoring kleiner werden, sodass auch der Vorteil der Token-Kostenreduktion allmählich sinkt. Wenn man das also aus einer makroskopischen Perspektive betrachtet: Falls dieser Vorteil durch die Kostenreduktion nicht lange genug anhält, könnte der Unterschied in der insgesamt für die Anfragen verwendeten Token-Anzahl am Ende vielleicht gar nicht signifikant sein, oder?
Und Sie hatten auch nach den Inhalten zum Experiment bezüglich der Anzahl der Prompt-Verkettungen gefragt.
Tatsächlich ist das umgekehrt ein Faktor, mit dem der Autor, salopp gesagt, leicht mogeln kann.
Schon die Entwicklung selbst bietet sehr viele mögliche Richtungen, und wenn man Prompts in eine Richtung aufhäuft, in der der Token-Verbrauch stärker auseinandergeht, dann wird diese Zahl wie ein Schneeball immer weiter anwachsen.
In der Forschung gibt es die Philosophie der „Cumulative Science“.
Zumindest nach meinem Kenntnisstand habe ich bislang noch nie Forschung zum Token-Verbrauch bei einem einzelnen Befehl gefunden,
also habe ich mich nicht sofort auf eine Untersuchung über N Durchläufe konzentriert, sondern darauf, klare Tests und Schlussfolgerungen für einen eindeutig bestimmten Einzeldurchlauf zu behandeln,
und die Forschung zu N Durchläufen kann ja im Anschluss an dieses Experiment weitergeführt werden.
Außerdem habe ich in einem anderen Beitrag schon einmal die Unterschiede im Verhalten von KI in Abhängigkeit von den Unterschieden in der Codebasis behandelt.
(Dieser wurde auch bereits hier auf GeekNews vorgestellt: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Kurz gesagt geht es um Tests und Ergebnisse dazu, dass sich die Qualität der Ausgaben je nach der Codebasis unterscheidet, die der KI als Eingabe gegeben wird.
Je nach Qualität und Ausrichtung der ursprünglichen Codebasis kann die Qualität des darauf folgenden Codes erhalten bleiben oder sich fortlaufend verschlechtern.
Das bedeutet, dass sich die Kosten für Refactoring in der frühen Projektphase stark von den Kosten für Refactoring in einem bereits weit fortgeschrittenen Projekt unterscheiden können.
Falls der Fragesteller Entwickler ist, hat er vielleicht schon einmal den Ausdruck „Flugzeugträger auf einem Segelboot“ gehört.
Refactoring ist ein tiefgehendes Thema, bei dem sich die Kosten enorm unterscheiden können – je nachdem, zu welchem Zeitpunkt es durchgeführt wird und welche Prinzipien und welches Design zu Beginn eines Projekts festgelegt werden.
Anstatt dieses Thema als Variable einzubeziehen und dadurch ein unsicheres Fazit zu erhalten,
wurde ein Test durchgeführt, mit dem sich zumindest sicher erklären lässt: „Ah, wenn die Qualität der Codebasis gut ist, sinkt auch der Tokenverbrauch.“
Ich werde es noch einmal erklären.
Die Personen, die Vibe Coding betreiben, reichen von Nicht-Entwicklern bis hin zu erfahrenen Entwicklern. Je nach ihrem Wissensstand kann die Qualität der Ergebnisse völlig unabhängig vom Inhalt dieses Artikels extrem unterschiedlich ausfallen.
Jemand kann ganz selbstverständlich unter der Voraussetzung der Nutzung von Cursor in
.cursorrulesgrundlegende OOP-Konventionen und Regeln zur Trennung von Klassen/Methoden festhalten und so in einer Form arbeiten, die kaum Refactoring erfordert,bei jemand anderem kann aufgrund eines fehlenden Verständnisses selbst sehr grundlegender Kerninhalte eine Flut von Low-Level-Code entstehen.
Es gibt sogar bereits viele Beiträge und Erfahrungen, die im Kern empfehlen, die Codequalität grundsätzlich durch das Festlegen von Projektregeln hochzuhalten.
Das deutet auf die Möglichkeit hin, dass manche auch ohne explizites Refactoring bereits Vorteile beim Token-Verbrauch haben könnten.
Allerdings fassen die oben genannten Fälle keine klare Verringerung des Token-Verbrauchs pro Ausführungseinheit anhand dieser Regeldefinitionen zusammen. Deshalb habe ich in diesem Beitrag die Unterschiede beim Token-Verbrauch je nach Qualität der Codebase getestet und die Ergebnisse zusammengefasst.
Mit anderen Worten: Je nach Nutzer wird die Anzahl expliziter Refactorings selbst wieder zu einer Variablen von 0 bis n,
und die eigentliche Absicht dieses Artikels ist wohl am besten so zu verstehen, dass er erklärt, „warum es sinnvoll ist, auf eine hochwertige Codebase zu achten“.
Ich bin der Autor. Vielen Dank für das Feedback. Ich werde es beim Verfassen des nächsten Artikels berücksichtigen.
Heißt das, dass die Kosten gesunken sind, weil dieser Prompt zusätzlich eingefügt wurde? Ich bin mir nicht sicher, ob ich den Kern richtig verstanden habe.
Ergänzend dazu sollte die Struktur des Codes entsprechend dem jeweiligen Projektmodell strukturell verbessert werden. Wie in der Antwort unten beschrieben, zeigt die AI passende Methoden zur Strukturverbesserung für das jeweilige Projekt auf, wenn man sie danach fragt.
Meine persönliche Empfehlung ist, der AI nicht sofort eine direkte Anweisung zur Strukturverbesserung zu geben. Besser ist es, sie zunächst um Vorschläge zu bitten; sie liefert dann Antworten, und wenn Sie im Gespräch gemeinsam zu einem ausreichend effizienten Vorschlag gelangt sind, können Sie sie die Umsetzung vornehmen lassen.
Ein zusätzlicher Tipp: Es ist am besten, die Arbeit möglichst abzuschließen, bevor eine Kontextzusammenfassung (Zurücksetzen des Kontextpuffers) erfolgt. Falls ein Zurücksetzen des Kontextpuffers unvermeidlich ist, ist es sinnvoll, die AI vorher zu bitten, Verbesserungsregeln zu
.cursorruleshinzuzufügen. Wenn während der Arbeit ein Kontext-Reset stattfindet, steigt die Wahrscheinlichkeit, dass die AI Fehler macht.Zur Info: Dass die Zahl der verbrauchten Tokens sinkt, je kleiner der eingegebene Quellcode ist, ist ein allgemein bekannter und offensichtlicher Umstand. Genau deshalb wurde die Datei
.cursorignoregeschaffen.Wenn man die AI im Allgemeinen zu strukturellen Verbesserungen veranlasst, nimmt die Menge des Quellcodes in den allermeisten Fällen tendenziell ab. Daher wirkt die Aussage plausibel, dass die Kosten sinken, wenn man den Code aus irgendeinem Grund aufräumen lässt.
Dieser Beitrag ergänzt nun die Behauptung, dass sich durch das Herbeiführen einer guten Struktur eine zusätzliche Reduzierung des Tokenverbrauchs erreichen lässt.
Genau. Wie auch im Haupttext steht, ist es tatsächlich so, dass sich die Größe des Projektcodes nach der Code-Verbesserung verringert hat.
In diesem Beispiel gab es jedoch gemessen an der Zeichenanzahl nur eine Reduktion von etwa 10 %, und allein damit lässt sich der Rückgang des Token-Verbrauchs um 37,91 % nicht erklären.
Im Haupttext gibt es einen Link zum Quellcode-Repository, und jede Person kann den Test selbst reproduzieren und überprüfen.
Ich habe das selbst zwar nicht direkt so getestet,
aber ich denke, dass auch der Prompt
„Analysiere den aktuellen Code und verbessere die Struktur so, dass er für dich leichter zu verwalten ist“
funktionieren könnte.
Im Kern bedeutet das wohl, dass es zur Kostensenkung beitragen kann, einer KI nicht nur funktionale Anforderungen zu übermitteln, sondern sie auch gezielt zu einer passenden und korrekten Struktur zu führen.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
Haben Sie diesen DeepRockGalactic-Mod selbst erstellt?
Haben Sie das auch mit Vibe Coding gemacht?
Hallo. Ich bin der Betreiber dieses Blogs.
Es stimmt, dass ich den DeepRAGal-Modus selbst entwickelt habe, und er wird derzeit über einen privaten Server bereitgestellt. (Das ist wegen der Chzzk-OAuth-Authentifizierung erforderlich.)
Die Entwicklung dieses Modus umfasst auch Arbeiten mit der Unreal Engine, aber leider ist Vibe Coding auf der Unreal-Engine-Seite schwierig.
Stattdessen ist die Methode der Mod-Entwicklung selbst nicht besonders schwierig, daher können Sie, falls Sie interessiert sind, sie mithilfe des Leitfadens zur Mod-Entwicklung (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/) leicht erlernen.
Ich habe in einer anderen Community gesehen, dass Sie den Mod hochgeladen haben, und es stimmte wirklich, dass es der Beitrag der Person war, die diesen Mod erstellt hat.
Ich hätte nicht gedacht, dass Sie sogar noch einen Leitfaden zum Blueprint-Modus geschrieben haben – danke.
Sie waren ohnehin schon jemand, der wirklich gut entwickelt!
Ah, dann haben Sie meinen Modus wohl schon einmal in einer anderen Community gesehen.
In den von mir verfassten Beiträgen gibt es zwar noch viele unzureichende Stellen, aber ich würde mich freuen, wenn sie hilfreich sein könnten.
Ach, wie nervig.
Wenn Sie mir mitteilen, welcher Teil Sie verärgert hat, antworte ich Ihnen gern und freundlich.
Bitte beachten Sie den Abschnitt zum Kommentieren in der Anleitung zur Nutzung der Seite.
Bitte formulieren Sie Ihre Beiträge freundlich und höflich.
Falls Sie eine Gegenposition haben, schreiben Sie bitte nur deren Inhalt