Kilka dni temu, aby stworzyć jeden workflow treści, męczyłem się od popołudnia aż do trzeciej nad ranem.
Na początku byłem naprawdę podekscytowany.
Bo ostatnio wyszło wiele nowych Agentów, narzędzi AI do kodowania oraz różnych produktów 'zero-barierowej automatyzacji'.
Zawsze, gdy widzę reklamę, mam takie wrażenie:
W końcu nie będę musiał samodzielnie męczyć się z workflow, prawda?
Kiedy zaczynamy naprawdę używać,
Znowu wraca znajomy proces.
Najpierw wybieramy model.
Claude lepiej radzi sobie z dłuższymi tekstami.
Gemini ma całkiem niezłe zrozumienie niektórych rzeczy.
Codex jest lepszy do zadań związanych z kodowaniem.
A potem zaczynamy zmieniać prompt.
Jedno zdanie to za mało.
Kontynuuj dostosowywanie struktury.
dodaj warunki ograniczające.
zmień formę wyrażenia.
podziel kroki.
uzupełnij kontekst.
potem znów zaczynam badać:
umiejętności,
MCP,
wywołania narzędzi,
Środowisko uruchomieniowe,
kompozycja workflow.
Kiedy wszystko zadziała, nagle zrozumiałem:
Czas spędzony na „pracy”,
Może jeszcze nie spędziłeś tyle czasu na „sprawieniu, by AI działało poprawnie”.
A prawdziwym problemem jest:
Teraz różnice w AI,
To już nie jest „czy potrafisz używać”.
A chodzi o to:
➡️ Czy potrafisz pisać prompt?
➡️ Czy potrafisz korzystać z Claude Code / Codex?
➡️ Czy potrafisz zestawić workflow?
➡️ Czy umiesz skonfigurować MCP?
➡️ Czy potrafisz łączyć modele i narzędzia?
Każda nowa umiejętność,
co stawia dodatkową poprzeczkę.
to to samo narzędzie.
Niektórzy kończą zadanie w 20 minut.
Niektórzy marnują 2 godziny i nadal nie mogą uruchomić.
Niektórzy otrzymują wyniki zgodne z własnym workflow.
Niektórzy zawsze otrzymują tylko uniwersalne odpowiedzi.
Niektórzy czują się coraz bardziej swobodnie w używaniu.
Niektórzy czują się coraz bardziej zmęczeni.
Wiele osób myśli, że problem AI to:
„Model nie jest wystarczająco mądry.”
Jednak po głębszym użyciu zauważysz:
Teraz to, co naprawdę obciąża ludzi,
W rzeczywistości to ukryte koszty operacyjne stojące za AI.
Musisz zbadać:
który model pasuje do jakiego zadania
Który łańcuch narzędzi jest bardziej stabilny?
Jak zredukować iluzje?
Jak robić weryfikację wyników?
Jak kontrolować koszty wykonania?
Jak ponownie wykorzystać workflow?
Nawet wiele zespołów już zaczęło pisać wewnętrzne podręczniki operacyjne AI.
Ale problem polega na tym:
Za każdym razem, gdy model jest aktualizowany,
Wiele doświadczenia trzeba będzie uczyć się od nowa.
W ciągu ostatniego roku zmieniłem niezliczoną ilość narzędzi.
stworzyłem wiele workflow.
testowałem niezliczone prompt.
próbowałem wielu Agentów AI Coding.
Czasami nawet zaczynam wątpić:
czy to AI pomaga mi w pracy,
czy to ja pomagam AI w pracy?
Właśnie dlatego, kiedy ostatnio zobaczyłem, że lider w dziedzinie intencji dappOS @dappOS_com wprowadza własny produkt AI xBubble, pomyślałem, że ich punkt wejścia jest dość wyjątkowy.
To nie jest tylko chęć stworzenia „mądrzejszego AI”.
A chodzi o to, aby rozwiązać inny problem:
Czy można sprawić, że użytkownicy nie muszą badać skomplikowanych promptów, workflow, kombinacji modeli, a mogą przy użyciu bardzo prostego inputu, dostarczyć stosunkowo stabilne wyniki w konkretnych zadaniach?
Jest tu jeden kluczowy punkt:
Klucz do niskich promptów (Low-prompt),
To nie znaczy, że AI lepiej rozumie użytkownika.
A chodzi o to:
System już wcześniej się nauczył,
Jak to zadanie powinno być wykonane?
xBubble zawiera dwa kluczowe elementy.
jednym jest Bubble Pilot.
drugim jest Bubble Engine.
W moim zrozumieniu:
Bubble Pilot bardziej przypomina warstwę dystrybucji zadań.
Użytkownik musi tylko wpisać prostą prośbę.
Na przykład:
„Pomóż mi uporządkować materiały badawcze i wygenerować artykuł gotowy do publikacji.”
System najpierw identyfikuje typ zadania.
a następnie kierować zadania do odpowiednich ścieżek wykonania.
Jeśli w systemie już istnieje dojrzałe rozwiązanie,
Po prostu wchodzi w już zweryfikowany proces wykonania.
Najważniejsze tutaj jest to, że xBubble proponuje koncepcję SOP.
Ale ten SOP,
to nie są zwykłe szablony prompt.
To bardziej przypomina:
Już wcześniej przeszkolony plan wykonania zadania.
Nie tylko zawiera prompt.
zawiera również:
Wybór modelu,
umiejętności,
Środowisko uruchomieniowe,
MCP,
wywołania narzędzi,
kombinacje usług zewnętrznych itd.
W pewnym sensie,
dojrzały SOP,
to już bardzo zbliżone do niezależnego produktu Agenta.
Różnica jest taka:
Kiedyś te rzeczy wymagały, aby użytkownik samodzielnie badał.
Teraz system wstępnie pomaga w treningu.
A rola Bubble Engine,
bardziej przypomina system uczenia się w tle.
Będzie dostosowane do konkretnego zadania:
Automatyczne generowanie różnych rozwiązań,
testowanie różnych kombinacji modeli,
testowanie różnych łańcuchów narzędzi,
testowanie różnych środowisk uruchomieniowych.
A następnie na podstawie:
jakość wyników,
stabilność,
koszty,
zakres zastosowania
Wybierz najlepszą ścieżkę.
Na koniec utrwalone jako SOP.
Ten proces naprawdę przypomina logikę wielu obecnych Agentów AI Coding.
Po prostu:
AI Coding bardziej przypomina jednorazowe generowanie kodu.
a xBubble bardziej przypomina generowanie:
„Możliwość ponownego użycia zdolności wykonawczych zadań.”
Oczywiście,
Ten wstępny trening sam w sobie nie jest tani.
a koszty nie są stabilne.
ponieważ system wymaga ciągłego testowania różnych kombinacji,
Weryfikacja, czy wyniki są stabilne.
Ale gdy tylko jakiś SOP zostanie ukończony,
Wiele podobnych zadań,
Koszty dalszego wykonania będą szybko maleć.
Podczas ponownego uruchamiania,
Zbliży się do poziomu zużycia zwykłego Agenta.
Więc z perspektywy operacyjnej,
System również będzie bardziej skłonny do agregowania użytkowników o podobnych potrzebach.
Ponieważ im bardziej podobne potrzeby,
Wartość ponownego użycia SOP rośnie.
a te szczególnie wyjątkowe,
Szczególnie dostosowane zadania,
może wymagać osobnego wygenerowania nowego SOP,
odpowiednie koszty również będą wyższe.
Myślę, że ten kierunek jest naprawdę interesujący.
Ponieważ zaczyna sprawiać, że AI przechodzi od:
„Za każdym razem przemyśleć problem”
Powoli staje się:
„Ciągłe osadzanie zdolności do zadań”.
Kiedyś:
użytkownicy sami badają workflow.
Teraz:
System wcześniej bada workflow.
Kiedyś:
Użytkownicy sami dostosowują prompt.
Teraz:
System wstępnie trenuje ścieżki wykonania.
Kiedyś:
użytkownicy sami łączą modele i narzędzia.
Teraz:
System automatycznie realizuje harmonogram.
Co użytkownik naprawdę musi zrobić,
Została tylko jedna rzecz:
Opisać cel.
Jest jeden aspekt, który szczególnie mnie interesuje, to dwa środowiska uruchomieniowe xBubble.
Bubble Computer bardziej przypomina pełną przestrzeń roboczą projektu.
Gdy system wykryje złożone zadanie,
automatycznie uruchomi odpowiednie środowisko,
załaduj potrzebne zdolności,
przetwarzając pośrednie kroki.
badania, pisanie, projektowanie, weryfikacja,
Wszystko można wykonać w jednej sesji.
Drugim jest Bubble Personal.
Jest bardziej zorientowane na współpracę w lokalnym środowisku.
możliwość operowania plikami,
przeglądarka,
aplikacje,
Harmonogramy i inne lokalne zasoby.
Wiele operacji na poziomie systemu będzie wykonywanych w chmurze.
Po zakończeniu zadania automatycznie się destruuje.
Użytkownik powinien wykonywać tylko jednoznacznie autoryzowane działania,
Nie wymaga skomplikowanej instalacji środowiska.
Ta koncepcja zasadniczo polega na tym, aby AI przestało być „narzędziem do czatowania”, a zaczęło być rzeczywiście systemem wykonującym zadania.
Zastanów się nad sceną z początku artykułu.
gdyby wtedy istniało xBubble.
Może nie muszę już ciągle zmieniać modeli,
zmień prompt,
tworzenie workflow,
badanie MCP.
może wystarczy jedno zdanie:
„Pomóż mi w tym zadaniu.”
Reszta,
zaufaj AI, aby się uczył,
samodzielnie wywołać,
sami optymalizują.
AI powinno uczyć się od AI.
AI powinno korzystać z AI.
Użytkownik musi tylko wyrazić cel.
Myślę, że przyszłość Low-prompt AI jest naprawdę ważna,
to nie jest po to, by AI wydawało się fajniejsze.
A chodzi o to:
Czy może ogarnąć coraz bardziej skomplikowany świat AI,
Znowu stanie się czymś, co mogą używać zwykli ludzie.