Trả lời nhanh: Plan mode là chế độ agent chỉ được đọc và khảo sát, không được sửa file, cho tới khi trình cho bạn một kế hoạch và bạn duyệt. Giá trị lớn nhất không phải là an toàn mà là bạn phát hiện agent hiểu sai yêu cầu trước khi nó viết ba trăm dòng theo hướng sai. Dùng cho việc đụng nhiều file hoặc chạm tới thiết kế. Với việc nhỏ và rõ ràng thì bật chế độ này chỉ thêm một vòng chờ vô ích.
Cảnh quen thuộc: bạn mô tả một tính năng, agent lao vào sửa mười file, và tới lúc đọc lại bạn mới thấy nó hiểu nhầm ngay từ câu đầu. Lúc đó bỏ thì tiếc mà giữ thì phải sửa nhiều hơn viết mới. Chế độ lập kế hoạch sinh ra để bắt lỗi hiểu nhầm ở phút thứ hai thay vì phút thứ ba mươi.
Chế độ này thật ra làm gì
Khi bật, agent bị giới hạn ở các thao tác đọc: mở file, tìm kiếm, xem cấu trúc thư mục. Nó không sửa được gì, không chạy được lệnh thay đổi hệ thống. Sau khi khảo sát, nó trình một kế hoạch gồm những file định sửa và cách tiếp cận, rồi dừng lại chờ bạn.
Bạn có ba lựa chọn: duyệt để nó bắt tay làm, sửa hướng rồi bảo lập lại kế hoạch, hoặc bỏ hẳn nếu thấy cách tiếp cận sai từ gốc.
Điểm khác biệt so với việc bạn tự dặn agent hãy lên kế hoạch trước: đây là ràng buộc kỹ thuật chứ không phải lời nhắc. Dặn bằng lời thì agent lập kế hoạch xong vẫn hay làm luôn, nhất là trong phiên dài khi lời dặn đã trôi xa. Nguyên tắc này giống hệt phân biệt giữa luật và hàng rào ở bài về hooks.
Khi nào nên bật
Bốn tình huống đáng bật:
- Việc đụng nhiều file. Càng nhiều file thì hiểu nhầm càng đắt, vì sửa lại phải rà khắp nơi.
- Việc chạm tới thiết kế. Thêm một bảng database, đổi cấu trúc dữ liệu trao đổi, tách một module. Đây là loại quyết định khó quay lui.
- Bạn chưa nói hết yêu cầu. Nhiều khi chính bạn cũng chưa nghĩ tới các trường hợp biên, và kế hoạch của agent làm lộ ra chúng.
- Repo lạ. Bạn mới nhận dự án và chưa biết code nằm ở đâu. Kế hoạch của agent lúc này còn có tác dụng như một bản đồ.
Ngược lại, đừng bật khi bạn chỉ cần sửa một dòng, đổi một chuỗi, hay thêm một trường vào biểu mẫu. Những việc đó bạn kiểm chứng kết quả nhanh hơn là đọc kế hoạch.
Đọc kế hoạch cho nhanh
Đừng đọc từng dòng, hãy soi ba câu hỏi theo thứ tự:
- Nó có hiểu đúng yêu cầu không? Xem phần mô tả mục tiêu ở đầu. Sai ở đây thì bỏ luôn, khỏi đọc tiếp.
- Danh sách file có chỗ nào lạ không? Một file bạn không ngờ tới thường nghĩa là một trong hai điều: nó phát hiện ra thứ bạn quên, hoặc nó đang định làm quá phạm vi. Cả hai đều đáng hỏi lại.
- Cách tiếp cận có đúng quy ước dự án không? Ví dụ nó định thêm một thư viện mới trong khi dự án đã có sẵn công cụ tương đương.
Ba câu này mất chừng một phút và bắt được phần lớn vấn đề. Phần chi tiết kỹ thuật bạn xem lại lúc duyệt code cũng chưa muộn.
Một dấu hiệu đáng chú ý: nếu kế hoạch dài bất thường cho một việc nghe đơn giản, thường là do yêu cầu của bạn mơ hồ nên agent phải bao quát nhiều hướng. Lúc đó nói rõ hơn rồi cho lập lại kế hoạch sẽ nhanh hơn là để nó tự đoán.
Kết hợp với các cơ chế khác
Chế độ lập kế hoạch giải quyết hiểu nhầm ở đầu vào. Nó không thay được các lớp khác:
- File quy ước dự án giữ cho kế hoạch tuân thủ chuẩn chung, theo bài CLAUDE.md. Không có nó thì mỗi lần bạn lại phải nhắc lại quy ước trong lúc duyệt kế hoạch.
- Hook chặn những thao tác tuyệt đối không được xảy ra, kể cả khi bạn đã duyệt kế hoạch.
- Tách việc ra phiên con giữ ngữ cảnh sạch cho phần khảo sát, theo bài về subagent. Với repo lớn, khâu khảo sát sinh rất nhiều nội dung trung gian.
Với việc lớn, nhiều người dùng theo trình tự: lập kế hoạch trong một phiên, duyệt, rồi giao từng phần của kế hoạch cho các phiên con thực thi. Cách chia việc cho nhiều phiên nằm ở bài thiết kế đội subagent.
Sai lầm hay gặp
Duyệt cho xong. Đọc lướt rồi bấm đồng ý là tự bỏ đi toàn bộ lợi ích. Nếu bạn thấy mình hay làm vậy, có lẽ bạn đang bật chế độ này cho những việc không cần tới nó.
Bật cho mọi việc. Vòng chờ duyệt cộng dồn rất nhanh, và sau vài chục lần bạn sẽ duyệt qua loa. Hãy dành nó cho việc thật sự đáng.
Coi kế hoạch là cam kết. Kế hoạch dựa trên thứ agent đọc được lúc đó. Khi bắt tay làm, nó phát hiện thêm và có thể phải đi khác đường. Đó là bình thường, miễn là hướng lớn không đổi.
Quên rằng kế hoạch cũng tốn token. Khâu khảo sát đọc rất nhiều file, và tất cả nằm lại trong ngữ cảnh. Với repo lớn, hãy để phần khảo sát chạy ở phiên riêng rồi mang kế hoạch sang phiên mới để thực thi.
Khi nào nên bật và khi nào bỏ qua
| Tình huống | Nên bật không | Vì sao |
|---|---|---|
| Việc chạm nhiều tệp, hoặc đổi cấu trúc dự án | Nên | Kế hoạch lộ ra hiểu nhầm trước khi thành mã sai |
| Việc trên mã nguồn quan trọng, khó quay lui | Nên | Rẻ hơn nhiều so với sửa sau |
| Bạn chưa chắc mình muốn gì | Nên | Đọc kế hoạch giúp chính bạn làm rõ yêu cầu |
| Sửa một dòng, đổi một chuỗi | Không cần | Chi phí đọc kế hoạch lớn hơn lợi ích |
| Việc lặp lại đã làm nhiều lần | Không cần | Bạn đã biết nó sẽ làm gì |
Đọc kế hoạch cho nhanh: bốn thứ cần kiểm
- Nó định sửa những tệp nào. Có tệp nào ngoài dự kiến không? Đây là dấu hiệu hiểu nhầm rõ nhất.
- Nó có định tạo tệp mới không, và có thật sự cần tệp mới không.
- Nó có định chạy lệnh nào không, nhất là lệnh xóa, lệnh cài thư viện, lệnh chạm cơ sở dữ liệu.
- Nó có hiểu đúng yêu cầu không. Nếu kế hoạch giải một bài toán khác thì dừng lại và mô tả lại yêu cầu.
Bốn thứ này đọc trong một phút và chặn được phần lớn trường hợp phải làm lại. Đây là tỷ lệ đổi lại tốt trong toàn bộ cách làm việc với trợ lý.
Ghép với tệp luật và điểm móc chặn lệnh
- Tệp luật của dự án giảm số lần kế hoạch sai ngay từ đầu. Xem bài về tệp luật.
- Điểm móc chặn lệnh chặn cứng những gì kế hoạch bỏ sót. Xem bài về điểm móc chặn lệnh.
- Ghi lại trạng thái mã nguồn trước khi giao việc lớn, để quay lui bằng một lệnh.
- Ba lớp này bổ sung nhau, không thay thế nhau.
Duyệt kế hoạch mà không đọc
- Duyệt kế hoạch mà không đọc. Bật chế độ này rồi bấm đồng ý luôn là mất hết giá trị của nó.
- Bật cho mọi việc, kể cả việc nhỏ. Sau vài ngày bạn sẽ bấm đồng ý theo phản xạ, và quay về vấn đề ở gạch đầu dòng trên.
- Coi kế hoạch được duyệt là bảo đảm. Vẫn phải đọc mã trước khi ghép vào nhánh chính.
Câu hỏi thường gặp
Plan mode có làm chậm công việc không?
Có, thêm một vòng đọc và duyệt. Nhưng nó rẻ hơn nhiều so với việc phát hiện hiểu nhầm sau khi đã có ba trăm dòng code sai hướng. Với việc nhỏ thì đúng là chỉ tổ chậm, nên đừng bật cho mọi thứ.
Có ép agent luôn lập kế hoạch bằng file quy ước được không?
Ghi vào file quy ước thì nó thường tuân theo, nhưng đó là lời nhắc chứ không phải ràng buộc, và trong phiên dài nó có thể bỏ qua. Chế độ này chặn ở tầng công cụ nên chắc chắn hơn.
Kế hoạch sai thì làm gì?
Nói rõ chỗ sai rồi yêu cầu lập lại, đừng sửa tay kế hoạch rồi bảo nó làm theo. Phản hồi cụ thể còn giúp nó hiểu đúng bối cảnh cho các bước sau trong cùng phiên.
Chạy trên máy chủ có khác gì không?
Không khác về cách hoạt động. Điểm lợi khi chạy trên máy chủ là phần khảo sát repo lớn không chiếm tài nguyên máy cá nhân, và phiên vẫn sống khi bạn đóng laptop giữa lúc đang đọc kế hoạch.