Diese Seite ist eine Übersetzung der englischen Dokumentation. Befehle, Bezeichner und Beispiele bleiben unverändert. Runtime 7.24.4 · SDK 2.6.7. Englische Fassung

AX Wiki Übersicht

Status: Aktiv
Umfang: aktueller Stand
Zuletzt geprüft: 2026-10-03 Verantwortlich: AX-Code-Laufzeit

AX Wiki ist der native Repository-Wiki-Compiler von AX Code. Er macht versionierte Quellen, Konfiguration, Tests, Workflows und vorhandene Dokumentation zu einer kleinen, quellengebundenen Markdown-Wissensbasis unter .ax-wiki/. Er nutzt dieselbe Anbieterkonfiguration und dasselbe Modell-Routing wie AX Code; es gibt keine eigene ausführbare Datei und keinen eigenen Anmeldespeicher.

ax-code wiki viz zeichnet die kompilierten Seiten und die Dateien, die sie zitieren. Bildschirmfotos dieser Karte stehen in der Visualisierung von Wiki-Nachweisen.

Einordnung

Wiki-Prosa ist eine kompilierte Navigationsschicht, kein struktureller Beweis. Weicht das Wiki vom Code ab, vertrauen Sie dem Code und führen Sie ax-code wiki update aus.

Schnellstart

Verbinden Sie einen Anbieter von AX Code und führen Sie dann aus:

ax-code wiki plan
ax-code wiki generate
ax-code wiki doctor

ax-code init --wiki erzeugt AGENTS.md, fügt den Zeigerblock von AX Wiki ein und kompiliert das Wiki in einem Arbeitsablauf. Nutzen Sie --wiki-only-agents, um Zeiger ohne Modellaufrufe hinzuzufügen.

Befehle

Zu den Generierungsoptionen gehören --model provider/model, --dir <relative>, --quiet, --skip-agents und --force. --force ist absichtlich erforderlich, um erzeugten Inhalt zu ersetzen, der außerhalb geschützter Abschnitte von Hand bearbeitet wurde.

Repository-Verzeichnis

Ab v7.22.2 ist das Standard-Ausgabeverzeichnis .ax-wiki/. Das verborgene Präfix kennzeichnet Repository-Wissen, das AX Code pflegt. Es macht Dateien nicht für Git ignoriert: Entscheiden Sie, ob Sie dieses Wissen committen oder /.ax-wiki/ zur .gitignore Ihres Repositorys hinzufügen.

Nutzen Sie wiki.dir in ax-code.json oder --dir docs/knowledge, um ein anderes relatives Verzeichnis zu wählen; das CLI-Flag hat Vorrang. Generierung, Status, Agenten-Zeiger, Hintergrundpflege und Visualisierung nutzen alle diese Auswahl. Der Compiler erkennt, verschiebt oder führt ein älteres Verzeichnis ax-wiki/ nicht automatisch zusammen. Namen von Paket und Generator, ax-wiki.config.json und ax-wiki.instructions.md bleiben unverändert.

Erzeugter Vertrag

AX Wiki schreibt Markdown-Seiten und .ax-wiki/.manifest.json. Jede Seite hat Frontmatter mit:

• generated_by: ax-wiki
• einer knappen summary
• genauen symbols aus nachweisgestützter Generierung
• dem repositoryrelativen sources, mit dem die Seite kompiliert wurde

Das Manifest speichert den deterministischen Plan-Hash, die Quell-Hashes des Repositorys, die Seiten-Hashes, das Generierungsmodell, die Git-Revision und die Generierungszeit. Seiten werden atomar geschrieben; das Manifest wird zuletzt geschrieben und erst, nachdem der vollständige Kandidat im Speicher die Prüfung besteht.

Die Quellensuche bevorzugt die von Git verfolgte und nicht ignorierte Dateiliste, schließt erzeugte Verzeichnisse, Build-Verzeichnisse, Vendor-Verzeichnisse und das Wiki selbst aus, überspringt binäre oder übergroße Dateien und lehnt Pfade oder Symlinks außerhalb des Repositorys ab.

Navigation nach Subsystemen

Der Standardplan behält Seiten für Schnellstart, Architektur und Entwicklung. Ein Modul, das das Budget einer Seite für Quellenanzahl oder Nachweisbytes überschreitet, kann zusätzlich fokussierte Seiten wie modules/core/src/session.md erhalten. Diese Seiten decken direkte Unterverzeichnisse unter dem Verzeichnis src, lib oder app des Moduls ab, mit mindestens drei Codedateien je Subsystem und zwei geeigneten Subsystemen im Modul.

