Khi nào nên dùng /context, /compact và /clear

Cuộc trò chuyện đã kéo dài khá lâu. Bạn đã bác bỏ một cách giải quyết và giải thích lý do, nhưng chừng mười tin nhắn sau, agent lại đề xuất đúng phương án đó. Phản ứng đầu tiên rất dễ hiểu: xóa hết rồi bắt đầu lại.

Phương án bị bác bỏ quay trở lại là một dấu hiệu đáng chú ý, nhưng chưa phải chẩn đoán. Chỉ từ một câu trả lời thì chưa thể kết luận cuộc trò chuyện tích tụ quá nhiều là nguyên nhân: tình huống trông y hệt khi yêu cầu mâu thuẫn hoặc agent đang xem phiên bản tệp từ nửa tiếng trước.

Hãy cùng xem ba lệnh tác động trực tiếp đến cuộc trò chuyện: /context cho biết cửa sổ ngữ cảnh đang chứa gì, /compact rút gọn lịch sử thành bản tóm tắt, còn /clear bắt đầu một cuộc trò chuyện mới. Cú pháp của chúng không phải phần thú vị nhất. Quan trọng hơn là chọn lệnh nào: cần lưu lại gì trước, kiểm tra gì sau, và làm sao biết vấn đề không nằm ở độ dài cuộc trò chuyện.

Trước tiên, hãy tìm vấn đề

Trước khi rút gọn hay xóa gì, hãy phân biệt bốn tình huống. Nhìn bên ngoài chúng khá giống nhau: agent đều có vẻ "không nghe", nhưng mỗi tình huống cần cách xử lý khác nhau.

• Thiếu dữ liệu đầu vào. Chưa ai nêu quy tắc trao phần thưởng, và quy tắc đó cũng không có trong các tệp đã đọc. Rút gọn cuộc trò chuyện không thể tạo ra thông tin vốn chưa từng có: bạn cần cung cấp phần còn thiếu.
• Thông tin đã lỗi thời. Cuộc trò chuyện còn giữ nội dung của một tệp được đọc nửa tiếng trước, nhưng tệp trên đĩa đã thay đổi. Đọc lại mới có ích, không phải rút gọn.
• Yêu cầu mâu thuẫn. Trong chat nói một đằng, còn tài liệu đặc tả đã lưu ghi một nẻo. Hãy tự quyết định yêu cầu nào còn hiệu lực rồi sửa nguồn tương ứng. Tệp không tự nhiên đúng chỉ vì nó là tệp.
• Nhiễu tích tụ. Quá nhiều phương án bị bác bỏ, đầu ra lệnh dài, thảo luận về những tệp không liên quan đến nhiệm vụ. Đây mới là lúc làm việc với ngữ cảnh thực sự phù hợp.

Mức lấp đầy cửa sổ không phải mục thứ năm trong danh sách này và cũng không giải thích mọi lỗi. Tỷ lệ cao tự nó không chứng minh agent sai vì lý do đó; tỷ lệ thấp cũng không chứng minh cuộc trò chuyện vẫn ổn. Thứ tự kiểm tra rất đơn giản: yêu cầu, độ mới của tệp, độ mới của đầu ra, rồi mới đến trạng thái của cuộc trò chuyện.

Xem mức sử dụng cửa sổ

Nếu vẫn nghi ngờ chính cuộc trò chuyện, hãy xem /context. Lệnh này cho biết cửa sổ đang chứa gì, chia theo nhóm: phần hệ thống, hướng dẫn của dự án, các tệp đã đọc và đầu ra lệnh, tin nhắn trao đổi, dung lượng còn trống. Bạn quyết định thông tin nào không còn cần cho nhiệm vụ. Lệnh không đánh giá nội dung đã đọc, còn dòng tổng hợp tin nhắn cũng không cho biết cụ thể tệp nào là thừa.

