Plan Mode trong Claude Code: Hướng dẫn từng bước và 4 giai đoạn trong năm 2026

Hướng dẫn bổ sung có trong tài liệu Ailoot.

Plan Mode là gì, và vì sao chỉ riêng nó vẫn chưa đủ?#

Ở chế độ thông thường, Claude Code viết mã ngay lập tức; nếu bạn không theo dõi, bạn có thể bất ngờ nhận được một diff trên nhiều tệp. Plan Mode đảo ngược trình tự: trước tiên là nghiên cứu và lập kế hoạch, sau đó phê duyệt, rồi mới thay đổi.

Anthropic mô tả Plan Mode trong tài liệu chính thức như sau:

Nghe có vẻ đơn giản, nhưng điều đó che khuất thay đổi cốt lõi. Plan Mode thay đổi nhịp độ làm việc: thống nhất trước, hành động sau. Đây là thay đổi chế độ, không phải chỉnh sửa cho đẹp. Điều khiến những người lập trình theo cảm hứng khó chịu là các tác nhân AI thường vội vàng. Nếu bạn yêu cầu “Thêm xác thực Google” ở chế độ thông thường, Claude sẽ viết mã trong một phút, nhưng một nửa số tệp sẽ sai. Trong Plan Mode, cùng yêu cầu đó trở thành một kế hoạch dạng văn bản mà bạn có thể đọc trong hai phút và chỉnh sửa trước khi bất kỳ mã nào bị đụng đến.

Đây là một cái bẫy không ai đề cập trong các hướng dẫn quốc tế. Chỉ riêng Plan Mode là một công cụ yếu: kế hoạch chỉ tồn tại trong cuộc trò chuyện hiện tại. Đóng cửa sổ là mất kế hoạch. Bạn không thể bàn giao kế hoạch cho tác nhân khác. Không có phiên bản hay lịch sử. Nếu tác vụ lớn (tái cấu trúc mô-đun gồm 30 tệp, chuyển sang cơ sở dữ liệu mới), kế hoạch sẽ nhanh chóng chạm giới hạn cửa sổ ngữ cảnh và bắt đầu suy giảm.

Đó là lý do Plan Mode hoạt động tốt khi kết hợp với thư mục plans/ trong kho mã. Kế hoạch được lưu dưới dạng plans/2026-05-21-google-oauth.md, chia thành các giai đoạn có hộp kiểm, và tác nhân tiếp theo có thể tiếp tục từ đó. Đó là cách kỹ thuật ngữ cảnh hoạt động—quản lý ngữ cảnh trước câu lệnh, chứ không phải trong lúc viết câu lệnh.

Cách bật Plan Mode trong Claude Code#

Cách nhanh nhất trong phiên làm việc là dùng bàn phím:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

Sau hai lần nhấn, chỉ báo ⏸ plan mode on sẽ xuất hiện ở cuối terminal. Nhấn lần thứ ba sẽ trở về chế độ thông thường. Đây là phương pháp tiện nhất—bạn có thể bật ngay khi thấy tác vụ ngày càng lớn.

Cách thứ hai là thêm tiền tố trước một câu lệnh duy nhất:

/plan write a plan to migrate the database from MySQL to Postgres

Tùy chọn này hữu ích khi bạn đang ở chế độ tự động chấp nhận và không muốn thay đổi chế độ cho toàn bộ phiên làm việc. Một yêu cầu chạy trong Plan Mode, sau đó công việc tiếp tục như trước.

Cách thứ ba là bật khi khởi chạy phiên:

claude --permission-mode plan

Dùng cách này khi bạn biết trước tác vụ cần lập kế hoạch. Ví dụ, trước một đợt tái cấu trúc lớn hoặc một lần chuyển đổi.

Cách thứ tư là đặt mặc định trong .claude/settings.json của dự án:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Khi nào cách này hữu ích? Khi một nhóm đang làm việc trên hệ thống phức tạp, nơi mọi thay đổi đều có thể ảnh hưởng đến các mô-đun liền kề. Khi đó, Plan Mode mặc định bảo vệ mọi người khỏi những thay đổi vô tình.

