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ậnTừng lần edit file, từng lần chạy lệnh
Rủi roRất thấp — an toàn nhất
Tốc độChậm nhất
Best forProduction 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 approveEdit/create file
Vẫn hỏiCommands shell
Tốc độNhanh, ít interrupt
Best forSandbox / 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 viChỉ lập kế hoạch, KHÔNG thực thi
Kết quảPlan chi tiết + clarifying questions
Sau khi approveChuyển sang Edit automatically để execute
Best forTask 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 viTự động chạy toàn bộ: edit + lệnh + tools
Không hỏiEdit file, chạy lệnh, sử dụng tools
Tốc độNhanh nhất
Best forTask đã 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 viBỏ qua mọi giới hạn permission
Use caseAutomation, CI/CD
Rủi roRấ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 editEdit automaticallyPlan ModeAuto ModeBypass
Rủi ro phá codeRất thấpTrung bìnhKhông cóCaoRất cao
Tốc độChậm nhấtNhanhTrung bìnhNhanh nhấtNhanh nhất
Cần xác nhậnMọi bướcChỉ lệnh shellChỉ khi approveKhôngKhông
Fit cho: nhỏ, rõ ràngTốtTốt nhấtOverkillTốtKhông nên
Fit cho: medium, có planChậmTốtTốt nhấtCó thểKhông nên
Fit cho: complex, khám pháQuá nhiều interruptRủi roTốt nhấtKhông nênKhông nên
Fit cho: production branchTốt nhấtKhông nênDùng để reviewKhông nênTuyệt đối không
Fit cho: code reviewTốtKhông cầnTốt nhấtKhông nênKhô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 commentAdd JWT refresh, dark mode toggle, viết test suiteRefactor auth architecture, migrate database schema
AI driveClaudeClaude (sau plan)BẠN
Mode dùngEdit automatically hoặc GitHub @mentionPlan Mode → Edit automaticallyAsk before edit (từng bước review)
Time estimateDưới 5 phút15 - 60 phútMột giờ trở lên
VerificationNhìn kết quả là xongReview plan + run testsReview 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.”
1
Bước 1: Shift+Tab — Plan Mode
2
Bước 2: Viết prompt với đủ context
3
Bước 3: Claude trả về plan chi tiết
4
Bước 4: Review plan, comment nếu cần điều chỉnh
5
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:
$ 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 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:
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ả

Tiêu chíGiá trị
Thời gian ước tính20 - 30 phút (bao gồm đọc plan + review + verify)
So với làm tayThường mất vài giờ vì phải touch hàng chục component
Files touchedConfig file, utility mới, toàn bộ component trong header
BugsKhô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ầnMô tảVí dụ
1. ContextCho Claude biết file nào, folder nào, codebase area nào”File src/auth/login.ts, function verifyPassword() dòng 42”
2. ConstraintsStyle, library được/không được dùng, performance, deadline”Không dùng thư viện ngoài. Giữ bundle size nhỏ.”
3. Success CriteriaKế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 TriggerExtended thinking — Claude suy nghĩ sâu hơn trước khi làmThê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ếuPrompt 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.memouseMemo 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:
  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 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:
TriggerKhi nào dùng
think hardBug không rõ nguyên nhân, cần suy nghĩ nhiều hơn
think harderTask đặc biệt phức tạp, Claude cần thêm depth
ultrathinkArchitectural 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):
1
Mở terminal tại root project, chạy claude
2
Shift+Tab — Plan Mode
3
Copy prompt Dark Mode từ bài này (có điều chỉnh cho tech stack của bạn)
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?
5
Comment điều chỉnh (nếu có) — approve — Claude execute
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:
Tiêu chíPrompt yếuPrompt 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ể.