Od zera do systemu AI w kwartał. Część 14: Pierwsze automatyzacje.

W części 13 zastąpiliśmy pierwszy abonament własnym rozwiązaniem. Zyskałeś kontrolę nad danymi. Ale wciąż AI działa tylko wtedy, gdy go o coś prosisz.

Teraz czas na zmianę charakteru współpracy.

Automatyzacja to sytuacja, w której pewna rzecz dzieje się sama, bez Twojego udziału. Bez klikania, bez otwierania aplikacji, bez przypominania sobie “aha, muszę to zrobić”. Coś się wydarzyło (przyszedł mail, minęła godzina, zmienił się plik), system zareagował, Ty dostajesz gotowy rezultat.

Brzmi jak luksus. W rzeczywistości to punkt, w którym system zaczyna naprawdę oszczędzać Ci czas. Dopóki wszystko wymaga polecenia, AI jest lepszym asystentem. Gdy zaczyna działać samodzielnie, jest pracownikiem.

W tym artykule pokażę, jak zbudować pierwszy prosty workflow (cały cykl automatyzacji jakiegoś procesu). Jeden konkretny przykład, od początku do końca. Żadnych obietnic o transformacji biznesu. Jeden mały efekt, który oszczędza pół godziny tygodniowo. Od tego zaczyna się każda większa automatyzacja.

Zastrzeżenie: to co opisuję w tym cyklu bazuje na moim stacku technologicznym, czyli macOS i Claude jako główny model językowy. Zasady i podejście działają na każdym systemie operacyjnym i z każdym modelem AI, ale konkretne kroki i skróty klawiszowe opisuję pod Maca. Jeśli pracujesz na Windows lub Linux, większość rzeczy zrobisz tak samo, ale powyższe systemy mogą się różnić detalami, które musisz dostosować.

Ważne: opisuję tu model uproszczony, czyli idealny obraz tego, jak działa ten fragment systemu. W praktyce mój obecny system ma więcej warstw, wyjątków i automatyzacji. Na potrzeby tego cyklu pokazuję wersję, którą najłatwiej zrozumieć i odtworzyć u siebie.

Co to jest workflow

Narzędzia do automatyzacji (n8n, Make, Zapier, Pipedream) operują na tym samym pomyśle. Workflow to łańcuch kroków. Każdy krok robi jedną rzecz.

Pierwszy krok to trigger. Coś, co uruchamia workflow. Przyszedł mail. Minęła 7:00. Pojawił się nowy plik w folderze. Ktoś wypełnił formularz.

Kolejne kroki to akcje. Czytasz dane z triggera, sprawdzasz coś, modyfikujesz, przesyłasz dalej. W jednym z kroków może być wywołanie AI. W innym zapis do pliku. W kolejnym wysłanie powiadomienia na Slacka czy inny komunikator.

Ostatni krok zwykle to gdzieś zapisujesz efekt. Plik w vault. Zadanie w systemie. Mail do Ciebie.

Całość trwa kilka sekund. Nie musisz tego doglądać. Dzieje się w tle.

Które narzędzie wybrać? Dla kogoś zaczynającego polecam n8n. Rozwija się szybko i ma dobrą dokumentację.

Jedna rzecz do wyjaśnienia od razu, bo łatwo się na niej naciąć. Darmowa jest wersja, którą hostujesz sam, bez limitu czasu. Wersja chmurowa ma okres próbny liczony w dniach, a po nim trzeba wybrać plan płatny — jeśli tego nie zrobisz, przestrzeń robocza zostaje usunięta. Workflow’y da się przedtem pobrać, ale zaplanuj to, zamiast odkrywać w dniu wygaśnięcia. Make i Zapier są prostsze na start i rozliczają się od liczby operacji, więc rachunek rośnie razem z wolumenem.

Mój setup to n8n self-hosted (gotowy obraz na zewnętrznym serwerze, działa 24/7, niezależnie od tego czy mój laptop jest włączony). Plus Make jako rezerwa dla integracji, których n8n jeszcze nie obsługuje natywnie. Jeśli automatyzacja ma odpalać się o 3:00 w nocy albo obsługiwać klientów w weekend, self-hosted rozwiązuje sprawę.

Dalej w tym artykule zakładam, że używasz n8n, ale zasady są te same dla każdego narzędzia.

Drobny disclaimer dla bardziej zaawansowanych: w nowszych wersjach n8n (od 1.40+) tryb “task runner” w węźle Code blokuje pewne pomocnicze funkcje (między innymi te do uwierzytelnionych zapytań HTTP). Jeśli zaczniesz pisać własny kod w workflow i zobaczysz błąd “not supported in the Code Node”, przerzuć tę logikę do węzła HTTP Request z wbudowanym credential. Code node zostaw na transformacje danych, nie na integracje API.

