NX Open Code-Generierung mit KI: Was 2026 funktioniert

NX Open Code-Generierung: Die Kurzfassung

NX Open Code-Generierung heißt, ein Sprachmodell den Python- oder C#-Code schreiben zu lassen, der Siemens NX automatisiert. Modelle liefern das Grundgerüst zuverlässig und erfinden API-Aufrufe, die es nicht gibt. inteliScience erdet sie auf der NX Open Referenz und verifiziert jedes Journal headless, bevor es auf den Arbeitsplatz eines Ingenieurs kommt — das halbiert die Zeit bis zur geprüften Automatisierung ungefähr.

	LLM-Ausgabe ohne Grounding	Pipeline mit Grounding und Verifikation
Geschwindigkeit des ersten Entwurfs	Minuten	Minuten
API-Aufrufe, die kompilieren	Häufig falsch	Gegen die Referenz geprüft
Sicher auf einem Produktivarbeitsplatz	Nein	Ja, nach einem Headless-Lauf

Das Problem: Warum NX Open Sprachmodelle stolpern lässt

Code-Assistenten sind nur so gut wie die Menge öffentlichen Codes, mit dem sie trainiert wurden — und NX Open ist ein dünner Korpus. Vergleichen Sie das Volumen an React- oder pandas-Code auf GitHub mit dem, was es für NXOpen gibt: die Tutorial-Sammlung der Community mit den meisten Stars, Foadsf/NXOpen_Python_tutorials, kommt auf 97 Stars und 12 Forks, letzter Push am 19. Februar 2026 (abgerufen am 28. Juli 2026). Das ist das öffentliche Trainingssignal für eine API-Oberfläche von mehreren Tausend Klassen.

Das Ergebnis ist ein spezifisches Fehlermuster. Fragt man ein Modell nach einem NX Open Journal, entsteht etwas, das sich wie korrektes NX Open liest — richtige Imports, richtiges Session-Muster, plausible Methodennamen — und ruft dann eine Methode auf, die Siemens nie ausgeliefert hat.

Das ist messbar. Eine Replikationsstudie von 2026 über fünf Frontier-Code-Modelle — Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro und DeepSeek V3.2 — ermittelte Halluzinationsraten bei Paketnamen zwischen 4.62% und 6.10% über 199,845 Prompts, gegenüber der Spanne von 5.2%–21.7%, die Spracklen et al. auf der USENIX Security ’25 berichteten — gelöst ist das Problem damit nicht (arXiv:2605.17062). Diese Zahlen gelten für PyPI und npm — Registries, die die Modelle millionenfach gesehen haben. Bei einer proprietären CAD-API ist die Fehlerquote bei konkreten Methodensignaturen deutlich höher.

Ingenieure erleben das nicht als Sicherheitsthema, sondern als verlorene Zeit. Sie bekommen Code, der fertig aussieht, debuggen ihn vierzig Minuten in NX und stellen fest, dass das Modell eine völlig andere Objekthierarchie gebraucht hätte.

Was KI richtig macht — und wo sie API-Aufrufe erfindet

Modelle sind gut in Struktur und schlecht im Abrufen von Details. Das Grundgerüst eines NX Open Journals — Session-Handle, Work Part, Listing Window, Iteration, Fehlerbehandlung — ist über die gesamte API stabil und in den vorhandenen öffentlichen Beispielen gut vertreten. So etwas kommt sauber heraus:

import NXOpen

def main():
    session = NXOpen.Session.GetSession()
    work_part = session.Parts.Work
    lw = session.ListingWindow
    lw.Open()

    for body in work_part.Bodies:
        lw.WriteLine(f"{body.JournalIdentifier}  solid={body.IsSolidBody}")

if __name__ == "__main__":
    main()

Fragen Sie dasselbe Modell jetzt nach der Masse eines Körpers. Varianten wie die drei folgenden tauchen bei aktuellen Assistenten immer wieder auf — und keine davon existiert in NX Open:

# Invented — none of these are real NX Open calls
mass = work_part.GetMass()
mass = body.Mass
mass = NXOpen.MeasureManager.GetMass(body)

# What NX Open actually requires: a unit array, an accuracy, the part's MeasureManager
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
uc = work_part.UnitCollection
units = [uc.FindObject("SquareCentiMeter"), uc.FindObject("CubicCentiMeter"),
         uc.FindObject("Gram"), uc.FindObject("CentiMeter"), uc.FindObject("Newton")]

props = work_part.MeasureManager.NewMassProperties(units, 0.999, [body])
mass = props.Mass   # in grams, the mass unit in the array
props.Dispose()