Một mẹo thứ năm thường bị bỏ qua: Ctrl+G mở kế hoạch trong trình soạn thảo văn bản. Hãy dùng khi kế hoạch gần đúng nhưng bạn cần diễn đạt lại 2-3 ý hoặc thêm một ràng buộc. Chỉnh sửa thủ công, lưu lại, rồi Claude sẽ tiếp tục với phiên bản của bạn.

4 giai đoạn chuẩn của Anthropic trong Plan Mode là gì: Explore, Plan, Implement, Commit?#

Nhiều hướng dẫn mô tả 3 giai đoạn (Explore-Plan-Execute) hoặc chỉ 2 (Plan-Implement). Đó là những cách đơn giản hóa. Trong hướng dẫn thực hành tốt nhất chính thức, Anthropic mô tả chính xác 4 giai đoạn. Sự khác biệt này rất quan trọng: tách Commit thành một giai đoạn riêng giúp bạn ghi lại kết quả thay vì dừng ở câu “Tôi vừa chỉnh thêm vài chỗ, để sau tôi commit”—đây là nguyên nhân phổ biến nhất khiến công việc bị thất lạc.

Kế hoạch càng chính xác, việc triển khai càng cần ít vòng lặp. Nếu bạn dành 10 phút cho kế hoạch, việc triển khai chỉ cần một câu lệnh. Nếu bạn phác thảo kế hoạch trong một phút, việc triển khai sẽ cần cả giờ sửa lỗi.

Dưới đây là 4 giai đoạn khi thêm Google OAuth (ví dụ từ Anthropic Docs):

Câu lệnh cũng khác nhau ở từng giai đoạn. Ở Explore: “đọc /src/auth và tìm hiểu cách chúng ta xử lý phiên và đăng nhập”. Ở Plan: “Tôi muốn thêm Google OAuth. Cần thay đổi những tệp nào? Hãy tạo kế hoạch”. Ở Implement: “triển khai luồng OAuth theo kế hoạch của bạn, viết kiểm thử, chạy bộ kiểm thử và sửa lỗi”. Ở Commit: “tạo commit với thông điệp mô tả và mở PR”.

Một điểm cần lưu ý: Plan Mode không ngăn Claude chạy lệnh để nghiên cứu. Read, LS, Glob, Grep, web fetch và các lệnh shell dùng để khám phá đều được phép. Chỉ Edit, Write và mọi thao tác hệ thống tệp làm thay đổi dữ liệu là bị cấm. Điều này có nghĩa Claude có thể đọc cấu trúc dự án, chạy git log và xem các bài kiểm thử—nhưng không thể vô tình thay đổi bất cứ thứ gì.

Cách đọc kế hoạch của Claude và quyết định có phê duyệt hay không#

Khi Claude tạo xong kế hoạch, Claude sẽ đưa ra các lựa chọn về việc cần làm tiếp theo:

• Phê duyệt và bắt đầu ở chế độ tự động
• Phê duyệt và chấp nhận các chỉnh sửa
• Phê duyệt và xem lại thủ công từng chỉnh sửa
• Tiếp tục lập kế hoạch với phản hồi
• Tinh chỉnh bằng Ultraplan (xem lại trong trình duyệt)

Biết khi nào nên phê duyệt một kế hoạch là kỹ năng then chốt trong Plan Mode. Rất dễ nhấn “Approve” theo phản xạ rồi phải hoàn tác các commit. AI xu nịnh muốn trả lời nhanh, còn bạn muốn chuyển sang viết mã nhanh hơn. Cả hai đều sai.

Một kế hoạch tốt đáp ứng 7 tiêu chí:

