Nguyen Le PhongNguyen Le Phong

Thụ, chấp, phá: học mà không mắc kẹt trong cái biết

Một ghi chú suy ngẫm về cách học trong thời đại AI: thụ để tiếp nhận, chấp để biến tri thức thành niềm tin có ích, rồi phá để vượt qua chính giới hạn của cái mình từng biết. Bài viết đi qua câu nói "Tôi biết rồi", knowledge obesity, niềm tin cứng từ kinh nghiệm dài hạn, nhãn dán ban đầu, process decrypt, Echology check và PAIR framework.

Một buổi chiều nhìn hàng comment trong code review, tôi bắt gặp trong đầu mình câu rất quen: Tôi biết rồi. Nó xuất hiện nhanh đến mức gần như vô thức. Một người góp ý về cách đặt tên, một tài liệu nhắc lại nguyên tắc tôi từng đọc, một đoạn hội thoại nói về AI theo hướng tôi nghĩ mình đã hiểu. Phản xạ đầu tiên không phải là tò mò, mà là đóng cửa. Tôi đã gặp ý này rồi, đã nghe rồi, đã dùng rồi. Nhưng chính khoảnh khắc ấy làm tôi hơi khựng lại, vì biết rồi đôi khi chỉ là cách lịch sự hơn của việc không muốn học tiếp.

Tôi ghi lại ba chữ thụ chấp phá như một cái khung nhỏ để tự kiểm tra chuyện học. Thụ là tiếp nhận: đọc, nghe, quan sát, thử một công cụ mới, nhận một phản hồi không dễ chịu. Chấp là phần tri thức bắt đầu đóng lại thành niềm tin, kinh nghiệm, thói quen, hoặc một cách nhìn mình dùng để ra quyết định. Không có chấp thì con người rất mệt, vì mọi thứ lúc nào cũng phải nghĩ lại từ đầu. Nhưng nếu chỉ thụ rồi chấp, kiến thức dần trở thành một căn phòng đầy đồ, nhiều thứ từng hữu ích nhưng không còn biết món nào đang cản lối đi.

Phá vì vậy không phải là phủ nhận sạch những gì mình biết. Nó là khả năng nới lỏng cái khung cũ đúng lúc, để tìm tri thức mới hoặc nhìn lại tri thức cũ trong một bối cảnh khác. Một người học lâu năm thường không thiếu thông tin. Cái khó hơn là nhận ra chỗ nào mình đang bám quá chắc. Khi câu Tôi biết rồi bật ra, câu hỏi tiếp theo nên là: tôi thật sự đã hiểu tới mức dùng được chưa, hay tôi chỉ nhận ra cái tên của khái niệm? Tôi có thể giải thích nó cho người mới không? Tôi có thể áp dụng nó trong một hoàn cảnh đang thay đổi không? Hay tôi đang bị knowledge obesity, nạp quá nhiều nhưng chuyển hóa quá ít?

Knowledge obesity là cảm giác rất hiện đại. Feed đầy bài hay, course đầy thư mục, note đầy quote, AI có thể tóm tắt thêm bất cứ lúc nào. Ta dễ thấy mình đang tiến bộ vì đầu vào không bao giờ ngừng. Nhưng tri thức không trở thành năng lực chỉ vì nó đi qua mắt. Nó cần được dùng, bị va đập, bị sửa bởi thực tế, rồi được nối lại thành một cách hành động tốt hơn. Nếu một ý tưởng chỉ làm mình thấy thông minh hơn trong lúc đọc, nhưng không đổi cách mình hỏi, làm, nghe, hoặc quyết định, nó vẫn còn nằm ở tầng trang trí.

Cái chấp nhiều nhất thường không đến từ sách, mà đến từ kinh nghiệm dài hạn. Chính vì ta đã từng trả giá để học nó, ta càng tin nó là đúng. Tôi nghĩ tới Paul và Brian như hai người có hai lịch sử khác nhau. Paul lớn lên trong một môi trường enterprise ổn định, nơi quy trình chặt, review nhiều tầng và tài liệu rõ đã cứu cả hệ thống khỏi những lỗi đắt đỏ. Với Paul, thêm process là thêm an toàn. Brian lại trưởng thành trong một startup nhỏ, nơi cơ hội biến mất rất nhanh, khách hàng đổi ý từng tuần, và quá nhiều process từng làm team lỡ nhịp. Với Brian, bớt process là giữ sự sống. Cả hai đều có lý trong dòng sông của mình. Vấn đề bắt đầu khi mỗi người đem kinh nghiệm thật của mình biến thành luật phổ quát cho mọi dòng sông khác.

Vì vậy tôi ngày càng cẩn thận hơn với những nhãn dán ban đầu. Lần đầu gặp một người, một công cụ, một team, một cách làm, đầu óc rất thích đặt tên thật nhanh: người này khó làm việc, công cụ này nguy hiểm, team này thiếu kỷ luật, phương pháp này chỉ là phong trào. Nhãn dán giúp ta phản ứng nhanh, nhưng nó cũng làm ta lười quan sát tiếp. Câu Không ai tắm 2 lần trên 1 dòng sông nhắc tôi rằng cả dòng sông lẫn người bước xuống đều đã đổi. Một niềm tin đúng ở tháng trước có thể chỉ còn đúng một nửa ở tháng này. Một nhận xét ban đầu có thể cần được cập nhật sau khi mình có thêm dữ kiện, thêm va chạm, hoặc thêm sự khiêm tốn.

