So sánh phiên Compact và Fresh trong Claude Code: Khi nào nên sử dụng mỗi loại?

Hai công cụ, một mục tiêu, những sự đánh đổi khác nhau

🔄 Tóm tắt nhanh: Trong Bài học 3, bạn đã học rằng cả /compact và /clear đều giảm bớt ngữ cảnh - nhưng chúng nằm ở các điểm khác nhau trên phổ bảo toàn. Compact giữ lại bản tóm tắt do Claude viết. Clear không giữ lại gì ngoài những gì bạn viết trong một bản tóm tắt mới.

Bây giờ hãy cùng tìm hiểu thực tế về khi nào mỗi công cụ sẽ hiệu quả hơn.

Cách /compact hoạt động

Khi bạn chạy /compact, ba điều sẽ xảy ra:

1. Claude đọc toàn bộ lịch sử cuộc hội thoại của bạn
2. Nó viết một bản tóm tắt về những gì nó cho là quan trọng - các quyết định chính, trạng thái file, trạng thái tác vụ hiện tại
3. Toàn bộ lịch sử được thay thế bằng bản tóm tắt đó

Nó nhanh, tự động và có tính chất mất mát - nghĩa là Claude quyết định giữ lại cái gì và loại bỏ cái gì. Đó vừa là điểm mạnh vừa là điểm yếu.

Điều chỉnh các bản tóm tắt của bạn

Đây là thao tác mà hầu hết mọi người bỏ qua: Bạn có thể cho Claude biết cần tập trung vào điều gì.

Thay vì dùng lệnh /compact thông thường, hãy thử:

📋 Sao chép và thử lệnh này:

/compact tập trung vào việc tái cấu trúc middleware xác thực và danh sách các file đã được sửa đổi. Loại bỏ phiên gỡ lỗi và các lỗi kiểm thử.

Hoặc:

/compact giữ nguyên cấu trúc API endpoint và các quyết định về lược đồ cơ sở dữ liệu. Có thể bỏ qua việc gỡ lỗi CSS.

Claude sẽ ưu tiên tóm tắt của nó theo bất cứ điều gì bạn chỉ định. Kỹ thuật này loại bỏ hầu hết các lệnh compact không hiệu quả.

✅ Kiểm tra nhanh: Tại sao /compact có định hướng lại tốt hơn /compact thông thường?

Câu trả lời: Không có định hướng, Claude đoán xem điều gì quan trọng. Với định hướng, bạn cho nó biết điều gì cần giữ lại, làm cho bản tóm tắt phù hợp hơn với nhiệm vụ tiếp theo của bạn.

Cách hoạt động của /clear + Brief

/clear xóa mọi thứ. Sau đó, bạn viết một bản tóm tắt mang theo những điều cần thiết:

📋 Sao chép và thử lệnh này:

/clear

Sau đó trong phiên mới:

Ngữ cảnh: Chúng ta đang tái cấu trúc middleware xác thực trong src/auth/. Ràng buộc là khả năng tương thích ngược với API v2. Các file quan trọng: middleware.ts, session.ts, types.ts. Chúng tôi đã loại bỏ mẫu thiết kế decorator vì nó phá vỡ chuỗi middleware của Express. Bước tiếp theo: triển khai logic làm mới token.

Việc này tốn nhiều công sức hơn. Bạn phải suy nghĩ về những gì quan trọng và ghi lại. Nhưng ngữ cảnh kết quả chính xác là những gì bạn đã quyết định là có liên quan - không hơn không kém.

Ma trận quyết định

Khi nào /compact chiến thắng?

• Bạn vẫn đang làm việc với cùng một thứ, chỉ cần loại bỏ những thứ không cần thiết
• Phiên làm việc bị phình to với các kết quả đầu ra của công cụ và công việc trung gian
• Bạn tin tưởng vào phán đoán của Claude về những gì quan trọng (hoặc bạn có thể định hướng nó)
• Bạn không muốn làm gián đoạn luồng công việc của mình bằng cách viết tóm tắt thủ công

Khi nào /clear + Brief chiến thắng?

• Bạn đang chuyển sang một nhiệm vụ thực sự khác
• Bạn đã dành 100.000 token để khám phá và tìm thấy một thông tin quan trọng
• Mức độ rủi ro cao và bạn cần ngữ cảnh chính xác
• Bạn muốn không có khả năng rò rỉ ngữ cảnh lỗi thời
• Chất lượng phiên làm việc đã giảm sút đáng kể

