Viết Prompt Hiệu Quả Cho Coding Agent
Tổng hợp nghiên cứu từ Anthropic, OpenAI, Google, IBM, và cộng đồng developer (2025-2026)
Mục lục
1. Nguyên Tắc Cơ Bản
1.1. Specificity & Clarity — Cụ thể và rõ ràng
Reasons:
-
Context Retrieval: Coding agent sử dụng prompt để search và retrieve context từ codebase. Prompt càng cụ thể (có tên file, function, component cụ thể), agent càng tìm đúng files/code liên quan để nạp vào working memory. Prompt mơ hồ → search queries kém → context thiếu/sai → output kém chất lượng.
-
Tool Selection: Agent quyết định dùng tools nào (Glob, Grep, Read, Edit) dựa trên prompt. Prompt rõ ràng giúp agent chọn đúng tools và parameters. VD: "Fix bug trong UserProfile.tsx" → agent biết dùng Read tool với exact file path thay vì phải Glob tìm kiếm mù mờ.
-
Scope Definition: Prompt cụ thể định rõ scope công việc, tránh agent làm quá nhiều (over-engineering) hoặc quá ít (thiếu features). "Thêm validation" quá chung → agent có thể thêm 10 validations không cần. "Thêm email format validation cho field email" → agent làm đúng cái cần.
-
Time Efficiency: Giảm số lần iterations. Prompt mơ hồ → output sai → phải refine prompt → lặp lại nhiều lần. Prompt cụ thể từ đầu → đúng ngay lần 1.
Bad prompt:
Viết code xử lý LoginForm cho tôi
Good prompt (theo RTF Framework):
<role>Senior React developer</role>
<task>
Viết LoginForm component với các yêu cầu:
- Dùng React Hook Form + Zod validation
- 2 fields: email (bắt buộc, format email), password (bắt buộc, min 8 ký tự, có uppercase + number)
- Submit: POST /api/auth/login với payload { email, password }
- Hiển thị error message dưới mỗi field khi validation fail
</task>
<format>
- File: src/components/LoginForm.tsx
- TypeScript với proper types
- Export default component
</format>
1.2. Context Assembly — Cung cấp ngữ cảnh đầy đủ
Reason: Theo Andrej Karpathy (2025): "LLM là CPU, context window là RAM, và bạn là hệ điều hành – công việc của bạn là nạp đúng dữ liệu vào working memory." Hầu hết lỗi của agent không phải do model kém mà do context kém. Cung cấp đủ ngữ cảnh giúp agent hiểu chính xác bạn muốn gì trong hoàn cảnh nào.
Bad prompt:
Tại sao function này bị lỗi?
Good prompt (theo RACE Framework):
<role>Senior TypeScript developer</role>
<action>
Tìm bug và fix function calculateTotal
</action>
<context>
Environment: Node.js 20, TypeScript 5.3
File: src/utils/calculator.ts
Current code:
function calculateTotal(items) {
return items.reduce((sum, item) => sum + item.price * item.qty, 0);
}
Problem:
- Input mẫu: [{ price: 10, qty: 2 }, { price: 5, qty: null }]
- Expected output: 20 (bỏ qua item có qty null)
- Actual output: NaN
</context>
<expectation>
- Function return đúng tổng, bỏ qua items có qty null/undefined
- Giải thích tại sao bug xảy ra
- Add proper TypeScript types
</expectation>
1.3. Task Decomposition — Chia nhỏ task phức tạp
Reason: Khi nhồi quá nhiều yêu cầu vào 1 prompt, agent bị "curse of instructions" – quá nhiều chỉ dẫn khiến nó không tuân thủ tốt bất kỳ cái nào. Chia nhỏ giúp agent tập trung, dễ kiểm tra lỗi, và output chất lượng hơn.
Bad prompt:
Xây dựng cho tôi một ứng dụng e-commerce hoàn chỉnh với authentication, product catalog,
shopping cart, checkout flow, payment integration, và admin dashboard.
Good prompt (chia nhỏ theo RISEN, 1 prompt/step):
Step 1:
<role>Database architect chuyên PostgreSQL</role>
<instructions>
Thiết kế database schema cho hệ thống e-commerce
</instructions>
<steps>
1. Tạo migration file cho 5 bảng: users, products, categories, orders, order_items
2. Define relationships (foreign keys, indexes)
3. Add constraints (unique, not null, check)
</steps>
<end_goal>
Schema hoàn chỉnh, ready để run migration
</end_goal>
<narrowing>
- Dùng PostgreSQL
- Follow naming convention: snake_case
- KHÔNG dùng ORM-generated migrations, viết raw SQL
</narrowing>
Step 2 (sau khi Step 1 xong):
<role>Backend engineer chuyên Node.js + PostgreSQL</role>
<task>
Viết API endpoint POST /api/auth/register dựa trên schema đã có
</task>
<requirements>
- Validate email unique
- Hash password bằng bcrypt
- Return JWT token
- Dùng pg driver (không dùng ORM)
</requirements>
1.4. Few-shot Prompting — Cung cấp ví dụ
Reason: Ví dụ hoạt động như ràng buộc ngầm, hướng dẫn model về format, style, và behavior mong muốn mà không cần giải thích dài dòng. Đây là một trong những kỹ thuật có ROI cao nhất trong prompt engineering.
Bad prompt:
Viết unit test cho function formatCurrency.
Good prompt (theo RACE + Few-shot):
<role>QA Engineer chuyên Vitest</role>
<action>
Viết unit test cho function formatCurrency
</action>
<context>
Project: TypeScript + Vitest
File cần test: src/utils/formatCurrency.ts
Function signature:
formatCurrency(amount: number, currency: string): string
Expected behavior:
- formatCurrency(1000, 'VND') => '1.000 ₫'
- formatCurrency(1500.5, 'USD') => '$1,500.50'
- formatCurrency(0, 'VND') => '0 ₫'
Existing test pattern trong dự án:
describe('formatDate', () => {
it('should format ISO date to dd/MM/yyyy', () => {
expect(formatDate('2024-01-15')).toBe('15/01/2024');
});
it('should return empty string for invalid date', () => {
expect(formatDate('invalid')).toBe('');
});
});
</context>
<expectation>
- Follow exact pattern như formatDate test
- Cover ít nhất 5 test cases (VND, USD, zero, negative, decimal)
- File: src/utils/formatCurrency.test.ts
</expectation>
1.5. Output Specification — Định nghĩa output rõ ràng
Reason: Nếu không chỉ định format output, agent sẽ tự chọn format mặc định (thường là bullet points hoặc code không theo convention của bạn). Chỉ rõ output format giúp kết quả sử dụng được ngay, giảm thời gian chỉnh sửa.
Bad prompt:
Tạo một API endpoint lấy danh sách users.
Good prompt (theo RTF + Output Spec rõ ràng):
<role>Backend developer chuyên Express.js</role>
<task>
Tạo API endpoint GET /api/users
</task>
<format>
File structure:
- Path: src/routes/users.ts
- Pattern: Follow Express Router giống src/routes/products.ts
Response format:
{
"data": [
{ "id": 1, "name": "...", "email": "..." }
],
"pagination": { "total": 100, "page": 1, "limit": 20 }
}
HTTP status codes:
- 200: Success
- 500: Database error
Constraints:
- KHÔNG return trường "password" trong response
- Support query params: ?page=1&limit=20
</format>
1.6. Constraints & Boundaries — Nêu rõ ràng buộc
Reason: Không có constraint, agent sẽ tự đưa ra quyết định kiến trúc mà có thể không phù hợp với dự án. Constraint giúp giới hạn phạm vi, tránh agent tự ý thêm dependency, thay đổi cấu trúc, hoặc dùng pattern không mong muốn.
Bad prompt:
Thêm caching cho API.
Good prompt (theo GCCVS + Constraints rõ ràng):
<goal>
Thêm in-memory caching cho endpoint GET /api/products
</goal>
<context>
File hiện tại: src/routes/products.ts
Package available: node-cache (đã có trong package.json)
Current flow: DB query mỗi request → chậm
</context>
<constraints>
- PHẢI dùng node-cache, KHÔNG được thêm Redis
- Cache TTL: 5 phút
- Invalidate cache khi có POST/PUT/DELETE trên /api/products
- KHÔNG thay đổi response format hiện tại
- KHÔNG modify file src/middleware/auth.ts
- KHÔNG thêm dependency mới
</constraints>
<verification>
- GET /api/products lần 1: query DB (slow)
- GET /api/products lần 2: từ cache (fast)
- POST /api/products → cache cleared
- GET /api/products sau POST: query DB lại
</verification>
<spec>
Cache key format: "products:all"
Cache hit/miss: log ra console để verify
</spec>
1.7. Verification & Testing — Yêu cầu kiểm chứng
Reason: Nếu không yêu cầu verification, bạn sẽ nhận được code "trông hợp lý" nhưng chưa được chứng minh hoạt động. Yêu cầu test hoặc verification buộc agent phải suy nghĩ kỹ hơn về edge cases và đảm bảo code đúng.
Bad prompt:
Viết function validate email.
Good prompt (theo GCCVS + Verification):
<goal>
Viết function validateEmail với test coverage đầy đủ
</goal>
<context>
Project: TypeScript + Vitest
File: src/utils/validateEmail.ts
Signature: validateEmail(email: string): boolean
</context>
<constraints>
- KHÔNG dùng thư viện external (validator.js, etc.)
- Dùng regex native
- TypeScript strict mode
</constraints>
<verification>
Viết unit test cover các case:
Valid emails:
- "[email protected]" → true
- "[email protected]" → true
Invalid emails:
- "" → false
- "user@" → false
- "@domain.com" → false
- "user @domain.com" → false
- "[email protected]" → false
Edge cases:
- Email > 254 chars → false
- Email có unicode "用户@domain.com" → handle gracefully
Sau khi viết, chạy: npm test validateEmail
Tất cả tests phải PASS trước khi return code.
</verification>
<spec>
Export cả function và test file:
- src/utils/validateEmail.ts
- src/utils/validateEmail.test.ts
</spec>
1.8. Structured Prompting — Sử dụng cấu trúc rõ ràng
Reason: Anthropic khuyến nghị dùng XML tags hoặc markdown sections để phân tách các phần trong prompt. Cấu trúc rõ ràng giúp model phân biệt đâu là context, đâu là instruction, đâu là constraint – giảm hiểu nhầm.
Bad prompt:
Tôi có một app React dùng TypeScript, cần thêm dark mode toggle vào Settings page,
dùng Context API, lưu preference vào localStorage, đừng thay đổi Header component,
và component nên nhận prop defaultTheme.
Good prompt:
<background>
App React + TypeScript, state management bằng Context API.
Theme hiện tại: chỉ có light mode.
</background>
<task>
Thêm dark mode toggle vào Settings page.
</task>
<requirements>
- Tạo ThemeContext với provider ở App level
- Toggle button trong src/pages/Settings.tsx
- Lưu preference vào localStorage, load khi app init
- Component nhận prop defaultTheme: 'light' | 'dark'
</requirements>
<constraints>
- KHÔNG modify src/components/Header.tsx
- KHÔNG thêm thư viện mới
- Dùng CSS variables cho theming
</constraints>
1.9. Persistent Instructions — Dùng project-level rules
Reason: Thay vì lặp lại coding conventions ở mỗi prompt, viết một lần vào file rules giúp mọi prompt đều tuân thủ cùng một chuẩn. Đây là "source of truth" mà cả bạn và agent cùng tham chiếu, giảm drift và inconsistency.
Bad practice:
(Mỗi lần prompt đều phải nhắc)
"Nhớ dùng single quotes, trailing comma, 2 spaces indent,
và viết theo functional component nhé..."
Good practice — tạo file CLAUDE.md hoặc .cursorrules:
# Project Conventions
## Code Style
- TypeScript strict mode
- Functional components + hooks only (no class components)
- Single quotes, trailing commas, 2-space indent
- Prettier + ESLint airbnb config
## Architecture
- Feature-based folder structure: src/features/{feature}/
- State management: Zustand
- API calls: React Query + Axios
- Testing: Vitest + React Testing Library
## Naming
- Components: PascalCase (UserProfile.tsx)
- Hooks: camelCase with "use" prefix (useAuth.ts)
- Utils: camelCase (formatDate.ts)
- Constants: UPPER_SNAKE_CASE
1.10. Iterative Refinement — Lặp lại và tinh chỉnh
Reason: Prompt engineering là quá trình lặp, không phải one-shot. Nếu output lần 1 chưa đúng, đừng viết lại từ đầu – hãy tinh chỉnh bằng cách bổ sung thông tin thiếu hoặc điều chỉnh constraint. Mỗi lần iterate bạn học được cách giao tiếp tốt hơn với agent.
Bad approach:
(Output không đúng ý → xóa hết → viết prompt hoàn toàn mới)
Good approach:
Prompt 1: "Viết component ProductCard hiển thị name, price, image."
(Output thiếu responsive design)
Prompt 2: "ProductCard ở trên chưa responsive. Hãy cập nhật:
- Mobile (<768px): card full width, image trên text dưới
- Desktop (>=768px): card 300px width, layout ngang
- Dùng CSS Grid, không dùng media query nếu có thể (dùng container query)"
1.11. Chain-of-Thought — Yêu cầu giải thích reasoning
Reason: Khi agent giải thích reasoning, bạn có thể verify logic đúng hay sai trước khi chấp nhận code. Nó cũng buộc agent suy nghĩ kỹ hơn, giảm hallucination, và đặc biệt hiệu quả với các task phức tạp.
Bad prompt:
Optimize đoạn code này cho nhanh hơn.
Good prompt (theo RISEN + Chain-of-Thought):
<role>Senior backend engineer chuyên database optimization</role>
<instructions>
Optimize đoạn code bị N+1 problem dưới đây
</instructions>
<steps>
1. Phân tích và giải thích:
- Tại sao đây là N+1 problem?
- Impact đến performance (với 100 users thì bao nhiêu queries?)
- Tính Big-O complexity hiện tại
2. Đề xuất solutions:
- List 2-3 cách fix khác nhau
- So sánh trade-offs (performance, complexity, maintainability)
- Recommend cách tốt nhất và explain WHY
3. Implementation:
- Implement solution được recommend
- Show code before/after
- Tính Big-O complexity sau optimize
4. Verification:
- Làm sao verify rằng fix đã work?
- Tools nào dùng để measure performance improvement?
</steps>
<end_goal>
Code optimized, giải thích reasoning đầy đủ để team hiểu WHY & HOW
</end_goal>
<narrowing>
- KHÔNG thay đổi database schema
- Giữ nguyên API response format
</narrowing>
<code>
// Current code (N+1 problem)
async function getUsersWithPosts() {
const users = await db.query('SELECT * FROM users');
for (let user of users) {
user.posts = await db.query('SELECT * FROM posts WHERE user_id = ?', [user.id]);
}
return users;
}
</code>
2. Công Thức Prompt
Dưới đây là các công thức phổ biến, được điều chỉnh cho coding context. Mỗi công thức phù hợp với một mức độ phức tạp khác nhau.
2.1. RTF Framework — Role, Task, Format
Công thức đơn giản nhất, phù hợp cho task nhanh, ít phức tạp.
| Thành phần | Ý nghĩa | Ví dụ coding |
|---|---|---|
| R — Role | AI đóng vai gì | "Act as a senior TypeScript developer" |
| T — Task | Việc cần làm cụ thể | "Viết function validate phone number VN" |
| F — Format | Định dạng output mong muốn | "Return TypeScript code với JSDoc comments" |
Công thức: [Role] + [Task] + [Format]
Ví dụ áp dụng:
Role: Bạn là senior TypeScript developer.
Task: Viết function validatePhoneVN(phone: string): boolean
kiểm tra số điện thoại Việt Nam (10 số, bắt đầu bằng 03/05/07/08/09).
Format: Return TypeScript code, kèm unit test dùng Vitest, có ít nhất 5 test cases.
Khi nào dùng: Quick fix, utility function, code snippet đơn lẻ, câu hỏi ngắn.
2.2. RACE Framework — Role, Action, Context, Expectation
Bổ sung thêm Context và Expectation so với RTF, phù hợp cho task có ngữ cảnh dự án.
| Thành phần | Ý nghĩa | Ví dụ coding |
|---|---|---|
| R — Role | AI đóng vai gì | "Senior React developer" |
| A — Action | Hành động cụ thể cần thực hiện | "Refactor component từ class sang functional" |
| C — Context | Bối cảnh dự án, tech stack, file liên quan | "Dự án dùng React 18 + TypeScript + Zustand" |
| E — Expectation | Kết quả mong đợi, tiêu chí thành công | "Component vẫn pass tất cả existing tests" |
Công thức: [Role] + [Action] + [Context] + [Expectation]
Ví dụ áp dụng:
Role: Senior React developer.
Action: Refactor UserProfile component từ class component sang functional component với hooks.
Context: Dự án React 18 + TypeScript. Component hiện tại dùng this.state và lifecycle methods.
File: src/components/UserProfile.tsx. State management: Zustand.
Expectation: Component hoạt động giống hệt bản cũ, tất cả existing tests trong
UserProfile.test.tsx vẫn pass. Dùng useState/useEffect thay thế state/lifecycle.
Khi nào dùng: Refactoring, bug fix, feature nhỏ trong dự án có sẵn.
2.3. RISEN Framework — Role, Instructions, Steps, End goal, Narrowing
Framework chi tiết nhất cho task phức tạp, nhiều bước, được khuyến nghị nhiều nhất cho coding tasks.
| Thành phần | Ý nghĩa | Ví dụ coding |
|---|---|---|
| R — Role | Persona / chuyên môn của AI | "Fullstack engineer chuyên Next.js + PostgreSQL" |
| I — Instructions | Mô tả chi tiết nhiệm vụ chính | "Xây dựng REST API authentication hoàn chỉnh" |
| S — Steps | Các bước cụ thể cần thực hiện (có thứ tự) | "1. Design schema → 2. Viết API → 3. Viết test" |
| E — End goal | Kết quả cuối cùng mong muốn | "User có thể register, login, refresh token" |
| N — Narrowing | Ràng buộc, giới hạn, điều KHÔNG được làm | "Không dùng ORM, chỉ raw SQL. Không thêm lib mới" |
Công thức: [Role] + [Instructions] + [Steps] + [End goal] + [Narrowing]
Ví dụ áp dụng:
Role: Bạn là fullstack engineer chuyên Next.js 14 App Router + PostgreSQL.
Instructions: Xây dựng hệ thống authentication với JWT cho dự án hiện tại.
Steps:
1. Tạo database migration cho bảng users (id, email, password_hash, created_at)
2. Viết API route POST /api/auth/register - validate input, hash password bằng bcrypt, insert DB
3. Viết API route POST /api/auth/login - verify credentials, return access token (15min) + refresh token (7d)
4. Viết API route POST /api/auth/refresh - verify refresh token, issue new access token
5. Viết middleware withAuth() để protect các route cần authentication
6. Viết unit test cho mỗi endpoint
End goal: User có thể register → login → nhận JWT → dùng token để access protected routes →
refresh token khi hết hạn. Tất cả tests pass.
Narrowing:
- KHÔNG dùng NextAuth/Auth.js - implement manual JWT
- KHÔNG dùng ORM, dùng pg driver trực tiếp
- KHÔNG thêm dependency ngoài bcrypt và jsonwebtoken (đã có trong package.json)
- Passwords phải được hash, KHÔNG BAO GIỜ lưu plaintext
- Tuân thủ folder structure hiện tại: src/app/api/...
Khi nào dùng: Feature lớn, multi-step implementation, system design, task cần plan rõ ràng.
2.4. COSTAR Framework — Context, Objective, Style, Tone, Audience, Response
Framework toàn diện nhất, phù hợp khi cần kiểm soát cả chất lượng code lẫn cách trình bày.
| Thành phần | Ý nghĩa | Ví dụ coding |
|---|---|---|
| C — Context | Background, tech stack, tình trạng hiện tại | "Dự án e-commerce Next.js, đang có performance issue" |
| O — Objective | Mục tiêu cần đạt được | "Giảm First Contentful Paint từ 4s xuống <1.5s" |
| S — Style | Coding style, pattern, convention | "Functional programming, immutable data, pure functions" |
| T — Tone | Mức độ chi tiết của giải thích | "Giải thích chi tiết từng thay đổi như đang mentor junior dev" |
| A — Audience | Ai sẽ đọc/maintain code này | "Team 3 junior devs, cần code dễ đọc hơn là clever" |
| R — Response | Format output mong muốn | "Code kèm inline comments, trước mỗi file ghi tóm tắt thay đổi" |
Công thức: [Context] + [Objective] + [Style] + [Tone] + [Audience] + [Response]
Ví dụ áp dụng:
Context: Dự án e-commerce Next.js 14 + React Query. Trang product listing đang load chậm
(FCP ~4s). Hiện tại fetch tất cả products một lần rồi filter client-side.
Objective: Optimize trang product listing để FCP < 1.5s và TTI < 2.5s.
Style: Dùng server components khi có thể. Prefer streaming + Suspense over loading states.
Giữ nguyên pattern React Query cho client components.
Tone: Giải thích chi tiết reasoning đằng sau mỗi optimization, ghi rõ trước/sau performance impact.
Audience: Team có 3 junior developers, ưu tiên code dễ hiểu, tránh abstraction phức tạp.
Response: Với mỗi file cần thay đổi:
1. Ghi tóm tắt 1 dòng về thay đổi
2. Show code diff (before/after)
3. Giải thích WHY thay đổi này improve performance
Khi nào dùng: Code review, optimization, documentation, task cần cân bằng giữa code quality và knowledge transfer.
2.5. GCCVS Framework — Goal, Context, Constraints, Verification, Spec
Công thức tôi tổng hợp riêng cho coding agent, lấy từ best practices của Anthropic và Addy Osmani.
| Thành phần | Ý nghĩa | Ví dụ |
|---|---|---|
| G — Goal | Mục tiêu rõ ràng, 1 câu | "Thêm dark mode toggle vào Settings page" |
| C — Context | Tech stack, file liên quan, code hiện tại | "React + Tailwind, file: src/pages/Settings.tsx" |
| C — Constraints | Giới hạn, điều KHÔNG được làm | "Không thêm lib, không sửa Header.tsx" |
| V — Verification | Cách kiểm tra kết quả đúng | "Chạy test, toggle 10 lần không bị flicker" |
| S — Spec | Input/output mẫu, acceptance criteria | "localStorage lưu 'theme': 'dark' |
Công thức: [Goal] + [Context] + [Constraints] + [Verification] + [Spec]
Ví dụ áp dụng:
Goal: Thêm infinite scroll cho trang product listing, thay thế pagination hiện tại.
Context:
- Tech: Next.js 14 + React Query + Tailwind
- File chính: src/app/products/page.tsx (hiện dùng <Pagination> component)
- API: GET /api/products?page=1&limit=20 (đã có sẵn, hỗ trợ cursor-based)
- Hiện tại: load 20 products/page, user click nút "Next"
Constraints:
- KHÔNG thêm thư viện mới (dùng IntersectionObserver native)
- KHÔNG thay đổi API response format
- Giữ khả năng SEO: page 1 vẫn server-rendered
- Memory: giữ tối đa 100 products trong DOM, virtualize phần còn lại
Verification:
- Scroll xuống cuối → tự động load thêm 20 products
- Network tab: chỉ gọi API khi scroll gần cuối (threshold 200px)
- Không memory leak khi scroll lâu (kiểm tra Chrome DevTools Memory)
- Hoạt động trên mobile Safari và Chrome
Spec:
- Loading indicator: skeleton 3 items khi đang fetch
- End state: hiển thị "Đã hiển thị tất cả sản phẩm" khi hết data
- Error state: hiển thị "Lỗi tải dữ liệu. Thử lại" với nút retry
- Scroll position: giữ nguyên khi navigate back từ product detail
Khi nào dùng: Mọi coding task từ nhỏ đến lớn. Đây là công thức versatile nhất cho coding agent.
2.6. So sánh các Framework
| Công thức | Độ phức tạp task | Số thành phần | Best for |
|---|---|---|---|
| RTF | Thấp | 3 | Quick fix, snippet, câu hỏi ngắn |
| RACE | Trung bình | 4 | Bug fix, refactor nhỏ |
| RISEN | Cao | 5 | Feature lớn, multi-step, system design |
| COSTAR | Cao | 6 | Code review, optimization, mentoring |
| GCCVS | Mọi mức | 5 | Mọi coding task (công thức chuyên biệt cho coding agent) |
Tip: Không nhất thiết phải dùng đủ mọi thành phần. Task đơn giản chỉ cần 2-3 thành phần. Điều quan trọng là luôn có Goal rõ ràng và Context đầy đủ.
3. Tổng Kết
3.1. Bảng tóm tắt các nguyên tắc
| # | Tiêu chí | Keyword |
|---|---|---|
| 1 | Cụ thể và rõ ràng | Specificity |
| 2 | Cung cấp ngữ cảnh đầy đủ | Context |
| 3 | Chia nhỏ task phức tạp | Decomposition |
| 4 | Cung cấp ví dụ | Few-shot |
| 5 | Định nghĩa output rõ ràng | Output Format |
| 6 | Nêu rõ constraint và boundary | Constraints |
| 7 | Yêu cầu verification | Testing |
| 8 | Cấu trúc prompt rõ ràng | Structure |
| 9 | Project-level rules | Persistent Rules |
| 10 | Lặp lại và tinh chỉnh | Iteration |
| 11 | Yêu cầu giải thích reasoning | Chain-of-thought |
4. Tài Liệu Tham Khảo
4.1. Nguyên tắc & Best Practices
- Anthropic - Claude Code Best Practices
- Anthropic - Claude Prompting Best Practices
- Addy Osmani - The Prompt Engineering Playbook for Programmers
- Addy Osmani - How to Write a Good Spec for AI Agents
- Lakera - The Ultimate Guide to Prompt Engineering 2026
- IBM - The 2026 Guide to Prompt Engineering
- OpenAI - Prompt Engineering Best Practices
- Graphite - How to Write Better Prompts for AI Code Generation
- Ranthebuilder - Agentic AI Prompting Best Practices
- Thomas Wiegold - Prompt Engineering Best Practices 2026