1. Tên tệp cụ thể. Không phải “Tôi sẽ cập nhật auth”, mà là “Tôi sẽ sửa src/auth/login.ts:42-58, tạo src/auth/oauth-callback.ts và cập nhật src/auth/session.ts:103.”
2. Trình tự được xác định. Kế hoạch được chia thành các giai đoạn hoặc bước, thay vì “Tôi sẽ làm tất cả những việc này đâu đó.”
3. Nêu rõ các phụ thuộc bên ngoài. Nếu tác vụ cần thư viện mới, hãy liệt kê. Nếu cần biến môi trường, cũng hãy liệt kê.
4. Liệt kê rủi ro. Một kế hoạch tốt nói: “Việc di chuyển có thể làm hỏng các phiên hiện có; cần kiểm tra X.” Kế hoạch kém thì không đề cập tác dụng phụ.
5. Có tiêu chí thành công. “Các bài kiểm thử trong test/auth chạy thành công, linter không báo lỗi và máy chủ phát triển khởi động không lỗi.”
6. Không có giả định “tự nghĩ ra”. Nếu Claude nói “Tôi sẽ dùng thư viện Z”, hãy kiểm tra: bạn đã cài thư viện đó trong dự án chưa? Nếu AI bịa ra, bạn sẽ thấy nó không được đề cập trong package.json.
7. Kế hoạch vừa trên màn hình. Nếu kế hoạch cho một tính năng đơn giản dài đến 200 dòng thì có lẽ tác vụ quá lớn để gói trong một kế hoạch. Hãy chia thành nhiều phần.

Khi kế hoạch không vượt qua bước kiểm tra, có ba lựa chọn:

• Tiếp tục lập kế hoạch với phản hồi—đưa cho Claude nhận xét cụ thể về điều bạn không thích, Claude sẽ viết lại kế hoạch.
• Ctrl+G—mở kế hoạch trong trình soạn thảo, chỉnh sửa thủ công rồi lưu. Claude sẽ tiếp tục với phiên bản của bạn.
• Tinh chỉnh bằng Ultraplan—kế hoạch được chuyển sang chế độ trình duyệt trên web của Claude Code, nơi bạn xem lại các phần và bình luận, sau đó chạy cục bộ hoặc trên đám mây.

Nếu có vấn đề giữa lúc triển khai, đừng cố làm cho bằng được. Quay lại Plan Mode và viết lại kế hoạch. Cách đó rẻ hơn 10 lần so với việc hoàn tác 40 commit sau này.

Plan Mode + thư mục plans/: kết hợp để xử lý ngữ cảnh dài#

Plan Mode là một chế độ của Claude Code. Thư mục plans/ là phương pháp được xây dựng dựa trên chế độ đó. Nếu dùng Plan Mode mà không có thư mục, bạn sẽ chạm giới hạn sau một giờ làm việc.

Logic như sau. Cửa sổ ngữ cảnh của Claude là bộ nhớ của phiên làm việc. Nó có thể chứa 1 triệu token trong Opus 4.7, nhưng đó là dung lượng dành cho toàn bộ cuộc trò chuyện. Nếu bạn lên kế hoạch cho một tác vụ phức tạp trong một cuộc trò chuyện, rồi yêu cầu triển khai, sau đó thảo luận về lỗi, rồi chuyển sang việc khác, cửa sổ sẽ bị “phình to”. Claude bắt đầu quên các quyết định ban đầu, nhầm lẫn ngữ cảnh và hỏi lại.

Giải pháp là quy tắc vàng: một tác vụ—một cuộc trò chuyện.

Cách thực hiện:

1. Cuộc trò chuyện 1—lập kế hoạch. Bật Plan Mode, mô tả tác vụ và Claude sẽ tạo kế hoạch. Lưu kế hoạch vào plans/2026-05-21-feature-name.md. Đóng cửa sổ.
2. Cuộc trò chuyện 2—chia kế hoạch thành các giai đoạn. Mở cuộc trò chuyện mới. Yêu cầu: “lấy plans/2026-05-21-feature-name.md và chia thành các giai đoạn.” Lưu tệp đã cập nhật.
3. Cuộc trò chuyện 3—triển khai giai đoạn 1. Mở cuộc trò chuyện mới. Yêu cầu: “triển khai Giai đoạn 1 từ plans/2026-05-21-feature-name.md, và đánh dấu các mục khi hoàn thành.” Đóng cửa sổ.
4. Cuộc trò chuyện 4—triển khai giai đoạn 2. Làm tương tự.

