W projekcie własnej witryny wykorzystaliśmy recenzje Claude, Perplexity i Gemini do przeglądu ówczesnej wersji tekstów oferty — PL 1.2. Ten przykład dotyczy tamtego etapu prac. Następnie rekomendacje zestawiono z materiałem i potwierdzonym zakresem HumGu. Weryfikację prowadził asystent AI w rozmowie, na podstawie treści i ustaleń właściciela.
Poniżej pokazujemy konkretne decyzje: sugestię odrzuconą, doprecyzowanie przyjęte i zależność sprawdzoną w źródłach. To zapis wykonanej pracy nad kontentem, a nie wdrożenie systemu u klienta.
Zadanie i materiał
Przejrzeć 14 stron i modułów: ofertę, rozwiązania, agentów, Kapitułę, kontakt oraz przykłady. Celem było dopracowanie wartości biznesowej i czytelności, z zachowaniem rzeczywistego zakresu oferty.
Materiał wejściowy obejmował treści PL 1.2, ustalenia właściciela i kryteria oceny recenzji. Uzyskano trzy recenzje, a następnie trzy odpowiedzi na challenge — prośbę o obronę lub korektę zarzutów względem konkretnych fragmentów.
Kryteria decyzji
Czy zarzut dotyczy dostarczonego tekstu? Czy wskazana informacja rzeczywiście jest nieobecna? Czy poprawka zachowuje potwierdzony zakres? Czy nie dodaje nieustalonej funkcji, statusu lub wyniku biznesowego?
Decyzja 1 — odrzucić atrakcyjnie brzmiący status
Jedna z recenzji zaleciła zastąpienie statusu rozwoju „wersją operacyjną” lub „wdrożeniami pilotowymi”. Potwierdzona była dostępność konkretnych usług oraz dalszy rozwój rozwiązań, a nie wymienione statusy platform.
Sugestii nie wprowadzono. Zachowano osobno informację o dostępnej współpracy i rozwoju rozwiązania. Recenzent wycofał propozycję po challenge’u.
Decyzja 2 — doprecyzować przekazanie wyniku
Opis ECOS wskazywał diagnozę i projekt zasad, lecz można było jaśniej zapowiedzieć uzgodnienie formy wyniku.
„Zakres dokumentacji i sprawdzenia ustalamy przed rozpoczęciem.”
„Zakres dokumentacji, formę przekazania wyniku i sposób jego sprawdzenia ustalamy przed rozpoczęciem.”
Przyjęta poprawka wyjaśnia współpracę bez dodawania nieustalonego raportu, szablonu lub liczby stron.
Decyzja 3 — sprawdzić podstawę zależności
Jedna z ilustracji w kontencie dotyczyła fikcyjnego zapytania serwisowego. W recenzji pojawiła się propozycja uzależnienia terminu startu i okna obsługi od liczby lokalizacji. Materiały przykładu nie ustanawiały takiej reguły.
Zamiast dopisać tę zależność, pokazano to, co wynikało z katalogu: liczba lokalizacji zmienia dobór wariantu, a wariant wpływa na sposób wyceny. Termin i rodzaje urządzeń nadal wymagają potwierdzenia; zasada akceptacji handlowca pozostaje bez zmiany.
Rezultat
Po recenzjach wprowadzono 12 zapisanych doprecyzowań w 10 modułach, tworząc PL 1.3. Każde ma wskazany fragment przed zmianą, po zmianie i uzasadnienie. Zachowano pełną ofertę, tożsamości agentów i właściwy mandat Kapituły.
Pokazana wartość tej pracy to możliwość prześledzenia decyzji i powiązania zmiany z podstawą. Konkretne niepotwierdzone dopiski nie zostały zamienione w obietnice firmy.
Zakres tego przykładu
Pokazujemy kontrolę rekomendacji AI w rzeczywistym projekcie redakcyjnym. Nie mierzono oszczędności czasu pracy, kosztów lub konwersji. Przypadek nie jest dowodem integracji produkcyjnej, działania całego portfolio lub niezależnie potwierdzonej jakości wszystkich tekstów.
W twojej organizacji
W którym zadaniu rekomendacja AI powinna być sprawdzona względem źródeł i zasad przed wykorzystaniem? Opisz proces i wynik, którego potrzebujesz.