# Học agent bằng một việc thật

Một dự án nhỏ chỉ giúp ta học khi có phản hồi rõ. Chọn đầu ra kiểm chứng được, xây bộ câu hỏi và tìm đúng lớp gây lỗi trước khi đổi công cụ.

URL: https://laban.cc/posts/hoc-agent-bang-mot-viec-that
Biên soạn: La Bàn Editorial (AI-assisted)
Nguồn: A Motorcycle for the Mind — https://nav.al/ai

Bạn có thể dành nhiều buổi đọc về agent mà vẫn thấy khó bắt đầu một việc cụ thể. Thuật ngữ đã quen, tên công cụ đã nhớ, nhưng khi gặp một đầu vào lộn xộn hoặc một kết quả sai, bạn chưa biết nên sửa phần nào.

Đó không nhất thiết là dấu hiệu học chưa đủ. Có thể điều đang thiếu là một vòng phản hồi: đặt ra một đầu ra, thử tạo nó, nhìn chỗ sai và thay đổi cách làm. Một dự án đủ nhỏ để đi hết vòng ấy có thể giúp kiến thức tìm được chỗ đứng trong công việc.

## Học qua việc làm cần có phản hồi

Trong “A Motorcycle for the Mind”, đăng ngày 19/02/2026 trên nav.al, Naval nhấn mạnh việc xây dựng và tiếp xúc với phản hồi thực tế. Cuộc trò chuyện cũng bàn về cách coding agent chuyển mô tả cùng phản hồi thành ứng dụng. Từ điểm gợi mở này, La Bàn phát triển một cách học qua dự án nhỏ; tình huống và quy trình dưới đây là phân tích riêng.

Tự tay làm một việc chưa bảo đảm sẽ học được nhiều. Nếu không kiểm tra kết quả hoặc không biết tiêu chí đúng, bạn có thể lặp lại cùng một sai lầm trong nhiều dự án. Giá trị của thực hành nằm ở việc nhìn ra khoảng cách giữa điều mình nghĩ sẽ xảy ra và điều đã thực sự xảy ra.

Vì thế, một bài tập tốt cần có đầu ra đủ rõ để đánh giá, dữ liệu đủ gần để bạn kiểm chứng và phạm vi đủ nhỏ để sửa thêm một vòng. Một vấn đề quá lớn dễ khiến thất bại trở thành một cảm giác chung chung: mọi thứ đều khó và không biết bắt đầu điều chỉnh từ đâu.

## Chọn một việc có thể nhìn thấy điểm kết thúc

Hãy xét một tình huống giả định: bạn có một tập ghi chú công khai dùng để hướng dẫn thành viên mới trong một nhóm cộng đồng. Mọi người thường hỏi lại các câu về lịch sinh hoạt, cách đăng ký và nơi tìm tài liệu. Bạn muốn thử một trang tra cứu nhỏ.

Mục tiêu có thể là giúp người mới tìm được thông tin trong đúng tập ghi chú ấy, có đường dẫn về đoạn gốc và thấy rõ khi dữ liệu chưa đủ. Mục tiêu này nhỏ hơn việc tạo một trợ lý biết mọi thứ về hoạt động của nhóm. Nó cũng cho bạn một tập kết quả có thể kiểm tra trực tiếp.

Vòng đầu chỉ cần một cách nhập câu hỏi và một cách trình bày kết quả. Đăng nhập, cá nhân hóa, giọng nói và thiết kế nhiều màn hình có thể chờ. Khi những phần ấy xuất hiện quá sớm, thời gian làm đẹp sản phẩm dễ lấn át thời gian tìm hiểu xem công cụ có trả lời đúng hay không.

## Viết bộ câu hỏi trước khi xem bản trình diễn

Chuẩn bị một nhóm câu hỏi mà ghi chú có câu trả lời rõ. Tiếp đó là những câu chắc chắn chưa có dữ liệu. Cuối cùng là các câu mơ hồ: cùng một tên hoạt động nhưng ở hai thời điểm, hoặc một câu cần hỏi thêm người dùng mới biết họ muốn gì.

Chẳng hạn, tài liệu chỉ ghi lịch buổi tháng trước. Một câu hỏi về buổi sắp tới cần được nhận diện là thiếu thông tin mới, thay vì dùng lại ngày cũ với giọng chắc chắn. Với câu hỏi có câu trả lời, đường dẫn nguồn phải thực sự dẫn tới phần hỗ trợ cho kết luận.

Viết các trường hợp này trước giúp bạn đánh giá bản đầu bằng cùng một tiêu chuẩn. Nếu chỉ nghĩ ra câu hỏi sau khi thấy giao diện đẹp, ta dễ chọn những câu mà công cụ đang trả lời tốt và bỏ qua phần còn yếu.

Bộ câu hỏi không cần lớn. Nó cần đại diện cho những kiểu sử dụng khác nhau. Mỗi khi có một lỗi đáng nhớ, thêm trường hợp ấy vào bộ kiểm tra để lần chỉnh sau còn nhìn thấy nó.

