Vì sao app AI làm ra vẫn sai ngay cả khi mọi bài test đều đạt?

AI có thể tạo ra tính năng trong vài phút, nhưng nó không thể biết shop của bạn có cho cộng dồn voucher hay không, tiền vào muộn thì đơn xử lý thế nào, hay thu hồi quyền truy cập ra sao khi hoàn tiền. Nếu bạn không chốt những ranh giới này trước, AI sẽ âm thầm quyết định thay bạn. Dưới đây là cách đặt lại ranh giới quyết định và bộ kiểm tra thực tế để bạn làm chủ sản phẩm do AI xây dựng.

App chạy được, rồi khách thật bắt đầu sử dụng

Bạn mô tả một ý tưởng cho AI, nó viết code, dựng giao diện và trả về một app có thể chạy được. Bạn thử vài thao tác, mọi thứ trông ổn. Những bài test, tức các phép kiểm tra xem chương trình có hoạt động như dự kiến không, đều báo đạt. Có vẻ sản phẩm đã sẵn sàng.

Cách xây phần mềm chủ yếu bằng việc mô tả điều mình muốn cho một AI coding agent thường được gọi là vibe coding. Agent là công cụ AI có thể nhận yêu cầu, viết và sửa code, chạy kiểm tra rồi báo kết quả. Bạn có thể dùng cách này mà không cần tự đọc từng dòng code. Vì vậy, người đang vibe code có thể là chủ shop, người bán khóa học, người làm sản phẩm số một mình, chứ không nhất thiết là lập trình viên.

Nhưng hãy hình dung khách thật bắt đầu mua hàng. Có người muốn hoàn tiền sau khi đã nhận sản phẩm. Có người chuyển khoản thiếu 2.000 đồng. Có người nhập hai mã giảm giá cho cùng một đơn. App vẫn chạy, nhưng cách nó xử lý những tình huống đó có thể hoàn toàn khác điều bạn muốn. Sửa một chỗ, một chỗ khác lại hỏng.

Vấn đề nằm ở đâu khi AI đã viết code, chạy test và báo mọi thứ đều ổn? Bài này dành cho người đang dùng AI để xây sản phẩm kinh doanh, đặc biệt khi bạn không trực tiếp lập trình. Mình muốn cùng bạn nhìn rõ phần việc dễ bị bỏ sót, rồi đi qua một quy trình 4 bước để xác định yêu cầu và tự kiểm tra kết quả trước khi chấp nhận.

Khi AI tự quyết định thay bạn

Giả sử bạn đang làm tính năng mã giảm giá cho shop. Bạn giao cho agent một prompt, tức lời yêu cầu gửi cho AI: “Cho khách nhập mã giảm giá khi thanh toán.” Agent tạo ô nhập mã, tính lại tiền và viết test. Bạn thử, thấy mã hoạt động bình thường.

Bây giờ khách có hai mã: SALE20 giảm 20% và WELCOME50K giảm 50.000 đồng. Agent cho nhập cả hai, trừ 20% trước rồi trừ tiếp 50.000 đồng. Các bài test đều đạt vì chúng đang kiểm tra đúng cách tính mà agent đã xây.

Nhưng shop của bạn có cho dùng hai mã cùng lúc không? Nếu có, giảm theo phần trăm trước hay trừ số tiền cố định trước? Hai thứ tự đó cho kết quả khác nhau. Mã giảm giá có dùng được với sản phẩm đang khuyến mãi không? Tổng tiền có được về 0 đồng không?

Đó không phải những câu hỏi có một đáp án kỹ thuật duy nhất. Chúng là luật kinh doanh của shop. Khi bạn chưa quyết định, agent vẫn cần chọn một cách xử lý để hoàn thành yêu cầu. Nó có thể chọn một phương án trông hợp lý, viết code theo phương án đó, rồi tạo test để xác nhận chính phương án mình đã chọn.

Ngay cả khi có bước review, tức kiểm tra code có khớp với bản kế hoạch hay không, kết quả vẫn có thể đạt. Nếu kế hoạch đã bỏ sót luật kinh doanh, việc làm đúng kế hoạch chưa đủ để tạo ra sản phẩm đúng ý bạn.