Cách này giúp gì cho bạn? Cửa sổ ngữ cảnh của mỗi cuộc trò chuyện luôn mới. Claude ở giai đoạn 3 không biết chi tiết của giai đoạn 1, nhưng biết kế hoạch vì tệp plans/ nằm trong kho mã. Tác nhân tiếp theo (dù là tác nhân phụ, phiên mới hay một lần chạy qua /goal) đều có thể tiếp tục kế hoạch.

So sánh các cách tiếp cận:

Mỗi tính năng có tệp kế hoạch riêng. Khi cần nhớ lại sau ba tháng vì sao bạn chọn một nhà cung cấp thanh toán thay vì phương án khác, bạn có thể mở kế hoạch liên quan và đọc lịch sử quyết định: đã thảo luận điều gì, cân nhắc những lựa chọn nào và vì sao chọn hướng đi này.

Đây là các kế hoạch công việc đang được cập nhật; tài liệu tĩnh sẽ lỗi thời chỉ sau vài tháng.

Cách để Claude làm việc trong khi bạn ngủ bằng Plan Mode và /goal?#

Hạn chế chính của các phiên AI dài không nằm ở bản thân mô hình, mà ở người nhấn Enter. Mỗi lần Claude kết thúc một lượt, nó chờ bạn phản hồi. /goal loại bỏ thời gian chờ đó.

Cú pháp rất đơn giản:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

Điều kiện có thể dài tối đa 4000 ký tự. Mỗi phiên chỉ có một mục tiêu. Sau mỗi lượt, mô hình mini Haiku xem bản ghi hội thoại và quyết định: “đã đạt điều kiện—kết thúc” hoặc “chưa đạt—sang lượt tiếp theo”. Bộ đánh giá không gọi công cụ; nó chỉ đọc.

Các bí danh để xóa mục tiêu: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Kết hợp với Plan Mode như sau:

1. Bật Plan Mode (nhấn Shift+Tab hai lần).
2. Yêu cầu: “tạo kế hoạch chuyển cơ sở dữ liệu từ MySQL sang Postgres, lưu vào plans/2026-05-21-postgres-migration.md với các giai đoạn và tiêu chí.”
3. Xem lại kế hoạch, chỉnh sửa rồi phê duyệt.
4. Thoát Plan Mode (nhấn Shift+Tab thêm một lần).
5. Đặt mục tiêu: “hoàn thành tất cả các giai đoạn trong plans/2026-05-21-postgres-migration.md, đánh dấu các ô, tất cả kiểm thử đều vượt qua, hoặc dừng sau 50 lượt.”
6. Đóng máy tính và đi ngủ.

Buổi sáng, kiểm tra kết quả: hoặc “✓ goal completed” hoặc “◎ stopped after 50 turns”, cùng lịch sử những việc đã thực hiện.

Có ba quy tắc thiết yếu cho /goal, nếu không bạn sẽ lãng phí token:

Quy tắc 1: Trạng thái cuối có thể đo lường. “Làm cho đẹp mắt” là yêu cầu tệ. “npm test trả về 0, npm run lint trả về 0 và đã thêm một mục vào CHANGELOG.md” là yêu cầu tốt.

Quy tắc 2: Xác minh rõ ràng. Điều kiện cần đề cập đến thứ có thể xác minh: một lệnh, tệp hoặc endpoint. Không phải “mọi thứ đều hoạt động”, mà là “curl localhost:3000/api/users trả về 200.”

Quy tắc 3: Giới hạn số lượt. Luôn thêm or stop after N turns. Anthropic khuyến nghị rõ ràng điều này trong tài liệu:

Nếu bật /goal mà không có or stop after, ngân sách của bạn có thể biến mất qua đêm.

Chu kỳ 4 bước nào biến Plan Mode thành một quy trình kỹ thuật?#

Một sai lầm phổ biến là hỏi “làm sao để sửa?”: Claude đưa ra giải pháp, bạn áp dụng, nhưng không có gì hiệu quả hoặc mọi việc còn tệ hơn. Đây là “AI xu nịnh”: AI được huấn luyện để trả lời nhanh, còn bạn muốn chuyển sang viết mã nhanh hơn. Chu kỳ 4 bước giải quyết vấn đề này.

