Zum Hauptinhalt springen

Übersicht

Devin indexiert jetzt automatisch deine Repos und erstellt Wikis mit Architekturdiagrammen, Links zum Quellcode und Zusammenfassungen deiner Codebasis. Nutze Devin, um dich schnell in unbekannte Teile deiner Codebasis einzuarbeiten – schau es dir in deiner Seitenleiste an. Ask Devin verwendet Informationen aus dem Wiki, um deine Codebasis besser zu verstehen und den relevanten Kontext zu finden.
DeepWiki wird beim Verbinden von Repositories während des Onboardings automatisch erstellt.

Für öffentliche Repos

Eine kostenlose Version von DeepWiki und Ask Devin, die mit öffentlichen GitHub-Repositories funktioniert, ist jetzt verfügbar. Sie generiert automatisch Architekturdiagramme, Dokumentation und Links zum Quellcode, damit Sie unbekannte Codebasen schnell verstehen können. Sie können außerdem komplexe Fragen zur Codebasis stellen, um kontextbezogene, präzise Antworten zu erhalten. Besuchen Sie deepwiki.com, um beliebte Open-Source-Repositories wie React, TensorFlow, LangChain und viele weitere zu erkunden. Sie können auch die URL Ihres eigenen öffentlichen GitHub-Repositories zur Indexierung einreichen. DeepWiki jetzt ausprobieren →

DeepWiki steuern

Steerable Wiki UI Die Datei .devin/wiki.json ermöglicht es dir, das Standardverhalten von Devin bei der Wiki-Generierung zu steuern. Das ist besonders wichtig für große Repositories, die an integrierte Grenzwerte stoßen können. Wenn während der Wiki-Generierung eine Datei .devin/wiki.json im Stammverzeichnis deines Repositories gefunden wird, verwenden wir die angegebenen repo_notes und pages, um die Wiki-Generierung zu steuern. Wenn pages angegeben ist, überspringen wir die standardmäßige, clusterbasierte Planung und erstellen genau die Seiten, die du angibst. So wird sichergestellt, dass die wichtigen Teile deiner Codebasis dokumentiert werden, selbst wenn das automatische System sie ansonsten überspringen würde.

Konfigurationsformat

Erstellen Sie im Stammverzeichnis Ihres Repositories eine Datei .devin/wiki.json mit der folgenden Struktur:
{
  "repo_notes": [
    {
      "content": "Dieses Repository enthält die Haupt-UI-Komponenten im cui/-Ordner, die in der Dokumentation priorisiert werden sollten",
      "author": "Team Lead"
    }
  ],
  "pages": [
    {
      "title": "CUI-Komponenten – Übersicht",
      "purpose": "Dokumentiert die cui/-Ordnerstruktur und Haupt-UI-Komponenten",
      "parent": null
    },
    {
      "title": "Authentifizierungssystem",
      "purpose": "Dokumentiert den Authentifizierungsablauf und zugehörige Komponenten",
      "parent": null
    },
    {
      "title": "Login-Komponenten",
      "purpose": "Detaillierte Dokumentation der Login-bezogenen UI-Komponenten",
      "parent": "Authentifizierungssystem"
    }
  ]
}

Konfigurationsoptionen

repo_notes (Array)

Bietet Kontext und Hinweise, damit das Dokumentationssystem Ihr Repository besser verstehen kann.
  • content (string, erforderlich): Der Inhalt der Notiz (max. 10.000 Zeichen)
  • author (string, optional): Verfasser der Notiz

pages (Array, optional)

Gibt genau an, welche Seiten in deinem Wiki erstellt werden sollen. Dieses Feld ist optional. Wenn du nur repo_notes angibst, generiert das System trotzdem ein Wiki und nutzt deine Notizen, um Struktur und Fokus festzulegen, ohne dass du jede einzelne Seite vorgeben musst. Wenn du pages angibst, werden sie als explizite Anweisungen behandelt. Es werden nur die Seiten generiert, die du im JSON definierst – nicht mehr und nicht weniger.
  • title (string, required): Der Seitentitel (muss eindeutig und nicht leer sein)
  • purpose (string, required): Was auf dieser Seite dokumentiert werden soll
  • parent (string, optional): Titel der übergeordneten Seite zur hierarchischen Strukturierung
  • page_notes (array, optional): Zusätzliche Notizen, die speziell für diese Seite gelten

Validierungslimits

  • Maximal 30 Seiten (80 im Enterprise-Plan)
  • Maximal 100 Notizen insgesamt (repo_notes + alle page_notes zusammen)
  • Maximal 10.000 Zeichen pro Notiz
  • Seitentitel müssen eindeutig sein und dürfen nicht leer sein

Praktische Beispiele

Beispiel 1: Repo Notes zur Steuerung der Wiki-Generierung

Wenn Sie keine spezifischen Seiten definieren möchten, können Sie nur repo_notes angeben, um die Wiki-Generierung zu unterstützen. Dadurch kann Devin die Dokumentationsstruktur automatisch erstellen und dabei trotzdem Ihre Prioritäten und Fokusbereiche berücksichtigen. Das ist hilfreich, wenn Sie eine bessere Abdeckung und Betonung wünschen, ohne jede Seite explizit selbst skizzieren zu müssen.
{
  "repo_notes": [
    {
      "content": "Das Repository enthält drei Hauptbereiche: den Ordner frontend/ mit React-Komponenten, den Ordner backend/ mit API-Services und den Ordner infra/ mit Deployment-Skripten. Die Dokumentation sollte die Interaktion dieser Komponenten hervorheben und die Backend-API-Schicht als höchste Priorität darstellen."
    }
  ]
}

Beispiel 2: Sicherstellen, dass bestimmte Ordner dokumentiert werden