Test và review giúp trả lời: “Code có làm đúng điều đã viết không?” Chúng không tự trả lời được: “Điều đã viết đã đủ chưa?”

Đây là chỗ dễ gây nhầm lẫn. Lỗi không nhất thiết nằm ở khả năng viết code của AI. Có một quyết định chưa từng được đưa ra, nên toàn bộ quy trình phía sau đang xác nhận một giả định thay vì một yêu cầu kinh doanh đã được chốt.

Vì sao công cụ tốt hơn vẫn chưa đủ

Mình đã dành thời gian đọc từng file hướng dẫn trong các bộ công cụ dành cho AI coding agent. Đó là những quy tắc, kỹ năng và bước kiểm tra chỉ dẫn agent từ lúc làm rõ ý tưởng, lập kế hoạch, viết code cho đến test và review. Điều đáng chú ý là phần quan trọng của quy trình nằm rất nhiều ở trước và sau lúc viết code.

Các bộ công cụ này có những điểm dừng để hỏi người dùng, xin xác nhận hoặc chờ duyệt trước khi đi tiếp. Nhưng phần lớn điểm dừng thực chất là lời hướng dẫn dành cho model AI làm theo, không phải một đoạn code bắt buộc nó phải dừng. Chỉ một số ít rào chắn được thực thi trực tiếp bằng code, chẳng hạn ngăn agent đọc file chứa mật khẩu hoặc khóa truy cập.

Chế độ mặc định thường nghiêng về việc chạy liên tục để hoàn thành công việc nhanh. Cách này hữu ích khi người dùng đã hiểu rõ yêu cầu. Những chế độ hỏi ngược lại hoặc dừng giữa các giai đoạn thường có sẵn, nhưng cần được chủ động lựa chọn.

Vì vậy, thêm hướng dẫn cho agent chưa đồng nghĩa với việc mọi quyết định quan trọng đều đã được kiểm soát. Bạn vẫn cần chọn những chỗ phải dừng, xem bằng chứng agent đưa ra và quyết định có cho công việc đi tiếp hay không. Công cụ có thể hỗ trợ việc kiểm tra, nhưng không thể tự biết luật riêng của shop khi bạn chưa nói rõ.

Đặt ranh giới giữa quyết định và thực thi

Một cách tiếp cận là tách rõ phần bạn quyết định khỏi phần agent thực hiện. Mình gọi đây là ranh giới quyết định: những điều phải đúng với việc kinh doanh thuộc về người sở hữu sản phẩm; việc biến chúng thành phần mềm có thể giao cho agent.

Ví dụ, bạn quyết định shop có cho cộng dồn mã giảm giá không, khi nào đơn được xem là đã thanh toán, khách nhận gì sau khi trả tiền, trường hợp nào được hoàn tiền. Agent nhận những quyết định đó, viết code và kiểm tra kết quả theo yêu cầu đã ghi.

Ai	Làm gì	Bằng chứng
Bạn	Xác định quy tắc, giới hạn và kết quả mong muốn	Yêu cầu cụ thể, có thể kiểm tra
Agent	Lập kế hoạch, viết code, chạy test và review	Code, kết quả test, bản ghi kiểm tra
Bạn	Đi lại quy trình như khách thật, đối chiếu kết quả với quy tắc	Tình huống đã thử và hành vi quan sát được

Những phép kiểm tra tự động chỉ có giá trị trong phạm vi yêu cầu bạn đã định nghĩa. Nếu quy tắc cộng dồn mã chưa được viết ra, một bài test đạt không chứng minh cách giảm giá đang đúng với shop. Vì vậy cần lần kiểm tra thứ hai từ chính người hiểu hoạt động kinh doanh.

Điểm quan trọng là bạn không cần đọc từng dòng code để thực hiện phần việc này. Thứ cần làm rõ là điều gì phải đúng, thế nào thì được xem là đúng, và bằng chứng nào cho thấy kết quả thực tế đáp ứng điều đó. Khi ranh giới này rõ ràng, agent có nhiều chỗ để tự xử lý kỹ thuật mà không phải đoán thay quyết định kinh doanh.

