+160 XP

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

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

Legen Sie ein 200-seitiges Unternehmenshandbuch und einen einseitigen Style Guide in ein Claude Project, und jeder Chat in diesem Project startet bereits gebrieft: Claude antwortet in Ihrer Hausstimme, zitiert Ihre Richtlinien und fragt nie wieder, ob Sie die gleichen Dokumente noch einmal einfügen. Das ist das ganze Versprechen von Projects, und es ist das am wenigsten genutzte Feature im Claude-Ökosystem.

Diese Lektion führt durch die Claude-Apps und geht dann tief auf Projects als Container für persistenten Kontext ein. Das Context Window kennen Sie bereits. Die Frage hier ist operativ: Wie hören Sie damit auf, denselben Hintergrund manuell in jede Konversation zu füttern?

Die drei Claude-Apps, kurz

Claude kommt als drei Clients, die ein Konto und einen Feature-Satz teilen:

  • Web (claude.ai) ist die kanonische Oberfläche. Alles landet hier zuerst.
  • Desktop (macOS und Windows) ergänzt lokale Connectors über MCP und kann auf Dateien und Apps auf Ihrem Rechner agieren. Hier hört Claude auf, eine Chatbox zu sein, und fängt an, Ihre Umgebung anzufassen.
  • Mobile (iOS und Android) ist für Erfassung und schnelle Abfragen: einen Gedanken diktieren, ein Whiteboard fotografieren, einen Project-Chat aus dem Zug weiterführen.

Es sind nicht drei Produkte. Ein Project, das Sie im Web erstellen, ist sofort auf Desktop und Mobile verfügbar. Die Unterschiede betreffen die *reach*: Desktop kann lokale Connectors und das Dateisystem nutzen, Mobile nicht.

Ein Begriff, den wir definieren und dann weitergehen: Ein Connector ist ein Stecker, der Claude erlaubt, aus einem externen System zu lesen oder darauf zu agieren (Google Drive, GitHub, eine Datenbank), und zwar über MCP, das Model Context Protocol. Wir behandeln Connectors hier nur oberflächlich und gehen in einer späteren Lektion tief hinein. Der Fokus heute liegt auf der persistenten Kontextschicht, die *über* jedem Connector sitzt.

Was ein Project wirklich ist

Ein Project ist ein Workspace, der drei Dinge bündelt und auf jeden Chat anwendet, der darin erstellt wird:

1. Project knowledge: Dateien und Text, die Sie einmal hochladen (PDFs, Dokumente, Tabellen, eingefügter Referenztext).

2. Custom instructions: ein dauerhaftes Briefing auf Systemebene, das Ton, Format und Verhalten prägt.

3. Die Chats selbst: jede Konversation, die Sie im Project starten, zusammengehalten.

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 hereinkommen. Sie bauen den Kontext nicht jedes Mal neu auf, sondern setzen auf einer gemeinsamen Baseline fort.

Das ist etwas anderes, als Ihr Handbuch in eine einzelne Konversation zu kopieren. Per Copy-and-paste eingefügter Kontext stirbt, wenn der Chat endet. Project knowledge bleibt über jeden Chat hinweg bestehen, unbefristet, für alle mit Zugriff auf das Project (in Team- und Enterprise-Plänen lassen sich Projects teilen).

Die offizielle Referenz steht in Anthropics Projects-Hilfedokumentation.

Der konkrete Aufbau: Handbuch plus Style Guide

Hier ist das Szenario aus dem Einstieg, sauber durchgezogen.

Sie haben zwei Assets:

  • company-handbook.pdf: 200 Seiten Richtlinien, Benefits, Eskalationswege, Sicherheitsregeln.
  • style-guide.md: eine Seite zur Stimme (warm, direkt, kein Jargon, britische Schreibweise, nie Rückerstattungen ohne Freigabe des Managers zusagen).

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

Schritt 2: Das Handbuch zu Project knowledge hinzufügen. Laden Sie company-handbook.pdf in das Knowledge-Panel. Claude indexiert es. Jetzt kann jeder Chat in diesem Project die Eskalationsrichtlinie auf Seite 147 referenzieren, ohne dass Sie etwas einfügen.

