Im März 2026 haben wir das Erlebnis auf moonshot.ai plattformweit aufgefrischt. Auf den ersten Blick wirkte das Update schlicht: eine neue Farbpalette, präzisere Typografie und überarbeitete Animationen. In der Praxis betraf es gemeinsame Komponenten, Design-token, Routen und interaktive Ebenen auf der gesamten Website.
Wir nutzten Kimi Code CLI, unterstützt von Kimi K2.5, als AI-Coding-Agent, um den Umbau umzusetzen. Das Projekt wurde zu einem Praxistest dafür, wie ein terminalbasierter Agent in einen echten Produktionsworkflow passt – nicht in eine Demo-Umgebung. Dieser Artikel zeigt, wie wir ihn eingesetzt haben und was wir dabei gelernt haben.
Worum es bei dieser Auffrischung wirklich ging
Bei der Auffrischung von moonshot.ai ging es nicht darum, die Marke von Grund auf neu zu gestalten. Der größte Teil der Designarbeit lag bereits in Figma vor. Die eigentliche Herausforderung bestand darin, diese Updates konsistent auf eine bestehende Codebasis zu übertragen.
Das bedeutete: gemeinsame token nachverfolgen, Komponenten aktualisieren, interaktives Verhalten prüfen und sicherstellen, dass Analytics und Barrierefreiheit nicht beeinträchtigt wurden. Viele Änderungen waren für sich genommen klein, zogen sich aber durch mehrere Ebenen der Website.
Diese Art von Arbeit ist nicht wegen algorithmischer Komplexität schwierig. Schwierig sind Umfang und Konsistenz. Die Herausforderung besteht darin zu wissen, was eine Änderung berührt, und sicherzustellen, dass nichts übersehen wird. Dafür nutzten wir eine Model Context Protocol (MCP)-Verbindung mit Figma, um Designvorgaben und Implementierung besser aufeinander abzustimmen, dem Agent die Struktur verständlicher zu machen und manuelle Interpretation zu reduzieren.
Grundregeln: den Agent nützlich machen
Der erste Schritt war nicht das Schreiben von Prompts, sondern das Setzen des Kontexts. Wir nutzten den Befehl /init, um eine Datei AGENTS.md zu erstellen, und verfeinerten sie anschließend etwa eine Stunde lang. Darin dokumentierten wir, was für die Auffrischung zum Umfang gehörte, was sich nicht ändern durfte, wie das Projekt strukturiert war und wie der Build-Prozess funktionierte. Außerdem ergänzten wir eine Regeldatei zu Namenskonventionen, Abständen und Kontrastanforderungen.
Dieses Setup reduzierte später den Bedarf an wiederholten Erklärungen und machte den Workflow mit Kimi Code CLI konsistenter. Ohne projektspezifischen Kontext liefert der AI-Coding-Agent tendenziell sinnvolle, aber generische Ergebnisse. Mit Kontext verhält er sich eher wie ein Teammitglied, das die Codebasis bereits kennt.
Wie wir ihn tatsächlich eingesetzt haben
Dieser Abschnitt zeigt, wie Kimi Code CLI während der Auffrischung praktisch genutzt wurde – beim Nachverfolgen von Abhängigkeiten, beim Designabgleich, bei der Untersuchung von Verhalten, bei Performance-Prüfungen und bei der Bewertung von Integrationsrisiken. Im Fokus stand nicht Automatisierung, sondern die Reduktion von Unsicherheit in einem groß angelegten Refactoring.
Verstehen, was eine Änderung berührt
Bevor wir etwas bearbeiteten, baten wir den Agent in Kimi Code CLI, den Zielbereich zu lesen und aufzulisten, was sonst noch davon abhing. Eine einzelne Änderung – etwa die Farbe eines Buttons – kann Hero-Bereiche, Download-Bereiche, Hover-Zustände und gemeinsame token beeinflussen; gemeinsame Komponenten, Animations-Timing und Analytics-Hooks können die Auswirkungen zusätzlich ausweiten. Eine Abhängigkeitsliste vorab reduzierte spätere Überraschungen und machte Änderungen berechenbarer.
Code mit der Designvorgabe abgleichen
Anschließend verglichen wir die Komponenten Abschnitt für Abschnitt mit der Designvorgabe: Hero, Navigation, Produktbereiche, Download-CTA und Footer. Der Agent erstellte Änderungslisten auf Property-Ebene, indem er Styles mit Design-token und Layoutwerten verglich. Dieser Prozess fühlte sich eher nach strukturierter Design-System-Automatisierung an als nach manueller Sichtprüfung. Die meisten Unterschiede waren klein, etwa Abstände, Border-Radius oder Schriftstärke. Gelegentlich tauchten jedoch größere Inkonsistenzen auf, wenn Komponenten, die eigentlich gemeinsame Varianten hätten nutzen sollen, im Lauf der Zeit auseinanderdrifteten. Das Ergebnis war eine konkrete Liste von Änderungen statt eines visuellen Ratespiels.
Neues Verhalten untersuchen
Die Auffrischung brachte neue UI-Verhaltensweisen mit sich, die in der Codebasis zuvor nicht implementiert waren: einen benutzerdefinierten Cursor, einen runtime-gesteuerten Hero, Illustrationskarten mit Hover-Wiedergabe und durch Scrollen ausgelöste Einblendungen.
Für jedes Feature nutzten wir Kimi Code CLI als kontextuelle Umgebung, indem wir Dokumentation und Repository-Zustand gemeinsam luden. Genau hier war Kimi K2.5 entscheidend: Der längere Kontext erleichterte es, Implementierung und Referenzen an einem Ort zusammenzudenken.
Die Fragen waren praktisch:
Sollen Hover-Animationen beim Verlassen zu Ende laufen oder abbrechen?
Soll der Cursor-Zustand mit dem Hero-Canvas interagieren?
Was bricht, wenn sich mehrere Ebenen überlagern?
Das große Kontextfenster ermöglichte einen kontinuierlicheren Kimi Code-Workflow, in dem Designabsicht und Code in derselben Sitzung leben.
Gewicht und Performance prüfen
Die Auffrischung führte eine neue Schrift, mehr Bewegung und zusätzliche Assets ein, wodurch das Seitengewicht stieg. Wir nutzten den Agent, um das bestehende Skript für Font-Subsetting anzupassen und die Ausgabe zu verifizieren; später half er dabei, Lighthouse-Berichte zu interpretieren, damit wir Regressionen früh erkennen konnten. Ziel war nicht, am Ende alles zu optimieren, sondern Keep-or-cut-Entscheidungen zu treffen, solange die Änderungen noch klein waren.
Integrationsrisiken vor dem Mergen nachverfolgen
Mehrere interaktive Ebenen – Einblendanimation, Cursor, Hero-Canvas – teilen sich Reihenfolge und Pointer-Verhalten, obwohl sie in separaten Komponenten leben. Deshalb kann eine Änderung in einer Ebene weiterhin andere beeinflussen. Außerdem mussten wir Unterschiede zwischen Browsern und Betriebssystemen berücksichtigen, bei denen CSS- und Rendering-Verhalten nicht immer übereinstimmen. Bevor wir Änderungspakete mergten, speisten wir Diffs in Kimi Code CLI ein und baten ihn nachzuverfolgen, welche Interaktionen betroffen sein könnten. Anschließend prüften wir diese Pfade im Browser und machten einen leichten Durchlauf über verschiedene Umgebungen hinweg.
MCP-Integrationen und Skills
Model Context Protocol (MCP) ermöglichte Kimi Code CLI, sich direkt mit externen Systemen zu verbinden, die Projektdaten enthalten. Wir nutzten mcp Figma, um Design-token, Layoutdaten und Typografie direkt aus Figma zu übernehmen. So reduzierten wir die manuelle Übersetzung zwischen Design und Code und banden außerdem interne Tools an, sodass Aufgaben, Spezifikationen und Edge Cases ohne Kontextwechsel verfügbar waren.
Einen Server hinzuzufügen ist ein einziger Befehl:
Das Muster lässt sich auf das gesamte MCP-Ökosystem übertragen. Zur Inspiration können Sie agents verbinden mit:
Figma — offizielles MCP für Designkontext, Variablen und Layoutdaten aus dem Canvas
Atlassian Cloud — Confluence-Seiten und Jira-Arbeitselemente über Atlassians Remote-MCP-Einstiegspunkt (gemeinsam mit Rovo dokumentiert)
Datenbanken, CMS APIs — MCP-Server von Anbietern oder der Community; Registries listen Hunderte Optionen nach Kategorie
Ihr Stack kann anders aussehen – eine private Docs-API, ein interner Design-token-Service oder ein Data Warehouse. Die Idee bleibt dieselbe: den Agent mit Systemen verbinden, in denen die relevanten Daten bereits liegen. Informationen zu Konfigurationsdateien, Serverdefinitionen und weiteren Möglichkeiten, MCP in Kimi Code CLI einzubinden, finden Sie im Plattformleitfaden.
Review-Skill
Wir schrieben außerdem einen Skill für Code-Reviews. Es handelt sich um eine Regeldatei, die Kimi Code CLI vorgibt, wie ein Merge Request von Anfang bis Ende zu bewerten ist: den Diff lesen, betroffene Dateien und Komponenten nachverfolgen, Verstöße gegen das Design System prüfen (unverarbeitete Farb-Literale, Abstände außerhalb des Rasters, fehlende Accessibility-Fallbacks), Risiken nach Bereich bewerten und einen strukturierten Bericht erstellen.
Der Bericht folgt einem festen Format:
Eine Zusammenfassung von Ziel und Umfang
Befunde nach Schweregrad gruppiert (kritische Probleme, die den Merge blockieren, empfohlene Verbesserungen, kleinere Konsistenzhinweise)
Zu jedem Befund: Belege aus dem Diff, Folgenabschätzung und eine konkrete Maßnahme
Der Skill markiert außerdem potenzielle Risiken, die eine kurze Prüfung im Browser oder auf einem Gerät erfordern können – Fälle, in denen der Agent unsicher ist, die Verifikation aber wenig Aufwand kostet.
In der Praxis durchlief jeder PR während der visuellen Auffrischung von moonshot.ai diesen strukturierten Durchgang, bevor das Review abgeschlossen wurde. Die Ausgabe enthielt immer eine Zusammenfassung der Absicht, nach Schweregrad priorisierte Befunde, Belege und Fixes.
Das verringerte Unruhe in späten Phasen und verbesserte die Konsistenz im Kimi Code-Workflow. Sichtbar wurden unter anderem hartcodierte URLs neben gemeinsamen Konstanten, Analytics-Felder, die angeglichen werden mussten, und Edge Cases bei mobilen Interaktionen.
Was wir nicht erwartet hatten
Während des Refactorings zeigten sich einige Muster, die zu Beginn nicht offensichtlich waren.
Spec-to-Code wurde schneller, als wir erwartet hatten
Mit Figma MCP und Kimi Code CLI im selben Thread kamen Maße und Design-token als strukturierter Input an, statt manuell übertragen zu werden. Das Ergebnis waren kürzere Iterationsschleifen pro Abschnitt – Änderungen und Korrekturen auf Property-Ebene landeten oft in einem einzigen Durchlauf, statt zwischen Tools hin- und herzuwechseln.
Recherche-Prompts zahlten sich stärker aus, als wir erwartet hatten
Die Auffrischung stützte sich stark auf lange, dokumentationsgetriebene Durchgänge durch Runtime-Dokumentation und Referenzimplementierungen, gemeinsam mit dem Repository. Diese Materialien in derselben Sitzung wie den Code zu halten, erwies sich oft als genauso wertvoll wie die Änderungen selbst.
Der Review-Skill machte aus kleinen Inkonsistenzen eine Liste
Der strukturierte Bericht brachte dieselben Klassen von Problemen zutage, die zuvor beschrieben wurden – hartcodierte URLs neben gemeinsamen Konstanten, Analytics-Felder, die abgeglichen werden mussten, und Edge Cases bei mobilen Interaktionen. Einzeln waren die meisten geringfügig, gebündelt in einem Durchgang aber leichter zu beheben.
Lange Threads ließen sich kostengünstig fortsetzen
Befehle wie kimi --continue und /compact bedeuteten, dass mehrtägige Arbeit nicht jeden Morgen einen neu aufgebauten Kontext erforderte. Das reduzierte erneutes Prompting und hielt denselben Kimi Code-Workflow konsistent in Bewegung.
Weitere Informationen zum Fortsetzen von Sitzungen, zum Wechseln zwischen ihnen und zur Kontextverwaltung mit /compact und verwandten Befehlen finden Sie im Kimi Code CLI-Sitzungsleitfaden.
Erkenntnisse aus dem Neubau von moonshot.ai
Wenn wir eine ähnliche visuelle Auffrischung von moonshot.ai noch einmal durchführen würden, würden wir ein paar Dinge anders angehen.
Mit Kontext beginnen, nicht mit Code
Die erste Stunde darauf zu verwenden, Umfang, Einschränkungen und Konventionen zu dokumentieren, sparte mehr Zeit als jedes spätere Prompting. Diese Vorarbeit sorgte dafür, dass Tools wie Kimi Code CLI über den gesamten Workflow hinweg konsistenter agierten.
Früh eine Single Source of Truth anbinden
In unserem Fall war das Figma. In anderen Projekten kann es ein CMS, eine interne API oder ein Design System sein. Entscheidend ist, dass das System mit echten Daten arbeitet statt mit abgeleiteten Annahmen – besonders, wenn ein AI-Coding-Agent in einem Frontend-Refactoring eingesetzt wird.
Design- und Aufgabenkontext in derselben Schleife halten
token, Spezifikationen und Implementierung in einen gemeinsamen Kontext zu bringen, reduzierte Abstimmungen und machte Iterationszyklen stabiler. Hier erwiesen sich Workflows mit Figma MCP und Kimi Code CLI als besonders effektiv, weil sie halfen, Designabsicht und Codeänderungen in einer durchgehenden Schleife aufeinander abzustimmen.
Wenn Sie keinen Code schreiben möchten: Kimi Websites
Alles oben beschreibt einen entwicklerzentrierten Workflow – Terminals, Diffs und Kontextdateien. Dasselbe Ergebnis – eine ausgefeilte, responsive Website – lässt sich jedoch auch ohne diesen Stack erreichen, wenn Geschwindigkeit wichtiger ist als Kontrolle auf Framework-Ebene.
Kimi Websites läuft auf demselben Kimi K2.5-Modell, jedoch über eine visuelle No-Code-Oberfläche. Sie beschreiben in natürlicher Sprache, was Sie möchten, verfeinern Abschnitte im Gespräch und veröffentlichen mit einem Klick. Auch ein vorhandener Screenshot kann als Eingabe dienen, um die Layoutstruktur zu rekonstruieren.
Für Gründer, die Landingpages prototypisieren, oder Marketer, die Kampagnenseiten unter engen Zeitplänen ausliefern, bietet das einen schnelleren Weg als die direkte Arbeit mit einem traditionellen Frontend-Stack.
Fazit
Kimi Code CLI und Kimi K2.5 waren in den Projektbereichen am nützlichsten, in denen Breite wichtiger war als Komplexität. Bei einer visuellen Auffrischung geht es selten um schwierige Probleme – sondern um viele kleine Änderungen, die im gesamten System konsistent bleiben müssen. Für Menschen ist das zeitaufwendig, für einen Agent, der dateiübergreifend nachverfolgen und vergleichen kann, jedoch vergleichsweise gut geeignet.
Die Entscheidungen trafen weiterhin wir, prüften jede Änderung und validierten das Endergebnis. Der Agent übernahm repetitive Nachverfolgung, Vergleiche und die erste Review-Arbeit. In der Praxis erwies sich diese Arbeitsteilung als praktikabler Weg, einen AI-Coding-Agent in einen Produktionsworkflow zu integrieren. Bei dateiübergreifenden Refactorings, der Verifikation von Design zu Code und Konsistenzarbeit in großem Maßstab hat sich dieser Ansatz bewährt.