Bước 1: Viết rõ kết quả trước khi giao việc

Trước khi nhờ agent xây một tính năng, mình sẽ bắt đầu bằng một bản thỏa thuận ngắn về kết quả cần đạt. Nó không phải hợp đồng pháp lý, mà là cách ghi rõ yêu cầu để cả bạn lẫn agent có cùng căn cứ kiểm tra.

Bản này có bốn phần:

1. Outcome, kết quả mong muốn: Người dùng làm được gì, hệ thống phản hồi ra sao?
2. Constraints, giới hạn: Những điều cần giữ nguyên hoặc không được vượt qua, như ngân sách, cổng thanh toán đang dùng, thời hạn và phần hệ thống không được sửa.
3. Non-goals, việc chưa làm: Những tính năng cố ý để ngoài phạm vi lần này, tránh agent tự mở rộng công việc.
4. Acceptance criteria, tiêu chí nghiệm thu: Những tình huống có thể quan sát hoặc chạy thử để kết luận tính năng đã đáp ứng yêu cầu.

Ví dụ, với tính năng mã giảm giá:

• Kết quả: Khách có thể nhập mã khi thanh toán và thấy số tiền được giảm.
• Giới hạn: Không thay đổi luồng thanh toán hiện tại; mỗi đơn chỉ dùng một mã.
• Chưa làm: Chưa hỗ trợ cộng dồn nhiều mã giảm giá.
• Tiêu chí nghiệm thu: Khách nhập SALE20 rồi tiếp tục nhập WELCOME50K. Hệ thống từ chối mã thứ hai và hiển thị “Mỗi đơn chỉ được dùng một mã giảm giá”.

Khác biệt nằm ở dòng cuối. “Có ô nhập mã” chỉ mô tả giao diện. Tình huống nhập hai mã nói rõ hành vi nào được chấp nhận, hành vi nào bị từ chối. Agent có căn cứ để viết test, còn bạn có căn cứ để kiểm tra.

Nếu có nhiều cách thực hiện, bạn có thể yêu cầu agent trình bày các phương án cùng trade-off, tức điều được và mất khi chọn từng cách. Hãy nhìn cả tình huống xấu nhất, không chỉ trường hợp thuận lợi nhất. Những khác biệt ảnh hưởng đến luật kinh doanh cần được quyết định trước khi agent bắt đầu xây.

Bước 2: Tìm những luật kinh doanh chưa được viết

Sau khi xác định kết quả, hãy nhìn sản phẩm như một hệ thống. Liệt kê các đối tượng như sản phẩm, khách hàng, đơn hàng, thanh toán và giao hàng. Với đơn hàng, vẽ các trạng thái, tức những tình trạng nó có thể ở trong đó: mới tạo, chờ thanh toán, đã trả tiền, đã giao, đã hoàn tiền hoặc hết hạn. Sau đó hỏi điều gì xảy ra khi đơn chuyển từ trạng thái này sang trạng thái khác, kể cả trường hợp tiền đến sau khi đơn hết hạn.

Tiếp theo là tìm edge case, tức tình huống ít gặp nhưng vẫn có thể xảy ra. Có thể nhờ agent lập danh sách theo nhóm: loại người dùng, dữ liệu quá lớn hoặc quá nhỏ, thời điểm, số lượng, chuyển trạng thái, môi trường chạy, lỗi kéo theo lỗi, quyền truy cập, tính toàn vẹn dữ liệu, kết nối với dịch vụ khác, quy định cần tuân thủ và logic kinh doanh. Riêng cột “hành vi mong đợi” của các tình huống kinh doanh, bạn là người xác nhận, không để AI tự đoán.

Đây là 12 câu hỏi dễ bị bỏ ngỏ ở một shop bán sản phẩm số:

