Von Null zu einem per Chat erstellten, sich drehenden Würfel

Der Nordstern: Warum „ein sich drehender Würfel“

An diesem Tag zielte alles auf einen einzigen Akzeptanzpunkt ab: Auf einer sauberen Maschine klonen, einen Schlüssel einlegen, einen Befehl ausführen und dann dem Agenten in der Benutzeroberfläche sagen: „Erstelle einen sich drehenden Würfel“ – er bearbeitet den Code, die Engine wird im laufenden Betrieb neu geladen, und sofort erscheint ein sich drehender Würfel im Browser. Der Würfel selbst ist unauffällig, aber er ist der minimale Beweis für die Kernaussage des Produkts – „man kann durch bloßes Reden etwas wirklich Lauffähiges bauen“ – und wenn irgendein Glied in dieser Kette bricht, hält die Plattform nicht stand. Die Zusammenfassung des Ziels zu einem eindeutigen Akzeptanzpunkt, wie ein einzelner Screenshot beweisen kann, bedeutet, dass das Team keinen „Fortschritt spürt“, sondern ein hartes Pass/Fail-Ziel verfolgt. Dieser Tag ist vergangen.

Die End-to-End-Schleife läuft: Sagen Sie einen Satz, das Bild ändert sich

Diese Schleife verkettet sechs Links Ende an Ende: Sie geben eine Anforderung im Chatfeld an → der Agent schreibt den entsprechenden Code in die Spieldatei → ein Dateibeobachter bemerkt die Änderung → ein Echtzeitkanal benachrichtigt das Frontend → die Engine lädt den neuen Code dynamisch → das Bild wird sofort aktualisiert. An diesem Tag wurden diese sechs Links zum ersten Mal vollständig und stabil verbunden, und ein automatisierter Browser-Screenshot erfasste tatsächlich den Würfel mitten in der Drehung bei einer Neigung, ohne dass auf dem gesamten Weg Fehler auftraten, außer einem harmlosen Hinweis auf ein fehlendes Symbol. Das bedeutet, dass „What you see is what you get“ nicht länger eine Zeile in einem Vision-Deck ist, sondern eine echte, wiederholbar ausgelöste Pipeline. Jede spätere Erfahrung von „Bauen Sie während des Chats und sehen Sie das Ergebnis sofort“ basiert auf dieser Schleife; Als es funktionierte, erwachte das Produkt einmal wirklich zum Leben.

Die drei Schichten landen: klare Rollen, austauschbar

Damit diese Schleife auf lange Sicht Bestand hat, wurde das System in Teile mit klaren, unabhängig austauschbaren Verantwortlichkeiten unterteilt: einen Laufzeitkern, der tatsächlich das Denken und Handeln des Agenten steuert (Verarbeitung von Modellaufrufen, Tools, Sitzungen, Speicher); eine reine Orchestrierungs- und Schnittstellenbrücke (Übertragung von Dateiänderungen an das Frontend, ohne das große Modell selbst zu berühren); eine Engine (die Spielcode in ein Bild rendert); plus die dreispaltige Oberfläche, mit der der Benutzer konfrontiert wird. Diese Aufteilung wurde in einen internen Schnittstellenvertrag geschrieben und als eiserne Regel festgelegt, die nicht leichtfertig abgeändert werden darf – der Kernel ist der Kernel, Orchestrierung ist Orchestrierung, Grenzen bleiben eindeutig. Sein Wert: Jede Schicht kann sich für sich weiterentwickeln und ausgetauscht werden, ein Problem in einer Schicht beeinträchtigt nicht das Ganze und „Austausch der Engine, Auswechseln der Schnittstelle“ wird später möglich, statt ein Umschreiben.

Ersetzen der „Platzhalter-Shell“ durch eine echte Agentenlaufzeit

In der Vordämmerungsversion der Schleife war der Antrieb des Agenten immer noch eine temporäre Platzhalter-Shell; Heute wurde es in mehr als dreißig Schritten durch eine echte Agentenlaufzeit der „professionellen Coding-Assistenz-Klasse“ ersetzt. Dieser Kernel hat das, was ein echter Agent braucht: Er kann das große Modell aufrufen, Tools verwenden, Sitzungen und Speicher verwalten und sich in einer „Denk-Handel“-Schleife vorantreiben. Nach dem Austausch empfing das System zum ersten Mal echte Modellantworten und führte eine vollständige Schleife „echtes Modell + echte Werkzeuge“ durch. Durch diesen Schritt wurde das Produkt von „sieht aus, als ob es chatten kann“ zu „kann tatsächlich die Arbeit erledigen“ verschoben – frühere Gespräche waren eine Leistung; Jetzt steht dahinter eine Engine, die lesen, schreiben und Tools verwenden kann, um Ihr Projekt wirklich zu verändern.

Nicht neu erfinden: Standards wiederverwenden, anstatt Tausende von Zeilen zu kopieren

Beim Ausfüllen der Agentenfähigkeit hätten zwei Teile durch „Kopieren von tausend Zeilen von anderswo“ erledigt werden können: die Protokollschicht, die die Werkzeugfähigkeit einbringt, und ein Standardprotokoll für Konversationsereignisse. Das heutige Urteil war klar: Überall dort, wo ein ausgereifter offener Standard bereits existiert und direkt installiert und verwendet werden kann, darf man ihn nicht von Hand erneut kopieren. Daher wurden beide durch offizielle Standardimplementierungen der früheren handgeschriebenen Versionen ersetzt: Der Tool-Protokollcode schrumpfte von etwa hundert Zeilen auf achtzig und erhielt umfassendere Transporte und Benachrichtigungen über Funktionsänderungen kostenlos; Das Konversationsereignisprotokoll zog eine Standardbibliothek ein und exportierte mehr als dreißig Standardereignisse fast ohne neuen Code. Zusammen fügten die beiden Schritte weniger als zweihundert Nettoleitungen hinzu und lieferten dennoch Funktionen auf Unternehmensniveau. Dahinter steckt eine immer wiederkehrende Disziplin: Bemühen Sie sich um die schwierigen Probleme, die niemand für Sie gelöst hat, und nicht darum, Räder neu zu erfinden, die bereits in öffentlichen Standards verankert sind.

