Od hackathonu do żywego projektu: czego nauczyło nas dziesięć dni ze skillami Claude'a w Revicie (część 2)

W części pierwszej opisaliśmy jedną sesję hackathonu: Claude Code połączony z Revitem przez serwer MCP (Model Context Protocol), pusty projekt i prosta rama konstrukcyjna. Werdykt brzmiał: szybki junior, który potrzebuje kompletnego briefu i recenzenta. Ten artykuł obejmuje dziesięć dni, które nastąpiły potem, kiedy ten sam zespół wziął agenta na żywy projekt centrum danych.

Klientem jest studio projektowe wyspecjalizowane w centrach danych, którego standard wyznaczają gotowe modele referencyjne, w tym niedawny, w pełni wyspecyfikowany model od czołowej firmy inżynierskiej. Naszym zadaniem było osiągnąć ten standard na nowym projekcie: typy ścian, drzwi, sufity, wykończenia podłóg i pomieszczenia, kodowane tak, jak robią to wzorce. Pracowały trzy osoby: nasz information manager i dwoje modelerów, z których jedna dopiero zaczynała pracę w Revicie. Użyliśmy Claude Code, open source'owego serwera MCP dla Revita z dodatkiem do Revita, Speckle oraz niewielkiego zestawu własnych skilli.

Piszemy dla BIM managerów, information managerów i liderów cyfryzacji, którzy rozstrzygają, czy agenci AI mają miejsce w procesach produkcyjnych. To ważne, bo demo pokazuje jedno uruchomienie, a dopiero żywy model drugie. Poniżej: czym jest skill, jak nasze zbudowaliśmy i zepsuliśmy, cztery epizody, zasady, które stosujemy, oraz ograniczenia agenta.

Skill to spisana w języku naturalnym procedura, którą agent czyta, zanim zacznie działać. To nie skrypt ani prompt z czatu, tylko plik opublikowany dla całej organizacji, który dla jednego zadania mówi, na co patrzeć, jakich typów użyć, jak je kodować i kiedy się zatrzymać i zapytać. Nasze skille obejmują typy ścian, typy drzwi, typy sufitów, wykończenia podłóg i pomieszczenia, a do tego ogólny skill do geometrii, używany przy bryłach koncepcyjnych.

Różnicę widać na ekranie. Z zainstalowanymi skillami agent komentował każdy krok i mniej zgadywał; bez nich oddawał tylko raport końcowy. Zadawał też lepsze pytania. Zanim zamienił typy ścian, zapytał, czym jest każde pomieszczenie: czy rdzenie są żelbetowe, czy dok dostaw to droga? Jeden z modelerów powiedział to, co myśleliśmy wszyscy: podobało mu się, że pyta.

Jak zbudowaliśmy je na podstawie modelu referencyjnego

Żadnego skilla nie pisaliśmy od zera: każdy zaczynał jako sesja robocza. Modeler otwierał model referencyjny obok pliku roboczego, wykonywał zadanie z agentem, a potem prosił Claude'a o utworzenie skilla z tej sesji i wgranie go do organizacji. Z pierwszych dni wyszły dwie zasady:

• Buduj skill z całej rozmowy, nie z raportu końcowego. Raport to tylko wynik. Rozumowanie i poprawki są w czacie.
• Skill uruchamiający działania nie może się różnić między projektami. Tam, gdzie model referencyjny nie pokazuje jasnej reguły, skill każe agentowi zapytać, żeby decydował człowiek.

Dla wykończeń podłóg agent utworzył w Revicie legendę kolorów przez serwer MCP, po tym jak powstrzymaliśmy go przed pisaniem skryptów pyRevit z pamięci. Kiedy skill do ścian został przepisany, nową wersję wgraliśmy z przyrostkiem „V2”, żeby jej opis nie kolidował ze starym. Od tego zaczęło się porządkowanie.

Porządki, które poszły źle

Spora część pierwszego tygodnia to kontrola wersji, czyli dopilnowanie, żeby wszyscy używali tego samego skilla.

