Bàn họp có một kiểu bừa bộn rất quen: hai chiếc laptop, ly cà phê đã nguội, cuốn sổ mở ở trang ghi chú bug hôm qua, và một đoạn chat AI đã kéo dài gần một giờ. Lúc đầu, trợ lý trả lời khá sắc. Nó nhớ failing test, tên file, edge case, và lý do team không muốn refactor lớn hơn. Nhưng đến khoảng lượt hỏi thứ tám, nó bắt đầu lệch. Nó gợi ý lại một hướng đã bị loại. Nó quên một ràng buộc. Giọng trả lời vẫn tự tin, nhưng cuộc trò chuyện đã nặng hơn chính cái task ban đầu.
Đó là context window bottleneck trong một hình dạng rất đời thường. AI tool có thể tạo cảm giác như nó có sự kiên nhẫn vô hạn, nhưng nó không có working memory vô hạn. Mỗi model có một context window: lượng text, code, tool output và lịch sử hội thoại mà nó có thể xem xét cùng lúc. Khi công việc nằm gọn trong cửa sổ đó, AI có thể giống một đồng nghiệp cẩn thận đến bất ngờ. Khi công việc tràn ra ngoài, nó có thể nén, bỏ qua, hoặc mất dấu những chi tiết vẫn còn quan trọng với bạn.
Điều này khác với chủ đề context engineering rộng hơn. Context engineering hỏi model cần thông tin gì để làm tốt. Context window bottleneck hỏi một câu hẹp hơn và vận hành hơn: ngay cả khi bạn biết thông tin nào quan trọng, chuyện gì xảy ra khi có quá nhiều thông tin để giữ trong tầm nhìn cùng lúc? Một team có thể viết prompt rõ, đính đúng file, nhưng output vẫn yếu vì task lớn hơn active workspace của model.
Nơi dễ thấy nhất là một codebase lớn. Một bug có thể phụ thuộc vào một route handler, hai helper dùng chung, một database migration, một feature flag, test fixture, và một quyết định trong PR trước. Mỗi mảnh riêng lẻ không quá lớn. Nhưng đặt cạnh nhau, chúng tạo thành một working set. Nếu AI chỉ thấy route handler, nó đoán. Nếu nó thấy cả repository, nó ngợp. Điểm nghẽn không chỉ là model thông minh đến đâu, mà là đúng lát cắt của hệ thống có đang hiện ra đúng lúc hay không.
Hội thoại dài cũng tạo áp lực tương tự. Mỗi lượt trao đổi đều chiếm chỗ. Những quyết định đầu buổi, lựa chọn đã loại, và các chỉnh sửa nhỏ vẫn nằm trong transcript, kể cả khi chúng không còn hữu ích. AI phải dành một phần chú ý để đọc lại những đoạn qua lại cũ thay vì tập trung vào vấn đề hiện tại. Sau đủ nhiều lượt, bắt đầu lại với một state summary gọn có khi tốt hơn là tiếp tục một chat về lý thuyết vẫn nhớ mọi thứ nhưng thực tế đang phải suy luận trên quá nhiều nhiễu.
Vì vậy context window lớn hơn có ích, nhưng không làm vấn đề biến mất. Một cái bàn lớn hơn cho phép bạn trải nhiều tài liệu hơn, nhưng nó không tự quyết định tài liệu nào đáng chú ý. Nếu trên bàn có product spec, log, test, docs, release note và ba file không liên quan, model vẫn phải đoán thứ nào quan trọng. Nhiều dung lượng hơn giảm một loại ma sát. Nó không thay thế việc chọn lọc.
Một cách xử lý hữu ích là xem context như một working set, không phải một kho lưu trữ. Trước khi nhờ AI giải quyết task, hãy quyết định thứ gì cần active ngay lúc này. Với bug, đó có thể là failing test, hàm đang nghi ngờ, error message, và một đoạn ngắn nói rõ đã thử gì. Với câu hỏi architecture, đó có thể là constraint hiện tại, non-goal, và hai hoặc ba module nơi quyết định sẽ chạm vào. Những thứ khác vẫn có thể là tài liệu tham khảo, nhưng không nhất thiết phải nằm trong tầm nhìn tức thời của model.
Summary sẽ hữu ích khi nó được viết như state, không phải trang trí. Một summary tốt nói rõ điều gì đã biết, điều gì đã quyết, hướng nào đã bị loại, và phần nào còn chưa chắc. Một summary yếu chỉ nói cuộc trò chuyện nói về authentication và performance. Cái đầu tiên mang working memory đi tiếp. Cái thứ hai chỉ là nhãn chủ đề. Khi session đã dài, dừng lại để viết một state note gọn không phải overhead. Đó là cách giữ câu trả lời tiếp theo khỏi được xây trên một phiên bản mờ của một giờ trước.
Retrieval system và code search cũng giúp, nhưng chúng kéo theo trách nhiệm riêng. Nếu search trả về sai file, model sẽ suy luận từ sai căn phòng. Nếu nó trả về quá nhiều file, bottleneck quay lại dưới hình dạng khác. Con người vẫn cần nhìn xem context được lấy ra có liên quan thật không. Trong thực tế, AI workflow tốt thường kết hợp search, vài trích đoạn nhỏ được chọn, và một câu mô tả task hiện tại do con người viết. Máy tìm ứng viên; con người bảo vệ ranh giới của vấn đề.
Cũng có một mặt cảm xúc trong điểm nghẽn này. Khi AI quên một constraint, mình dễ cảm thấy tool đang cẩu thả. Đôi khi lời giải thích đơn giản hơn là working memory đã trở nên nhiễu. Điều đó không làm output tự nhiên đáng tin, nhất là với production work, nhưng nó đổi cách mình phản ứng. Thay vì tranh luận thêm năm lượt với trợ lý, mình có thể reset workspace: nhắc lại quyết định, bỏ context cũ, đưa đúng file, và yêu cầu một bước tiếp theo hẹp hơn.
Thói quen tôi tin nhất khá nhỏ: giữ một task state nhìn thấy được bên cạnh cuộc trò chuyện AI. Mình đang cố làm gì? File nào quan trọng? Hướng nào đã loại? Điều gì không được thay đổi? Cái gì sẽ chứng minh câu trả lời là an toàn? Ghi chú này có thể chỉ vài dòng. Giá trị của nó không nằm ở hình thức, mà ở việc giữ con người và model cùng nhìn vào một thực tại hiện tại.
Context window bottleneck không phải lý do để dùng AI ít đi. Nó là lý do để dùng AI với ranh giới sạch hơn. Làm việc tốt với AI không chỉ là đưa thêm thông tin cho model. Nó là giữ nguyên hình dạng của vấn đề khi công việc bắt đầu lộn xộn. Nếu bạn từng thấy một đoạn chat AI từ từ mất mạch, câu hỏi hữu ích tiếp theo có lẽ không phải là prompt thế nào cho mạnh hơn. Có lẽ là: lúc này, thứ gì nên nằm trên bàn, và thứ gì có thể tạm rời khỏi đó?