Tôi đã dùng Claude Code hàng ngày khoảng một năm nay. Vài tháng đầu, tôi dùng như cách hầu hết mọi người dùng — một cuộc hội thoại dài dằng dặc, ném mọi thứ vào, rồi bực bội khi nó bắt đầu quên. Phải mất một thời gian đáng xấu hổ tôi mới nhận ra vấn đề không nằm ở công cụ. Vấn đề nằm ở cách tôi tư duy về nó.
Đây là cách tôi làm bây giờ, và tại sao.
Claude Code cho bạn một context window khổng lồ. Và bản năng tự nhiên của bạn là tận dụng hết — kéo dài cuộc hội thoại, nhồi thêm context, vì chắc chắn nhiều thông tin hơn sẽ cho kết quả tốt hơn.
Sai. Đây là những gì thực sự xảy ra:
Tôi gọi đây là context rot (suy thoái ngữ cảnh), và nó đánh mạnh nhất đúng lúc bạn đã bỏ nhiều công sức nhất. Bạn dành cả tiếng xây dựng sự hiểu biết chung về một vấn đề phức tạp, và đó chính xác là lúc mọi thứ bắt đầu rã ra.
Đến một lúc tôi có một nhận ra nghe thì hiển nhiên nhưng thực sự thay đổi cách tôi làm việc:
Cuộc hội thoại là RAM. File là ổ cứng.
Bạn sẽ không bao giờ thiết kế một hệ thống mà bản sao duy nhất của trạng thái quan trọng chỉ nằm trong RAM. Nhưng đó chính xác là điều hầu hết mọi người làm với Claude Code. Họ đổ cả tiếng điều tra vào một cuộc hội thoại rồi ngạc nhiên khi nó bốc hơi.
Khi tôi thấm nhuần điều này, mọi thứ còn lại đều vào đúng chỗ.
Đây có lẽ là thứ đòn bẩy cao nhất bạn có thể làm với Claude Code. File CLAUDE.md nằm ở thư mục gốc của dự án và được nạp vào mọi cuộc hội thoại một cách tự động. Tôi dùng nó để lưu bất kỳ thứ gì model cần biết xuyên suốt các phiên làm việc:
Mọi cuộc hội thoại mới đều bắt đầu với context này đã được nạp sẵn. Không cần giải thích. Khi tôi phát hiện điều gì quan trọng trong một phiên làm việc — ví dụ, một service có rate limit không được ghi tài liệu — tôi thêm nó vào CLAUDE.md trước khi quên. Phiên bản tương lai của tôi (và các cuộc hội thoại tương lai) sẽ cảm ơn.
Đây là nơi Claude Code chuyển từ “công cụ hữu ích” sang “công cụ biết học hỏi.”
Auto memory là hệ thống mà Claude Code tự động ghi lại những phát hiện, sở thích và pattern quan trọng khi làm việc với bạn. Khi bạn nói “luôn dùng pnpm, không dùng npm” hay “nhớ rằng API tests cần Redis local,” nó lưu vào file memory — không cần bạn phải tự tay chỉnh sửa gì.
Mỗi dự án có thư mục memory riêng tại ~/.claude/projects/<project>/memory/. Cấu trúc trông như thế này:
~/.claude/projects/<project>/memory/
├── MEMORY.md # Mục lục ngắn gọn, nạp vào mọi phiên
├── debugging.md # Ghi chú chi tiết về debugging
├── api-conventions.md # Quy ước thiết kế API
└── ... # Các file chủ đề khác
MEMORY.md là điểm vào — 200 dòng đầu (hoặc 25KB) được nạp khi bắt đầu mỗi cuộc hội thoại. Claude giữ nó ngắn gọn bằng cách chuyển ghi chú chi tiết sang các file chủ đề riêng. Những file chủ đề đó không được nạp lúc khởi động; Claude đọc chúng khi cần. Thiết kế này thông minh — phiên làm việc bắt đầu nhanh với mục lục tập trung, còn kiến thức sâu chỉ cách một lần đọc file.
Điểm mấu chốt: tất cả đều là markdown thuần bạn có thể chỉnh sửa hoặc xóa bất cứ lúc nào. Chạy /memory để duyệt và mở các file memory từ trong phiên làm việc. Tôi kiểm tra thường xuyên, cắt tỉa những thứ lỗi thời và thỉnh thoảng sắp xếp lại.
Điều này trực tiếp chống lại context rot. Thay vì phải giải thích lại những đặc thù của dự án mỗi phiên, Claude đã biết rồi. Sự hiểu biết tồn tại xuyên các cuộc hội thoại, xuyên các lần /clear, xuyên nhiều ngày. Đó là nguyên tắc “file là ổ cứng,” được tự động hóa.
Nếu bạn muốn auto memory lưu ở nơi cụ thể, bạn có thể đặt autoMemoryDirectory trong cài đặt:
{
"autoMemoryDirectory": "~/my-custom-memory-dir"
}
Một lưu ý: auto memory chỉ nằm trên máy local. Nó không được chia sẻ giữa các máy hay môi trường cloud. Tuy nhiên, tất cả worktree và thư mục con trong cùng một git repository sẽ dùng chung một thư mục auto memory — đúng là điều bạn muốn.
Ngay cả khi có auto memory, tôi vẫn tự tay ghi lại ghi chú điều tra trước khi cuộc hội thoại quá dài. Auto memory nắm bắt sở thích và pattern; ghi chú thủ công nắm bắt trạng thái cụ thể của phiên debug. Hai nhiệm vụ khác nhau.
Tôi thường để chúng trong .claude/ hoặc dưới dạng debug-notes.md:
## Bug: Lỗi 500 không ổn định trên /api/orders
### Nguyên nhân gốc
Race condition trong OrderService.process() — hai request
đồng thời đều có thể pass kiểm tra inventory trước khi
bất kỳ cái nào giảm số lượng tồn kho.
### Những gì đã thử nhưng không hiệu quả
- Thêm mutex đơn giản (deadlock với payment callback)
- Database-level locking (phạm vi quá rộng, giết throughput)
### Hướng sửa khả thi
Optimistic locking với retry trên bước cập nhật inventory.
Sau đó tôi bắt đầu cuộc hội thoại mới: “Đọc debug-notes.md và triển khai fix.” Cuộc hội thoại mới có toàn bộ context cần thiết mà không kèm theo rác.
Điều này đơn giản đến mức xấu hổ và tôi đã chống cự nó suốt nhiều tháng. Đừng như tôi.
Mỗi khi Claude Code tạo ra thứ gì đáng giữ — một fix một phần, một refactor hữu ích, thậm chí một script chẩn đoán — tôi commit nó. Và tôi viết message mô tả cụ thể:
git commit -m "Thêm diagnostic logging cho race condition đơn hàng
Đã xác nhận: các request đồng thời đều pass inventory check
tại OrderService.java:142 trước khi bất kỳ cái nào ghi lại.
Xem test thất bại trong OrderServiceRaceTest."
Khi tôi bắt đầu cuộc hội thoại mới, git log và git diff trở thành context chất lượng cao mà không tốn token nào. Claude Code có thể đọc lịch sử git của bạn — hãy để nó làm.
Đây là điều tôi rao giảng nhiều nhất. Nếu tôi tìm ra bug, tôi yêu cầu Claude Code viết test thất bại trước khi tôi clear cuộc hội thoại:
"Viết test chứng minh race condition trong
OrderService.process() với hai request đồng thời
cho mặt hàng cuối cùng trong kho."
Test đó chính là sự hiểu biết, được mã hóa thành thứ có thể chạy được. Một cuộc hội thoại hoàn toàn mới có thể chạy nó, thấy nó fail, đọc code test, và biết chính xác cần sửa gì. Bạn không phải giải thích gì cả. Test tự giải thích.
Thay vì một cuộc hội thoại khổng lồ vừa điều tra, vừa chẩn đoán, vừa sửa:
Mỗi cuộc hội thoại đủ ngắn để Claude Code sắc bén suốt quá trình. Bạn đang làm việc cùng context window thay vì chống lại nó.
Đây là lệnh tôi ước mình phát hiện sớm hơn: /context hiển thị mức sử dụng context hiện tại dưới dạng lưới màu và đưa ra gợi ý tối ưu.
Hãy coi nó như đồng hồ đo xăng cho cuộc hội thoại. Khi lưới chủ yếu xanh lá, bạn còn nhiều dư địa. Khi nó chuyển đỏ và hiện cảnh báo, bạn đang ở vùng nguy hiểm cho context rot. Nó thậm chí còn gợi ý tối ưu cụ thể — có thể một tool nào đó đang ăn quá nhiều context, hoặc bạn có memory bloat từ việc đọc file lặp lại.
Tôi liếc /context định kỳ trong các phiên dài. Mất một giây và đã cứu tôi khỏi việc đẩy sâu vào vùng suy thoái hơn một lần.
Trước khi biết /rewind, lựa chọn của tôi khi mọi thứ đi sai hướng là nhị phân: tiếp tục đẩy qua vùng rot, hoặc /clear và mất hết.
/rewind cho bạn con đường giữa. Nó cho phép bạn quay lại cuộc hội thoại (và tùy chọn cả code) về checkpoint trước đó, hoặc tóm tắt từ một tin nhắn đã chọn. Đi sai hướng cách đây ba tin nhắn? Rewind về trước bước rẽ đó. Phần khám phá ngõ cụt biến mất, sự chú ý của model không bị lãng phí vào nó, và bạn giữ được mọi thứ đang hoạt động tốt.
Điều này đặc biệt hữu ích khi Claude Code đi vào hang thỏ — bạn có thể phẫu thuật loại bỏ những bước rẽ xấu thay vì hủy toàn bộ phiên.
Điều này tinh tế nhưng quan trọng. Giữa phiên debug, bạn cần kiểm tra cú pháp hoặc hỏi nhanh một câu không liên quan. Nếu bạn hỏi trực tiếp, câu hỏi và câu trả lời đó trở thành một phần context mãi mãi — noise cạnh tranh với cuộc điều tra thực sự.
/btw cho phép bạn hỏi câu phụ mà không thêm vào context. Tra cứu nhanh, không tốn context. Tôi dùng nó liên tục cho những câu kiểu “cú pháp của X là gì nhỉ?” không liên quan gì đến task hiện tại.
Lệnh /compact của Claude Code tóm tắt cuộc hội thoại để giải phóng context. Thời điểm quan trọng hơn bạn nghĩ.
Nếu bạn compact khi cuộc hội thoại đã lộn xộn, bản tóm tắt sẽ thừa hưởng sự lộn xộn đó. Rác vào, rác ra.
Bước đi phản trực giác: khoảnh khắc bạn nghĩ “mọi thứ đang tốt nhưng hơi dài” — đó là cửa sổ của bạn. Compact khi mọi thứ vẫn sạch sẽ. Đừng đợi đến khi bạn đã đang vật lộn với model.
/fork (cũng có tên /branch) cho phép bạn rẽ nhánh cuộc hội thoại để khám phá hướng tiếp cận khác mà không mất dòng công việc hiện tại. Hãy nghĩ nó như tạo branch trong git — cuộc hội thoại gốc vẫn nguyên vẹn, bạn có bản sao để đi theo hướng khác.
Đang cân nhắc hai chiến lược sửa lỗi? Fork cuộc hội thoại và thử một cái. Nếu không thành công, cuộc hội thoại gốc vẫn đúng chỗ bạn để nó. Tôi dùng mỗi khi muốn thử nghiệm hướng tiếp cận có thể không hiệu quả — chiến lược refactor, kiến trúc thay thế, thay đổi rủi ro — mà không phải cam kết hay làm bẩn cuộc hội thoại chính bằng ngõ cụt.
Một lý do mọi người ngại clear cuộc hội thoại là sợ mất hết. Nhưng /clear không phá hủy cuộc hội thoại — nó chỉ cất đi. Mọi phiên đã clear đều có sẵn qua /resume, nơi bạn có thể duyệt và quay lại bất kỳ cuộc hội thoại nào trước đó.
Kết hợp với /rename — đặt tên mô tả cho phiên làm việc như “dieu-tra-race-condition-don-hang” hay “thu-refactor-payment-lan-2” — và bạn có lịch sử tìm kiếm được của tất cả công việc. Bắt đầu mới không còn cảm giác như mất mát mà như mở một tab sạch.
/export xuất toàn bộ cuộc hội thoại ra file. Tôi dùng nó như bản lưu trữ trước khi clear — bảo hiểm rẻ phòng khi cần quay lại. /copy chỉ lấy response cuối cùng vào clipboard, tiện khi muốn kéo một insight cụ thể vào ghi chú mà không phải copy-paste lòng vòng.
Không có cái nào tự nó thay đổi cuộc chơi. Kết hợp với thói quen ghi chú, chúng làm việc quản lý context gần như không đau đớn.
/diff mở trình xem tương tác hiển thị các thay đổi chưa commit và diff theo từng lượt Claude. Bạn có thể chuyển giữa git diff tổng thể và những gì mỗi lượt Claude đã chỉnh sửa.
Tôi dùng trước khi commit — nó cho tôi bức tranh rõ ràng về những gì đáng giữ so với những gì chỉ là thăm dò. Nó cũng hữu ích trước khi clear cuộc hội thoại: liếc qua diff để chắc chắn bạn đã commit hết mọi thứ có giá trị.
Khi một task đủ lớn để cần nhiều cuộc hội thoại tập trung, /batch đưa nguyên tắc này lên cực đại. Nó nghiên cứu codebase, phân rã công việc thành các đơn vị độc lập, và khởi tạo agent riêng cho mỗi cái — mỗi agent trong worktree git cô lập riêng với context sạch.
Đây là nguyên tắc “cuộc hội thoại tập trung,” được tự động hóa hoàn toàn. Mỗi agent nhận một task nhỏ, rõ ràng và không có context nào từ công việc của agent khác. Không có rot theo thiết kế.
Chế độ thất bại hiển nhiên là code sai. Nhưng context rot tự báo hiệu tinh tế hơn:
Khi điều này bắt đầu xảy ra, đừng lặp lại to hơn. Kiểm tra /context để xem bạn đang ở đâu. Dùng /rewind nếu rot mới xảy ra. Lưu tiến trình và /clear nếu nó đã lan rộng. Lặp lại bản thân trong context đã suy thoái chỉ làm mọi thứ tệ hơn.
Một phiên debug điển hình của tôi bây giờ:
/fork để thử nghiệm mà không mất tiến trình hiện tại. Nếu đủ phức tạp để cần trang mới, tôi bắt đầu cuộc hội thoại mới trỏ đến ghi chú./btw cho bất kỳ câu hỏi phụ nào có thể làm rối context./context định kỳ. Nếu phiên dài nhưng hiệu quả, /compact khi nó vẫn sắc bén./rewind về điểm tốt cuối cùng. Nếu đã quá xa, lưu ghi chú và /clear.Toàn bộ quy trình tốn ít thời gian hơn cách cũ của tôi — cố đẩy qua một cuộc hội thoại ngày càng confused. Và chất lượng output tốt hơn rõ rệt vì model luôn làm việc với context sạch.
Một phần trong đây là vật lý của cách attention hoạt động trong language model. Context window có giới hạn, và nhồi thêm token không làm tất cả chúng hữu ích như nhau. Điều đó không thay đổi sớm.
Nhưng tooling đang cải thiện nhanh. Auto memory đã tự động duy trì kiến thức xuyên phiên. CLAUDE.md cho mọi cuộc hội thoại một bước chạy đà. Tóm tắt thông minh hơn, compact tốt hơn, các lệnh như /batch phân rã công việc thành context song song sạch — tất cả đều gặm nhấm vấn đề từ nhiều góc. Một năm nữa tôi dự đoán một nửa chiến lược thủ công trong bài này sẽ không còn cần thiết.
Cho đến lúc đó, auto memory cộng một chút kỷ luật git đưa bạn đến 80% chặng đường.
Đây là điều không ai muốn nói thẳng: AI đã làm cho bất kỳ ai cũng có thể tạo ra code hoạt động được. Rào cản xây dựng phần mềm đã sụp đổ. Điều này có nghĩa viết code không còn là thứ phân biệt lập trình viên.
Thứ phân biệt họ là khả năng điều khiển agent.
Và đừng nhầm — nền tảng lập trình vững chắc giúp bạn điều khiển agent tốt hơn. Nếu bạn hiểu cách một vấn đề nên được giải quyết trong code, bạn có thể hướng model đến kiến trúc đúng, bắt nó khi nó trôi vào pattern xấu, và đặt khung prompt sao cho tạo ra output có thể ship được. Người hiểu code tốt trông như thế nào sẽ luôn khai thác được nhiều hơn từ những công cụ này so với người không hiểu.
Nhưng chỉ kỹ năng code thôi không còn đủ. Hai senior developer có thể dùng Claude Code cho cùng một feature — một người ra kết quả sạch trong một giờ, người kia mất cả ngày chiến đấu với hallucination và output spaghetti. Cùng năng lực lập trình, khác kết quả. Khoảng cách nằm ở quản lý context, phân rã task, biết khi nào nên clear và khi nào nên đẩy tiếp. Đó là mọi thứ trong bài viết này.
Vì thế context rot không chỉ là sự phiền toái. Nó là nút thắt cổ chai. Nghề đang chuyển từ “bạn có viết được cái này không?” sang “bạn có viết được cái này và điều khiển được agent viết phần còn lại không?”
Sự thay đổi lớn nhất trong cách tôi dùng Claude Code không phải là học một lệnh hay tính năng mới. Mà là thay đổi nơi tôi lưu trữ kiến thức.
Cuộc hội thoại để suy nghĩ. File, commit, test và memory để ghi nhớ.
Claude Code đã cho bạn bộ công cụ đầy đủ: auto memory cho việc học tập bền vững, CLAUDE.md cho hướng dẫn cấp dự án, /context cho nhận thức, /rewind cho sửa chữa phẫu thuật, /btw cho câu hỏi phụ sạch, /compact cho tóm tắt đúng lúc, /fork cho khám phá hướng khác, và /clear cùng /resume cho khởi đầu mới mà không mất lịch sử.
Giữ mối quan tâm suy nghĩ và ghi nhớ tách biệt và phần lớn sự bực bội sẽ biến mất. Trợ lý AI của bạn sẽ quên những gì bạn nói — nhưng với quy trình làm việc đúng, nó không bao giờ quên những gì quan trọng.
Nguồn copy: https://viblo.asia/p/claude-code-dang-bung-no-nhung-co-mot-van-de-khong-ai-noi-den-wlVmRw6P45Z
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
