Welches Modell soll deine Object-Pascal-Änderungen steuern?
Arraydeck liefert kein festes Gehirn aus. Du verbindest einen Cloud-KI-Anbieter über einen Standard-API-Endpoint, führst ein Modell auf deinem PC aus oder nutzt das eingebaute Modell. Die Wahl kannst du jederzeit ändern, wenn eine Aufgabe etwas anderes erfordert.
Drei Möglichkeiten, ein Modell zu verbinden
Ein Cloud-KI-Anbieter
Ein Cloud-KI-Anbieter wird über einen Standard-API-Endpoint erreicht, den du in der App eingibst, zusammen mit deinem API-Schlüssel. Er eignet sich für große Einheiten, lange Refactorings und Aufgaben, bei denen ein größeres Modell besser argumentiert. Die Konsequenz für die Privatsphäre ist klar. Die Eingabe wird an den Anbieter gesendet, einschließlich des Textes aus jeder Datei, die der Agent liest, und wird gemäß den Bedingungen des Anbieters verarbeitet. Dein API-Schlüssel bleibt auf deinem PC, und Geheimnisse in der Agentenausgabe werden vor der Übermittlung an das Modell maskiert. Die Abrechnung für den Dienst des Anbieters erfolgt direkt zwischen dir und dem Anbieter.
Ein Modell, das lokal auf deinem PC läuft
Ein lokal auf deinem PC laufendes Modell beantwortet Anfragen von deiner eigenen Maschine. Es eignet sich für privaten Code, schnelle kleine Änderungen und Arbeiten, bei denen nichts den Computer verlassen darf. Bei einem lokalen Modell verlässt nichts die Maschine, und Chats, Arbeitsordner und API-Schlüssel bleiben ebenfalls auf dem PC. Die Grenze ist die Hardware. Ein kleines lokales Modell hat einen kleineren Kontextfenster und benötigt möglicherweise kürzere Einheiten oder klarere Anweisungen, also lies jeden Diff mit zusätzlicher Sorgfalt.
Das eingebaute Modell
Das eingebaute Modell ist ohne eigenen Endpoint sofort einsatzbereit. Wähle es, wenn du Arraydeck bei einem ersten Projekt testen, eine Einheit lesen oder nach einer kleinen Änderung fragen möchtest. Die Qualität variiert je nach Aufgabe wie bei jedem Modell, also überprüfe den Diff vor der Annahme, führe deinen Build-Befehl aus und behalte Ask first aktiviert. Du kannst später in denselben Einstellungen einen Cloud-Anbieter oder ein lokales Modell verbinden.
Was der Test-Button dir sagt
Drücke Test, nachdem du einen Endpoint, einen Schlüssel oder einen Modellnamen eingegeben hast. Die Schaltfläche überprüft den Endpoint und zeigt die Antwortzeit sowie das Kontextfenster an. Die Antwortzeit zeigt, wie lange eine Antwort von dieser Verbindung dauert, was hilfreich ist, wenn du zwei Modelle bei derselben Aufgabe vergleichst. Das Kontextfenster zeigt, wie viel Text das Modell auf einmal verarbeiten kann, was für lange Einheiten mit vielen Prozeduren wichtig ist. Ein fehlgeschlagener Test bedeutet meist eine falsche Adresse oder einen falschen Schlüssel, also behebe die Einstellungen, bevor du eine Aufgabe startest.
Modell für die Aufgabe auswählen
Verwende ein größeres Modell für Refactorings, lange Einheiten und komplexe Logik, und ein kleineres für kleine Änderungen wie das Hinzufügen von try ... finally oder das Umbenennen einer Prozedur. Du kannst sie in einem Chat mischen. run_on_model sendet einen einzelnen harten Schritt an ein größeres Modell, während der Rest der Arbeit auf dem von dir gewählten Modell bleibt, und task startet Sub-Agents, wenn Teile der Arbeit parallel ausgeführt werden können. Passe das Modell an den Schritt an und überprüfe das Kontextfenster mit der Test-Schaltfläche, bevor du eine große Einheit einfügst.
Die Qualität unterscheidet sich zwischen Modellen und Aufgaben, und kein Modell löst jede Aufgabe perfekt. Lies jeden Diff, baue das Projekt und führe deine Tests aus, bevor du eine Änderung akzeptierst. Ask first pausiert vor Aktionen, die etwas ändern, sodass eine schwache Antwort eines Modells dich nur wenige Sekunden zum Lesen kostet, anstatt eine kaputte Einheit. Verwerfe den Diff und formuliere die Anfrage neu, wenn sie nicht passt.
