Vom Datenblatt zum Schnappverschluss: Ein 3D-Gehäuse mit Claude Code entwerfen

Veröffentlicht am 30. Juli 2026 von Dominic Böttger (vor 3 Tagen) · 11 Min. Lesezeit

Ich hatte ein Problem, das nichts mit Software zu tun hatte: Auf meinem Schreibtisch lag ein Luftqualitätssensor als loser Haufen Einzelteile. Ein kleines ESP32-C6-Entwicklungsboard, ein Sensirion SEN66 in der Größe einer Streichholzschachtel und sechs Kabel dazwischen. Er hat wunderbar gemessen — Feinstaub, CO₂, Temperatur, Luftfeuchte — und sah aus wie etwas, das beim nächsten Vorbeigehen kaputtgeht.

Es brauchte also ein Gehäuse. Ich kann Blender bedienen — nicht auf Profi-Niveau, aber es reicht für eine Aufgabe wie diese. Und genau das macht die Sache interessant: Die Frage war nie, ob ich die Kiste selbst modellieren kann. Die Frage war, wie lange es dauert. Ein Zweikammer-Gehäuse mit Deckel, Lüftungsschlitzen und Schnappverbindungen von Hand zu bauen ist auf meinem Niveau ein Abend Arbeit, und jede Korrektur danach ist die nächste Runde davon. Die KI ist darin schlicht schneller als ich.

Also habe ich etwas anderes versucht. Ich habe Claude Code das Gehäuse entwerfen lassen. Nicht „generiere mir irgendwie eine STL-Datei”, sondern als echte Konstruktionsaufgabe, mit Datenblättern, Toleranzen und Schnappverbindungen. Was jetzt kommt, ist der Bericht darüber, was funktioniert hat, was nicht, und warum es am Ende nur drei Drucke gebraucht hat statt zehn.

Warum das überhaupt funktioniert: CAD als Text

Die entscheidende Wahl fiel vor der ersten Zeile: das Werkzeug. Die meisten 3D-Programme arbeiten visuell — man zieht Formen mit der Maus, und das Ergebnis ist ein Netz aus Millionen Dreiecken. Damit kann eine KI wenig anfangen. Sie sieht deinen Bildschirm nicht, und ein Dreiecksnetz lässt sich nicht sinnvoll als Text bearbeiten.

OpenSCAD funktioniert völlig anders. Dort beschreibt man einen Körper in einer einfachen Programmiersprache, und die Software baut ihn. Ungefähr so:

// Eine Kiste, 40 mm breit, mit einem Loch von 20 mm darin
difference() {
    cube([40, 30, 15]);
    cylinder(h = 20, d = 20);
}

Das ist der ganze Trick. difference() heißt „zieh die zweite Form von der ersten ab”. cube und cylinder sind genau das, was man vermutet. Keine Menüs, keine Maus, kein verborgener Zustand — nur Text.

Für eine KI ist das das perfekte Medium, und zwar aus drei Gründen. Sie kann Text schreiben. Sie kann Text gezielt ändern — eine einzelne Zahl statt eines kompletten Neuentwurfs. Und eine Textdatei kann man versionieren, vergleichen und kommentieren, sodass jedes Maß im Modell einen Vermerk trägt, woher es stammt.

Die zweite wichtige Eigenschaft ist der parametrische Aufbau. Alle Maße stehen oben in der Datei als benannte Werte:

wall       = 2.0;   // Wandstärke
pcb_l      = 51.8;  // Platinenlänge (aus der Espressif-Zeichnung)
pcb_tol    = 0.35;  // Spiel rund um die Platine
snap_depth = 0.85;  // wie weit die Haltenoppen vorstehen

Alles andere wird daraus berechnet. Ändert man die Wandstärke von 2 auf 2,5 mm, passen sich Außenmaße, Deckel, Kammerpositionen und Lüftungsschlitze von selbst an. Genau deshalb hat das Gehäuse sieben Revisionen überlebt, ohne je neu gebaut zu werden. Jede Korrektur war ein chirurgischer Eingriff an einer Stelle der Datei.