✅ Kiểm tra nhanh: Bạn đã khám phá ba tùy chọn cơ sở dữ liệu khác nhau trong một giờ. Bạn đã quyết định chọn PostgreSQL. Bạn cần bắt đầu quá trình di chuyển thực tế. Bước nào và tại sao?

Đáp án: /clear + brief - bạn cần chính xác quyết định (PostgreSQL) và lý do, chứ không phải cả giờ đồng hồ tìm hiểu ba lựa chọn.

Thực hành: So sánh song song

Hãy thử điều này trong quy trình làm việc thực tế của bạn với Claude Code ngay hôm nay:

1. Làm việc trên một nhiệm vụ trong 15 - 20 phút cho đến khi cảm thấy hơi nặng nề
2. Chạy lệnh /compact focus vào [trọng tâm hiện tại của bạn] - ghi lại kích thước ngữ cảnh trước và sau
3. Tiếp tục làm việc trong 10 phút
4. Bây giờ chạy lệnh /clear và viết một bản tóm tắt 3 câu để bắt đầu lại
5. So sánh: Phiên làm việc nào cảm thấy sắc bén hơn cho nhiệm vụ tiếp theo?

Không có cái nào tốt hơn một cách tuyệt đối. Mục tiêu là cảm nhận sự khác biệt để bạn có thể lựa chọn một cách trực quan.

Những điểm chính cần ghi nhớ

• /compact là tóm tắt không đầy đủ - nhanh chóng nhưng bạn tin tưởng vào phán đoán của Claude
• /clear + brief là điều khiển thủ công - nhiều công việc hơn nhưng độ chính xác tuyệt đối
• Luôn hướng dẫn /compact bằng các chỉ dẫn: /compact tập trung vào X, bỏ qua Y
• Sử dụng /compact để cắt bớt công việc giữa chừng, /clear để chuyển đổi giữa các nhiệm vụ
• Một bản tóm tắt tốt gồm 3 - 5 câu: Bạn đang làm gì, điều gì quan trọng, điều gì bạn đã loại trừ

Thử ngay: Lệnh /compact được kiểm soát + Template tóm tắt phiên mới

Sử dụng hai prompt này trong quy trình làm việc thực tế của bạn với Claude Code. Prompt đầu tiên điều khiển lệnh /compact để không làm mất trạng thái quan trọng. Prompt thứ hai xây dựng bản tóm tắt phiên mới để phiên đã được xóa bắt đầu mà không bị mất dữ liệu.

Prompt A - Lệnh /compact được kiểm soát (dán TRƯỚC khi chạy lệnh /compact):

Trước khi chạy lệnh /compact, tôi cần bạn soạn thảo hướng dẫn nén để bản tóm tắt giữ lại những gì quan trọng và loại bỏ những gì không cần thiết.

Trọng tâm phiên hiện tại: []
Giai đoạn công việc (khám phá / quyết định / thực hiện / gỡ lỗi / hoàn thiện): []
Các file hiện đang được chỉnh sửa: []
Các quyết định tôi đã chốt trong phiên này (kèm lý do): []
Các ràng buộc tôi đã chấp nhận (công nghệ, thương hiệu, bảo mật, lịch trình): []
Những điều tôi đã loại trừ rõ ràng và lý do: []
3 bước tiếp theo tôi dự định thực hiện: []

Tạo hướng dẫn ngắn gọn có định hướng:

/compact tập trung vào:
- [nhiệm vụ + 3 bước tiếp theo cụ thể]
- [các quyết định kèm lý do, được đặt tên là "đã khóa"]
- [đường dẫn file với mục đích 1 dòng cho mỗi file]
- [các ràng buộc kèm lý do]

Loại bỏ:
- [khám phá bị bỏ dở + lý do bị bỏ dở]
- [đầu ra công cụ dư thừa]
- [sự khác biệt file dài đã được cam kết]
- [các vấn đề lạc đề]

