Zum Hauptinhalt springen
Diese Seite ist für einzelne Ingenieure, die Claude Code bereits nutzen und ihr Team bei der Einführung unterstützen möchten. Sie behandelt, was man teilen sollte, wie man die Fragen beantwortet, die man erhält, einen 30-Tage-Leitfaden und Antworten auf häufige Bedenken. Die Einführung eines Entwickler-Tools geschieht selten aufgrund einer Rollout-Ankündigung. Sie geschieht, weil jemand im Team das Tool gut nutzt, offen darüber spricht und es anderen leicht macht, es zu übernehmen. Die Arbeit, die Sie als Champion leisten, hat eine überproportionale Wirkung: Jedes Beispiel, das Sie teilen, verkürzt die Lernkurve für die Ingenieure, die nach Ihnen kommen, und jede Frage, die Sie öffentlich beantworten, verwandelt die Erfahrung einer Person in etwas, das das ganze Team nutzen kann. Sie fungieren als Multiplikator für Ihr Team, nicht als Helpdesk, und dieser Leitfaden ist so strukturiert, dass die Rolle unter diesen Bedingungen nachhaltig bleibt.

​
Die Champion-Rolle

Die Rolle besteht aus drei Verhaltensweisen, die sich gegenseitig verstärken.
VerhaltenWie es in der Praxis aussiehtWarum es wichtig ist
Teilen Sie, was Sie entdeckenPosten Sie die Prompts, Screenshots und kleinen Erfolge aus Ihrer eigenen Arbeit an den Orten, die Ihr Team bereits liest, z. B. in einem Engineering-Kanal, einem Standup-Thread oder einer Pull-Request-Beschreibung.Beispiele aus Ihrer eigenen Codebasis sind überzeugender als jede externe Dokumentation, da Kollegen genau sehen können, wie das Tool auf die Probleme angewendet wird, die Sie teilen.
Seien Sie die Person, die man fragtWenn ein Kollege fragt, wie Sie etwas erreicht haben, antworten Sie mit dem tatsächlichen Prompt, den Sie verwendet haben, damit er ihn direkt auf seine eigene Aufgabe anwenden kann.Ein konkretes, ausführbares Beispiel schließt die Lücke zwischen Neugier und einer ersten erfolgreichen Nutzung, wo die meisten Einführungsbemühungen steckenbleiben.
Erweitern Sie den KreisEtablieren Sie eine kleine Anzahl leichter, wiederkehrender Gewohnheiten, z. B. einen dedizierten Kanal oder einen wöchentlichen Thread, damit der Schwung auch dann anhält, wenn Ihre Aufmerksamkeit woanders liegt.Eine Einführung, die von einer einzelnen Person abhängt, ist fragil. Eine Einführung, die durch gemeinsame Gewohnheiten getragen wird, setzt sich von selbst fort.
Das meiste davon passt natürlich in die Arbeit, die Sie bereits leisten. Der Unterschied liegt in einer kleinen zusätzlichen Absicht darüber, wo Ihre Entdeckungen gepostet werden und wie Ihre Antworten verbreitet werden.

​
Was dies Sie kosten sollte

Setzen Sie Erwartungen mit sich selbst und mit Ihrem Vorgesetzten. Die folgenden Aktivitäten sollen in eine normale Arbeitswoche passen, und die Rolle sollte ein Multiplikator für Ihre bestehende Arbeit bleiben, anstatt eine zusätzliche Support-Verantwortung zu sein.
AktivitätZeit pro WocheAnleitung
Erfolge und Prompts postenEtwa 15 MinutenErfassen Sie diese im Moment mit einem Screenshot und ein oder zwei Sätzen; vermeiden Sie es, sie in formale Schriftstücke umzuwandeln.
Fragen in einem gemeinsamen Kanal beantwortenEtwa 20 MinutenBeantworten Sie die Frage einmal öffentlich, dann verlinken Sie auf diese Antwort, wenn die Frage erneut auftritt.
Wöchentlichen Show-and-Tell-Thread hostenEtwa 5 MinutenSie posten den Eröffnungs-Prompt; das Team liefert den Inhalt.
Optionales Pairing oder Walkthroughs0 bis 30 MinutenReservieren Sie dies für Kollegen, die wirklich blockiert sind, und bieten Sie den Quickstart-Link an, bevor Sie Zeit einplanen.

​
Teilen Sie, was Sie entdecken

