Szkolenie Asystent AI + MCP dla Inventora

Czas trwania szkolenia: 2 dni, 14 godz.

Wymagania wstępne: ukończone szkolenia Inventor poziom I i II. Mile widziane podstawy iLogic. Nie wymagamy umiejętności programowania — kod narzędzi pisze asystent, my uczymy go czytać, testować i oceniać.
Wymóg organizacyjny: uczestnik przychodzi na szkolenie z własną, aktywną subskrypcją asystenta AI obsługującego standard MCP. Dzięki temu wychodzi ze skonfigurowanym własnym środowiskiem, które
działa po powrocie do firmy. Listę wspieranych aplikacji i minimalnych planów wysyłamy w mailu przed szkoleniem.

Cele kształcenia:

• konfiguracja asystenta AI połączonego z Inventorem,
• formułowanie zleceń, które asystent wykonuje poprawnie za pierwszym razem,
• audyt i raportowanie modeli oraz dokumentacji z pomocą AI,
• bezpieczne modyfikowanie modeli, złożeń i rysunków przez asystenta,
• rozpoznawanie zagrożeń i zasady wpuszczenia AI do środowiska projektowego,
• budowa własnego narzędzia rozszerzającego możliwości asystenta,
• zapisanie standardu firmowego jako warstwy wiedzy asystenta — bez kodu

SZCZEGÓŁOWY PROGRAM SZKOLENIA

Dzień I — praca z asystentem

Fundamenty i krajobraz narzędzi

• Jak to działa: Standard MCP w pigułce — aplikacja, klient i serwer narzędzi; jeden plik konfiguracyjny obsługujący wielu asystentów.
• Co jest dostępne na rynku: Porównanie asystenta wbudowanego w Inventora, projektów społecznościowych i serwera używanego na szkoleniu — w kolumnach: odczyt, zapis geometrii, złożenia, rysunki.
• Dwa wzorce projektowe: Zestaw wąskich, kontrolowanych narzędzi kontra jedno narzędzie „wykonaj dowolny kod” — i dlaczego ta różnica wraca w rozmowie o bezpieczeństwie.

Audyt i raportowanie modeli

• Jak zlecać, żeby trafiało za pierwszym razem: Co asystent widzi sam, a co musisz mu podać; zlecenie z kryterium akceptacji zamiast opisu życzenia — dlaczego „popraw ten model” daje gorszy wynik niż
  „wypisz otwory bez fazy, potem zaproponuj poprawkę”.
• Inspekcja modelu: Lista operacji, wymiary, właściwości masowe, skan otworów, informacje o konstrukcjach blaszanych, stan zdrowia dokumentu.
• Inspekcja dokumentacji: Arkusze, widoki, style, tabelka rysunkowa i właściwości — obszar, w którym asystent oszczędza najwięcej czasu przy odbiorze cudzych plików.
• Raport odchyleń od standardu: Zlecenie sprawdzenia serii modeli pod kątem standardu firmowego i porównanie czasu z pracą ręczną.

Parametry i reguły iLogic z asystentem

• Sterowanie modelem przez rozmowę: Zmiana parametrów i generowanie wariantów wymiarowych.
• Reguła pisana przez AI: Asystent generuje regułę iLogic, człowiek ją czyta i uruchamia, a wynik weryfikujemy narzędziem odczytu — nie „na oko”.
• Skąd biorą się błędy modeli językowych: Dlaczego weryfikacja jest częścią procesu, a nie wyrazem nieufności.

Modyfikacje modelu, złożenia i dokumentacji

• Geometria w rozmowie: Szkic, wyciągnięcie, otwory i szyki zlecane asystentowi.
• Złożenia i konstrukcje ramowe: Wstawianie i pozycjonowanie komponentów, praca z generatorem ram.
• Operacje seryjne na dokumentacji: Porządkowanie serii rysunków — zadanie, którego ręcznie nikt nie wykonuje w rozsądnym czasie.
• Praca seryjna i miejsce człowieka: Zatwierdzasz plan przed serią, a nie każdą operację w serii — jak taki plan powinien wyglądać i co się dzieje przy błędzie w połowie serii.
• Granica skalowania: Kiedy asystent na stanowisku przestaje wystarczać i wchodzi automatyzacja serwerowa.

Bezpieczeństwo jako warunek wdrożenia