Zasada: zaczynasz od jednego bólu

Nie myśl o wielkich systemach. Myśl o jednej rzeczy, która Cię irytuje codziennie.

Kilka przykładów z listy, którą sam przepracowałem:

“Znowu zapomniałem przygotować się do spotkania.” Mail z potwierdzeniem spotkania przychodzi na dzień wcześniej. Dobrze byłoby dostać przygotowanie na godzinę przed. Trigger: wydarzenie w kalendarzu. Akcja: AI pisze brief z wiedzą o kliencie z pliku klienta. Wynik: dostajesz brief na godzinę przed spotkaniem.

“Muszę codziennie ręcznie zebrać dane z Analytics do raportu.” Trigger: 7:00 rano. Akcja: skrypt pobiera dane z API, AI je podsumowuje. Wynik: dostajesz jeden mail z dziennym podsumowaniem zamiast logować się do trzech paneli.

“Mail od klienta ląduje w skrzynce i szybko tonie.” Trigger: mail od konkretnego kontaktu. Akcja: AI czyta treść, wyciąga intencje, zapisuje jako zadanie w pliku projektu. Wynik: mail ląduje w systemie jako zadanie, nie w skrzynce.

Każdy z tych workflow’ów rozwiązuje jeden ból. Nie trzy. Nie pięć. Jeden.

To jest ważne. Budowanie “jednego systemu, który robi wszystko” kończy się frustracją. Budowanie dziesięciu małych workflow’ów, z których każdy robi jedną rzecz, kończy się działającym systemem.

Przykład: mail od klienta staje się zadaniem

Pokażę od początku do końca najprostszy workflow.

Problem: Mail od klienta z informacją “trzeba zaktualizować tekst na stronie o usłudze X” ląduje w skrzynce. Przeczytam, pomyślę “tak, zrobię to”, wrócę do pracy, zapomnę. Za dwa tygodnie klient pisze: “to co z tym tekstem?”

Rozwiązanie: Workflow, który przy przychodzącym mailu od klienta wyciąga intencję, zapisuje jako zadanie w pliku projektu, wysyła mi powiadomienie.

Kroki workflow:

Krok 1: trigger (Gmail). Słuchaj na maile od nadawców z konkretnej listy (moich klientów) albo z etykietą “klient”. Gdy przyjdzie nowy, uruchom workflow. To ustawisz w n8n w dwie minuty (węzeł Gmail Trigger, konfiguracja z tokenem).

Krok 2: filtr. Nie każdy mail jest prośbą o zadanie. Czasem to tylko potwierdzenie, podziękowanie, pytanie. Dodaj krok, który prosi AI o klasyfikację: czy ten mail zawiera prośbę o zrobienie czegoś, czy nie.

Polecenie w węźle AI:

Przeczytaj ten mail. Czy klient prosi mnie o wykonanie konkretnego zadania?
Odpowiedz tylko TAK lub NIE. Jeśli TAK, dodaj jedno zdanie opisujące zadanie.
Mail: {{mail.body}}

Jeśli odpowiedź to NIE, workflow się kończy. Żadnego szumu.

Krok 3: wyciągnięcie zadania. Jeśli TAK, kolejny krok AI wyciąga strukturę:

Z tego maila wyciągnij następujące informacje w formacie JSON:
- zadanie: jedno zdanie opisujące co klient prosi
- projekt: nazwa projektu lub "nieznany"
- termin: jeśli podany w mailu, w formacie YYYY-MM-DD, inaczej "nie podany"
- kontekst: trzy zdania wyjaśnienia dla mnie
Mail: {{mail.body}}

Krok 4: zapis do pliku projektu. Krok, który otwiera odpowiedni plik w TASKS/ i dopisuje zadanie jako checkbox:

- [ ] {{zadanie.zadanie}} [mail od {{mail.from}}, {{data}}]

Krok 5: powiadomienie. Wysyłasz sobie krótką wiadomość na Slack lub mail: “Nowe zadanie od [klient]: [treść]. Plik: [ścieżka].”

Cały workflow wykonuje się w trzy sekundy od momentu odebrania maila. Mail dalej ląduje w skrzynce (nie usuwasz, bo chcesz budować historię), ale zadanie jest już w systemie.

Budowa tego całego workflow w n8n zajmie osobie początkującej od trzech do sześciu godzin, zależnie od tego, ile razy trafi na coś, czego nie zna. Drugi podobny workflow zajmie godzinę. Dziesiąty piętnaście minut. Inwestycja czasu w pierwszy workflow jest duża, ale amortyzuje się na kolejnych.

