Có một kịch bản quen: bạn giao cho CC một task lớn, nó bắt đầu sửa file ngay lập tức, và đến khi bạn nhận ra nó đang đi theo hướng sai thì đã có 12 file thay đổi. Rollback là được nhưng mất thời gian, và quan trọng hơn là bạn không có cơ hội can thiệp trước khi nó bắt đầu.

Plan mode giải quyết đúng vấn đề đó. Thay vì để model lao vào thực thi, bạn yêu cầu nó viết kế hoạch trước, bạn đọc qua, có thể chỉnh hoặc từ chối, rồi mới approve cho chạy. Một vòng review ngắn nhưng giúp tránh được những thay đổi không mong muốn ở phạm vi lớn.

Bài này giải thích cách plan mode hoạt động, file state được lưu ở đâu, và sự khác biệt giữa ba khái niệm hay bị nhầm lẫn: plan, todo, và memory.

Plan mode là gì

Plan mode là một chế độ đặc biệt trong CC, trong đó model bị yêu cầu chỉ được produce kế hoạch, không được thực thi tool destructive trực tiếp. Kế hoạch được hiển thị cho user xem. User có ba lựa chọn: approve, reject, hoặc yêu cầu chỉnh sửa kế hoạch.

Đây không phải hành vi mặc định. CC không tự enter plan mode cho mọi task. Bạn phải trigger nó, hoặc model sẽ tự propose vào plan mode khi task đủ phức tạp.

Hai cách trigger

1. User gõ /plan     -> CC enter plan mode ngay
2. CC tự propose     -> khi model nhận ra task lớn,
                        nhiều file, nhiều bước,
                        nó có thể tự hỏi "lập plan trước không?"

Trường hợp 2 không guaranteed. CC không phải lúc nào cũng propose plan mode. Nếu bạn muốn luôn có bước review trước với task lớn, dùng /plan trực tiếp.

Workflow chi tiết

Khi trong plan mode, vòng đời một plan trải qua các bước:

+-------------------------------+
|   User gõ /plan <task>        |
+-------------------------------+
            |
            v
+-------------------------------+
|   Model write plan            |
|   (markdown, không thực thi) |
+-------------------------------+
            |
            v
+-------------------------------+
|   User đọc plan               |
|   -> approve                  |
|   -> reject / yêu cầu sửa    |
|   -> chỉnh trực tiếp file    |
+-------------------------------+
            |
       (approve)
            |
            v
+-------------------------------+
|   Model gọi ExitPlanMode tool |
|   -> exit plan mode           |
|   -> bắt đầu thực thi        |
+-------------------------------+

Khi user reject hoặc yêu cầu sửa: model viết lại plan, vòng review tiếp tục. User không bị buộc phải approve. Bạn có thể kết thúc plan mode bằng /exit hoặc đóng session mà không commit thực thi gì cả.

ExitPlanMode tool

Đây là tool model tự gọi sau khi nhận approval. Bạn không gọi nó trực tiếp. Khi tool này fire, CC chuyển trạng thái nội bộ từ “plan mode” sang “execution mode” và bắt đầu dùng Bash, Edit, Write như bình thường.

Một điểm quan trọng: nếu user nói “ok, làm đi” nhưng không nói rõ ràng “tôi approve plan này”, model đôi khi không gọi ExitPlanMode mà lại đặt câu hỏi thêm. Khi thấy điều này, bạn cần nói rõ hơn: “approve, chạy theo plan” hay tương tự.

File state: plan lưu ở đâu

Plan được lưu vào ~/.claude/plans/<slug>.md. Slug do CC tự generate (ngẫu nhiên) khi plan được tạo.

~/.claude/plans/
├── fuzzy-badger-a3b9.md
├── silver-phoenix-c71d.md
└── ...

Việc file này có được git track hay không phụ thuộc vào bạn. Mặc định ~/.claude/plans/ là thư mục dưới ~/.claude/ và nếu bạn track ~/.claude/ như một git repo (branch-per-machine, xem bài 22), bạn có thể chọn commit hoặc gitignore folder plans/.