Die Installation ist unter Arch Linux ein Einzeiler, und für jede andere Distribution gibt es das Äquivalent:

sudo pacman -S openscad

Schritt 1: Maße besorgen statt raten

Mein erster Versuch scheiterte aus dem langweiligsten Grund, den man sich vorstellen kann: Das Modell hat die Maße erfunden. Claude Code produzierte ein sauberes, gut kommentiertes Gehäuse — für einen Sensor mit 48,5 mm Länge und 12,5 mm Höhe. Der echte SEN66 ist 55,2 mm lang und 21,3 mm hoch. Die Kammer war fast 7 mm zu kurz und 9 mm zu flach. Da hätte nie etwas hineingepasst.

Das ist die erste und wichtigste Lehre: Sprachmodelle haben eine grobe Vorstellung davon, wie verbreitete Bauteile aussehen, und grob ist im Maschinenbau wertlos. Ein Teil passt oder es passt nicht.

Die Lösung war einfach — ich habe die offiziellen Dokumente holen lassen:

• Das Sensirion-SEN6x-Datenblatt, ein 60-Seiten-PDF. Auf Seite 55 steht eine bemaßte technische Zeichnung mit jedem Maß auf den Zehntelmillimeter.
• Die PCB-Layout-Zeichnung des ESP32-C6-DevKitC-1 von Espressif, die die Platine mit 51,8 × 25,4 mm samt Pin-Abständen angibt.

Claude Code hat beide PDFs geladen und die relevanten Seiten als Bild gelesen — technische Zeichnungen sind Grafik, nicht Text, das geht also nur, wenn das Modell die Seite wirklich anschauen kann. Ab da trug jedes Maß in der Datei einen Quellenkommentar. Nicht „etwa 25 mm”, sondern „25,4 mm (Espressif-Layout, Rev. 1.1)”.

Die Zeichnung verriet außerdem etwas, das ich nie geraten hätte: Beim SEN66 liegen Lufteinlass und Lüfterauslass auf derselben großen Oberseite. Diese einzige Tatsache bestimmte die gesamte Architektur — der Deckel brauchte ein großes Fenster über dem Sensor, und der Sensor musste bündig direkt darunter sitzen.

Schritt 2: Sich selbst kontrollieren lassen

Bevor ein Gramm Filament verbraucht wurde, kam ein weiterer Schritt dazwischen: OpenSCAD kann ein Modell von der Kommandozeile aus als Bild rendern.

openscad -D 'part="body"' --render -o preview.png \
  --imgsize=1600,1000 --camera=0,0,0,58,0,22,0 --viewall modell.scad

Claude Code hat diese Vorschauen erzeugt und sich dann selbst angeschaut. Das klingt nach Spielerei, hat aber echte Fehler gefangen: einen Lüftungsschlitz, der versehentlich durch eine Wand schnitt, einen Kabelkanal auf falscher Höhe, einen Deckel, dessen Verstärkungsstege genau über der Lüfteröffnung des Sensors landeten. All das ist auf einem Bild offensichtlich und im Code unsichtbar.

Das ist der Punkt, an dem die Sache aufhört, ein Textgenerator zu sein, und anfängt, eine Konstruktionsschleife zu werden: bauen, anschauen, korrigieren.

Schritt 3: Drucken, fotografieren, patchen

Und dann kam der Teil, den kein Datenblatt ersetzt. Ich habe gedruckt. Und der erste Druck sah so aus:

Die Sensorkammer passte. Die Boardkammer nicht — nicht einmal annähernd. Und der Grund ist lehrreich: Meine Jumperkabel stecken auf Pins, die auf der Unterseite der Platine herausstehen. Das Modell war davon ausgegangen, dass die Stecker oben aufsitzen. Also hatte es die Platine 15 mm über dem Boden platziert, um darunter Platz zu lassen — für Stecker, die dort nicht waren, während die echten keinen Platz hatten.

