Die Claude-Apps und Projects: persistenter Kontext, der sich erinnert

Legen Sie ein 200-seitiges Unternehmenshandbuch und einen einseitigen Styleguide in ein Claude Project, und jeder Chat in diesem Project startet bereits gebrieft: Claude antwortet in Ihrer Hausstimme, zitiert Ihre Richtlinien und bittet Sie nie wieder, dieselben Dokumente erneut einzufügen. Genau das verspricht Projects, und es ist die am wenigsten genutzte Funktion im Claude-Ökosystem.

Diese Lektion gibt einen Überblick über die Claude-Apps und geht dann ausführlich auf Projects als Container für persistenten Kontext ein. Das Context Window kennen Sie bereits. Die Frage hier ist operativ: Wie hören Sie auf, denselben Hintergrund manuell in jede Unterhaltung einzuspeisen?

Die drei Claude-Apps im Überblick

Claude gibt es als drei Clients, die sich ein Konto und einen Funktionsumfang teilen:

Web (claude.ai) ist die maßgebliche Oberfläche. Alles landet zuerst hier.
Desktop (macOS und Windows) ergänzt lokale MCP-Server, sodass Claude mit Dateien und Apps auf Ihrem eigenen Rechner arbeiten kann. Hier hört Claude auf, ein Chatfenster zu sein, und greift in Ihre Umgebung ein.
Mobile (iOS und Android) ist zum Festhalten und für schnelle Abfragen gedacht: einen Gedanken diktieren, ein Whiteboard fotografieren, einen Project-Chat im Zug fortsetzen.

Es sind keine drei Produkte. Ein Project, das Sie im Web anlegen, steht sofort auf Desktop und Mobile zur Verfügung. Die Unterschiede liegen in der *reach*. Remote-Connectors (Google Drive, GitHub, Notion und ähnliche) funktionieren auf jedem Client. Nur Desktop kann lokale MCP-Server ausführen, die auf Ihr Dateisystem und lokale Apps zugreifen.

Ein Begriff, kurz definiert: Ein Connector ist ein Stecker, über den Claude aus einem externen System (Google Drive, GitHub, eine Datenbank) lesen oder darin handeln kann, und zwar über MCP, das Model Context Protocol. Connectors streifen wir hier nur, ausführlich behandeln wir sie in einer späteren Lektion. Heute geht es um die Ebene des persistenten Kontexts, die *über* jedem Connector liegt.

Was ein Project tatsächlich ist

Ein Project ist ein Workspace, der folgende Bausteine bündelt und auf jeden darin erstellten Chat anwendet:

Project knowledge: Dateien und Texte, die Sie einmal hochladen (PDFs, Dokumente, Tabellen, eingefügter Referenztext).
Custom Instructions: ein dauerhaftes Briefing auf Systemebene, das Ton, Format und Verhalten prägt.
Die Chats selbst: jede Unterhaltung, die Sie im Project beginnen, an einem Ort gesammelt.
Project-Memory (wo Memory aktiviert ist): eine Zusammenfassung, die Claude aus Ihren bisherigen Chats in diesem Project erstellt, getrennt von Ihren anderen Projects.

Das mentale Modell: Ein normaler Chat ist ein leerer Raum. Ein Project ist ein Raum, in dem das Briefing schon an der Wand hängt, bevor Sie eintreten. Sie stellen den Kontext nicht jedes Mal neu her; Sie machen auf einer gemeinsamen Basis weiter.

Das ist etwas anderes, als Ihr Handbuch in eine einzelne Unterhaltung einzufügen. Eingefügter Kontext stirbt mit dem Ende des Chats. Project knowledge bleibt über alle Chats hinweg erhalten, unbegrenzt, für alle mit Zugriff auf das Project (in den Team- und Enterprise-Plänen lassen sich Projects teilen).

Die offizielle Referenz finden Sie in Anthropics Hilfedokumentation zu Projects.

Memory: was Claude selbst aufnimmt

Seit Ende 2025 kann sich Claude an Kontext aus früheren Unterhaltungen erinnern. Sie können einsehen und bearbeiten, was gespeichert ist, und die Funktion in den Einstellungen abschalten. Außerdem gibt es einen Inkognito-Modus für Chats, die nicht ins Memory einfließen sollen.

Das für diese Lektion wichtige Detail: Memory gilt pro Project. Was Claude in „Support Desk Assistant“ lernt, bleibt dort und sickert nicht in Ihr Project „Q3 Marketing Copy“ durch. Damit sind Projects die natürliche Grenze, um Kundenarbeit, Teams oder vertrauliche Themen voneinander zu trennen.