Subsystemseiten enthalten ihren Implementierungsbaum und passende Dateien unter dem Verzeichnis test oder tests des Moduls. Ihre Generierungsanweisungen verlangen Einstiegspunkte, Laufzeitfluss, Grenzen, konkrete Änderungsorte und zugehörige Tests. Modulseiten setzen bis zu zwei Testdateien unmittelbar nach der höchstbewerteten Quelle, damit Tests an der begrenzten Nachweisauswahl teilnehmen können.

Das gesamte Standardbudget bleibt bei 12 Seiten, einschließlich der drei Übersichtsseiten. Modulübersichten und Subsystemseiten konkurrieren nach Quellenanzahl um die übrigen Plätze; ein Subsystem wird erst aufgenommen, nachdem seine übergeordnete Übersicht steht. Größere Subsysteme können daher kleinere Paketseiten verdrängen. Sehen Sie das Ergebnis mit ax-code wiki plan in der Vorschau. Erhöhen Sie maxPages (bis 40 für automatische Pläne) oder konfigurieren Sie ausdrückliche pages, wenn ein bestimmtes Subsystem garantierte Abdeckung braucht. Ausdrückliche Pläne bleiben maßgeblich und erhalten keine automatischen Subsystemseiten.

Das verbessert Navigation und Nachweisschärfe; es prüft erzeugte Prosa nicht und garantiert nicht, dass ein Agent das Wiki liest. Folgen Sie Zitaten zur aktuellen Quelle zurück, bevor Sie sich auf Implementierungsdetails verlassen.

Wie Agenten das Wiki nutzen

Agenten erreichen das Wiki auf drei Wegen, vom günstigsten zum genauesten:

1. Prompt-Index. Existiert ein gesundes Wiki, trägt der Sitzungs-Prompt einen kurzen Block <repo_wiki>: den Ort des Wikis, eine Frischekennzeichnung und eine Zeile je Seite (Pfad und eine gekürzte Zusammenfassung, etwa 750 Token für die standardmäßigen 12 Seiten). Die Zusammenfassungen zeigen nur, wo zu lesen ist; sie sind kein Beweis.
2. Tool repo_wiki. Ein schreibgeschütztes Tool mit drei Operationen: index (Seitenkarten mit Frische je Seite), read (eine Seite plus ihre zitierten Quellen, welche zitierten Quellen sich geändert haben und welche Frontmatter-Symbole in diesen Quellen fehlen) und related (Seiten für ein Symbol, eine Erwähnung im Text oder einen Quellpfad). Es steht in den Tool-Profilen für den vollen Umfang und für Coding bereit und nutzt die Genehmigung read.
3. Allgemeine Datei-Tools. read, glob und grep auf .ax-wiki/ funktionieren weiter.

Die Frische des Prompts wird je Seite beurteilt: Eine Seite ist frisch, solange jede von ihr zitierte Quelle noch zum Hash des Manifests passt. Eine hinzugefügte oder bearbeitete Datei, die keine Seite zitiert, belässt die Prompt-Kennzeichnung bei fresh und fügt einen Hinweis hinzu, dass das Wiki sie noch nicht abdeckt. Eine geänderte zitierte Quelle setzt die Kennzeichnung auf stale, und der Prompt bittet den Agenten, das Wiki nur als Navigation zu behandeln. ax-code wiki status und wiki lint behalten das strengere Urteil über das ganze Repository, bei dem jede hinzugefügte, entfernte oder bearbeitete geeignete Datei veraltet ist.

Das Wiki ersetzt nie die Quelle: Jedes Ergebnis von read listet die Dateien, gegen die zu prüfen ist, und wenn Seite und Code voneinander abweichen, gewinnt der Code.

Inkrementelle Aktualisierung und manueller Inhalt

wiki update vergleicht aktuelle Quell-Hashes mit dem Manifest und bildet Änderungen über die Selektoren jeder Seite ab. Eine Planänderung erzeugt alle geplanten Seiten neu; andernfalls bleiben unbeteiligte Seiten unberührt.

Erzeugte Prosa gehört dem Compiler. Legen Sie dauerhaften Betreuertext in einen geschützten Block:

<!-- AX-WIKI:PROTECTED:START deployment-warning -->

Production migrations require an operator-approved maintenance window.