Ich habe es fotografiert und das Bild geschickt. Das wurde das Muster für alles Weitere: Das Foto ist der Debug-Kanal. Ich habe nicht beschrieben, was falsch war. Ich habe es gezeigt. Und in fast jedem Foto hat Claude Code etwas im Modell gefunden, das keine Zeichnung verraten hatte.

Hier die vollständige, unschöne Liste:

Die Stecker waren auf der falschen Seite. Annahme: von oben aufgesteckt. Realität: hängen unter der Platine. Die Boardhöhe musste zweimal neu gebaut werden — erst zu hoch, dann zu tief, dann richtig.

Die Stecker waren breiter als gedacht. Sie sitzen direkt auf den Pinreihen an den Platinenkanten — genau dort, wo ich meine Auflageschienen hatte. Die Platine muss in der Mitte getragen werden, weil dort als einziger Stelle nichts nach unten heraussteht.

Zwei Lötpins mitten auf der Platine. Genau an der Stelle, wo die neue Mittelauflage hinsollte. Ich hatte sie in der Layout-Zeichnung gesehen und falsch verortet. Es brauchte ein Nahaufnahme-Foto der Platinenunterseite und eine gezielte Nachfrage von mir, bis die Auflage in vier Pads mit einer Lücke dazwischen aufgeteilt wurde.

Der Sensor ist tailliert, nicht eingekerbt. Die Datenblattzeichnung zeigt vier Merkmale an den Seitenflächen des SEN66. Ich habe sie als Vertiefungen zum Einrasten gelesen. Falsch — das Gehäuse ist dort einfach schmaler. Meine sorgfältig konstruierten Rastnasen griffen ins Leere. Aufgefallen ist mir das erst, als ich den Satz sagte: „An der Stelle ist das Gehäuse schmaler und die Nasen liegen nicht an.” Die Lösung: seitlich gar keine Rastung mehr, sondern dünne Quetschrippen plus ein Deckel, der das Modul von oben niederhält.

Der USB-Ausschnitt war breiter als die Platine. Das war mein Lieblingsfehler, weil die Geometrie fehlerfrei und die Funktion Unsinn war: eine einzige 26 mm breite Öffnung für beide USB-C-Buchsen. Die Platine ist 25,4 mm breit. Zog man am Kabel, rutschte das Board also durch seine eigene Öffnung heraus.

Die Lösung waren zwei getrennte 11-mm-Fenster mit einem 3 mm breiten Steg dazwischen. Die Platinenkante schlägt jetzt an diesem Steg an und bleibt drin. Die Stecker passen weiterhin durch, das Board nicht mehr.

Der Deckel ging zu leicht zu. Er hielt nur durch Reibung und rastete nicht immer ein. Drei Parameter haben es gelöst: größere Rastnoppen, tieferer Eingriff, strammere Lippenpassung.

Das Muster dahinter ist immer dasselbe. Datenblätter beschreiben Geometrie, nicht Verbauung. Wie ein Bauteil tatsächlich verkabelt wird, wohin die Stecker zeigen, was wo heraussteht — ein Mensch mit dem Teil in der Hand sieht das in zwei Sekunden, und die Zeichnung sagt darüber kein Wort.

Das Ergebnis

Das fertige Gehäuse misst 119 × 40 × 32 mm und braucht keine einzige Schraube:

• Zwei Kammern. Sensor links, Board rechts, dazwischen eine Trennwand, die die Abwärme der Elektronik vom Temperatursensor fernhält. Das ist relevant: Der SEN66 misst mehrere Grad zu warm, wenn er neben einer Wärmequelle sitzt.
• Das Board klickt ein. Vier Posten mit Haltenoppen greifen von oben über die Platinenkante, zwei Schienen tragen sie von unten in der Mitte, wo nichts heraussteht.
• Zwei USB-Fenster mit Ziehsicherung. Kabel rein, Kabel raus, das Board bleibt drin.
• Der Deckel schnappt. Vier kugelförmige Noppen rasten in flache Mulden in den Wänden. Die Kugelform ist hier der Trick, weil sie sich selbst zentriert und — anders als klassische Schnapphaken — nicht entlang der Druckschichten bricht.
• Alles Sichtbare bleibt sichtbar. Die Status-LED leuchtet durch ein Gitter, der Boot-Taster bleibt erreichbar, und der Sensor atmet durch ein großes Fenster im Deckel.

