Generarea de cod NX Open: pe scurt
Generarea de cod NX Open înseamnă să pui un model de limbaj să scrie codul Python sau C# care automatizează Siemens NX. Modelele livrează schela de cod în mod fiabil și inventează apeluri API care nu există. inteliScience le ancorează pe referința NX Open și verifică fiecare jurnal headless înainte să ajungă la postul de lucru al unui inginer, ceea ce reduce aproximativ la jumătate timpul până la o automatizare verificată.
| Ieșire LLM fără grounding | Pipeline cu grounding și verificare | |
|---|---|---|
| Viteza primei versiuni | Minute | Minute |
| Apeluri API care compilează | Adesea greșite | Verificate față de referință |
| Sigur pe un post de lucru din producție | Nu | Da, după o rulare headless |
Problema: de ce NX Open încurcă modelele de limbaj
Asistenții de cod sunt doar atât de buni cât volumul de cod public pe care au fost antrenați, iar NX Open este un corpus subțire. Comparați volumul de cod React sau pandas de pe GitHub cu ce există pentru NXOpen: colecția de tutoriale comunitare cu cele mai multe stele, Foadsf/NXOpen_Python_tutorials, are 97 de stele și 12 fork-uri, ultimul push la 19 februarie 2026 (accesat pe 28 iulie 2026). Acesta este semnalul public de antrenament pentru o suprafață API de câteva mii de clase.
Rezultatul este un mod de eșec specific. Dacă îi cereți unui model un jurnal NX Open, apare ceva ce se citește ca NX Open corect — importuri corecte, pattern de sesiune corect, nume de metode plauzibile — și apoi apelează o metodă pe care Siemens nu a livrat-o niciodată.
Acest lucru este măsurabil. Un studiu de replicare din 2026 pe cinci modele de cod de frontieră — Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro și DeepSeek V3.2 — a găsit rate de halucinare a numelor de pachete între 4.62% și 6.10% pe 199,845 de prompturi, în scădere față de intervalul de 5.2%–21.7% raportat de Spracklen et al. la USENIX Security ’25, dar problema nu este rezolvată (arXiv:2605.17062). Aceste cifre sunt pentru PyPI și npm — registre pe care modelele le-au văzut de milioane de ori. Pentru un API CAD proprietar, rata de eroare pe semnături de metode concrete este considerabil mai mare.
Inginerii percep acest lucru ca timp pierdut, nu ca problemă de securitate. Primiți cod care pare finalizat, îl depanați patruzeci de minute în NX și descoperiți că modelul avea nevoie de o ierarhie de obiecte complet diferită.
Ce face bine AI-ul și unde inventează apeluri API
Modelele sunt bune la structură și slabe la recall. Schela unui jurnal NX Open — handle de sesiune, work part, listing window, iterație, tratarea erorilor — este stabilă în întregul API și bine reprezentată în exemplele publice existente. Așa ceva iese curat:
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()Cereți acum aceluiași model masa unui corp. Variante ca cele trei de mai jos apar iar și iar la asistenții actuali, iar niciuna nu există în 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()Calea reală are nevoie de un array de unități construit din colecția de unități a piesei, de o toleranță de precizie și de eliberarea ulterioară a obiectului de măsurare. Niciun prompting nu duce un model acolo în mod fiabil, pentru că aceasta este recall, nu raționament — un punct pe care literatura despre halucinații îl face explicit: modelele distilate pentru raționament halucinează API-uri de bibliotecă la aceeași rată ca variantele fără raționament.
Unde se aplică acest pattern
Tot ce citește piesa este ușor de corectat când greșește. Devine scump acolo unde se scrie geometrie, se editează ansambluri sau se atinge Teamcenter, pentru că eșecul poate ieși la iveală abia când cineva deschide piesa trei săptămâni mai târziu.
Grounding și verificare: bucla care face totul utilizabil
Două schimbări transformă generarea de cod NX Open dintr-un truc de petrecere într-o metodă solidă.
Ancorați modelul pe referința reală
Retrieval peste documentația NX Open pentru versiunea dumneavoastră exactă de NX, plus biblioteca dumneavoastră de jurnale existente, plus standardele dumneavoastră de denumire și atribute. Modelul nu mai ghicește semnături, pentru că cele corecte sunt în contextul său. Este aceeași arhitectură care stă în spatele asistenților de cunoștințe NX pe care îi construim pentru echipe de inginerie, îndreptați spre cod în loc de întrebări de documentație — inteliScience le rulează on-premise acolo unde constrângerile GDPR sau de proprietate intelectuală exclud trimiterea datelor despre piese către un API public.
Verificați prin rulare, nu prin citire
Fiecare jurnal generat trece prin NX în mod batch, pe un set de piese de test reprezentative, înainte ca vreun om să îl vadă. Erorile de compilare și metodele inventate mor imediat. Ce supraviețuiește primește o recenzie reală.
Acesta rulează ca un POC. Ce lipsește pentru producție: Fixarea versiunii peste două release-uri NX pe an, execuția în batch și tratarea erorilor la eșecul încărcării pieselor, contextul de sesiune Teamcenter, rollout pe sute de posturi de lucru și o suită de regresie care vă spune când un update Siemens v-a stricat jurnalul. Închidem decalajul de la “rulează pe calculatorul meu” la “rulează în întreprindere” — discutați cu inginerii noștri despre programarea NX Open.
Recomandarea noastră clară: niciun cod NX Open generat nu ajunge pe un post de lucru din producție fără o rulare headless pe piese de test. Echipele care sar peste acest pas nu economisesc timp, ci mută depanarea către inginerul care a avut încredere în script.
Unde se amortizează prima generarea de cod NX Open
Începeți acolo unde sarcina este repetitivă, rezultatul este verificabil și o greșeală este ieftină. Această ordine contează mai mult decât alegerea modelului.
| Sarcină | Pârghie AI | Ce necesită în continuare un inginer |
|---|---|---|
| Export în lot de desene și PDF-uri pe un ansamblu | Ridicat | Reguli de denumire, logica reviziilor |
| Curățarea atributelor și sincronizarea cu Teamcenter | Ridicat | Maparea pe schema dumneavoastră PLM |
| Extragerea de rapoarte și liste de materiale (BOM) din datele pieselor | Ridicat | Format de ieșire, cazuri limită |
| Crearea de familii parametrice de piese | Mediu | Intenția de proiectare, tolerarea |
| Configurarea operațiilor CAM | Mediu | Limitele mașinii, dispozitivele de prindere |
| Crearea geometriei de la zero | Scăzut | Aproape tot |
De ce generarea de geometrie este pilotul greșit
Am sfătui împotriva începerii cu crearea de geometrie, exact acolo unde încep majoritatea piloturilor și exact acolo unde se blochează. Decalajul dintre “apare un bloc” și “o caracteristică fabricabilă care respectă regulile dumneavoastră de proiectare” este întreaga muncă.
Pentru echipele care încă analizează ce fluxuri de lucru merită automatizate, ghidul nostru din 2026 despre NX AI și automatizarea NX Open detaliază partea de ROI a acestei decizii.
Designcenter Copilot nu este un generator de cod
Siemens a redenumit NX CAD în Designcenter , cu release-ul din iunie 2026, versiunea 2606 (blogul Siemens Designcenter); NX for Manufacturing 2606 a fost livrat pe 19 iunie 2026. Funcția AI principală este Designcenter Copilot, un asistent conversațional ancorat în documentația Siemens și în contextul dumneavoastră actual. Notele de release nu spun nimic despre modificări ale API-ului NX Open în sine.
Această distincție se pierde în aproape fiecare discuție pe care o avem. Copilot răspunde la întrebări. Nu scrie automatizarea dumneavoastră.
| Designcenter Copilot | Asistent IDE | Pipeline NX Open cu grounding | |
|---|---|---|---|
| Răspunde la “cum fac…” din documentația Siemens | Da | Parțial | Da |
| Scrie jurnale NX Open | Nu | Da, neverificat | Da, verificat |
| Cunoaște standardele și denumirile dumneavoastră | Nu | Nu | Da |
| Rulează și testează rezultatul | Nu | Nu | Da, headless |
| Implementabil pe sute de posturi de lucru | n/a | Nu | Da |
Stratul de asistenți stă lângă automatizarea dumneavoastră, nu deasupra ei
Siemens împinge puternic aici, iar cifrele citate sunt reale: Michael Taesch, senior director product management pentru NX CAM, estimează că NX CAM Copilot economisește 80% sau mai mult din timpul de programare CAM. Teamcenter 2606, tot din iunie 2026, a livrat primul agent AI pentru liste de materiale (BOM), care propune și execută modificări în mai mulți pași. Nimic din toate acestea nu înlocuiește automatizarea care vă aparține.
În practică, abordarea bazată exclusiv pe asistentul din IDE rezistă rar la contactul cu un upgrade de NX. Nimeni nu deține scriptul, niciun test nu vă spune că s-a stricat, iar inginerul care l-a generat a plecat mai departe.
Dacă propriii dumneavoastră ingineri trebuie să răspundă de acest cod, au nevoie de cunoștințele despre API din spatele lui. Cursurile de instruire Siemens NX de la inteliScience includ un curs NXOpen pe propriile dumneavoastră piese, la sediul dumneavoastră sau live online.
Întrebări frecvente
Pot ChatGPT sau Claude să scrie cod NX Open funcțional?
Pentru schele de cod și jurnale doar-citire, adesea da, din prima încercare. De îndată ce intervin semnături de metode concrete — măsurare, editarea ansamblurilor, acces la Teamcenter — apar apeluri API inventate. Soluția este retrieval peste referința NX Open pentru versiunea dumneavoastră de NX plus o rulare de test headless, nu un prompt mai bun.
Cât costă un proiect de automatizare NX Open asistat de AI?
O automatizare unică, bine delimitată — de exemplu exportul de desene în lot după regulile dumneavoastră de denumire — se situează în zona zecilor de mii de euro, inclusiv cadrul de verificare. Exact acest cadru este subestimat de echipe: reprezintă de obicei 40–60% din efort și este motivul pentru care automatizarea funcționează și după următorul release NX.
NX Open Python sau C#?
Python pentru jurnale, explorare și tot ce întreține o echipă mică. C# atunci când livrați un add-in compilat cu interfață proprie, aveți nevoie de performanță pe ansambluri mari sau trebuie să vă integrați într-un lanț de instrumente .NET existent. Modelele sunt vizibil mai bune pe varianta Python, pur și simplu pentru că există mai mult cod public.
Înlocuiește Designcenter Copilot automatizarea NX Open proprie?
Nu. Copilot este un asistent de documentație și orientare din interiorul aplicației; răspunde la întrebări despre cum se face ceva. Codul NX Open propriu execută munca nesupravegheat, pe un ansamblu întreg sau pe un release complet, după regulile dumneavoastră. Sunt două probleme diferite.
Cum împiedicăm codul generat să se strice la următorul release NX?
Fixați versiunea NX în build, mențineți o suită de regresie cu piese de test reprezentative și rulați-o pe fiecare release nou într-un mediu de staging. Siemens livrează aproximativ două ori pe an, deci este o sarcină planificată, nu o surpriză.
Pasul următor
Aduceți un flux de lucru NX repetitiv la o discuție de 60 de minute. Vă spunem dacă automatizarea NX Open asistată de AI este instrumentul potrivit pentru el și cum ar trebui să arate cadrul de verificare. inteliScience livrează acest lucru cu ingineri NX Open seniori din România, cu doar o oră înaintea clienților noștri din DACH.
Rezervați o discuție de strategie despre backlogul dumneavoastră de automatizare NX