Ihre eigene Erfahrung ist das überzeugendste Material, das Ihre Kollegen antreffen werden, da es spezifisch für die Codebasis, Workflows und Probleme ist, die Sie alle teilen. Dokumentation sagt den Menschen, was möglich ist; Ihre Posts zeigen ihnen, was in Ihrer Umgebung tatsächlich funktioniert.

​
Was es wert ist, geteilt zu werden

Die nützlichsten Posts beschreiben eine Technik, die ein Kollege morgen wiederverwenden kann, anstatt eines Ergebnisses, das bereits abgeschlossen ist. Techniken verstärken sich, wenn sie sich durch ein Team verbreiten; Statusaktualisierungen nicht. Beispiele für wiederverwendbare Techniken:
  • „Ich habe gelernt, dass das @-Erwähnen eines Verzeichnisses funktioniert. Wenn ich es auf @src/components/ zeige und frage, welche Tests fehlen, werden zwei angezeigt, die ich übersehen hatte.”
  • „Plan Mode (Shift+Tab) zeigt genau, welche Dateien berührt werden, bevor eine Bearbeitung vorgenommen wird, weshalb ich mich wohlfühle, ihn auf gemeinsamen Code anzuwenden.”
  • „Ich habe einen Stop-Hook konfiguriert, damit ich eine Desktop-Benachrichtigung erhalte, wenn eine lange Aufgabe abgeschlossen ist. Die Konfiguration ist im Thread.”
  • „Das Ausführen von /init generiert eine CLAUDE.md aus dem Repository, damit der Assistent nicht mehr nach unseren Konventionen fragt.”

​
Wo man es teilt

Posten Sie überall dort, wo Ihr Team bereits liest. Das Ziel ist es, Beispiele in den Weg der normalen Arbeit zu platzieren, anstatt ein Ziel zu schaffen.
OrtAm besten geeignet fürEmpfohlenes Format
Ein #claude-code- oder allgemeiner Engineering-KanalEntdeckungen, Prompts und „heute habe ich gelernt”-MomenteEin Screenshot mit ein oder zwei Sätzen Kontext
Pull-Request-BeschreibungenDemonstration des Ansatzes auf echtem Code, den Reviewer bereits lesenEin einzelner Satz wie „Claude und ich haben dieses Refactoring durchgeführt; ich stelle gerne den Ansatz vor.”
Standups oder wöchentliche schriftliche UpdatesNormalisierung der Nutzung mit Vorgesetzten und Skip-Level-ManagernEin Satz, der ein konkretes Ergebnis beschreibt
Team-Wiki oder interne DokumentationDauerhafte Muster, benutzerdefinierte Skills und CLAUDE.md-BeispieleEine kurze Seite, verlinkt vom Kanal-Thema, damit sie auffindbar bleibt

​
Das Format, das funktioniert

Ein Screenshot mit einem einzelnen Satz Kontext oder eine kurze Vorher-Nachher-Beschreibung ist im Allgemeinen das richtige Detaillierungsniveau. Halten Sie jeden Post kurz genug, dass jemand, der vorbeiscrollt, den Punkt trotzdem versteht. Ein langer Schriftsatz wird tendenziell für später gespeichert und vergessen, während ein kurzer Post mit einem Screenshot tendenziell kopiert und ausprobiert wird. Die folgenden Beispiel-Posts veranschaulichen Ton und Länge; passen Sie sie an, anstatt sie wörtlich zu kopieren. 
Heute gelernt, dass das @-Erwähnen eines Verzeichnisses funktioniert. Ich habe es auf
@src/components/ gezeigt und gefragt, welche Komponenten Tests fehlen, und es
wurden zwei angezeigt, die ich vergessen hatte.

Ich habe einen Stop-Hook konfiguriert, damit ich eine Desktop-Benachrichtigung erhalte, wenn eine lange
Aufgabe abgeschlossen ist. Ich habe ein Refactoring gestartet, bin weggegangen und wurde benachrichtigt, als
es fertig war. Die Konfiguration ist im Thread.

Plan Mode ist der Grund, warum ich mich wohlfühle, dies auf Code zu verwenden, der wichtig ist.
Drücken Sie Shift+Tab, bis Sie „plan" sehen; es zeigt genau, welche Dateien es
berühren möchte, bevor etwas geändert wird.

​
Seien Sie die Person, die man fragt

Sobald Sie ein paar Beispiele geteilt haben, werden Fragen folgen. Dies ist der Punkt, an dem die Champion-Rolle die größte Hebelwirkung hat, da eine gute Antwort auf eine Person häufig mehrere andere freischaltet, die denselben Kanal beobachten.