Chu kỳ 4 bước ngăn kiểu làm việc này. Chu kỳ được thực hiện tuần tự trong một phiên Plan Mode:

Bước 1. Xác lập sự thật mà chưa đưa ra giải pháp.

Câu lệnh: “Tôi đang gặp tình trạng sau: [mô tả triệu chứng]. Nhiệm vụ của bạn lúc này là xác lập sự thật. Nghiêm cấm mọi giải pháp, ý tưởng và lời khuyên. Chỉ ghi nhận: tôi quan sát được gì, các bước nào có thể tái hiện, dữ liệu nào hiện có và dữ liệu nào còn thiếu. Điều kiện dừng cứng: KHÔNG đề xuất giải pháp; chỉ ghi lại chẩn đoán.”

Điều này chặn phản xạ đầu tiên của AI: “đây là giải pháp”. Claude phải dừng lại ở câu “đã biết gì và chưa biết gì”.

Bước 2. Phát triển các phương án có tiền lệ.

Câu lệnh: “Giờ khi đã xác lập chẩn đoán, hãy tìm các tiền lệ trực tuyến về cách giải quyết những vấn đề tương tự. Ít nhất 3 cách tiếp cận khác nhau. Với mỗi cách: liên kết đến nguồn sơ cấp, mô tả ngắn gọn, ưu và nhược điểm trong tình huống của chúng ta.”

Điều này chặn phản xạ thứ hai của AI: “tự nghĩ ra giải pháp ngay tại chỗ”. Ta yêu cầu AI bước ra thế giới và mang về các cách tiếp cận có thể kiểm chứng.

Bước 3. Lập kế hoạch chi tiết có xét rủi ro.

Câu lệnh: “Chọn phương án tốt nhất từ Bước 2 và lập kế hoạch chi tiết: cần chạm đến những tệp cụ thể nào, cần thêm gì, xóa gì, viết kiểm thử nào, điều gì có thể hỏng và rủi ro nào nằm trước 2-3 bước.”

Đây là giai đoạn Plan quen thuộc, nhưng có một khác biệt: nó dựa trên các phương án đã xác minh ở Bước 2, chứ không phải phỏng đoán của Claude.

Bước 4. Tự kiểm tra kế hoạch.

Câu lệnh: “Bây giờ hãy tự kiểm tra bắt buộc. Thành thật xem lại kế hoạch: có chỗ nào bạn tự nghĩ ra mà chưa xác minh với mã, tài liệu hoặc tiền lệ từ Bước 2 không? Nếu có, hãy đánh dấu và sửa lại kế hoạch.”

Đây là bộ lọc cuối cùng. Claude phải kiểm tra lại lập luận của chính mình và thừa nhận chỗ nào mình đã ảo giác. Thông thường, ít nhất 2 mục trong kế hoạch sẽ được sửa ở bước này.

Sau 4 bước, kế hoạch đã sẵn sàng để phê duyệt. Bạn chuyển sang triển khai với sự tự tin rằng tác vụ đã được hiểu, các phương án đã được cân nhắc và rủi ro đã được xem xét.

Phương pháp này dành cho việc chẩn đoán lỗi khó và đưa ra quyết định kiến trúc—những tình huống mà sai lầm phải trả giá đắt. Khi áp dụng vào Plan Mode, phương pháp loại bỏ nỗi đau lớn nhất của những người lập trình theo cảm hứng: “AI đưa ra giải pháp, tôi áp dụng và mọi thứ hỏng hết.”

5 câu lệnh sẵn dùng nào hiệu quả trong Plan Mode cho các tác vụ phổ biến?#

Mẫu 1. Tái cấu trúc mô-đun.

I'm enabling Plan Mode. Task: refactor the {module-name} module.

Step 1: Study the current structure of the {module-path} module. Describe:
- which files are part of the module
- which external dependencies it has
- which parts are duplicated
- which functions are overcomplicated

