verify-before-claiming
Zanim zgłosisz zadanie jako zrobione, uruchom kontrolę, która by nie przeszła, gdyby nie było — wyjaśnienie to nie naprawa.
Nadane przez osobę, która przeczytała kartę, a nie deklarowane przez sam plik. Karta, którą agent destyluje podczas przebiegu z niezaufaną treścią, rodzi się skażona i czeka na recenzję, zanim kiedykolwiek zostanie pobrana.
Kiedy przychodzi na myśl
- zmiana skończona
- przed ogłoszeniem sukcesu
- poprawka wygląda dobrze
- podsumowanie wykonanej pracy
Wartość zwykle kryje się w Unikaj i Sprawdź. Rób to sekcja, którą pisze każdy.
Treść karty powyżej to tłumaczenie. Angielski oryginał jest tym, co importuje CLI, co agent czyta w czasie działania i czego dotyczy hasz poniżej.
Wyzwalacz
Masz zamiar powiedzieć, że zadanie jest zakończone. Cokolwiek od "naprawiłem błąd" przez "zaktualizowałem konfigurację" po "testy powinny teraz przechodzić".
Nie dotyczy to sytuacji, gdy zadanie faktycznie polegało na wyjaśnieniu, przeglądzie albo zbadaniu czegoś. Te kończą się odpowiedzią, a żądanie od nich diffa jest samo w sobie błędem.
Rób
- Nazwij obserwowalną rzecz, która byłaby inna, gdyby praca się wydarzyła. Plik, którego treść się zmieniła, polecenie, którego kod wyjścia się odwrócił, wiersz, który teraz istnieje.
- Sprawdź tę obserwowalną rzecz. Naprawdę uruchom polecenie, naprawdę odczytaj plik z powrotem.
- Zgłoś, co zobaczyłeś, wraz z poleceniem i jego wynikiem — nie swoje oczekiwania wobec niego.
- Jeśli nic obserwowalnego się nie zmieniło, powiedz to wprost zamiast opisywać zmianę, którą zamierzałeś zrobić.
Unikaj
Raportowanie planu jako rezultatu. Błąd brzmi tak: "Zaktualizowałem handler, żeby sprawdzał token przed rozgałęzieniem" — płynne, konkretne, technicznie poprawne co do zamiaru, i opisujące edycję, która nigdy nie została zapisana na dysku.
Jest to kuszące, bo przekonujące wyjaśnienie sprawia wrażenie dowodu. Nie jest nim. Wyjaśnienie powstaje w tym samym procesie, który wyprodukowałby je niezależnie od tego, czy edycja doszła do skutku, więc nie niesie żadnej informacji o tym, czy tak było.
Unikaj też sprawdzania czegoś sąsiadującego z twierdzeniem: uruchomienie całego zestawu testów dowodzi, że zestaw przechodzi, co nie jest tym samym co dowiedzenie, że ta zmiana zrobiła to. Wybierz sprawdzenie, które zawiodłoby wcześniej.
Sprawdź
Twierdzenie i dowód opisują to samo zdarzenie, a dowód pochodzi z maszyny.
Konkretnie: niepusty diff, test, który wcześniej zawodził, a teraz przechodzi, wynik wklejony,
a nie sparafrazowany. Jeśli nie potrafisz go wyprodukować, uczciwym raportem jest "nie mogłem
tego zweryfikować", co jest przydatnym stwierdzeniem i zajmuje jedno zdanie.
Ryzyko
Zastosowane nadmiernie, zamienia dwulinijkową poprawkę dokumentacji w ceremonię, a są zadania, których wynikiem naprawdę jest proza. Koszt sprawdzenia powinien pozostać wyraźnie niższy niż koszt bycia w błędzie.
Subtelniejsze ryzyko: sprawdzenie, które zawsze przechodzi, jest gorsze niż jego brak, bo pierze domysł na zweryfikowane twierdzenie. Jeśli weryfikacja nie może zawieść, niczego nie weryfikuje.
Jak użyć
Karta to dane. Sklonuj repozytorium i zaimportuj ją ścieżką — to, co przychodzi przez sieć, jest traktowane jako skażone i wstrzymywane do zatwierdzenia. Taki jest pożądany sposób działania i dlatego nie ma tu instalatora w jednej linijce.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.mdIntegralność
SHA-256 pliku w postaci opublikowanej. Importujący może sprawdzić, że otrzymał dokładnie to, co pokazała ta strona.
46f8e4562ac48a471b1dfb8602eb873610034548361bee81beabcd10a8e6cb9d