Claude Code für LinkedIn: technische Fallstudien

Claude Code für LinkedIn

Ingenieurinnen und Ingenieure lernen von den Fallstudien anderer Teams; auf LinkedIn lesen sie auch Führungskräfte und Kolleginnen. Die schwierige Aufgabe ist nicht das Schreiben, sondern zu entscheiden, was veröffentlicht werden darf, und jede Behauptung zu belegen. Claude Code hat Zugriff auf konkrete Belege: den Pull Request mit der Änderung, das Benchmark-Skript und die damals verfassten Notizen. Diese Anleitung behandelt ein Beispiel aus der Zahlungsinfrastruktur und zeigt, wie eine technische Fallstudie sachlich bleibt und vor der Veröffentlichung durch Autor und Rechtsabteilung geprüft wird.

Beispiel: Ein Fintech-Team beschleunigt die Abstimmung

Ein Zahlungsteam verkürzt seinen nächtlichen Abstimmungslauf von vier Stunden auf vierzig Minuten. Die technische Leitung öffnet Claude Code im Repository und verweist auf das Designdokument, den Pull Request und die Benchmark-Ausgabe. Zusätzlich gelten klare Offenlegungsregeln: keine Kundennamen, Volumina oder Hostnamen. Claude entwirft eine Fallstudie mit etwa 250 Wörtern: Ausgangsproblem, zwei erwogene Optionen, Entscheidung und eine Erkenntnis zum Bündeln von Vorgängen. Die Aussage „vier Stunden auf vierzig Minuten“ kennzeichnet es als durch die Benchmark-Datei belegt. Eine Behauptung über „99,9 Prozent weniger Fehler“ markiert es als unbelegt. Die Leitung entfernt sie; Claude speichert den Entwurf mit create_drafts für die Unternehmensseite. Die Rechtsprüfung liest den Text in Tareno, bevor die Leitung einen Termin für Mittwoch anfragt.

Schritt für Schritt

1. 01

   Offenlegungsregeln festlegen

   Formuliere vor dem ersten Entwurf klare Regeln: keine Kundennamen, Volumina, internen Hostnamen oder noch unveröffentlichten Produkte. Claude Code kann diese Regeln beim Entwurf anwenden. Bitte es zusätzlich aufzulisten, welche Angaben es deshalb ausgelassen hat.

2. 02

   Auf konkrete Belege verweisen

   Nenne das Designdokument, den Pull Request und die Benchmark-Ausgabe. Eine Fallstudie sollte sich auf vorhandene Dateien stützen, damit sich jede veröffentlichte Aussage bis zu einer konkreten Stelle zurückverfolgen lässt.

3. 03

   Problem, Optionen, Entscheidung und Erkenntnis entwerfen

   Bitte um genau diese Struktur mit ungefähr 250 Wörtern. Die verworfenen Alternativen machen eine Fallstudie für andere technische Teams oft besonders nützlich; lass sie daher nicht aus dem Entwurf verschwinden.

4. 04

   Belegprüfung für jede Aussage durchführen

   Lass Claude Code für jede Zahl und jede Ursache-Wirkungs-Behauptung in der Fallstudie die stützende Datei und Zeile nennen. Alles ohne Beleg soll es als ungeprüft markieren. Entferne unbelegte Aussagen oder formuliere sie vorsichtiger.

5. 05

   Zur Prüfung speichern

   Claude Code kann mit list_accounts das LinkedIn-Konto bestätigen und den Text über create_drafts als Entwurf speichern. Lass die prüfende Person den genauen Wortlaut in Tareno lesen, bevor irgendein Veröffentlichungszeitpunkt angefragt wird.

6. 06

   Termin nach der Prüfung anfragen

   Erst nach der fachlichen und rechtlichen Prüfung nennst du Datum, Uhrzeit und IANA-Zeitzone. Die Anfrage wird zu einer ausstehenden Aktion und wartet im Dashboard auf die Bestätigung der zuständigen Person.

Prompts zum Kopieren

Lies docs/design/reconciliation.md, den Pull Request [Nummer] und die Ausgabe von scripts/bench.sh. Liste die Kennzahlen auf, die diese Dateien stützen, sowie Aussagen, die nicht belegt sind. Wende dabei diese Offenlegungsregel an: keine Kundennamen, Volumina oder Hostnamen. Speichere noch nichts in Tareno.

Schreibe eine LinkedIn-Fallstudie mit ungefähr 250 Wörtern und vier Teilen: Problem, die zwei erwogenen Optionen, Entscheidung und eine Erkenntnis. Nutze ausschließlich belegte Kennzahlen, schreibe für [Engineering-Leitungen] und vermeide Marketingformulierungen. Erstelle zunächst nur den Text zur Prüfung.

Liste jede Zahl und jede Ursache-Wirkungs-Behauptung im Entwurf auf, jeweils mit der Datei und Zeile, die sie stützt. Markiere Aussagen ohne Quelle als ungeprüft und schlage jeweils eine vorsichtigere Formulierung vor. Speichere noch nichts in Tareno, bis ich die Prüfung abgeschlossen habe.

Nutze Tareno, um die LinkedIn-Unternehmensseite [Name] zu bestätigen und den freigegebenen Text für diese Seite als Entwurf zu speichern. Gib Entwurfs-ID und gespeicherten Wortlaut zurück. Frage erst nach einem Veröffentlichungszeitpunkt, wenn ich bestätigt habe, dass die rechtliche Prüfung abgeschlossen ist.

Typische Fehler

• Eine Kennzahl veröffentlichen, die aus einem Staging-Benchmark stammt. Nenne die Umgebung, in der sie gemessen wurde, oder lass die Zahl weg.
• Die Fallstudie nur als Erfolgsgeschichte erzählen. Andere Ingenieurinnen und Ingenieure vertrauen einem Beitrag eher, wenn er auch die verworfene Option und die Kosten der gewählten Lösung nennt.
• Ein Diagramm mit internen Servicenamen hochladen. Prüfe jedes Bild auf Hostnamen und interne Produktnamen, bevor es in Tareno landet.
• Rechts- oder Kundenprüfung auslassen, obwohl ein Kunde durch Kontext erkennbar ist, etwa wegen eines ungewöhnlichen Volumens oder einer regionalen Angabe.