<!-- AX-WIKI:PROTECTED:END -->

Geschützte Körper überstehen die Neuerzeugung. AX Wiki verweigert das Überschreiben anderer manueller Bearbeitungen, sofern nicht --force angegeben ist. Veraltete erzeugte Seiten werden nur entfernt, wenn ihr verwalteter Inhalt unverändert ist und sie keinen geschützten Abschnitt enthalten.

Konfiguration

Konfigurieren Sie die Integration in der Projektdatei ax-code.json:

{
  "wiki": {
    "enabled": true,
    "auto": true,
    "dir": ".ax-wiki",
    "model": "openai/gpt-5-mini",
    "autoInjectAgents": true,
    "touchClaudeMd": true,
    "maxPages": 12,
    "generationConcurrency": 2,
    "maxSourcesPerPage": 80,
    "exclude": ["fixtures/**"]
  }
}

include, exclude, maxSourceBytes und maxPageSourceBytes steuern Nachweisfindung und Budgets. instructions fügt compilerspezifische Anleitung für das Projekt hinzu. Für einen vollständig kuratierten Plan konfigurieren Sie Einträge pages mit path, title, purpose und selectors; ein ausdrücklicher Plan muss quickstart.md enthalten.

generationConcurrency akzeptiert 1 oder 2. Native Generierung in der Cloud nutzt standardmäßig zwei gleichzeitige Seitenaufrufe; lokale Engines und CLI-Anbieter nutzen standardmäßig einen. Setzen Sie den Wert auf 1, wenn ein Anbieter überlappende Anfragen einreiht oder drosselt. Die Planung macht vorhandenen Seiteninhalt nicht ungültig. Das wiederverwendbare Paket bleibt seriell, sofern diese Einstellung nicht angegeben ist.

Jede Modellseite erhält höchstens zwei eingestufte Versuche, die sich eine Frist von 180 Sekunden teilen. Relative Wiki-Links werden vor der Annahme der Seite gegen den Seitenplan geprüft; eine Antwort mit defektem Link darf den verbleibenden Versuch nutzen, um diese Seite zu reparieren. Abschließende Prüfung und Schutz manueller Inhalte laufen weiter vor der Veröffentlichung.

Unterbrochene Builds behalten geprüfte Ergebnisse in .ax-wiki/.page-cache/ (oder im konfigurierten Wiki-Verzeichnis). Ein späterer Build verwendet passende Ergebnisse nur wieder, nachdem aktuelle Quellennachweise, Plan, Generator, Modell und vorheriger Inhalt geprüft wurden. Die erste Generierung bleibt unveröffentlicht, bis der vollständige Kandidat die Prüfung besteht. Eine erfolgreiche Veröffentlichung entfernt verbrauchte Staging-Einträge; ein späteres ausdrückliches wiki generate erzeugt weiterhin alle Seiten neu. Cache-Einträge sind begrenzt und an eine Genehmigung gebunden; beschädigte oder unzugängliche Einträge werden ignoriert.

.build-report.json unterscheidet modellgenerierte und zwischengespeicherte Seiten von Seiten written, die tatsächlich veröffentlicht wurden. Das optionale Array pages zeichnet je Seite Versuche, Dauer, Byte-Größen von Prompt und Quelle sowie den genauen Token-Verbrauch auf, wenn der Anbieter ihn liefert. Fehlgeschlagene oder abgebrochene Builds melden keine veröffentlichten Seiten.

Sie können Compiler-Anleitung auch in ax-wiki.instructions.md und die Konfiguration der Kern-Engine in ax-wiki.config.json ablegen. Ausdrückliche Laufzeiteinstellungen von AX Code überschreiben die Kernkonfiguration, wo beide angegeben sind.

Standardmäßige interaktive Pflege

Das Öffnen eines Projekts in der TUI von AX Code aktiviert die Wiki-Pflege im Hintergrund standardmäßig. Nach 30 Sekunden Leerlauf des Projekts werden fehlende Artefakte erzeugt und veraltete Artefakte inkrementell aktualisiert. Beschäftigte oder wiederholende Sitzungen, eingereihte Arbeit und ein nicht leerer Entwurf haben Vorrang und brechen die Hintergrundgenerierung ab. Die Lese- und Schreibrechte des aktuellen Agenten gelten; schreibgeschützte Agenten erzeugen nichts. Dieser Hintergrund-Workflow schreibt keine Anweisungsdateien für Agenten um.

