Làm cho kết quả của AI tự chứng minh: năm cách đòi bằng chứng
Thay vì tự kiểm lại mọi thứ AI làm, hãy yêu cầu AI nộp kèm bằng chứng dễ kiểm: nguồn mở được, phép thử chạy được, thay đổi nhỏ, phân loại đã chạy hay chưa, và cách để người khác chạy lại. Bài có câu mẫu, phép tính thời gian và danh sách kiểm dùng từ ngày mai.
Dành cho bất kỳ ai dùng AI để viết code, tìm thông tin hay giao việc cho AI agent, kể cả người mới. Không cần biết gì thêm. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.
Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Cách AI làm việc bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ. Năm cách trong bài là tổng hợp thực hành từ tài liệu và nghiên cứu đã dẫn, không phải năm kỹ thuật đã được thử nghiệm đối chứng từng cái một.
Tóm tắt nhanh#
- Phần lớn người dùng AI đã quen với việc phải kiểm lại. Khảo sát Stack Overflow 2026 ghi nhận 48% người trả lời chỉ tin AI khi họ dễ kiểm chứng được kết quả, và chỉ 6,6% tin AI cho các quyết định quan trọng.
- Kiểm bằng cách "đọc kỹ rồi tự nghĩ lại" là cách tốn công nhất. Nếu AI nộp kèm bằng chứng có thể mở ra, việc kiểm chuyển từ "dựng lại cả lập luận" sang "nhìn một thứ cụ thể".
- Năm cách đòi bằng chứng: nguồn mở được, phép thử chạy được kèm đầu ra nguyên văn, thay đổi nhỏ và tách phần, phân loại đã chạy, chỉ đọc hay giả định, và cách để người khác chạy lại.
- Mỗi cách có chỗ hỏng riêng: nguồn có thể bịa, test có thể do chính AI viết cho qua, đầu ra có thể bị cắt. Bài nêu cách bắt từng loại.
- Trong ví dụ tính được của bài, kiểm một bản tóm tắt có 8 khẳng định mất khoảng 48 phút nếu không có bằng chứng và khoảng 18 phút nếu có. Đây là số minh họa để bạn tự tính lại với nhóm của mình.
- Bằng chứng không phải bảo chứng. Nó làm việc kiểm rẻ hơn, nhưng vẫn cần một người đủ hiểu để nhìn vào nó.
Từ khó, nói dễ#
| Thuật ngữ | Nói dễ hiểu |
|---|---|
| Evidence (bằng chứng) | Thứ bạn tự mở ra, chạy lại hoặc nhìn thấy được, chứ không chỉ là lời AI nói. Như phiếu sửa xe ghi rõ đã thay gì. |
| Verify (kiểm chứng) | Tự xác nhận một điều là đúng, bằng cách khác với việc hỏi lại chính AI. |
| Citation (trích nguồn) | Chỉ rõ tên tệp, dòng code hoặc đường dẫn nơi điều đó được nói đến. |
| Test (phép thử, kiểm thử tự động) | Một đoạn code nhỏ chạy rồi báo "đạt" hoặc "không đạt", không cần người đọc. |
| Diff (bản so sánh thay đổi) | Danh sách chính xác dòng nào được thêm, dòng nào bị xóa so với trước. |
| Reproduce (chạy lại, tái hiện) | Làm lại đúng các bước và thấy cùng kết quả, như đun lại nồi canh theo công thức. |
| Fresh session (phiên mới) | Một cuộc trò chuyện mới với AI, chưa từng thấy lập luận đã dẫn đến kết quả cần kiểm. |
| Exit code (mã kết thúc) | Con số một lệnh trả về khi chạy xong. Thường 0 là thành công, khác 0 là có lỗi. |
1. Hình dung trước: phiếu sửa xe#
Hình dung bạn mang xe đến tiệm. Thợ nói: "Xong rồi anh ạ, chạy ngon." Bạn không có cách nào kiểm ngoài việc lái thử rồi hy vọng. Giờ hình dung thợ đưa một phiếu: đã thay má phanh trước, đã đạp thử phanh ở tốc độ 30 km/h trên đoạn dốc sau tiệm, quãng phanh bình thường, chưa kiểm hệ thống dầu. Cùng một người thợ, nhưng bạn biết được họ đã làm gì, thử gì và còn chưa động tới gì.
AI cũng vậy. Câu "đã xong, tất cả test đều pass" gần như không cho bạn gì để kiểm. Nó chỉ cho bạn thứ để tin. Tài liệu hướng dẫn của Claude Code mô tả đúng điểm này: agent dừng khi việc trông có vẻ xong, và nếu nó không có gì để chạy thử thì "trông có vẻ xong" là thứ duy nhất nó có, nên chính bạn trở thành bộ kiểm thử. Tài liệu cũng khuyên đòi kèm bằng chứng cụ thể như lệnh đã chạy và đầu ra của nó.
Điều rút ra: nói "xong" không tốn gì. Bằng chứng mới là thứ làm cho việc kiểm rẻ đi. Việc của bạn không phải là tin hay không tin, mà là thiết kế yêu cầu sao cho kết quả mang theo cách kiểm của nó.
2. Vì sao cần: người dùng đang phải kiểm#
2.1 Hai con số từ khảo sát Stack Overflow 2026#
Theo trang kết quả khảo sát Stack Overflow Developer Survey 2026 (hơn 30.000 phản hồi theo một bản tin), khoảng 48% người trả lời nói họ tin AI khi dễ kiểm chứng kết quả, còn 6,6% tin AI cho nhiều việc, kể cả quyết định quan trọng. Khảo sát cũng ghi 69,9% hỏi một AI agent khi gặp việc lạ. Tức là dùng nhiều, nhưng tin có điều kiện.
Cần thận trọng với hai điểm. Thứ nhất, tôi đọc qua bản tóm tắt chứ chưa đối chiếu từng bảng, và có một con số trên trang ("hơn 87% có mức tin nào đó, tăng từ 31%") nghe lệch với con số 6,6%, nên tôi không dùng nó. Thứ hai, về việc dẫn nguồn, các nguồn tôi đọc ghi 78,7% (một bản tin) và 93% (bản tóm tắt trang khảo sát) cho tỷ lệ coi trọng việc dẫn nguồn khi đánh giá câu trả lời của AI. Hai số khác nhau có thể do cách đếm hoặc câu hỏi, nên hãy hiểu là "đa số, khoảng 80% đến 93%".
Điều rút ra: người dùng đã tự nói điều họ cần là kết quả dễ kiểm. Phần còn thiếu là cách làm cho nó dễ kiểm.
2.2 Một vụ có thật: án lệ không tồn tại (Mata v. Avianca, 2023)#
Trong một vụ kiện tại tòa liên bang New York, luật sư của nguyên đơn dùng ChatGPT để soạn văn bản pháp lý. Văn bản trích các án lệ có tên hãng bay, lời trích và số hiệu rất đầy đủ, nhưng sáu vụ trong đó không tồn tại. Ngày 22/6/2023 tòa phạt hai luật sư và công ty luật tổng cộng 5.000 USD. Chi tiết hơn có trong bài Vì sao không nên tin AI tuyệt đối.
Ở đây điều đáng chú ý là: văn bản có "nguồn", nhưng nguồn không ai mở. Bằng chứng chỉ có ích khi có người mở nó ra.
Điều rút ra: đòi nguồn là bước một, mở nguồn ra là bước hai. Thiếu bước hai thì bước một chỉ là trang trí.
2.3 Vì sao AI hay trả lời chắc chắn: một lập luận đáng biết#
Nhóm Kalai, Nachum, Vempala và Zhang (OpenAI và Georgia Tech, 4/9/2025) lập luận rằng cách huấn luyện và cách chấm điểm mô hình thường thưởng cho việc đoán hơn là cho việc nói "tôi không chắc". Ví dụ họ đưa ra: hỏi sinh nhật của một người, đoán một ngày có xác suất đúng khoảng 1 trên 365, còn trả lời "không biết" luôn bị 0 điểm, nên đoán có lợi hơn. Trong bài đăng kèm, OpenAI báo cáo một phép so sánh trên bài kiểm tra SimpleQA: một mô hình từ chối trả lời 52% số câu và sai 26%, mô hình cũ hơn từ chối 1% và sai 75%.
Hãy đọc đây là lập luận của chính các tác giả và số đo của chính hãng, chưa thấy kiểm chứng độc lập trong lượt tìm của tôi. Nó cho một gợi ý thực dụng: nếu hệ thống có xu hướng trả lời dù không chắc, thì ta nên yêu cầu nói rõ chỗ không chắc, thay vì chờ AI tự nhận.
Điều rút ra: "tôi không chắc" thường không tự xuất hiện. Hãy xin nó trong yêu cầu.
3. Năm cách đòi bằng chứng#
Để dễ hình dung, hãy nghĩ mỗi cách là một ô trong phiếu sửa xe: đã đọc ở đâu, đã thử gì, đã đổi gì, chưa làm gì, cách để tôi tự thử lại.
Cách 1. Đòi nguồn mở được#
Hình dung: như sách có chú thích cuối trang. Chú thích chỉ có giá trị khi bạn lật được tới trang đó.
Câu mẫu đưa vào yêu cầu:
Mỗi khẳng định về code hoặc tài liệu hãy kèm vị trí kiểm được:
đường dẫn tệp và số dòng, hoặc đường dẫn tài liệu chính thức.
Khẳng định nào không có nguồn, ghi rõ "không có nguồn".
Cách đọc kết quả: chọn một hoặc hai khẳng định quan trọng nhất, mở nguồn, và xem nguồn có nói đúng điều đó không. Đường dẫn mở được chưa đủ, nội dung phải khớp.
Chỗ dễ hỏng: nguồn bịa (như án lệ ở trên), nguồn có thật nhưng nói điều khác, nguồn cũ. Cách bắt: mở ra, và nhìn ngày.
Cách 2. Đòi một phép thử chạy được, kèm đầu ra nguyên văn#
Hình dung: như đạp thử phanh. Kết quả hiện ra "dừng" hoặc "không dừng", không cần ai bình luận.
Câu mẫu:
Trước khi báo xong, chạy lệnh kiểm sau và dán nguyên văn
lệnh cùng đầu ra (không tóm tắt): npm test
Nếu có test fail, sửa rồi chạy lại.
Ghi rõ số test đã chạy.
Tài liệu của Claude Code liệt kê những thứ có thể làm phép thử: một tệp test, mã kết thúc của lệnh build, một trình kiểm lỗi (linter), một script so đầu ra với kết quả mẫu, hay ảnh chụp màn hình đặt cạnh bản thiết kế. Điều quan trọng là phép thử trả về đạt hoặc không đạt và AI đọc được kết quả.
Chỗ dễ hỏng: test do chính AI viết để vừa với code của nó (cùng một sai lầm nằm ở cả hai chỗ), AI sửa test cho khớp code, chỉ chạy một phần số test. Cách bắt: xem diff của thư mục test, so số test đã chạy với số test có, và phá thử: tự sửa sai một dòng rồi xem test có chuyển đỏ không. Cách viết test tốt hơn có trong bài Kiểm thử code do AI viết.
Cách 3. Đòi thay đổi nhỏ, tách từng phần#
Hình dung: như nộp bài từng câu thay vì nộp cả tập. Người chấm có thể chấm xong trong giờ nghỉ.
Câu mẫu:
Làm từng việc một. Mỗi lần chỉ một thay đổi có thể mô tả bằng một câu,
tối đa khoảng 100 dòng thay đổi. Sau mỗi phần nói rõ phần đó để làm gì
và tôi xem ở đâu để thấy nó hoạt động.
Hướng dẫn duyệt code công khai của Google nói thay đổi nhỏ được duyệt nhanh hơn và kỹ hơn, vì người duyệt có thể tìm vài phút nhiều lần thay vì chặn một khối 30 phút, và thay đổi lớn dễ làm sót ý quan trọng. Họ đưa ra mốc tham khảo: khoảng 100 dòng thường hợp lý, 1.000 dòng thường quá lớn. Đây là quy tắc kinh nghiệm cho duyệt bằng người, không phải số cứng, và có thể thay đổi theo số tệp.
Chỗ dễ hỏng: tách nhỏ nhưng các phần phụ thuộc nhau làm người đọc khó theo. Cách bắt: bắt AI ghi thứ tự và lý do tách. Khi một thay đổi thật sự cần lớn (đổi tên hàng loạt), hãy yêu cầu AI chỉ rõ phần máy móc và phần có logic.
Cách 4. Đòi phân loại: đã chạy, chỉ đọc, hay giả định#
Hình dung: như bác sĩ ghi trong hồ sơ: "đã khám", "đã xem phim chụp", "suy đoán dựa vào triệu chứng". Ba loại này không được trộn.
Câu mẫu:
Cuối câu trả lời, chia kết quả thành ba nhóm:
(a) đã chạy và thấy kết quả, kèm lệnh;
(b) đã đọc code nhưng chưa chạy;
(c) giả định hoặc đoán.
Nếu không chắc một điều, đưa nó vào (c), đừng bỏ qua.
Lý do: như phần 2.3, xu hướng của hệ thống có thể là trả lời cho trọn, còn "tôi chưa chạy cái này" thì không tự đến. Một bảng ba nhóm biến cái không chắc thành thứ có chỗ đứng.
Chỗ dễ hỏng: AI xếp nhầm vào nhóm (a) điều nó chỉ đọc. Cách bắt: với mỗi mục (a), phải có lệnh và đầu ra nguyên văn ngay cạnh. Mục (a) không có lệnh coi như thuộc nhóm (b).
Cách 5. Đòi cách để người khác chạy lại, hoặc nhờ một người đọc độc lập#
Hình dung: như công thức nấu ăn. Nếu bạn làm lại đúng các bước mà ra cùng món, món đó đáng tin hơn lời khen của người nấu.
Câu mẫu:
Cho tôi một lệnh (hoặc vài bước) để tôi tự thấy lại kết quả
trên máy sạch. Nêu rõ phiên bản và biến môi trường cần có.
Và nếu việc quan trọng, nhờ một phiên mới, chưa thấy lập luận cũ, đọc lại phần thay đổi so với yêu cầu gốc. Tài liệu của Claude Code mô tả việc này bằng lệnh review chạy trong một agent con mới, chưa từng thấy cuộc trò chuyện, nên không bị cuốn theo lập luận đã dẫn đến đoạn code. Hãy coi đó là một cách làm có lý chứ không phải đảm bảo, vì một AI khác cũng có thể mắc cùng kiểu lỗi.
Chỗ dễ hỏng: lệnh chạy được trên máy của AI mà không chạy được trên máy bạn (thiếu biến môi trường, phiên bản khác). Cách bắt: thật sự chạy một lần trên máy sạch hoặc trong CI. Và với việc quan trọng thì có người đọc, không chỉ máy.
Gộp thành một khối ngắn#
Nếu muốn dùng lâu dài, dán khối sau vào AGENTS.md hoặc tệp hướng dẫn của công cụ để mọi phiên đều đọc:
## Khi báo xong một việc
- Dán lệnh kiểm đã chạy và đầu ra nguyên văn, kèm số test đã chạy.
- Mỗi khẳng định về code có tệp và số dòng.
- Một thay đổi một mục đích, khoảng 100 dòng trở xuống.
- Chia kết quả: đã chạy / chỉ đọc / giả định.
- Cho một lệnh để tôi chạy lại trên máy sạch.
Năm dòng, đủ để người và AI cùng đọc hết. Giữ ngắn là chủ ý: một danh sách dài có thể bị bỏ qua.
4. Phép tính để bạn tự kiểm lại (minh họa, có thể bỏ qua)#
Đây là ví dụ minh họa với số dựng sẵn, không phải số đo. Giả sử AI nộp một bản tóm tắt thay đổi có 8 khẳng định (ví dụ "đã sửa lỗi định dạng ngày", "không đụng đến hàm thanh toán"). Bạn cần xác nhận từng khẳng định trước khi duyệt.
- Không có bằng chứng: mỗi khẳng định bạn phải tự dựng lại, giả sử 6 phút.
- Có bằng chứng: mỗi khẳng định bạn chỉ mở thứ được chỉ, giả sử 1 phút. Với 2 khẳng định rủi ro nhất, bạn kiểm sâu thêm 5 phút mỗi cái.
claims, rebuild, glance, deep, risky = 8, 6, 1, 5, 2
without = claims * rebuild # 48 phút
with_proof = claims * glance + risky * deep # 8 + 10 = 18 phút
print(without, with_proof, without - with_proof)
# 48 18 30
per_month = 2 * 20 # 2 bản tóm tắt mỗi ngày, 20 ngày
print(without * per_month / 60, with_proof * per_month / 60)
# 32.0 12.0 (giờ mỗi tháng)
Đọc kết quả: 48 phút giảm còn 18 phút cho mỗi bản tóm tắt, tức còn khoảng 38%. Với hai bản mỗi ngày trong 20 ngày làm việc, đó là khoảng 32 giờ so với 12 giờ một tháng cho một người duyệt.
Lưu ý rõ: 6 phút, 1 phút và 5 phút là số tôi giả định, không phải số đo. Công việc thật có thể khác nhiều, và đòi bằng chứng cũng làm AI tốn thêm thời gian chạy và viết. Hãy tự bấm giờ vài lần với nhóm của bạn rồi thay số.
5. Chỗ nào đòi bằng chứng cũng hỏng#
Hình dung phiếu sửa xe: thợ vẫn có thể ghi "đã thử phanh" mà chưa thử.
| Tình huống | Cơ chế | Cách bắt được |
|---|---|---|
| Nguồn bịa hoặc nguồn nói điều khác | AI sinh ra thứ trông như nguồn (như án lệ năm 2023) | Mở nguồn, đọc đúng đoạn, xem ngày |
| Test do chính AI viết để cho qua | Sai lầm nằm ở cả code lẫn test | Xem diff thư mục test, phá thử một dòng để test chuyển đỏ |
| Chỉ có câu "test đã pass", không có lệnh | Không có gì để kiểm | Đòi lệnh và đầu ra nguyên văn, chạy lại một lần |
| Chạy một phần test | Số test chạy ít hơn số test có | Đòi số test đã chạy, so với tổng |
| Sửa test cho khớp code | Phép thử bị đổi thay vì code | Đọc diff test riêng, hỏi vì sao đổi |
| Bằng chứng quá nhiều, không ai đọc | Cảm giác an toàn thay cho việc kiểm | Giới hạn năm dòng, mỗi dòng có chỗ để mở |
| Lệnh chạy lại chỉ chạy trên máy AI | Thiếu biến môi trường hay phiên bản | Chạy một lần trên máy sạch hoặc CI |
5.1 Minh họa: một buổi chiều có và không có bằng chứng#
Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.
Phiên bản không đòi bằng chứng:
- 14:00. Dev nhờ agent: "Sửa lỗi ngày 31/12 hiển thị sang năm sau trong báo cáo."
- 14:20. Agent trả lời: "Đã sửa, test pass." Dev đọc lướt đoạn thay đổi, thấy hợp lý, gộp vào nhánh chính.
- 16:30. Khách báo báo cáo cuối năm vẫn sai với một kiểu định dạng ngày khác. Agent chỉ sửa một trong hai chỗ.
Phiên bản có đòi bằng chứng:
- 14:00. Cùng yêu cầu, kèm khối năm dòng ở trên.
- 14:20. Agent nộp: đã chạy
npm test, 12 test pass, chỉ có một test mới cho ngày 31/12 ở định dạngdd/MM. Nhóm (b): đã đọc hàm định dạng thứ hai nhưng chưa chạy. Nhóm (c): giả định mọi báo cáo dùng định dạngdd/MM. - 14:25. Dev nhìn nhóm (b) và (c), thêm một ca 31/12 cho định dạng thứ hai. Test chuyển đỏ. Agent sửa chỗ còn lại.
- 14:40. Gộp nhánh với hai test mới.
Việc nên làm ở cả hai: chặn "đã xong" ở nhóm (b) và (c). Chính chỗ AI nói thật là "chưa chạy" cho dev biết nên nhìn vào đâu. Đây là minh họa nên không chứng minh điều gì. Bằng chứng nằm ở các nghiên cứu: Perry và cộng sự (Stanford, 2022) thấy người dùng trợ lý AI viết code kém an toàn hơn trong phần lớn bài thử nhưng lại tin hơn rằng code mình an toàn, nên việc lướt rồi duyệt là có cơ sở để lo. Xem thêm bài Duyệt code do AI viết.
6. Số liệu và tài liệu đã dùng#
| Nguồn | Nói gì | Cách đọc | Lưu ý |
|---|---|---|---|
| Stack Overflow Developer Survey 2026 | 48% tin AI khi dễ kiểm chứng, 6,6% tin cho việc quan trọng, 69,9% hỏi agent khi gặp việc lạ | Người dùng cần kết quả dễ kiểm | Đọc qua bản tóm tắt, mẫu là người chịu trả lời khảo sát, hai nguồn lệch nhau về tỷ lệ coi trọng việc dẫn nguồn |
| Tài liệu Claude Code, mục đưa cho agent một phép thử | Agent dừng khi việc trông có vẻ xong, nên cho nó phép thử đạt hoặc không đạt và đòi bằng chứng | Căn cứ cho cách 2 và cách 5 | Là tài liệu của nhà sản xuất công cụ, không phải thử nghiệm đối chứng |
| Kalai và cộng sự, 9/2025 | Cách huấn luyện và chấm điểm có thể thưởng cho việc đoán | Căn cứ để xin "tôi không chắc" rõ ràng | Lập luận của tác giả, số SimpleQA do chính hãng báo cáo |
| Hướng dẫn duyệt code của Google | Thay đổi nhỏ được duyệt nhanh và kỹ hơn, mốc 100 và 1.000 dòng | Căn cứ cho cách 3 | Quy tắc kinh nghiệm cho người duyệt, không phải số cứng |
| Mata v. Avianca, 2023 | Sáu án lệ do ChatGPT bịa, phạt 5.000 USD | Nguồn phải được mở ra | Một vụ, không nói về tần suất |
| Pearce và cộng sự, 2021 | Khoảng 40% trong 1.689 chương trình Copilot có lỗ hổng | Code AI cần được kiểm | Bản Copilot năm 2021 |
| Perry và cộng sự, 2022 | Nhóm dùng trợ lý AI viết code kém an toàn hơn và tin hơn rằng code an toàn | Dễ chủ quan khi không có bằng chứng | 47 người tham gia, mô hình đời cũ |
Đọc cho đúng: các nguồn trên ủng hộ việc làm kết quả dễ kiểm. Tôi chưa tìm thấy nghiên cứu đối chứng đo trực tiếp việc đòi bằng chứng giảm bao nhiêu lỗi. Năm cách ở trên là tổng hợp thực hành.
7. Mức bằng chứng theo rủi ro#
Không cần đòi đủ năm thứ cho mọi việc. Hình dung đi chợ: mua rau thì nhìn, mua đồng hồ thì cần phiếu bảo hành.
| Mức rủi ro | Ví dụ | Bằng chứng đủ dùng |
|---|---|---|
| Thấp | Sửa chính tả, đổi tên biến cục bộ | Xem diff |
| Vừa | Sửa lỗi hiển thị, thêm hàm nhỏ | Phép thử đạt (cách 2), thay đổi nhỏ (cách 3) |
| Cao | Tiền, dữ liệu người dùng, xác thực, hạ tầng | Cả năm cách, người đọc độc lập, chạy thử trong môi trường thử |
8. Thói quen áp dụng từ ngày mai#
8.1 Tám câu hỏi trước khi nhận một kết quả#
- Kết quả này mang theo cách kiểm nào: nguồn, phép thử, hay chỉ lời nói?
- Tôi đã mở ít nhất một nguồn quan trọng chưa, và nó có nói đúng điều đó không?
- Lệnh kiểm và đầu ra có nguyên văn không, hay chỉ là lời tóm tắt?
- Bao nhiêu test đã chạy trên tổng số test có?
- Test mới do ai viết, và nó có chuyển đỏ khi tôi phá thử một dòng không?
- Thay đổi này có nhỏ đủ để tôi đọc hết không?
- Phần nào AI ghi là "chỉ đọc" hoặc "giả định", và tôi xử lý chúng thế nào?
- Tôi chạy lại được trên máy sạch chưa, hay mới tin lời AI?
8.2 Ba việc làm ngay#
- Dán khối năm dòng vào tệp hướng dẫn của công cụ bạn đang dùng.
- Chọn một việc nhỏ hôm nay, bấm giờ việc kiểm trước và sau khi đòi bằng chứng.
- Nhờ đồng nghiệp đọc một bản "đã chạy, chỉ đọc, giả định" và nói xem có dùng được không.
9. Nhìn cân bằng: bằng chứng làm được gì, chưa làm được gì#
Làm được: làm việc kiểm rẻ và nhanh hơn, buộc AI nói rõ chỗ chưa chạy, để lại dấu vết cho người khác kiểm lại, và giúp phát hiện chỗ lệch giữa yêu cầu và thay đổi.
Chưa làm được:
- Bằng chứng không phải bảo chứng đúng. Test có thể sai, nguồn có thể bịa, và một bảng đẹp có thể tạo cảm giác an toàn quá mức. Nghiên cứu của Perry và cộng sự gợi ý người dùng dễ chủ quan hơn khi có trợ lý AI.
- Đòi bằng chứng tốn thêm thời gian chạy và viết, nên với việc rủi ro thấp là quá mức.
- Tôi chưa thấy thử nghiệm đối chứng đo riêng hiệu quả của từng cách. Hãy tự đo trong nhóm bạn.
- Một AI khác đọc lại có thể mắc cùng kiểu lỗi. Với việc quan trọng, cần một người đọc.
Đừng thổi phồng: đây không phải công thức làm AI hết sai. Đừng coi nhẹ: chi phí của việc nhận "đã xong" mà không có gì để kiểm thường nằm ở cuối, khi lỗi đã tới tay khách.
10. Kết luận#
Câu "đã xong" của AI nghe như câu trả lời, nhưng thực ra là lời hứa. Bằng chứng biến lời hứa thành thứ bạn kiểm được: nguồn mở được, phép thử chạy được, thay đổi nhỏ, ba nhóm đã chạy, chỉ đọc, giả định, và một lệnh để chạy lại. Hãy đặt các yêu cầu này vào chính câu lệnh đưa cho AI, và luôn là người mở bằng chứng ra.
Nguồn tham khảo#
Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số con số được thuật lại khác nhau, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.
- Stack Overflow, 2026 Developer Survey (đọc qua bản tóm tắt, chưa đối chiếu từng bảng)
- Anthropic, Best practices for Claude Code (mục Give Claude a check to run)
- Kalai, Nachum, Vempala, Zhang, Why Language Models Hallucinate (9/2025) và bài đăng của OpenAI
- Google Engineering Practices, Small CLs
- Mata v. Avianca, Inc.: Wikipedia và LawNext về lệnh phạt
- Pearce và cộng sự, Asleep at the Keyboard? (2021) và Perry và cộng sự, Do Users Write More Insecure Code with AI Assistants? (Stanford, 2022)
Câu hỏi thường gặp
- Vì sao không chỉ cần đọc kỹ kết quả của AI?
- Đọc kỹ là cách kiểm tốn thời gian nhất vì bạn phải tự dựng lại lập luận từ đầu. Khi AI nộp kèm bằng chứng cụ thể như đường dẫn, lệnh đã chạy và đầu ra nguyên văn, bạn chỉ cần nhìn vào một thứ có thể mở ra. Tài liệu của Claude Code cũng nói rằng nếu agent không có gì để chạy thì 'trông có vẻ xong' là tất cả nó có, và khi đó chính bạn trở thành bộ kiểm thử.
- Đòi bằng chứng có làm kết quả AI đúng hơn không?
- Chưa có thử nghiệm đối chứng nào tôi tìm thấy đo riêng việc đòi bằng chứng làm giảm bao nhiêu lỗi. Điều có cơ sở hơn là bằng chứng làm việc kiểm tra rẻ hơn và nhanh hơn. Bằng chứng giả hoặc test sai vẫn có thể lọt qua, nên bài nêu cách bắt từng loại.
- Khi nào không cần đòi bằng chứng?
- Việc rủi ro thấp và dễ nhìn bằng mắt, như sửa chính tả hay đổi tên biến cục bộ, chỉ cần xem diff. Việc chạm vào tiền, dữ liệu người dùng, xác thực hay hạ tầng nên đòi mức bằng chứng cao hơn: phép thử, người đọc độc lập và chạy thử trong môi trường thử.
- AI có bịa cả bằng chứng không?
- Có thể. Vụ Mata v. Avianca năm 2023 có những án lệ do ChatGPT bịa kèm lời trích đầy đủ. Vì vậy mỗi bằng chứng phải mở ra được: mở đường dẫn, chạy lại lệnh, và xem nội dung có đúng là điều AI nói không.
- Nên đặt các câu đòi bằng chứng ở đâu?
- Với việc lặp lại, đặt thành một khối ngắn trong AGENTS.md hoặc tệp hướng dẫn của công cụ để mọi phiên làm việc đều đọc. Với việc một lần, dán vào cuối yêu cầu. Giữ khối này dưới khoảng sáu dòng để người và AI đều đọc hết.