• Kopie organizacyjne i osobiste. Jedna z modelerek wciąż dostawała starą logikę ścian po jej usunięciu, bo kopia trafiła do jej osobistych skilli. Usunęliśmy kopie osobiste.
• Nieaktualne wersje. Dwa skille do ścian z podobnymi opisami „użyj, gdy” pozwoliły agentowi wybrać stary. Duplikaty zmieniają to, co robi agent.
• Przeładowanie. Nowa wersja zaczyna działać dopiero po zamknięciu Claude Code i ponownym załadowaniu skilli. Kto o tym zapomni, testuje wczorajszą logikę.
• Uprawnienia administratora. Zastąpienie skilla organizacji wymaga uprawnień administratora lub właściciela, których autorzy z początku nie mieli.
• Instalacja domyślna. Zaznaczenie jej przy publikacji sprawia, że jedna osoba nie widzi skilla, który widzi druga.

Nic z tego nie jest skomplikowane. Wszystko jest niewidoczne, dopóki dwie osoby nie dostaną różnych wyników z tego samego promptu.

Sufity tuż pod stropem piętra wyżej

Projekty referencyjne kolorują pomieszczenia filtrami widoków, które czytają elementy, a nie tylko parametry. Dlatego skill do sufitów wstawia sufit referencyjny około 1 cm pod stropem wyższej kondygnacji wszędzie tam, gdzie pomieszczenie go wymaga, i pomija go tam, gdzie pomija go wzorzec, na przykład w galerii (gantry) z kratą odwadniającą. Pierwsza reakcja naszego information managera była taka, że modelowanie sufitu, którego nie ma, to nie jest BIM. Zmienił zdanie, gdy zobaczył, że filtry sterowane elementami to sprytniejsze rozwiązanie. Na razie przydaje się to do filtrów i do niczego więcej.

Sufity w korytarzach leżały pod stropem i znikały, dopóki nie ustawiliśmy zakresu widoku jako nieograniczonego u góry, z offsetem. Rdzenie schodów i wind wychodziły szare zamiast zielonych, bo strop wyżej nie miał otworu, a skill robi sufity, nie otwory. Na razie rdzenie schodów nie dostają sufitu.

Modelerka testująca skill wybierała opcję „zalecaną” prawie za każdym razem; jego autor powiedział, że sam postąpiłby tak w około 90 procentach przypadków. Jej komentarz był najbardziej użyteczny: nie pisała skilla, więc nazwy typów nic jej nie mówiły. Skill musi działać dla kogoś, kto nie zna jeszcze odpowiedzi.

Sześćdziesiąt ścian i typ siedmiowarstwowy

Prompt był krótki: na podstawie pomieszczeń wprowadź typy ścian, zamień je na rzucie i ustaw filtry. Agent zamienił 60 ścian automatycznie i wrócił z prośbami o akceptację. Ściany zewnętrzne przy rdzeniu i galerii: nie zmieniać. Korytarz chłodzenia: akceptuj typ 105. Dwanaście ścian elewacji, sześć ścian galerii i cztery ściany podstacji: bez zmian. Ściany między dwoma pomieszczeniami pomocniczymi: akceptuj 104. Wystarczały odpowiedzi jednym słowem.

Potem pojawiły się problemy:

• Słupy. Zmieniły kolor razem ze ścianami, bo w rodzinie słupa było włączone „automatyczne łączenie”. Cofnęliśmy zmianę, przeładowaliśmy rodzinę bez tej opcji i pokolorowaliśmy od nowa.
• Długie ściany. Jedna zmieniła typ na całej długości, bo agent nie potrafi przeciąć ściany.
• Ręczne poprawki. Dwa razy modeler poprawił ścianę ręcznie, a agent cofnął to przy kolejnym przejściu.
• Warstwy. Nowe typy miały właściwe nazwy, kody i grubości, ale warstwy i materiały skopiowane z typów źródłowych. Skill nie miał katalogu układów warstw; jego autor wypracował warstwy w swojej sesji i nigdy ich nie zapisał.

Wersja 2 je dodała, a czerwony typ ściany przeszedł ze wszystkimi siedmioma warstwami i z prefiksem indeksu klienta zamiast prefiksu z wzorca.

Budynek z linku Speckle, dwa razy

