2.3 · Prompt Đầu Tiên

Mở đầu: Tại sao prompt đầu tiên quan trọng hơn bạn nghĩ

Viết cho tôi một function login.

Claude bắt đầu chạy. Sau 2 phút, bạn nhận được một file login.ts 80 dòng. Nhưng khi nhìn kỹ — nó dùng express-session, trong khi project của bạn đang dùng JWT. Nó tạo endpoint /login riêng, trong khi codebase đã có authRouter. Nó viết bcrypt theo kiểu cũ, trong khi team đã chuẩn hoá dùng argon2.

Bạn mất 20 phút gỡ ra và viết lại. Lần này tốn nhiều thời gian hơn làm tay.

Vấn đề không phải ở Claude. Vấn đề ở prompt.

Boris Cherny — kỹ sư chủ chốt trong nhóm phát triển Claude Code tại Anthropic — có một lời khuyên ngược đời mà nhiều người bỏ qua:

Don't use Claude Code to write code first. Use it to ask questions about the codebase.

Đây là sự khác biệt về mindset: prompt không phải là command — prompt là brief. Bạn không đang ra lệnh cho một cái máy. Bạn đang brief cho một kỹ sư mới vào team, người cực kỳ tài năng nhưng chưa biết gì về codebase của bạn.

Một kỹ sư giỏi khi nhận brief sẽ làm gì? Họ sẽ hỏi lại. Họ sẽ đọc code hiện tại trước. Họ sẽ đề xuất plan trước khi gõ dòng code đầu tiên. Claude Code được thiết kế để làm đúng như vậy — nếu bạn biết cách prompt.

Bài này sẽ dạy bạn cách làm điều đó.

3 Permission Modes: Claude Code hoạt động ở chế độ nào?

Trước khi gõ prompt, bạn cần chọn "chế độ làm việc" của Claude Code. Đây không phải chi tiết kỹ thuật nhỏ — đây là quyết định ảnh hưởng trực tiếp đến mức độ kiểm soát của bạn trong toàn bộ session.

Claude Code có 3 permission modes, toggle bằng Shift+Tab:

┌─────────────────────────────────────────────────────────────────┐
│              SHIFT+TAB — CYCLING PERMISSION MODES               │
└─────────────────────────────────────────────────────────────────┘

          ┌──────────────────────────────────────┐
          │         DEFAULT (Approval)            │
          │                                      │
          │  • Hỏi xác nhận TỪNG lần edit file  │
          │  • Hỏi xác nhận TỪNG lần chạy lệnh  │
          │  • An toàn nhất, chậm nhất           │
          │  • Best for: production codebase      │
          └──────────────────────────────────────┘
                          │
                    Shift+Tab
                          │
                          ▼
          ┌──────────────────────────────────────┐
          │         AUTO ACCEPT (Edit)            │
          │                                      │
          │  • Tự động approve edit/create file  │
          │  • Vẫn hỏi trước khi chạy commands  │
          │  • Nhanh hơn, ít interrupt hơn       │
          │  • Best for: sandbox / dev branch     │
          └──────────────────────────────────────┘
                          │
                    Shift+Tab
                          │
                          ▼
          ┌──────────────────────────────────────┐
          │           PLAN MODE                   │
          │                                      │
          │  • Read-only: đọc file, KHÔNG sửa   │
          │  • Claude phân tích → trả plan       │
          │  • Hỏi clarifying questions          │
          │  • Best for: task phức tạp, review   │
          └──────────────────────────────────────┘
                          │
                    Shift+Tab
                          │
                          ▼
                   (trở về Default)

Default (Approval Mode)

Mỗi khi Claude muốn sửa một file hoặc chạy một lệnh, nó dừng lại và hỏi bạn. Bạn đọc, approve hoặc reject.

Khi nào dùng

Production branch. Codebase của khách hàng. Lần đầu dùng Claude trên một project mới. Bất kỳ khi nào cost của sai lầm cao.

