Đa số developer dùng Claude Code như bói toán. Ném một request mơ hồ, hy vọng điều tốt nhất, rồi mất 20 phút sửa output. Tôi cũng từng vậy. Rồi tôi nhận ra những phiên tốt nhất — khi Claude cho ra kết quả chuẩn ngay lần đầu — đều theo cùng một cấu trúc ba giai đoạn.

Tôi gọi nó là Think-Plan-Execute. Đây không phải tính năng Claude Code. Đây là framework tư duy cho cách bạn tương tác với nó. Và khi đã thấy, bạn không thể bỏ qua.


Vấn Đề: Nhảy Thẳng Vào Execute

Đa số phiên làm việc trông như thế này:

Bạn: "Refactor auth module để dùng JWT"
Claude: *bắt đầu viết code ngay*
Claude: *chọn sai library*
Bạn: "Không, dùng jose, không phải jsonwebtoken"
Claude: *viết lại một nửa code*
Claude: *đặt middleware sai chỗ*
Bạn: "Cái đó nên ở src/middleware/, không phải src/auth/"
Claude: *di chuyển hết, break imports*

5 message, $3 đã chi, và bạn mới chỉ ở điểm xuất phát lẽ ra là message đầu tiên. Vấn đề không phải Claude Code — mà là bạn yêu cầu nó execute trước khi hiểu vấn đề.


Ba Giai Đoạn

Giai Đoạn 1: Think (Hiểu Vấn Đề)

Trước khi yêu cầu Claude Code thay đổi bất cứ thứ gì, hãy yêu cầu nó suy nghĩ về trạng thái hiện tại. Đây là lúc xây dựng context chung.

"Tôi cần thêm JWT authentication vào Express API. Trước khi thay đổi
bất cứ thứ gì, phân tích implementation auth hiện tại:
- Đọc src/auth/ và tóm tắt approach hiện tại
- Đọc src/middleware/auth.ts và giải thích cách validate request
- Kiểm tra package.json xem có dependency auth-related nào
- Liệt kê tất cả route đang yêu cầu authentication
Chưa thay đổi gì. Chỉ giúp tôi hiểu những gì đang có."

Giai đoạn này rẻ (đọc file tốn rất ít) và cực kỳ giá trị. Claude Code xây dựng mental model về hệ thống của bạn. Bạn xác nhận model đó đúng. Không có token lãng phí cho implementation sai.

Cụm từ chìa khóa cho giai đoạn Think:

  • “Trước khi thay đổi, phân tích…”
  • “Chưa thay đổi gì”
  • “Giúp tôi hiểu trạng thái hiện tại”
  • “Đọc và tóm tắt…”

Giai Đoạn 2: Plan (Thiết Kế Giải Pháp)

Khi Claude Code đã hiểu trạng thái hiện tại, yêu cầu nó lập kế hoạch trước khi viết code.

"Phân tích tốt. Giờ lên kế hoạch migration JWT. Dùng jose library
(đã có trong package.json):
1. File nào cần thay đổi?
2. Thứ tự thay đổi để không break gì?
3. Edge case nào cần xử lý?
4. Viết kế hoạch implementation từng bước.
Chưa viết code — chỉ kế hoạch."

Claude Code cho ra kế hoạch có cấu trúc. Bạn review. Phát hiện vấn đề sớm. Điều chỉnh nếu cần. Chi phí này chỉ bằng một phần nhỏ so với viết lại code.

Cụm từ cho giai đoạn Plan:

  • “Viết kế hoạch từng bước”
  • “Thứ tự thay đổi như thế nào?”
  • “Chưa viết code — chỉ kế hoạch”
  • “Edge case nào cần xử lý?”

Claude Code có Plan Mode (/plan) built-in để enforce pattern này. Nó ngăn Claude viết code cho đến khi bạn approve kế hoạch. Nhưng ngay cả không dùng Plan Mode, bạn vẫn đạt lợi ích tương tự bằng cách rõ ràng trong prompt.

Giai Đoạn 3: Execute (Implement Chính Xác)

Giờ bạn execute, từng bước một, theo kế hoạch.

"Bắt đầu execute kế hoạch. Step 1: Tạo JWT utility functions trong
src/auth/jwt.ts. Dùng jose library's SignJWT và jwtVerify. Bao gồm:
- generateToken(userId, role)
- verifyToken(token) → trả payload hoặc throw
- refreshToken(existingToken) → trả token mới
Theo patterns hiện có trong src/auth/password.ts cho error handling."

Prompt cực kỳ cụ thể. Claude Code biết chính xác cần tạo gì, đặt ở đâu, và theo pattern nào. Kế hoạch đã giải quyết sự mơ hồ. Execution chỉ là implementation.


Tại Sao Pattern Này Hiệu Quả: Token Economics

Pattern Think-Plan-Execute không chỉ cho code tốt hơn — nó thực sự rẻ hơn.

Không dùng pattern:

BướcMessagesChi phí
Request ban đầu (mơ hồ)1$0.30
Sửa chọn sai library2$0.80
Sửa vị trí file2$1.20
Sửa imports bị break3$2.40
Có version cuối đúng2$1.80
Tổng10$6.50

Dùng pattern:

Giai đoạnMessagesChi phí
Think (phân tích)1$0.20
Plan (thiết kế)2$0.60
Execute (implement)3$1.50
Tổng6$2.30

Bạn chi thêm một chút cho think và plan, nhưng tiết kiệm rất nhiều rework. Tổng rẻ hơn 65%.


