06 - IDE AI のプロンプト エンジニアリング: 効果的なプロンプトの作成
開発者と開発者の間には明らかな違いがあります。 アメリカ合衆国 AI コーディング アシスタントと 1 人 それ コミュニケーションの仕方を知っている それと一緒に。最初のものは平凡な結果しか得られず、多くの反復が必要です そして、最終的には生成されたコードを手動で修正することになります。後者は前者への正確な出力を取得します または 2 回目の試行では、ワークフローを高速化し、永続的な指示システムを構築します。 時間の経過とともに改善されます。違いはすべて 迅速なエンジニアリング.
バイブコーディングのコンテキストでは、プロンプトは単なる入力ではなく、メインインターフェイスです。 開発者とAIの間のコミュニケーション。プロンプトの品質がコードの品質を決定します 生成された提案の関連性、バグ分析の深さ、堅牢性 リファクタリングの。しかし、ほとんどの開発者は、即席で曖昧で空のプロンプトを使用しています。 構造に問題があった場合、結果について不満を言います。
この記事では、開発に適用される技術分野としてのプロンプト エンジニアリングについて説明します。
ソフトウェア: 効果的なプロンプトの解剖学的基礎から、思考連鎖などの高度なパターンまで
システム ファイル設定からのメタプロンプト (CLAUDE.md,
.cursorrules, .github/copilot-instructions.md) チェーンプロンプトで
複雑なタスクに。各シナリオの TypeScript と Python の具体的な例を示します。
何を学ぶか
- 効果的なプロンプトの構造: コンテキスト、制約、出力
- 基本的なパターン: ゼロショット、少数ショット、思考の連鎖、メタプロンプト
- CLAUDE.md、.cursorrules、および copilot-instructions.md を構成する方法
- Claude Code 固有のプロンプト、カーソル、GitHub Copilot の比較
- 実際の例を使用したリファクタリング、デバッグ、テストのための効果的なプロンプト
- 複雑なタスクを管理可能なステップに分割するためのプロンプトチェーン
- 最も一般的なアンチパターンとその回避方法
- プロンプトの品質を測定するための指標
効果的なプロンプトの構造
AI コーディング アシスタントにとって効果的なプロンプトは、単純な自然言語文ではありません。 そして、AI が生産するために必要なものを正確に提供する情報構造 高品質の出力。すべての効果的なプロンプトには、次の 3 つの主要なコンポーネントが含まれています。 コンテクスト, 制約 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;
}
"""明示的なコンテキスト ルール
プロンプトエンジニアリングに関する研究によると、メッセージの最初と最後にコンテキストを提供することがわかっています。 中央に配置するよりも迅速かつ大幅に効果的です。モデルはより多くのことを与える傾向があります 開閉位置における情報の重み。長いプロンプトの場合は、次の操作を繰り返します。 最も重要な制約を最後に「覚えておいてください: インターフェイスを変更しないでください」のような文言を付けます。 関数の公開。」
プロンプトエンジニアリングの基本パターン
迅速なエンジニアリング パターンは、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) 研究 プロンプトと比較して、コード生成タスクの精度が 15.27% 向上していることを示しています。 標準。
# 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 コーディング アシスタントを使用する際に最もよくある間違いの 1 つは、コンテキストを繰り返さなければならないことです。 すべての会話でプロジェクトについて話します。最新のツールを使用すると永続的な命令を定義できます これらは各セッションに自動的に含まれます。入手できるレベルです 長期的な生産性の最大の向上。
CLAUDE.md: クロード コードのオペレーティング システム
CLAUDE.md およびそれぞれの開始時にクロード コードによって読み取られる設定ファイル
セッション。 328 個の公開 CLAUDE.md ファイルの分析によると、最も一般的なカテゴリは次のとおりです。
アーキテクチャ (72.6%)、開発ガイドライン (44.8%)、プロジェクト概要 (39.0%)、
テスト (35.4%) とコマンド (33.2%)。優れた CLAUDE.md はクロードを一般アシスタントから変身させます
あなたの特定のプロジェクトの専門家。
# 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の。カーソルは 3 種類のルールをサポートします。 いつも (すべてに適用
ファイル)、 自動適用 (glob パターンに一致するファイルに適用されます) 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 +インポート |
クロスツール (それをインポートする特定のツールを使用) |
特定のタスクのプロンプト: リファクタリング、デバッグ、テスト
開発タスクの種類ごとに異なる特性があり、構造化されたプロンプトが必要です 違う。 3 つの最も一般的なタスク、リファクタリング、 デバッグとテストの生成。
リファクタリングのプロンプト
適切なリファクタリング プロンプトでは、 変化の方向性 (どのパターンまたは原則に向かって移行しているのか)、i 互換性の制約 （変えてはいけないもの）と、 成功基準 (それを知る方法 リファクタリングが成功しました)。
# 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.
"""複雑なタスクのプロンプトチェーン
プロンプトチェーンとは、複雑なタスクを一連のシーケンスに分割するテクニックです。 接続されたサブタスク。各ステップの出力が次のステップの入力になります。そして特に 単一の長いプロンプトによって一貫性のない、または不完全な結果が生成される場合に効果的です。鍵 そして 分解: 問題内の自然な分離点を特定します。
例: プロンプトチェーンを使用した完全な機能
レート制限、キュー、再試行を備えた電子メール通知システムを実装する必要があると想像してください。 機能全体に対する 1 つのプロンプトでは、不完全なコードが生成されることがよくあります。チェーンあり:
# 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
"""プロンプトチェーンの利点
- きめ細かな制御: 続行する前に各ステップを有効にします
- ローカライズされた修正: 手順が間違っている場合は、その手順だけを修正します
- クリーンなコンテキスト: 各ステップには正確で焦点を当てたコンテキストがあります
- より信頼性の高い出力: モデルは一度に 1 つの問題に焦点を当てます
- トレーサビリティ: チェーンのどのステップからでも再開できます
条件付きプロンプトの連鎖
条件付きチェーンでは、前のステップの出力に基づいて決定が行われます。そして役に立つ 今後の進め方は 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 コパイロット: 即時比較
各ツールには、プロンプトの構成方法に影響を与える異なる特性があります。知っている これらの違いにより、出力の品質を最大化するように通信を適応させることができます。
クロード コード: エンドツーエンド操作のプロンプト
Claude コードは、ファイルシステム、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 の組み込みチャットに応答します。私は コパイロットにとって最も効果的なプロンプトは、コンテキストに応じたプロンプトです。つまり、カーソルがポイントに配置されます。 多くの場合、チャットでの長い説明よりも、適切な説明と説明的なコメントの方が効果的です。
// 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 | 最適なプロンプト | コンテキストウィンドウ |
|---|---|---|---|
| クロード・コード | エンドツーエンドのタスク、深い推論 | 宣言的な目標、広範な自主性 | 200,000トークン |
| カーソル | 複数ファイルの編集、コードベースの認識 | 特定のファイル、コーディネートされたパターン | 128K トークン (作曲家) |
| 副操縦士 | オートコンプリート、インライン提案 | インライン コメント、正確な JSDoc | ファイルのコンテキストに応じた |
| ウィンドサーフィン | プロアクティブなコンテキスト、探索 | 高レベルの目標、独立して探索する | 128,000トークン |
アンチパターン: 機能しないプロンプト
アンチパターンを知ることは、パターンを知ることと同じくらい重要です。これらはプロンプトです 体系的に低品質の出力や文脈から外れた結果を生成するもの。
アンチパターン 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 に 1 つのプロンプトで機能全体を実装するよう依頼すると、ほとんどの場合うまくいきます。 結果が不完全であるか、ギャップがある。モデルは詳細について選択を迫られます。 指定していないため、選択肢が必ずしも期待と一致するとは限りません。
# 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コーディングアシスタントの具体的な経験から浮かび上がった最も効果的な実践方法をまとめます。 専門能力開発の文脈で。
- コンテキストを優先: 各プロンプトはスタック、バージョンで始まる必要があります および関連するアーキテクチャ。何事も当然のことだと思わないでください。
- プロンプトごとに 1 つのタスク: 集中力を維持します。タスクが複数にまたがる場合 ディメンションの場合は、プロンプト チェーンを使用します。
- 制約を明示的に指定する: 変えてはいけないもの、大切なもの 何をどれだけ変える必要があるのか。
- 成功基準を定義する: 結果が次のようになったことはどのようにしてわかりますか? 受け入れられますか？これをプロンプトで指定します。
- 永続的な構成ファイルを使用する: CLAUDE.md、.cursorrules e copilot-instructions.md は、長期的に高い ROI を実現する投資です。
- パターンを問題に適応させる: 標準タスクの場合はゼロショット、少数ショット カスタム規則の場合は CoT、アルゴリズムの問題の場合は CoT、不明確な問題の場合はメタプロンプト。
- 重要なコンテキストを最初と最後に配置する: のモデル 開閉位置に重点を置きます。
- コードだけでなくプロンプトを反復処理する: 出力が期待どおりにならない場合、 多くの場合、問題はモデルではなくプロンプトにあります。
- 機能するプロンプトを文書化する: テンプレート ライブラリを作成します。 プロジェクトの繰り返しタスク。
- 有効性を測定する: タスクごとの反復回数を追跡します。 承認率とレビュー時間を継続的に改善します。
プロンプトはレビューに代わるものではありません
最適に構造化されたプロンプトであっても、100% 安全で正しいコードが保証されるわけではありません。 AI 生成コードの 45% が単独でセキュリティ テスト (Veracode 2025) に不合格 プロンプトの品質によって異なります。迅速なエンジニアリングにより、必要な反復回数が削減されます 出力の品質は向上しますが、人間による批判的なレビューは引き続き不可欠です。 特に認証、認可、機密データ管理に関わるコードの場合 そして財務ロジック。ガイドラインについては、Vibe コーディングの安全性に関する記事を参照してください。 仕様。
結論: コードとしてのプロンプト
AI IDE の迅速なエンジニアリングは、スキルを持った人だけが行える神秘的な技術ではありません 詳細。これは、明確な原則、認識可能なパターン、指標を備えた技術分野です。 測定可能。コードと同様に、プロンプトも作成、テスト、リファクタリング、改善されます。 時間が経つにつれて。
AI コーディング アシスタントから最高の結果を得ている開発者には次のような共通点があります。 体系的なアプローチ: 永続ファイルの構成に時間を費やし、 タスクのタイプごとに適切なパターンを使用し、コンテキストと制約を明示的に指定します そして、失敗したすべてのプロンプトを改善の機会として扱います。
AI を「使用する」開発者と、AI と「通信する方法を知っている」開発者の違いは次のとおりです。 具体的な方法で測定する: タスクごとの反復回数が減り、最初の試行で許容できる出力が増加する、 生成されたコードを手動で修正するのにかかる時間が短縮されます。投資収益率 迅速なエンジニアリングにおいて、バイブコーディングエコシステム全体の中でも最高レベルにあります。
シリーズの次の記事では、このパラダイム全体の最も重要な問題について取り上げます。 の AI が生成したコードのセキュリティ。なぜ完璧なプロンプトを書くのか 脆弱なコードを生成することは改善ではありません。コードのより微妙な危険性です。 明らかに書き方が悪い。
シリーズの次の記事
- 07 - Vibe コーディングのセキュリティ: AI が生成したコードのリスク、 45% はセキュリティ テストと具体的な緩和戦略に不合格
- 08 - 薬剤開発の未来：2026年のトレンド、予測 開発者の役割と自律エージェントのロードマップに関する人間的視点
覚えておくべき重要なポイント
- 効果的なプロンプトには、コンテキスト、制約、期待される出力の 3 つのコンポーネントがあります。
- 標準タスクにはゼロショットを使用し、カスタムの思考連鎖規則には少数ショットを使用します 複雑なアルゴリズムの問題に対して
- CLAUDE.md、.cursorrules、および copilot-instructions.md は、ROI の高い投資です。 一度設定すれば、セッションごとにメリットが得られます
- プロンプト チェーンは、複雑なタスクのメガプロンプトを上回ります。一度に 1 つのタスクを実行し、 すべてのステップは有効です
- 最も一般的なアンチパターンは、あいまい、長すぎる、暗黙のコンテキスト、 出力形式が指定されていません
- プロンプトをコードのように扱います。プロンプトをバージョン管理し、テストし、反復的に改善します。
- 最適なプロンプトはコード レビューの代わりにはなりません: AI コードの 45% が失敗します プロンプトの品質に関係なくセキュリティ テストを行う
関連記事
- バイブコーディングシリーズ: シリーズの他の記事を読む バイブコーディングとエージェント開発の全体像
- クロードコードの詳細: Anthropic CLI をマスターするには CLAUDE.md 設定システム
- カーソルIDE: カーソルルールと Cursor Composer を使用したワークフロー