​
Antworten Sie mit einem Prompt statt mit einer Erklärung

Wenn ein Kollege fragt, wie Sie etwas erreicht haben, ist die nützlichste Antwort der Prompt, den Sie tatsächlich verwendet haben. Sie werden mehr lernen, wenn sie diesen Prompt gegen ihr eigenes Problem ausführen, als aus jeder Beschreibung, die Sie schreiben könnten, und es gibt ihnen etwas, das sie sofort umsetzen können. 
Kollege: Wie hast du es geschafft, diese Race Condition zu finden?

Champion: Ich habe gefragt: „Der Test in @tests/scheduler.test.ts ist instabil, finde heraus, warum", und es hat zwei nicht verbundene Promises im Scheduler verfolgt. Versuchen Sie die gleiche Formulierung bei Ihrem Test.

​
Zeigen Sie auf die Funktion statt auf die Dokumentation

Eine Antwort wie „Versuchen Sie Plan Mode, drücken Sie Shift+Tab, bis Sie ihn sehen” ist im Moment nützlicher als ein Link zur Dokumentation. Wenn die Person später mehr Tiefe braucht, wird sie sie selbst finden; jetzt brauchen sie das eine, das sie freischaltet.

​
Fragen, die Sie wahrscheinlich hören werden

FrageVorgeschlagene AntwortNachschlageressource
„Womit sollte ich es zuerst versuchen?”Empfehlen Sie eine echte, aber begrenzte Aufgabe, idealerweise einen Bug oder eine Aufgabe, die die Person aufgeschoben hat, weil sie mühsam ist, nicht schwierig.Häufige Workflows
„Wie kann ich meinem Code vertrauen?”Stellen Sie Plan Mode vor: Drücken Sie Shift+Tab, um ihn zu aktivieren, Claude schlägt genau vor, was es ändern möchte, und nichts wird geändert, bis der Benutzer zustimmt.Berechtigungen
„Lohnt sich der Einrichtungsaufwand?”Die Installation dauert etwa zwei Minuten, läuft im Terminal und erfordert keine IDE-Erweiterung. Das einmalige Ausführen von /init reicht aus, um zu beginnen.Quickstart
„Es hat ein falsches Ergebnis produziert.”Ermutigen Sie sie, den Fehler an Claude zurückzugeben. Das Einfügen der Fehlermeldung oder des fehlgeschlagenen Tests ist viel effektiver als die Umformulierung der ursprünglichen Anfrage.Häufige Workflows
„Es versteht unsere Codebase-Konventionen nicht.”Schlagen Sie vor, /init auszuführen, um eine CLAUDE.md-Datei zu generieren, und fügen Sie dann die Konventionen des Teams, Testbefehle und alle Verzeichnisse hinzu, die vermieden werden sollten.Memory
„Ist das nur Autovervollständigung?”Bieten Sie eine kurze Demonstration an, in der Claude eine unbekannte Datei erklärt, einen Bug über Services hinweg verfolgt oder einen Migrationsplan entwirft. Diese Aufgaben erfordern Überlegungen über das Repository hinweg, nicht das Vervollständigen einer einzelnen Zeile.Eine zweiminütige Live-Demonstration
„Was ist mit Sicherheit und Datenbehandlung?”Verweisen Sie diese Frage an Ihren Administrator. Die Bereitstellungs- und Datenbehandlungsrichtlinie Ihrer Organisation ist bereits konfiguriert, und Champions sollten diese Antwort nicht improvisieren.Sicherheit · Datennutzung

​
Erweitern Sie den Kreis

Das Ziel ist nicht, ein Programm zu erstellen oder einen Rollout zu besitzen. Es ist, eine kleine Anzahl leichter Gewohnheiten zu etablieren, die es dem Schwung ermöglichen, nach Ihnen fortzufahren. Wenn Fragen im Kanal von anderen Personen als Ihnen beantwortet werden, hat die Rolle ihre Aufgabe erfüllt.

​
Muster, die tendenziell funktionieren