• Model zagrożeń: Wstrzyknięcie polecenia przez dane w pliku od podwykonawcy, zatrucie opisu narzędzia, nadużycie uprawnień; realne incydenty z ostatnich lat.
• Najgroźniejsza para narzędzi: Możliwość dopisania i uruchomienia reguły to w praktyce „wstaw kod i wykonaj kod” — omówienie konsekwencji.
• Zasady wdrożenia: Człowiek w pętli przy operacjach zapisu, praca na kopiach, uprawnienia per rola, wyłącznie kontrolowane serwery narzędzi.

Dane, architektura i decyzje

• Lokalny serwer to nie lokalne dane: Co faktycznie opuszcza firmę i kiedy jedynym rozwiązaniem jest model uruchamiany lokalnie.
• Kiedy narzędzia, a kiedy wiedza: Reguła decyzyjna — dane zmienne obsługuje serwer narzędzi, wiedza stabilna (standardy, normalia) trafia do warstwy wiedzy asystenta.

Dzień II — budowa własnych narzędzi

Anatomia narzędzia

• Definicja narzędzia: Nazwa, opis, parametry z walidacją i wynik — cztery elementy, które decydują o tym, czy asystent użyje narzędzia poprawnie.
• Opis jako interfejs: Dobry opis sprawia, że AI sięga po narzędzie we właściwym momencie; zły powoduje, że narzędzie jest ignorowane albo używane błędnie.
• Narzędzia wąskie kontra szerokie: Dlaczego zestaw precyzyjnych operacji jest bezpieczniejszy i skuteczniejszy niż jedna wszechmocna funkcja.
• Pokaz na żywo: Trener dodaje nowe narzędzie od zera — definicja, wygenerowanie kodu przez AI, uruchomienie, test.

Pierwsze własne narzędzie

• Wybór zadania: Uczestnik wybiera z przygotowanej listy propozycji o przewidywalnej trudności — eksport parametrów, raport wiązań złożenia, audyt nazw komponentów, zestawienie mas.
• Przebieg pracy: Specyfikacja narzędzia (człowiek) → kod (AI) → przegląd (człowiek) → test na modelu → poprawki.
• Praca w izolowanym środowisku: Każdy uczestnik pracuje na własnej kopii serwera, więc błąd nie blokuje sali.

Narzędzie z własnego procesu

• Przywieź swój przypadek: Powtarzalna czynność z Twojej codziennej pracy jako kandydat na narzędzie — temat zapowiadany w mailu przed szkoleniem.
• Pierwsze narzędzie zapisujące: Walidacja danych wejściowych i praca na kopii jako warunek dopuszczenia narzędzia do użytku.
• Przegląd krzyżowy: Wzajemna recenzja narzędzi i ich opisów — czy asystent to zrozumie, czy opis nie obiecuje za dużo, czy walidacja zatrzyma złe dane.

Standard firmowy jako warstwa wiedzy

• Kiedy brakuje nie narzędzia, tylko wiedzy: Konwencja nazw, normalia i typoszeregi, wymagania tabelki rysunkowej — ustalenia firmy, których nie da się odczytać z modelu.
• Własna warstwa wiedzy bez linijki kodu: Zapisujesz fragment standardu swojej firmy i powtarzasz audyt z pierwszego dnia — różnicę w raporcie widać od razu.
• Utrzymanie: Kto aktualizuje zapisaną wiedzę i dlaczego nieaktualna norma jest groźniejsza niż jej brak.

Bezpieczeństwo i droga do wdrożenia

• Checklista narzędzia: Odczyt czy zapis, zakres uprawnień, walidacja wejść, najgorszy możliwy skutek błędnego wywołania, uczciwość opisu. Szablon do zabrania.
• Czego nie wystawiać: Narzędzia typu „wykonaj cokolwiek”, dostęp poza katalog projektu, operacje na plikach oryginalnych.
• Od prototypu do produkcji: Jak wygląda wdrożenie serwera narzędzi w firmie — utwardzenie, narzędzia pod własne procesy, warstwa wiedzy inżynierskiej, zgoda działu IT i metryki pilotażu.

Kolejność omawianych zagadnień może być modyfikowana w celu lepszego dostosowania do potrzeb i oczekiwań
uczestników oraz przebiegu szkolenia.

Warunkiem realizacji szkolenia jest zebranie minimalnej, wymaganej liczby uczestników (4 osób).
W przypadku niezebrania się wymaganej minimalnej liczby, osobom zapisanym na szkolenie zaproponowane zostanie przesunięcie zgłoszenia na kolejny terminy szkolenia.

REGULAMIN ŚWIADCZENIA USŁUG SZKOLENIOWYCH