Memory und Project knowledge erfüllen unterschiedliche Aufgaben. Knowledge ist das, was Sie bewusst hochladen und kontrollieren. Memory ist das, was Claude aus Ihrer Arbeitsweise ableitet (wiederkehrende Fragen, Entscheidungen von letzter Woche). Verlassen Sie sich bei Richtlinien nicht auf Memory. Wenn eine Regel wichtig ist, schreiben Sie sie in die Instructions oder ins Knowledge-Panel.

Der konkrete Aufbau: Handbuch plus Styleguide

Hier das Szenario vom Anfang, sauber umgesetzt.

Sie haben zwei Assets:

company-handbook.pdf: 200 Seiten Richtlinien, Benefits, Eskalationswege, Sicherheitsregeln.
style-guide.md: eine Seite zur Tonalität (warm, direkt, kein Jargon, britische Schreibweise, nie Erstattungen ohne Freigabe eines Managers zusagen).

Schritt 1: Project anlegen. Öffnen Sie in der Web-App Projects und legen Sie eines namens „Support Desk Assistant“ an.

Schritt 2: Handbuch zu Project knowledge hinzufügen. Laden Sie company-handbook.pdf ins Knowledge-Panel hoch. Claude indexiert die Datei. Ab jetzt kann jeder Chat in diesem Project auf die Eskalationsrichtlinie auf Seite 147 zurückgreifen, ohne dass Sie etwas einfügen.

Schritt 3: Custom Instructions schreiben. Hier machen es sich die meisten zu leicht. Seien Sie konkret:

text

You are the internal support assistant for Acme Ltd.

Sources of truth:
- Always ground policy answers in the uploaded company handbook.
- Always follow the uploaded style guide for voice and formatting.

House rules:
- Use British spelling. Warm but direct. No corporate jargon.
- Never promise a refund. For refunds, instruct the user to flag a manager
  and quote handbook section 6.2.
- If the handbook does not cover something, say so plainly and do not guess.
- End policy answers with the handbook section number you used.

Schritt 4: Testen. Starten Sie einen neuen Chat im Project und fragen Sie: „Ein Kunde möchte nach 40 Tagen eine Erstattung. Was sage ich ihm?“

Claude antwortet in britischer Schreibweise, im warmen, aber direkten Ton, sagt keine Erstattung zu, verweist auf Abschnitt 6.2 und nennt die Quelle. Sie haben nichts eingefügt. Der nächste Chat und der Chat, den Ihr Kollege morgen startet, verhalten sich genauso.

Um diese Wiederholbarkeit geht es. Ein Project macht aus „Claude, das das heute zufällig weiß“ ein „Claude, das sich jedes Mal verlässlich so verhält“.

Project knowledge vs. Context Window

Eine berechtigte Frage: Wenn Sie 200 Seiten hochladen, verbraucht das bei jeder Nachricht Ihr Context Window?

Nicht so, wie es beim Einfügen der Fall wäre. Bei umfangreichem Project knowledge ruft Claude die relevanten Abschnitte ab, statt das ganze Dokument in jeden Prompt zu packen (dieselbe Retrieval-Idee, die Sie früher im Kurs auf Konzeptebene kennengelernt haben). Ist es klein, kann es vollständig im Kontext liegen. So oder so müssen Sie es nicht manuell verwalten.

Praktische Konsequenz: Halten Sie Project knowledge *kuratiert*. Ein straffes Handbuch plus ein sauberer Styleguide schlagen vierzig lose zusammenhängende PDFs. Die Retrieval-Qualität sinkt, wenn die Wissensbasis verrauscht ist. Behandeln Sie das Knowledge-Panel wie ein Nachschlageregal, nicht wie einen Dachboden.

Styles: Tonalität, ohne jedes Mal die Instructions umzuschreiben

Hier gibt es eine Überschneidung, die eine Klärung verdient. Mit Styles speichern Sie eine wiederverwendbare Schreibstimme (formell, knapp, Ihr Markenton) und wenden sie mit einem Klick auf jeden Chat an, auch *über* Projects hinweg. Sie können einen Style sogar anhand von Beispieltexten anlernen.

Wann also was?

Verhalten und Regeln, die zu einem bestimmten Wissensbestand gehören, kommen in die Custom Instructions des Projects (die Erstattungsregel oben).
Wiederverwendbare Tonalität, die Sie überall wollen, kommt in einen Style.

