Mit TypeSafe bauen

Was macht Mit TypeSafe bauen?

TypeSafe macht KI-Intelligenzeinheiten nutzbar wie Programmier-Primitive: kleine Beurteilungen, die Sie zu größeren Fähigkeiten zusammensetzen können. Seine System-One-Modelle liefern schnelle, fokussierte Beurteilungen, die Software direkt verarbeiten kann. Jev ist TypeSafes Flaggschiff und erstes System-One-Modell. Es versteht natürliche Sprache und gibt typisierte Antworten und Wahrscheinlichkeiten zurück, anstatt Text oder Begründungen zu generieren. Der Code besitzt den Workflow; das Modell liefert programmierbaren gesunden Menschenverstand, wo normaler Code semantisches Verständnis benötigt.

Jev über OpenRouter aufrufen

Diese Variante der Skill ruft Jev über OpenRouter auf, nicht über TypeSafes eigene API. TypeSafes Dokumentation bleibt die Referenz für Konzepte und Fragendesign; nur Zugang, Modell-IDs und Abrechnung unterscheiden sich.

• Anmeldedaten: ein OpenRouter-API-Key, abgerechnet über das OpenRouter-Konto. Es wird kein TypeSafe-Konto benötigt. Lesen Sie ihn aus der Umgebung (OPENROUTER_API_KEY oder TYPESAFE_API_KEY auf den OpenRouter-Key gesetzt); hard-coden Sie ihn niemals und bewahren Sie ihn serverseitig in Web-Apps auf.
• System-One-API (Standard): POST https://openrouter.ai/api/v1/systemone mit Authorization: Bearer <OpenRouter-Key>. Sie implementiert TypeSafes Anfrage- und Antwortstrukturen und fügt id, provider und usage.cost zur Antwort hinzu.
• TypeSafe-SDKs (@typesafe-ai/sdk, typesafe_sdk): setzen Sie die Basis-URL auf https://openrouter.ai/api (das SDK hängt /v1/systemone an) über baseURL / base_url oder TYPESAFE_BASE_URL, und übergeben Sie den OpenRouter-Key über apiKey / api_key oder TYPESAFE_API_KEY. Alles andere folgt der TypeSafe-SDK-Dokumentation.
• Rufen Sie die Modellliste des SDKs nicht auf (client.models.list()): auf OpenRouter trifft es auf die OpenRouter-Modelle-API, deren Antwortstruktur das SDK ablehnt.
• Modell-IDs: jev-1.14 (aktuell), jev-1.13 oder jev-latest; nackte IDs werden zu typesafe/jev-… und ~typesafe/jev-latest aufgelöst. Fixieren Sie eine Version für reproduzierbare Schwellenwerte. Prüfen Sie die TypeSafe-Modelle auf OpenRouter auf aktuelle Versionen, Preise und Kontextlänge; das model-Feld der Antwort benennt die exakte Version, die die Anfrage bedient hat.
• Box (ein beschriebenes Ziel in einem Bild in state lokalisieren) benötigt jev-1.14 oder neuer; 1.13 lehnt es mit einem 400 ab. Box gibt immer Kanten zurück, also kombinieren Sie es mit einem Noul, wenn das Ziel fehlen könnte.
• Alternative Oberfläche: OpenRouters eigene Decisions-API (POST https://openrouter.ai/api/alpha/decisions) und deren TypeScript-, Python- und Go-SDKs. Bevorzugen Sie sie nur, wenn das Projekt bereits das OpenRouter-SDK verwendet.
• Nicht Jevs typisierte API: typesafe/jev-router ist ein Chat-Completions-Router, der Jev verwendet, um ein anderes LLM auszuwählen. Er gibt generierten Text zurück, keine typisierten Antworten, daher passt er nicht zu den Mustern dieser Skill.
• Cloud- und Sandbox-Sitzungen: die Netzwerk-Whitelist muss openrouter.ai enthalten; speichern Sie den Key als Geheimnis, nicht als einfache Umgebungsvariable.

OpenRouter-Dokumentation: Jev auf OpenRouter, TypeSafe-SDK auf OpenRouter, Jev-Tutorial und das Dokumentationsverzeichnis (durchsuchen Sie es nach „Jev", um die Cookbooks zu finden). Wenn die OpenRouter- und TypeSafe-Dokumentation bezüglich Zugriff, Endpunkten, Modell-IDs oder Preisen voneinander abweichen, gilt die OpenRouter-Dokumentation für dieses Setup.

Die Live-Dokumentation lesen

Die Live-TypeSafe-Dokumentation ist die maßgebliche Quelle. Lesen Sie sie als Teil der Aufgabe. Diese Skill gibt eine Richtung vor; die Dokumentation enthält aktuelle Konzepte, Prompting-Hinweise, API-Verträge, SDK-Nutzung, Modelle, Grenzen und ausgearbeitete Beispiele.

• Beginnen Sie mit dem Dokumentationsverzeichnis, um relevante Seiten und Cookbooks zu entdecken. Verwenden Sie gezielte Lektüre, anstatt die gesamte Seite zu laden.
• Mintlify liefert Markdown durch Anhängen von .md an einen Seitenpfad, zum Beispiel Wie man mit TypeSafe baut. Folgen Sie Links aus dem Verzeichnis; konvertieren Sie Links zu Dokumentationsseiten ohne Endung nach Bedarf zu .md. Lösen Sie relative Links gegen https://docs.typesafe.ai auf.
• Bevor Sie eine Integration schreiben, lesen Sie die aktuelle API- oder gewählte SDK-Seite und die für das Design relevante Fragenanleitung. Prüfen Sie für einen neuen Workflow auch das nächstgelegene Cookbook: es zeigt oft eine bessere Zerlegung als ein generischer Klassifikator.
• Wenn das Verzeichnis nicht verfügbar ist, verwenden Sie die direkten Links unten oder die Navigation der Seite. Wenn das Markdown-Fetching fehlschlägt, versuchen Sie es mit der normalen Seite. Wenn Live-Zugriff nicht verfügbar ist, verwenden Sie verfügbare lokale Dokumentation oder installierte SDK-Typen, geben Sie diese Einschränkung an und vermeiden Sie das Erfinden versionsabhängiger Details.

Aufgabe	Hier beginnen; den relevanten Details folgen
Das Programmiermodell verstehen	System One, Bauanleitung
Erkunden, was gebaut werden kann	Use-Case-Karte, dann relevante Cookbooks aus dem Verzeichnis
Eingaben und Fragen vorbereiten	State, Primitive, dann die Seite des gewählten Primitivs
Entscheiden, wie mit Unsicherheit umgegangen wird	Confidence
API-Code schreiben	TypeSafe-SDK auf OpenRouter zuerst, dann HTTP-API, Python-SDK oder JavaScript-SDK für Anfragestrukturen, mit OpenRouter-Basis-URL und -Key
OpenRouter-Cookbooks finden	Tool-Call-Gating, Verifizierte Kaskade, Klassifikation in großem Maßstab, Permission-Prompt-Auto-Approval
Eine ältere Integration aktualisieren	Migrationsanleitung und die aktuelle Referenz des installierten SDKs

Die nützliche Form finden

Beginnen Sie mit dem Verhalten, das der Benutzer wünscht: Was soll die Anwendung anzeigen, auswählen, ändern oder übergeben? Arbeiten Sie rückwärts zu den benötigten Beurteilungen. Behalten Sie bekannte Regeln, Berechnungen, exakte Nachschlagevorgänge und Ausführung im Code. Bewahren Sie den gewählten Stack und Umfang des Benutzers; fügen Sie TypeSafe hinzu, wo semantisches Verständnis hilft.

Betrachten Sie beim Brainstorming oder der Wahl einer Architektur mehr als nur Klassifikation. Die folgenden Muster sind Ausgangspunkte: Kombinieren Sie Primitive rund um das Ziel des Benutzers, einschließlich Ideen, die nicht in ein etabliertes Rezept passen.

• Bekannte Argumente routen und füllen. Eine Anfrage kann einen Handler und seine typisierten Parameter auswählen. Stellen Sie nützliche verzweigungsspezifische Fragen im Voraus und verwenden Sie nur die relevanten Antworten. Erkunden Sie Function Calling und Spekulativer Fan-Out.
• Auswählen statt generieren. Finden Sie Kandidatenwerte oder Quellspannen im Code, verwenden Sie eine Beurteilung, um den beabsichtigten auszuwählen, dann kopieren oder normalisieren Sie ihn. Code kann auch Quelltext zu einem formatierten Dokument oder Leseleitfaden zusammenstellen. Erkunden Sie Wertextraktion und Strukturwiederherstellung.
• Evidenz finden und beurteilen. Rufen Sie Kandidaten ab, vergleichen Sie ihre Relevanz für eine Abfrage und wählen Sie nützlichen Kontext aus. Erkunden Sie Reranking und Hierarchische Klassifikation.
• Beurteilungen in wiederverwendbare Daten verwandeln. Bewerten Sie Dimensionen einmal, lassen Sie dann Code oder Benutzersteuerungen Gewichte, Schwellenwerte, Rankings und Ansichten ändern. Mit gelabelten Ergebnissen können diese Signale zu klassischen ML-Merkmalen werden. Erkunden Sie Composite Scoring und Feature Discovery.
• Verifizieren und eskalieren. Prüfen Sie spezifische Behauptungen oder Felder gegen ihre Evidenz; leiten Sie unsichere oder fehlschlagende Fälle an eine Person oder ein Reasoning-Modell weiter. Erkunden Sie Zitationsprüfungen und Extraktionskaskaden.
• Auf sich ändernden Zustand reagieren. Code kann Ziele und Beobachtungen behalten, während frische Beurteilungen den nächsten begrenzten Schritt leiten. Halten Sie abgeleiteten Zustand getrennt von beobachteten Fakten und prüfen Sie die Aktualität, bevor Sie ein Ergebnis auf eine geänderte Situation anwenden.

Bieten Sie für offene Anfragen die wenigen Richtungen an, die das Ziel des Benutzers am besten bedienen, und empfehlen Sie einen Ausgangspunkt. Wählen Sie für eine konkrete Anfrage das relevante Muster und bauen Sie es; ein Brainstorming ist kein obligatorischer Umweg.

Die Beurteilungen entwerfen

Wählen Sie nach der Bedeutung der Antwort, lesen Sie dann die relevante Primitivseite:

Bedarf	Primitiv	Wichtige Unterscheidung
Eines aus einer definierten Menge	Choice	Wählt eine Option; seine Verteilung vergleicht konkurrierende Optionen
Ob eine Bedingung gilt	Noul	Wahrscheinlichkeit von Ja; kein separates Vertrauen; verwenden Sie eines pro Label, wenn mehrere zutreffen könnten
Grad entlang einer beschriebenen Dimension	Score	Wahrscheinlichkeitsgewichtete Position auf geordneten Stufen; verwenden Sie vergleichbare Scores pro Element für abgestuftes Ranking
Wo ein beschriebenes Ziel in einem Bild ist	Box	Nur Jev 1.14+; keine Kriterien; gibt immer Kanten zurück, also fragen Sie einen Noul nach dem Vorhandensein

Geben Sie jeder Frage ausreichend relevanten State zur Beantwortung: Quelltext, Identitäten, Beziehungen, Richtlinien und aktuelle Fakten. Bevorzugen Sie benannte JSON-Felder, wenn der Kontext mehrere Teile hat. Setzen Sie die Beurteilung in Instructions und definieren Sie ihre möglichen Antworten in Criteria. Fragen-IDs sind für den Code und werden nicht an das Modell gesendet; geben Sie die vollständige Bedeutung in die Frage. Referenzieren Sie verschachtelten Zustand mit Backtick-Pfaden wie ticket.messages[0].text.

Stellen Sie eine enge, kohärente Beurteilung pro Frage. Teilen Sie unabhängig nützliche Dimensionen auf, ohne die Beziehung zu zerstören, die beurteilt wird. Eine begrenzte Aktionsauswahl oder kontextuelle Interpretation ist gültig; atomar bedeutet nicht wörtliche Faktenextraktion oder eine Begrenzung auf einen Satz. Strings funktionieren für einfache Fragen. Verwenden Sie strukturierte Objekte oder Arrays, wenn Definitionen, Kontraste, Ausschlüsse oder Beispiele Anweisungen oder Kriterien verdeutlichen. Score-Stufen müssen konkrete Situationen beschreiben und für sich allein stehen.

Halten Sie die benötigten Antworten verfügbar. Fügen Sie ein „Keine Übereinstimmung"-Ergebnis hinzu, wenn nichts passen könnte; verwenden Sie eine separate Vorhandenseinsbeurteilung, wenn sie unabhängig nützlich ist. Prüfen Sie bei der Auswahl von Quellwerten die Kandidatenabdeckung: Das Modell kann einen ausgelassenen Wert nicht wählen.

Zusammensetzen und verifizieren

Stellen Sie unabhängige Fragen zum gleichen State gemeinsam, einschließlich nützlicher spekulativer Fragen. Sie laufen parallel und können die Antworten des jeweils anderen nicht sehen. Formulieren Sie jede spekulative Prämisse explizit; der Code konsumiert die zutreffenden Antworten. Eine zweite Anfrage ist gerechtfertigt, wenn eine frühere Antwort benötigt wird, um Evidenz zu beschaffen, neuen State zu konstruieren oder die nächsten Optionen zu bestimmen. Zusätzliche Fragen verbrauchen trotzdem Tokens; messen Sie tatsächliche Anfragebudgets, Kosten und End-to-End-Latenz.

Verwenden Sie Wahrscheinlichkeiten und Vertrauen, um das Verhalten zu steuern, mit Schwellenwerten, die auf Benutzerdaten und Konsequenzen evaluiert werden. Choice/Score-Vertrauen fasst die Verteilungskonzentration zusammen, nicht die allgemeine Workflow-Korrektheit oder die Erlaubnis zu handeln. Ein Noul nahe 0,5 bedeutet ähnliche Wahrscheinlichkeit für Ja und Nein, nicht mittlere Intensität. Mehrere akzeptable Alternativen können auch die Wahrscheinlichkeit verteilen; niedriges Vertrauen muss eine harmlose Präferenzwahl nicht ungültig machen. Ignorieren Sie Unsicherheit bei ungenutzten Zweigen.

Halten Sie Richtlinien explizit und rohe Beurteilungen wiederverwendbar. Gewichtete Scores eignen sich für kompensierende Präferenzen; eine „Jede schwerwiegende Verletzung"-Regel benötigt separate Bedingungen. Das Ändern eines Gewichts oder Anzeigefilters muss keine Inferenz wiederholen, wenn Evidenz und Fragebedeutungen unverändert sind. Typisierte Ausgabe garantiert die Schnittstelle, nicht die Wahrheit. System-One-Modelle sind für kalibrierte Entscheidungen trainiert; validieren Sie ihre Leistung in der Zieldomäne.

Testen Sie repräsentative Fälle und das resultierende Anwendungsverhalten. Bei Fehlschlägen inspizieren Sie den exakten State, Fragen, Kandidaten, Antworten, Zusammensetzung und beobachtetes Ergebnis. Trennen Sie fehlende Evidenz, Modellfehler, Codefehler und Dienstfehler. Behandeln Sie Cookbook-Schwellenwerte und Demoergebnisse als zu evaluierende Beispiele, nicht als universelle Regeln oder dauerhafte Modelleinschränkungen. Behalten Sie API-Anmeldedaten bei Web-Apps serverseitig.