Sieben Revisionen des Modells — aber nur drei tatsächliche Drucke. Dieses Verhältnis ist das eigentliche Ergebnis. Die Renderings und die Fotos haben die Fehler gefangen, bevor sie Filament gekostet haben.

Das Rezept

Wenn du das nachmachen willst, decken fünf Regeln das meiste ab:

Textbasiertes CAD wählen. OpenSCAD, nicht Fusion. Das Modell muss lesen und ändern können, was es gebaut hat.

Keine geratenen Maße. Bestehe auf dem offiziellen Datenblatt oder der Layout-Zeichnung, und lass jeden Wert einen Quellenkommentar tragen. Was sich aus keinem Dokument belegen lässt, wird mit dem Messschieber gemessen — von dir.

Rendern vor dem Drucken. Bilder erzeugen lassen und das Modell draufschauen lassen. Kostet Sekunden, spart Stunden.

Fotografieren statt beschreiben. „Passt nicht” produziert Vermutungen. Ein Foto produziert eine Diagnose. Das ist der stärkste Hebel im ganzen Prozess.

Eine Änderung pro Druck. Wenn du drei Dinge gleichzeitig änderst und es passt trotzdem nicht, hast du nichts gelernt.

Und eine sechste Regel, die erst im Rückblick klar wird: weiter nachfragen. Die Hälfte der Fehler oben hat nicht das Modell gefunden, sondern meine eigenen Fragen — „passt das Board dann noch rein, wenn der Steg da ist?”, „wie hält der Deckel, wenn er plan aufliegt?”. Jede einzelne dieser Fragen hat einen echten Konstruktionsfehler aufgedeckt. Das ist genau das Muster, das ich in KI schreibt schneller als dein Schatten beschrieben habe: Die Maschine produziert im Tempo, der Mensch wacht über das Ergebnis. Bei physischen Teilen ist diese Rolle brutal offensichtlich, weil es keinen Interpretationsspielraum gibt. Es passt oder es passt nicht.

Wo das nicht funktioniert

Fairerweise zu den Grenzen. Der Ansatz ist stark bei technischer, kantiger Geometrie mit bekannten Maßen: Gehäusen, Halterungen, Aufnahmen, Adaptern, Distanzstücken. Er ist schwach oder unbrauchbar bei organischen Formen und Freiformflächen, bei allem Ergonomischen, das sich in der Hand gut anfühlen muss, bei Teilen ohne jede Dokumentation und bei echter Baugruppen-Kinematik wie Zahnrädern oder belasteten Scharnieren.

Und ohne Drucker und ohne Geduld funktioniert es gar nicht. Die Feedback-Schleife braucht das physische Teil. Wer auf eine fertige STL aus einem einzigen Prompt hofft, wird enttäuscht — und würde das Ergebnis wahrscheinlich nicht in seiner Wohnung verbauen wollen.

Dateien

Das Gehäuse passt für ein ESP32-C6-DevKitC-1 zusammen mit einem Sensirion SEN66 (oder jedem anderen SEN6x — die haben dieselbe Bauform):

• OpenSCAD-Quelldatei — alle Maße parametrisch am Dateianfang, mit Quellenkommentaren
• STL Korpus und STL Deckel

Alle drei Drucke sind in PLA mit 0,2 mm Schichthöhe entstanden, ohne Stützstrukturen — die Rastung funktioniert in PLA einwandfrei. Falls sie auf deinem Drucker zu stramm oder zu locker ausfällt, sind snap_depth und pcb_snap_depth in der SCAD-Datei die beiden Werte zum Nachstellen.

Der Sensor selbst läuft übrigens mit ESPHome und meldet nach Home Assistant — inklusive CO₂-Ampel auf der Onboard-LED des Boards, die ab 800 ppm gelb und ab 1400 ppm rot wird. Aber das ist ein Thema für einen eigenen Post.

Geschrieben von Dominic Böttger