Khi làm việc với trợ lý AI, lời khuyên phổ biến nhất luôn là: hãy viết đề bài cho thật chặt. Đưa vào đầy đủ ngữ cảnh, giới hạn chính xác các file được đọc, liệt kê từng dữ kiện được phép dùng, và khóa chặt phạm vi đầu ra. Đề bài càng chặt chẽ, kết quả trả về càng sạch sẽ.
Điều đó đúng, nhưng chỉ là một nửa của câu chuyện.
Mặt sau của lời khuyên đó là một nghịch lý ít người nhắc tới: đề bài càng chặt bao nhiêu, thì cái sai nằm trong đề bài của bạn sẽ càng đi xa bấy nhiêu mà không gì chặn. Khi tước đi quyền tự do suy diễn của mô hình để đổi lấy sự chính xác, bạn cũng đồng thời tước đi khả năng tự phản biện và chỉnh sửa của nó.
Tuần này, khi điều phối các tác vụ tự động cho dự án, tôi đã chứng kiến tận mắt cơ chế đó: một model nhanh hoàn thành xuất sắc mọi yêu cầu kỹ thuật, viết ra một bài văn trôi chảy đến mức hoàn hảo — chỉ có điều nó chép lại y nguyên một tiền đề sai lệch do chính tôi viết trong bản mô tả yêu cầu. Không một câu hỏi ngược, không một chút ngờ vực.
Mười lăm tờ đề bài, và vì sao tôi bỏ công viết chúng
Để các tác vụ không bị trượt ray, tôi xây dựng một bộ gồm 15 tờ đề bài lưu trực tiếp trên đĩa, với tổng dung lượng 120.865 byte — trung bình mỗi tờ chiếm khoảng 8 KB.
Bộ đề bài này sinh ra 6 bản nháp văn xuôi, một trang công cụ, một engine tính chi phí có đầy đủ kiểm thử, và hai đợt bóc tách dữ liệu.
Mỗi tờ đề bài được chuẩn hóa theo cùng một bộ khung nghiêm ngặt: lý do tác vụ tồn tại, danh sách file được đọc (và chỉ những file đó), đường dẫn kết quả chính xác, danh sách dữ kiện được phép dùng, tiêu chí nghiệm thu, danh sách điều cấm, và các tình huống bắt buộc phải dừng lại báo cáo.
Việc mô tả việc cho đủ rõ giúp loại bỏ sự mơ hồ trong giao tiếp. Đặc biệt, việc giới hạn danh sách file được đọc là yếu tố cốt lõi của context chứ không phải prompt: nó cô lập không gian làm việc, ngăn mô hình nạp dữ liệu rác, và bảo đảm mọi kết quả đều dựa trên những nguồn đã được kiểm chứng.
📥 Tải miễn phí
Bộ Khung Repo Cho AI Agent
Đề bài đóng kín làm một model nhanh chạy sạch
Quy trình đóng kín này phát huy hiệu quả xuất sắc qua một loạt tác vụ kỹ thuật.
Tác vụ xây dựng engine tính chi phí khớp đề bài từng dòng, vượt qua toàn bộ 8 trên 8 assertion kiểm thử, và không thêm bất kỳ dependency nào.
Tác vụ trích xuất dữ liệu telemetry từ các phiên làm việc trước đó đối chiếu độc lập khớp 26 trên 27 phiên. Phiên lệch duy nhất là phiên đang chạy dở lúc đo đạc và tiếp tục phát sinh tương tác giữa chừng.
Tác vụ đóng băng dữ liệu và phân tách chi phí theo từng dòng mô hình khi cộng tổng lại cũng khớp hoàn toàn với tổng cũ ở cả bốn trường token.
Cả ba lần thực thi đều trả về kết quả sạch sẽ. Khi được đặt trong một không gian có luật chơi khép kín và tiêu chuẩn đối chứng định sẵn, một model nhanh cho thấy nó cực kỳ đáng tin cậy.
Rồi tôi ghi sai một dòng
Chính sự trơn tru của các tác vụ trước đã tạo ra sự chủ quan ở khâu chuẩn bị đề bài.
Trong một tờ đề bài cho bài viết so sánh giữa gói thuê bao và hình thức dùng theo lượng tiêu thụ, tôi đã tự tay viết vào một dữ kiện sai: tôi ghi rằng giá các gói thuê bao là thứ không kiểm chứng được nên phải để trống trong bảng giá.
Đó là nhận định sai. Giá thuê bao là thông tin công khai và tra cứu được dễ dàng trên trang web của các nhà cung cấp. Thứ không ai công bố là hạn mức sử dụng tính bằng token, chứ không phải giá tiền. Tử số thì rõ ràng; mẫu số mới là thứ không tồn tại.
Nhưng vì một thoáng nhầm lẫn khi tổng hợp thông tin, tôi đã đưa tiền đề sai đó vào danh sách dữ kiện được phép dùng của tờ đề bài, rồi gửi đi cho mô hình thực thi.
Nó không ngờ vực một giây nào
Khi nhận tờ đề bài chứa tiền đề sai lệch, mô hình thực thi làm chính xác những gì được giao.
Nó không thắc mắc, không kiểm tra lại, và không ngờ vực một giây nào.
Nó lấy đúng dòng dữ kiện sai đó, gọt giũa thành câu văn trôi chảy, lập luận khúc chiết, và đặt vào đúng vị trí đắc địa nhất để chứng minh cho quan điểm của đề bài. Câu văn xuôi tai đến mức người đọc lướt qua sẽ hoàn toàn tin đó là phân tích có căn cứ.
Sự cố này khác hẳn lần trước con làm nghiên cứu trả về số đúng gắn nhãn sai. Lần đó mô hình tự bịa thông tin khi tra cứu mở. Lần này mô hình không hề tự bịa — nó chấp hành kỷ luật tuyệt đối, và chính sự chấp hành đó đã khuếch đại cái sai của người viết đề bài lên mức tối đa.
Bản nháp đó còn để lọt một mã dữ kiện nội bộ ra thẳng câu văn cho người đọc, đồng thời gọi khoảng cách giữa nhiều phiên là biến động trong một phiên. Hai lỗi này là lỗi thực thi của mô hình, nhưng lỗi sai về bản chất dữ liệu lại hoàn toàn bắt nguồn từ chính tôi.
Bốn bài đi thẳng ra production, bỏ qua cổng soát
Khi quy trình tự động hóa chạy quá mượt mà, cái bẫy lớn nhất là sự mất cảnh giác.
Bốn bản nháp trong đợt làm việc đó đã đi thẳng ra production mà không qua cổng kiểm duyệt của người soát.
Hậu quả xuất hiện ngay: một trong bốn bài khi lên sóng mang theo chỗ hỏng về tính trung thực. Nó gọi con số quy đổi theo biểu giá chuẩn là chi phí "đo được", trong khi thực tế tác giả dùng gói thuê bao cố định hằng tháng và chưa từng trả tiền theo cách ấy. Chỗ hỏng chỉ bị bắt sau khi bài đã live.
Trong khi đó, một bài khác cùng đợt có đi qua tay người soát đã có sẵn câu đính chính rõ ràng ngay tại vị trí đó.
Cùng một chuẩn, hai bài viết lại có kết quả khác nhau: một bài chuẩn mực, còn một bài dính lỗi trên sản phẩm thật. Khác biệt duy nhất là có qua cổng soát hay không.
Cổng soát không phải thủ tục
Từ sự cố này, tôi rút ra ba nguyên tắc sống còn khi làm việc với trợ lý AI:
1. Đề bài chặt nhân năng lực lên, và nhân sai sót lên cùng một hệ số. Đó là cùng một cơ chế, không phải hai. Khi khóa chặt mọi nguồn dữ liệu và ép mô hình chỉ dùng dữ kiện định sẵn, bạn tạo ra cỗ máy thực thi cực kỳ chính xác. Nhưng nếu chính bạn đưa vào dữ kiện hỏng, cỗ máy đó sẽ biến cái sai thành sản phẩm hoàn thiện với tốc độ tương đương.
2. Model không có nghĩa vụ ngờ vực đề bài, và cũng không có khả năng đó. Chỗ duy nhất cái sai của người viết đề bài bị chặn là mắt người thứ hai đọc lại kết quả. Một mô hình thực thi không được thiết kế để nghi ngờ tính đúng đắn của người giao việc. Đừng kỳ vọng nó sẽ tự phát hiện mâu thuẫn trong logic của bản yêu cầu.
3. Cổng soát tốn ít hơn hẳn việc gỡ một bài đã live. Bài đã live thì cái sai đã phát tán ra ngoài, làm tổn hại uy tín nội dung và đòi hỏi nhiều công sức đính chính. Vài phút đọc lại của người soát ở bước cuối luôn là khoản đầu tư rẻ nhất để bảo vệ chất lượng dự án.
Điều tôi nhận ra
Sau tuần đó tôi bỏ hẳn ý nghĩ rằng quy trình chạy mượt là quy trình an toàn. Hai thứ đó không liên quan gì đến nhau.
Đề bài chi tiết định hình công việc, model nhanh rút ngắn thời gian, còn cổng soát thì không làm được việc nào trong hai việc đó — nó chỉ có đúng một nhiệm vụ là bắt cái sai của tôi trước khi người đọc bắt được.
Trước khi khép lại, tôi muốn nói rõ về giới hạn của những quan sát này:
Tôi chỉ đích thân soát hai trong sáu bản nháp, nên tôi không có tỉ lệ đạt cho cả bộ và sẽ không dựng ra một tỉ lệ. Cái tôi có là một cơ chế hỏng, quan sát được, và một lần nó đi lọt tới production.
Hiểu rõ cơ chế này giúp chúng ta tỉnh táo hơn khi tiếp nhận các sản phẩm do AI tạo ra. Khi đề bài sai thì sản phẩm đầu ra chắc chắn sẽ sai — và trách nhiệm kiểm soát rủi ro đó luôn thuộc về con người đứng sau hệ thống.
Năm gói giao việc mẫu và khung 9 phần giúp khóa chặt phạm vi tác vụ được tôi chia sẻ trong bộ Token Efficient Vibe Coding Kit để bạn dùng làm khuôn cho dự án của mình.