## Đọc một lỗi theo từng lớp

Giả sử công cụ trả lời sai địa điểm sinh hoạt. Có nhiều nguyên nhân có thể tạo ra cùng một biểu hiện. Ghi chú đầu vào có thể đã cũ. Công cụ có thể lấy nhầm tài liệu. Nó có thể tìm đúng đoạn nhưng diễn giải sai. Hoặc giao diện hiển thị kết quả từ câu hỏi trước đó.

Mỗi nguyên nhân cần một cách sửa khác nhau. Dữ liệu cũ cần được cập nhật hoặc gắn mốc thời gian. Lấy nhầm tài liệu cần xem lại cách tìm kiếm và lựa chọn nguồn. Diễn giải sai cần xem cách đặt câu hỏi, ngữ cảnh và tiêu chí trả lời. Lỗi giao diện cần được kiểm tra như một lỗi phần mềm.

Gọi tất cả những tình huống ấy là mô hình chưa đủ thông minh sẽ khiến bạn khó học. Tương tự, cứ thêm chỉ dẫn dài hơn vào lời nhắc có thể làm quy trình nặng lên mà không chạm vào chỗ hỏng.

Một thói quen hữu ích là lưu lại đầu vào, kết quả nhận được, kết quả mong đợi và căn cứ để biết kết quả mong đợi là đúng. Bốn phần đó biến một lời than phiền thành một trường hợp có thể cùng agent điều tra.

## Thay một điều rồi chạy lại cả bộ

Sau khi có vài lỗi, ta thường muốn sửa cùng lúc mọi thứ: đổi mô hình, viết lại lời nhắc, thêm dữ liệu và thay giao diện. Nếu kết quả tốt hơn, bạn sẽ khó biết thay đổi nào tạo ra khác biệt. Nếu kém đi, việc tìm đường quay lại cũng khó hơn.

Trong giai đoạn học, hãy chọn một giả thuyết. Ví dụ: công cụ đang nhầm vì tài liệu không có ngày cập nhật rõ ràng. Bổ sung ngày vào dữ liệu mẫu, giữ các yếu tố khác tương đối ổn định rồi chạy lại bộ câu hỏi. Quan sát cả câu từng sai và câu từng đúng.

Kết quả cũng có thể bác bỏ giả thuyết của bạn. Việc thêm ngày không giúp công cụ chọn đúng nguồn là thông tin có ích: cần tìm một nguyên nhân khác. Học qua thực hành đòi hỏi sẵn sàng từ bỏ lời giải thích đầu tiên của chính mình.

## Nhờ một người dùng mà không đứng cạnh chỉ đường

Người xây hiểu sẵn công cụ nên rất giỏi tránh những chỗ nó gây khó. Một người mới sẽ hỏi bằng từ khác, dán một đoạn dài hơn hoặc bỏ qua hướng dẫn mà bạn nghĩ rất rõ. Những hành vi ấy giúp kiểm tra cách mình đã hình dung người dùng.

Với bản thử trong ví dụ, có thể nhờ một thành viên tự tìm ba thông tin. Quan sát lúc họ dừng, quay lại hoặc hỏi thêm. Họ không biết phải nhập gì? Không hiểu phần nguồn dẫn? Hay thấy câu trả lời đúng nhưng chưa biết bước tiếp theo?

Ý kiến “trông đẹp” hoặc “có vẻ hữu ích” chưa cho nhiều hướng sửa. Một hành vi cụ thể như liên tục mở tài liệu gốc vì không tin phần trả lời cho biết rõ hơn điều cần kiểm tra. Đồng thời, bạn có thể nhận ra trang tìm kiếm đơn giản đã phục vụ đủ nhu cầu, chưa cần một cuộc trò chuyện nhiều bước.

## Mang điều đã học sang việc tiếp theo

Khi kết thúc một vòng, đừng chỉ lưu đường dẫn sản phẩm. Ghi lại điều gì làm kết quả tốt hơn, điều gì đã thử mà không giúp và bạn biết được giới hạn nào của dữ liệu hoặc cách kiểm tra.

Một dự án nhỏ có thể dạy rằng thông tin cần mốc thời gian, rằng câu trả lời nên đi cùng nguồn hoặc rằng điều kiện thiếu dữ liệu phải được thể hiện rõ. Những bài học đó có thể tiếp tục hữu ích khi công cụ, mô hình và giao diện đã thay đổi.

Bạn chưa cần chọn một lộ trình học hoàn hảo. Chỉ cần một việc đủ gần để kiểm chứng, một vòng đủ ngắn để hoàn tất và sự kiên nhẫn nhìn thẳng vào chỗ kết quả chưa đúng. Đó là nơi việc học bắt đầu bám vào thực tế.

---
Phân tích độc lập của La Bàn, biên soạn cùng AI. Các tình huống và khung thực hành do La Bàn phát triển; bài không phải bản dịch toàn văn hay phát ngôn chính thức của tác giả nguồn.