KI-gestütztes Review elektronischer Baugruppen

Use Case · Entwicklung & Qualität

Wie aus einem Zweizeiler in acht Iterationen ein wiederverwendbarer Analyse-Prompt wurde – anwendbar auf rund einhundert Baugruppen desselben Kunden.

Ausgangslage

Technische Design-Reviews elektronischer Baugruppen sind aufwendig. Sie erfordern erfahrene Entwickler, laufen unter Termindruck und decken trotzdem nicht jeden Punkt ab – besonders dann, wenn viele vergleichbare Baugruppen nacheinander zu prüfen sind. Die naheliegende Idee, ein Sprachmodell einzusetzen, scheitert im ersten Anlauf zuverlässig: Auf die Aufforderung „Führe ein technisches Review durch“ produziert ein Modell allgemeine Aussagen, rät Bauteilwerte und erfindet Netznamen. Das Ergebnis ist nicht nur nutzlos, sondern irreführend.

In einem Kundenprojekt haben wir deshalb nicht nach dem besseren Modell gesucht, sondern nach dem besseren Auftrag. Über acht Iterationen entstand ein Analyse-Prompt, der das Vorgehen, den Kontext und vor allem die Grenzen der Auswertbarkeit verbindlich vorgibt. Nach jeder Iteration bewertete ein Fachprüfer den erzeugten Output manuell auf Plausibilität und fachliche Richtigkeit und entschied, welche Lücke in die nächste Fassung einfließt.

Fünf Hebel, die den Unterschied machen

1. Rolle und prüfbare Struktur. Eine klare fachliche Rolle und feste Prüfkategorien machen aus einem Textgenerator einen strukturierten Prüfer. Das verbessert die Form – noch nicht den Inhalt.
2. Funktionsverständnis vor Bewertung. Das Modell muss zuerst das Funktionsprinzip der Baugruppe in eigenen Worten erklären und daraus die kritischen Knoten ableiten. Erst danach beginnt die Prüfung. Damit prüft es diese Baugruppe statt irgendeiner.
3. Einsatzkontext und Normbezug. Gerätekontext, Versorgungskonzept und die maßgeblichen Normen werden als Parameter vorgegeben. Erst dadurch werden Grenzwerte, Trennstrecken und Isolationsanforderungen überhaupt bewertbar.
4. Dokumenten-Inventur vor der Prüfung. Das Modell listet zuerst auf, welche Unterlagen es tatsächlich erhalten hat und in welchem Format, und markiert fehlende Dokumente. Damit bewertet es nicht mehr stillschweigend auf Lücken.
5. Datenrealität und Toleranzanalyse. Verbindliche Regel: Was nicht lesbar vorliegt, wird als „nicht bewertbar – fehlende Daten“ gekennzeichnet statt geschätzt. Geometrie aus Gerber- oder CAD-Dateien kann ein Sprachmodell nicht messen. Wo Werte vorliegen, wird gerechnet – mit offengelegten Eingangswerten und Annahmen.

Aufbau des Reports

Der Report trennt konsequent zwischen dem, was belegt ist, und dem, was nicht:

• (A) Belegte Designfehler – durch die gelieferten Unterlagen nachweisbar.
• (B) Zu prüfende Auffälligkeiten – plausibel, aber ohne weitere Daten nicht abschließend bewertbar.
• (C) Nicht bewertbar – mit Benennung der jeweils fehlenden Angabe.

Jeder Befund folgt demselben Schema: Kategorie, Fundstelle, Beschreibung, Schweregrad, Begründung inklusive Normbezug und konkrete Handlungsempfehlung. Am Ende steht eine nach Schweregrad sortierte Maßnahmenliste. Eine formale Freigabe- oder Sperrentscheidung gibt das Modell ausdrücklich nicht ab.

Vom Einzelfall zur Vorlage

Die achte Iteration generalisiert das Ergebnis: Aus der konkret geprüften Baugruppe wird „elektronische Baugruppe“, aus Gerätetyp, Normen und Umgebungsbedingungen werden ausfüllbare Parameter. Der Prompt ist damit auf den gesamten Baugruppenbestand des Kunden anwendbar – im konkreten Fall rund einhundert Baugruppen – und lässt sich auf andere Geräte und Normen übertragen.

Nutzen

• Strukturierte Vorarbeit für das Review – der Entwickler startet nicht bei null
• Einheitliches Befund-Schema über alle Baugruppen hinweg, dadurch vergleich- und priorisierbar
• Transparenter Datenstand: fehlende Unterlagen werden benannt statt überspielt
• Wiederverwendbar durch Parametrierung statt Neuformulierung je Baugruppe
• Nachvollziehbare Toleranzrechnungen mit offengelegten Annahmen