Tình huống	Câu bạn cần tự trả lời
1. Hai mã giảm giá	Có cộng dồn không? Nếu có, trừ theo thứ tự nào?
2. Hoàn tiền sau giao hàng	Có hoàn không? Thu hồi quyền truy cập ra sao?
3. Chuyển khoản lệch tiền	Thiếu hoặc thừa tiền thì xử lý thế nào?
4. Làm tròn và đổi tiền	Làm tròn VND và áp dụng tỷ giá theo quy tắc nào?
5. Thuế và hóa đơn	Giá niêm yết đã gồm thuế chưa? Xuất hóa đơn thế nào?
6. Đơn hết hạn	Nếu tiền đến sau khi đơn hết hạn thì sao?
7. Thông báo thanh toán trùng	Webhook gửi hai lần thì có giao hàng hai lần không?
8. Hết mã bản quyền	Nếu hết mã giữa lúc thanh toán thì xử lý sao?
9. Giá thay đổi	Giá đổi giữa lúc xem và trả tiền thì lấy giá nào?
10. Sản phẩm 0 đồng	Có cần đi qua cổng thanh toán không?
11. Lời hứa trên trang bán	Hứa giao ngay nhưng thực tế giao thủ công thì sao?
12. Kiểu giá bán	Có vô tình áp dụng giá thuê bao cho sản phẩm mua một lần không?

Webhook ở dòng 7 là thông báo tự động từ dịch vụ thanh toán gửi về hệ thống. Nếu cùng một thông báo đến hai lần, app cần biết có nên giao sản phẩm lần nữa hay không.

Đặc biệt, câu 11 và 12 nằm giữa việc build và việc bán. Test code không tự phát hiện lời hứa bán hàng sai với hành vi sản phẩm. Nếu bỏ qua một nhóm tình huống, hãy ghi rõ giả định khiến bạn bỏ qua; nếu giả định đó có thể sai, nó cũng cần được kiểm tra. Và trước khi nghiên cứu hay ra mắt, hãy ghi một phát hiện đủ để bạn dừng ý tưởng, thay vì chỉ tìm bằng chứng ủng hộ nó.

Bước 3: Chốt plan rồi mới build

Khi các quyết định quan trọng đã rõ, lúc này mới đến plan, tức bản kế hoạch thực hiện. Thay vì chỉ trao đổi trong cửa sổ chat, hãy yêu cầu agent viết plan thành một file có thể đọc và sửa. File đó ghi các giai đoạn công việc, những file dự kiến thay đổi và cách kiểm tra kết quả ở từng giai đoạn.

Việc lưu plan thành file tạo ra một điểm tham chiếu rõ ràng. Nếu cuộc trò chuyện kéo dài hoặc agent cần xem lại yêu cầu, căn cứ vẫn là nội dung bạn đã kiểm tra, không phải cách AI nhớ hoặc tóm tắt cuộc trao đổi. Bạn cũng có thể sửa kế hoạch trước khi cho phép thực hiện.

Mình sẽ tách việc lập kế hoạch và build, tức bước thực sự tạo hoặc sửa phần mềm, thành hai chặng riêng. Khi đang làm rõ yêu cầu, chọn chế độ để agent hỏi lại những điều chưa chắc chắn. Khi xây phần có rủi ro, chọn chế độ dừng giữa các giai đoạn để xem kết quả trước khi tiếp tục.

Một phần hữu ích khác là ghi lại những giả định chịu lực: điều đang được xem là đúng, dấu hiệu cho thấy nó không còn đúng, và việc sẽ làm khi giả định đó sai. Ví dụ, nếu một giai đoạn phụ thuộc vào quy tắc giá đã chốt, agent không được âm thầm thay ngưỡng, cách tính hay cấu trúc dữ liệu chỉ để hoàn thành nhanh hơn.

Với công việc dài, agent có thể tiếp tục chạy trong lúc bạn làm việc khác. Nhưng chạy xong chưa có nghĩa là được chấp nhận. Khi quay lại, bạn vẫn có bản plan để đối chiếu: nó đã thay đổi những gì, hoàn thành đến đâu, có tự mở rộng phạm vi hoặc đảo ngược quyết định nào không?

Bước 4: Hoàn thành nghĩa là có bằng chứng