Im Handbuch-Beispiel ist „britische Schreibweise, warm, direkt“ eher ein Style, den Sie in vielen Projects wiederverwenden, während „für Erstattungen Abschnitt 6.2 zitieren“ in die Instructions dieses Projects gehört. Die Trennung hält jedes Project schlank und Ihre Tonalität unternehmensweit einheitlich.

Wo Artifacts und Skills ins Bild passen

Zwei weitere Bausteine vervollständigen das Bild in den Apps.

Artifacts sind eigenständige Outputs, die Claude in einem Seitenpanel erzeugt: ein Dokument, eine funktionierende Web-App, ein Diagramm, ein interaktives Tool. In Ihrem Support-Desk-Project könnten Sie Claude ein Artifact bauen lassen: eine kleine Triage-Checklisten-App, die die Eskalationslogik des Handbuchs abbildet. Sie wird live gerendert, Sie können im selben Chat daran weiterarbeiten, und sie übernimmt die Wissensgrundlage des Projects.

Skills sind gepackte, wiederverwendbare Fähigkeiten: Ordner mit Anweisungen plus optionalen Skripten und Ressourcen, die Claude lädt, wenn eine Aufgabe sie braucht. Ein Style prägt die Tonalität, Project knowledge liefert Fakten, ein Skill bringt Claude ein *Verfahren* bei: wie ein Quartalsbericht genau nach Ihren Vorgaben formatiert wird oder wie ein bestimmter Flow zur Dokumentenverarbeitung abläuft. Skills funktionieren in den Apps, über die API und in Claude Code. Die Struktur finden Sie in der Agent-Skills-Dokumentation.

Das Schichtenmodell ist das mentale Modell, das Sie behalten sollten:

Project knowledge = was Claude weiß.
Custom Instructions = wie Claude sich *hier* verhält.
Memory = was Claude aus Ihren bisherigen Chats in diesem Project aufgenommen hat.
Styles = wie Claude *überall* klingt.
Skills = Verfahren, die Claude ausführen kann.
Connectors / MCP = Systeme, die Claude erreichen kann.

How to use Claude Projects

Watch on YouTube

Wissenscheck

1. Welches Kernproblem sollen Claude Projects lösen?

2. Die Lektion nutzt die Metapher, ein normaler Chat sei ein „leerer Raum“. Wofür steht ein Project in dieser Metapher?

3. Was unterscheidet laut Lektion die drei Claude-Apps (Web, Desktop, Mobile) hauptsächlich voneinander?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Elemente aus, die ein Project bündelt und auf jeden darin erstellten Chat anwendet.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen aus, die laut Lektion korrekt beschreiben, wie die Desktop-App und Connectors funktionieren.

Wählen Sie alle richtigen Antworten aus.

Connectors und GitHub: wenn ein Project Live-Daten braucht

Statisches Wissen genügt für ein Handbuch, das sich quartalsweise ändert. Manche Projects brauchen aber *aktuelle* Daten, und hier kommen Connectors ins Spiel.

Die Apps enthalten ein Connector-Verzeichnis: Aktivieren Sie Google Drive, Gmail, GitHub, Notion und andere, und ein Chat kann in Echtzeit daraus lesen, im Web, auf Desktop oder Mobile. Sie können auch eigene Remote-MCP-Server hinzufügen. Lokale MCP-Server, die auf Dateien und Tools auf Ihrem eigenen Rechner zugreifen, laufen nur in Claude Desktop.

Die GitHub-Integration ist für technische Teams das Highlight. Verbinden Sie ein Repository, und Claude kann Ihre Codebasis als Kontext lesen. In einem Project, das auf ein Repo zugeschnitten ist, können Sie fragen „Wo validieren wir das Erstattungsfenster?“, und Claude arbeitet mit dem tatsächlichen Code. Das ist die Brücke zu Claude Code, dem Agenten, der direkt in Ihrem Repo arbeitet und später in diesem Lernpfad eine eigene ausführliche Lektion bekommt.

Die Unterscheidung, die Sie festhalten sollten: Project knowledge ist ein Snapshot, den Sie hochgeladen haben. Ein Connector ist eine Live-Leitung zu einer Quelle. Nutzen Sie Knowledge für stabile Referenzen (das Handbuch). Nutzen Sie Connectors für Dinge, die sich laufend ändern (offene Tickets, der aktuelle Branch, die Tabelle dieser Woche).