Schritt 3: Custom instructions schreiben. Hier machen es die meisten zu lasch. Werden Sie spezifisch:

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 will nach 40 Tagen eine Rückerstattung. Was sage ich ihm?“

Claude antwortet in britischer Schreibweise, in der warm-aber-direkten Stimme, sagt die Rückerstattung nicht zu, verweist auf Abschnitt 6.2 und nennt die Quelle. Sie haben nichts eingefügt. Der nächste Chat, und der Chat, den Ihre Kollegin morgen startet, verhalten sich identisch.

Diese Wiederholbarkeit ist der Punkt. Ein Project verwandelt „Claude, der das heute zufällig weiß“ in „Claude, der sich jedes Mal zuverlässig so verhält“.

Project knowledge vs. Context Window

Eine berechtigte Frage: Wenn Sie 200 Seiten hineinlegen, frisst das dann bei jeder Nachricht Ihr Context Window?

Nicht so, wie Einfügen es täte. Wenn Project knowledge groß ist, holt Claude die relevanten Chunks heraus, statt das gesamte Dokument in jeden Prompt zu stopfen (dieselbe Retrieval-Idee, die Sie früher im Kurs auf Konzeptebene kennengelernt haben). Wenn es klein ist, kann es vollständig im Kontext liegen. In beiden Fällen verwalten Sie es nicht manuell.

Praktische Konsequenz: Halten Sie Project knowledge *kuratiert*. Ein knappes Handbuch plus ein sauberer Style Guide schlägt das Abladen von vierzig lose verwandten PDFs. Die Retrieval-Qualität sinkt, wenn die Wissensbasis rauscht. Behandeln Sie das Knowledge-Panel wie ein Referenzregal, nicht wie einen Dachboden.

Styles: Stimme, ohne jedes Mal die Instructions neu zu schreiben

Es gibt eine Überlappung, die eine Klärung verdient. Styles erlauben es, eine wiederverwendbare Schreibstimme zu speichern (formell, knapp, Ihr Markenton) und sie mit einem Klick auf jeden Chat anzuwenden, *quer* über Projects. Sie können einen Style sogar aus Beispieltexten lernen lassen.

Wann nutzt man also was?

  • Verhalten und Regeln, die spezifisch für einen Wissensbestand sind, gehören in die custom instructions des Projects (die Rückerstattungsregel oben).
  • Wiederverwendbare Stimme, die Sie überall wollen, gehört in einen Style.

Im Handbuch-Beispiel ist „britische Schreibweise, warm, direkt“ wohl ein Style, den Sie über viele Projects hinweg wiederverwenden, während „bei Rückerstattungen Abschnitt 6.2 zitieren“ in die Instructions dieses Projects gehört. Die Trennung hält jedes Project schlank und Ihre Stimme unternehmensweit konsistent.

Wo Artifacts und Skills hineinpassen

Zwei weitere Teile vervollständigen das Bild innerhalb der Apps.

Artifacts sind die eigenständigen Outputs, die Claude in einem Seitenpanel erzeugt: ein Dokument, eine funktionierende Web-App, ein Chart, ein interaktives Tool. In Ihrem Support-Desk-Project könnten Sie Claude bitten, ein Artifact zu bauen: eine kleine Triage-Checklisten-App, die die Eskalationslogik des Handbuchs kodiert. Sie rendert live, Sie können sie im selben Chat weiterentwickeln, und sie erbt die Grundlage des Projects.

Skills sind verpackte, wiederverwendbare Fähigkeiten: Ordner mit Instructions plus optionalen Skripten und Ressourcen, die Claude lädt, wenn eine Aufgabe sie braucht. Wo ein Style die Stimme prägt und Project knowledge die Fakten liefert, bringt ein Skill Claude eine *Prozedur* bei: wie man einen Quartalsbericht genau auf Ihre Weise formatiert oder einen bestimmten Dokumentenverarbeitungs-Flow ausführt. Skills funktionieren über die Apps, die API und Claude Code. Die Struktur steht in der Agent-Skills-Dokumentation.