Hunderte von Chat-UI-Durchgängen: vom Rohtext bis hin zu nahezu Desktop-Qualität

Sobald die Schleife wirklich funktionierte, wurden die Erfahrungslücken der Schnittstelle zum wunden Punkt. An diesem Tag wurde das Chat-Panel in winzigen Schritten über hundert Iterationen von „Rohtext und Platzhalterfeldern“ zu etwas verfeinert, das einem ausgereiften Desktop-Assistenten ähnelt. Es umfasst einen vollständig handgeschriebenen Markdown-Renderer (Codeblöcke, Listen, Tabellen, Aufgabenlisten werden alle unterstützt), eine Zeichen-für-Zeichen-Streaming-Animation, deren Geschwindigkeit sich an die Länge des Inhalts anpasst, Tool-Aufrufe, die in einem hochdichten „Pill“-Tag zusammengefasst sind, das sich zum vollständigen Ergebnis ausdehnt, die „Selbstkorrektur/Reflexion“ des Agenten, die visuell hervorgehoben wird, den Kontrast zwischen Blasen und Hintergrund, der auf Barrierefreiheitsstandards abgestimmt ist, und deaktivierte Schleifenanimationen für Benutzer, die reduzierte Bewegung bevorzugen. Bei jedem Durchgang wurde eine Sache berührt, ein Selbsttest durchgeführt und eine Notiz protokolliert. Der Punkt ist klar: Wie stark die Funktion auch sein mag, wenn sie sich mühsam liest oder billig aussieht, werden Benutzer ihr nicht vertrauen; Das Polieren der Oberfläche, auf die Sie am meisten starren, in etwas Angenehmes ist selbst Teil der Kernfunktion.

Eine flache Umstrukturierung + Zero-Build, Run-from-Source-Entwicklung

Am Nachmittag kam es zu einer strukturellen Abflachung: Die einst tief verschachtelten Verzeichnisse wurden flach gelegt, sodass die Teile direkter nebeneinander liegen. Daneben wurde ein „Zero-Build“-Entwicklungsmodus eingeführt: Nach dem Klonen führt ein Befehl die Quelle direkt aus, ohne dass zuerst ein langer Schritt zum Kompilieren und Bündeln erforderlich ist. Für Entwickler bedeutet das, dass sie eine Zeile ändern und das Ergebnis fast sofort im Browser sehen und die Iterationsgeschwindigkeit um eine Stufe steigern können. Für Neulinge ist der Weg „vom Klon zum Sehen des Bildes“ auf den kürzesten Weg verkürzt. Die strukturelle Vereinfachung ist nicht greifbar, entscheidet jedoch darüber, ob in den kommenden Wochen der Rhythmus „ein großer Schritt pro Tag“ eingehalten werden kann – je einfacher und klarer das Fundament, desto schneller und stabiler baut man darauf auf.

Das dreispaltige Studio nimmt Gestalt an: Dateien, Vorschau, Konsole, Umschalter

Am Abend wurde das dreispaltige Studio mit einer Reihe tatsächlich verwendbarer Bedienfelder auf einmal eingerichtet: Der Dateibaum auf der linken Seite ist mit echten Projektdateien verbunden. Klicken Sie auf ein Produkt, um eine Vorschau anzuzeigen. ein Live-Vorschaufenster in der Mitte, das direkt mit der Engine verbunden ist, mit den Modi Bildratenanzeige, Pause, Neuladen, Vollbild und Desktop/Mobilgerät; Plus ein Panel, das die Konsolenausgabe der Engine weiterleitet, ein Umschalter, der vergangene Sitzungen auflistet und wiedergibt, und Einträge zum Wechseln von Projekten und Spielen mit einem „neuen“ Menü. Bemerkenswerterweise folgte dieser Tag auch einem Instinkt und verschmolz die beiden Konzepte „Projekt“ und „Spiel“ zu einem – der Benutzer sagte, sie seien dasselbe, daher sollte die Benutzeroberfläche sie nicht auseinander zwingen. Damit wurde das Layout „Links verwalten/Vorschau-Mitte/Chat-rechts“ festgelegt, und das Studio begann, von einer Fülle an Funktionen zu einer nutzbaren Produktform zu konvergieren.

Was dieser Tag bedeutet

Zusammengenommen besteht das Gewicht dieses Tages darin, dass es sich nicht um die Auslieferung eines einzelnen Features handelte, sondern darum, dass sich die Kernthese des Produkts zum ersten Mal durchgängig bewährt hat. Von einem Satz bis zu einem sich bewegenden Würfel lief jede Verbindung dazwischen – Rendering, Laufzeit, Orchestrierung, Schnittstelle – tatsächlich auf einer sauberen Maschine, was durch einen Screenshot belegt wird. Alles Komplexe nach dem Würfel – echte Spiele, komplexe Szenen, ein ganzes Agententeam – wächst auf diesem bereits verbundenen Stamm. Genau deshalb lohnt es sich, diesen Tag als Modell festzuhalten: Zuerst die kritischste, fälschbarste Hauptkette verbinden, dann über die Zweige sprechen; Das einmalige Laufen gibt einem das Selbstvertrauen für das zweite und das hundertste Mal.