Pierwsza próba była ambitna, duży krok od prostej ramy. Modeler dał agentowi link Speckle do geometrii koncepcyjnej, PDF z planem zagospodarowania terenu i skill orkiestrujący, po czym pozwolił mu pracować bez nadzoru przez około dwie godziny. Agent utworzył konstrukcję w rodzinach systemowych, a potem rozpoznał agregaty prądotwórcze i szafy rack po nazwach. Poproszony o pracę w tle, zapisał plik Revita do folderu przy zamkniętym Revicie. Przebieg zużył całe pięciogodzinne okno limitu użycia, a po nim trzeba było czekać dwie godziny. PDF i geometria ze Speckle w kilku miejscach się różniły i nigdy nie ustaliliśmy, na którym z nich agent się oparł.

Odbudowa pod nadzorem była wolniejsza i bardziej pouczająca. Speckle nie przeniósł parametrów z Rhino ani żadnych innych metadanych, więc agent czytał nazwy i zgadywał. Część elementów to były bryły-pudełka nazwane jak pomieszczenia, na przykład „biuro”, które obrysował ścianami, zostawiając szczeliny i jedną podwójną ścianę. Zaproponował wyprostowanie ścian lekko odchylonych od osi, co było naprawdę przydatne. Ale po walce ze ścianami jedna po drugiej nasz information manager doszedł do wniosku, że ostatnie ściany mogły być szybsze do narysowania ręcznie. Źródłem był szkic, a szkic nie ma wzorca, który dałoby się powtórzyć.

Pomieszczenia: nie pozwól mu zgadywać

Pomieszczenia najlepiej pokazały problem powtarzalności. Przy ponownym uruchomieniu skill zadał pytania o pomieszczenia, których za pierwszym razem nie zadał. Jedno, którego nie potrafił zidentyfikować, okazało się przestrzenią dachową.

Rozwiązaniem są wskazówki, nie swoboda. Pomieszczenia biorą nazwy ze źródła Speckle. Tam, gdzie nazwy nie ma, pomieszczenie jest „nieokreślone”, nigdy z wymyśloną etykietą, a wskazówki trafiają na rzut jako tekst, który agent może odczytać. Gdy nadal nie potrafi rozstrzygnąć, pyta. Jak ujął to jeden z modelerów: agent nie czyta, tylko zgaduje, chyba że da mu się coś do czytania.

• Testuj nowe skille na czystym kontekście, na komputerze innej osoby. Claude autora pamięta model referencyjny, więc przechodzi testy, których nowy użytkownik by nie przeszedł.
• Podawaj prawdziwą geometrię, nie zrzuty ekranu. Kilka liczb kosztuje mniej kontekstu niż obraz, a PDF wygrywa ze zrzutem z przeglądarki.
• Projekt referencyjny wygrywa z promptem. Z modelem referencyjnym otwartym w tej samej sesji Revita agent znalazł dziewięć typów drzwi i wziął reguły z modelu, a nie ze skilla. To nas ugryzło: kopia modelu referencyjnego była bardzo stara, więc wybrał złe drzwi. Utrzymuj modele referencyjne aktualne, a nazwy rodzin identyczne przy każdym uruchomieniu.
• Nadzorowany MCP do zmian w projekcie, generowanie w tle tylko dla rodzin do załadowania. Wszystko, co zmieniałoby model projektu, dzieje się na żywo, pod okiem człowieka.
• Komentowanie kroków i akceptacje to zalety, nie przeszkody. Dzięki nim wyłapiesz cofniętą ręczną poprawkę. Długie przebiegi bez nadzoru wymagają automatycznej akceptacji, której nie chcemy na modelu projektu.
• Powtarzalność jest miarą. Skill, który za drugim razem odpowiada inaczej, nadal jest demem.
• Ostrożnie z poleceniem „wykonaj kod Revita”. W trybie pełnej mocy, ze wszystkimi możliwościami włączonymi, serwer uruchamia dowolny kod i wykonuje polecenia dosłownie, także to, czego nie miało się na myśli. Agent pyta i kończy checklistą, Ctrl-Z działa do czasu, aż ktoś zapisze i zsynchronizuje model, a agent widzi tylko plik otwarty na komputerze modelera. Serwer tworzy społeczność, więc jego dodatek do Revita i lokalny most to także kwestia bezpieczeństwa danych, a uprawnienia wymagają starannej konfiguracji; więcej w artykule MCP w Revicie. Nasz information manager wolałby, żeby agent pisał kod pyRevit, a każdą zmianę zatwierdzano w Revicie.

