Die Einführung eines neuen Entwickler-Tools geschieht selten nur wegen einer Ankündigung. Sie geschieht, weil jemand im Team das Tool gut nutzt, offen darüber spricht und es anderen leicht macht, es zu übernehmen. Dieses Kit soll diese Bemühung unterstützen, ohne daraus einen Nebenjob zu machen. Es gibt Form zu Dingen, die Sie wahrscheinlich bereits tun, und bietet Material, das Sie direkt an Kollegen weitergeben können.
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, auf dem das ganze Team aufbauen kann. Sie fungieren als Multiplikator für Ihr Team, nicht als Help Desk, und dieser Leitfaden ist so strukturiert, dass die Rolle unter diesen Bedingungen nachhaltig bleibt.
So verwenden Sie diesen Leitfaden
Die Champion-Rolle besteht aus drei Verhaltensweisen, die sich gegenseitig verstärken: das Teilen von Erkenntnissen, die Person sein, die man fragt, und den Kreis der aktiven Nutzer vergrößern. Die folgenden Abschnitte behandeln jede einzelne, gefolgt von einem 30-Tage-Playbook, Hinweisen zur Beantwortung häufiger Bedenken und einem Schnellreferenzblatt, das Sie jedem in die Hand geben können.
Verwenden Sie, was zu Ihrem Team passt, und lassen Sie weg, was nicht passt. Nichts hier ist eine Checkliste, die Sie abarbeiten müssen; es ist eine Sammlung von Mustern, die sich in vielen Ingenieurorganisationen bewährt haben.
Phase 1: Die Champion-Rolle
Was ein Champion tut
Verhalten | Wie es in der Praxis aussieht | Warum es wichtig ist |
Teilen Sie, was Sie entdecken | Posten Sie die Prompts, Screenshots und kleinen Erfolge aus Ihrer eigenen Arbeit an den Stellen, wo 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 fragt | Wenn 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. |
Vergrößern Sie den Kreis | Etablieren Sie eine kleine Anzahl leichter, wiederkehrender Gewohnheiten – wie 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, wächst weiter von selbst. |
Das meiste davon passt natürlich in die Arbeit, die Sie bereits tun. Der Unterschied liegt in einer kleinen zusätzlichen Absicht darüber, wo Ihre Erkenntnisse gepostet werden und wie Ihre Antworten verbreitet werden.
Warum das wichtig ist
Tools verbreiten sich in einer Organisation, wenn jemand Vertrauenswürdiges demonstriert, dass sie den Aufwand wert sind. Dokumentation kann beschreiben, was möglich ist, aber das Beispiel eines Kollegen – aus derselben Codebasis, denselben Workflows und denselben Einschränkungen – ist das, was Menschen von der Neugier zu einem ersten Versuch bewegt. Indem Sie Ihre eigene Erfahrung sichtbar machen, beseitigen Sie den häufigsten Grund, warum Einführungen steckenbleiben: nicht zu wissen, wo man anfangen soll.
Was dies Sie kosten sollte
Es lohnt sich, Erwartungen mit sich selbst und mit Ihrem Lead zu setzen. Die folgenden Aktivitäten sollen in eine normale Arbeitswoche passen, und die Rolle sollte ein Multiplikator Ihrer bestehenden Arbeit bleiben, anstatt eine zusätzliche Support-Verantwortung zu sein.
Aktivität | Zeit pro Woche | Anleitung |
Erfolge und Prompts posten | Etwa 15 Minuten | Erfassen 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 beantworten | Etwa 20 Minuten | Beantworten Sie die Frage einmal öffentlich, dann verlinken Sie auf diese Antwort, wenn die Frage erneut auftaucht. |
Hosting eines wöchentlichen Show-and-Tell-Threads | Etwa 5 Minuten | Sie posten die Eröffnungsfrage; das Team liefert den Inhalt. |
Optionales Pairing oder Walkthroughs | 0–30 Minuten | Reservieren Sie dies für Kollegen, die wirklich blockiert sind, und bieten Sie den Quickstart-Link an, bevor Sie Zeit einplanen. |
Phase 2: Teilen Sie, was Sie entdecken
Ihre eigene Erfahrung ist das überzeugendste Material, auf das Ihre Kollegen stoßen werden, da es spezifisch für die Codebasis, Workflows und Probleme ist, die Sie alle teilen. Dokumentation zeigt 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 verbreiten sich, wenn sie sich durch ein Team ausbreiten; Statusupdates nicht.
Es wert, geteilt zu werden (eine Technik, die andere wiederverwenden können) | Weniger nützlich (ein Statusupdate) |
"Ich habe gelernt, dass @-Erwähnung eines Verzeichnisses funktioniert – wenn ich es auf | "Ich habe den Zahlungsservice mit Claude migriert." |
"Plan-Modus (Shift+Tab) zeigt genau, welche Dateien vor einer Bearbeitung berührt werden, weshalb ich mich wohlfühle, ihn auf gemeinsamen Code anzuwenden." | „Claude hat mir in diesem Sprint viel Zeit gespart. |
„Ich habe einen Stop-Hook konfiguriert, um eine Desktop-Benachrichtigung zu erhalten, wenn eine lange Aufgabe abgeschlossen ist; die Konfiguration befindet sich im Thread. | „Ich habe diese Woche acht Tickets geschlossen. |
„Das Ausführen von | „Claude ist wirklich gut; du solltest es versuchen. |
Wo man es teilt
Poste überall dort, wo dein Team bereits liest. Das Ziel ist es, Beispiele in den Arbeitsfluss zu integrieren, anstatt ein neues Ziel zu schaffen.
Ort | Am besten geeignet für | Empfohlenes Format |
Ein | Entdeckungen, Prompts und „Heute gelernt"-Momente" | Ein Screenshot mit ein oder zwei Sätzen Kontext |
Pull-Request-Beschreibungen | Demonstration des Ansatzes an echtem Code, den Reviewer bereits lesen | Ein einzelner Satz wie „Claude und ich haben diesen Refactor durchgeführt; ich stelle gerne den Ansatz vor. |
Standups oder wöchentliche schriftliche Updates | Normalisierung der Nutzung mit Leads und Skip-Level-Managern | Ein Satz, der ein konkretes Ergebnis beschreibt |
Team-Wiki oder interne Dokumentation | Dauerhafte Muster, benutzerdefinierte Skills und | Eine kurze Seite, verlinkt vom Kanal-Thema, damit sie auffindbar bleibt |
Das Format, das funktioniert
Ein Screenshot mit einer einzelnen Kontextzeile oder eine kurze Vorher-Nachher-Beschreibung ist in der Regel das richtige Detaillierungsniveau. Halte jeden Beitrag kurz genug, damit jemand, der vorbeiscrollt, den Punkt trotzdem versteht. Ein langer Artikel wird normalerweise für später gespeichert und vergessen, während ein kurzer Beitrag mit Screenshot eher kopiert und ausprobiert wird.
Beispielbeiträge
Die folgenden sind Illustrationen von Ton und Länge und nicht als wörtlich zu kopierende Vorlagen.
Heute gelernt, dass @-Erwähnung eines Verzeichnisses funktioniert. Ich habe es auf @src/components/ verwiesen und gefragt, welche Komponenten Tests fehlten, und es hat zwei aufgedeckt, die ich vergessen hatte.
Ich habe einen Stop-Hook konfiguriert, um eine Desktop-Benachrichtigung zu erhalten, wenn eine lange Aufgabe abgeschlossen ist. Ich habe einen Refactor gestartet, bin weggegangen und wurde benachrichtigt, als er fertig war. Die Konfiguration befindet sich im Thread.
Der Plan-Modus ist der Grund, warum ich mich wohlfühle, dies bei Code zu verwenden, der wichtig ist. Drücke Shift+Tab, bis du „plan
Phase 3: Sei die Person, die die Leute fragen
Sobald du ein paar Beispiele geteilt hast, werden Fragen folgen. Hier hat die Champion-Rolle die größte Hebelwirkung, denn eine gute Antwort für eine Person entsperrt häufig mehrere andere, die denselben Kanal beobachten.
Antworte mit einem Prompt statt einer Erklärung
Wenn ein Kollege fragt, wie du etwas erreicht hast, ist die nützlichste Antwort der Prompt, den du tatsächlich verwendet hast. Er wird mehr lernen, wenn er diesen Prompt auf sein eigenes Problem anwendet, als aus jeder Beschreibung, die du schreiben könntest, und es gibt ihm etwas, das er sofort umsetzen kann.
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
Verweise auf die Funktion statt auf die Dokumentation
Eine Antwort wie „Versuche den Plan-Modus – drücke Shift+Tab, bis du ihn siehst
Fragen, die du wahrscheinlich hören wirst
Die folgende Tabelle behandelt die Fragen, die Champions am häufigsten gestellt werden, zusammen mit einer vorgeschlagenen Antwort und der Ressource, die angeboten werden soll, wenn die Person bereit für mehr Tiefe ist.
Frage, die du wahrscheinlich hören wirst | Vorgeschlagene Antwort | Nachfolgende Ressource |
„Womit sollte ich es zuerst versuchen? | Empfehle eine echte, aber begrenzte Aufgabe – idealerweise einen Bug oder eine Aufgabe, die die Person aufgeschoben hat, weil sie mühsam statt schwierig ist. | |
„Wie kann ich ihm mit meinem Code vertrauen? | Stelle den Plan-Modus vor: Shift+Tab drücken wechselt ihn ein, Claude schlägt genau vor, was es ändern möchte, und nichts wird geändert, bis der Benutzer zustimmt. | |
„Lohnt sich der Aufwand für die Einrichtung? | Die Installation dauert etwa zwei Minuten, läuft im Terminal und erfordert keine IDE-Erweiterung. Das einmalige Ausführen von | |
„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. | |
„Es versteht unsere Codebase-Konventionen nicht. | Schlagen Sie vor, | |
„Ist das nur Autovervollständigung? | Bieten Sie eine kurze Demonstration an, in der Claude eine unbekannte Datei erklärt, einen Fehler über Services hinweg verfolgt oder einen Migrationsplan entwirft – Aufgaben, die Überlegungen über das Repository hinweg erfordern, anstatt eine einzelne Zeile zu vervollständigen. | Eine zweiminütige Live-Demonstration |
„Was ist mit Sicherheit und Datenbehandlung? | Leiten Sie diese Frage an Ihren Administrator weiter. Die Bereitstellungs- und Datenbehandlungsrichtlinie Ihrer Organisation ist bereits konfiguriert, und Champions sollten diese Antwort nicht improvisieren. |
Phase 4: Den Kreis erweitern
Das Ziel ist nicht, ein Programm zu erstellen oder einen Rollout zu besitzen. Es geht darum, eine kleine Anzahl leichter Gewohnheiten zu etablieren, die es dem Momentum ermöglichen, nach Ihrer aktiven Unterstützung fortzubestehen. Wenn Fragen im Kanal von anderen Personen als Ihnen beantwortet werden, hat die Rolle ihre Aufgabe erfüllt.
Muster, die tendenziell funktionieren
Muster | Wie man es ausführt | Erforderlicher Aufwand |
Ein dedizierter Kanal | Erstellen Sie einen | Ungefähr fünf Minuten zum Einrichten, dann ambient |
Ein wöchentlicher Show-and-Tell-Thread | Posten Sie jeden Freitag „Wobei hat Claude dir diese Woche geholfen? | Ungefähr zwei Minuten pro Woche |
Eine benutzerdefinierte Fähigkeit teilen | Posten Sie Ihre nützlichste | Ungefähr fünf Minuten pro Fähigkeit |
Bei einer ersten Aufgabe zusammenarbeiten | Bieten Sie eine einzelne fünfzehnminütige Pairing-Sitzung für jeden an, der anfängt. Ein erfolgreicher Ausgang bei ihrem eigenen Code ist überzeugender als jede Präsentation. | Ungefähr fünfzehn Minuten pro Person |
Den nächsten Champion identifizieren | Der Kollege, der Ihnen die meisten Fragen stellt, ist normalerweise bereit, diese Rolle zu übernehmen. Leiten Sie ihm dieses Kit weiter und teilen Sie die Kanalverantwortung zwischen Ihnen auf. | Vernachlässigbar |
Ein dreißigtägiger Spielplan
Wenn ein lockerer Plan hilfreich ist, spiegelt die folgende Abfolge wider, was bei den meisten Teams funktioniert. Passen Sie frei an Ihren Kontext an.
Woche | Empfohlene Aktivität | Signal, dass es funktioniert |
Woche 1 | Erstellen Sie den Kanal, heften Sie den Schnellstart an, und posten Sie zwei oder drei Ihrer eigenen Beispiele mit den enthaltenen Prompts. | Ein paar Kollegen reagieren oder antworten, und mindestens eine Frage wird im Kanal gestellt. |
Woche 2 | Starten Sie den wöchentlichen Show-and-Tell-Thread, beantworten Sie jede Frage öffentlich, und teilen Sie eine benutzerdefinierte Fähigkeit oder einen | Jemand anderes als Sie postet ein Beispiel von sich selbst. |
Woche 3 | Bieten Sie zwei oder drei kurze Pairing-Sitzungen an und konsolidieren Sie die häufigsten Fragen und Antworten in einer angehefteten FAQ-Nachricht. | Sie sehen wiederholte Nutzung – dieselben Kollegen kehren zurück, anstatt einmal zu versuchen und zu stoppen. |
Woche 4 | Identifizieren Sie einen zweiten Champion und teilen Sie eine kurze Zusammenfassung dessen, was funktioniert und was nicht, mit Ihrem Lead oder Administrator. | Fragen im Kanal werden von anderen Personen als dir beantwortet. |
Wenn jemand tiefer einsteigen möchte
Du bist die warme Einführung und nicht das Onboarding-Programm. Wenn ein Kollege von "sollte ich das versuchen" zu "wie werde ich damit effektiv" übergeht, verweise ihn auf die offiziellen Seiten Quickstart und Common workflows. Sie enthalten kurze Abschnitte zu Funktionen, die wirklich nützlich, aber schwer selbst zu entdecken sind.
Phase 5: Reaktion auf häufige Bedenken
Gesunde Skepsis ist zu erwarten; Ingenieure sollten vorsichtig mit neuen Tools sein. Die wirksamste Reaktion ist selten, den allgemeinen Fall zu argumentieren. Erkenne stattdessen das Bedenken an, biete eine kurze Umrahmung an und schlage eine konkrete Demonstration am eigenen Code der Person vor. Die meisten Bedenken werden durch eine einzige erfolgreiche Erfahrung gelöst.
Bedenken | Vorgeschlagene Antwort | Zu bietende Evidenz |
"Ich bin schneller ohne es." | Das ist wahrscheinlich wahr für Code, den die Person routinemäßig schreibt. Schlag vor, es bei der Arbeit zu versuchen, die sie vermeiden – Legacy-Dateien, unbekannte Services oder Test-Gerüste – wo der Hebel am höchsten ist. | Zeitlich eine mühsame Aufgabe auf beide Arten und vergleiche. |
"Ich vertraue KI nicht, um Production-Code zu bearbeiten." | Stimme zu, dass keine Änderung ungelesen landen sollte. Der Plan-Modus kombiniert mit normalem Diff-Review bedeutet, dass nichts angewendet wird, das der Ingenieur nicht überprüft hat – der gleiche Standard wie bei jedem Pull Request. | Demonstriere den Plan-Modus an einer echten Datei. |
"Es wird Junior-Ingenieure schwächer machen." | Richtig eingesetzt ist es ein effektiver Erklärer. Ermutige Junior-Ingenieure, Claude zu bitten, eine Datei und ihre Aufruforte zu erklären, bevor sie ihn bitten, etwas zu ändern. | Führe "Explain @file and where it is called from" zusammen aus. |
"Ich habe es einmal versucht und es hat halluziniert." | Dies ist normalerweise ein Kontextproblem und kein Modellproblem. Das @-Erwähnen der relevanten Dateien, das Ausführen von | Führe ihre ursprüngliche Anfrage mit ordnungsgemäßem @-Kontext erneut aus. |
"Wir haben keine Zeit, ein anderes Tool zu erlernen." | Claude Code ist ein Terminal-Befehl und keine 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. |
Anhang: Schnellreferenz-Blatt
Die folgenden Techniken sind diejenigen, die jemanden am zuverlässigsten von einem ersten Versuch zur täglichen Nutzung bewegen. Diese Tabelle soll in einem Kanal angeheftet oder eigenständig geteilt werden.
Technik | Wie man es anwendet |
Stelle den richtigen Kontext bereit | Verwende |
Überprüfe den Plan vor der Bearbeitung | Drücke Shift+Tab, um in den Plan-Modus zu wechseln. Claude wird die beabsichtigten Änderungen zur Genehmigung beschreiben, bevor sie ausgeführt werden. |
Lehre es dein Repository | Führe |
Verwende einen Workflow erneut | Speichere eine Markdown-Datei in |
Bleibe während langer Aufgaben informiert | Konfiguriere einen Stop-Hook, um eine Desktop-Benachrichtigung zu erhalten, wenn eine lange laufende Aufgabe abgeschlossen ist. |
Erholen Sie sich von einem falschen Ergebnis | Anstatt die Anfrage umzuformulieren, füge den fehlgeschlagenen Test oder Stack Trace an Claude zurück und bitte ihn, diesen spezifischen Fehler zu beheben. |
Halte Bearbeitungen chirurgisch | Frage nach einem Diff oder gib "only change X" an. Claude respektiert den Umfang, wenn der Umfang angegeben ist. |
Anhang: Ressourcenverzeichnis
Ressource | Link |
Quickstart | |
Common workflows | |
Skills | |
Anthropic Academy | |
Vollständige Claude Code-Dokumentation |
Vielen Dank, dass Sie diese Rolle übernommen haben. Menschen nutzen neue Tools, weil ihnen jemand, dem sie vertrauen, gezeigt hat, dass sich der Aufwand lohnt – und das ist der Beitrag, den Sie leisten. Claude Code wird häufig aktualisiert; bitte überprüfen Sie versionsspezifische Details unter code.claude.com/docs, bevor Sie dieses Material intern weitergeben.