Bịa chi tiết
hallucinationThông tin cụ thể, nghe hợp lý, nhưng không có thật.
Tên menu, endpoint API, số điều khoản, link tài liệu không tồn tại.
Độ khó phát hiện
Mục lục
01 · Nền tảng
Vì sao phải kiểm
Verify không có nghĩa là nghi ngờ mọi thứ AI viết. Verify là biết lỗi hay nằm ở đâu, rồi kiểm đúng những chỗ đó bằng một nguồn nằm ngoài AI.
Giọng chắc chắn không đi kèm độ chính xác
AI tạo ra câu trả lời nghe hợp lý nhất. Nó không tự biết lúc nào mình sai, nên câu sai và câu đúng được viết bằng cùng một giọng tự tin.
Lỗi rơi vào chỗ đắt nhất
Con số, ngày, tên riêng, điều kiện, cam kết. Đây cũng chính là những thứ khách đọc kỹ nhất và dùng để ra quyết định.
Gửi đi rồi thì nó mang tên bạn
Khách không phân biệt "AI viết" với "PM viết". Một biên bản sai do AI vẫn là biên bản sai của dự án.
Chỗ AI dễ sai, theo kinh nghiệm dùng thực tế
Soi kỹ
Con số và phép tính
Tên menu, endpoint, phiên bản, giá
Trích dẫn, link, số điều khoản
Điều kiện, ngoại lệ, phủ định
Ai làm gì, trước khi nào
Thông tin mới, thông tin nội bộ công ty
Phần giữa và cuối tài liệu dài
Đọc lại
Tóm tắt khi bạn có bản gốc trước mặt
Giải thích khái niệm phổ biến
Dàn ý tài liệu
Lướt là đủ
Viết lại văn phong
Định dạng, bố cục
Brainstorm ý tưởng (bạn là người chọn)
02 · Điều kiện
Ai đủ sức kiểm
Mọi kỹ thuật ở các phần sau chỉ có tác dụng khi người dùng nó hiểu việc đang được kiểm. Thang Bloom bản sửa năm 2001 giúp nói rõ phải hiểu tới mức nào thì mới đủ.
- Sáng tạo 6
Tạo ra cách làm mới. Thiết kế lại quy trình Q&A với khách.
- Người verify phải đứng được ở bậc nàyĐánh giá 5
Nói được một kết quả đúng hay sai, và chỉ ra căn cứ. Biết estimate 20 man-day cho một API là hợp lý hay không; biết bản dịch có làm đổi requirement không.
- Phân tích 4
Tách một việc thành các phần để thấy phần nào gây ra vấn đề. Tách change request thành các màn hình, API, test case bị ảnh hưởng.
- Áp dụng 3
Làm theo quy tắc có sẵn. Viết test case theo template dự án; dịch theo bảng thuật ngữ.
- Hiểu 2
Giải thích lại bằng lời của mình. Kể lại cho team vì sao khách muốn đổi luồng đăng ký.
- Nhớ 1
Nhắc lại một thông tin. Nhớ ngày release, tên các màn hình trong spec.
Nguyên tắc
Trước khi giao một việc cho AI, tự hỏi: nếu kết quả sai, mình có chỉ ra được sai ở đâu và vì sao không? Trả lời được thì bạn đang đứng ở bậc Đánh giá. Chưa trả lời được thì chưa nên là người đóng dấu 確認.
Dịch spec là việc AI làm khá tốt. Câu cần hỏi không phải AI dịch giỏi tới đâu, mà là bạn có nhận ra khi một điều kiện nghiệp vụ bị dịch lệch hay không. Khả năng đó đến từ hiểu nghiệp vụ, không đến từ vốn tiếng Nhật.Kể lại được chưa có nghĩa là đã kiểm. Bạn có thể tóm tắt lại email của khách cho team rất mạch lạc mà vẫn không biết bản tóm tắt đã đánh rơi chữ 保留. Bậc Hiểu giúp bạn nói lại; chỉ bậc Đánh giá mới cho bạn quyền nói "đúng rồi".
Thang này đo người ký, không đo AI. AI có thể sai ở việc đơn giản nhất, như bịa ra một tên màn hình không có trong spec. Ngược lại, khi có đủ dữ liệu và tiêu chí, nó có thể góp ý estimate khá sắc. Vì vậy đừng dùng thang để hỏi "việc này AI làm được không", mà để hỏi "ai trong team đủ sức ký việc này".
Output bám nguồn
"Có khớp với nguồn không?"
- Ví dụ
- Tóm tắt email, biên bản họp, bản dịch, trích số liệu từ file.
- Cách kiểm
- Đối chiếu từng claim với nguồn gốc, rồi đọc ngược để tìm phần bị bỏ sót.
- Bạn cần
- Đọc hiểu được nguồn. Với email tiếng Nhật, cần đủ tiếng Nhật và đủ hiểu bối cảnh dự án.
Output phán đoán
"Có đúng với cách việc này thật sự vận hành không?"
- Ví dụ
- Nhận xét estimate, đề xuất phương án, đánh giá rủi ro, câu trả lời kiểu "có nên…".
- Cách kiểm
- Không có tài liệu nào để Ctrl+F. Bạn phải biết cơ chế thật: hệ thống, team, khách, nghiệp vụ, và tiêu chí để xét.
- Bạn cần
- Tự xét được việc đó ở bậc Đánh giá, hoặc có người trong team xét được.
Nhiều output thật có cả hai phần. Biên bản họp là output bám nguồn, nhưng dòng "rủi ro: thấp" AI tự thêm vào cuối biên bản là output phán đoán.
Khi bạn chưa đủ sức ký
Học thêm tới khi đủ
Đọc lại spec, hỏi dev đang làm phần đó, mở môi trường test xem tận mắt. Ghi điều vừa học vào ghi chú dự án để lần sau không phải hỏi lại.
Mượn mắt người khác
- Estimate, kiến trúc: tech lead
- Phạm vi test: QA
- Quy tắc nghiệp vụ: phía khách hoặc người nắm nghiệp vụ
- Kính ngữ, sắc thái tiếng Nhật: BrSE lâu năm
Nói rõ chỗ chưa kiểm
"Phần effort tích hợp với hệ thống cũ tôi chưa kiểm được. Đã gửi anh Nam xem, hẹn trả lời thứ Năm."
Không làm: hỏi lại chính AI xem nó đúng chưa, rồi coi câu trả lời ấy là đã có người kiểm.
Thang Bloom ở đây là bản sửa của Anderson & Krathwohl (2001), A Taxonomy for Learning, Teaching, and Assessing. Muốn đi sâu hơn chuyện chia việc giữa người và AI, có thể xem khóa Làm chủ tư duy AI trên 200Lab.
03 · Nhận diện
8 kiểu AI hay sai
Biết tên lỗi thì dễ thấy lỗi hơn. Mỗi tình huống ở phần 07 đều gắn với một hoặc hai kiểu dưới đây.
Bỏ sót
omissionÝ chính còn, nhưng điều kiện, ngoại lệ hay việc đang chờ thì mất.
Email nói "đồng ý, ngoại trừ màn hình tìm kiếm"; bản tóm tắt chỉ còn "đồng ý".
Độ khó phát hiện
Nâng mức chắc chắn
overstatement"Có thể" thành "sẽ", "đang cân nhắc" thành "đã quyết", "đề xuất" thành "đồng ý".
Khách nói cần hỏi sếp; biên bản ghi "khách đồng ý lùi deadline".
Độ khó phát hiện
Tự điền chỗ trống
gap fillingĐầu vào mơ hồ thì AI chọn giúp bạn một cách hiểu, và không báo là nó đã chọn.
Câu tiếng Nhật lược chủ ngữ; AI đoán ai là người làm và đoán ngược.
Độ khó phát hiện
Sai số học, sai logic
arithmeticCộng sai, chia sai, đếm sai ngày làm việc, đổi đơn vị nhầm.
Bảng effort có tổng 70 man-day trong khi các dòng cộng lại là 78.
Độ khó phát hiện
Chiều theo câu hỏi
sycophancyCâu hỏi dẫn dắt thì nhận câu trả lời đồng tình. Bạn phản bác thì AI dễ đổi ý dù nó đúng.
"Kế hoạch này ổn đúng không?" và AI khen một kế hoạch thiếu rollback.
Độ khó phát hiện
Báo cáo đẹp hơn thực tế
agent overclaimAgent báo "đã xong", "đã nhất quán", trong khi bỏ bước, làm khác yêu cầu, hoặc làm thừa.
"Đã cập nhật 5 file", nhưng một file chỉ đổi ngày ở trang bìa.
Độ khó phát hiện
Dùng context cũ hoặc thiếu
stale contextAI dựa vào spec bản cũ dán từ đầu cuộc chat, hoặc kiến thức đã lỗi thời so với thời điểm hiện tại.
Trả lời theo spec v2.0 trong khi khách đã gửi v2.1 hôm qua.
Độ khó phát hiện
Độ khó phát hiện là đánh giá của sổ tay này, dựa trên một câu hỏi: lỗi có để lại dấu vết trên output không. Bỏ sót và tự điền gần như không để lại dấu vết nào, nên phải đọc từ nguồn gốc mới thấy.
04 · Định mức
Kiểm bao nhiêu là đủ
Kiểm mọi thứ ở mức cao nhất thì sẽ mệt rồi bỏ kiểm luôn. Hãy đặt mức kiểm theo hai câu hỏi: AI có dễ sai ở loại việc này không, và nếu sai thì hậu quả lớn cỡ nào.
Hậu quả nếu sai →
Hậu quả cao · AI ít saiMức 2
- Chỉnh câu chữ email gửi khách (kiểm ý không bị đổi)
- Định dạng lại tài liệu nộp khách
Hậu quả cao · AI dễ saiMức 3
- Estimate, báo giá, lịch gửi khách
- Biên bản họp có quyết định và cam kết
- Dịch spec, dịch email có điều kiện
- Agent sửa tài liệu hoặc dữ liệu thật
Hậu quả thấp · AI ít saiMức 1
- Viết lại tin nhắn Slack nội bộ
- Brainstorm tên sprint, ý tưởng retro
Hậu quả thấp · AI dễ saiMức 2
- Tóm tắt tài liệu dài để tự đọc
- Hỏi về một tool hay khái niệm mới
Khả năng AI sai ở loại việc này →
Mức 1 · Đọc lại
Đọc hết một lượt bằng con mắt của người nhận. Có chỗ nào lạ, sai giọng, sai tên không.
Mức 2 · Đối chiếu
Mọi claim quan trọng đều tìm được chỗ đứng trong nguồn gốc. Đọc ngược nguồn gốc để tìm phần bị bỏ sót.
Mức 3 · Kiểm độc lập
Đối chiếu, cộng thêm một cách kiểm khác: tính lại bằng Excel, chạy thử, nhờ người thứ hai, hoặc người có thẩm quyền xác nhận.
Không chắc nên chọn mức nào thì chọn mức cao hơn một bậc.
05 · Quy trình
Quy trình 5 bước
Dùng cho mọi output ở mức 2 và 3. Ví dụ đi kèm là một biên bản họp do AI viết từ bản ghi âm.
Trước bước 1Tôi có đủ hiểu việc này để biết output sai ở đâu không?
CóBắt đầu từ bước 1.
hoặc
ChưaTìm hiểu thêm, hoặc chuyển phần đó cho người đủ hiểu (phần 02). Vẫn đi qua 5 bước với phần mình kiểm được.
-
Định mức rủi ro
"Nếu chỗ này sai, ai bị ảnh hưởng? Sửa lại có dễ không?"
Chọn mức 1, 2 hoặc 3 theo bảng ở phần trên. Bước này quyết định bạn bỏ bao nhiêu công sức cho các bước sau.
Biên bản họp: sẽ gửi khách và có quyết định về deadline, nên là mức 3. -
Tách ra từng claim
"Câu nào trong đây có thể đúng hoặc sai?"
Gạch chân những gì kiểm được: con số, ngày, tên riêng, ai làm gì, cam kết, điều kiện. Câu chung chung như "hai bên trao đổi tích cực" không cần kiểm. Claim mới là chỗ cần kiểm.
Biên bản họp: tách được 6 claim, gồm 2 quyết định, 2 việc cần làm có hạn, 1 câu trả lời Q&A, 1 mốc giữ nguyên. -
Đối chiếu với nguồn sự thật
"Claim này nằm ở đâu trong bản gốc?"
Mỗi claim phải tìm được chỗ đứng trong một nguồn nằm ngoài AI: email gốc, bản ghi âm, spec bản mới nhất, file Excel, docs chính thức, người có thẩm quyền. Không tìm được nguồn thì claim đó chưa được kiểm, dù nghe hợp lý đến đâu.
Biên bản họp: mở bản ghi, tìm đúng đoạn khách nói về deadline. Khách nói "cần xin ý kiến trưởng phòng", không phải "đồng ý". -
Đọc ngược để tìm phần thiếu
"Bản gốc có gì mà output không nhắc tới?"
Lần này đi từ nguồn gốc sang output. Soi kỹ điều kiện, ngoại lệ, việc đang chờ, rủi ro được nêu ra. Bước 3 bắt được cái sai; lỗi bỏ sót chỉ lộ ra ở bước này.
Biên bản họp: khách dặn "màn hình báo cáo chưa chốt, đừng làm vội", nhưng biên bản không có dòng nào về việc này. -
Ghi dòng verify khi gửi đi
"Người nhận nên tin output này đến mức nào?"
Thêm một dòng ngắn: đã đối chiếu gì với đâu, chưa kiểm gì, ai cần xác nhận. Người nhận biết chỗ nào chắc chắn, chỗ nào còn treo, và bạn có bằng chứng mình đã làm bước kiểm.
Verify: Đã đối chiếu 6 mục với bản ghi họp 20/10. Mục deadline chưa chốt, chờ khách trả lời thứ Hai 27/10. Chưa kiểm: phần Q&A số 15–18, Minh gửi bổ sung.
06 · Kỹ thuật
Hộp đồ nghề
Tám kỹ thuật, kèm prompt mẫu copy được. Prompt giúp AI để lộ chỗ yếu, nhưng không cho bạn năng lực Đánh giá. Chúng chỉ ra chỗ đáng nghi; người hiểu việc mới kết luận được.
Bắt AI trích câu gốc
Dùng khi: tóm tắt, biên bản, trả lời dựa trên tài liệu.
Với mỗi ý trong câu trả lời, trích nguyên văn câu trong tài liệu gốc làm căn cứ. Ý nào không có câu gốc, ghi rõ: KHÔNG CÓ CĂN CỨ.
AI có thể trích sai. Dùng Ctrl+F tìm câu trích trong bản gốc; không tìm thấy thì coi như không có căn cứ.
Bắt AI khai giả định
Dùng khi: estimate, kế hoạch, phân tích, đề xuất.
Liệt kê các giả định bạn đã dùng để ra kết quả này và những thông tin bạn còn thiếu. Đánh dấu giả định nào gây ảnh hưởng lớn nhất nếu sai.
Giả định sai thường nằm ở thứ AI không biết về dự án: quy mô team, ngày lễ, phụ thuộc giữa các việc.
Reviewer ở phiên chat mới
Dùng khi: tài liệu quan trọng mà bạn đã đọc nhiều lần đến mức quen mắt.
Bạn là reviewer. Dưới đây là TÀI LIỆU GỐC và BẢN TÓM TẮT. Chỉ dựa vào tài liệu gốc, liệt kê: 1. Chỗ bản tóm tắt nói khác tài liệu gốc. 2. Chỗ bản tóm tắt nói thêm điều tài liệu gốc không có. 3. Điều quan trọng trong tài liệu gốc bị bỏ sót. Mỗi mục kèm câu gốc làm căn cứ.
Mở chat mới để reviewer không bị cuộc trò chuyện cũ dẫn dắt. Reviewer AI giúp khoanh vùng chỗ nghi ngờ; kết luận vẫn phải qua đối chiếu của bạn.
Dịch ngược
Dùng khi: dịch spec, email có điều kiện, tài liệu hợp đồng.
Dịch đoạn tiếng Nhật sau sang tiếng Việt, sát nghĩa từng câu, không diễn ý. Đánh dấu những câu lược chủ ngữ mà bạn phải đoán ai là người thực hiện.
Làm ở phiên mới, không đưa câu gốc tiếng Việt. Dịch ngược bắt được nghĩa bị đổi, không bắt được sắc thái lịch sự; sắc thái cần BrSE đọc.
Tính lại bằng công cụ khác
Dùng khi: tổng, phần trăm, số ngày làm việc, đổi đơn vị, quy đổi tiền.
Dán bảng vào Excel hoặc Google Sheets, dùng SUM, NETWORKDAYS. Không nhờ AI kiểm lại phép tính của chính nó.
Nhanh nhất trong tám kỹ thuật và bắt được loại lỗi dễ làm mất uy tín nhất trước khách.
Kiểm mẫu ngẫu nhiên
Dùng khi: danh sách dài: 50 test case, 200 dòng dịch, 40 ticket.
Chọn ngẫu nhiên 5 mục rải đều từ đầu đến cuối, kiểm từng mục ở mức 3. Gặp 1 lỗi thì kiểm toàn bộ danh sách.
Đừng chỉ kiểm vài mục đầu. Với tài liệu dài, AI hay xử lý kém phần giữa và phần cuối.
Hỏi để tìm lỗi
Dùng khi: xin feedback cho kế hoạch, thiết kế, tài liệu đề xuất.
Đóng vai [khách hàng khó tính / QA lead / người vận hành hệ thống]. Tìm 5 vấn đề lớn nhất của tài liệu dưới đây, xếp theo mức nghiêm trọng, mỗi vấn đề kèm lý do và căn cứ trong tài liệu. Không khen.
AI phản biện cũng có thể nêu vấn đề không có thật, và chỉ người hiểu việc mới phân biệt được. Không đủ hiểu thì đưa danh sách đó cho người đủ hiểu xét.
Cho AI quyền nói "không biết"
Dùng khi: ngay từ đầu, để phòng lỗi bịa.
Chỉ trả lời dựa trên tài liệu tôi đưa. Nếu tài liệu không có thông tin, trả lời "Tài liệu không đề cập" thay vì suy đoán. Nếu phải suy luận, ghi rõ "Suy luận:" ở đầu câu.
Cách này làm giảm lỗi bịa, không loại bỏ được nó. Vẫn cần kiểm.
07 · Use-case
9 tình huống thường gặp
Mỗi tình huống gồm output của AI, lỗi nằm ở đâu, cách bắt lỗi và bài học. Khi luyện, hãy che cột bên phải và tự tìm lỗi trước.
PM · AI Chat
Estimate trước khi gửi khách
Sai số học · Tự điền chỗ trốngChị Lan nhờ AI lập bảng effort cho tính năng đặt lịch hẹn và ước thời gian hoàn thành, để gửi khách trong chiều nay.
AI trả về
| Hạng mục | Man-day |
|---|---|
| Thiết kế màn hình | 12 |
| API đặt lịch | 20 |
| Tích hợp thanh toán | 18 |
| Test | 16 |
| Hỗ trợ UAT | 8 |
| Deploy | 4 |
| Tổng | 70 |
"Với team 4 người, dự kiến hoàn thành trong 3 tuần."
Lỗi nằm ở đâu
Các dòng cộng lại là 78 man-day, không phải 70. 78 chia cho 4 người là 19,5 ngày làm việc, tức gần 4 tuần chứ không phải 3. Phép chia đó còn ngầm cho rằng 4 người làm song song từ ngày đầu, trong khi test chỉ bắt đầu được khi đã có code.
Cách bắt
- Dán bảng vào Excel, dùng SUM. Mất chưa tới một phút.
- Tự xếp lịch theo thứ tự phụ thuộc, trừ ngày lễ của cả phía Việt Nam lẫn phía Nhật.
- Hỏi AI: "Liệt kê các giả định đằng sau con số 3 tuần."
Bài họcKhông nhờ AI tính lại phép tính của chính nó. Số liệu gửi khách phải đi qua một công cụ khác.
PM · AI Chat
Nhờ AI nhận xét estimate của team
Output phán đoán · Tự điền chỗ trốngTech lead gửi estimate, trong đó API đặt lịch là 20 man-day. Khách muốn giảm chi phí, nên PM dán estimate vào và hỏi AI: "Estimate này có chỗ nào cắt được không?"
AI trả về
"Hạng mục API đặt lịch 20 man-day là cao so với một API CRUD thông thường. Có thể giảm còn khoảng 10–12 man-day nếu dùng thư viện có sẵn."
Lỗi nằm ở đâu
AI so với "một API CRUD thông thường" vì trong prompt chỉ có tên hạng mục và con số 20 man-day. Thực tế API phải đồng bộ lịch hai chiều với hệ thống đặt chỗ cũ của khách, vốn chỉ nhận file CSV theo lô mỗi 15 phút. Phần lớn 20 man-day nằm ở đó. Không có tài liệu nào để đối chiếu câu "cao so với thông thường". Chỉ người hiểu hệ thống mới biết nó sai.
Cách bắt
- Nhận ra đây là output phán đoán, nên đối chiếu tài liệu không giúp được.
- Trước khi đưa con số nào cho khách, hỏi tech lead: "20 man-day này chủ yếu nằm ở đâu?"
- Muốn AI giúp thì đưa cơ chế vào trước: mô tả hệ thống cũ và ràng buộc tích hợp, rồi mới hỏi phương án giảm effort. Tech lead là người xét phương án.
Bài họcOutput phán đoán được kiểm bằng hiểu biết về cơ chế. Mình không đủ hiểu thì chuyển cho người đủ hiểu.
PM · AI Chat
Hỏi về tính năng của tool khách đang dùng
Bịa chi tiếtKhách hỏi hệ thống quản lý nội bộ của họ (gọi là Tool X) có xuất báo cáo tự động mỗi tuần được không. PM hỏi AI để trả lời cho nhanh.
AI trả về
"Có. Vào Settings → Automation → Scheduled Export, chọn tần suất Weekly. Nếu cần tích hợp với hệ thống khác, dùng endpoint /api/v2/reports/schedule."
Lỗi nằm ở đâu
Câu trả lời cụ thể đến tên menu và endpoint, nghe như của người đã từng dùng. Mở docs chính thức thì không có menu Scheduled Export, và API v2 không có endpoint đó. AI đã ghép từ những tool tương tự.
Cách bắt
- Với tên riêng (menu, endpoint, phiên bản, giá, điều khoản), tìm đúng chuỗi đó trong docs chính thức hoặc release note.
- Docs không nói rõ thì nhờ dev hoặc khách thử trên môi trường thật.
- Trả lời khách "bên em đang xác nhận, thứ Năm sẽ phản hồi" vẫn tốt hơn một câu trả lời sai.
Bài họcCâu trả lời càng cụ thể càng phải kiểm. Mức chi tiết không chứng minh được độ chính xác.
PM · AI Chat
Hỏi xin sự đồng ý
Chiều theo câu hỏiTrước buổi họp release, PM dán kế hoạch vào và hỏi: "Kế hoạch release dưới đây ổn rồi đúng không?"
AI trả về
"Kế hoạch rất hợp lý và chi tiết. Các mốc thời gian rõ ràng, phân công cụ thể. Bạn có thể tự tin trình bày."
Lỗi nằm ở đâu
Câu hỏi đã gợi sẵn câu trả lời. AI có xu hướng đồng tình với người hỏi, nên lời khen này gần như không mang thông tin. Kế hoạch thực ra không có bước rollback và đặt giờ deploy vào chiều thứ Sáu.
Cách bắt
- Hỏi trung lập và giao vai phản biện: "Đóng vai QA lead khó tính. Liệt kê 5 rủi ro lớn nhất của kế hoạch này, xếp theo mức nghiêm trọng. Không khen."
- Tự đánh giá từng rủi ro AI nêu ra, vì AI phản biện cũng có thể nêu rủi ro không có thật.
Bài họcCách hỏi quyết định câu trả lời. Muốn tìm lỗi thì phải hỏi để tìm lỗi.
BrSE · AI Chat
Tóm tắt email tiếng Nhật
Bỏ sót
Email gốc của khách
先日ご相談した画面レイアウトの変更について、社内で確認いたしました。基本的には御社の案で進めていただいて問題ございません。ただし、検索画面については既存ユーザーへの影響を確認したいため、一旦保留とさせてください。来週水曜日までにご回答いたします。
AI tóm tắt
"Khách đồng ý toàn bộ phương án layout mới. Team có thể bắt đầu làm ngay."
Lỗi nằm ở đâu
Câu bắt đầu bằng ただし bị bỏ. Màn hình tìm kiếm đang 保留 vì khách muốn xem ảnh hưởng tới người dùng hiện tại, và khách hẹn trả lời trước thứ Tư tuần sau. Nếu team làm luôn màn hình này, có thể phải làm lại.
Cách bắt
- Quét email gốc tìm các từ báo điều kiện và ngoại lệ: ただし、なお、〜場合、一旦、保留、〜次第.
- Prompt: "Liệt kê mọi điều kiện, ngoại lệ và việc đang chờ trong email, mỗi ý kèm câu gốc tiếng Nhật."
Bài họcBản tóm tắt hay giữ ý chính và đánh rơi ngoại lệ, mà ngoại lệ thường là thứ đắt nhất.
BrSE · AI Chat
Dịch spec sang tiếng Nhật
Bỏ sót
Câu gốc trong spec
"Hệ thống chỉ gửi email thông báo khi đơn hàng bị hủy."
AI dịch
注文がキャンセルされた場合、システムは通知メールを送信します。
Lỗi nằm ở đâu
Mất chữ "chỉ". Bản dịch đúng ngữ pháp nhưng không loại trừ các trường hợp khác, nên dev phía Nhật có thể giữ nguyên email cho các trạng thái khác. Bản đúng: 通知メールを送信するのは、注文がキャンセルされた場合のみです。
Cách bắt
- Dịch ngược ở phiên chat mới, không đưa câu gốc, rồi so nghĩa.
- Soi riêng từ giới hạn và phủ định: chỉ, tất cả, không bao giờ, ít nhất, tối đa, trừ khi.
Bài họcTrong spec, mất một từ giới hạn là đổi một requirement.
BrSE · AI Chat
Ai làm việc gì?
Tự điền chỗ trống
Tin nhắn của khách
テスト環境の準備ができ次第、ご連絡いただけますと幸いです。
AI dịch
"Chúng tôi sẽ liên lạc khi môi trường test sẵn sàng."
Lỗi nằm ở đâu
いただけます cho biết người nhận tin nhắn, tức team mình, là người làm việc đó. Nghĩa đúng: "Khi bên anh chuẩn bị xong môi trường test, nhờ anh báo cho chúng tôi." AI đảo chiều hành động, và kết quả là team ngồi chờ khách trong khi khách ngồi chờ team.
Cách bắt
- Với mỗi việc cần làm, tự hỏi: ai làm, cho ai, trước khi nào.
- Prompt: "Với mỗi câu, ghi rõ ai thực hiện hành động và căn cứ ngữ pháp (いただく、くださる、させていただく...)." BrSE kiểm lại từng căn cứ.
Bài họcKhi câu gốc lược chủ ngữ, AI sẽ tự điền. Chỗ AI tự điền là chỗ phải kiểm.
PM / BrSE · AI Agent
Agent cập nhật spec theo change request
Báo cáo đẹp hơn thực tếGiao cho agent: "Cập nhật bộ tài liệu spec theo CR-12 (thêm trường Mã giới thiệu vào màn hình đăng ký) và đồng bộ bảng test case."
Agent báo cáo
"Đã cập nhật 5 file theo CR-12. Các tài liệu đã nhất quán."
Thực tế khi xem diff
| File | Thay đổi | |
|---|---|---|
| 01_画面設計.xlsx | Thêm trường đúng vị trí | Đúng |
| 02_項目定義.xlsx | Thêm trường, đúng độ dài | Đúng |
| 03_API仕様.md | Thêm tham số request | Đúng |
| 04_テストケース.xlsx | Chỉ đổi ngày ở trang bìa, không có test case mới | Chưa làm |
| 05_用語集.md | Đổi toàn bộ 会員 thành ユーザー | Ngoài phạm vi |
Cách bắt
- Xem diff hoặc lịch sử version của từng file, đối chiếu với từng mục của CR.
- Yêu cầu agent báo cáo dạng bảng có vị trí và đoạn trước/sau (prompt ở phần 08).
- Thay đổi ngoài phạm vi: hoàn tác, hoặc hỏi người phụ trách trước khi giữ lại.
Bài họcBáo cáo của agent cũng là output của AI. Hãy kiểm kết quả, đừng kiểm lời kể.
PM · AI Agent
Agent phân tích bug list
Dùng context thiếu · Tự điền chỗ trốngĐưa agent file Excel bug list gồm hai sheet, tháng 9 và tháng 10, khoảng 1.200 dòng, và nhờ tổng hợp tình hình chất lượng để báo cáo khách.
Agent trả về
"Có 37 bug Critical, 62% nằm ở module Payment. Đề xuất ưu tiên Payment trong sprint tới."
Lỗi nằm ở đâu
Agent chỉ đọc sheet đầu tiên, tức tháng 9. Agent còn đếm "Critical" theo cột Priority, trong khi team đánh giá mức nghiêm trọng bằng cột Severity. Con số nghe rất chính xác nhưng trả lời một câu hỏi khác.
Cách bắt
- Hỏi trước khi tin: "Bạn đã đọc những sheet nào, bao nhiêu dòng, đếm theo cột nào?"
- Tự lọc lại một con số bằng filter của Excel. Khớp thì mới dùng tiếp các con số còn lại.
- Lần sau, ghi rõ định nghĩa ngay trong yêu cầu: "Critical là Severity = S1."
Bài họcMột con số do agent đưa ra cần đi kèm cách nó được đếm.
08 · AI Agent
Kiểm AI Agent ở ba thời điểm
AI Chat đưa bạn một đoạn văn để đọc. AI Agent tự làm nhiều bước và thay đổi file, dữ liệu, ticket thật. Vì vậy việc kiểm bắt đầu từ trước khi giao việc, chứ không đợi tới lúc agent báo xong.
Trước khi giao scope
- Viết rõ phạm vi: được sửa gì, không được đụng vào gì.
- Viết tiêu chí "xong" mà người khác kiểm được. Ví dụ: mỗi mục của CR-12 có thay đổi tương ứng trong spec và ít nhất một test case.
- Cho agent làm trên bản sao hoặc nhánh riêng khi có thể; chỉ cấp quyền vừa đủ.
- Yêu cầu báo cáo kèm bằng chứng (prompt bên dưới).
Trong khi chạy checkpoint
- Cho làm thử một mục trước, kiểm mục đó, rồi mới cho làm hàng loạt.
- Khi agent xin quyền, đọc hành động nó định làm trước khi bấm cho phép.
- Hành động xóa, ghi đè, hoặc gửi ra ngoài (email, chat với khách): dừng lại và hỏi người phụ trách.
Sau khi xong evidence
- So kết quả với tiêu chí "xong", từng mục một.
- Mở file thật, xem diff hoặc lịch sử version.
- Tìm thay đổi ngoài phạm vi.
- Tự tính lại ít nhất một con số agent đưa ra.
Lời kể
"Đã xong. Mọi thứ đã nhất quán."
- Không nói đã làm ở đâu
- Không nói chưa làm được gì
- Không cách nào kiểm lại
Bằng chứng
Bảng từng việc, có vị trí và đoạn trước/sau
- Mỗi việc chỉ được tới đúng file và vị trí
- Việc chưa làm được ghi riêng, có lý do
- Thay đổi ngoài phạm vi được khai ra
Phạm vi: chỉ sửa [danh sách file/thư mục]. Không sửa file khác. Không xóa, không gửi gì ra ngoài. Xong khi: [tiêu chí kiểm được]. Làm thử 1 mục trước và dừng lại để tôi kiểm. Khi xong, báo cáo bằng bảng gồm các cột: Việc được giao | Đã làm gì | File và vị trí | Bằng chứng (đoạn trước/sau hoặc kết quả chạy) Thêm hai mục riêng: - Việc chưa làm được và lý do - Thay đổi ngoài phạm vi (nếu có)
09 · Tránh
Bẫy thường gặp
Những cách "kiểm" cho cảm giác đã kiểm nhưng không bắt được lỗi.
✕
Hỏi lại "Bạn chắc chưa?"
AI có thể khẳng định lại, hoặc đổi ý cho vừa lòng bạn. Cả hai đều không phải bằng chứng. Bằng chứng nằm ở nguồn gốc.
✕
Thấy có link là tin
Link có thể không tồn tại, hoặc tồn tại nhưng không nói điều AI viết. Mở link và tìm đúng đoạn.
✕
Duyệt cả phần mình không đánh giá được
Phần bạn không đủ hiểu để biết sai mới là phần dễ lọt lỗi nhất. Tách riêng phần đó và chuyển cho người đứng được ở bậc Đánh giá.
✕
Đọc báo cáo thay vì kết quả
Với agent, mở file, diff, dữ liệu thật. Bản tóm tắt do agent tự viết về chính việc nó làm cũng cần kiểm.
✕
Bảo AI "sửa đi" rồi gửi luôn
Bản sửa có thể tạo lỗi mới ở chỗ trước đó đã đúng. Sau mỗi lần sửa, kiểm lại các claim quan trọng.
✕
Gửi đi không nói đã kiểm tới đâu
Người nhận sẽ tưởng mọi thứ đã được kiểm. Thêm dòng verify để họ biết chỗ nào còn treo.
10 · Thực hành
Bài luyện: soát biên bản họp
Bên trái là ghi chép lời thoại. Bên phải là biên bản AI viết từ ghi chép đó. Với mỗi dòng biên bản, chọn "Khớp" hoặc "Sai lệch" rồi xem giải thích.
Ghi chép họp 20/10 · lời thoại đã dịch sang tiếng Việt
Anh Tanaka (khách)Về việc lùi deadline sang 15/11, tôi cần xin ý kiến trưởng phòng. Chắc thứ Hai tuần sau mới trả lời được.
Chị Lan (PM)Vâng. Trong lúc chờ, bên em vẫn giữ mốc 31/10 cho phần đăng nhập.
Anh TanakaPhần thanh toán thì cứ làm theo spec v2.1. Màn hình báo cáo thì chưa chốt, đừng làm vội.
Minh (BrSE)Em sẽ gửi lại danh sách Q&A cho anh trước thứ Năm.
Anh TanakaĐược. Câu Q&A số 14 về phân quyền thì tôi trả lời luôn: chỉ Admin được xóa dữ liệu.
Biên bản do AI viết
11 · Mang theo
Checklist bỏ túi
Chạy qua danh sách này trước khi gửi bất kỳ output nào của AI ra khỏi tay mình. Trang tự nhớ các ô bạn đã đánh dấu trên trình duyệt này.
Trước khi gửi送信前チェック
0/9 mụcMục nào chưa đánh dấu được thì ghi vào dòng verify.
Trôi chảy không phải là bằng chứng.Câu sai và câu đúng được viết bằng cùng một giọng tự tin.
Nguồn sự thật nằm ngoài AI.Email gốc, bản ghi, spec mới nhất, Excel, docs chính thức, và người hiểu cơ chế thật của việc đó.
Kiểm theo rủi ro, ghi lại đã kiểm gì.Kiểm vừa đủ thì mới duy trì được, và người nhận biết nên tin tới đâu.