Không có ngưỡng chung kiểu "vượt quá từng này phần trăm thì nên rút gọn"; dung lượng cửa sổ còn tùy thuộc vào model và cài đặt. Hãy xem nội dung gồm những gì thay vì nhìn vào tỷ lệ. Và lưu ý, đóng tab trong editor không tự xóa phần đã đọc khỏi cuộc trò chuyện.

Tiếp tục nhiệm vụ sau khi rút gọn

Lệnh /compact rút gọn lịch sử thành một bản tóm tắt, còn bạn vẫn ở trong cùng nhiệm vụ. Claude Code cũng tự làm việc này khi cửa sổ dần đầy, vì thế bạn thường tự chạy lệnh khi muốn chọn thời điểm (chẳng hạn trước một phần việc lớn mới) và đặt trọng tâm.

Giới hạn chính: thứ được giữ lại là bản tóm tắt, không phải toàn bộ cuộc trò chuyện. Đừng trông chờ các chi tiết ngoài bản tóm tắt vẫn còn trong cửa sổ. Câu "hãy giữ lại những điều kiện này" cũng không đảm bảo bản tóm tắt đầy đủ - đó là một lời yêu cầu, không phải cơ chế.

Cần lưu lại gì

Trước khi chạy lệnh, hãy ghi chú ngắn về nhiệm vụ: mục tiêu, phạm vi, quyết định đã đưa ra, dữ kiện đã kiểm chứng và bước tiếp theo. Chỉ mất vài phút. Bù lại, bạn có thể đối chiếu ghi chú với các tệp và đầu ra kiểm tra, điều mà trí nhớ về cuộc trò chuyện không làm được. Không cần tạo tệp riêng, tài liệu nhiệm vụ hiện có là đủ.

Dưới đây là trạng thái của một nhiệm vụ thực hành về việc trao phần thưởng lặp lại. Đây là ví dụ, không phải báo cáo về một lần kiểm tra đã thực hiện:

Mục tiêu: trong một ván đã kết thúc, phần thưởng chỉ được trao một lần; sang ván mới thì có thể nhận thưởng lần nữa.
Phạm vi: src/reward-flow.js và kiểm tra phần thưởng hiện có; không thay đổi giao diện.
Đã xác nhận: sau lần trao thưởng đầu tiên, nhấn thêm lần nữa trong cùng ván vẫn làm tăng điểm.
Nguồn: bản ghi tái hiện lỗi và trạng thái ban đầu được nêu trong TASK_SPEC.md.
Đã bác bỏ: ẩn nút mà không sửa cách xử lý lần nhấn lặp lại.
Bước tiếp theo: kiểm tra handler và đề xuất chỉnh sửa; bản sửa và test vẫn chưa được thực hiện.

Hãy chú ý dòng cuối. Tái hiện lỗi đã xác nhận và bản sửa đã hoàn tất là hai việc khác nhau; ghi chú phải thể hiện rõ điều đó, nếu không sau khi rút gọn, "đã kiểm tra" rất dễ biến thành "đã sửa". Tài liệu nhiệm vụ ở đây là ví dụ thực hành, hãy thay bằng đường dẫn của bạn.

Sau khi đã đối chiếu ghi chú, bạn có thể rút gọn với trọng tâm cụ thể:

/compact Tập trung sửa lỗi trao phần thưởng lặp lại. Giữ lại mục tiêu, phạm vi trong TASK_SPEC.md, cách tái hiện đã xác nhận, phương án đã bác bỏ và bước tiếp theo. Ghi rõ bản sửa và test vẫn chưa được thực hiện.

Kiểm tra gì sau đó

Sau khi rút gọn, đừng vội làm tiếp từ chỗ đang dở. Trước tiên, hãy đưa trở lại cuộc trò chuyện những thông tin cần chính xác, rồi đặt câu hỏi kiểm tra:

Hãy đọc TASK_SPEC.md và src/reward-flow.js phiên bản hiện tại. Nêu ngắn gọn giới hạn và bước tiếp theo. Nếu bản tóm tắt khác với các tệp, hãy chỉ ra điểm khác biệt. Tạm thời đừng sửa code.