Wann Sie stattdessen zur API greifen

Alles oben beschreibt die App-Erfahrung: ein Mensch im Loop, der sich durch Chats klickt. Wenn Sie das *programmatisch* wollen, wechseln Sie zur Anthropic Messages API, wo persistenter Kontext im Stil eines Projects zu einem System-Prompt plus pro Request angehängten Dokumenten wird.

python

import anthropic

client = anthropic.Anthropic()

with open("style-guide.md") as f:
    style_guide = f.read()

message = client.messages.create(
    model="claude-sonnet-4-5",  # den aktuellen Namen auf der Models-Seite prüfen
    max_tokens=1024,
    system=(
        "You are Acme Ltd's support assistant. Follow this style guide "
        f"exactly:\n\n{style_guide}\n\n"
        "Never promise refunds; quote handbook section 6.2 instead."
    ),
    messages=[{
        "role": "user",
        "content": "Customer wants a refund after 40 days. What do I say?",
    }],
)

print(message.content[0].text)

Dieser system-Block ist das API-Pendant zu den Custom Instructions eines Projects, und pro Request angehängte Dokumente entsprechen Project knowledge. Zwischen API-Calls bleibt nichts erhalten, sofern Sie es nicht erneut senden (oder einen eigenen Speicher bauen). Die App macht das per Klick und persistent; die API macht es skriptfähig und einbettbar. Für agentische Workflows verpackt das Claude Agent SDK dasselbe Modell mit Tools und Schleifen. Einstieg über die API-Dokumentation.

Faustregel: Nutzen Sie Projects, wenn Menschen die Arbeit in einem gemeinsamen, sich weiterentwickelnden Raum erledigen. Nutzen Sie die API oder das Agent SDK, wenn Software die Arbeit in großem Maßstab erledigt.

Ein paar nicht offensichtliche Gewohnheiten

Ein Project pro Aufgabe, nicht pro Thema. „Support Desk Assistant“ und „Q3 Marketing Copy“ sollten getrennte Projects mit getrennten Instructions (und getrenntem Memory) sein. Gemischte Projects führen zu unscharfem Verhalten.
Versionieren Sie Ihr Knowledge. Wenn das Handbuch aktualisiert wird, ersetzen Sie die Datei, statt eine zweite Kopie hochzuladen. Zwei Versionen im Knowledge-Panel garantieren Widersprüche.
Formulieren Sie Instructions als Regeln, nicht als Stimmungen. „Nie eine Erstattung zusagen; Abschnitt 6.2 zitieren“ ist durchsetzbar. „Bei Erstattungen hilfsbereit sein“ nicht.
Prüfen Sie ab und zu das Memory. Hat Claude zu einem Project etwas Veraltetes gespeichert, bearbeiten oder löschen Sie es.
Verankern Sie die Regel zur Quellenangabe. Wenn Claude jede Antwort mit dem verwendeten Abschnitt beendet, wird aus einem selbstsicheren Assistenten ein überprüfbarer.

Das Wichtigste in Kürze

Ein Project bündelt persistentes Knowledge, Custom Instructions und Chats, sodass Claude jede Unterhaltung bereits gebrieft beginnt. Hören Sie auf, Kontext immer wieder einzufügen.
Memory gilt pro Project, deshalb funktionieren Projects auch als Grenzen für Vertraulichkeit. Wichtige Regeln gehören in die Instructions, nicht ins Memory.
Schichten Sie Ihre Werkzeuge nach Aufgabe: Knowledge (Fakten), Custom Instructions (Verhalten hier), Styles (Tonalität überall), Skills (Verfahren), Connectors/MCP (Live-Zugriff).
Remote-Connectors wie GitHub und Google Drive funktionieren auf jedem Client. Lokale MCP-Server brauchen Claude Desktop.
Wenn die Arbeit vom Menschen, der klickt, zur Software in großem Maßstab wandert, lebt dasselbe Muster in der Messages API (system-Prompt plus angehängte Dokumente) und im Agent SDK weiter.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

Wissen versionieren, indem Sie Dateien ersetzen und niemals eine zweite Kopie hochladen
Ein Tool zu Claude Code hochziehen, sobald es Secrets oder ein Repo braucht

Vollständiges Action Playbook ansehen →

Zurück

Die Claude-Modellfamilie: opus, sonnet, haiku und wann Sie welches Modell einsetzen

Weiter

Custom instructions, Styles und Artifacts