06 - IDE AI를 위한 프롬프트 엔지니어링: 효과적인 프롬프트 작성
개발자와는 분명히 차이가 있습니다. 미국 AI 코딩 도우미와 그 의사소통 방법을 알고 있다 그것으로. 첫 번째는 평범한 결과를 얻었으며 많은 반복이 필요합니다. 생성된 코드를 수동으로 수정하게 됩니다. 후자는 전자에 대한 정확한 출력을 얻습니다. 또는 두 번째 시도에서 작업 흐름 속도를 높이고 지속적인 교육 시스템을 구축하세요. 시간이 지나면서 개선됩니다. 차이점은 모두 있습니다 신속한 엔지니어링.
바이브 코딩의 맥락에서 프롬프트는 단순한 입력이 아니라 주요 인터페이스입니다. 개발자와 AI의 커뮤니케이션. 프롬프트의 품질이 코드의 품질을 결정합니다. 생성, 제안의 관련성, 버그 분석의 깊이 및 견고성 of a refactoring. 그러나 대부분의 개발자는 즉흥적이고 모호하며 빈 프롬프트를 사용합니다. 구조에 대해 불평하고 결과에 대해 불평합니다.
이 기사에서는 개발에 적용되는 기술 분야로서 신속한 엔지니어링을 탐구합니다.
소프트웨어: 효과적인 프롬프트의 해부학적 기초부터 생각의 사슬과 같은 고급 패턴까지
시스템 파일 구성에서 메타 프롬프트(CLAUDE.md,
.cursorrules, .github/copilot-instructions.md) 체인 프롬프트에서
복잡한 작업을 위해. 각 시나리오에 대해 TypeScript 및 Python의 구체적인 예가 포함되어 있습니다.
무엇을 배울 것인가
- 효과적인 프롬프트의 분석: 컨텍스트, 제약 조건, 출력
- 기본 패턴: 제로샷, 퓨샷, 생각 연쇄, 메타 프롬프트
- CLAUDE.md, .cursorrules 및 copilot-instructions.md를 구성하는 방법
- Claude Code 관련 프롬프트, Cursor 및 GitHub Copilot 비교
- 실제 예제를 사용한 리팩토링, 디버깅 및 테스트를 위한 효과적인 프롬프트
- 복잡한 작업을 관리 가능한 단계로 나누는 프롬프트 체인
- 가장 일반적인 안티패턴과 이를 방지하는 방법
- 프롬프트의 품질을 측정하는 측정항목
효과적인 프롬프트의 분석
AI 코딩 도우미의 효과적인 프롬프트는 단순한 자연어 문장이 아닙니다. 그리고 AI가 생산하는 데 필요한 것을 정확히 제공하는 정보 구조 품질 출력. 모든 효과적인 프롬프트에는 세 가지 주요 구성 요소가 포함됩니다. 문맥, 제약 e 예상 출력.
1. 맥락: AI가 문제에 대해 알고 있는 것
컨텍스트는 가장 중요하지만 가장 자주 간과되는 구성 요소입니다. AI는 당신의 프로젝트를 모릅니다. 아키텍처, 코드 표준 또는 비즈니스 요구 사항. 맥락 없이는 추상적으로는 작동하지만 특정 사례에서는 작동하지 않는 일반 코드입니다. 효과적인 맥락 다음이 포함됩니다:
- 기술 스택: 언어, 프레임워크, 특정 버전
- 현재 아키텍처: 사용된 패턴, 프로젝트 구조
- 관련 코드: 문제와 관련된 함수, 클래스, 인터페이스
- 사업 목표: 왜 이렇게 변경하는 건가요?
- 현황: 무엇이 작동하는지, 무엇이 작동하지 않는지, 정확한 문제는 무엇인지
2. 제약: 운영의 한계
제약 조건은 허용 가능한 솔루션의 경계를 정의합니다. 제약 없이 AI가 제안할 수 있다 기술적으로는 정확하지만 컨텍스트와 호환되지 않는 솔루션: 해당 라이브러리 이외의 라이브러리 승인됨, 이전 버전과의 호환성을 깨뜨리는 아키텍처, 표준에 맞지 않는 패턴 팀의. 일반적인 제약 조건은 다음과 같습니다.
- 승인되거나 금지된 라이브러리
- Node, TypeScript, Python 등의 특정 버전과의 호환성
- 성능 제한(알고리즘 복잡성, 번들 크기)
- 팀 표준(명명 규칙, 최소 테스트 적용 범위)
- 보안 제약 조건(평가 없음, 셸 주입 없음, 입력 검증)
3. 기대되는 출력 : 결과의 형태
출력 형식을 지정하는 것은 필수적입니다. "이 기능을 개선해 주세요"라는 메시지가 표시됩니다. 텍스트 응답, 인라인 코드, 제안 목록 또는 리팩토링을 얻을 수 있습니다. 완료. 원하는 것을 지정하면 모호함이 줄어듭니다.
- 체재: 직접 코드, 설명 + 코드, 변경 사항 목록
- 빗자루: 테스트가 포함된 기능, 전체 모듈
- 세부 수준: 주석 포함, TypeScript 유형 포함, 오류 처리 포함
- 다음 작업: 변경 사항을 적용하고, 차이점을 표시하고, 먼저 설명하고 구현합니다.
동일한 작업에 대해 모호한 프롬프트와 잘 구성된 프롬프트의 차이점을 살펴보겠습니다.
# 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;
}
"""명시적 컨텍스트 규칙
Research on prompt engineering shows that providing context at the beginning and end of the 중앙에 배치하는 것보다 신속하고 훨씬 더 효과적입니다. 모델은 더 많은 것을 제공하는 경향이 있습니다. 시작 및 종료 위치의 정보에 가중치를 둡니다. 긴 프롬프트의 경우 다음을 반복하세요. 가장 중요한 제약 조건은 "기억하세요: 인터페이스를 변경하지 마세요"와 같은 문구로 끝납니다. 기능을 공개합니다."
프롬프트 엔지니어링의 기본 패턴
신속한 엔지니어링 패턴은 LLM 상호 작용에 대한 학문적 연구에서 발생하지만 AI 코딩 도우미를 활용해 일상 업무에 구체적으로 적용됩니다. 그것들을 아는 것은 허용한다 모든 유형의 문제에 적합한 도구를 선택하는 것입니다.
제로샷 프롬프트
가장 간단한 패턴은 예시를 제공하지 않고 AI에게 작업을 수행하도록 요청하는 것입니다. 잘 작동해요 모델에 풍부한 훈련 데이터가 있는 표준 및 잘 정의된 작업의 경우. 그리고 요점은 모든 상호 작용의 이탈.
# 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.
"""몇 번의 프롬프트
복제하려는 패턴의 예를 제공하십시오. 특히 구축에 효과적입니다. 명명 규칙, 프로젝트별 데이터 구조 또는 비표준 코드 스타일. 모델은 예제에서 패턴을 "학습"하고 이를 새 사례에 적용합니다.
# 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.
"""CoT(사고 사슬) 프롬프트
최종 코드를 제공하기 전에 AI에게 단계별로 생각하도록 요청하세요. 이 접근법 특히 복잡한 알고리즘 문제, 성능 최적화 및 찾기 어려운 버그를 디버깅합니다. 구조화된 사고 사슬(SCoT) 연구 shows accuracy improvements of 15.27% for code generation tasks compared to prompts 표준.
# 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
"""메타 프롬프트
메타 프롬프트는 AI를 사용하여 프롬프트 자체를 생성하거나 향상시킵니다. 고급기술이네요 복잡한 문제를 공식화하는 방법을 정확히 모르거나, 기존 프롬프트를 최적화하고 싶습니다. AI는 프롬프트 생성에 협력자가 됩니다.
# 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)
...
"""어떤 패턴을 선택해야 합니까?
- 제로샷: 명확한 기술 용어를 사용하여 잘 정의된 표준 작업
- 몇 장의 샷: 디자인 규칙, 비표준 패턴, 특정 스타일
- 생각의 연쇄: 복잡한 버그, 최적화, 아키텍처 결정
- 메타 프롬프트: 문제가 명확하지 않을 때, 프롬프트를 개선하고 싶을 때
시스템 프롬프트 및 영구 구성 파일
AI 코딩 도우미를 사용할 때 가장 흔히 저지르는 실수 중 하나는 컨텍스트를 반복해야 한다는 것입니다. 모든 대화에서 프로젝트에 대해 이야기하세요. 최신 도구를 사용하면 지속적인 지침을 정의할 수 있습니다. 각 세션에 자동으로 포함됩니다. 획득하는 수준입니다 장기적으로 생산성이 가장 크게 향상됩니다.
CLAUDE.md: 클로드 코드의 운영체제
CLAUDE.md 각 시작 부분에서 Claude Code가 읽은 구성 파일
세션. 328개의 공개 CLAUDE.md 파일을 분석한 결과 가장 일반적인 카테고리는 다음과 같습니다.
아키텍처(72.6%), 개발 지침(44.8%), 프로젝트 개요(39.0%),
테스트(35.4%) 및 명령(33.2%). 좋은 CLAUDE.md는 Claude를 일반 조수로 변화시킵니다.
귀하의 특정 프로젝트에 대한 전문가입니다.
# 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: 커서 구성
커서가 파일을 사용합니다. .cursorrules 프로젝트 루트(또는 폴더
.cursor/rules/ 보다 세부적인 규칙의 경우) 동작을 사용자 정의합니다.
AI의. 커서는 세 가지 유형의 규칙을 지원합니다. 언제나 (모두에게 적용
파일), 자동 적용 (글로브 패턴과 일치하는 파일에 적용) e
에이전트 선택 (요청 시 가끔 적용).
# .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: Copilot용 사용자 정의 지침
GitHub Copilot이 파일을 사용합니다. .github/copilot-instructions.md 지침을 위해
저장소 수준에서 지속됩니다. GitHub에 따르면 이 파일은 "온보드"되도록 설계되었습니다.
효율적인 작업에 필요한 정보를 제공하는 Copilot 에이전트에 저장소
첫 번째 상호 작용부터. 2025년 8월 Copilot은 자동 생성을 도입했습니다.
저장소 구조를 분석하여 사용자 정의 지침을 제공합니다.
# 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)지속적인 지침을 넣을 위치
| 도구 | 파일 | 빗자루 |
|---|---|---|
| 클로드 코드 | CLAUDE.md (루트) 또는 ~/.claude/CLAUDE.md |
프로젝트 또는 글로벌 |
| 커서 | .cursorrules o .cursor/rules/*.mdc |
프로젝트 또는 파일 유형별 |
| GitHub 코파일럿 | .github/copilot-instructions.md |
저장소 |
| 윈드서핑 | .windsurfrules |
프로젝트 |
| 모두(표준) | .ai-instructions.md + 수입 |
교차 도구(가져오는 특정 도구 포함) |
특정 작업에 대한 프롬프트: 리팩터링, 디버깅, 테스트
각 개발 작업 유형에는 서로 다른 특성이 있으며 구조화된 프롬프트가 필요합니다. 다르게. 가장 일반적인 세 가지 작업인 리팩토링, 디버깅 및 테스트 생성.
리팩토링에 대한 프롬프트
좋은 리팩토링 프롬프트는 다음을 지정해야 합니다. 변화의 방향 (어떤 패턴이나 원칙으로 마이그레이션하고 있는지), 나는 호환성 제약 (변해서는 안 되는 것) 그리고 성공 기준 (그걸 어떻게 아는가? 리팩토링하여 성공했습니다).
# 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
"""디버깅 프롬프트
디버깅은 컨텍스트가 가장 중요한 작업입니다. AI는 충돌을 보지 못했습니다. 제공한 조각에서 상황을 재구성합니다. 효과적인 디버깅 프롬프트 완전한 오류 메시지, 스택 추적, 관련 코드 및 컨텍스트를 제공합니다. 환경.
# 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
"""테스트 생성 프롬프트
AI 생성 테스트는 올바르게 안내되지 않으면 너무 피상적인 경우가 많습니다. 좋은 것 테스트 프롬프트에서는 다음을 지정해야 합니다. 뼈대, il 테스트 유형 (단일, 통합, e2e), i 경계선 사례 덮는 것과 보장 수준 예상되는.
# 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.
"""복잡한 작업을 위한 프롬프트 체인
프롬프트 체인(Prompt Chaining)은 복잡한 작업을 일련의 작업으로 나누는 기술입니다. 각 단계의 출력이 다음 단계의 입력이 되는 연결된 하위 작업입니다. 그리고 특히 하나의 긴 프롬프트가 일관되지 않거나 불완전한 결과를 생성할 때 효과적입니다. 열쇠 그리고 분해: 문제에서 자연스러운 분리 지점을 식별합니다.
예: 프롬프트 연결을 통한 완전한 기능
속도 제한, 대기열 및 재시도 기능을 갖춘 이메일 알림 시스템을 구현해야 한다고 상상해 보십시오. 전체 기능에 대한 단일 프롬프트로 인해 불완전한 코드가 생성되는 경우가 많습니다. 체인 사용:
# 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
"""프롬프트 체인의 장점
- 세분화된 제어: 진행하기 전에 각 단계를 확인하세요.
- 현지화된 수정 사항: 단계가 잘못된 경우 해당 단계만 수정합니다.
- 깨끗한 컨텍스트: 각 단계에는 정확하고 집중된 컨텍스트가 있습니다.
- 더욱 안정적인 출력: 모델은 한 번에 하나의 문제에 초점을 맞춥니다.
- 추적성: 체인의 어느 단계에서나 다시 시작할 수 있습니다.
조건부 프롬프트 연결
조건부 연결은 이전 단계의 결과를 기반으로 결정을 내립니다. 유용하고 앞으로 나아갈 길은 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.
"""클로드 코드 vs 커서 vs Copilot: 프롬프트 비교
각 도구에는 프롬프트 구성 방법에 영향을 미치는 다양한 특성이 있습니다. 알아두세요 이러한 차이를 통해 커뮤니케이션을 조정하여 출력 품질을 최대화할 수 있습니다.
Claude Code: 엔드투엔드 작업에 대한 프롬프트
Claude Code는 파일 시스템, bash 명령 및 정수에 액세스하여 터미널에서 작동합니다. 코드베이스. 완전히 위임하려는 엔드 투 엔드 자율 작업에 최적입니다. 하위 작업. 클로드 코드에 대한 프롬프트는 더 선언적이고 지향적인 경향이 있습니다. 목표에.
# 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.
"""커서: 다중 파일 편집 프롬프트
Cursor는 Composer를 사용하여 여러 파일을 공동으로 편집하는 데 탁월합니다. 커서에 대한 프롬프트 수정할 파일과 파일 간의 관계를 명시적으로 지정할 때 효과적입니다. 변화.
# 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: 댓글과 채팅을 통한 프롬프트
GitHub Copilot은 코드의 인라인 주석과 IDE의 내장 채팅에 응답합니다. 나는 Copilot에 대한 가장 효과적인 프롬프트는 상황에 맞는 프롬프트입니다. 즉, 커서가 해당 지점에 위치합니다. 채팅에서 긴 설명보다 맞고 설명적인 의견이 더 효과적인 경우가 많습니다.
// 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)"| 도구 | Forza | 최적의 프롬프트 | 컨텍스트 창 |
|---|---|---|---|
| 클로드 코드 | 엔드투엔드 작업, 심층적 추론 | 선언적 목표, 광범위한 자율성 | 200K 토큰 |
| 커서 | 다중 파일 편집, 코드베이스 인식 | 특정 파일, 조정된 패턴 | 128K 토큰(작곡가) |
| 부조종사 | 자동 완성, 인라인 제안 | 인라인 주석, 정확한 JSDocs | 파일에 대한 상황별 |
| 윈드서핑 | 사전 상황 파악, 탐색 | 높은 수준의 목표, 독립적으로 탐색 | 128K 토큰 |
안티 패턴: 작동하지 않는 프롬프트
안티 패턴을 아는 것은 패턴을 아는 것만큼 중요합니다. 다음은 프롬프트입니다 품질이 낮은 출력이나 컨텍스트를 벗어난 결과를 체계적으로 생성하는 것입니다.
안티 패턴 1: 모호한 프롬프트
모호한 프롬프트가 가장 일반적입니다. 방향을 지정하지 않고 변경을 요청합니다. 제약조건 또는 성공 기준. AI는 그럴듯한 것을 생산하지만 종종 그렇지 않은 경우도 있습니다. 실제 요구 사항에 부합합니다.
# 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."안티 패턴 2: 너무 긴 프롬프트
역설적이게도 지나치게 긴 프롬프트(2,000개 이상의 토큰)는 결과를 생성하는 경향이 있습니다. 잘 구성된 평균 메시지보다 나쁩니다. 모델이 세부 사항에 초점을 잃을 수 있음 비판이 텍스트 중간에 묻혀 있거나 너무 많은 요구 사항을 동시에 충족시키려고 노력함 모든 면에서 평범한 코드를 생성합니다.
프롬프트에 대한 2,000개의 토큰 제한
경험적 연구에 따르면 단일 작업에 대해 2,000개 이상의 토큰을 요구하는 경향이 있습니다. 품질이 떨어지는 결과를 생성합니다. 프롬프트가 이 임계값에 도달하면 한 번에 너무 많은 일을 하려고 한다는 신호입니다. 다음으로 작업을 분할하세요. 신속한 연결. 예외는 소스 코드를 컨텍스트로 제공하는 것입니다. 파일을 포함합니다. 전체를 선택하면 일부만 추출하는 것보다 결과가 더 좋아지는 경우가 많습니다.
안티 패턴 3: 암시적 컨텍스트 활용
AI는 이전 대화를 기억하지 않습니다(현재 세션의 맥락 제외). 당신이 그에게 설명하지 않았다면 그는 당신의 구체적인 프로젝트를 알지 못합니다. "명백하다"고 가정하면 암묵적이고 체계적인 비효과적인 프롬프트 소스입니다.
# 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."안티 패턴 4: "모든 작업 수행" 메가 프롬프트
AI에게 단일 프롬프트로 전체 기능을 구현하도록 요청하는 것은 거의 항상 작동합니다. 결과가 불완전하거나 공백이 있습니다. 모델은 세부 사항에 대해 선택을 해야 합니다. 귀하가 지정하지 않았으며 선택 사항이 항상 귀하의 기대와 일치하는 것은 아닙니다.
# 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 procedere안티 패턴 5: 출력 형식을 지정하지 마세요
출력 형식을 지정하지 않으면 AI가 적절하다고 생각하는 형식을 선택합니다. 에이 때로는 괜찮지만 코드나 코드를 원할 때 긴 설명을 듣는 경우가 많습니다. 필요할 때 코멘트 없이, 또는 예상했을 때 부분적인 솔루션 제공 완전한 것.
# 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'
}"프롬프트 품질을 평가하는 측정항목
코드와 마찬가지로 프롬프트도 다음을 측정하여 반복적으로 개선할 수 있습니다. 그들의 효율성. 이러한 측정항목을 사용하면 프롬프트가 표시되는지 여부를 객관적으로 이해할 수 있습니다. 시간이 지남에 따라 개선되고 있습니다.
정량적 지표
| 미터법 | 측정 방법 | 목표 |
|---|---|---|
| 작업당 반복 | 수용 가능한 출력에 필요한 프롬프트 수 계산 | 표준 작업의 경우 <3 |
| 합격률 | 수동 변경 없이 허용되는 출력 비율(%) | 반복적인 작업의 경우 >60% |
| 첫 번째 실행에서 합격률 테스트 | 수정 없이 테스트를 통과한 생성된 코드의 비율 | >70% |
| 검토 시간 | 출력을 검토하고 승인하는 데 걸리는 평균 시간 | 시간이 지남에 따라 감소 |
| 복귀율 | 되돌려진 AI 지원 커밋의 비율 | <5% |
품질 지표
숫자 외에도 프롬프트에 응답하여 정기적으로 프롬프트의 구조적 품질을 평가하세요. 다음 질문에:
# 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?지속적인 개선 주기
최고의 메시지는 첫 번째 시도에 작성되지 않습니다. 시간이 지남에 따라 진화합니다. 내가 치료해 프롬프트 템플릿을 코드로 작성: 버전을 지정하고, 변형을 테스트하고, 파일을 업데이트하세요. 가장 잘 작동하는 패턴을 발견하면 지속적인 구성이 가능합니다.
# 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)고급 사용 사례: 복잡한 시나리오에 대한 프롬프트
일부 개발 시나리오에는 특히 정교한 프롬프트 접근 방식이 필요합니다. 구체적인 예를 들어 가장 일반적인 것을 살펴 보겠습니다.
보조 코드 검토에 대한 프롬프트
AI를 코드 검토자로 사용하려면 엄격함 수준을 지정하는 프롬프트가 필요합니다. 찾아야 할 문제의 범주와 보고서 형식.
# 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]
"""기술 이전 촉구
기술 마이그레이션(예: CommonJS에서 ES 모듈로, Prisma에서 Drizzle로, Express에서 Fastify로) 원활하고 이전 버전과 호환되는 전환의 복잡성을 처리하는 프롬프트가 필요합니다.
# 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.
"""모범 사례: 신속한 엔지니어링의 십계명
AI 코딩 어시스턴트의 구체적인 경험에서 나온 가장 효과적인 사례를 요약합니다. 전문 개발 맥락에서.
- 맥락 우선: 각 프롬프트는 stack, versions로 시작해야 합니다. 그리고 관련 아키텍처. 아무것도 당연하게 여기지 마십시오.
- 프롬프트당 하나의 작업: 초점을 유지합니다. 작업이 여러 개에 걸쳐 있는 경우 차원이라면 프롬프트 체인을 사용하세요.
- 제약조건을 명시적으로 지정: 변하지 말아야 할 것, 중요한 것 무엇이 바뀌어야 하는지.
- 성공 기준 정의: 결과가 무엇인지 어떻게 알 수 있나요? 받아들일 수 있나요? 프롬프트에 이를 표시합니다.
- 영구 구성 파일 사용: CLAUDE.md, .cursorrules e copilot-instructions.md는 장기적으로 ROI가 높은 투자입니다.
- 문제에 맞게 패턴을 조정하세요: 표준 작업을 위한 제로샷, 퓨샷 사용자 정의 규칙의 경우, 알고리즘 문제의 경우 CoT, 잘못 정의된 문제의 경우 메타 프롬프트입니다.
- 시작과 끝 부분에 중요한 컨텍스트를 배치하세요.: 모델 출신 열리고 닫히는 위치에 더 많은 무게가 가해집니다.
- 코드뿐만 아니라 프롬프트를 반복합니다.: 출력이 예상과 다르면 문제는 모델이 아니라 프롬프트에 있는 경우가 많습니다.
- 효과적인 문서 프롬프트: 다음에 대한 템플릿 라이브러리를 생성합니다. 프로젝트의 반복되는 작업.
- 효율성 측정: 작업당 반복 횟수를 추적합니다. 합격률과 심사시간을 지속적으로 개선해 나가고 있습니다.
프롬프트가 검토를 대체하지 않음
아무리 잘 구성된 프롬프트라도 100% 안전하고 올바른 코드를 보장하지는 않습니다. AI 생성 코드의 45%가 독립적으로 보안 테스트(Veracode 2025)에 실패합니다. 프롬프트의 품질에 따라. 신속한 엔지니어링으로 필요한 반복 횟수 감소 출력의 품질을 향상시키지만, 사람의 비판적인 검토는 여전히 필수입니다. 특히 인증, 권한 부여, 민감한 데이터 관리와 관련된 코드의 경우 그리고 금융 논리. 지침은 바이브 코딩의 안전에 관한 기사를 읽어보세요. 사양.
결론: 코드형 프롬프트
AI IDE를 위한 신속한 엔지니어링은 기술을 갖춘 사람들에게만 국한된 신비한 기술이 아닙니다. 세부 사항. 이는 명확한 원칙, 인식 가능한 패턴 및 측정 기준을 갖춘 기술 분야입니다. 측정 가능. 코드와 마찬가지로 프롬프트도 작성, 테스트, 리팩터링 및 개선됩니다. 시간이 지남에 따라.
AI 코딩 도우미를 통해 최고의 결과를 얻는 개발자들의 공통점은 다음과 같습니다. 체계적인 접근 방식: 영구 파일 구성에 시간을 투자하고 각 작업 유형에 적합한 패턴, 컨텍스트 및 제약 조건을 명시적으로 지정 그리고 그들은 실패한 모든 프롬프트를 개선의 기회로 간주합니다.
AI를 '사용'하는 개발자와 AI와 '소통하는 방법을 아는' 개발자의 차이점은 다음과 같습니다. measure in a concrete way: fewer iterations per task, more acceptable output on the first try, 생성된 코드를 수동으로 수정하는 데 소요되는 시간이 줄어듭니다. 투자 수익 신속한 엔지니어링과 전체 바이브 코딩 생태계에서 가장 높은 수준에 속합니다.
시리즈의 다음 기사에서는 이 전체 패러다임의 가장 중요한 문제를 다룹니다. 는 AI 생성 코드 보안. 왜 완벽한 메시지를 작성해야 할까요? 취약한 코드를 생성하는 것은 개선이 아닙니다. 코드에 대한 더 미묘한 위험입니다. 눈에 띄게 잘 작성되지 않았습니다.
시리즈의 다음 기사
- 07 - Vibe 코딩의 보안: AI가 생성한 코드의 위험성, 보안 테스트와 구체적인 완화 전략에 실패한 45%
- 08 - 에이전트 개발의 미래: 2026년 동향, 전망 개발자의 역할과 자율 에이전트의 로드맵에 대한 인류학
기억해야 할 핵심 사항
- 효과적인 프롬프트에는 컨텍스트, 제약 조건, 예상 출력의 세 가지 구성 요소가 있습니다.
- 표준 작업에는 제로샷을 사용하고, 맞춤형 사고방식 규칙에는 퓨샷을 사용합니다. 복잡한 알고리즘 문제의 경우
- CLAUDE.md, .cursorrules 및 copilot-instructions.md는 ROI가 높은 투자입니다. 한 번 설정하면 모든 세션에 혜택이 제공됩니다
- 프롬프트 체인은 복잡한 작업에 대해 메가 프롬프트를 능가합니다. 한 번에 하나의 작업, 모든 단계가 유효합니다
- 가장 일반적인 안티 패턴은 다음과 같습니다: 모호하고, 너무 길며, 암시적인 컨텍스트, 출력 형식이 지정되지 않았습니다.
- 프롬프트를 코드처럼 처리합니다. 버전을 지정하고, 테스트하고, 반복적으로 개선합니다.
- 가장 좋은 메시지는 코드 검토를 대체할 수 없습니다. AI 코드의 45%가 실패합니다. 프롬프트의 품질에 관계없이 보안 테스트
관련 기사
- 바이브 코딩 시리즈: 시리즈의 다른 기사를 읽어보세요. 바이브 코딩 및 에이전트 개발의 전체 그림
- 클로드 코드 심층 분석: Anthropic CLI를 마스터하려면 e CLAUDE.md 구성 시스템
- 커서 IDE: 커서 규칙의 고급 구성 및 Cursor Composer를 사용한 작업 흐름