Trade-off

Bạn phải approve liên tục. Đôi khi Claude xin phép đọc file — cũng phải approve. Nếu task gồm 20 bước, bạn sẽ approve 20 lần.

Auto Accept

Claude tự động edit và tạo file mà không hỏi. Nhưng khi cần chạy lệnh shell (chạy test, install package, restart server) — vẫn hỏi bạn.

Khi nào dùng

Sandbox environment. Dev branch đã tách riêng. Khi bạn đã hiểu rõ scope của task và muốn Claude chạy nhanh.

Trade-off

Nếu Claude hiểu sai yêu cầu, nó có thể edit nhiều file trước khi bạn nhận ra. Vẫn được bảo vệ bởi git — nhưng phải git diff để kiểm tra sau.

Plan Mode

Claude chỉ dùng read-only tools: đọc file, grep, tìm kiếm, phân tích. Nó không sửa bất kỳ thứ gì. Kết quả là một bản plan chi tiết với các bước cụ thể.

Sau khi bạn review và approve plan, Claude mới chuyển sang execute — thường là trong Auto Accept mode.

Khi nào dùng

Task đủ lớn để cần plan trước. Feature mới trên codebase bạn chưa rõ. Code review an toàn. Bất kỳ khi nào bạn muốn "align trước, code sau".

Trade-off

Chậm hơn cho task nhỏ. Plan mode không phù hợp khi bạn chỉ cần fix typo hay đổi màu button.

Bảng so sánh: Khi nào dùng mode nào

Quy tắc nhanh: Task < 5 phút → Default hoặc Auto Accept. Task > 30 phút hoặc chạm nhiều file → Plan Mode trước.

Boris's 3-Task Framework

Boris Cherny chia mọi task Claude Code thành 3 loại, và mỗi loại có cách tiếp cận khác nhau:

┌─────────────────────────────────────────────────────────────────┐
│               BORIS'S 3-TASK FRAMEWORK                          │
├─────────────────┬───────────────────┬───────────────────────────┤
│   EASY          │   MEDIUM          │   HARD                    │
│   (One-shot)    │   (Planned)       │   (You drive)             │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Fix typo        │ Add JWT refresh   │ Refactor auth architecture│
│ Change color    │ Dark mode toggle  │ Migrate database schema   │
│ Add comment     │ New API endpoint  │ Design new module từ đầu  │
│ Format file     │ Viết test suite   │ Debug race condition phức │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Ai drive:       │ Ai drive:         │ Ai drive:                 │
│ Claude          │ Claude (sau plan) │ BẠN                       │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Mode dùng:      │ Mode dùng:        │ Mode dùng:                │
│ Auto Accept     │ Plan Mode →       │ Default                   │
│ hoặc GitHub     │ Auto Accept       │ (từng bước review)        │
│ @mention        │                   │                           │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Time estimate:  │ Time estimate:    │ Time estimate:            │
│ < 5 phút        │ 15-60 phút        │ 1+ giờ                    │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Verification:   │ Verification:     │ Verification:             │
│ Nhìn kết quả   │ Review plan +     │ Review sâu từng bước,     │
│ là xong        │ run tests          │ bạn là decision maker     │
└─────────────────┴───────────────────┴───────────────────────────┘

Easy: One-shot task

Với task rõ ràng, nhỏ, risk thấp — chỉ cần prompt cụ thể và để Claude chạy.

Ví dụ thực tế: Bạn đang review PR trên GitHub. Thấy comment "add loading state cho button". Thay vì assign cho ai, bạn tag @Claude trong issue:

@Claude, thêm loading state vào button Submit trong src/components/SubmitButton.tsx. Khi isLoading=true, disable button và hiển thị spinner thay cho text.

Claude đọc file, sửa, tạo commit. Done.

Medium: Plan trước, execute sau

