06 – Prompt Engineering pro IDE AI: Psaní efektivních výzev
Je jasný rozdíl mezi vývojářem, který USA asistent kódování AI a jeden že ví, jak komunikovat s tím. První z nich dosahuje průměrných výsledků, vyžaduje mnoho iterací a skončí ruční opravou vygenerovaného kódu. Ten druhý dostane přesné výstupy k prvnímu nebo na druhý pokus zrychlete svůj pracovní postup a vybudujte trvalé instrukční systémy které se časem zlepšují. Rozdíl je ve všem rychlé inženýrství.
V kontextu kódování vibrací není výzva jen vstupem: je to hlavní rozhraní komunikace mezi vývojářem a AI. Kvalita výzvy určuje kvalitu kódu generované, relevanci návrhů, hloubku analýzy chyby a robustnost refaktoringu. Přesto většina vývojářů používá improvizované, vágní a prázdné výzvy struktury, pak si stěžuje na výsledky.
Tento článek zkoumá rychlé inženýrství jako technickou disciplínu aplikovanou na vývoj
software: od anatomických základů efektivní výzvy až po pokročilé vzorce, jako je řetěz myšlenek
a meta-prompting, z konfigurace systémových souborů (CLAUDE.md,
.cursorrules, .github/copilot-instructions.md) na výzvu k řetězení
pro složité úkoly. S konkrétními příklady v TypeScriptu a Pythonu pro každý scénář.
Co se naučíte
- Anatomie efektivní výzvy: kontext, omezení, výstup
- Základní vzorce: nulový výstřel, několik výstřelů, řetěz myšlenek, metanávrh
- Jak nakonfigurovat CLAUDE.md, .cursorrules a copilot-instructions.md
- Porovnaly se výzvy specifické pro Claude Code, kurzor a GitHub Copilot
- Efektivní výzvy pro refaktorování, ladění a testování se skutečnými příklady
- Okamžité řetězení pro rozdělení složitých úkolů do zvládnutelných kroků
- Nejčastější anti-vzory a jak se jim vyhnout
- Metriky pro měření kvality vašich výzev
Anatomie efektivní výzvy
Efektivní výzva pro asistenta kódování AI není jednoduchá věta v přirozeném jazyce. A informační struktura, která poskytuje AI přesně to, co potřebuje k výrobě kvalitní výstup. Každá účinná výzva obsahuje tři klíčové součásti: kontext, omezení e očekávaný výstup.
1. Kontext: Co ví AI o vašem problému
Kontext je nejkritičtější a nejčastěji přehlíženou složkou. AI nezná váš projekt, vaši architekturu, standardy kódu nebo obchodní požadavky. Bez kontextu produkuje generický kód, který může fungovat abstraktně, ale ne ve vašem konkrétním případě. Efektivní kontext zahrnuje:
- Zásobník technologií: jazyk, rámec, konkrétní verze
- Současná architektura: použité vzory, struktura projektu
- Příslušný kód: funkce, třídy, rozhraní související s problémem
- Obchodní cíl: Proč děláte tuto změnu?
- Aktuální stav: co funguje, co nefunguje, jaký je přesný problém
2. Omezení: Limity, ve kterých se provozuje
Omezení definují hranice přijatelného řešení. Bez omezení může AI navrhovat řešení, která jsou technicky správná, ale nekompatibilní s vaším kontextem: knihovny jiné než ty schválené, architektury, které narušují zpětnou kompatibilitu, vzory nejsou v souladu se standardy týmu. Mezi typická omezení patří:
- Schválené nebo zakázané knihovny
- Kompatibilita se specifickými verzemi Node, TypeScript, Python atd.
- Limity výkonu (algoritmická složitost, velikost balíčku)
- Týmové standardy (konvence pojmenování, minimální pokrytí testem)
- Bezpečnostní omezení (žádné hodnocení, žádné vkládání shellu, ověřování vstupu)
3. Očekávaný výstup: Tvar výsledku
Je důležité určit výstupní formát. Výzva, která říká „vylepšete mi tuto funkci“ může získat textovou odpověď, vložený kód, seznam návrhů nebo refaktoring kompletní. Zadání toho, co chcete, snižuje nejednoznačnost:
- Formát: přímo kód, vysvětlení + kód, seznam změn
- Košťata: pouze funkce, celý modul včetně testů
- Úroveň detailů: s komentáři, s typy TypeScript, se zpracováním chyb
- Další akce: použít změnu, ukázat rozdíl, nejprve vysvětlit a poté implementovat
Podívejme se na rozdíl mezi vágní výzvou a dobře strukturovanou výzvou pro stejný úkol:
# 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;
}
"""Pravidlo explicitního kontextu
Výzkum rychlého inženýrství ukazuje, že poskytování kontextu na začátku a na konci rychlé a výrazně efektivnější než umístění do středu. Model má tendenci dávat více váhu k informacím v otevírací a zavírací pozici. U dlouhých výzev opakujte nejkritičtější omezení na konci se zněním jako „Pamatujte: Neměňte rozhraní veřejnost funkce“.
Základní vzorce rychlého inženýrství
Vzory rychlého inženýrství vycházejí z akademického výzkumu interakce LLM, ale jsou konkrétně aplikovány na každodenní práci s asistentem kódování AI. Jejich znalost umožňuje vybrat správný nástroj pro každý typ problému.
Výzva k nulovému výstřelu
Nejjednodušší vzorec: požádejte AI, aby provedla úkol bez uvedení příkladů. Funguje to dobře pro standardní a dobře definované úlohy, kde má model dostatek trénovacích dat. A pointa toho odchod z jakékoli interakce.
# 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.
"""Několik výstřelů
Uveďte příklady vzoru, který chcete replikovat. Zvláště efektivní pro založení konvence pojmenování, datové struktury specifické pro projekt nebo nestandardní styly kódu. Model se „naučí“ vzor z příkladů a aplikuje jej na nový případ.
# 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.
"""Chain-of-Thought (CoT) Prompting
Před poskytnutím konečného kódu požádejte AI, aby přemýšlela krok za krokem. Tento přístup a zvláště efektivní pro složité algoritmické problémy, optimalizace výkonu a ladění těžko dohledatelných chyb. Výzkum strukturovaného řetězce myšlení (SCoT). ukazuje zlepšení přesnosti o 15,27 % pro úlohy generování kódu ve srovnání s výzvami standardní.
# 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-prompting
Meta-promptování používá AI ke generování nebo vylepšení samotných výzev. Je to pokročilá technika zvláště užitečné, když nevíte, jak přesně formulovat složitý problém nebo kdy chcete optimalizovat existující výzvu. AI se stává spolupracovníkem při vytváření výzvy.
# 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)
...
"""Který vzor byste si měli vybrat?
- Nulový výstřel: Standardní, dobře definované úkoly s jasnou technickou slovní zásobou
- Málo výstřelů: Konvence designu, nestandardní vzory, specifické styly
- Řetězec myšlenek: Komplexní chyby, optimalizace, architektonická rozhodnutí
- Meta-nabádání: Když je problém špatně definovaný, když chcete zlepšit své výzvy
Systémové výzvy a trvalé konfigurační soubory
Jednou z nejčastějších chyb při používání asistentů kódování AI je opakování kontextu projektu v každém rozhovoru. Moderní nástroje umožňují definovat trvalé instrukce které jsou automaticky zahrnuty do každé relace. Toto je úroveň, kde se získávají the greatest long-term productivity gains.
CLAUDE.md: Operační systém Claude Code
CLAUDE.md a konfigurační soubor načtený Claude Code na začátku každého z nich
zasedání. Podle analýzy 328 veřejných souborů CLAUDE.md jsou nejběžnější kategorie:
Architektura (72,6 %), Pokyny pro vývoj (44,8 %), Přehled projektu (39,0 %),
Testování (35,4 %) a Příkazy (33,2 %). Dobrý CLAUDE.md promění Clauda z hlavního asistenta
odborník na váš konkrétní projekt.
# 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: Konfigurace kurzoru
Kurzor používá soubor .cursorrules v kořenovém adresáři projektu (nebo ve složce
.cursor/rules/ pro podrobnější pravidla) k přizpůsobení chování
AI. Kurzor podporuje tři typy pravidel: Vždy (platí pro všechny
soubory), Automatické použití (platí pro soubory, které odpovídají vzoru glob) e
Výběr agenta (používá se příležitostně na vyžádání).
# .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: Vlastní instrukce pro Copilota
GitHub Copilot používá soubor .github/copilot-instructions.md pro pokyny
trvalé na úrovni úložiště. Podle GitHubu je tento soubor navržen tak, aby „na palubě“
úložiště agentovi Copilot, které poskytuje informace potřebné pro efektivní práci
od první interakce. V srpnu 2025 Copilot představil automatické generování
vlastní instrukce analýzou struktury úložiště.
# 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)Kam umístit trvalé pokyny
| Nástroje | Soubor | Košťata |
|---|---|---|
| Claude Code | CLAUDE.md (kořen) nebo ~/.claude/CLAUDE.md |
Projekt nebo globální |
| Kurzor | .cursorrules o .cursor/rules/*.mdc |
Projekt nebo typ souboru |
| GitHub Copilot | .github/copilot-instructions.md |
Úložiště |
| Surfování | .windsurfrules |
Projekt |
| Vše (standardní) | .ai-instructions.md + dovoz |
Křížový nástroj (se specifickými nástroji, které jej importují) |
Výzvy pro konkrétní úkoly: Refaktorování, ladění, testování
Každý typ vývojového úkolu má jiné vlastnosti a vyžaduje strukturované výzvy jinak. Podívejme se na optimální struktury pro tři nejčastější úkoly: refaktoring, ladění a generování testů.
Výzvy pro Refaktoring
Dobrá výzva k refaktorování by měla specifikovat směr změny (k jakému vzoru nebo principu migrujete), tj omezení kompatibility (co se nesmí změnit) a kritérium úspěchu (jak poznat, že refaktorování a úspěšné).
# 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
"""Výzva k ladění
Ladění je úkol, kde je kontext nejdůležitější. AI havárii neviděla: musela rekonstruovat situaci z fragmentů, které poskytnete. Efektivní výzva k ladění poskytuje úplnou chybovou zprávu, trasování zásobníku, relevantní kód a kontext životního prostředí.
# 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
"""Výzva pro generování testu
Testy generované umělou inteligencí jsou často příliš povrchní, pokud nejsou správně vedeny. Dobrý výzva k testování musí specifikovat rámec, The typ testu (unitární, integrační, e2e), tzn hraniční případy zakrýt a úroveň pokrytí očekávaný.
# 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.
"""Rychlé řetězení pro složité úkoly
Prompt chaining je technika rozdělení složitého úkolu do sekvence spojených dílčích úkolů, kde výstup každého kroku se stává vstupem dalšího. A zvláště efektivní, když jediná dlouhá výzva vytváří nekonzistentní nebo neúplné výsledky. Klíč a rozklad: Identifikujte přirozené oddělovací body v problému.
Příklad: Kompletní funkce s rychlým řetězením
Představte si, že potřebujete implementovat e-mailový oznamovací systém s omezením rychlosti, frontou a opakováním. Jediná výzva pro celou funkci často vytváří neúplný kód. S řetězením:
# 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
"""Výhody rychlého řetězení
- Granulované ovládání: Před pokračováním platí každý krok
- Lokalizované opravy: pokud je krok chybný, opravte pouze tento
- Čistý kontext: každý krok má přesný a zaměřený kontext
- Spolehlivější výstup: Model se zaměřuje na jeden problém najednou
- Sledovatelnost: můžete restartovat z libovolného kroku řetězce
Podmíněné rychlé řetězení
Podmíněné řetězení zavádí rozhodnutí na základě výstupu předchozích kroků. A užitečné když cesta vpřed závisí na počáteční analýze AI.
# 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.
"""Claude Code vs Cursor vs Copilot: Rychlé srovnání
Každý nástroj má jiné vlastnosti, které ovlivňují, jak strukturovat výzvy. Vědět tyto rozdíly umožňují přizpůsobit komunikaci k maximalizaci kvality výstupu.
Claude Code: Výzva pro end-to-end operace
Claude Code pracuje v terminálu s přístupem k souborovému systému, příkazům bash a celému číslu kódová základna. Je optimální pro end-to-end autonomní úkoly, kde chcete delegovat úplně dílčí úkol. Výzvy pro Claude Code bývají více deklarativní a orientované k cílům.
# 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.
"""Kurzor: Výzva k úpravě více souborů
Cursor vyniká v koordinovaných úpravách více souborů pomocí Composer. Výzvy pro kurzor jsou účinné, když explicitně specifikují soubory, které se mají upravit, a vztahy mezi nimi změny.
# 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: Výzvy prostřednictvím komentářů a chatu
GitHub Copilot reaguje na vložené komentáře v kódu a vestavěný chat v IDE. já Nejúčinnější výzvy pro Copilota jsou kontextové: kurzor umístěný v bodě správný a popisný komentář je často účinnější než dlouhé vysvětlování v chatu.
// 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)"| Nástroje | Platnost | Optimální výzva | Kontextové okno |
|---|---|---|---|
| Claude Code | Úkoly end-to-end, hluboké uvažování | Deklarativní cíle, široká autonomie | 200 tisíc tokenů |
| Kurzor | Editace více souborů, povědomí o kódové základně | Specifické soubory, koordinované vzory | 128 000 tokenů (skladatel) |
| Druhý pilot | Automatické doplňování, vložené návrhy | Vložené komentáře, přesné JSDocs | Kontextově k souboru |
| Surfování | Proaktivní kontext, průzkum | Cíle na vysoké úrovni, prozkoumejte nezávisle | 128 tisíc tokenů |
Anti-Pattern: Výzvy, které nefungují
Znát anti-vzorce je stejně důležité jako znát vzorce. Toto jsou výzvy které systematicky produkují nekvalitní výstupy nebo výsledky mimo kontext.
Anti-Pattern 1: The Vague Prompt
Nejběžnější je neurčitá výzva. Požádá o změny bez určení směru omezení nebo kritérium úspěchu. AI produkuje něco věrohodného, ale často ne v souladu se skutečnými potřebami.
# 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."Anti-Pattern 2: Příliš dlouhá výzva
Paradoxně příliš dlouhé výzvy (přes 2000 tokenů) obvykle vedou k výsledkům horší než dobře strukturované průměrné výzvy. Model může ztratit zaměření na detaily kritiky pohřbené uprostřed textu nebo se snaží uspokojit příliš mnoho požadavků současně produkuje průměrný kód na všech frontách.
Limit 2 000 tokenů pro výzvy
Empirický výzkum naznačuje, že výzvy nad 2 000 tokenů pro jednotlivé úkoly mají tendenci k dosažení výsledků s klesající kvalitou. Pokud se vaše výzva blíží této hranici, a znamení, že se snažíte udělat příliš mnoho najednou. Rozdělit úkol s promptní řetězení. Výjimkou je poskytnutí zdrojového kódu jako kontextu: include the file úplná často zlepšuje výsledek ve srovnání s extrakcí pouze její části.
Anti-Vzor 3: Převzetí implicitního kontextu
AI si nepamatuje předchozí konverzace (kromě kontextu aktuální relace). nezná váš konkrétní projekt, pokud jste mu jej nepopsali. Za předpokladu "samozřejmého" jak implicitní, tak systematický zdroj neúčinných podnětů.
# 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."Anti-Pattern 4: Mega-výzva „Udělejte všechno“.
Požádat AI, aby implementovala celou funkci v jediné výzvě, téměř vždy funguje výsledky neúplné nebo s mezerami. Modelka je nucena volit detaily, které neuvedli jste a výběr nemusí vždy odpovídat vašim očekáváním.
# 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 procedereAnti-Pattern 5: Nespecifikujte výstupní formát
Pokud neurčíte výstupní formát, AI si vybere, co považuje za vhodné. A někdy je to v pořádku, ale často dostanete dlouhé vysvětlování, když jste jen chtěli kód nebo kód bez připomínek, když jste to potřebovali, nebo částečné řešení, když jste to očekávali ten úplný.
# 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'
}"Metriky pro hodnocení kvality výzev
Stejně jako u kódu lze výzvy také iterativně vylepšovat měřením jejich účinnost. Tyto metriky vám umožní objektivně pochopit, zda vaše výzvy časem se zlepšují.
Kvantitativní metriky
| Metrický | Jak měřit | Cíl |
|---|---|---|
| Iterace na úkol | Spočítejte výzvy potřebné pro přijatelný výstup | <3 pro standardní úlohy |
| Míra přijetí | % výstupu přijato bez ručních změn | > 60 % pro opakující se úkoly |
| Absolvovat test rychlosti na první spuštění | % vygenerovaného kódu, který projde testy bez oprav | >70 % |
| Čas kontroly | Průměrný čas na kontrolu a schválení výstupu | Postupem času klesá |
| Návratová rychlost | % potvrzení s pomocí AI, které jsou poté vráceny | <5 % |
Metriky kvality
Kromě čísel pravidelně vyhodnocujte strukturální kvalitu svých výzev tím, že na ně odpovídáte na tyto otázky:
# 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?Cyklus neustálého zlepšování
Nejlepší výzvy nejsou napsány na první pokus: vyvíjejí se v průběhu času. Léčit i vaše šablony výzev jako kód: verzujte je, testujte varianty a aktualizujte soubory trvalé konfigurace, když objevíte vzory, které fungují nejlépe.
# 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)Pokročilé případy použití: Výzvy pro složité scénáře
Některé vývojové scénáře vyžadují zvláště sofistikované přístupy pobízení. Podívejme se na ty nejběžnější s konkrétními příklady.
Výzva k asistované kontrole kódu
Použití umělé inteligence jako kontrolora kódu vyžaduje výzvy, které určují úroveň přísnosti, kategorie problémů, které je třeba hledat, a formát zprávy.
# 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]
"""Výzva k migraci technologií
Technologické migrace (např. CommonJS na moduly ES, Prisma na Drizzle, Express na Fastify) vyžadují výzvy, které zvládají složitost hladkého, zpětně kompatibilního přechodu.
# 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.
"""Nejlepší postupy: Desatero rychlého inženýrství
Shrneme nejúčinnější postupy, které vyplynuly z konkrétních zkušeností s asistentem kódování AI v kontextu profesního rozvoje.
- Nejprve kontext: Každá výzva musí začínat zásobníkem, verzemi a příslušnou architekturu. Neberte nic jako samozřejmost.
- Jeden úkol na výzvu: udržení pozornosti. Pokud úkol zahrnuje více rozměry, použijte rychlé řetězení.
- Explicitně určete omezení: co se nesmí změnit a je důležité jak moc je potřeba co změnit.
- Definujte kritérium úspěchu: jak poznáte, že je výsledek přijatelné? Uveďte to ve výzvě.
- Používejte trvalé konfigurační soubory: CLAUDE.md, .kurzorová pravidla e copilot-instructions.md jsou investice s vysokou návratností investic z dlouhodobého hlediska.
- Přizpůsobte vzor problému: nulový výstřel pro standardní úkoly, několik výstřelů pro vlastní konvence, CoT pro algoritmické problémy, meta-prompting pro špatně definované problémy.
- Umístěte kritický kontext na začátek a konec: model z větší váhu na pozici otevření a zavření.
- Iterujte výzvu, nejen kód: pokud výstup není podle očekávání, Problém je často ve výzvě, ne v modelu.
- Dokumentujte výzvy, které fungují: Vytvořte knihovnu šablon pro opakující se úkoly vašeho projektu.
- Změřte účinnost: sledovat počet iterací na úkol, míra přijetí a doba kontroly, aby se neustále zlepšovaly.
Výzva nenahrazuje recenzi
Ani sebelepší strukturovaná výzva nezaručuje 100% bezpečný a správný kód. 45 % kódu generovaného umělou inteligencí neprošlo nezávisle na bezpečnostních testech (Veracode 2025). podle kvality výzvy. Rychlé inženýrství snižuje počet potřebných iterací a zlepšuje kvalitu výstupu, ale kritická lidská kontrola zůstává nepostradatelná, zejména pro kód, který se dotýká autentizace, autorizace, správy citlivých dat a finanční logiku. Pokyny najdete v článku o bezpečnosti v kódování vibrací specifikace.
Závěry: Výzva jako kód
Pohotové inženýrství pro AI IDE není záhadným uměním vyhrazeným pro ty, kteří mají dovednosti podrobnosti. Je to technická disciplína s jasnými principy, rozpoznatelnými vzory a metrikami měřitelný. Stejně jako kód jsou výzvy psány, testovány, refaktorovány a vylepšovány časem.
Vývojáři, kteří dosahují nejlepších výsledků z AI kódovacích asistentů, to mají společné systematický přístup: investují čas do konfigurace trvalých souborů, které používají vzory vhodné pro každý typ úlohy, explicitně specifikujte kontext a omezení a každou neúspěšnou výzvu považují za příležitost ke zlepšení.
Rozdíl mezi vývojářem, který „používá“ AI, a tím, kdo s ní „umí komunikovat“, je měřit konkrétním způsobem: méně iterací na úkol, přijatelnější výstup na první pokus, méně času stráveného ruční opravou generovaného kódu. Návratnost investice v rychlém inženýrství a patří k nejvyšším v celém ekosystému kódování vibrací.
Další článek ze série se zabývá nejkritičtějším problémem celého tohoto paradigmatu: a Zabezpečení kódu generovaného AI. proč psát perfektní výzvy, že produkovat zranitelný kód není zlepšení: je to jemnější nebezpečí kódu viditelně špatně napsané.
Další články v seriálu
- 07 - Bezpečnost v kódování Vibe: Rizika kódu generovaného umělou inteligencí, 45 % neprojde bezpečnostními testy a konkrétními strategiemi zmírňování
- 08 - Budoucnost vývoje agentů: Trendy 2026, předpovědi Antropický o roli vývojáře a cestovní mapě autonomních agentů
Klíčové body k zapamatování
- Efektivní výzva má tři součásti: Kontext, Omezení, Očekávaný výstup
- Použijte nulový snímek pro standardní úkoly, několik snímků pro vlastní konvence řetězce myšlenek pro složité algoritmické problémy
- CLAUDE.md, .cursorrules a copilot-instructions.md jsou investice s vysokou návratností investic: Nastavte je jednou, těží z každé relace
- Řetězení výzev překonává megavýzvy pro složité úkoly: jeden úkol po druhém, každý krok je platný
- Nejběžnější anti-vzory jsou: vágní, příliš dlouhý, implicitní kontext, výstupní formát není určen
- Zacházejte s výzvami jako s kódem: verzujte je, testujte je a iterativně je vylepšujte
- Nejlepší výzva nenahrazuje kontrolu kódu: 45 % kódu AI selže bezpečnostní testy bez ohledu na kvalitu výzvy
Související články
- Řada Vibe Coding: Přečtěte si další články ze série pro úplný obraz kódování vibrací a vývoje agentů
- Claude Code Deep Dive: Pro zvládnutí antropického CLI e jeho konfigurační systém CLAUDE.md
- Kurzorové IDE: Pro pokročilou konfiguraci kurzorových pravidel a pracovní postup s Cursor Composer