Mục tiêu học tập
Sau bài này, bạn sẽ có thể:
- ✅ Viết prompt hiệu quả — đủ context, đủ constraint, đủ success criteria
- ✅ Phân biệt 3 permission modes: Default, Auto Accept, Plan Mode — và biết khi nào dùng cái nào
- ✅ Kích hoạt Plan Mode đúng lúc để tránh Claude “lao đầu viết code” khi task còn mơ hồ
- ✅ Hiểu Boris’s 3-task framework — Easy/Medium/Hard — để chọn cách tiếp cận phù hợp
- ✅ Tự tay chạy demo Dark Mode Toggle end-to-end theo Plan Mode workflow
Mở đầu: Tại sao prompt đầu tiên quan trọng hơn bạn nghĩ
Hãy hình dung bạn mới cài Claude Code xong. Terminal đang mở. Bạn hào hứng gõ vào:
“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ó 5 permission modes, toggle bằng Shift+Tab:
Nếu ở VS Code, bạn cũng có thể toggle bằng cách click vào thanh trạng thái dưới cùng.
Tóm gọn: mức độ tự chủ tăng dần từ trái sang phải — từ “hỏi từng bước” đến “làm hết không hỏi gì”.
Ask before edit
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.
| Tiêu chí | Chi tiết |
|---|
| Hỏi xác nhận | Từng lần edit file, từng lần chạy lệnh |
| Rủi ro | Rất thấp — an toàn nhất |
| Tốc độ | Chậm nhất |
| Best for | Production codebase, lần đầu dùng Claude |
Khi nào dùng: Production branch. Codebase của khách hàng. Bất kỳ khi nào cost của sai lầm cao.
Trade-off: Bạn phải approve liên tục. Nếu task gồm 20 bước, bạn sẽ approve 20 lần.
Edit automatically
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.
| Tiêu chí | Chi tiết |
|---|
| Tự động approve | Edit/create file |
| Vẫn hỏi | Commands shell |
| Tốc độ | Nhanh, ít interrupt |
| Best for | Sandbox / dev branch |
Khi nào dù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.
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 Edit automatically mode.
| Tiêu chí | Chi tiết |
|---|
| Hành vi | Chỉ lập kế hoạch, KHÔNG thực thi |
| Kết quả | Plan chi tiết + clarifying questions |
| Sau khi approve | Chuyển sang Edit automatically để execute |
| Best for | Task phức tạp, cần review trước |
Khi nào dùng: Task đủ lớn để cần plan trước. Feature mới trên codebase bạn chưa rõ.
Trade-off: Chậm hơn cho task nhỏ. Không phù hợp khi bạn chỉ cần fix typo.
Auto Mode
Claude tự động chạy toàn bộ: edit file + chạy lệnh + tool calls — không có interrupt nào trong quá trình thực thi. Tốc độ cao nhất.
| Tiêu chí | Chi tiết |
|---|
| Hành vi | Tự động chạy toàn bộ: edit + lệnh + tools |
| Không hỏi | Edit file, chạy lệnh, sử dụng tools |
| Tốc độ | Nhanh nhất |
| Best for | Task đã rõ ràng, có trigger cho kết quả cụ thể |
Khi nào dùng: Khi task đã rõ ràng, bạn muốn Claude tự chạy từ đầu đến cuối mà không cần can thiệp.
Trade-off: Không thể can thiệp giữa chừng. Dùng khi đã hiểu rõ Claude và task đủ đơn giản.
Bypass permissions
Claude bỏ qua mọi giới hạn permission — không hỏi edit, không hỏi chạy lệnh, không hỏi gì cả.
| Tiêu chí | Chi tiết |
|---|
| Hành vi | Bỏ qua mọi giới hạn permission |
| Use case | Automation, CI/CD |
| Rủi ro | Rất cao — cực kỳ nguy hiểm |
Cực kỳ nguy hiểm. Không dùng trên production codebase. Chỉ dùng khi Claude bị stuck do permission bị chặn và bạn hiểu rõ điều gì đang xảy ra.
Bảng so sánh: Khi nào dùng mode nào
| Tiêu chí | Ask before edit | Edit automatically | Plan Mode | Auto Mode | Bypass |
|---|
| Rủi ro phá code | Rất thấp | Trung bình | Không có | Cao | Rất cao |
| Tốc độ | Chậm nhất | Nhanh | Trung bình | Nhanh nhất | Nhanh nhất |
| Cần xác nhận | Mọi bước | Chỉ lệnh shell | Chỉ khi approve | Không | Không |
| Fit cho: nhỏ, rõ ràng | Tốt | Tốt nhất | Overkill | Tốt | Không nên |
| Fit cho: medium, có plan | Chậm | Tốt | Tốt nhất | Có thể | Không nên |
| Fit cho: complex, khám phá | Quá nhiều interrupt | Rủi ro | Tốt nhất | Không nên | Không nên |
| Fit cho: production branch | Tốt nhất | Không nên | Dùng để review | Không nên | Tuyệt đối không |
| Fit cho: code review | Tốt | Không cần | Tốt nhất | Không nên | Không nên |
Quy tắc nhanh: Task dưới 5 phút — Ask before edit hoặc Edit automatically. Task trên 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:
Bảng tổng quan
| Easy (One-shot) | Medium (Planned) | Hard (You drive) |
|---|
| Ví dụ | Fix typo, change color, add comment | Add JWT refresh, dark mode toggle, viết test suite | Refactor auth architecture, migrate database schema |
| AI drive | Claude | Claude (sau plan) | BẠN |
| Mode dùng | Edit automatically hoặc GitHub @mention | Plan Mode → Edit automatically | Ask before edit (từng bước review) |
| Time estimate | Dưới 5 phút | 15 - 60 phút | Một giờ trở lên |
| Verification | Nhìn kết quả là xong | Review plan + run tests | Review sâu từng bước, 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:
“Shift+Tab into plan, align with Claude first. Once I feel good about the plan, I go into Edit automatically.”
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 Edit automatically để 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 Ask before edit 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:
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ạ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 Edit automatically
Claude tự động chuyển mode (hoặc bạn Shift+Tab sang Edit automatically). 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 Edit automatically, 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:
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ả
| Tiêu chí | Giá trị |
|---|
| Thời gian ước tính | 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, toàn bộ component trong header |
| Bugs | Không có merge conflict — vì bạn đã review plan trước |
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 đủ:
| Thành phần | Mô tả | Ví dụ |
|---|
| 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 | Extended thinking — Claude suy nghĩ sâu hơn trước khi làm | Thêm “think hard” hoặc “ultrathink” 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ả:
| Prompt yếu | Prompt mạnh |
|---|
| ”Sửa bug authentication" | "Hàm verifyPassword() trong src/auth/login.ts dòng 42-58 return true khi password rỗng vì bcrypt.compare() bị catch silent. Fix: throw error ra. Update test trong tests/auth/login.test.ts để cover case này." |
| "Thêm dark mode” | [Xem prompt ví dụ Dark Mode ở trên] |
| “Optimize performance" | "Component ProductList.tsx render lại mỗi khi parent state thay đổi dù props không đổi. Dùng React.memo và useMemo cho filteredProducts. Đo trước/sau bằng React DevTools Profiler." |
| "Viết tests" | "Viết unit tests cho src/utils/dateFormatter.ts. Cover: (1) format ngày hợp lệ, (2) invalid date, (3) timezone edge case. Dùng Vitest + @testing-library. Mock Date.now() khi cần." |
| "Fix cái bug kia" | "Bug: khi user submit form 2 lần nhanh liên tiếp (double-click), API call được gửi 2 lần. File: src/pages/CheckoutPage.tsx. Fix: debounce hoặc disable button sau lần submit đầu. Test: thêm case double-submit trong CheckoutPage.test.tsx.” |
Pattern quan sát được: Prompt mạnh luôn trả lời 3 câu hỏi ngầm:
- Claude cần đọc file nào để hiểu vấn đề?
- Constraint là gì (không được làm gì, phải dùng gì)?
- “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 trên 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 trên 30 phút làm việc của bạn — Plan Mode trước, không ngoại lệ.
Anti-pattern 3: Edit automatically trên production branch
❌ git checkout main
claude # rồi dùng Edit automatically ngay
Edit automatically 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 Ask before edit 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 Edit automatically.
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 dưới 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:
| Trigger | Khi nào dùng |
|---|
think hard | Bug không rõ nguyên nhân, cần suy nghĩ nhiều hơn |
think harder | Task đặc biệt phức tạp, Claude cần thêm depth |
ultrathink | Architectural decision quan trọng, không thể sai |
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.
Á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):
Mở terminal tại root project, chạy claude
Copy prompt Dark Mode từ bài này (có điều chỉnh cho tech stack của bạn)
Đọ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?
Comment điều chỉnh (nếu có) — approve — Claude execute
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:
| Tiêu chí | Prompt yếu | Prompt mạnh |
|---|
| Số lần Claude hỏi lại | ___ | ___ |
| Token usage | ___ | ___ |
| Kết quả cần sửa lại | ___ lần | ___ lần |
| Thời gian tổng | ___ phút | ___ 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
-
Prompt là brief, không phải command. Cung cấp đủ context (file, area), constraint (không được dùng gì, phải dùng gì), và success criteria (kết quả trông như thế nào).
-
5 permission modes — mỗi cái có use case riêng: Ask before edit (production, an toàn nhất), Edit automatically (sandbox, sau khi đã có plan), Plan Mode (task complex, cần align trước), Auto Mode (tự động chạy toàn bộ), Bypass permissions (automation/CI).
-
Boris’s 3-task framework: Easy — one-shot với Edit automatically. Medium — Plan Mode trước, Edit automatically sau. Hard — bạn drive, Claude là pair programmer với Ask before edit mode.
-
Plan Mode là best practice cho task trên 30 phút. Read-only, không risk. Claude hỏi clarifying questions, trả plan chi tiết. Bạn review và điều chỉnh trước khi approve.
-
Extended thinking với “think hard” / “think harder” / “ultrathink” khi task phức tạp — Claude suy nghĩ sâu hơn trước khi đưa ra câu trả lời, kết quả chính xác hơn đáng kể.