Wprowadzenie: Kod nie dba o Twoje wibracje
Rzecz w tym z dużymi modelami językowymi i kodem jest taka: są zadziwiająco pewne siebie i całkowicie obojętne na to, czy Twój program się kompiluje. Claude Haiku 4.5 z przyjemnością napisze dla Ciebie skrypt w Pythonie, który rozwiąże Twój problem, plus dwa, które wymyśli dla sportu. Sztuczka – jedyna sztuczka, która ma znaczenie – polega na nauczeniu się, jak formułować zapytania do Claude Haiku 4.5 w celu dokładnego generowania kodu w sposób, który nie pozostawia miejsca na wibracje, a maksymalizuje przestrzeń dla prawdy. Nie chcesz prozy, która brzmi jak kod. Chcesz kodu, który działa jak kod. Jest różnica.
Ludzie traktują tworzenie zapytań jak mistyczną inkantację – wypowiedz odpowiednie słowa, a otrzymasz idealną aplikację. To myślenie typu cargo cult. Kod to umowa. Jeśli chcesz dokładności od Claude Haiku, musisz spisać umowę. „Zbuduj aplikację internetową” to nie jest umowa. „Wygeneruj punkt końcowy FastAPI w Pythonie 3.12, który akceptuje JSON, waliduje schemat za pomocą Pydantic v2 i zwraca 422 w przypadku błędów schematu z określonym formatem ładunku” to umowa. W ten sposób formułuje się zapytania do Claude Haiku 4.5 w celu dokładnego generowania kodu: ustalasz umowę.
Czym to jest (a czym nie jest)
- To instrukcja obsługi dotycząca uzyskiwania niezawodnego, testowalnego kodu z Claude Haiku 4.5.
- To nie jest kazanie o „AI zastępującym programistów”. Narzędzia nie zastępują myślenia.
- Koncentruje się na praktycznych zapytaniach, strukturze i zabezpieczeniach: nudnych częściach, które sprawiają, że magia działa.
Jeśli chcesz kodu, który działa, musisz dać Claude działającą definicję „działa”. Jeśli chcesz dokładnego generowania kodu, musisz zdefiniować dokładność w prostych, testowalnych kategoriach. To cała gra.
Zdefiniuj dokładność jak prawnik, a nie jak poeta
„Dokładny” kod to nie kod, który „wygląda na prawdopodobny”. Dokładność to:
- Poprawność składniowa: kompiluje się lub uruchamia pod interpreterem.
- Wierność semantyczna: robi to, co mówi specyfikacja.
- Deterministyczne zachowanie: te same dane wejściowe, te same dane wyjściowe, w określonych granicach błędu.
- Poprawność wersji: używa odpowiednich zestawów SDK, wersji API i funkcji językowych.
Claude da ci to, o co poprosisz. Jeśli poprosisz o „funkcję, która sortuje listę”, prawdopodobnie ją dostaniesz. Jeśli poprosisz o „stabilne sortowanie w miejscu przy użyciu semantyki Timsort z dodatkową przestrzenią O(1)”, to jest to inna obietnica. „Jak formułować zapytania do Claude Haiku 4.5 w celu dokładnego generowania kodu” zaczyna się od wpisania tych obietnic w zapytanie.
Minimalne opłacalne zapytanie, ulepszone
Źle: „Napisz API Node dla zadań”.
Lepiej: „Napisz API Node 20 Express 4 z trasą /tasks POST, która waliduje pola {title: string, dueDate: ISO 8601} i odpowiada 201 z utworzonym obiektem lub 400 ze szczegółami błędu”.
Poprawnie: „Wygeneruj serwer Node 20 Express 4 z pojedynczym punktem końcowym /tasks POST. Wymagania: 1) Walidacja treści za pomocą [email protected]; 2) Pola: title (niepusty ciąg znaków, max 140), dueDate (data ISO 8601 w przyszłości); 3) W przypadku sukcesu: 201 z {id: ULID, title, dueDate}; 4) W przypadku nieprawidłowego: 400 z {error: 'VALIDATION', details: array}; 5) Brak bazy danych; Mapa w pamięci; 6) Dołącz plik testowy Jest 29 obejmujący prawidłowe, nieprawidłowe (pusty tytuł, data w przeszłości); 7) Udostępnij skrypty npm do testowania i programowania; 8) Użyj ESM; 9) Nie dodawaj zbędnych komentarzy”. Zwróć uwagę na kształt: wersja języka, biblioteki, ograniczenia, dane wyjściowe, błędy, testy, a nawet struktura pakietu. Usunąłeś niejednoznaczność. Zadaniem Claude jest wypełnienie kodu, a nie wymagań.
Wzorzec rusztowania: System, Specyfikacja, Testy, a następnie Kod
Jeśli chcesz dokładnego generowania kodu z Claude Haiku 4.5, musisz dać mu pas startowy:
- Systemowe ramy (krótka smycz)
- Ty: „Piszesz kod TypeScript w jakości produkcyjnej dla Node 20. Wyprowadzaj tylko bloki kodu z nazwami plików i nic więcej”.
- Dlaczego: Kontrolujesz ton i format wyjściowy. Nie zostawiaj tego przypadkowi.
- Dołącz wersje języków, wybór pakietów, semantykę błędów, formaty I/O, limity wydajności i ograniczenia bezpieczeństwa.
- Powiedz Claude, aby najpierw napisał testy jednostkowe. Testy definiują „dokładny” lepiej niż przymiotniki. Jeśli linia kodu nie służy testowi, jest dekoracyjna.
- Dopiero po testach. Tak, to w zasadzie TDD, ale z robotem, któremu nigdy nie nudzi się pisanie boilerplate.
- Instrukcje dotyczące ponownych uruchomień
- „Jeśli testy nie powiodą się lub importy nie pasują, zaktualizuj tylko te części, które się nie powiodły. Nie przepisuj całego projektu”.
Claude radzi sobie dobrze, gdy ma kontekst i szyny. Daj mu szyny.
Przypinanie wersji nie jest opcjonalne
Dane treningowe Claude są pełne starych i nowych dokumentów. To uprzejmy sposób na powiedzenie, że widział wiele sprzecznych porad. „Użyj React Router” jest niejasne. „Użyj [email protected] z routerami danych” to kierunek. Nie ufaj ustawieniom domyślnym: - Języki: przypnij do Pythona 3.12, Node 20, Go 1.22, Java 21 – cokolwiek faktycznie uruchamiasz.
- Frameworki: określ dokładne wersje główne i wszelkie flagi powodujące zmiany powodujące niezgodność.
- Zestawy SDK w chmurze: przypnij wersje; aws-sdk v2 vs v3 ma znaczenie.
- Lintery/formatery: określ reguły, aby uniknąć przepisania „styl ping-pong”.
Jeśli nie przypniesz, otrzymasz składankę największych hitów z pięciu lat postów na blogu. Dokładne generowanie kodu jest uczulone na nostalgię.
Najpierw schemat, zawsze
Nie pytaj o struktury „profilu użytkownika”. Zdefiniuj schematy w zapytaniu i wymagaj walidacji:
- Schemat JSON lub typy Zod/Yup w JS/TS
- Modele Pydantic w Pythonie
- Protobuf lub Avro dla usług
Następnie spraw, aby Claude wymuszał schematy na granicach – dane wejściowe API, zapisy do bazy danych i kolejki komunikatów. Poproś o jawne ładunki błędów i kody. Dokładność kocha schematy. Niejednoznaczność nie.
Uczyń to obserwowalnym lub nie udawaj, że to prawdziwe
Powiedz Claude, aby dodał logowanie, metryki i ślady tam, gdzie ich potrzebujesz – i aby zachował je w ciszy tam, gdzie ich nie potrzebujesz. Dobre zapytanie obejmuje:
- Polityka logowania: poziomy, redakcja PII, struktura (proszę o logi JSON)
- Metryki: czas na żądanie, liczba błędów
- Punkty końcowe stanu: /healthz, które udowadniają, że zależności działają
Claude doda to, o co poprosisz. Jeśli nie poprosisz, otrzymasz instrukcje drukowania – jeśli będziesz miał szczęście.
Zapytania typu „najpierw testy” są lepsze niż „po prostu mi zaufaj”
Dobrym sposobem na formułowanie zapytań do Claude Haiku 4.5 w celu dokładnego generowania kodu jest uczynienie testów źródłem prawdy. Przykład:
„Napisz testy pytest dla funkcji normalize_email(s), która:
- zamienia na małe litery części lokalne i domenowe;
- usuwa kropki w części lokalnej tylko dla gmail.com;
- usuwa subadresy (+tag) tylko dla gmail.com;
- odrzuca dane wejściowe bez pojedynczego @ lub z spacjami;
- zachowuje punycode domeny unicode tak, jak jest.
Obejmij przypadki brzegowe. Po napisaniu testów zaimplementuj funkcję, aby je zaliczyć.”
Claude często pisze lepszy kod, gdy jest zmuszony do spełnienia opisanych testów. Jeśli tego nie robi, masz konkretną porażkę, a nie argument o wibracjach.
Brak halucynacji przez konstrukcję
Nie możesz wyeliminować halucynacji, ale możesz je ogrodzić:
- Proś o cytaty lub adresy URL źródła tylko wtedy, gdy źródła istnieją. W przypadku metod SDK wymagaj linków do dokumentów i wymagaj, aby kod pasował do tych dokumentów.
- W przypadku prywatnych API wklej specyfikację w zapytaniu. Nie oczekuj, że Claude zna Twoje wewnętrzne punkty końcowe.
- W przypadku bibliotek z mylącymi API dołącz przykładowy fragment z oficjalnych dokumentów i powiedz Claude, aby się go trzymał.
Dokładny kod to głównie dokładne odniesienia. Daj Claude odniesienia.
Przewodniki po stylu: Najmniej seksowna, najbardziej przydatna rzecz
Claude pisze kod w dowolnym stylu, jaki wywnioskuje. To przepis na zmiany. Wklej swój przewodnik po stylu. Określ:
- Formatowanie (Prettier, Black, gofmt default)
Wymagaj również krótkiego komentarza uzasadniającego nietrywialne wybory. Przyszły Ty podziękuje Ci za to, a obecny Claude wyprodukuje mniej PR-ów „poprawek”.
Długie zapytania, krótkie dane wyjściowe
Inny sposób myślenia o tym, jak formułować zapytania do Claude Haiku 4.5 w celu dokładnego generowania kodu: poświęć słowa na zapytanie, a nie na dane wyjściowe. Chcesz:
- Wyczerpujące ograniczenia w zapytaniu
- Minimalne zbędne narracje w danych wyjściowych
Powiedz mu, aby pominął wyjaśnienia i zwracał tylko bloki kodu z nazwami plików i krótkim plikiem README. Jeśli chcesz komentarza, poproś o niego w osobnym uruchomieniu. Przeplatanie prozy i kodu to sposób, w jaki błędy wślizgują się w monoklu i cylindrze.
Udoskonalanie: Ścisła pętla, która faktycznie działa
Najszybsza ścieżka do niezawodnego kodu to nie „zrób to dobrze za pierwszym razem”. To krótkie, korekcyjne pętle:
- Uruchom lokalnie. Wklej nieudane dane wyjściowe testów i błędy kompilatora z powrotem do Claude verbatim.
- Poinstruuj: „Zmodyfikuj tylko minimalną liczbę wierszy; nie zmieniaj sygnatur funkcji, chyba że wymagają tego nieudane testy”.
- Powtarzaj, aż będzie zielono.
Claude doskonale radzi sobie z aplikowaniem diffów, gdy powiesz mu dokładnie, co się zepsuło. Nie parafrazuj dzienników błędów. Wklej je. Dzienniki to prawda.
Bezpieczeństwo jest funkcją, a nie postscriptum
Ponieważ modele są szkolone na publicznym kodzie (dobrym, złym i przeklętym), chcesz, aby bezpieczeństwo było wymogiem pierwszej klasy:
- Jawnie zabroń eval, shell=True i SQL o typie stringly-typed
- Wymagaj parametryzowanych zapytań, ochrony CSRF i ograniczania szybkości
- Poproś o przypinanie zależności plus plik blokady
- Wymagaj obsługi wpisów tajnych za pomocą zmiennych środowiskowych lub menedżera wpisów tajnych
Zapytanie bezpieczne domyślnie daje bezpieczniejszy kod. Zapytanie „załatam to później” daje nagłówki.
Wydajność: Powiedz, co oznacza „szybko”
„Uczyń to szybkim” tłumaczy się na „rób, co chcesz”. Zamiast tego określ metryki:
- Docelowe wartości opóźnień (p95 < 50 ms dla operacji w pamięci, p95 < 300 ms dla operacji DB)
- Limity pamięci (RSS < 150 MB)
- Złożoność czasowa (musi być O(n log n), a nie O(n^2))
Claude wybierze algorytmy pasujące do ustawionego budżetu. Daj mu budżet.
Dokumentacja: Wystarczająca, aby wdrożyć obcego
Poproś Claude o plik README, który zawiera:
- Instrukcje konfiguracji z dokładnymi wersjami
- Polecenia do testowania, lintowania, sprawdzania typów, uruchamiania
- Przykładowe żądania/odpowiedzi
- Ograniczenia i znane kompromisy
„Dokładny kod” zawiera dokładną dokumentację. Są częścią dostarczanego produktu.
Konkretne szablony zapytań, które możesz ukraść
Szablon: Punkt końcowy backendu
System: Jesteś skrupulatnym inżynierem Pythona 3.12. Wyprowadzaj tylko bloki kodu z nazwami plików.
Użytkownik:
- Zbuduj aplikację FastAPI 0.111 z punktem końcowym POST /convert.
- Żądanie: {amount: Decimal as string, from: 'USD'|'EUR', to: same}.
- Waliduj za pomocą pydantic v2; zwróć kształt 422 w przypadku błędów schematu.
- Użyj czystej funkcji convert(amount, from, to) ze stałymi stawkami {USD:1, EUR:1.1}.
- Zwróć {amount: string, currency: string} z 200.
- Dołącz testy pytest obejmujące prawidłowe, nieprawidłowe (zły ułamek dziesiętny, nieznany kod) i brzegowe (0).
- Udostępnij pyproject.toml z przypiętymi zależnościami; dołącz konfiguracje ruff i mypy.
- Brak połączeń sieciowych, brak komentarzy.
Szablon: Narzędzie CLI
System: Piszesz w Go 1.22. Wyprowadzaj tylko bloki kodu z nazwami plików.
Użytkownik:
- Utwórz CLI o nazwie slugify, który odczytuje stdin i drukuje adresy URL-safe slug.
- Zasady: małe litery, tylko ASCII, separatory myślnikowe, zwijanie białych znaków, usuwanie znaków interpunkcyjnych.
- Udostępnij main.go i slugify_test.go z testami tabeli.
- Dołącz Makefile z testami i celami kompilacji.
Szablon: Komponent frontendowy
System: Jesteś pragmatycznym inżynierem React, którego celem jest React 18 + TypeScript.
Użytkownik:
- Zaimplementuj komponent <DebouncedInput>.
- Props: value: string, onChange(value): void, delay=300.
- Użyj useRef/useEffect; brak haczyków stron trzecich.
- Dołącz testy vitest z fałszywymi licznikami czasu.
- Udostępnij minimalną historię Storybook.
Te szablony pokazują, jak formułować zapytania do Claude Haiku 4.5 w celu dokładnego generowania kodu przez przypinanie wersji, definiowanie zachowania i wymaganie testów.
Odmowa bycia sprytnym: Kiedy powiedzieć „Nie optymalizuj”
Jeśli nie chcesz przedwczesnych mikrooptymalizacji (a nie chcesz), powiedz to:
- „Preferuj czytelność nad spryt; brak bit-twiddling, chyba że wymagają tego testy”.
- „Brak rekurencji, jeśli iteracyjne jest wyraźniejsze”.
- „Brak metaprogramowania; jawne > niejawne”.
Claude uwielbia imponować. Nie pozwól mu na to. Spraw, aby przeszedł testy i był czytelny. To wystarczająco imponujące.
Sider.AI w przepływie pracy, gdzie faktycznie pomaga Widziałem, jak ludzie żonglują zapytaniami w losowych zakładkach czatu, jakby to był rytuał produktywności. Użyj obszaru roboczego, który rozumie kontekst kodu. Sider.AI, na przykład, jest zbudowany wokół utrzymywania specyfikacji, kodu, diffów i dzienników testów w widoku, więc pętla „wklej błąd, popraw linię” jest naprawdę ścisła. To nie jest magia; to nudne rusztowanie, które zapobiega zgubieniu wątku. Jeśli twoje narzędzie utrzymuje umowę, testy i kod w tej samej konwersacji – bez denerwowania cię konfetti – użyj go. Sider to robi. Jak debugować z Claude jako kolegą z zespołu, a nie wyrocznią
- Wklej nieudane dane wyjściowe testów dokładnie tak, jak są. Nie podsumowuj.
- Poproś o diff: „Odpowiedz tylko z ujednoliconym diffem w stosunku do pliku X”.
- W przypadku błędów w czasie wykonywania dodaj najmniejszy odtwarzalny fragment i zażądaj wyjaśnienia oraz poprawki.
- W przypadku błędów biblioteki wklej fragment dokumentu, który Twoim zdaniem ma zastosowanie, i zapytaj: „Czy to jest poprawne API dla wersji X? Jeśli nie, zaktualizuj kod i podaj prawidłowy fragment”.
Celem jest zmuszenie Claude do argumentowania dowodami. Ty przynosisz dowody.
Parada pułapek (i jak ich unikać)
- Pułapka „najnowszego” API: Nie mów „użyj najnowszego”. Powiedz „użyj wersji X.Y” i trzymaj się jej.
- Pusty plik testowy: Jeśli nie zażądasz testów, nie otrzymasz ich.
- Błąd jednorazowego strzału: Zaplanuj dwa lub trzy krótkie udoskonalenia. Jest to szybsze niż jedno rozdęte zapytanie.
- Niejednoznaczna polityka błędów: Zdefiniuj kody stanu i ładunki. „Zwróć błąd” nic nie znaczy.
- Niezarządzana zależność: Jeśli kod opiera się na usłudze, której nie możesz kontrolować, zatrzymaj ją. Poproś o podróbki.
Twoja lista kontrolna zapytań (Przyklej to w pobliżu monitora)
- Przypięta wersja języka i środowiska uruchomieniowego
- Przypięte wersje bibliotek
- Zdefiniowane schematy danych
- Zdefiniowana semantyka błędów (kody, kształty)
- Najpierw testy, potem kod
- Jawne ograniczenia bezpieczeństwa
- Określone budżety wydajności
- Określony styl i struktura
- Ograniczony format wyjściowy (nazwy plików, bloki kodu, diffy)
- Krótka pętla udoskonalania z wklejonymi dziennikami
Jeśli trafisz we wszystkie dziesięć, Claude Haiku 4.5 generalnie produkuje dokładne generowanie kodu, które przetrwa światło dzienne.
Przepracowany przykład: Od niejasnego do zweryfikowanego
Niejasne zapytanie: „Napisz funkcję bezpiecznego parsowania CSV”.
Wynik: Prawdopodobnie w porządku, prawdopodobnie źle, z pewnością nietestowany.
Precyzyjne zapytanie:
„Piszesz w Pythonie 3.12. Wyprowadzaj tylko bloki kodu z nazwami plików.
Utwórz csvsafe/init.py i csvsafe/reader.py z funkcją read_rows(path: Path) -> list[dict[str,str]]. Wymagania: użyj csv.DictReader z newline='' i encoding='utf-8'; zabroń bajtów null; odrzucaj pliki >10MB; ogranicz kolumny do 100; usuń BOM; traktuj puste komórki jako puste ciągi znaków; zgłaszaj ValueError z kodami komunikatów {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS}. Dołącz testy w tests/test_reader.py z pytest obejmujące happy path, bajt null, plik 11MB, 101 kolumn i obsługę BOM. Udostępnij pyproject.toml z przypiętymi zależnościami i czarną konfiguracją.”
Otrzymasz kod, testy i obsługę krawędzi. Następnie uruchamiasz testy, wklejasz niepowodzenia i iterujesz z minimalnymi dyferencjami. To jest dokładne generowanie kodu w praktyce.
O „Kreatywności” i innych słowach marketingowych
Nie potrzebuję „kreatywnego” kodu. Potrzebuję poprawnego kodu. Zachowaj kreatywność na nazywanie swojego kota. Podczas formułowania zapytań do Claude, kreatywność jest naturalnym produktem ubocznym solidnych ograniczeń. Właściwe testy i jasne specyfikacje prowadzą do eleganckich rozwiązań. Niewłaściwe zapytanie powoduje „odkrycie na nowo base64 z emoji”. Nie kuś go.
Nietajna tajemnica
Sposobem na formułowanie zapytań do Claude Haiku 4.5 w celu dokładnego generowania kodu jest nudny: zapisz to, czego potrzebujesz, przypnij wersje, zdefiniuj schematy, zażądaj testów i iteruj z rzeczywistymi porażkami. To wszystko. Bez mistycyzmu. Po prostu dyscyplina inżynierska, z modelem, który potrafi pisać bardzo szybko i nie ma nic przeciwko pisaniu piętnastu prawie identycznych przypadków testowych.
I to jest zwrot akcji: dokładność jest nieefektowna. Zapytania, które działają, brzmią jak lista kontrolna TSA. Kod, który jest wysyłany, brzmi, jakby został napisany przez człowieka, któremu zależało. Otrzymujesz oba, traktując model jak młodszego inżyniera, który rozwija się pod wpływem jasnych wymagań i więdnie pod wpływem niejasnych wskazówek. Daj mu umowę. Spraw, aby przeszedł testy. Wtedy, być może, możesz mu zaufać – z takim zaufaniem, jakim obdarzasz narzędzie, a nie proroka.
Podsumowanie: Mniej czarów, więcej gwarancji
Jeśli chcesz czarów, idź na pokaz magiczny. Jeśli chcesz oprogramowania, które się kompiluje i zachowuje, pisz zapytania, które działają jak gwarancje. Sposób formułowania zapytań do Claude Haiku 4.5 w celu dokładnego generowania kodu nie polega na kwiecistych sformułowaniach ani tajnych słowach kluczowych. Chodzi o ograniczenia, testy, wersje i pętle sprzężenia zwrotnego. Zrób te cztery rzeczy, a otrzymasz kod, który działa. Pomiń je, a otrzymasz pięknie sformatowaną fikcję.
Kod nie przejmuje się twoją aurą. Na szczęście testy też nie.
FAQ
P1: Jaki jest najprostszy sposób, aby skłonić Claude Haiku 4.5 do dokładnego generowania kodu?
Traktuj to jak umowę: przypinaj wersje, definiuj schematy, określaj formaty błędów i najpierw wymagaj testów. Im jaśniejsze ograniczenia, tym dokładniejszy kod.
P2: Jak zredukować halucynacje, gdy Claude pisze kod?
Wklej autorytatywne dokumenty lub specyfikacje i zażądaj ścisłego przestrzegania tych konkretnych API. W przypadku prywatnych endpointów dołącz własną specyfikację — nie oczekuj, że zgadnie.
P3: Czy powinienem prosić Claude'a o testy, czy pisać je sam?
Poproś Claude'a o wygenerowanie testów jako pierwsze, a następnie zaimplementuj kod, aby je spełnić. Testy definiują dokładność lepiej niż przymiotniki i utrzymują model w uczciwości.
P4: Jak szczegółowe powinno być przypinanie wersji w promptach?
Bardzo szczegółowe: środowisko uruchomieniowe języka, wersja główna/podrzędna frameworka i wersje SDK. „Najnowsza” zachęca do sprzecznych wzorców; dokładność zależy od stabilnych celów.
P5: Jak Sider.AI wpisuje się w prompting dla dokładnego kodu?
Użyj Sider.AI, aby przechowywać specyfikacje, kod, diffy i logi testów w jednej pętli. To nie magia — po prostu zachowuje kontekst, dzięki czemu poprawki Claude'a śledzą twoje rzeczywiste błędy. 