Đối chiếu câu trả lời với từng dòng trong ghi chú, đừng chỉ dựa vào ấn tượng chung. Trong ví dụ này có ba điểm cần kiểm tra:

• dòng "Bước tiếp theo" không nói rằng bản sửa và test đã hoàn tất;
• trong mục "Phạm vi" vẫn còn điều cấm thay đổi giao diện;
• điều kiện về ván mới trong mục "Mục tiêu" vẫn còn nguyên.

Agent sẽ diễn đạt theo cách riêng, như vậy không sao. Nếu thiếu một điều kiện, hãy lấy lại từ nguồn trước khi chỉnh sửa. Bạn đang kiểm tra trạng thái cuộc trò chuyện, chứ không phải code: cách kiểm tra này không chứng minh chỉnh sửa tiếp theo sẽ đúng.

Bắt đầu nhiệm vụ mới

Lệnh /clear bắt đầu một cuộc trò chuyện mới, không có các tin nhắn trước đó. Tệp trên đĩa và hướng dẫn của dự án vẫn còn; nếu bật bộ nhớ tự động thì bộ nhớ đó cũng có thể được dùng. Vì vậy, "từ đầu" ở đây chỉ nói về tin nhắn. Cuộc trò chuyện cũ không bị xóa, bạn có thể quay lại bằng /resume.

Dễ nhầm lệnh này với claude --continue, dù hai thao tác trái ngược nhau. Bạn nhập /clear trong phiên để thoát khỏi lịch sử đã tích tụ. Còn claude --continue được nhập trong terminal khi khởi chạy để quay lại cuộc trò chuyện gần nhất trong thư mục đó, cùng toàn bộ lịch sử. Nếu chính cuộc trò chuyện là vấn đề, --continue sẽ đưa bạn quay lại đúng cuộc trò chuyện ấy.

Trước khi xóa, hãy lưu những gì sẽ cần sau này: ghi chú, các đường dẫn cần thiết, đầu ra kiểm tra. Cuộc trò chuyện mới cần yêu cầu cụ thể chứ không phải gợi ý mơ hồ - mục tiêu, giới hạn và đường dẫn. Dùng @file để chỉ định tệp cần đọc, nhưng lưu ý rằng việc nhắc đến tệp chỉ định hướng đọc chứ không giới hạn quyền truy cập vào các tệp khác.

Chọn cách xử lý

Quy trình khá ngắn: dừng lại, đặt câu hỏi kiểm tra, xem mức sử dụng cửa sổ nếu chưa rõ nó đang chứa gì, chọn một thao tác rồi kiểm tra kết quả. Đếm tin nhắn chẳng ích gì; cần xem cuộc trò chuyện gồm những gì và bạn định làm gì tiếp theo.

Điều này thay đổi cách làm việc ra sao

Bản thân ba lệnh không sửa được gì. Thứ thay đổi là cách bạn xử lý một nhiệm vụ dài:

• khi câu trả lời lạ, trước tiên kiểm tra yêu cầu và độ mới của các tệp, rồi mới xét đến cuộc trò chuyện;
• trước khi rút gọn hoặc xóa, có ghi chú đã đối chiếu với tệp; sau khi rút gọn, câu trả lời được kiểm tra theo từng dòng;
• nhiệm vụ mới có yêu cầu riêng, thay vì phần còn sót lại từ cuộc trò chuyện trước.

Khác biệt thể hiện rõ qua một yêu cầu. Trước đây:

Bạn rối rồi, làm lại từ đầu đi.

Còn bây giờ:

Nhiệm vụ hiện tại là sửa lỗi trao phần thưởng lặp lại trong src/reward-flow.js.
Hãy đọc TASK_SPEC.md, nêu giới hạn và bước tiếp theo. Tạm thời đừng sửa code.

Yêu cầu thứ hai giúp nhận được câu trả lời có thể kiểm tra: bạn đối chiếu giới hạn và bước agent nêu ra với các tệp để nhận ra ngay điểm khác biệt. Câu đầu tiên thì không có gì cụ thể để đối chiếu.