Giữ nguyên văn:
- [bất kỳ thông báo lỗi chính xác nào hiện đang liên quan]
- [bất kỳ [Ràng buộc do người dùng cung cấp mà tôi KHÔNG muốn được diễn đạt lại]
- [bất kỳ tên kiểm thử / lược đồ / biểu thức chính quy / đường dẫn file nào sẽ bị lỗi nếu được diễn đạt lại]

Trước khi tôi nhấn /compact, hãy lưu ghi chú bàn giao 5 dòng này vào .claude/notes/ để bản tóm tắt không phải là bản ghi duy nhất:

Nhiệm vụ: []
Các file đã được xử lý: []
Các quyết định đã được khóa: []
Các câu hỏi chưa được giải đáp: []
Bước tiếp theo: []

QUY TẮC BẮT BUỘC:
- Không bao giờ chạy /compact nếu có công việc chưa được cam kết mà bộ nhớ của mô hình là bản ghi duy nhất — hãy lưu ghi chú TRƯỚC
- Không bao giờ chạy /compact giữa quá trình gỡ lỗi nếu việc tái tạo lỗi phụ thuộc vào trạng thái chính xác mà sẽ bị mất
- ​​Không bao giờ bỏ qua "Giữ nguyên văn" đối với biểu thức chính quy / lược đồ / ID / tên kiểm thử / đường dẫn file — việc diễn đạt lại sẽ gây ra lỗi
- Nếu phiên chứa thông tin đăng nhập, client NDA code hoặc dữ liệu nhạy cảm, hãy lên kế hoạch những gì KHÔNG nên viết vào ghi chú bàn giao mà sẽ được cam kết

Prompt B - Tóm tắt phiên mới (dán vào phiên MỚI sau khi dùng lệnh /clear):

Tôi vừa chạy lệnh /clear. Đây là một phiên mới. Đây là bản tóm tắt đầy đủ cho nhiệm vụ tiếp theo:

Nhiệm vụ (một câu): []
Tại sao điều này quan trọng (một câu): []
Các file và vai trò của chúng:
- đường dẫn/đến/file 1: [mục đích 1 dòng]
- đường dẫn/đến/file 2: [mục đích 1 dòng]

Các quyết định đã được khóa (không xem xét lại):
- [quyết định] — vì [lý do]
- [quyết định] — vì [lý do]

Đã bị loại trừ (không đề xuất):
- [lựa chọn] — vì [lý do]
- [lựa chọn] — vì [lý do]

Ràng buộc:
- [công nghệ / bảo mật / lịch trình / phong cách]
- [công nghệ / bảo mật / lịch trình / phong cách]

3 bước tiếp theo tôi muốn thực hiện:
1. []
2. []
3. []

Trạng thái "hoàn thành" của phiên này: []

Các quy tắc dành cho bạn (mô hình) trong phiên này:
- KHÔNG đề xuất các lựa chọn đã bị loại trừ
- KHÔNG xem xét lại các file không có trong danh sách vai trò trên đây
- KHÔNG đề xuất thay đổi các quyết định đã khóa mà không có sự cho phép của tôi
- Khi không chắc chắn, hãy hỏi tôi thay vì đoán mò — phiên làm việc mới = không có giả định

Trước khi thực hiện bất kỳ hành động nào, hãy xác nhận bạn hiểu nhiệm vụ + các ràng buộc trong ≤ 2 câu. Sau đó, đề xuất bước đầu tiên nhỏ nhất hướng tới bước 1.

CÁC QUY TẮC BẮT BUỘC áp dụng cho toàn bộ phiên làm việc:
- Không sử dụng các lệnh phá hủy mà không có xác nhận rõ ràng
- Không sử dụng force-push, không sử dụng rm -rf, không sử dụng DROP / TRUNCATE, không thực hiện commit mà không hiển thị diff trước
- Nếu bản tóm tắt của tôi mâu thuẫn với chính nó, hãy dừng lại và hỏi — đừng chọn phe nào một cách im lặng
- Nếu tôi đề cập đến thông tin đăng nhập, client NDA hoặc dữ liệu được quy định, hãy xác nhận cấp độ chúng ta đang sử dụng hỗ trợ điều đó TRƯỚC KHI chúng ta tiếp tục

Những gì bạn sẽ thấy: Một lệnh /compact được kiểm soát bảo toàn trạng thái chính xác mà công việc của bạn phụ thuộc vào, cộng với một template bản tóm tắt mới ngăn chặn việc xem xét lại các quyết định bạn đã đưa ra - vì vậy các thay đổi ngữ cảnh diễn ra mà không bị mất trí nhớ theo bất kỳ hướng nào.