Step 2: Find 2-3 examples online of refactoring similar modules.
At least 1 source must be official Anthropic or related framework documentation.

Step 3: Create a refactoring plan in plans/YYYY-MM-DD-refactor-{module}.md:
- which files to rename
- which functions to extract into separate modules
- which tests to keep and which to rewrite
- risks: what could break for users

Step 4: Self-check. Are there any assumptions in the plan that are "pulled out of thin air"?
Rewrite or remove them.

Mẫu 2. Chuyển đổi cơ sở dữ liệu.

I'm enabling Plan Mode. Task: migrate the database from {old} to {new}.

Step 1: Study the current database schema using {schema-reading-command}. Describe:
- which tables exist and their size
- which relationships, indexes, and constraints there are
- where migrations are stored
- which data is critical

Step 2: Find precedents for {old → new} migrations in production projects.
At least 3 different approaches: pg_dump, dual-write, blue-green.
For each, list the pros and risks for our data size.

Step 3: Create a migration plan in plans/YYYY-MM-DD-db-migration.md:
- phases (backup, migration, verification, switchover)
- success criteria for each phase
- rollback plan if something goes wrong
- downtime or no downtime

Step 4: Self-check. Are all figures supported by documentation?
Have all steps been mentally checked against the dev environment?

Mẫu 3. Thêm tính năng mới.

I'm enabling Plan Mode. Task: add the {description} feature to the project.

Step 1: Study how similar features currently work in the project.
Specifically, look at:
- {file-1}
- {file-2}
- which architectural patterns are used
- which tests are written for similar features

Step 2: Find how this feature is implemented in open-source projects
with a similar architecture. At least 2 different approaches.

Step 3: Create a plan in plans/YYYY-MM-DD-feature-{name}.md:
- list of new files
- list of changed files with specific lines
- implementation sequence
- which tests to add
- what to add to CLAUDE.md as a rule for future sessions

Step 4: Self-check. Does the plan follow the project's architecture?
Does it assume libraries that haven't been installed yet?

Mẫu 4. Viết kiểm thử.

I'm enabling Plan Mode. Task: cover the {name} module with tests.

Step 1: Study the {path} module. Identify:
- public functions and their signatures
- internal functions we will NOT test (implementation details)
- edge cases: empty input, errors, concurrent access

Step 2: Find test examples for a similar class of tasks
in popular open-source projects using the same framework.

Step 3: Create a test plan in plans/YYYY-MM-DD-tests-{module}.md:
- for each public function, a list of tests
- which mocks are needed
- which fixtures
- which verification approach (assertion style)

Step 4: Self-check. Do all tests check behavior rather than implementation?
Does the coverage include edge cases?

Mẫu 5. Gỡ lỗi phức tạp.

I'm enabling Plan Mode. Task: understand the cause of the error {symptom-description}.

Step 1: ESTABLISH THE FACTS. Solutions and ideas are prohibited. Only:
- what I observe (exact wording of the error)
- reproducible steps
- what data is available (logs, traces, library versions)
- what data is missing (what needs to be collected additionally)

Step 2: Find precedents for this error.
At least 3 sources: issues and official documentation.
For each, provide a link and a brief summary of the solution.

Step 3: Create a diagnostic plan in plans/YYYY-MM-DD-bug-{name}.md:
- which hypotheses to check (sorted by likelihood)
- which commands/scripts to run to check each one
- the expected result of each check

Step 4: Self-check. Are there any hypotheses in the plan that are "pulled out of thin air"?
Are all hypotheses tied to facts from Step 1?

Sao chép từng mẫu, thay {parameters} bằng giá trị của bạn rồi dán vào Claude Code ở Plan Mode. Kết quả là một kế hoạch khả thi trong plans/ mà bạn có thể phê duyệt và dùng để triển khai.

Plan Mode hay chế độ thông thường: nên chọn chế độ nào?#

Anthropic nói rõ điều này trong tài liệu:

Chỉ bỏ kế hoạch riêng khi diff thực nhỏ, hiểu rõ và ít rủi ro. Lập kế hoạch khi cần tìm cách hoặc phối hợp đổi nguy hiểm giữa thành phần. Biết tên tệp hay tóm mục tiêu một câu không bỏ rủi ro migration, auth, toàn vẹn dữ liệu.