Co automatyzować w pierwszej kolejności

Z moich obserwacji: najlepsi kandydaci do pierwszej automatyzacji mają trzy cechy.

Pierwsza: robisz to regularnie. Raz w tygodniu, codziennie, po każdym mailu. Bez regularności automatyzacja nie ma ROI. Zadanie, które robisz raz na kwartał, nie warto automatyzować.

Druga: reguły są proste. Jeśli X, to Y. Jeśli mail od klienta z konkretnej listy, zapisz zadanie. Jeśli data 7:00, wyślij raport. Proste reguły = przewidywalny workflow.

Trzecia: koszty błędu są niskie. Dopóki uczysz się automatyzacji, workflow może się pomylić. Mail może zostać błędnie zaklasyfikowany. Zadanie zostanie zapisane nie do tego projektu. W pierwszych automatyzacjach wybieraj te, w których błąd oznacza “muszę to zrobić ręcznie”, a nie “klient się obrazi”.

Z tego wynika jasna lista startowa:

Poranny briefing (dane z API + AI + mail do Ciebie)
Mail od klienta → zadanie w systemie
Nowy artykuł opublikowany → post w social media do zaakceptowania
Raport tygodniowy z danych + AI komentarz
Przygotowanie do spotkania na podstawie wiedzy o kliencie

Każdy z tych workflow’ów jest prosty, regularny i niski w koszcie błędu. Dobre pierwsze wybory.

Zasada: buduj generycznie, nie pod jeden przypadek

Mała pułapka, w którą sam wpadałem: budujesz workflow dla jednego konkretnego klienta albo projektu. Ścieżki, identyfikatory, formaty — wszystko zaszyte na sztywno w środku. Działa świetnie, dopóki nie pojawia się drugi klient albo drugi projekt z podobnym problemem. Wtedy zaczynasz kopiować workflow, podmieniać piętnaście miejsc i modlić się, żeby nic nie ominąć.

Lepsza praktyka: od pierwszego workflow myśl o nim tak, jakby miał kiedyś obsłużyć dziesięciu klientów. Wszystko, co jest specyficzne (identyfikator klienta, ścieżka do pliku, lista nadawców), wyciągnij do parametrów wejściowych albo do osobnego pliku konfiguracyjnego. Sam workflow zostaje generyczny.

W praktyce: jeden workflow, dziesięć configów. Klient A ma swój plik z listą nadawców, klient B swój. Workflow czyta jego konfigurację na starcie i wie, co robić. Nowy klient = nowy plik, nie nowy workflow.

To kosztuje może 20% więcej pracy przy pierwszym budowaniu. Oszczędza setki godzin przy dziesiątym wdrożeniu. Reguła brzmi: jeśli już teraz widzisz, że coś podobnego będziesz powtarzał, nie buduj ad-hoc. Buduj parametryzowalnie.

Czego nie automatyzować

Równie ważna jest lista tego, czego nie warto ruszać.

Decyzji jakościowych. Kogo zatrudnić, któremu klientowi powiedzieć nie, jak ustawić ceny. To są miejsca, gdzie AI może doradzać, ale decyzja jest Twoja i powinna być świadoma. Automatyzacja usuwa ten moment decyzyjny. Nie chcesz tego.

Komunikacji z ludźmi, którą ludzie zauważą. Automatyczne odpowiedzi na maile, automatyczne posty, automatyczne powitania nowych subskrybentów. Ludzie czują, że coś jest nie tak. Lepiej napisać krótszą, ale autentyczną wiadomość, niż długą automatyczną. To jest temat na inną rozmowę, ale krótko: automatyzuj wewnętrzne procesy, nie zewnętrzne relacje.

Rzeczy, które robisz rzadko. Raz w kwartale. Raz w roku. Budowanie workflow zajmuje kilka godzin. Ręczne zrobienie tego raz na kwartał, dziesięć minut. Rachunek jest prosty.

Rzeczy, które musisz widzieć. Księgowość, zobowiązania prawne, umowy. Tu chcesz być świadomy, że coś się dzieje. Automatyzacja odsuwa Cię od sytuacji. Zostaw ręczne.

Sekret: czytelność workflow’u

Po zbudowaniu kilku workflow’ów pojawia się nowy problem. Wracasz do tego, co zrobiłeś dwa miesiące temu, i nie rozumiesz, co tam się dzieje.

Dwie praktyki, które pomagają.

