AI không chỉ sinh AC, nó còn là một người review tuyệt vời — soi mâu thuẫn, chỗ mơ hồ, case thiếu, Then không đo được. Điểm mạnh: AI không ngại nói "chỗ này mơ hồ" như đồng nghiệp đôi khi ngại. Bài này biến AI thành lớp kiểm định thứ hai trước khi AC vào sprint.
Bốn loại lỗi AI review giỏi
- Mơ hồ: từ như "nhanh", "thân thiện", "hợp lý" — không đo được.
- Mâu thuẫn: hai Scenario nói ngược nhau về cùng điều kiện.
- Thiếu case: nhánh lỗi hiển nhiên bị bỏ (số dư 0, quyền thiếu).
- Không kiểm chứng được: Then không nói rõ trạng thái/thông báo.
Prompt mẫu "review AC như một critic"
Đóng vai QA lead khó tính. REVIEW bộ Acceptance Criteria dưới đây.
Không viết lại — chỉ CHỈ RA vấn đề, phân loại theo:
(1) Mơ hồ/không đo được — trích đúng câu chữ có vấn đề.
(2) Mâu thuẫn giữa các Scenario.
(3) Case còn thiếu (nêu nhánh cụ thể, giải thích vì sao quan trọng).
(4) Then không kiểm chứng được.
Với mỗi vấn đề: nêu mức độ (Cao/Trung/Thấp) và gợi ý sửa 1 dòng.
Không tự bịa ràng buộc nghiệp vụ; nếu nghi thiếu, hãy hỏi.
AC:
[dán bộ AC của bạn]
Mẹo: câu "chỉ ra vấn đề, không viết lại" giữ AI ở vai critic — bạn nhận feedback chứ không bị AI thay bằng phiên bản mới toàn giả định của nó. Yêu cầu AI gắn mức độ (Cao/Trung/Thấp) cho từng vấn đề giúp bạn ưu tiên: sửa hết các lỗi mức Cao trước khi họp, còn mức Thấp có thể để bàn ở refinement. Đây là cách biến một danh sách feedback dài thành việc làm có thứ tự.
Vì sao AI review giỏi hơn con người ở một số điểm
Đồng nghiệp đôi khi ngại chỉ ra rằng AC của bạn mơ hồ, hoặc đọc lướt vì bận. AI không có tâm lý đó: nó soi từng câu, không mệt, không nể nang, và bắt lỗi mâu thuẫn giữa hai Scenario cách nhau ba mươi dòng mà mắt người dễ bỏ qua. Đổi lại, AI không hiểu ngữ cảnh nghiệp vụ sâu như dev senior đã làm hệ thống ba năm. Vì thế cách dùng đúng là ghép — AI làm lớp soi cơ học, con người làm lớp phán đoán nghiệp vụ. Đừng chọn một trong hai.
Quy trình review 2 vòng
- Vòng tự soi: dán AC, chạy prompt critic ở trên.
- Phân loại feedback: cái nào đúng (sửa ngay), cái nào AI hiểu nhầm (bỏ qua, nhưng ghi chú vì sao).
- Vòng phản đề: hỏi AI "một dev cố tình hiểu sai AC này có thể build ra cái gì lệch ý?" — lộ ra chỗ chưa chặt.
- Chốt bản sửa, ghi lại các quyết định.
Một lập trình viên đọc AC này nhưng muốn làm ít nhất có thể. Họ có
thể build ra kết quả nào vẫn "đúng chữ" nhưng SAI ý định? Liệt kê các
kẽ hở diễn giải và đề xuất câu chữ bịt kẽ hở.
Checklist review AC
- [ ] Đã chạy prompt critic 4 loại lỗi.
- [ ] Mọi từ mơ hồ đã thay bằng tiêu chí đo được.
- [ ] Không còn Scenario mâu thuẫn.
- [ ] Đã chạy "vòng phản đề" tìm kẽ hở diễn giải.
- [ ] Ghi lại quyết định với các feedback bị bỏ qua.
Sai lầm thường gặp
- Sửa mù theo mọi feedback. AI có thể ảo giác ra "case thiếu" thực chất không thuộc phạm vi story, làm scope phình. Lọc theo mục tiêu story.
- Để AI viết lại toàn bộ. Nếu bảo AI "sửa giúp", nó dễ đưa vào giả định nghiệp vụ mới sai. Giữ nó ở vai critic, bạn tự sửa.
- Bỏ ghi chú vì sao bỏ qua feedback. Sáu tuần sau bạn quên mất lý do và tranh cãi lại từ đầu. Ghi quyết định.
- Phụ thuộc quá mức, bỏ review người. AI là lớp kiểm thứ hai, không thay được refinement với dev/QA hiểu hệ thống thật.