06 - Inżynieria podpowiedzi dla IDE AI: pisanie skutecznych podpowiedzi
Istnieje wyraźna różnica pomiędzy programistą, który USA asystent kodowania AI i jeden to wie, jak się komunikować z tym. Pierwsza daje mierne rezultaty, wymaga wielu iteracji i kończy się ręcznym naprawianiem wygenerowanego kodu. Ten ostatni otrzymuje dokładne dane wyjściowe do pierwszego lub przy drugiej próbie przyspiesz przepływ pracy i zbuduj trwałe systemy instrukcji które z czasem się poprawiają. Różnica jest w tym wszystkim szybka inżynieria.
W kontekście kodowania wibracji zachęta to nie tylko dane wejściowe: to główny interfejs komunikacja między programistą a sztuczną inteligencją. Jakość podpowiedzi określa jakość kodu wygenerowanych błędów, trafność sugestii, głębokość analizy błędu i solidność refaktoryzacji. Jednak większość programistów używa improwizowanych, niejasnych i pustych podpowiedzi struktury, a potem narzeka na rezultaty.
W tym artykule omówiono inżynierię szybkiej realizacji jako dyscyplinę techniczną stosowaną w rozwoju
oprogramowanie: od anatomicznych podstaw skutecznego podpowiedzi po zaawansowane wzorce, takie jak łańcuch myśli
i meta-podpowiadania z konfiguracji plików systemowych (CLAUDE.md,
.cursorrules, .github/copilot-instructions.md) w wierszu polecenia łączenia
do skomplikowanych zadań. Z konkretnymi przykładami w TypeScript i Pythonie dla każdego scenariusza.
Czego się nauczysz
- Anatomia skutecznego podpowiedzi: kontekst, ograniczenia, wynik
- Podstawowe wzorce: zero-shot, kilka strzałów, łańcuch myśli, meta-podpowiadanie
- Jak skonfigurować CLAUDE.md, .cursorrules i copilot-instructions.md
- Porównanie podpowiedzi specyficznych dla kodu Claude'a, kursora i funkcji GitHub Copilot
- Skuteczne podpowiedzi dotyczące refaktoryzacji, debugowania i testowania na prawdziwych przykładach
- Szybkie łączenie w celu podzielenia złożonych zadań na łatwe do wykonania etapy
- Najczęstsze anty-wzorce i jak ich unikać
- Metryki mierzące jakość Twoich podpowiedzi
Anatomia skutecznej podpowiedzi
Skuteczna zachęta dla asystenta kodowania AI nie jest prostym zdaniem w języku naturalnym. Oraz strukturę informacji, która zapewnia AI dokładnie to, czego potrzebuje do wytworzenia jakość wyjściowa. Każdy skuteczny monit zawiera trzy kluczowe elementy: kontekst, ograniczenia e oczekiwany wynik.
1. Kontekst: Co sztuczna inteligencja wie o Twoim problemie
Kontekst jest najważniejszym i najczęściej pomijanym elementem. AI nie zna Twojego projektu, Twojej architektury, standardów kodu lub wymagań biznesowych. Bez kontekstu tworzy kod ogólny, który może działać abstrakcyjnie, ale nie w twoim konkretnym przypadku. Efektywny kontekst obejmuje:
- Stos technologii: język, framework, konkretne wersje
- Obecna architektura: użyte wzorce, struktura projektu
- Odpowiedni kod: funkcje, klasy, interfejsy związane z problemem
- Cel biznesowy: dlaczego wprowadzasz tę zmianę
- Aktualny stan: co działa, co nie działa, na czym polega dokładny problem
2. Ograniczenia: granice, w których można działać
Więzy definiują granice akceptowalnego rozwiązania. Bez ograniczeń sztuczna inteligencja może proponować rozwiązania, które są technicznie poprawne, ale niezgodne z Twoim kontekstem: biblioteki inne niż te zatwierdzone, architektury łamiące kompatybilność wsteczną, wzorce niezgodne ze standardami zespołu. Typowe ograniczenia obejmują:
- Biblioteki zatwierdzone lub zabronione
- Zgodność z określonymi wersjami Node, TypeScript, Python itp.
- Limity wydajności (złożoność algorytmiczna, rozmiar pakietu)
- Standardy zespołu (konwencje nazewnictwa, minimalny zakres testów)
- Ograniczenia bezpieczeństwa (brak ewaluacji, brak wstrzykiwania powłoki, sprawdzanie poprawności danych wejściowych)
3. Oczekiwany wynik: kształt wyniku
Określenie formatu wyjściowego jest niezbędne. Komunikat „Ulepsz dla mnie tę funkcję” może uzyskać odpowiedź tekstową, kod wbudowany, listę sugestii lub refaktoryzację kompletny. Określenie, czego chcesz, zmniejsza niejednoznaczność:
- Format: kod bezpośrednio, wyjaśnienie + kod, lista zmian
- Miotły: tylko funkcja, cały moduł, łącznie z testami
- Poziom szczegółowości: z komentarzami, z typami TypeScript, z obsługą błędów
- Następna akcja: zastosuj zmianę, pokaż różnicę, najpierw wyjaśnij, a następnie zaimplementuj
Zobaczmy różnicę między niejasną podpowiedzią a dobrze zorganizowaną podpowiedzią dotyczącą tego samego zadania:
# PROMPT VAGO - Risultato imprevedibile
"Migliora questa funzione di autenticazione"
# PROMPT STRUTTURATO - Risultato prevedibile
"""
Contesto:
- Stack: TypeScript 5.4, Node.js 22, Express 5, JWT
- Funzione di autenticazione attuale (vedi sotto)
- Architettura: Repository Pattern, servizi separati da controller
Problema:
La funzione validateToken lancia eccezioni non tipizzate e non gestisce
il refresh token scaduto. In prod abbiamo avuto 3 crash nelle ultime 24h.
Vincoli:
- Non cambiare l'interfaccia pubblica (backward compatibility)
- Usare solo librerie già nel package.json (jsonwebtoken, zod)
- Mantenere compatibilità con Node.js 20+
- Test coverage minima 80%
Output atteso:
1. Funzione validateToken refactored con error handling tipizzato
2. Tipi personalizzati per gli errori (AuthError con codici specifici)
3. Unit test con Jest per i casi di errore principali
Codice attuale:
async function validateToken(token: string) {
const decoded = jwt.verify(token, process.env.JWT_SECRET);
return decoded;
}
"""Jawna reguła kontekstu
Badania nad szybką inżynierią pokazują, że podanie kontekstu na początku i na końcu szybkie i znacznie skuteczniejsze niż umieszczenie go na środku. Modelka daje więcej wagę do informacji w pozycjach otwarcia i zamknięcia. W przypadku długich monitów powtórz najbardziej krytyczne ograniczenie na końcu ze sformułowaniem typu „Pamiętaj: nie zmieniaj interfejsu publiczna funkcja.”
Podstawowe wzorce szybkiej inżynierii
Szybkie wzorce inżynieryjne wynikają z badań akademickich dotyczących interakcji LLM, ale są one konkretnie stosowane w codziennej pracy z asystentem kodowania AI. Znajomość ich pozwala wybrać odpowiednie narzędzie do każdego rodzaju problemu.
Podpowiadanie o zerowym strzale
Najprostszy schemat: poproś sztuczną inteligencję o wykonanie zadania bez podawania przykładów. To działa dobrze dla standardowych i dobrze zdefiniowanych zadań, gdzie model ma dużą ilość danych szkoleniowych. I o to chodzi odejście od jakiejkolwiek interakcji.
# Zero-shot efficace: task standard con contesto minimo
"""
Crea un custom hook React in TypeScript per gestire richieste HTTP con:
- Stato di loading, data, error tipizzato con generics
- Cancellazione automatica con AbortController al unmount
- Retry automatico con backoff esponenziale (max 3 tentativi)
- Cache in-memory per evitare richieste duplicate entro 30 secondi
Usa React 18+ e TypeScript strict mode.
"""Podpowiadanie o kilku strzałach
Podaj przykłady wzorca, który chcesz odtworzyć. Szczególnie skuteczny przy zakładaniu konwencje nazewnictwa, struktury danych specyficzne dla projektu lub niestandardowe style kodu. Modelka „uczy się” wzoru z przykładów i stosuje go do nowego przypadku.
# Few-shot: stabilire il pattern di error handling del progetto
"""
Nel nostro progetto usiamo questo pattern per gli errori:
ESEMPIO 1 - Repository error:
class UserNotFoundError extends AppError {
constructor(userId: string) {
super(`User ${userId} not found`, 'USER_NOT_FOUND', 404);
}
}
ESEMPIO 2 - Validation error:
class InvalidEmailError extends AppError {
constructor(email: string) {
super(`Invalid email format: ${email}`, 'INVALID_EMAIL', 422);
}
}
ESEMPIO 3 - External service error:
class PaymentGatewayError extends AppError {
constructor(provider: string, details: string) {
super(`Payment failed via ${provider}: ${details}`, 'PAYMENT_FAILED', 502);
}
}
Seguendo esattamente questo pattern, crea gli errori per il modulo
di autenticazione: TokenExpiredError, InvalidCredentialsError,
AccountLockedError e SessionLimitExceededError.
"""Podpowiadanie w ramach łańcucha myśli (CoT).
Poproś sztuczną inteligencję, aby pomyślała krok po kroku przed podaniem ostatecznego kodu. To podejście i szczególnie skuteczny w przypadku złożonych problemów algorytmicznych, optymalizacji wydajności i debugowanie trudnych do znalezienia błędów. Badania ustrukturyzowanego łańcucha myślowego (SCoT). pokazuje poprawę dokładności zadań generowania kodu o 15,27% w porównaniu do podpowiedzi standardowe.
# Chain-of-thought: debugging di un problema di performance
"""
Ho una funzione Python che processa 50.000 record in ~40 secondi.
Devo portarla sotto i 2 secondi. Prima di scrivere codice, ragiona
passo per passo:
1. Analizza i colli di bottiglia nel codice attuale
2. Identifica le strutture dati subottimali
3. Valuta quali ottimizzazioni hanno il maggiore impatto
4. Solo dopo proponi l'implementazione ottimizzata
Codice attuale:
def find_duplicate_transactions(transactions: list[dict]) -> list[dict]:
duplicates = []
for i, t1 in enumerate(transactions):
for j, t2 in enumerate(transactions):
if i != j:
if (t1['amount'] == t2['amount'] and
t1['merchant'] == t2['merchant'] and
t1['date'] == t2['date']):
if t1 not in duplicates:
duplicates.append(t1)
return duplicates
Vincoli: Python 3.11+, nessuna libreria esterna oltre a quelle stdlib
"""Meta-podpowiadanie
Meta-podpowiadanie wykorzystuje sztuczną inteligencję do generowania lub ulepszania samych podpowiedzi. To zaawansowana technika szczególnie przydatne, gdy nie wiesz dokładnie, jak sformułować złożony problem i kiedy chcesz zoptymalizować istniejący monit. Sztuczna inteligencja staje się współpracownikiem w tworzeniu podpowiedzi.
# Meta-prompt: ottimizzare un prompt per generare API REST
"""
Questo e il prompt che ho scritto per generare un'API REST:
"Crea un'API per gestire ordini e-commerce in Node.js con TypeScript"
Analizza questo prompt e:
1. Identifica le informazioni mancanti che renderebbero il risultato più preciso
2. Suggerisci una versione migliorata del prompt con le informazioni necessarie
3. Spiega perchè ogni aggiunta migliora il risultato finale
Non generare ancora l'API: prima ottimizziamo il prompt insieme.
"""
# L'AI risponde con un prompt migliorato come:
"""
[Suggerimento AI]: Il prompt migliorato dovrebbe includere:
- Framework specifico (Express vs Fastify vs NestJS)
- Pattern architetturale (MVC, Clean Architecture, DDD)
- Database (PostgreSQL, MongoDB) e ORM (Prisma, TypeORM)
- Autenticazione (JWT, OAuth2, API Key)
- Endpoint specifici del dominio ordini
- Requisiti di validazione e error handling
- Standard API (REST, JSON:API, HAL)
...
"""Który wzór wybrać?
- Zerowy strzał: Standardowe, dobrze zdefiniowane zadania z jasnym słownictwem technicznym
- Kilka ujęć: Konwencje projektowe, niestandardowe wzory, specyficzne style
- Łańcuch myśli: Złożone błędy, optymalizacje, decyzje architektoniczne
- Meta-podpowiadanie: Gdy problem jest źle zdefiniowany, gdy chcesz ulepszyć podpowiedzi
Monity systemowe i trwałe pliki konfiguracyjne
Jednym z najczęstszych błędów w korzystaniu z asystentów kodowania AI jest konieczność powtarzania kontekstu projektu w każdej rozmowie. Nowoczesne narzędzia pozwalają na definiowanie trwałych instrukcji które są automatycznie dołączane do każdej sesji. Jest to poziom, na którym są one uzyskiwane największy długoterminowy wzrost produktywności.
CLAUDE.md: System operacyjny Claude Code
CLAUDE.md oraz plik konfiguracyjny czytany przez Claude'a Code na początku każdego z nich
sesja. Według analizy 328 publicznych plików CLAUDE.md, najczęstszymi kategoriami są:
Architektura (72,6%), Wytyczne rozwojowe (44,8%), Przegląd projektu (39,0%),
Testowanie (35,4%) i polecenia (33,2%). Dobry CLAUDE.md zmienia Claude'a z asystenta generalnego
ekspertem w Twoim konkretnym projekcie.
# CLAUDE.md - Portfolio Angular + API Node.js
## Panoramica Progetto
Portfolio professionale con blog, developer tools e API.
Frontend: Angular 21 + SSR. Backend: Node.js 22 + Express 5.
Deploy: Firebase Hosting (frontend) + Cloud Run (API).
## Stack Tecnologico
- **Frontend**: Angular 21 standalone components, TypeScript 5.4, Signals
- **Backend**: Node.js 22, Express 5, TypeScript, Prisma ORM
- **Database**: PostgreSQL 16 (prod), SQLite (dev)
- **Testing**: Jest (unit), Cypress (e2e)
- **Linting**: ESLint 9 + Prettier
## Architettura Frontend
- Standalone components (no NgModules)
- Signals per stato reattivo (no RxJS dove possibile)
- OnPush change detection su tutti i componenti
- Lazy loading per tutte le route
- CSS scoped ai componenti (no global styles tranne design system)
## Architettura Backend
- Clean Architecture: routes -> controllers -> services -> repositories
- Repository Pattern per l'accesso ai dati
- Error handling centralizzato con AppError e globalErrorHandler
- Validazione input con Zod su tutti gli endpoint
- JWT + refresh token per autenticazione
## Comandi Essenziali
```bash
# Frontend
npm start # dev server
npm run build # production build con SSR
npm test # unit tests
# Backend
npm run dev # dev con hot reload
npm run migrate # Prisma migrations
npm run seed # seed database
```
## Standard di Codice
- TypeScript strict mode: sempre
- No `any`: usare tipi espliciti o generics
- Funzioni: max 30 righe. File: max 400 righe.
- Nomi: kebab-case per file, PascalCase per classi, camelCase per variabili
- Import: absolute paths con @ alias, non path relativi oltre 2 livelli
## Regole di Sicurezza CRITICHE
- MAI hardcodare secrets o chiavi API
- Validare SEMPRE l'input con Zod prima di processarlo
- Usare SEMPRE query parametrizzate (Prisma gestisce questo)
- Rate limiting su tutti gli endpoint pubblici
- CORS configurato con allowlist esplicita
## Testing
- Coverage minima: 80% per servizi e repository
- Test: should + comportamento (es: "should return 404 when user not found")
- Mock: solo dipendenze esterne (DB, API), non logica interna
- E2E: critical user flows (auth, checkout, API key creation)
## Pitfalls Noti
- SSR: usare isPlatformBrowser() per API browser-only (localStorage, window)
- Angular templates: escapare { con {{ }} Angolare in ngNonBindable
- Prisma: usare transazioni per operazioni multi-step
- JWT: refresh token deve essere httpOnly cookie, non localStorage
## Cross-References
Vedi @docs/architecture.md per diagrammi
Vedi @docs/api-patterns.md per convenzioni REST
Vedi @.env.example per variabili d'ambiente richieste.cursorrules: Konfiguracja kursora
Kursor używa pliku .cursorrules w katalogu głównym projektu (lub w folderze
.cursor/rules/ aby uzyskać bardziej szczegółowe reguły), aby dostosować zachowanie
AI. Kursor obsługuje trzy typy reguł: Zawsze (dotyczy wszystkich
pliki), Zastosuj automatycznie (dotyczy plików pasujących do wzorca globu) e
Wybierz agenta (stosowane sporadycznie na żądanie).
# .cursorrules - TypeScript Angular Project
## Ruolo
Sei un senior Angular developer. Conosci questo progetto e segui
le sue convenzioni senza eccezioni. Quando generi codice, rispetta
sempre questi standard.
## TypeScript
- strict mode abilitato: no implicit any, no unused variables
- Preferisci `interface` a `type` per oggetti
- Usa generics invece di `any` per funzioni riutilizzabili
- Destructuring dove possibile
- Async/await invece di Promise chains
## Angular Specifico
- SOLO standalone components, mai NgModules
- Signals per stato locale e computed values
- `inject()` invece di constructor injection
- OnPush change detection obbligatoria
- `ngOptimizedImage` per tutte le immagini statiche
- Lazy loading su tutte le feature routes
## Stile CSS
- CSS custom properties (variabili del design system in styles.css)
- BEM naming per classi custom
- No stili inline negli HTML template
- Mobile-first con breakpoints: 768px (tablet), 1024px (desktop)
## Codice da NON Generare
- NgModules o forRoot/forChild patterns
- Class-based guards o resolvers (usa functional guards)
- RxJS per stato semplice (usa signals)
- setTimeout o setInterval (usa RxJS timer se necessario)
- document.querySelector (usa ViewChild o renderer)
## Formato Output
Quando generi un componente, includi sempre:
1. Il file .ts con il componente
2. Il file .html con il template
3. Il file .css se ci sono stili specifici
4. Un file .spec.ts con test minimi.github/copilot-instructions.md: Niestandardowe instrukcje dla Copilot
GitHub Copilot używa pliku .github/copilot-instructions.md po instrukcje
trwałe na poziomie repozytorium. Według GitHuba plik ten ma na celu „wbudowanie”
repozytorium agentowi Copilot, dostarczając informacje potrzebne do wydajnej pracy
od pierwszej interakcji. W sierpniu 2025 Copilot wprowadził automatyczne generowanie
niestandardowe instrukcje poprzez analizę struktury repozytorium.
# Copilot Custom Instructions
This is a TypeScript Node.js microservices project following Clean Architecture.
## Project Structure
- `src/domain/` - Business entities and domain logic (no framework dependencies)
- `src/application/` - Use cases and application services
- `src/infrastructure/` - Database, external APIs, repositories
- `src/presentation/` - HTTP controllers and routes
## Coding Standards
Always use TypeScript. Prefer `interface` over `type` for object shapes.
Use `Result<T, E>` pattern for error handling, never throw from business logic.
All public functions must have JSDoc with @param and @returns.
## Testing Requirements
Write Jest unit tests for all domain and application layer code.
Mock infrastructure dependencies. Target 85% coverage.
Test file naming: `*.spec.ts` co-located with source files.
## API Conventions
REST endpoints follow kebab-case: `/api/user-profiles` not `/api/userProfiles`.
All responses use the envelope: `{ data, error, meta }`.
HTTP status codes: 200 (success), 201 (created), 400 (validation),
401 (auth), 403 (authz), 404 (not found), 500 (server error).
## Security
Validate all input with Zod schemas at the presentation layer.
Never log sensitive data (passwords, tokens, PII).
Use parameterized queries via Prisma - never string concatenation.
## Dependencies
Approved: express, zod, prisma, jsonwebtoken, winston, jest
Restricted: lodash (use native JS), moment (use date-fns), axios (use fetch)
Forbidden: eval, vm, child_process (unless in dedicated worker)Gdzie umieścić trwałe instrukcje
| Narzędzia | Plik | Miotły |
|---|---|---|
| Claude'a Koda | CLAUDE.md (root) lub ~/.claude/CLAUDE.md |
Projekt lub globalnie |
| Kursor | .cursorrules o .cursor/rules/*.mdc |
Projekt lub typ pliku |
| Drugi pilot GitHuba | .github/copilot-instructions.md |
Repozytoria |
| Windsurfing | .windsurfrules |
Projekt |
| Wszystkie (standardowe) | .ai-instructions.md + import |
Narzędzie krzyżowe (z określonymi narzędziami, które je importują) |
Monity dotyczące określonych zadań: refaktoryzacja, debugowanie, testowanie
Każdy typ zadania programistycznego ma inną charakterystykę i wymaga uporządkowanych podpowiedzi inaczej. Zobaczmy optymalne struktury dla trzech najczęstszych zadań: refaktoryzacji, debugowanie i generowanie testów.
Monity o refaktoryzację
Dobry monit o refaktoryzację powinien określać kierunek zmian (w stronę jakiego wzorca lub zasady migrujesz), tj ograniczenia kompatybilności (czego nie wolno zmieniać) i kryterium sukcesu (skąd wiedzieć, że refaktoryzacja i powodzenie).
# Template: Prompt per Refactoring
"""
Task: Refactoring verso [PATTERN TARGET]
Codice attuale:
[INCOLLA IL CODICE DA REFACTORARE]
Motivazione:
[Spiega perchè stai facendo questo refactoring]
Es: "Questo servizio fa troppe cose. Violare SRP rende difficile il testing."
Direzione del refactoring:
[Descrivi il pattern o principio verso cui vuoi migrare]
Es: "Separare la logica di business dalla persistenza con Repository Pattern"
Vincoli CRITICI (non modificare):
- L'interfaccia pubblica del servizio UserService deve rimanere invariata
- I test esistenti devono continuare a passare
- Nessuna dipendenza nuova oltre a quelle nel package.json
Criteri di successo:
- UserService non importa più Prisma direttamente
- IUserRepository e un'interfaccia iniettabile
- UserRepository può essere mockato nei test senza Prisma
Output atteso:
1. UserRepository interfaccia (src/domain/repositories/IUserRepository.ts)
2. PrismaUserRepository implementazione (src/infrastructure/repositories/)
3. UserService aggiornato che usa l'interfaccia
4. Test aggiornati con mock del repository
"""Monit o debugowanie
Debugowanie to zadanie, w którym kontekst jest najważniejszy. Sztuczna inteligencja nie widziała katastrofy: musiała zrekonstruuj sytuację na podstawie podanych fragmentów. Skuteczny monit o debugowanie udostępnia pełny komunikat o błędzie, ślad stosu, odpowiedni kod i kontekst środowiskowy.
# Template: Prompt per Debugging
"""
Ambiente:
- Node.js 22.3.0, TypeScript 5.4, Express 5.0.1
- Database: PostgreSQL 16 via Prisma 5.14
- OS: Ubuntu 22.04 (prod), macOS 14 (dev) - bug in ENTRAMBI
Errore (messaggio completo):
TypeError: Cannot read properties of undefined (reading 'email')
at UserController.createUser (src/controllers/user.controller.ts:47:28)
at Layer.handle [as handle_request] (express/lib/router/layer.js:95:5)
at next (express/lib/router/route.js:149:13)
...
Codice dove avviene l'errore (user.controller.ts, righe 40-55):
[INCOLLA LE RIGHE RILEVANTI]
Dati in input (dal log di debug):
Request body: { "name": "Mario", "role": "admin" }
Request headers: { "content-type": "application/json", "x-api-key": "..." }
Cosa ho già provato:
1. Aggiunto console.log a riga 46: body.email e undefined
2. Controllato il middleware: body-parser e configurato correttamente
3. Testato con Postman con email presente: funziona
Ipotesi:
Il validatore Zod potrebbe non trasformare correttamente i valori opzionali?
Lo schema accetta email come optional ma il controller assume che ci sia sempre.
Chiedo:
1. Identifica la causa root del problema
2. Spiega perchè si manifesta solo quando email manca
3. Proponi la correzione
4. Suggerisci come prevenire errori simili in futuro
"""Monituj o wygenerowanie testu
Testy generowane przez sztuczną inteligencję są często zbyt powierzchowne, jeśli nie są odpowiednio prowadzone. Dobry monit o testowanie musi określać struktura, il rodzaj testu (jednostkowe, integracyjne, e2e), tj przypadki graniczne zakryć i poziom pokrycia oczekiwany.
# Template: Prompt per Test Generation
"""
Framework: Jest 29 + TypeScript. Testing library: @testing-library/react (se UI).
Tipo di test: Unit tests per la funzione seguente.
Funzione da testare:
export function calculateShippingCost(
orderValue: number,
destination: 'IT' | 'EU' | 'WORLD',
weight: number,
options: { express?: boolean; insurance?: boolean } = {}
): ShippingCost {
// implementazione...
}
Business rules (da testare obbligatoriamente):
- Spedizione gratuita per ordini > 50€ in IT, > 100€ in EU
- Express: +50% sul costo base
- Insurance: 2% del valore ordine, min 2€
- Peso massimo: 30kg, oltre lancia WeightLimitExceededError
- Destinazione WORLD: sempre a pagamento, no free shipping
Casi da coprire OBBLIGATORIAMENTE:
1. Happy path: tutti i tipi di destinazione
2. Spedizione gratuita: threshold esatti (49.99€ vs 50.00€ vs 50.01€)
3. Opzioni combinate: express + insurance insieme
4. Casi limite: peso 0, peso 30, peso 30.01 (errore atteso)
5. Valori negativi: orderValue negativo (validazione attesa)
6. Arrotondamento: verificare che i prezzi abbiano max 2 decimali
Formato test:
describe('calculateShippingCost', () => {
describe('[categoria]', () => {
it('should [comportamento] when [condizione]', () => {
// arrange - act - assert
});
});
});
Coverage attesa: 100% branch coverage sulla funzione.
"""Szybkie łączenie w przypadku złożonych zadań
Szybkie łączenie w łańcuchy to technika dzielenia złożonego zadania na sekwencję połączonych podzadań, w których wynik każdego kroku staje się wejściem do następnego. A szczególnie skuteczny, gdy pojedynczy długi monit daje niespójne lub niekompletne wyniki. Klucz i rozkład: Zidentyfikuj naturalne punkty rozdzielenia problemu.
Przykład: pełna funkcja z natychmiastowym łączeniem w łańcuch
Wyobraź sobie, że musisz wdrożyć system powiadomień e-mail z ograniczaniem szybkości, kolejką i ponawianiem prób. Pojedynczy monit dotyczący całej funkcji często powoduje powstanie niekompletnego kodu. Z łańcuchem:
# STEP 1: Design dell'architettura (nessun codice)
"""
Prima di scrivere codice, progetta l'architettura per un sistema
di notifiche email con queste caratteristiche:
- Rate limiting: max 100 email/ora per utente
- Queue persistente con Redis (Bullmq)
- Retry automatico con backoff esponenziale (max 3 volte)
- Template email con variabili
- Tracking: sent, failed, bounced, opened
Output atteso:
1. Diagramma testuale dei componenti e relazioni
2. Lista delle interfacce TypeScript (senza implementazione)
3. Schema del database per il tracking
4. Potenziali problemi e come li risolviamo
Non scrivere ancora codice: voglio validare l'architettura prima.
"""
# STEP 2: Interfacce e tipi (basato sull'output dello step 1)
"""
L'architettura approvata e quella che hai proposto nello step precedente.
Ora implementa SOLO le interfacce TypeScript:
- IEmailService con tutti i metodi
- IEmailTemplate con le variabili tipizzate
- INotificationJob per la queue
- IEmailTrackingEvent per gli eventi di tracking
- Tipi di errore specifici del dominio
Nessuna implementazione: solo interfacce e tipi.
File: src/domain/interfaces/email.interfaces.ts
"""
# STEP 3: Implementazione del core service
"""
Le interfacce sono definite. Implementa EmailService che implementa
IEmailService usando:
- nodemailer per l'invio
- Zod per validazione input
- Winston per logging
Assumi che IEmailTemplateRenderer e IEmailQueue esistano gia
come dipendenze iniettate. Usa i tipi definiti nello step 2.
Test: includi test unitari per i metodi send() e sendBulk()
mockando le dipendenze esterne.
"""
# STEP 4: Queue e rate limiting
"""
Implementa EmailQueue usando Bullmq che:
- Rispetti il rate limit di 100 email/ora per utente
- Implementi il retry con backoff: 1min, 5min, 15min
- Persista i job in Redis
- Emetta eventi per il tracking
Usa l'interfaccia IEmailQueue definita nello step 2.
Non reimplementare EmailService: usala come dipendenza.
"""
# STEP 5: Integrazione e test end-to-end
"""
Tutti i componenti sono implementati. Ora:
1. Crea il container DI che wires tutto insieme
2. Scrivi un test di integrazione che simula:
- 150 email in 1 ora (deve rispettare il rate limit)
- Un invio che fallisce 2 volte e riesce al 3° tentativo
- Un invio che esaurisce i retry e va in dead letter queue
3. Crea un README.md per il modulo con setup e usage examples
"""Zalety szybkiego łączenia łańcuchowego
- Szczegółowa kontrola: Obowiązuje każdy krok przed kontynuowaniem
- Zlokalizowane poprawki: jeśli krok jest błędny, popraw tylko ten
- Czysty kontekst: każdy krok ma precyzyjny i konkretny kontekst
- Bardziej niezawodne wyjście: Model koncentruje się na jednym problemie na raz
- Identyfikowalność: możesz rozpocząć od dowolnego etapu łańcucha
Warunkowe łączenie podpowiedzi
Łańcuch warunkowy wprowadza decyzje na podstawie wyników poprzednich kroków. I przydatne gdy dalsze działania zależą od wstępnej analizy sztucznej inteligencji.
# STEP 1: Analisi preliminare
"""
Analizza questa funzione Python e classifica i problemi trovati
in tre categorie:
- CRITICO: bug o vulnerabilità che devono essere corretti immediatamente
- IMPORTANTE: design issues o violazioni di principi SOLID
- SUGGERIMENTO: ottimizzazioni o miglioramenti opzionali
def process_user_data(user_id, data):
conn = sqlite3.connect('users.db')
query = f"UPDATE users SET data = '{data}' WHERE id = {user_id}"
conn.execute(query)
conn.commit()
conn.close()
return True
Rispondi SOLO con la classificazione. Non proporre soluzioni ancora.
"""
# STEP 2a (se ci sono CRITICI): Fix immediati
"""
Hai trovato [N] problemi CRITICI. Inizia da quelli.
Per ogni problema critico:
1. Spiega la vulnerabilità specifica (es: SQL injection via f-string)
2. Mostra il codice vulnerabile evidenziato
3. Proponi il fix con spiegazione
4. Indica il CVE o OWASP category di riferimento
Dopo i critici, mostreremo gli altri in sessioni separate.
"""
# STEP 2b (se nessun CRITICO): Refactoring generale
"""
Non ci sono problemi critici. Procedi con il refactoring completo
indirizzando i problemi IMPORTANTI. Mantieni la stessa firma della funzione
per compatibilità con il codice chiamante.
"""Kod Claude vs kursor vs drugi pilot: szybkie porównanie
Każde narzędzie ma inne cechy, które wpływają na strukturę podpowiedzi. Wiedz różnice te umożliwiają dostosowanie komunikacji w celu maksymalizacji jakości wyników.
Kod Claude: Monituj o kompleksowe operacje
Claude Code działa w terminalu z dostępem do systemu plików, poleceń bash i liczby całkowitej baza kodu. Jest optymalny do kompleksowych, autonomicznych zadań, które chcesz całkowicie delegować podzadanie. Podpowiedzi dotyczące kodu Claude'a są zwykle bardziej deklaratywne i zorientowane do celów.
# Claude Code: prompt efficace per task autonomo
"""
Implementa il modulo di autenticazione per questa API.
Requisiti funzionali:
- Registrazione con email/password (hash bcrypt, salt 12)
- Login con JWT access token (15min) + refresh token (7 giorni httpOnly cookie)
- Logout che invalida il refresh token
- Refresh token endpoint
- Password reset via email (token con scadenza 1h)
Stack: Node.js 22, Express 5, Prisma con PostgreSQL, Zod
Struttura attesa:
- src/modules/auth/ con controller, service, repository
- src/domain/interfaces/IAuthService.ts
- Migrations Prisma per la tabella refresh_tokens
- Test Jest per AuthService (unit) e auth routes (integration)
- Aggiornamento del README con i nuovi endpoint
Procedi autonomamente. Alla fine, mostrami un summary delle
modifiche apportate e come testare il risultato.
"""Kursor: monit o edycję wielu plików
Cursor wyróżnia się skoordynowaną edycją wielu plików za pomocą narzędzia Composer. Monity dotyczące kursora są skuteczne, gdy wyraźnie określają pliki do modyfikacji i relacje między nimi zmiany.
# Cursor Composer: prompt per refactoring coordinato
"""
Refactoring: migra da class-based services a functional services con
dependency injection tramite closures.
File da modificare (in questo ordine):
1. src/services/userService.ts (classe attuale)
2. src/controllers/userController.ts (usa il servizio)
3. src/app.ts (DI container)
4. src/services/__tests__/userService.test.ts (aggiorna i mock)
Pattern target:
// PRIMA (class-based)
class UserService {
constructor(private repo: UserRepository) {}
async findById(id: string) {...}
}
// DOPO (functional)
const createUserService = (repo: IUserRepository) => ({
findById: async (id: string) => {...},
});
type UserService = ReturnType<typeof createUserService>;
Mantieni la stessa interfaccia pubblica dei metodi.
I test esistenti devono continuare a passare senza modifiche
alla logica di test, solo ai mock/setup.
"""GitHub Copilot: monity za pośrednictwem komentarzy i czatu
GitHub Copilot odpowiada na komentarze wbudowane w kodzie i wbudowany czat w IDE. ja Najbardziej efektywne podpowiedzi dla Copilota są podpowiedzi kontekstowe: kursor umieszczony w punkcie racja i opisowy komentarz są często skuteczniejsze niż długie wyjaśnienia na czacie.
// TECNICA 1: Commenti come prompt (file: src/utils/validation.ts)
// Validate email with RFC 5322 standard, return detailed error object
// with field name, message, and IETF error code. No external deps.
export function validateEmail(email: string): ValidationResult {
// Copilot suggerisce l'implementazione qui
}
// TECNICA 2: JSDoc come specifica (più contesto = più accurato)
/**
* Calcola il prezzo finale con sconti a cascata applicati nell'ordine:
* 1. Sconto per quantità (sopra 10: -5%, sopra 50: -10%, sopra 100: -20%)
* 2. Sconto utente (0-30%, applicato al prezzo dopo sconto quantità)
* 3. Codice promozionale (importo fisso, applicato per ultimo)
*
* @throws {InvalidDiscountError} se userDiscount > 30 o promoAmount < 0
* @returns prezzo arrotondato a 2 decimali
*/
function calculateFinalPrice(
basePrice: number,
quantity: number,
userDiscount: number,
promoAmount: number
): number {
// Copilot implementa seguendo la specifica JSDoc
}
// TECNICA 3: Chat Copilot con selezione codice
// [Seleziona il codice] poi in chat:
// "@workspace Refactoring questo metodo verso il pattern Result<T,E>
// che abbiamo nelle altre parti del progetto (vedi src/shared/Result.ts)"| Narzędzia | Siła | Optymalny monit | Okno kontekstowe |
|---|---|---|---|
| Claude'a Koda | Zadania od końca do końca, głębokie rozumowanie | Deklaratywne cele, szeroka autonomia | 200 tys. tokenów |
| Kursor | Edycja wielu plików, świadomość bazy kodu | Konkretne pliki, skoordynowane wzorce | 128 tys. tokenów (Kompozytor) |
| Drugi pilot | Autouzupełnianie, wbudowane sugestie | Komentarze wbudowane, precyzyjne dokumenty JSDoc | Kontekstowe dla pliku |
| Windsurfing | Kontekst proaktywny, eksploracja | Cele wysokiego poziomu, eksploruj niezależnie | 128 tys. tokenów |
Anty-wzorzec: podpowiedzi, które nie działają
Znajomość antywzorców jest równie ważna jak znajomość wzorców. To są podpowiedzi które systematycznie dają wyniki niskiej jakości lub wyniki wyrwane z kontekstu.
Anty-wzorzec 1: Niejasna zachęta
Niejasny monit jest najczęstszy. Prosi o zmiany bez określenia kierunku, tj ograniczenie lub kryterium sukcesu. Sztuczna inteligencja tworzy coś wiarygodnego, ale często tak nie jest dostosowane do rzeczywistych potrzeb.
# ANTI-PATTERN: vago e senza contesto
"Migliora questa funzione"
"Ottimizza le performance"
"Rendi il codice più pulito"
"Aggiungi error handling"
"Refactora questo"
# PATTERN CORRETTO: specifico e contestualizzato
"Ottimizza questa funzione Python che attualmente ha complessità O(n^2)
portandola a O(n log n) usando un heap. Mantieni lo stesso output ma
usa solo librerie stdlib. Includi benchmark prima/dopo con timeit."
"Aggiungi error handling a questo endpoint Express che al momento
lancia eccezioni non gestite. Usa il pattern AppError centralizzato
gia definito in src/errors/AppError.ts. Testa i casi 400, 401, 404, 500."Antywzorzec 2: Zbyt długa podpowiedź
Paradoksalnie zbyt długie podpowiedzi (ponad 2000 tokenów) zwykle dają rezultaty gorsze niż dobrze ustrukturyzowane średnie podpowiedzi. Modelka może stracić koncentrację na szczegółach krytycy pogrzebani w środku tekstu lub próbujący zaspokoić zbyt wiele wymagań jednocześnie tworzenie przeciętnego kodu na wszystkich frontach.
Limit 2000 tokenów dla podpowiedzi
Badania empiryczne sugerują, że zwykle pojawiają się monity o wartości powyżej 2000 tokenów dla pojedynczych zadań w celu uzyskania wyników o pogarszającej się jakości. Jeśli monit zbliża się do tego progu, i znak, że próbujesz zrobić za dużo na raz. Podziel zadanie za pomocą szybkie łączenie łańcuchowe. Wyjątkiem jest podanie kodu źródłowego jako kontekstu: dołącz plik kompletny często poprawia wynik w porównaniu z wyodrębnieniem tylko jego części.
Antywzorzec 3: branie ukrytego kontekstu
AI nie zapamiętuje poprzednich rozmów (z wyjątkiem kontekstu bieżącej sesji) np nie zna Twojego konkretnego projektu, jeśli mu go nie opisałeś. Zakładając, że jest to „oczywiste” zarówno ukryte, jak i systematyczne źródło nieskutecznych podpowiedzi.
# ANTI-PATTERN: assume contesto implicito
"Aggiungi il campo 'status' al modello"
# L'AI non sa: quale modello? quale database? quale ORM?
# quale tipo per 'status'? quali valori ammessi? quale migration?
"Usa il nostro pattern standard per questo"
# L'AI non conosce il tuo "pattern standard"
"Come facciamo di solito con gli errori"
# L'AI non sa come gestite gli errori nel vostro progetto
# PATTERN CORRETTO: contesto sempre esplicito
"Aggiungi il campo 'status' al modello User in Prisma (prisma/schema.prisma).
Il tipo e un enum: ACTIVE, INACTIVE, SUSPENDED, DELETED.
Default: ACTIVE. Obbligatorio (non nullable).
Genera la migration Prisma. Aggiorna UserRepository.findByStatus(status).
Aggiorna i test esistenti."Antywzorzec 4: Mega-podpowiedź „Zrób wszystko”.
Poproszenie sztucznej inteligencji o zaimplementowanie całej funkcji w jednym monicie prawie zawsze działa wyniki są niekompletne lub zawierają luki. Modelka zmuszona jest dokonywać wyborów dotyczących szczegółów nie określiłeś, a wybory nie zawsze odpowiadają Twoim oczekiwaniom.
# ANTI-PATTERN: mega-prompt
"Implementa un sistema completo di gestione utenti con CRUD,
autenticazione JWT, ruoli e permessi, rate limiting, audit log,
password reset via email, 2FA con TOTP, OAuth2 con Google e GitHub,
sessioni multi-device, revoca token, GDPR export e deletion,
dashboard admin, test completi e documentazione API."
# Risultato: codice generico, incompleto, senza adattamento al tuo stack
# PATTERN CORRETTO: decomposizione e priorità
# Step 1: "Implementa CRUD base per User (POST/GET/PUT/DELETE) con Prisma"
# Step 2: "Aggiungi autenticazione JWT al modulo users esistente"
# Step 3: "Implementa il sistema di ruoli RBAC basato su questi requisiti..."
# Step 4: "Aggiungi rate limiting con Redis usando il pattern già in AuthController"
# Ogni step valida il precedente prima di procedereAnty-wzorzec 5: Nie określaj formatu wyjściowego
Jeśli nie określisz formatu wyjściowego, sztuczna inteligencja wybierze to, co uzna za odpowiednie. A czasami jest to w porządku, ale często otrzymujesz długie wyjaśnienia, gdy potrzebujesz tylko kodu lub kodu bez komentarzy, kiedy tego potrzebujesz, lub częściowe rozwiązanie, kiedy się tego spodziewałeś kompletny.
# Formato output esplicito: esempi
"Mostrami SOLO il codice, senza spiegazioni."
"Fornisci prima una breve spiegazione dell'approccio (max 3 righe),
poi il codice completo, poi un esempio di utilizzo."
"Produce un diff nel formato git (+ per righe aggiunte, - per rimosse)."
"Mostrami solo le righe che cambiano, non l'intero file."
"Rispondi con un JSON nel formato:
{
'analysis': 'breve analisi del problema',
'solution': 'codice della soluzione',
'tests': 'test unitari minimi',
'caveats': 'limitazioni o assunzioni fatte'
}"Metryki służące do oceny jakości podpowiedzi
Podobnie jak w przypadku kodu, podpowiedzi można również ulepszać iteracyjnie poprzez pomiary ich skuteczność. Te wskaźniki pozwalają obiektywnie zrozumieć, czy Twoje monity są wyświetlane z czasem się poprawiają.
Metryki ilościowe
| Metryczny | Jak mierzyć | Cel |
|---|---|---|
| Iteracje na zadanie | Policz podpowiedzi potrzebne do uzyskania akceptowalnego wyniku | <3 dla standardowych zadań |
| Wskaźnik akceptacji | % mocy wyjściowej zaakceptowanej bez ręcznych zmian | >60% w przypadku powtarzalnych zadań |
| Test wskaźnika zdawalności za pierwszym razem | % wygenerowanego kodu, który przechodzi testy bez poprawek | >70% |
| Czas przeglądu | Średni czas przeglądu i zatwierdzenia wyników | Z biegiem czasu maleje |
| Przywróć stawkę | % zatwierdzeń wspomaganych przez sztuczną inteligencję, które są następnie cofane | <5% |
Metryki jakości
Oprócz liczb okresowo oceniaj jakość swoich podpowiedzi, odpowiadając na nie na te pytania:
# Checklist qualità prompt - Valutazione settimanale
CONTESTO
[ ] Ho specificato lo stack tecnologico con le versioni?
[ ] Ho incluso il codice rilevante (non tutto, ma quello collegato)?
[ ] Ho spiegato il contesto di business, non solo tecnico?
[ ] Ho specificato l'ambiente (dev/staging/prod)?
VINCOLI
[ ] Ho elencato cosa NON deve cambiare?
[ ] Ho specificato le librerie approvate/proibite?
[ ] Ho indicato i requisiti di performance o sicurezza?
[ ] Ho menzionato i vincoli di compatibilità?
OUTPUT ATTESO
[ ] Ho specificato il formato dell'output?
[ ] Ho indicato il livello di dettaglio (con test? con commenti?)?
[ ] Ho definito i criteri di successo?
[ ] Ho indicato cosa fare in caso di ambiguità?
STRUTTURA
[ ] Il prompt e focalizzato su un singolo problema?
[ ] E più corto di 2.000 token? (se no: usare chaining)
[ ] Il contesto critico e all'inizio e/o alla fine?
[ ] Ho usato il pattern giusto (zero-shot/few-shot/CoT)?
RED FLAGS
[ ] Sto usando parole vaghe come "migliorare", "ottimizzare", "pulire"?
[ ] Sto assumendo che l'AI conosca il mio progetto?
[ ] Sto chiedendo troppe cose contemporaneamente?
[ ] Sto omettendo il formato dell'output atteso?Cykl ciągłego doskonalenia
Najlepszych podpowiedzi nie tworzy się za pierwszym razem: ewoluują one z biegiem czasu. Leczyć I szablony podpowiedzi jako kod: wprowadź je do wersji, przetestuj odmiany i zaktualizuj pliki trwałe konfiguracje w miarę odkrywania wzorców, które działają najlepiej.
# Workflow: miglioramento iterativo dei prompt
# 1. Documenta i prompt che funzionano bene
# Salva in .claude/commands/ o in un docs/prompts/ folder
# 2. Quando un prompt fallisce, analizza perchè
"""
Post-mortem prompt fallito:
- Prompt: "Aggiungi logging al servizio"
- Problema: L'AI ha usato console.log invece di winston
- Causa root: non ho specificato la libreria di logging del progetto
- Fix CLAUDE.md: aggiunto "Logging: sempre winston, mai console.log"
"""
# 3. Aggiorna i file di configurazione persistenti
# CLAUDE.md aggiornato con:
# ## Logging
# SEMPRE usare winston (src/infrastructure/logger.ts)
# MAI usare console.log o console.error in produzione
# Livelli: error, warn, info, debug
# Formato: JSON strutturato con timestamp e request ID
# 4. Testa il prompt aggiornato
# 5. Misura il miglioramento (iterazioni necessarie)Zaawansowane przypadki użycia: monity dotyczące złożonych scenariuszy
Niektóre scenariusze rozwoju wymagają szczególnie wyrafinowanych podejść do podpowiedzi. Zobaczmy najczęstsze z konkretnymi przykładami.
Monituj o wspomaganą recenzję kodu
Korzystanie ze sztucznej inteligencji jako recenzenta kodu wymaga podpowiedzi określających poziom rygorystyczności, kategorie problemów, których należy szukać i format raportu.
# Prompt: code review sistematica
"""
Esegui una code review di questa Pull Request seguendo questi criteri.
Contesto PR:
- Feature: sistema di pagamento con Stripe
- Reviewer: sei un senior backend developer con focus su sicurezza
- Standard del team: Clean Architecture, Zod validation, 80% test coverage
Analizza il codice in questi ordini di priorità:
SICUREZZA (CRITICO - blocca la merge se trovato):
- Secrets o API keys hardcoded
- SQL injection o NoSQL injection
- Validazione input mancante o bypassabile
- Autenticazione/autorizzazione non corretta
- Esposizione di dati sensibili nei log o nelle risposte
- Riferimento OWASP Top 10 per ogni issue trovata
CORRETTEZZA (IMPORTANTE - richiede fix prima della merge):
- Bug logici o race conditions
- Error handling mancante per casi edge
- Violazioni delle invarianti di dominio
- Test mancanti per casi critici
DESIGN (MIGLIORAMENTO - fix in PR separata):
- Violazioni di principi SOLID
- Codice duplicato
- Nomi fuorvianti
- Complessità ciclomatica elevata (> 10)
Per ogni issue trovata, fornisci:
- File e riga
- Categoria (SICUREZZA/CORRETTEZZA/DESIGN)
- Descrizione del problema
- Codice problematico
- Suggerimento di fix con codice
Codice da revisionare:
[INCOLLA IL DIFF DELLA PR]
"""Monit o migrację technologii
Migracje technologiczne (np. CommonJS do modułów ES, Prisma do Drizzle, Express do Fastify) wymagają podpowiedzi, które poradzą sobie ze złożonością płynnego przejścia zgodnego wstecz.
# Prompt: migrazione tecnologica graduale
"""
Task: Migrazione graduale da CommonJS a ES Modules
Situazione attuale:
- 120 file .ts con require() e module.exports
- Node.js 22 (supporta ESM nativo)
- TypeScript 5.4 con "module": "commonjs" in tsconfig
- Build: tsc + ts-node per dev
Strategia richiesta: GRADUALE, non big-bang
- Non voglio migrare tutto in una PR
- I file CJS e ESM devono coesistere durante la transizione
- Zero regressioni durante la migrazione
Prima dimmi:
1. Qual è l'ordine ottimale di migrazione (quali file prima)?
2. Come configurare TypeScript per supportare entrambi i moduli?
3. Quali pattern CJS non hanno un equivalente ESM diretto?
4. Come gestire i __dirname e __filename nei moduli ESM?
Poi, partendo dall'analisi, migra SOLO questi 3 file come pilot:
- src/config/database.ts
- src/utils/logger.ts
- src/middleware/errorHandler.ts
Mostrami i file migrati e le modifiche a package.json e tsconfig.json.
"""Najlepsze praktyki: Dekalog szybkiej inżynierii
Podsumowujemy najskuteczniejsze praktyki, które wyłoniły się z konkretnych doświadczeń z asystentem kodowania AI w kontekstach rozwoju zawodowego.
- Najpierw kontekst: Każdy monit musi zaczynać się od stosu, wersji i odpowiednią architekturę. Nie bierz niczego za pewnik.
- Jedno zadanie na monit: utrzymuj koncentrację. Jeśli zadanie obejmuje wiele wymiarów, użyj szybkiego łączenia.
- Określ wiązania jawnie: co nie może się zmienić i jest ważne jak bardzo trzeba się zmienić.
- Zdefiniuj kryterium sukcesu: skąd będziesz wiedzieć, że wynik jest dopuszczalne? Wskaż to w monicie.
- Użyj trwałych plików konfiguracyjnych: CLAUDE.md, .cursorrules e copilot-instructions.md to inwestycje o wysokim ROI w dłuższej perspektywie.
- Dostosuj wzór do problemu: zero-shot do zadań standardowych, kilka strzałów w przypadku konwencji niestandardowych, CoT w przypadku problemów algorytmicznych, meta-podpowiadanie w przypadku źle zdefiniowanych problemów.
- Umieść kontekst krytyczny na początku i na końcu: model z większy ciężar w pozycjach otwierania i zamykania.
- Iteruj po podpowiedzi, a nie tylko po kodzie: jeśli wynik nie jest zgodny z oczekiwaniami, Często problem leży w podpowiedzi, a nie w modelu.
- Dokument podpowiada, że to działa: Utwórz bibliotekę szablonów dla powtarzające się zadania Twojego projektu.
- Mierz skuteczność: śledź liczbę iteracji na zadanie, współczynnika akceptacji i czasu przeglądu w celu ciągłego doskonalenia.
Podpowiedź nie zastępuje recenzji
Nawet najlepiej skonstruowany monit nie gwarantuje 100% bezpieczeństwa i poprawności kodu. 45% kodu wygenerowanego przez sztuczną inteligencję niezależnie nie przechodzi testów bezpieczeństwa (Veracode 2025). przez jakość podpowiedzi. Szybka inżynieria zmniejsza liczbę potrzebnych iteracji i poprawia jakość wyników, lecz krytyczny przegląd ludzki pozostaje niezbędny, szczególnie w przypadku kodu, który dotyczy uwierzytelniania, autoryzacji i zarządzania wrażliwymi danymi i logika finansowa. Przeczytaj artykuł na temat bezpieczeństwa w kodowaniu wibracji, aby uzyskać wytyczne specyfikacje.
Wnioski: Podpowiedź jako kod
Szybka inżynieria dla AI IDE nie jest tajemniczą sztuką zarezerwowaną dla osób posiadających umiejętności szczegóły. Jest to dyscyplina techniczna posiadająca jasne zasady, rozpoznawalne wzorce i wskaźniki mierzalne. Podobnie jak kod, podpowiedzi są pisane, testowane, refaktoryzowane i ulepszane z biegiem czasu.
Programiści, którzy uzyskują najlepsze wyniki dzięki asystentom kodowania AI, mają tę wspólną cechę podejście systematyczne: inwestują czas w konfigurowanie trwałych plików, których używają wzorce odpowiednie dla każdego typu zadania, wyraźnie określają kontekst i ograniczenia i traktują każdą nieudaną sugestię jako szansę na poprawę.
Różnica pomiędzy programistą, który „używa” sztucznej inteligencji, a tym, który „wie, jak się z nią komunikować” jest taka mierzyć w konkretny sposób: mniej iteracji na zadanie, bardziej akceptowalny wynik przy pierwszej próbie, mniej czasu spędzonego na ręcznym poprawianiu wygenerowanego kodu. Zwrot z inwestycji w szybkiej inżynierii i jednym z najwyższych w całym ekosystemie kodowania vibe.
Następny artykuł z tej serii porusza najbardziej krytyczną kwestię całego paradygmatu: the Bezpieczeństwo kodu generowanego przez sztuczną inteligencję. po co pisać idealnie, podpowiada to wygenerowanie podatnego na ataki kodu nie jest ulepszeniem: jest to bardziej subtelne zagrożenie związane z kodem wyraźnie słabo napisane.
Następne artykuły z serii
- 07 - Bezpieczeństwo w kodowaniu Vibe: Ryzyko związane z kodem generowanym przez sztuczną inteligencję, 45% nie przeszło testów bezpieczeństwa i konkretnych strategii łagodzących
- 08 - Przyszłość rozwoju agentycznego: Trendy 2026, prognozy Anthropic o roli dewelopera i planie działania agentów autonomicznych
Kluczowe punkty do zapamiętania
- Skuteczny monit składa się z trzech elementów: kontekstu, ograniczeń i oczekiwanego wyniku
- Użyj metody zerowej do standardowych zadań, kilku strzałów do niestandardowych konwencji opartych na łańcuchu myślowym dla złożonych problemów algorytmicznych
- CLAUDE.md, .cursorrules i copilot-instructions.md to inwestycje o wysokim ROI: Skonfiguruj je raz i korzystaj z każdej sesji
- Szybkie łączenie w łańcuchy przewyższa megapodpowiadanie w przypadku złożonych zadań: jedno zadanie na raz, każdy krok jest ważny
- Najczęstsze antywzorce to: niejasny, zbyt długi, ukryty kontekst, nie określono formatu wyjściowego
- Traktuj podpowiedzi jak kod: wersjonuj je, testuj i ulepszaj iteracyjnie
- Najlepsza podpowiedź nie zastąpi przeglądu kodu: 45% kodu AI kończy się niepowodzeniem testy bezpieczeństwa niezależnie od jakości podpowiedzi
Powiązane artykuły
- Seria kodowania Vibe: Przeczytaj inne artykuły z serii pełny obraz kodowania wibracji i rozwoju agenta
- Claude Code Głębokie nurkowanie: Aby opanować Anthropic CLI np jego system konfiguracji CLAUDE.md
- Kursor IDE: Do zaawansowanej konfiguracji reguł kursora i przepływ pracy z Cursor Composer