Die Schichtung ist das mentale Modell, das man behalten sollte:

  • Project knowledge = was Claude weiß.
  • Custom instructions = wie Claude sich *hier* verhält.
  • Styles = wie Claude *überall* klingt.
  • Skills = Prozeduren, 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, dass ein normaler Chat ein „leerer Raum“ ist. Was entspricht in dieser Metapher einem Project?

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

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Dinge 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 reicht für ein Handbuch, das sich quartalsweise ändert. Aber manche Projects brauchen *aktuelle* Daten, und dafür gibt es Connectors.

Auf Claude Desktop können Sie Connectors (über MCP) hinzufügen, damit ein Chat aus Google Drive lesen, ein System abfragen oder in Echtzeit aus einem Repository ziehen kann. In den Apps gibt es ein wachsendes Connector-Directory, plus die Möglichkeit, eigene zu bauen.

Die GitHub-Integration ist das Highlight für technische Teams. Verbinden Sie ein Repository, und Claude kann Ihre Codebase als Live-Kontext lesen, nicht als veralteten Snapshot. In einem Project, das auf ein Repo zugeschnitten ist, können Sie fragen „wo validieren wir das Rückerstattungsfenster?“, und Claude denkt über den tatsächlichen Code nach. Das ist die Brücke zu Claude Code, dem terminalbasierten Agenten, der direkt auf Ihrem Repo arbeitet und später in diesem Pfad eine eigene tiefe Lektion bekommt.

Die Unterscheidung, die man festhalten sollte: 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 unter Ihnen verändern (offene Tickets, der aktuelle Branch, die Tabelle dieser Woche).

Wann man stattdessen zur API greift

Alles oben ist die App-Erfahrung: Mensch in der Schleife, klickt sich durch Chats. Wenn Sie das *programmatisch* wollen, gehen Sie runter zur Anthropic Messages API, wo persistenter Kontext im Project-Stil 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",
    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-Äquivalent zu den custom instructions eines Projects, und das Anhängen von Dokumenten pro Request spiegelt Project knowledge. Die App macht das per Klick und persistent, die API macht es skriptbar und einbettbar. Für agentische Workflows umhüllt das Claude Agent SDK dasselbe Modell mit Tools und Loops. Beginnen Sie bei der API-Dokumentation.

Daumenregel: Nutzen Sie Projects, wenn Menschen die Arbeit in einem gemeinsamen, sich entwickelnden Raum machen. Nutzen Sie die API / das Agent SDK, wenn Software die Arbeit im Maßstab macht.

Ein paar nicht offensichtliche Gewohnheiten

  • Ein Project pro Job, nicht pro Thema. „Support Desk Assistant“ und „Q3 Marketing Copy“ sollten getrennte Projects mit getrennten Instructions sein. Gemischte Projects erzeugen trübes 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.
  • Schreiben Sie Instructions als Regeln, nicht als Stimmungen. „Nie eine Rückerstattung zusagen; Abschnitt 6.2 zitieren“ ist durchsetzbar. „Sei hilfreich bei Rückerstattungen“ nicht.
  • Verankern Sie die Quellenangabe-Regel. Claude zu bitten, Antworten mit dem verwendeten Abschnitt zu beenden, macht aus einem selbstbewussten Assistenten einen prüfbaren.

Wichtigste Erkenntnisse

  • Ein Project bündelt persistentes Knowledge, custom instructions und Chats, sodass Claude jede Konversation bereits gebrieft beginnt. Hören Sie auf, Kontext neu einzufügen.
  • Schichten Sie Ihre Werkzeuge nach Aufgabe: Knowledge (Fakten), custom instructions (Verhalten hier), Styles (Stimme überall), Skills (Prozeduren), Connectors/MCP (Live-Zugriff).
  • Nutzen Sie Project knowledge für stabile Referenzen und Connectors (wie die GitHub-Integration) für Daten, die sich unter Ihnen verändern.
  • Schreiben Sie custom instructions als durchsetzbare Regeln mit einer Pflicht zur Quellenangabe, und halten Sie das Knowledge-Panel kuratiert, nicht überfüllt.
  • Wenn die Arbeit von klickenden Menschen zu Software im Maßstab wandert, lebt dasselbe Muster in der Messages API (system-Prompt plus angehängte Dokumente) und im Agent SDK.

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