Agent báo “Done” chưa phải là bằng chứng tính năng đã đúng. Sau thay đổi cuối cùng, cần có kết quả kiểm tra mới: đầu ra của test, ảnh chụp màn hình hoặc một lần chạy thực tế. Kết quả kiểm tra từ trước khi sửa code không chứng minh được phiên bản vừa sửa đang hoạt động.

Nếu phát hiện lỗi, việc đầu tiên là tìm nguyên nhân gốc. Một bài test báo sai không đồng nghĩa với việc sửa test cho thành đúng. Cũng không thể thay dữ liệu giả hoặc bỏ qua trường hợp khó chỉ để bảng kết quả chuyển sang màu xanh. Cần xem lỗi đến từ cách thực hiện, yêu cầu chưa rõ, hay một luật kinh doanh đã bị bỏ sót.

Sau phần kiểm tra của agent, bạn tự đi qua quy trình như một khách hàng. Thử chọn sản phẩm, đặt mua, thanh toán, nhận hàng và hoàn tiền. Với mỗi bước, đối chiếu hành vi quan sát được với những quy tắc đã ghi. Nếu có điểm khác nhau, đó là việc cần làm rõ trước khi chấp nhận kết quả.

Đừng dừng ở giao diện app. Hãy mở cả nội dung trang bán để xem lời hứa có đúng với thứ khách thực sự nhận được không. Nếu trang ghi giao ngay nhưng quy trình thực tế cần người xử lý thủ công, code chạy đúng vẫn chưa có nghĩa toàn bộ trải nghiệm bán hàng đúng.

Nguyên tắc này cũng áp dụng cho marketing. Một bản nháp chưa phải quyền được xuất bản. Mỗi thông tin khẳng định cần có nguồn để đối chiếu. Và nếu một chỉ số chưa được đo, hãy ghi là “chưa đo”, không biến khoảng trống dữ liệu thành số 0. Hoàn thành một công việc là có đủ bằng chứng phù hợp để người chịu trách nhiệm quyết định chấp nhận nó.

Thử trong 30 phút với sản phẩm của bạn

Bạn không cần bắt đầu bằng việc viết lại toàn bộ hệ thống. Hãy chọn một tính năng đang có hoặc chuẩn bị xây, miễn là nó liên quan đến tiền: mã giảm giá, thanh toán, hoàn tiền hoặc giao sản phẩm sau khi mua.

Dành 30 phút để làm một lượt:

1. Viết hợp đồng 4 phần: Kết quả muốn có, giới hạn phải giữ, việc chưa làm và tiêu chí có thể tự kiểm tra.
2. Liệt kê các đối tượng: Sản phẩm, khách hàng, đơn hàng, thanh toán, giao hàng. Vẽ các trạng thái đơn và những chỗ có thể chuyển sai.
3. Đi qua 12 quy tắc: Với từng tình huống liên quan, ghi quyết định kinh doanh của bạn. Tình huống không áp dụng thì ghi lý do.
4. Giao lại yêu cầu cho agent: Đưa các quyết định vừa viết vào trước khi agent lập plan hoặc build.
5. Tự kiểm tra một tình huống: Chọn một quy tắc kinh doanh và so sánh hành vi thực tế với kết quả bạn đã xác định, thay vì chỉ nhìn thông báo test đạt.

Nếu chưa biết câu trả lời cho một quy tắc, chính khoảng trống đó là kết quả đáng chú ý của bài tập. Nó cho thấy còn một quyết định cần làm rõ trước khi phần mềm có thể được đánh giá là đúng.

AI có thể ngày càng giỏi viết code. Khi đó, giá trị của người tự xây sản phẩm có lẽ nằm nhiều hơn ở khả năng nói rõ shop của mình vận hành theo những quy tắc nào, phục vụ ai và vì sao chọn cách đó.

Sản phẩm bạn đang làm có bao nhiêu quy tắc mà từ trước đến giờ chưa ai thực sự viết ra?

Framework độc quyền

#vibe-coding#ai-agent#quy-trinh#san-pham-so#acceptance-criteria