Punkt startowy
Zespół redakcyjny tworzył wielojęzyczne treści długie. Chcieli wsparcia AI w szkicowaniu i tłumaczeniu, ale odmówili dwóch rzeczy: nieprzejrzystego kosztu i publikowania bez nadzoru. Obie odmowy są rozsądne.
Brief brzmiał: dajcie nam narzędzia AI, które można audytować, które nie zaskakują pięciocyfrowym rachunkiem i które nigdy nie publikują niczego, co nie przeszło przez człowieka.
Dlaczego MCP, a nie bezpośrednie wywołania API
Bezpośrednie wywołania Anthropic albo OpenAI z kodu WordPress by zadziałały. Rozsmarowałyby też klucze po pluginach, rozproszyły koszt per feature i uczyniły audyt nierealnym.
MCP dało jedną granicę: instalacja WordPress redakcji rozmawia z jednym serwerem MCP, serwer MCP rozmawia z dostawcami modeli, a każde wywołanie narzędzia jest typowane, logowane i scoped.
Design narzędzi
Każde narzędzie było typowane przez Zod i nazwane akcją redakcyjną: suggest_outline, draft_section, translate_to_locale, evaluate_against_voice. Każde miało jasny input, output i deklarację efektów ubocznych.
Narzędzia tworzące treść nigdy nie zapisywały bezpośrednio do wp_posts. Zapisywały do kolejki draftów. Człowiek akceptował przed publikacją.
Kontrola kosztu w designie
Budżety per user, per tool i per dzień były egzekwowane na granicy MCP, nie przy wywołaniu API. Gdy user wyczerpał limit, kolejne wywołanie zwracało odpowiedź budget exhausted, a UI redakcji informował go o tym. Bez cichych przekroczeń.
Ta sama granica dawała raporty kosztu per locale, per klaster tematyczny i per narzędzie. Finanse miały jedną tablicę.
Przedziały wyników
Dokładne liczby są poufne. Publicznie: throughput redakcyjny poprawił się przy tłumaczeniach, czas do pierwszego draftu spadł przy długich briefach, a koszt mieścił się w uzgodnionym budżecie co miesiąc dzięki twardym limitom.
Lekcja: AI w redakcji działa, gdy granica jest typowana, a budżet egzekwowany, nie gdy prompt jest sprytny. Większość porażek AI w redakcji bierze się z granicy, nie z modelu.