Tip: đổi tên file plan thành tên có nghĩa ngay sau khi tạo, trước khi ra khỏi session. Slug mặc định như fuzzy-badger-a3b9 không nói lên gì cả. Đặt lại thành plans/refactor-auth-module-2026-05.md sẽ dễ tìm lại hơn nhiều.

Resume plan sau session

Nếu bạn tạo plan hôm nay nhưng chưa thực thi, muốn quay lại vào ngày mai:

  1. Mở session mới.
  2. Gõ /plan để vào plan mode.
  3. Chỉ model đường dẫn đến file plan: “load plan từ ~/.claude/plans/my-refactor.md, tiếp tục từ đây”.
  4. Model đọc file, hiển thị lại plan, chờ approval.

Không có cơ chế auto-resume tự động. Bạn phải làm bước 3 thủ công.

Plan khác todo khác memory như thế nào

Ba khái niệm này giải quyết ba bài toán khác nhau. Hay bị nhầm lẫn vì tên gợi ý chức năng tương tự nhau (“ghi nhớ thứ gì đó”), nhưng scope và lifecycle rất khác.

Khái niệmTạo bởiLưu ở đâuExpire khi nàoMục đích
PlanModel (qua /plan)~/.claude/plans/*.mdTask done (thủ công xóa)User review trước khi execute
TodoModel (qua TodoWrite tool)In-memory, session-scopedSession kết thúcTrack tiến độ trong session
MemoryModel (qua MemoryWrite)~/.claude/projects/.../memory/ hoặc autoMemoryDirectoryKhông (persist)Cross-session context

Plan

Đây là document deliberate, user đọc và approve. Nó tồn tại để align expectation trước khi code bị thay đổi. Sau khi task xong, plan không tự động xóa. Bạn quyết định giữ hay xóa.

Todo

Todo là danh sách task ngắn trong session, tạo bởi TodoWrite tool. Bạn có thể thấy nó xuất hiện khi CC nói “tôi sẽ làm 3 việc: 1) …, 2) …, 3) …”. Đây là in-memory task list giúp model và user theo dõi tiến độ trong session hiện tại.

Todo không được review/approve trước khi thực thi. Model tạo todo rồi thực thi luôn. Khi session kết thúc, todo biến mất.

Nếu bài toán cần user review: dùng plan. Nếu chỉ cần track progress trong session: todo là đủ.

Memory

Memory persist xuyên session. Nó ghi lại quyết định kiến trúc, convention, context dài hạn để session sau không phải learn lại. Memory không có bước user review vì nó không làm thay đổi code.

Bài 12-14 đi sâu hơn vào memory. Ở đây chỉ cần nhớ: plan expire theo task, memory expire không bao giờ (cho đến khi bạn xóa thủ công).

Khi nào dùng plan mode

Nên dùng

Refactor lớn nhiều file. Khi task liên quan đến 5 file trở lên hoặc thay đổi kiến trúc module, plan mode giúp bạn xác nhận trình tự thực thi trước khi bất kỳ file nào bị chạm vào.

Migration hoặc schema change rủi ro. Database migration, đổi API contract, rename field lan rộng. Đây là những thao tác mà nếu làm sai giữa chừng sẽ để lại codebase ở trạng thái broken. Có plan giúp bạn kiểm tra logic trước.

Task model uncertainty cao. Khi bạn không rõ cách model sẽ approach, hoặc task có nhiều cách làm hợp lý với trade-off khác nhau, plan mode giúp bạn thấy model đang nghĩ gì và redirect sớm nếu hướng không phù hợp.

Khi bạn muốn có audit trail. Plan file được lưu lại. Nếu ba tháng sau bạn tự hỏi “tại sao lúc đó làm vậy”, có plan document là dễ truy ngược hơn nhiều.

Không cần dùng

  • Sửa một bug rõ ràng trong 1-2 file, root cause đã được xác định.
  • Câu hỏi exploration (“giải thích cái này cho tôi”).
  • Thay đổi nhỏ: rename biến, sửa comment, format code.
  • Task bạn đã quen và biết CC sẽ làm đúng.

Plan mode có chi phí: thêm một vòng review. Với task nhỏ, chi phí đó không xứng với lợi ích. Dùng plan mode có chọn lọc thì giá trị mới cao.

Viết plan tốt là gì

Khi model produce plan, bạn đọc và có thể sửa trực tiếp trong file plan hoặc hướng dẫn model viết lại. Một plan tốt thường có:

  • Danh sách file sẽ bị thay đổi (không phải mọi file sẽ được đọc, chỉ file sẽ bị edit/create/delete).
  • Trình tự thực thi có lý do (bước A trước B vì B phụ thuộc A).
  • Rủi ro hoặc điểm không chắc chắn cần confirm với user.

Plan không cần dài. Một plan 10-15 dòng rõ ràng tốt hơn plan 50 dòng nhưng đầy chi tiết implementation mà chỉ model cần biết.

Pitfall phổ biến: plan quá dài

Model có xu hướng viết plan chi tiết vì chi tiết giúp nó planning tốt hơn. Nhưng user không cần đọc mọi chi tiết đó. Nếu plan dài quá và bạn thấy mệt khi đọc, có thể yêu cầu trực tiếp:

Plan này quá dài. Rút ngắn còn tập trung vào:
1. File nào bị chạm
2. Trình tự thực thi
3. Điểm rủi ro cần tôi confirm

Model sẽ viết lại plan ngắn hơn.

Pitfall thứ hai: approve mà không đọc

Plan mode chỉ có giá trị nếu bạn thực sự đọc plan. Approve qua loa vì “chắc đúng rồi” thì tương đương không dùng plan mode. Nếu task đủ nhỏ để bạn tin tưởng model không cần review, đừng dùng plan mode.

Ví dụ minh họa: refactor auth module

Giả sử task: “Refactor module auth để tách JWT logic ra một service riêng, cập nhật mọi chỗ import.”

Không có plan mode, CC có thể:

  • Bắt đầu tạo file mới, edit 8 file, nhưng bỏ sót 2 file import cũ.
  • Codebase biên dịch nhưng có bug runtime lúc 3h sáng.

Với plan mode:

Plan: Tách JWT logic
1. Tạo src/services/jwt.service.ts (move logic từ src/auth/auth.service.ts)
2. Cập nhật src/auth/auth.service.ts: bỏ JWT code, import jwt.service
3. Cập nhật src/middleware/auth.middleware.ts: import từ jwt.service thay vì auth.service
4. Cập nhật src/controllers/user.controller.ts: tương tự
5. Cập nhật tests: auth.service.test.ts, jwt.service.test.ts (tạo mới)
Rủi ro: cần grep toàn bộ codebase xem còn import nào từ auth.service không trước bước 5.

Bạn đọc qua 30 giây, thấy có 2 controller khác cũng cần cập nhật mà plan không kể đến. Bạn bổ sung, approve, CC thực thi với danh sách đầy đủ.

Tóm tắt và bài tiếp theo

  • Plan mode là chế độ CC viết kế hoạch trước, user review, approve thì mới thực thi. Trigger bằng /plan hoặc CC tự propose.
  • Plan lưu vào ~/.claude/plans/<slug>.md. Resume bằng cách load file trong session mới. Đổi tên slug ngay sau khi tạo để dễ tìm.
  • Plan khác todo (in-session task list, không review), khác memory (persist xuyên session, không expire).
  • Dùng plan mode cho refactor lớn, migration rủi ro, task uncertainty cao. Không cần cho small fix hoặc exploration.
  • Plan tốt: ngắn, focus vào file bị chạm, trình tự có lý do, điểm rủi ro nổi bật. Nếu model produce plan quá dài, yêu cầu rút ngắn trực tiếp.

Một khi bạn nhận ra một workflow nào đó lặp đi lặp lại nhiều lần (ví dụ “mỗi lần deploy mình đều plan theo cùng một checklist”), đó là lúc đáng để wrap nó thành một skill. Bài 24 sẽ đi vào cách biến một pattern lặp lại thành skill production-grade.

Bài thuộc series Claude Code từ zero. Series plan tại bài giới thiệu.