Der echte Weg braucht ein Unit-Array aus der eigenen Unit-Collection des Teils, eine Genauigkeitstoleranz und das anschließende Verwerfen des Messobjekts. Kein Prompting bringt ein Modell zuverlässig dorthin, denn das ist Abruf, nicht Schlussfolgern — ein Punkt, den die Halluzinations-Literatur ausdrücklich macht: reasoning-destillierte Modelle halluzinieren Bibliotheks-APIs genauso häufig wie ihre Geschwister ohne Reasoning.

Wo das Muster gilt

Alles, was das Teil liest, ist im Fehlerfall leicht zu korrigieren. Teuer wird es, wo Geometrie geschrieben, Baugruppen bearbeitet oder Teamcenter angefasst wird — denn dort zeigt sich der Fehler vielleicht erst, wenn drei Wochen später jemand das Teil öffnet.

Grounding und Verifikation: Die Schleife, die es nutzbar macht

Zwei Änderungen machen aus NX Open Code-Generierung statt eines Partytricks eine belastbare Methode.

Erden Sie das Modell auf der echten Referenz

Retrieval über die NX Open Dokumentation Ihrer genauen NX-Version, dazu Ihre eigene bestehende Journal-Bibliothek und Ihre Benennungs- und Attributstandards. Das Modell hört auf, Signaturen zu raten, weil die korrekten in seinem Kontext stehen. Das ist dieselbe Architektur wie hinter den NX-Wissensassistenten, die wir für Engineering-Teams bauen, nur auf Code statt auf Dokumentationsfragen gerichtet — inteliScience betreibt diese on-premise, wo DSGVO- oder IP-Vorgaben es ausschließen, Teiledaten an eine öffentliche API zu senden.

Verifizieren durch Ausführen, nicht durch Lesen

Jedes generierte Journal läuft im Batch-Modus durch NX — gegen einen Satz repräsentativer Testteile, bevor ein Mensch es überhaupt sieht. Compile-Fehler und erfundene Methoden sterben sofort. Was übrig bleibt, bekommt ein echtes Review.

Das läuft als POC. Was für die Produktion fehlt: Versions-Pinning über zwei NX-Releases pro Jahr, Batch-Ausführung und Fehlerbehandlung bei fehlgeschlagenem Teile-Laden, Teamcenter-Session-Kontext, Rollout auf hunderte Arbeitsplätze und eine Regressionssuite, die Ihnen sagt, wann ein Siemens-Update Ihr Journal zerstört hat. Wir schließen die Lücke von “läuft auf meinem Rechner” zu “läuft im Unternehmen” — Sprechen Sie mit unseren Engineers über NX Open Programmierung.

Unsere klare Empfehlung: Kein generierter NX Open Code kommt ohne Headless-Lauf gegen Testteile auf einen Produktivarbeitsplatz. Teams, die diesen Schritt überspringen, sparen keine Zeit — sie verlagern das Debugging auf den Ingenieur, der dem Skript vertraut hat.

Wo sich NX Open Code-Generierung zuerst auszahlt

Fangen Sie dort an, wo die Aufgabe repetitiv, das Ergebnis prüfbar und ein Fehler günstig ist. Diese Reihenfolge zählt mehr als die Wahl des Modells.

Aufgabe	KI-Hebel	Was weiterhin einen Ingenieur braucht
Stapel-Export von Zeichnungen und PDFs über eine Baugruppe	Hoch	Benennungsregeln, Revisionslogik
Attribut-Bereinigung und Teamcenter-Sync	Hoch	Mapping auf Ihr PLM-Schema
Report- und Stücklisten-Extraktion aus Teiledaten	Hoch	Ausgabeformat, Sonderfälle
Erstellung parametrischer Teilefamilien	Mittel	Design-Intent, Tolerierung
Einrichten von CAM-Operationen	Mittel	Maschinengrenzen, Spannmittel
Geometrieerstellung von Grund auf	Niedrig	Praktisch alles davon

Warum Geometriegenerierung der falsche Pilot ist

Wir würden davon abraten, mit Geometrieerstellung anzufangen — genau dort beginnen die meisten Piloten, und genau dort bleiben die meisten stecken. Die Lücke zwischen “ein Block erscheint” und “ein herstellbares Feature, das Ihre Konstruktionsregeln einhält” ist die eigentliche Arbeit.

Für Teams, die noch abwägen, welche Workflows überhaupt automatisiert werden sollen, arbeitet unser Leitfaden 2026 zu NX KI und NX Open Automatisierung die ROI-Seite dieser Entscheidung durch.

Designcenter Copilot ist kein Code-Generator

Siemens hat NX CAD umbenannt in Designcenter , mit dem Release vom Juni 2026, Version 2606 (Siemens Designcenter Blog); NX for Manufacturing 2606 erschien am 19. Juni 2026. Das AI-Highlight ist Designcenter Copilot, ein dialogbasierter Assistent, der auf der Siemens-Dokumentation und Ihrem aktuellen Kontext aufsetzt. Zu Änderungen an der NX Open API selbst sagen die Release Notes nichts.