Pierwsza: nazwy. Każdy węzeł w n8n ma domyślną nazwę typu “HTTP Request” albo “OpenAI Chat”. Zmień ją na konkretną: “Pobierz dane z Analytics API”, “AI klasyfikuje mail jako zadanie / nie-zadanie”. Po miesiącu podziękujesz sobie za tę zmianę.

Druga: opis workflow’u. W n8n możesz dodać do każdego workflow notatkę. Wpisz tam trzy linie: co robi, co uruchamia, gdzie zapisuje wynik. Gdy wracasz po miesiącu, od razu wiesz, co masz przed oczami.

Trzy dodatkowe minuty na workflow. Ratuje godziny szukania, co się właściwie dzieje.

Bezpiecznik: testuj zanim puścisz, weryfikuj zanim zaufasz

To jest najważniejsza sekcja w całym artykule. U mnie przekuła się w prostą zasadę: nie wdrażaj produkcyjnie, jeśli nie zweryfikowałeś. Dotyczy każdego workflow’u, każdego skryptu, każdej zmiany, która operuje na danych.

Cykl wygląda tak:

Krok 1: zdefiniuj kryterium akceptacji. Co znaczy, że workflow “działa”? Konkretnie. Mail przychodzi, w pliku pojawia się checkbox z prawidłową treścią, do mnie idzie powiadomienie z linkiem. Jeśli któryś element nie wystąpi, test jest do powtórki.

Krok 2: test w izolacji. n8n pozwala uruchomić workflow jednym kliknięciem, nawet jeśli trigger to mail czy harmonogram. Wyślij sobie testowego maila i prześledź każdy węzeł. Co wchodzi, co wychodzi. AI klasyfikuje poprawnie? Plik trafia w dobre miejsce? Powiadomienie przychodzi?

Krok 3: pokaż dowód. Logi n8n pokazują, co dokładnie się wydarzyło. Zrób screenshot albo skopiuj wynik. To jest Twój dowód, że na razie działa zgodnie z założeniem.

Krok 4: weryfikuj, nie zakładaj. Najczęstszy błąd początkujących: workflow zwrócił “success” na końcu, więc zakładam, że wszystko poszło dobrze. Niekoniecznie. Pójdź do miejsca docelowego (plik w vault, zadanie w systemie, mail w skrzynce) i sprawdź, czy efekt naprawdę tam jest. Jeśli workflow miał coś zaktualizować, zrób GET po fakcie, porównaj z tym, co miało się stać.

Krok 5: włącz i obserwuj tydzień. Przez pierwszy tydzień patrz, co workflow zrobił. n8n ma logi każdego uruchomienia. Przejrzyj je raz dziennie. Wyłapiesz błędy klasyfikacji albo niespodziewane sytuacje, o których nie pomyślałeś.

Krok 6: popraw, zanim zapomnisz. Na podstawie tego, co zobaczyłeś, dopracuj prompt dla AI albo filtr wejścia. Kolejny tydzień obserwacji. Dopiero wtedy workflow trafia do trybu “zapomnij, że istnieje”.

Cały cykl zajmuje dwa tygodnie. Nie próbuj go skracać. Automatyzacja, która działa źle, jest gorsza od braku automatyzacji, bo daje fałszywe poczucie kontroli.

Drobna uwaga praktyczna: gdy workflow operuje na cudzej infrastrukturze (sklep klienta, panel klienta, jego arkusz), zanim zrobisz cokolwiek, zrób backup tego, co modyfikujesz. Pierwszy krok, nie ostatni. To uratowało mi kilka razy projekt, gdy “drobna automatyzacja” okazała się mniej drobna niż założyłem.

Czego unikać

Budowania workflow’u “na wszystkie możliwe przypadki”. Buduj dla 80% przypadków. Te 20% pozostałych obsłuż ręcznie na początku. Gdy zobaczysz wzorzec w tych wyjątkach, wtedy dopiero dopracuj workflow. Nie próbuj przewidzieć wszystkiego z głowy.

Bezpośredniego łączenia trigger-akcja bez walidacji. Między triggerem a akcją zawsze daj przynajmniej jeden krok sprawdzający, czy to w ogóle powinno się wydarzyć. To kosztuje trzy sekundy, ale ratuje Cię przed spamem, błędami i frustracją.

Używania AI jako routera bez testowania. AI może źle klasyfikować. Zwłaszcza w prostych przypadkach typu “ten mail to zadanie czy nie”. Daj testowy okres przed pełnym zaufaniem. Sprawdzaj pierwsze 30 decyzji.