Powinno się to zmieścić na jednej stronie BEP, którą agent odczyta równie łatwo jak człowiek. Nazwy modeli w ACC składają się z numeru projektu, kodu klienta, kodu budynku (DC01), ZZ w polu poziomu, pola typu modelu, branży (A dla architektury), a na końcu przyrostka dla terenu (ST) lub kontekstu (CX). Praca w toku leży w podfolderze „01 WIP”. Stałe nazewnictwo i szablony utrzymują spójność dokumentów i pozwalają użyć skilli na następnym projekcie.

Synchronizacja ze Speckle jest teraz automatyczna: w integracji Speckle z ACC łączysz konto, wybierasz zespół i projekt, zaznaczasz modele i tworzysz synchronizację, a Speckle od tej pory pobiera nowe wersje. Dashboardy Speckle klienta zależą od parametrów referencyjnych, które zapisują nasze skille. Otwartym ryzykiem są współrzędne: powiązane modele kontekstu i masterplanu mogą ich nie współdzielić.

Pod koniec dziesięciu dni usiedliśmy do rozmowy z założycielem klienta i zewnętrznym studiem programistycznym.

Wizja klienta to nie automatyzacja projektowania. Masterplanning pozostaje po stronie człowieka, a test fity nie są celem. Celem jest produkcja i detalowanie, od projektu definitywnego do wykonawczego, najpierw w architekturze: rysunki, typy ścian, zestawienia drzwi, tak żeby pięciu czy sześciu doświadczonych specjalistów, którzy ponoszą odpowiedzialność, mogło pracować szybciej. Wspierać seniorów, a nie ich zastępować.

Plan ma trzy kroki. Po pierwsze, instrukcja: codzienne procesy, które przez dwa, trzy tygodnie spisywaliśmy jako checklisty, a przez tydzień jako skille, zamienione w opis pisany, który jest też czytelny dla maszyny. Deweloper ze studia zaproponował, żeby dać LLM całą instrukcję i pozwolić mu przeprowadzać wywiady z ludźmi rozdział po rozdziale; założyciel wątpił, że wywiady zadziałają, i wolałby nagrywać spotkania i porządkować powtarzające się problemy. Po drugie, integracje AI: konektory między narzędziami. Po trzecie, interfejs, który obniża architektom próg wejścia do AI. Instrukcja ma się sama przepisywać w miarę postępu prac.

Najważniejszą dla BIM managera uwagę wniósł założyciel: w ciągu dwudziestu lat każdy projekt badawczo-rozwojowy, jaki widział w biurze architektonicznym, zakończył się porażką, a przyjęło się wyłącznie to, co codziennie testowano na żywym projekcie.

Pojawiła się też ekonomia tokenów. Wbudowana funkcja AI na platformie sprzedaje dostęp do modelu drożej niż bezpośrednie połączenie przez narzędzia AI do kodowania, takie jak Claude Code, które pozwalają też wybrać model AI. Ponieważ MCP jest otwartym protokołem, można zmienić dostawcę AI bez odbudowy połączenia z Revitem. Rozważaliśmy lokalną stację roboczą z lokalnymi modelami i nieograniczoną liczbą tokenów. Nie kupiliśmy jej: działa na Linuksie i nie uruchomi Revita.

• Przeciąć ściany i umieścić drzwi. Skill do drzwi zamienia istniejące drzwi na podstawie kontekstu pomieszczeń; skoro w modelu nie było drzwi, nie miał do czego się odnieść. Skill do lokalizacji drzwi jest następny i spodziewamy się, że trafi w 80 do 90 procent przypadków.
• Znać układ warstw, którego nie dostał. Katalog warstw trzeba było wpisać do skilla. Otwory w stropach nie są jeszcze obsługiwane.
• Działać tanio. Jeden przebieg bez nadzoru zużył całe okno limitu użycia, a spodziewamy się, że tokeny będą drożeć, co jest kolejnym powodem do twardych standardów.

I najważniejsze ograniczenie: nie mamy zmierzonej oszczędności czasu. Jedna z modelerek powiedziała, że spędziła dwa dni na rozmowie z Claude'em bez otwierania Revita i czuła się, jakby oszukiwała. To jest odczucie, nie pomiar.

FAQ