# email-design.md: brief marki dla agenta e-mailowego Kanoniczny adres URL: https://brew.new/pl/blog/email-design-md Autor: Thomas Park Opublikowano: 2026-06-15 Zaktualizowano: 2026-09-28 Kod szesnastkowy koloru mówi agentowi e-mailowemu, którego odcienia niebieskiego użyć. Nie mówi mu jednak, dlaczego marka umieszcza nad każdym nagłówkiem małą etykietę w kroju monospace ani dlaczego jej separatory to cienkie linie, a nie ramki. Na tym polegał problem z naszym pierwszym modelem marki w Brew. Zbieraliśmy mnóstwo wartości, a mimo to gubiliśmy szczegóły, dzięki którym marka była rozpoznawalna. ## Obiekt miał pole niemal na wszystko Na początku marka wyglądała jak dane strukturalne. Modelowaliśmy kolory, typografię, zasoby i obszerny zbiór właściwości stylu. Crawler wypełniał pola, a potem proces generowania składał je w kontekst dla agenta e-mailowego. Wynik mógł mieć właściwy kolor i krój pisma, a mimo to wyglądać generycznie. Każda nowa marka przynosiła szczegół, którego schemat nie przewidział. Mogliśmy dalej dodawać pola, ale bardziej przydatne było pytanie, jak projektant wyjaśniłby tę samą markę innej osobie. Projektant napisałby wytyczne. Dokładne wartości tam, gdzie mają znaczenie, przykłady tam, gdzie pomagają, i opis wyjaśniający decyzje pomiędzy nimi. Zmieniliśmy więc to, czego oczekujemy od agenta, który wyodrębnia markę. ## Dokument jest briefem Nazywamy go `email-design.md`. To edytowalny dokument w formacie Markdown, który opisuje, jak dana marka powinna wyglądać w e-mailach. Oto fikcyjny, skrócony przykład: ```markdown # Acme email design ## Voice Write for engineers who want the setup instructions first. Use short explanations and name the product action precisely. ## Signature details - Put a small monospace label above the main headline. - Use thin dividers between sections, without drop shadows. - Reserve the accent color for the primary action. - Use one product screenshot when it explains the task. ## Assets Use the approved logo URL from the asset list. Do not invent product images or customer logos. ``` Dokument może zawierać regułę w rodzaju „używaj koloru akcentu tylko na jednym elemencie w e-mailu” obok dokładnej wartości koloru. Daje to agentowi wskazówkę na przypadki, których nie przewidzieliśmy z osobna. ![Brew wyświetla edytowalny plik email-design.md obok rozmowy o marce.](/blog/email-design-md-editor.png) *Instrukcje marki są widoczne. Poprawka staje się częścią kolejnego briefu.* Markdown sprawdza się tu, bo ludzie mogą go czytać i edytować bez specjalnego formularza. Nagłówki nadają dokumentowi strukturę, a dodanie nowej reguły projektowej nie wymaga nowego pola w bazie danych. To praktyczny wybór formatu. Nie twierdzimy, że Markdown zawsze zużywa mniej tokenów niż JSON ani że każdy model był trenowany głównie na Markdownie. ## E-mail potrzebuje własnych wytycznych projektowych Strona internetowa i e-mail podlegają innym ograniczeniom renderowania. Obsługa czcionek, układu i trybu ciemnego różni się w zależności od programu pocztowego. Projekt, który dobrze wygląda w podglądzie w przeglądarce, i tak trzeba przetestować w skrzynce odbiorczej. Dlatego dokument marki zawiera wskazówki specyficzne dla e-maili: czcionki zastępcze, szerokości kontenerów, gotowe wzorce układów opartych na tabelach oraz rozwiązania dla jasnego i ciemnego tła. Te instrukcje pomagają agentowi podejmować właściwe decyzje, ale nie gwarantują identycznego wyświetlania w każdym programie pocztowym. Obrazy mają inne wymagania, dlatego Brew korzysta też z pliku `image-style.md` z wytycznymi dotyczącymi obrazów. Wyraźne rozdzielenie tych dwóch obszarów jest prostsze niż oczekiwanie, że jedna lista tokenów projektowych opisze każde medium. ## Zacznij od materiałów, którym już ufasz Działająca strona internetowa to przydatne źródło, ale nie zawsze rozstrzygające. Może zawierać starą kampanię albo eksperyment stylistyczny, z którego zespół marki już nie korzysta. Oprócz domeny Brew może korzystać z przesłanych wytycznych marki, logotypów, obrazów i innych materiałów referencyjnych. Gdy przesłane wytyczne marki są sprzeczne z wnioskami wyciągniętymi ze strony, to one mają pierwszeństwo. Przejrzyj powstały dokument, zwłaszcza tam, gdzie materiały źródłowe są niepełne lub niespójne. ![Formularz konfiguracji marki z polem na adres strony i miejscem na pliki pomocnicze.](/blog/email-design-md-ingest.png) *Domena i zatwierdzone pliki dostarczają procesowi wyodrębniania marki różnego rodzaju dowodów.* Jeśli kształt przycisku się nie zgadza, zmień instrukcję. Jeśli ton jest zbyt formalny, zastąp ogólnikowy przymiotnik przykładowym zdaniem. O takiej poprawce dużo łatwiej rozmawiać niż o wielkim obiekcie pełnym pól, których nikt nie chce edytować. ## Czego ta zmiana dowodzi, a czego nie Dokument umieszcza lokalizacje zatwierdzonych zasobów, nazwy produktów i decyzje projektowe bezpośrednio w kontekście generowania. Zmniejsza to liczbę luk, które model musiałby inaczej wypełniać domysłami. Nie eliminuje jednak błędnych wyników. W trakcie tej pracy zmieniliśmy też inne elementy agenta e-mailowego. Bez kontrolowanego porównania nie przypisywałbym ogólnej poprawy jakości samemu formatowi pliku. Mogę twierdzić coś węższego: brief marki łatwiej sprawdzić, poprawić i ponownie wykorzystać. Wygenerowany e-mail nadal wymaga sprawdzenia faktów i warstwy wizualnej. Porównaj twierdzenia z briefem, przetestuj linki i obejrzyj wynik w skrzynce odbiorczej. To przekazanie pracy opisuje [poradnik o briefowaniu agenta e-mailowego](/pl/blog/how-to-brief-an-email-agent). ## Ten sam kontekst mają podłączeni agenci [Serwer MCP Brew](/pl/mcp) jest już dostępny. Zgodny asystent może pracować z Brew za pomocą udokumentowanych narzędzi, korzystając z tego samego kontekstu marki co aplikacja. Połączenie wyjaśniają [ogłoszenie o MCP](/pl/blog/brew-mcp) i [dokumentacja konfiguracji](https://docs.brew.new/api-reference/mcp/overview). Podoba mi się, że instrukcje marki mają oczywiste miejsce. Gdy coś w e-mailu nie gra, możemy wskazać konkretne zdanie, zmienić je i spróbować ponownie. To bardziej przydatna rozmowa niż kolejna prośba do modelu: „zrób to bardziej w stylu marki”.