Nutzen Sie "wiki": { "auto": false }, um die Hintergrundpflege abzuschalten, oder enabled: false, um Kompilierung und Prompt-Injektion abzuschalten. auto ist standardmäßig wahr und schreibt keine Konfiguration. Der Ablauf nutzt das konfigurierte Wiki-Modell oder das Standardmodell von AX Code, mit einer Auftragsfrist von 10 Minuten und bis zu drei automatischen Versuchen mit Backoff. Eine ausdrückliche Graph-Anfrage oder eine Änderung von Quelle oder Konfiguration erlaubt einen weiteren Versuch. Headless-Läufe und CI aktivieren den interaktiven Planer nicht. Verzeichnisse ohne Git verlangen eine ausdrückliche Anfrage. In Git-Projekten nutzen Generierung und Nutzung des Wikis die nächste Worktree-Wurzel, sodass das Öffnen von AX Code in einem Paket kein separates Paket-Wiki erzeugt.

Die Seitenleiste der Sitzung und /wiki-viz öffnen sofort eine lokale Fortschrittsseite und fordern Pflege an. Sobald ein Snapshot bereit ist, zeigt diese Seite aufgezeichnete Beziehungen zwischen Wiki-Seiten und Quellen. Siehe Wiki-Visualisierung.

Agenten-Routing

Existiert ein gesundes Wiki und ist wiki.enabled nicht false, erhalten Sitzungs-Prompts ein kompaktes Protokoll <repo_wiki>. Das Protokoll weist Agenten an, beim Schnellstart zu beginnen, nur relevante Seiten zu laden, wichtige Behauptungen über zitierte Dateien zu prüfen und Graph- sowie LSP-Tools für strukturelle Fragen zu nutzen.

healthy beschreibt das Vorhandensein von Wiki-Verzeichnis, Index und Manifest. Das separate Feld freshness lautet fresh, stale oder unknown. Status und Sitzungs-Routing vergleichen aktuelle Quell-Hashes anhand der wirksamen Einstellungen für Include, Exclude und Größe, sodass uncommittete Bearbeitungen, Ergänzungen und Löschungen erkannt werden. Prüfungen verwenden ein zwischengespeichertes Frischeurteil nicht erneut; sie durchsuchen geeignete Quellen mit begrenzter Nebenläufigkeit beim Lesen. Fehlende oder deaktivierte Wikis vermeiden den Quellenscan. Frische ist eine Quellenprüfung zu einem Zeitpunkt, keine Prüfung jeder erzeugten Behauptung oder Seite; nutzen Sie Lint zur Prüfung der Artefakte.

Veraltete oder ungeprüfte Wikis bleiben zur Navigation verfügbar, mit der ausdrücklichen Anweisung, die aktuelle Originalquelle zu prüfen, bevor Sie sich auf Behauptungen zur Implementierung verlassen. Prüffehler erzeugen unknown. wiki status endet mit Exit 0, wenn kein Wiki-Verzeichnis existiert (das fehlende Wiki ist der Bericht). Ist ein Wiki vorhanden, endet der Befehl erfolglos, wenn das Wiki ungesund ist oder die Frische nicht fresh lautet.

Wiki-Nachweise sind begrenzt: Jede ausgewählte Quelle trägt höchstens ihre ersten 32,000 Bytes innerhalb des Seitenbudgets bei, mit für den Generator markierter Kürzung. GraphContext kann ausgewählte Ausschnitte hinzufügen, jeder Ausschnitt ist aber auf 80 Zeilen begrenzt. Diese Navigationshilfen garantieren nicht, dass jede geänderte Funktion oder erforderliche Schutzbedingung erhalten bleibt; stellen Sie den nötigen Originalcode für eine eingegrenzte Prüfung getrennt bereit.

Der verwaltete Block <!-- AX-WIKI:START --> in AGENTS.md trägt dieselbe Routing-Richtlinie, ohne Inhalt des Wikis in die Anweisungen des Repositorys zu kopieren.

CI

Führen Sie ax-code wiki update und danach ax-code wiki lint in einem Auftrag mit authentifiziertem Anbieter aus und öffnen Sie dann einen Dokumentations-PR. Siehe examples/ax-wiki-update.yml. Behandeln Sie erzeugte Wiki-Änderungen wie andere Dokumentation: Prüfen Sie Quellenzitate und vermeiden Sie das automatische Zusammenführen von Modellausgabe.

Fehlerbehebung