Task đủ lớn để cần plan. Bạn cần align với Claude về approach trước khi nó bắt đầu viết code.

Workflow chuẩn (Boris's quote):

Shift+Tab into plan, align with Claude first. Once I feel good about the plan, I go into Auto Accept.

Bước 1: Shift+Tab → Plan Mode Bước 2: Viết prompt với đủ context Bước 3: Claude trả về plan chi tiết Bước 4: Review plan, comment nếu cần điều chỉnh Bước 5: Approve → Claude chuyển sang Auto Accept để execute

Hard: Bạn là người điều hướng

Task phức tạp, nhiều unknowns, cần judgment calls liên tục. Claude là pair programmer, nhưng bạn drive.

Mindset: Đừng viết prompt dài và để Claude làm một mình. Thay vào đó:

• Chia task thành subtask nhỏ hơn
• Làm từng subtask với Default mode
• Bạn review và quyết định hướng đi sau mỗi bước
• Dùng Plan Mode cho từng subtask nếu cần

Anti-pattern hay gặp: Nhồi toàn bộ "refactor auth architecture" vào 1 prompt → Claude tự quyết định approach → kết quả không match với vision của bạn.

Ví dụ thực chiến: Add Dark Mode Toggle (Step-by-step)

Đây là ví dụ Medium task theo đúng Plan Mode workflow. Task này từ video gốc của khóa học — được expand chi tiết để bạn có thể tự reproduce.

Tình huống

Bạn có một app React + Tailwind CSS đang chạy ở light mode. Product manager yêu cầu:

• Dark mode toàn app (background, text, card, border đều phải đổi)
• Toggle switch ở header để user tự chọn
• Preference phải lưu lại khi reload trang
• Contrast color phải đẹp, không xung đột với light theme hiện tại

Ước tính nếu làm tay: nửa ngày. Với Plan Mode: khoảng 25 phút.

Bước 1: Vào Plan Mode

Trong terminal tại root directory của project:

$ claude

Bấm Shift+Tab hai lần để vào Plan Mode. Thanh trạng thái dưới cùng hiển thị Plan Mode.

Bước 2: Viết prompt có đủ context và constraint

Prompt yếu (đừng làm thế này):

Thêm dark mode vào app của tôi.

Prompt mạnh (làm thế này):

My app needs dark mode implemented across the entire app.
Tech stack: React 18, Tailwind CSS v3, TypeScript.
App structure: src/components/ (reusable), src/pages/ (routes),
src/layouts/Header.tsx (header file chứa navigation).

Yêu cầu:
1. Dark mode áp dụng toàn app — background, text, card, border, input
2. Toggle switch đặt trong Header.tsx (góc phải, cạnh user avatar)
3. Dùng localStorage để lưu preference giữa các session
4. Respect prefers-color-scheme của OS nếu user chưa từng toggle
5. Tìm màu contrast phù hợp với light theme hiện tại — đọc
   tailwind.config.ts để hiểu color palette đang dùng

Constraint: KHÔNG dùng thư viện ngoài (next-themes hay tương tự).
Chỉ dùng Tailwind dark: variants + localStorage. Keep it simple.

Bước 3: Claude trả về plan 7 bước

Claude đọc các file liên quan (không sửa gì — Plan Mode) và trả về plan:

Plan: Implement Dark Mode Toggle

Step 1: Đọc tailwind.config.ts → identify màu hiện tại
        → propose dark palette tương phản tốt

Step 2: Thêm darkMode: 'class' vào tailwind.config.ts
        (switch từ media query sang class-based)

Step 3: Tạo DarkModeContext + useDarkMode hook
        → localStorage + OS preference detection

Step 4: Wrap App.tsx với DarkModeProvider
        → inject class 'dark' vào <html> element

Step 5: Tạo DarkModeToggle component (toggle switch UI)
        → Accessible: aria-label, keyboard nav

Step 6: Import DarkModeToggle vào Header.tsx
        → đặt trước user avatar

Step 7: Update global CSS classes trong các component hiện có
        → bg-white → bg-white dark:bg-gray-900
        → text-gray-900 → text-gray-900 dark:text-gray-100
        → (và các class card, border, input)

Câu hỏi: Step 7 sẽ update tất cả component files. Hiện có
~12 component. Bạn có muốn tôi update toàn bộ hay chỉ các
component trong layouts/ và pages/ trước?

Bước 4: Review plan và comment điều chỉnh

Bạn đọc plan. Có một điểm muốn điều chỉnh: không cần animation cho version 1 (cần ship hôm nay), và muốn update toàn bộ component luôn.

Gõ vào:

Plan trông tốt. Một điều chỉnh:
- Skip animation/transition cho toggle và color switching ở V1
  (cần ship hôm nay, animation sau)
- Step 7: Update tất cả component, không chỉ layouts/pages

Ready to proceed.

Bước 5: Approve plan

Claude xác nhận điều chỉnh và hỏi bạn có muốn chuyển sang execute không. Bạn confirm.

Bước 6: Claude execute với Auto Accept

Claude tự động chuyển mode (hoặc bạn Shift+Tab sang Auto Accept). Claude bắt đầu execute từng bước:

• Đọc tailwind.config.ts → thêm darkMode: 'class'
• Tạo src/hooks/useDarkMode.ts
• Tạo src/context/DarkModeContext.tsx
• Update src/App.tsx
• Tạo src/components/DarkModeToggle.tsx
• Update src/layouts/Header.tsx
• Update 12 component files với dark: variants

Bạn theo dõi. Mỗi file Claude edit hiện ra diff rõ ràng. Với Auto Accept, bạn không cần approve từng file — nhưng vẫn thấy được Claude đang làm gì.

Bước 7: Verify visual và run tests

Sau khi Claude xong:

npm run dev

Mở browser, test toggle. Kiểm tra:

• Light mode: đúng màu cũ
• Dark mode: contrast đẹp, không có text khó đọc
• Reload: preference giữ lại
• OS dark mode: auto-detect đúng

Nếu có vấn đề gì (ví dụ một card bị quên update), bạn prompt thêm:

Card trong src/components/ProductCard.tsx chưa có dark mode.
Background vẫn white. Fix dark:bg-gray-800 cho card container.

Kết quả

Thời gian (ước tính): khoảng 20-30 phút (bao gồm đọc plan + review + verify) So với làm tay: thường mất vài giờ vì phải touch hàng chục component Files touched: config file, utility mới, cùng toàn bộ component trong header Bugs: không có merge conflict — vì bạn đã review plan trước, Claude không sửa lệch

Anatomy của prompt tốt

Mỗi prompt hiệu quả có 4 thành phần. Không nhất thiết phải có đủ 4 cho task nhỏ — nhưng task càng lớn, càng cần đủ:

┌─────────────────────────────────────────────────────────────────┐
│                  4 THÀNH PHẦN CỦA PROMPT TỐT                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. CONTEXT                                                     │
│     Cho Claude biết: file nào, folder nào, codebase area nào    │
│     "File src/auth/login.ts, function verifyPassword() dòng 42" │
│                                                                 │
│  2. CONSTRAINTS                                                 │
│     Style, library được/không được dùng, performance, deadline  │
│     "Không dùng thư viện ngoài. Giữ bundle size nhỏ."          │
│                                                                 │
│  3. SUCCESS CRITERIA                                            │
│     Kết quả trông như thế nào? Test nào phải pass?              │
│     "Dark mode toggle hiển thị ở header. Unit test pass."       │
│                                                                 │
│  4. "THINK HARD" TRIGGER (nếu task khó)                        │
│     Extended thinking — Claude suy nghĩ sâu hơn trước khi làm  │
│     Thêm "think hard" hoặc "think harder" vào cuối prompt       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Bảng đối chiếu: Prompt yếu vs Prompt mạnh

Cùng một task — khác biệt về kết quả:

Pattern quan sát được: Prompt mạnh luôn trả lời 3 câu hỏi ngầm:

1. Claude cần đọc file nào để hiểu vấn đề?
2. Constraint là gì (không được làm gì, phải dùng gì)?
3. "Done" trông như thế nào?

Anti-patterns: 5 sai lầm phổ biến nhất

Anti-pattern 1: Prompt quá broad — "Build me an app"

❌ "Xây cho tôi một app quản lý todo"

Claude không biết: React hay Vue? REST hay GraphQL? Auth cần không? Database là gì? Deploy ở đâu?

Claude sẽ đoán. Và đoán của Claude không match vision của bạn.

Cách đúng: Break down trước. Bắt đầu với 1 tính năng cụ thể nhất:

✅ "Tạo React component TodoList với mock data. Chưa cần backend.
    Dùng TypeScript, Tailwind CSS. Cần: hiển thị list, add item,
    toggle done. Không cần delete ở V1."

Anti-pattern 2: Skip Plan Mode cho task > 30 phút

Bạn biết task này lớn — nhiều file, nhiều edge case — nhưng vẫn gõ thẳng prompt mà không dùng Plan Mode.

Claude bắt đầu viết. Sau 10 phút, bạn nhận ra Claude đang đi theo hướng khác với bạn muốn. Bạn interrupt. Claude phải rollback. Mất nhiều thời gian hơn nếu plan từ đầu.

Quy tắc: Task ước tính > 30 phút làm việc của bạn → Plan Mode trước, không ngoại lệ.

Anti-pattern 3: Auto Accept trên production branch

❌ git checkout main
   claude  # rồi dùng Auto Accept ngay

Auto Accept tốt cho sandbox. Trên production branch, một file bị edit sai có thể ảnh hưởng đến user thật. Luôn dùng Default mode (approval) khi đang làm việc trực tiếp trên main/production.

Cách đúng: Tạo feature branch trước, rồi mới dùng Auto Accept.

Anti-pattern 4: Không define "done" → Claude loop vô tận

❌ "Optimize toàn bộ codebase"

Claude sẽ optimize. Rồi optimize thêm. Rồi refactor. Rồi thêm tests. Rồi thêm docs. Không có điểm dừng tự nhiên.

Cách đúng: Luôn có success criteria rõ ràng:

✅ "Optimize queries trong src/api/products.ts.
    Mục tiêu: response time < 200ms (hiện tại ~800ms).
    Đo bằng cách chạy test suite. Dừng khi đạt target."

Anti-pattern 5: "Hãy fix tất cả bugs"

❌ "Fix tất cả bugs trong project"

Đây vừa broad vừa nguy hiểm. "Fix bugs" có thể dẫn đến Claude thay đổi behavior mà bạn không expect, với scope không giới hạn.

Cách đúng: Một bug cụ thể, một prompt cụ thể. Hoặc nếu muốn scan, dùng Plan Mode để Claude liệt kê bugs trước, bạn chọn cái nào fix.

Mẹo nâng cao

Mẹo 1: "Think hard" và extended thinking

Với bug khó, bài toán phức tạp, hoặc architecture decision quan trọng — thêm trigger extended thinking vào cuối prompt:

Ví dụ:

Race condition trong payment processing — 2 request gửi đồng thời
cùng order ID đôi khi tạo 2 transaction. File: src/api/payment.ts.
Phân tích và đề xuất fix. Think hard trước khi trả lời.

Extended thinking giúp Claude "viết nháp" quá trình suy luận trước khi đưa ra câu trả lời. Kết quả thường chính xác hơn đáng kể cho task phức tạp.

Mẹo 2: Reference file cụ thể bằng @filename

Thay vì mô tả file, dùng @:

❌ "Đọc file auth trong thư mục src rồi..."
✅ "Đọc @src/auth/login.ts và @src/auth/middleware.ts, sau đó..."

Claude sẽ load đúng file đó vào context, không phải đoán.

Mẹo 3: Multi-line prompt — ngắn nhưng cụ thể

3 dòng đủ cho hầu hết task medium, nếu mỗi dòng đều cụ thể:

Fix: LoginForm trong src/components/LoginForm.tsx không validate email format.
Constraint: Dùng regex RFC 5322, không install thư viện ngoài.
Test: Thêm 3 cases trong LoginForm.test.tsx (valid, invalid format, empty).

Không cần paragraph dài. Cụ thể > dài dòng.

Mẹo 4: Interrupt khi Claude đi sai hướng

Nếu Claude bắt đầu làm gì đó không đúng ý bạn — đừng để nó chạy hết rồi mới sửa. Bấm ESC ngay để interrupt.

[Claude đang viết function 50 dòng theo pattern bạn không muốn]
→ Bấm ESC
→ "Dừng lại. Approach đó sẽ không work vì [lý do]. Hãy thử theo hướng này..."

Interrupt sớm = tiết kiệm thời gian + tiết kiệm context window (xem Bài 2.5).

Áp dụng ngay

Bài tập 1: Reproduce Dark Mode Demo (15 phút)

Dùng bất kỳ project React + Tailwind nào của bạn (hoặc tạo project mới bằng Vite):

Bước 1

Mở terminal tại root project, chạy claude

Bước 2

Shift+Tab → Plan Mode

Bước 3

Copy prompt Dark Mode từ bài này (có điều chỉnh cho tech stack của bạn)

Bước 4

Đọc plan Claude trả về — ghi lại:

• Claude đề xuất bao nhiêu bước?
• Claude hỏi clarifying question nào?
• Có bước nào bạn muốn điều chỉnh không?

Bước 5

Comment điều chỉnh (nếu có) → approve → Claude execute

Bước 6

Verify: toggle hoạt động, preference lưu lại, contrast đẹp

Kết quả cần đạt

Dark mode chạy được, toggle ở header, localStorage giữ preference.

Bài tập 2: Prompt yếu vs Prompt mạnh — so sánh kết quả (10 phút)

Chọn 1 task đơn giản trong project của bạn (ví dụ: thêm loading state vào một button).

Lần 1 — Prompt yếu:

Thêm loading state vào button.

Ghi lại: Claude làm gì? Hỏi lại bao nhiêu lần? Kết quả có match không?

Lần 2 — Prompt mạnh (cùng task):

Thêm loading state vào component [YourButton] trong [path/to/file].
Khi prop isLoading=true: disable button + hiển thị spinner (Tailwind animate-spin).
Khi isLoading=false: trở về bình thường. Update TypeScript interface.
Test: Thêm 2 cases (loading/not loading) trong [YourButton.test.tsx].

So sánh:

• Số lần Claude hỏi lại: ___ vs ___
• Token usage (xem ở cuối session): ___ vs ___
• Kết quả cần sửa lại: ___ lần vs ___ lần
• Thời gian tổng: ___ phút vs ___ phút

Bài học: Prompt mạnh thường nhanh hơn và ít token hơn, dù bản thân prompt dài hơn.

Tóm tắt bài học

Tài liệu tham khảo

• Claude Code best practices — Anthropic engineering blog, bao gồm Plan Mode và prompt tips
• Boris Cherny transcript "Future of Agentic Coding" — nguồn cho 3-task framework và "Don't code first" advice
• Extended thinking docs — Cách Claude xử lý "think hard" trigger
• Video gốc: "Your first prompt" — Claude Code 101, Anthropic Skilljar (transcript tại source file)

Khoá học "Claude Code 101" — bản tiếng Việt v1.0 Bản quyền 2026 Anthropic. Mọi quyền được bảo lưu.