Zapominania o alertach, gdy workflow pada. Automatyzacja, która pada po cichu, jest gorsza niż żadna. Skonfiguruj w n8n powiadomienie na Slack lub mail, gdy workflow kończy się błędem. Dowiesz się od razu, a nie za dwa tygodnie, gdy zadania nie przychodzą i nie wiesz dlaczego.

Czego nauczyłeś się na tym etapie?

Automatyzacja to workflow. Trigger (coś się wydarzyło) uruchamia łańcuch akcji, z których jedna może wywoływać AI. Efekt zapisuje się tam, gdzie Ci najbardziej odpowiada.

Zaczynaj od jednego bólu, nie od wielkiego systemu. Mały workflow, który rozwiązuje jeden problem, jest lepszy od jednego dużego, który próbuje rozwiązać wszystko.

Dobrzy kandydaci do pierwszej automatyzacji mają trzy cechy: robisz to regularnie, reguły są proste, koszt błędu jest niski.

Przykład: mail od klienta przez AI jest klasyfikowany jako zadanie, struktura jest wyciągana w JSON, zadanie zapisuje się w pliku projektu, Ty dostajesz powiadomienie.

Nie automatyzuj decyzji jakościowych, komunikacji z ludźmi, rzeczy rzadkich, ani rzeczy, które musisz świadomie widzieć.

Buduj generycznie, nie pod jeden przypadek. Wyciąganie tego, co specyficzne, do osobnego configu kosztuje 20% więcej przy pierwszym workflow, oszczędza setki godzin przy dziesiątym.

Dwie praktyki, które ratują przed chaosem: dobre nazwy węzłów i notatka opisująca workflow. Trzy minuty oszczędzają godziny po miesiącu.

Cykl testowania: kryterium akceptacji → test w izolacji → dowód → weryfikacja w miejscu docelowym (nie ufaj statusowi “success”) → tydzień obserwacji → poprawki. Dwa tygodnie. Bez skracania. Plus przy pracy na cudzej infrastrukturze: backup PIERWSZY krok.

W następnej części pokażę jak dać AI dostęp do Twoich narzędzi. Nie tylko pliki w vault, ale też mail, kalendarz, sklep, analytics. Gdy AI widzi Twoje systemy, odpowiedzi stają się naprawdę konkretne.

Twój następny krok: zadanie na dzisiaj

Dwie rzeczy.

1. Wybierz jeden ból do zautomatyzowania. Otwórz plik w vault i napisz trzy powtarzalne zadania, które robisz ręcznie co tydzień. Dla każdego zapisz: jak często, ile minut zajmuje, co by było, gdyby się działo samo. Wybierz jeden z trzech jako pierwszy cel automatyzacji. Zasady wyboru: regularnie, proste reguły, niski koszt błędu.

2. Zainstaluj narzędzie do workflow’ów. Polecam n8n. Dwie opcje: chmurowa (szybki start, ale po okresie próbnym trzeba wybrać plan płatny) albo hostowana samodzielnie na prostym serwerze (więcej pracy na początku, pełna kontrola, bez opłaty i bez terminu). Jeśli chcesz tylko obejrzeć interfejs i nie masz jeszcze pewności, czy to dla Ciebie, zacznij od chmury. Jeśli już wiesz, że zostajesz, od razu idź w self-hosted i nie przenoś tego potem. Stwórz pierwszy pusty workflow i zapoznaj się z interfejsem. Nie buduj nic jeszcze. Tylko kliknij po menu, obejrzyj listę dostępnych węzłów. Jutro wrócisz do budowania.

Zasoby

Oficjalna dokumentacja n8n i forum społeczności — lepszy punkt startu niż przypadkowe tutoriale. Gdy utkniesz na węźle albo na błędzie wykonania, zaczynaj tam. Na forum ludzie dzielą się gotowymi workflow’ami, więc czasem znajdziesz swój problem już rozwiązany.
Twoja własna lista bólów — przed każdym nowym workflow’em wracaj do niej. Nie buduj automatyzacji, bo “fajnie by było”. Buduj, bo masz konkretny ból do rozwiązania.

Ten artykuł jest częścią cyklu “Od zera do kompletnego systemu AI w kwartał”. Krok po kroku opisuję jak zbudowałem system AI do zarządzania firmą i rozwojem osobistym, żebyś mógł wdrożyć podobny u siebie. W następnej części: jak dać AI dostęp do Twoich narzędzi (mail, kalendarz, sklep, analytics) przez API. Masz pytania? Napisz. Odpowiadam osobiście.

Żeby nie przegapić kolejnych części, zaobserwuj mój profil. Nowe artykuły publikuję regularnie.

Marcin Atamańczuk, Technologia w służbie życia, nie odwrotnie.