Ví Dụ Thực: Database Migration

Phiên làm việc thật tuần trước, tôi dùng pattern này để migrate PostgreSQL schema.

Giai Đoạn Think

"Chúng ta cần thêm multi-tenancy vào database. Trước khi thay đổi:
1. Đọc schema hiện tại trong prisma/schema.prisma
2. Liệt kê models tham chiếu User
3. Kiểm tra raw SQL queries trong src/db/
4. Tóm tắt data access patterns hiện tại"

Claude Code báo: 12 models, 4 có relation trực tiếp với User, 2 raw SQL queries trong /db/reports.ts, và tất cả data access đều qua Prisma.

Giai Đoạn Plan

"Tốt. Lên kế hoạch migration multi-tenancy dùng cách thêm cột
'tenantId' (không tách schema). Yêu cầu:
- Mỗi table có cột tenantId
- Mọi Prisma query phải filter theo tenantId
- Raw SQL trong reports.ts cần update thủ công
- Migration phải backwards-compatible (data hiện tại nhận tenant mặc định)
- Lên thứ tự thay đổi để tránh foreign key issues"

Claude Code cho ra kế hoạch 7 bước. Tôi phát hiện một vấn đề — nó định thêm tenantId vào bảng AuditLog, nhưng bảng này nên cross-tenant cho admin. Chúng tôi điều chỉnh kế hoạch trước khi viết bất kỳ dòng code nào.

Giai Đoạn Execute

"Execute step 1: Thêm tenantId vào Prisma schema cho các model:
User, Project, Task, Comment, File. Required với default value
'default-tenant'. Thêm index trên tenantId cho mỗi table."

Mỗi bước sạch sẽ, tập trung, và đúng ngay lần đầu. Toàn bộ migration tốn 12 message thay vì 30+ với cách “cứ làm đi”.


Điều Chỉnh Pattern Theo Kích Thước Task

Không phải task nào cũng cần cả ba giai đoạn:

Kích thướcVí dụApproach
Rất nhỏ”Sửa lỗi chính tả”Execute trực tiếp
Nhỏ”Thêm một dòng log”Execute trực tiếp
Trung bình”Thêm validation cho form”Plan → Execute
Lớn”Refactor auth dùng JWT”Think → Plan → Execute
Rất lớn”Thêm multi-tenancy”Think → Plan → Execute (nhiều vòng)

Với task trung bình, bạn có thể bỏ qua Think nếu đã hiểu rõ codebase. Với task rất lớn, có thể cần nhiều chu trình Think-Plan-Execute, mỗi chu trình cho một component chính.


Công Cụ Built-in Cho Pattern Này

Claude Code có tính năng map trực tiếp vào mỗi giai đoạn:

Giai đoạn Think:

  • Prompt thường với “analyze”, “read”, “summarize”
  • AI đọc file và xây dựng understanding

Giai đoạn Plan:

  • /plan — Kích hoạt Plan Mode, ngăn execution code
  • Think mode với extended thinking cho lý luận phức tạp

Giai đoạn Execute:

  • Interactive mode cho implementation từng bước
  • Full auto mode cho execution đã plan kỹ

Insight quan trọng: bạn không cần tính năng built-in để dùng pattern. Pattern là về kỷ luật prompting, không phải về toggles và settings.


Anti-Patterns Cần Tránh

1. Bỏ qua Think cho thay đổi “đơn giản” nhưng thực ra không đơn giản. “Chỉ đổi tên User model thành Account” nghe đơn giản. Nhưng nó ảnh hưởng mọi file tham chiếu User. Think trước.

2. Plan quá rộng. “Plan toàn bộ kiến trúc ứng dụng” quá mơ hồ. Plan từng component một. Mỗi giai đoạn Plan nên cho ra kế hoạch execute được trong 3-5 bước.

3. Lệch khỏi kế hoạch khi Execute. Bạn đã có kế hoạch. Theo nó. Nếu phát hiện điều bất ngờ khi execute, dừng lại. Quay về Plan. Điều chỉnh. Rồi tiếp tục execute.

4. Gộp các giai đoạn trong một prompt. “Phân tích auth module rồi viết lại dùng JWT” gộp Think và Execute trong cùng prompt. Claude lướt qua phân tích và vội vàng implement. Tách chúng ra.


Tóm Lại

  1. Think trước Plan, Plan trước Execute. Mỗi giai đoạn giảm rủi ro và chi phí cho giai đoạn sau.
  2. Giai đoạn Think là bảo hiểm rẻ nhất. Đọc file tốn vài cent. Viết lại code tốn vài dollar.
  3. Kế hoạch bắt lỗi thiết kế trước khi thành lỗi code. Review kế hoạch trong 30 giây; review code trong 30 phút.
  4. Điều chỉnh độ sâu theo kích thước task. Task nhỏ có thể nhảy thẳng Execute. Task lớn cần cả ba giai đoạn.
  5. Dùng “Chưa thay đổi gì” làm power phrase. Nó buộc Claude vào chế độ phân tích và ngăn execute quá sớm.

Pattern này đã trở nên tự nhiên đến mức tôi không nghĩ về nó nữa. Nó đơn giản là cách tôi làm việc với Claude Code. Và kết quả tự nói — chất lượng cao hơn, chi phí thấp hơn, ít frustration hơn.


Pattern Think-Plan-Execute được trình bày chi tiết trong Phase 6: Thinking & Planning của khóa học Claude Code Mastery. Phases 1-3 miễn phí.