Bảng quyết định:

Trước chọn mode, hỏi cách làm, tác dụng phụ và kiểm chứng đã hiểu chưa. Làm trực tiếp thay đổi nhỏ, cục bộ, ít rủi ro có kiểm hiển nhiên. Lập trước khi bất định, mã lạ, migration, auth hoặc phối hợp thành phần, dù đã kể đủ 3-5 tệp ảnh hưởng.

Cách kết hợp Plan Mode + CLAUDE.md + tác nhân phụ để làm việc đáng tin cậy?#

CLAUDE.md là tệp Claude đọc khi bắt đầu mỗi phiên, bao gồm cả Plan Mode. Nếu CLAUDE.md ghi “không bao giờ mã hóa cứng ngày tháng; luôn lấy ngày từ cơ sở dữ liệu”, kế hoạch sẽ không bao giờ đề xuất mã hóa cứng. Nếu không có quy tắc đó, kế hoạch có thể đề xuất bất cứ điều gì.

Sự kết hợp này hoạt động như sau:

Lớp 1. CLAUDE.md đặt ra các quy tắc.

Tệp chỉ rõ công nghệ của dự án, nguyên tắc kiến trúc, điều cấm (“không dùng API đã lỗi thời”) và yêu cầu (“mọi email đều dùng chung một bố cục”). Hướng dẫn chi tiết: Cách cấu hình CLAUDE.md.

Lớp 2. Plan Mode áp dụng các quy tắc vào tác vụ.

Khi bật Plan Mode và yêu cầu “thêm OAuth”, Claude đọc CLAUDE.md, thấy các quy tắc (“lưu token trong Redis, không phải cơ sở dữ liệu”) và tính đến chúng ngay trong kế hoạch. Kế hoạch tuân theo kiến trúc dự án.

Lớp 3. Tác nhân phụ chia nhỏ công việc.

Nếu kế hoạch được chia thành các giai đoạn, mỗi giai đoạn có thể được giao cho một tác nhân phụ riêng. Mỗi tác nhân làm việc trong cửa sổ ngữ cảnh riêng mà không làm chật cửa sổ chính. Kế hoạch trong plans/ vẫn là nguồn thông tin chuẩn ở trung tâm: các tác nhân phụ đọc kế hoạch, thực hiện giai đoạn của mình và cập nhật hộp kiểm.

7 sai lầm nào làm hỏng Plan Mode?#

Sai lầm 1. Kế hoạch chỉ tồn tại trong cuộc trò chuyện.

Triệu chứng: bạn viết kế hoạch, đóng cửa sổ và cần quay lại vào ngày hôm sau—nhưng chẳng còn gì; ngữ cảnh đã mất. Giải pháp: luôn lưu kế hoạch trong plans/YYYY-MM-DD-feature-name.md ở kho mã. Cuộc trò chuyện là bàn làm việc; tệp là kho lưu trữ.

Sai lầm 2. Mọi tác vụ đều nằm trong một cuộc trò chuyện.

Triệu chứng: trong một phiên, bạn thảo luận về auth, rồi chuyển sang di chuyển dữ liệu, thiết kế UI và một lỗi. Cửa sổ ngữ cảnh bị “phình to”, Claude quên các nội dung trước đó. Giải pháp: một tác vụ—một cuộc trò chuyện. Xong kế hoạch thì đóng cửa sổ. Bắt đầu triển khai thì mở cửa sổ mới.

Sai lầm 3. Một kế hoạch dài 3000 dòng nhưng không có giai đoạn.

Triệu chứng: có kế hoạch nhưng không có hộp kiểm hay phần chia. Không thể biết việc gì đã xong và việc gì chưa. Cũng không thể giao việc. Giải pháp: chia mỗi kế hoạch thành 3-7 giai đoạn. Mỗi giai đoạn là một danh sách hộp kiểm với các hành động cụ thể.

Sai lầm 4. Không nghiên cứu sâu trước khi lập kế hoạch.