Wenn Ihr umfangreiches Repository wichtige Ordner enthält, die im Wiki nicht berücksichtigt werden, führen Sie diese explizit auf:
{
  "repo_notes": [
    {
      "content": "Der cui/-Ordner enthält kritische UI-Komponenten, die dokumentiert werden müssen. Der backend/-Ordner enthält die Haupt-API-Logik. Der utils/-Ordner enthält gemeinsam genutzte Hilfsfunktionen, die in der gesamten Codebasis verwendet werden."
    }
  ]
}

Beispiel 3: Umgang mit fehlenden Komponenten

Wenn Sie feststellen, dass bestimmte Teile Ihrer Codebasis nicht dokumentiert werden:
{
  "repo_notes": [
    {
      "content": "Das Verzeichnis testing/ enthält wichtige Test-Utilities und Muster, die Entwickler kennen müssen. Das Verzeichnis scripts/ enthält Deployment- und Wartungsskripte, die für den Betrieb entscheidend sind."
    }
  ]
}

Beispiel 4: Hierarchische Dokumentationsstruktur

Für komplexe Repositories organisieren Sie Seiten hierarchisch:
{
  "repo_notes": [
    {
      "content": "Dies ist eine Full-Stack-Anwendung mit separaten Frontend-, Backend- und gemeinsam genutzten Komponenten, die getrennt, aber mit klaren Zusammenhängen dokumentiert werden sollten."
    }
  ],
  "pages": [
    {
      "title": "Architekturübersicht",
      "purpose": "Überblick über die Anwendungsarchitektur und die Interaktion der Komponenten auf hoher Ebene"
    },
    {
      "title": "Frontend",
      "purpose": "Struktur und Komponenten der Frontend-Anwendung",
      "parent": "Architekturübersicht"
    },
    {
      "title": "React-Komponenten",
      "purpose": "Detaillierte Dokumentation der React-Komponenten, ihrer Props und Verwendung",
      "parent": "Frontend"
    },
    {
      "title": "State Management",
      "purpose": "Verwaltung des Anwendungszustands, einschließlich Stores und Datenfluss",
      "parent": "Frontend"
    },
    {
      "title": "Backend",
      "purpose": "Backend-Services, APIs und Datenschicht",
      "parent": "Architekturübersicht"
    },
    {
      "title": "API-Endpunkte",
      "purpose": "REST-API-Dokumentation einschließlich Endpunkten sowie Request- und Response-Formaten",
      "parent": "Backend"
    }
  ]
}

Bewährte Vorgehensweisen

1. Repo Notes strategisch einsetzen

  • Geben Sie Kontext dazu, welche Teile Ihrer Codebasis am wichtigsten sind
  • Nennen Sie spezifische Ordner oder Komponenten, die priorisiert werden sollen
  • Erläutern Sie die Beziehungen zwischen verschiedenen Teilen Ihres Systems

2. Seiten logisch strukturieren

  • Beginnen Sie mit übergeordneten Übersichtsseiten
  • Nutzen Sie über- und untergeordnete Seiten, um klare Hierarchien zu erstellen
  • Fassen Sie verwandte Funktionen bzw. Funktionalitäten zusammen

3. Seien Sie konkret bei den Zwecken der Seiten

  • Geben Sie klar an, was jede Seite dokumentieren soll
  • Nennen Sie spezifische Verzeichnisse, Dateien oder Konzepte, auf die der Fokus liegen soll
  • Geben Sie ausreichend Details an, damit das System Ihre Absicht versteht

4. Bekannte Lücken gezielt angehen

  • Wenn Sie wissen, dass bestimmte Teile Ihrer Codebasis übersehen werden, schließen Sie sie explizit ein
  • Verwenden Sie aussagekräftige Titel, aus denen klar hervorgeht, was abgedeckt werden soll

Fehlerbehebung bei häufigen Problemen

”Nur bestimmte Ordner werden dokumentiert”

Dies ist das klassische Problem großer Repositories. Lösung: Verwende .devin/wiki.json, um explizit festzulegen, welche Teile deines Codes dokumentiert werden sollen.
Beginne damit, nur repo_notes zu aktualisieren, und generiere das Wiki mit diesem zusätzlichen Kontext neu, um zu prüfen, ob das aktualisierte Wiki die fehlenden Ordner enthält. Füge das pages-Array nur hinzu, wenn es wirklich nötig ist.

”Wichtige Komponenten fehlen im Wiki”

Fügen Sie für diese Komponenten eigene Seiten hinzu und verwenden Sie repo_notes, um ihre Bedeutung hervorzuheben.
Denken Sie daran: DeepWiki generiert nur die Seiten, die in diesem Array enthalten sind. Stellen Sie also sicher, dass alle Seiten vorhanden sind, nicht nur die fehlende Seite.
{
  "repo_notes": [
    {
      "content": "Das Verzeichnis [missing-component] ist kritisch für die Anwendung und muss vollständig dokumentiert werden."
    }
  ],
  "pages": [
    {
      "title": "Name der kritischen Komponente",
      "purpose": "Dokumentiert das Verzeichnis [missing-component] und seine Funktionalität"
    }
  ]
}

Erste Schritte

  1. Erstelle .devin/wiki.json im Stammverzeichnis deines Repositories
  2. Füge repo_notes hinzu, in denen du die Struktur und Prioritäten deiner Codebasis erläuterst
  3. Gib bei Bedarf alle Seiten an, die erstellt werden sollen, mit klaren Titeln und Zwecken
  4. Committe die Datei und generiere dein Wiki neu
Das System erstellt die Dokumentation nun auf Basis deiner expliziten Anweisungen statt durch vollständig automatische Analyse und sorgt so für eine umfassendere und genauere Abdeckung großer Repositories.