Đến AI, câu hỏi này càng rõ hơn. Có lúc tôi thấy nhiều cuộc nói chuyện xoay quanh việc Controls AI, kiểm soát AI như thể đó là việc cấp bách nhất. Kiểm soát là cần, nhất là với dữ liệu, quyền riêng tư, chất lượng và trách nhiệm. Nhưng nếu chỉ chăm chăm kiểm soát công cụ, ta dễ bỏ qua một tầng gần hơn: kiểm soát tiến trình tư duy của chính mình. AI thường khuếch đại cách ta nghĩ. Nếu suy nghĩ mơ hồ, nó làm ra nhiều phiên bản mơ hồ hơn. Nếu câu hỏi nông, nó trả lời bằng sự trơn tru của cái nông. Nếu tiêu chuẩn đánh giá yếu, nó làm ta tin vào một bản nháp nghe rất ổn nhưng chưa thật sự đúng.

Trước khi nhờ AI làm nhanh hơn, tôi cần làm một việc mà tôi gọi là process decrypt: giải mã tiến trình tư duy. Tức là nhìn vào cách mình đang đi từ vấn đề đến quyết định. Tôi đang giả định điều gì? Tôi đang bỏ qua dữ kiện nào? Tôi đang nhảy cóc từ cảm giác sang kết luận ở bước nào? Tôi đang cần sáng tạo, phân tích, kiểm chứng, hay chỉ cần diễn đạt lại? Khi tiến trình còn là một khối mù, mình rất dễ giao sai việc cho người khác, kể cả cho AI. Khi tiến trình được giải mã, nó bắt đầu có thể được chia nhỏ, kiểm tra và cải thiện.

PAIR là một khung tôi thấy hữu ích cho đoạn đó: Parse, Assign, Integrate, Refine. Parse là chuyển tiến trình ra nhiều step nhỏ, để một vấn đề không còn là cục mây lớn treo trong đầu. Assign là cho người chuyên, hoặc cho đúng công cụ, đúng đồng đội, đúng AI agent, đúng phần năng lực của chính mình. Integrate là nối các kết quả rời lại thành một bức tranh có nghĩa, vì nhiều đầu ra tốt vẫn có thể tạo thành một quyết định rối nếu không ai chịu tổng hợp. Refine là quay lại mài, kiểm tra giả định, bỏ phần dư, thêm phần thiếu, rồi thử lại với thực tế. Nếu làm nghiêm túc, PAIR không chỉ giúp dùng AI tốt hơn. Nó giúp mình thấy rõ cách mình học, làm và quyết định.

Nhưng bất kỳ framework nào cũng cần một lần kiểm tra cân bằng. Tôi gọi bước này là Echology check: kiểm tra xem cách làm mới có phá vỡ hệ sinh thái xung quanh không. Một quy trình AI có làm team phụ thuộc vào một người biết prompt nhất không? Nó có làm kỹ năng nền của mình teo lại vì cái gì cũng hỏi máy trước khi tự nghĩ không? Nó có làm thông tin nhạy cảm đi qua nơi không nên đi qua không? Nó có tiết kiệm thời gian cho mình nhưng đẩy gánh kiểm tra sang người khác không? Một cách làm nhanh hơn chưa chắc là một cách làm lành hơn nếu nó làm mất cân bằng giữa tốc độ, trách nhiệm, năng lực và niềm tin.

Câu Không giải quyết vấn đề đã tạo ra bởi tầng đó cũng đi cùng hướng này. Có những lỗi không thể sửa ở cùng tầng sinh ra chúng. Nếu output AI kém vì prompt mơ hồ, sửa vài chữ trong prompt có thể giúp một chút, nhưng tầng sâu hơn là mình chưa hiểu tiêu chuẩn của việc tốt. Nếu team tranh luận mãi về một task, vấn đề có thể không nằm ở task, mà ở tầng mục tiêu, quyền quyết định, hoặc cách chia trách nhiệm. Nếu mình cứ học thêm mà không giỏi hơn, vấn đề không nằm ở việc thiếu nguồn học, mà ở tầng chuyển hóa: thiếu thực hành, thiếu phản hồi, thiếu một việc thật để kiến thức bám vào. Muốn phá, đôi khi phải bước lên một tầng cao hơn để nhìn lại hệ thống đã tạo ra vấn đề.

Nhìn lại, thụ chấp phá không phải là một khẩu hiệu học tập. Nó giống một vòng kiểm tra vệ sinh cho cái đầu. Thụ để mình không đóng kín. Chấp để mình có nền mà hành động, không trôi nổi trong vô hạn lựa chọn. Phá để nền ấy không biến thành nhà tù. AI, PAIR, process decrypt hay Echology check chỉ là các dụng cụ phụ trợ cho cùng một việc: giữ cho tri thức còn sống. Cái biết còn sống là cái biết vẫn chịu được câu hỏi mới, bối cảnh mới, người phản biện mới, và chính phiên bản mới hơn của mình.

Có lẽ điều tôi muốn giữ lại sau ghi chú này là: lần sau khi câu Tôi biết rồi xuất hiện, tôi sẽ không vội tin nó. Tôi sẽ hỏi nhẹ hơn: mình biết ở tầng nào, biết bằng trải nghiệm nào, trong bối cảnh nào, và đã đến lúc phá một phần nào của cái biết ấy chưa? Nếu bạn cũng từng có một niềm tin rất chắc rồi sau này phải chỉnh lại, tôi muốn nghe câu chuyện đó, vì nhiều khi chính những chỗ ta từng chắc nhất lại là nơi việc học thật sự bắt đầu lại.

Bạn thấy bài này thế nào?