Triệu chứng: Claude tự nghĩ ra giải pháp vì bạn không yêu cầu tìm tiền lệ. Một tuần sau, bạn phát hiện mã nguồn mở đã có cách tốt hơn từ lâu. Giải pháp: dùng Bước 2 trong chu kỳ 4 bước—yêu cầu Claude tìm 2-3 tiền lệ trực tuyến trước khi tạo kế hoạch.

Sai lầm 5. AI xu nịnh đưa ra giải pháp mà chưa chẩn đoán.

Triệu chứng: bạn hỏi “làm sao sửa lỗi X?”, Claude đưa giải pháp, bạn áp dụng nhưng không hiệu quả hoặc tình hình còn tệ hơn. Giải pháp: luôn bắt đầu bằng “xác lập sự thật; nghiêm cấm giải pháp”. Chỉ sau khi chẩn đoán mới chuyển sang các phương án.

Sai lầm 6. Bỏ qua bước tự kiểm tra.

Triệu chứng: kế hoạch trông có vẻ hợp lý nhưng chứa 2-3 giả định “tự nghĩ ra” (thư viện bịa ra, API không tồn tại hoặc phiên bản sai). Việc triển khai sẽ thất bại ở những điểm đó. Giải pháp: dùng Bước 4 trong chu kỳ 4 bước—yêu cầu Claude thành thật kiểm tra lại kế hoạch và chỉ ra các giả định.

Sai lầm 7. Điều kiện mơ hồ trong /goal.

Triệu chứng: bạn đặt /goal make it look nice, để chạy qua đêm rồi thức dậy thấy 200 đô hạn mức đã bị tiêu hết. Giải pháp: chỉ dùng điều kiện có thể đo lường, kèm lệnh xác minh và yêu cầu bắt buộc or stop after N turns. Không dùng “làm cho tốt” hay “trau chuốt thêm”.

Sai lầm thứ tám, mà những người lập trình theo cảm hứng thường mắc nhất, là bỏ qua chính khái niệm thư mục plans/. Plan Mode không có thư mục plans/ không phải là phương pháp; nó chỉ là món đồ chơi. Nếu dùng Plan Mode nhưng không tạo tệp, bạn chỉ khai thác được 10% khả năng của nó.

Sau trải nghiệm đầu tiên với Plan Mode, bạn nên làm gì tiếp theo?#

Ba bước cụ thể theo mức độ khó tăng dần:

Bước 1. Cấu hình CLAUDE.md nếu bạn chưa có.

Không có CLAUDE.md, Plan Mode hoạt động “trong khoảng không”—Claude không biết quy tắc của dự án và đề xuất kế hoạch phá vỡ kiến trúc. Hướng dẫn đầy đủ: Cách cấu hình CLAUDE.md. Một CLAUDE.md tối thiểu dài 50-80 dòng, mô tả công nghệ, quy tắc và điều cấm. Độ dài không quan trọng bằng tính cụ thể.

Bước 2. Tạo thư mục plans/ trong kho mã.

Thêm thư mục plans/ vào thư mục gốc của dự án. Thống nhất định dạng đặt tên: YYYY-MM-DD-feature-name.md. Mỗi kế hoạch có tệp riêng. Sau một tháng, bạn sẽ có 20-30 tệp; sau sáu tháng là hơn 100. Đó là lịch sử quyết định của dự án, luôn được cập nhật.

Bước 3. Thử /goal với một tác vụ.

Chọn một tác vụ bạn thường làm thủ công trong 30-40 phút. Bật Plan Mode, tạo kế hoạch và lưu vào plans/. Thoát Plan Mode. Đặt /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. Đóng máy tính trong một giờ và làm việc khác. Sau đó quay lại kiểm tra kết quả.

Ba bước đó là mức tối thiểu. Mọi thứ được xây dựng dần dần; đừng cố gắng hoàn tất tất cả trong một buổi tối. Bắt đầu với CLAUDE.md, thêm plans/ sau một tuần và thử /goal qua đêm sau một tháng.

Khi sẵn sàng, hãy gặp Ailoot.