MusterWie man es ausführtErforderlicher Aufwand
Ein dedizierter KanalErstellen Sie einen #claude-code-Kanal (oder einen wiederkehrenden Thread in einem bestehenden), heften Sie den Quickstart-Link und ein starkes Beispiel an, und beantworten Sie Fragen öffentlich, damit jede Antwort jedem, der zuschaut, zugute kommt.Etwa fünf Minuten zum Einrichten, dann ambient
Ein wöchentlicher Show-and-Tell-ThreadJeden Freitag posten Sie „Womit hat Claude dir diese Woche geholfen?” Keine Vorbereitung, Folien oder Meetings erforderlich; Screenshots und kurze Beschreibungen reichen aus.Etwa zwei Minuten pro Woche
Teilen Sie einen benutzerdefinierten SkillPosten Sie Ihre nützlichste .claude/skills/<name>/SKILL.md-Datei, z. B. einen /ship-Skill, der Tests und Lint vor dem Commit ausführt, mit einer einzeiligen Beschreibung. Da Skills einfaches Markdown sind, können Kollegen sie sofort übernehmen.Etwa fünf Minuten pro Skill
Generieren Sie einen Setup-Leitfaden aus Ihrer eigenen NutzungFühren Sie /team-onboarding in einem Projekt aus, in dem Sie echte Zeit verbracht haben. Claude scannt Ihre letzten Sessions, Befehle und MCP-Server und erstellt dann einen Leitfaden, den ein neuer Teamkollege als erste Nachricht einfügen kann, um Ihr Setup zu wiederholen. Heften Sie ihn im Kanal an.Etwa zwei Minuten
Pairing bei einer ersten AufgabeBieten Sie eine einzelne fünfzehnminütige Pairing-Sitzung für jeden an, der anfängt. Ein erfolgreicher Ergebnis auf ihrem eigenen Code ist überzeugender als jede Präsentation.Etwa fünfzehn Minuten pro Person
Identifizieren Sie den nächsten ChampionDer Kollege, der Ihnen die meisten Fragen stellt, ist normalerweise bereit, diese Rolle zu übernehmen. Leiten Sie diese Seite an ihn weiter und teilen Sie die Kanal-Verantwortung zwischen Ihnen auf.Vernachlässigbar

​
30-Tage-Leitfaden

Wenn ein lockerer Plan hilfreich ist, spiegelt die folgende Abfolge wider, was über die meisten Teams hinweg tendenziell funktioniert. Passen Sie frei an Ihren Kontext an.
1

Woche 1: Säen Sie den Kanal

Erstellen Sie den Kanal, heften Sie den Quickstart an, und posten Sie zwei oder drei Ihrer eigenen Beispiele mit den Prompts.Signal, dass es funktioniert: Ein paar Kollegen reagieren oder antworten, und mindestens eine Frage wird im Kanal gestellt.
2

Woche 2: Starten Sie den Rhythmus

Starten Sie den wöchentlichen Show-and-Tell-Thread, beantworten Sie jede Frage öffentlich, und teilen Sie einen benutzerdefinierten Skill oder CLAUDE.md-Snippet.Signal, dass es funktioniert: Jemand anderes als Sie postet ein Beispiel aus seiner eigenen Erfahrung.
3

Woche 3: Pairing und Konsolidierung

Bieten Sie zwei oder drei kurze Pairing-Sitzungen an und konsolidieren Sie die häufigsten Fragen und Antworten in einer angehefteten FAQ-Nachricht.Signal, dass es funktioniert: Sie sehen wiederholte Nutzung, wobei die gleichen Kollegen zurückkehren, anstatt einmal zu versuchen und zu stoppen.
4

Woche 4: Übergabe

Identifizieren Sie einen zweiten Champion und teilen Sie eine kurze Zusammenfassung dessen, was funktioniert und was nicht, mit Ihrem Vorgesetzten oder Administrator.Signal, dass es funktioniert: Fragen im Kanal werden von anderen Personen als Ihnen beantwortet.

​
Wenn jemand tiefer gehen möchte

Sie sind die warme Einführung, nicht das Onboarding-Programm. Wenn ein Kollege von „sollte ich das versuchen” zu „wie werde ich damit effektiv” übergeht, verweisen Sie ihn auf die Seiten Quickstart und Häufige Workflows. Sie enthalten kurze Abschnitte, die die Funktionen abdecken, die wirklich nützlich sind, aber schwer zu entdecken sind.

​
Reagieren Sie auf häufige Bedenken