Diese Unterscheidung geht in fast jedem Gespräch unter, das wir führen. Copilot beantwortet Fragen. Er schreibt nicht Ihre Automatisierung.

	Designcenter Copilot	IDE-Assistent	NX Open Pipeline mit Grounding
Beantwortet “Wie mache ich…” aus der Siemens-Doku	Ja	Teilweise	Ja
Schreibt NX Open Journals	Nein	Ja, unverifiziert	Ja, verifiziert
Kennt Ihre Standards und Benennung	Nein	Nein	Ja
Führt das Ergebnis aus und testet es	Nein	Nein	Ja, headless
Auf hunderte Arbeitsplätze ausrollbar	n/a	Nein	Ja

Die Assistenten-Schicht sitzt neben Ihrer Automatisierung, nicht darüber

Siemens drückt hier stark, und die genannten Zahlen sind echt: Michael Taesch, Senior Director Product Management für NX CAM, schätzt, dass NX CAM Copilot 80% oder mehr der CAM-Programmierzeit einspart. Teamcenter 2606, ebenfalls Juni 2026, brachte den ersten AI-BOM-Agenten, der mehrstufige Änderungen vorschlägt und ausführt. Nichts davon ersetzt die Automatisierung, die Ihnen gehört.

In der Praxis übersteht ein Vorgehen, das nur auf den IDE-Assistenten setzt, den Kontakt mit einem NX-Upgrade selten. Niemand besitzt das Skript, kein Test sagt Ihnen, dass es kaputt ist, und der Ingenieur, der es generiert hat, ist weitergezogen.

Sollen Ihre eigenen Ingenieure diesen Code verantworten, brauchen sie das API-Wissen dahinter. Die Siemens-NX-Schulungen von inteliScience umfassen einen NXOpen-Kurs an Ihren eigenen Bauteilen, bei Ihnen vor Ort oder live online.

Häufig gestellte Fragen

Können ChatGPT oder Claude funktionierenden NX Open Code schreiben?

Für Grundgerüste und rein lesende Journals oft ja, schon beim ersten Versuch. Sobald konkrete Methodensignaturen ins Spiel kommen — Messung, Baugruppenbearbeitung, Teamcenter-Zugriff —, sind erfundene API-Aufrufe die Regel. Die Lösung ist Retrieval über die NX Open Referenz Ihrer NX-Version plus ein Headless-Testlauf, nicht ein besserer Prompt.

Was kostet ein KI-gestütztes NX Open Automatisierungsprojekt?

Eine einzelne, klar abgegrenzte Automatisierung — etwa der Stapel-Zeichnungsexport nach Ihren Benennungsregeln — liegt im unteren fünfstelligen Bereich, inklusive Prüfgerüst. Genau dieses Prüfgerüst unterschätzen Teams: Es macht meist 40–60% des Aufwands aus und ist der Grund, warum die Automatisierung auch nach dem nächsten NX-Release noch läuft.

NX Open Python oder C#?

Python für Journals, Exploration und alles, was ein kleines Team pflegt. C#, wenn Sie ein kompiliertes Add-in mit eigener UI ausliefern, Performance bei großen Baugruppen brauchen oder in eine bestehende .NET-Toolchain integrieren müssen. Modelle sind bei der Python-Variante merklich besser — einfach weil davon mehr öffentlich existiert.

Ersetzt Designcenter Copilot eigene NX Open Automatisierung?

Nein. Copilot ist ein Dokumentations- und Orientierungsassistent innerhalb der Anwendung; er beantwortet Fragen dazu, wie etwas geht. Eigener NX Open Code führt die Arbeit unbeaufsichtigt aus — über eine ganze Baugruppe oder ein komplettes Release hinweg, nach Ihren Regeln. Das sind zwei verschiedene Probleme.

Wie verhindern wir, dass generierter Code beim nächsten NX-Release bricht?

Pinnen Sie die NX-Version im Build, halten Sie eine Regressionssuite mit repräsentativen Testteilen vor und lassen Sie sie gegen jedes neue Release in einer Staging-Umgebung laufen. Siemens liefert etwa zweimal pro Jahr aus — das ist eine geplante Aufgabe, keine Überraschung.

Nächster Schritt

Bringen Sie einen repetitiven NX-Workflow in ein 60-minütiges Gespräch mit. Wir sagen Ihnen, ob KI-gestützte NX Open Automatisierung dafür das richtige Werkzeug ist und wie das Prüfgerüst aussehen müsste. inteliScience liefert das mit Senior-NX-Open-Engineers aus Rumänien, unseren DACH-Kunden nur eine Stunde voraus.

Strategiegespräch zu Ihrem NX-Automatisierungs-Backlog buchen