Gesunde Skepsis ist zu erwarten; Ingenieure sollten vorsichtig mit Tools sein, die ihren Code berühren. Die effektivste Antwort ist selten, den allgemeinen Fall zu argumentieren. Stattdessen erkennen Sie das Bedenken an, bieten eine kurze Umformulierung an und schlagen eine konkrete Demonstration auf dem eigenen Code der Person vor. Die meisten Bedenken werden durch eine einzige erfolgreiche Erfahrung gelöst.
BedenkenVorgeschlagene AntwortZu bietender Beweis
„Ich bin schneller ohne es.”Das ist wahrscheinlich wahr für Code, den die Person routinemäßig schreibt. Schlagen Sie vor, es auf die Arbeit zu versuchen, die sie tendenziell vermeiden: Legacy-Dateien, unbekannte Services oder Test-Gerüste, wo die Hebelwirkung am höchsten ist.Zeitlich eine mühsame Aufgabe auf beide Arten und vergleichen Sie.
„Ich vertraue KI nicht, Production-Code zu berühren.”Stimmen Sie zu, dass keine Änderung ungelesen landen sollte. Plan Mode kombiniert mit normalem Diff-Review bedeutet, dass nichts angewendet wird, das der Ingenieur nicht überprüft hat, der gleiche Standard wie jeder Pull Request.Demonstrieren Sie Plan Mode auf einer echten Datei.
„Es wird Junior-Ingenieure schwächer machen.”Wenn es gut verwendet wird, ist es ein effektiver Erklärer. Ermutigen Sie Junior-Ingenieure, Claude zu bitten, eine Datei und ihre Aufruforte zu erklären, bevor sie ihn bitten, etwas zu ändern.Führen Sie „Erklären Sie @file und wo es aufgerufen wird” zusammen aus.
„Ich habe es einmal versucht und es hat halluziniert.”Dies ist normalerweise ein Kontextproblem, kein Modellproblem. Das @-Erwähnen der relevanten Dateien, das Ausführen von /init und das Bereitstellen der tatsächlichen Fehlerausgabe lösen es normalerweise.Führen Sie ihren ursprünglichen Prompt mit ordnungsgemäßem @-Kontext erneut aus.
„Wir haben keine Zeit, ein anderes Tool zu lernen.”Claude Code ist ein Terminal-Befehl, kein Plattform. Wenn es in der ersten Sitzung keinen Wert zurückgibt, ist es angemessen, es beiseite zu legen.Eine zweiminütige Installation gefolgt von einem echten Bug.

​
Schnellreferenz-Blatt

Die folgenden Techniken sind diejenigen, die am zuverlässigsten jemanden von einem ersten Versuch zur täglichen Nutzung bewegen. Heften Sie diese Tabelle in einem Kanal an oder teilen Sie sie allein.
TechnikWie man sie anwendet
Geben Sie den richtigen Kontext anVerwenden Sie @file- oder @directory/-Referenzen, oder fügen Sie die Fehler- oder Log-Ausgabe direkt ein. Die Bereitstellung relevanten Kontexts ist effektiver als aufwendiges Prompting.
Überprüfen Sie den Plan vor der BearbeitungDrücken Sie Shift+Tab, um in den Plan Mode zu gelangen. Claude wird die beabsichtigten Änderungen zur Genehmigung beschreiben, bevor sie ausgeführt werden.
Lehren Sie es Ihr RepositoryFühren Sie /init aus, um eine CLAUDE.md-Datei zu generieren, und fügen Sie dann Ihre Konventionen, Testbefehle und alle Verzeichnisse hinzu, die nicht geändert werden sollten. Siehe Memory.
Verwenden Sie einen Workflow erneutSpeichern Sie eine SKILL.md-Datei in .claude/skills/<name>/, um einen /name-Skill zu erstellen, den das gesamte Team verwenden kann. Siehe Skills.
Bleiben Sie während langer Aufgaben informiertKonfigurieren Sie einen Stop-Hook, um eine Desktop-Benachrichtigung zu erhalten, wenn eine lange Aufgabe abgeschlossen ist. Siehe Hooks.
Erholen Sie sich von einem falschen ErgebnisAnstatt die Anfrage umzuformulieren, fügen Sie den fehlgeschlagenen Test oder Stack Trace an Claude zurück und bitten Sie ihn, diesen spezifischen Fehler zu beheben.
Halten Sie Bearbeitungen chirurgischFragen Sie nach einem Diff, oder geben Sie an „ändere nur X”. Claude respektiert den Umfang, wenn der Umfang angegeben ist.
Claude Code wird häufig aktualisiert. Überprüfen Sie versionsspezifische Details gegen die Dokumentationsstartseite, bevor Sie dieses Material intern verteilen.