Cách gỡ lỗi app do AI xây dựng: một phương pháp thực tế

Để gỡ lỗi một app do AI xây dựng, trước hết hãy cố tình làm cho lỗi xảy ra lại, sau đó thu thập bằng chứng — các bước chính xác, thông báo lỗi, và những gì console và tab network của trình duyệt hiển thị — rồi đưa cho AI dưới dạng "tôi đã làm X, mong đợi Y, nhận được Z". Nếu một bản sửa làm mọi thứ tệ hơn, hãy khôi phục về phiên bản hoạt động gần nhất thay vì chồng thêm bản sửa. Bạn không cần đọc mã để làm tốt tất cả những điều này.

Hướng dẫn này bao quát toàn bộ vòng lặp, kèm một tour nhanh về công cụ dành cho nhà phát triển của trình duyệt dành cho người không phải lập trình viên.

Vòng lặp gỡ lỗi

Mọi bản sửa lỗi, dù do người hay AI thực hiện, đều theo cùng một vòng lặp:

1. Tái hiện — làm cho lỗi xảy ra một cách ổn định.
2. Quan sát — thu thập thông báo lỗi và việc app đang làm gì.
3. Mô tả — đưa cho AI các bước cụ thể, kết quả mong đợi và kết quả thực tế.
4. Sửa — để AI thay đổi một điều duy nhất.
5. Xác minh — lặp lại chính xác các bước và xác nhận lỗi đã được sửa, và không có gì lân cận bị hỏng.
6. Khôi phục nếu cần — nếu mọi thứ tệ hơn, hoàn tác và thử lại với thông tin tốt hơn.

Hầu hết thời gian bị lãng phí với app do AI xây dựng đến từ việc bỏ qua các bước 1, 2 và 5: nói "nó bị hỏng", chấp nhận một thay đổi mà không kiểm thử, rồi yêu cầu sửa thêm trên một thứ đã hỏng.

Bước 1: Tái hiện lỗi

Một lỗi mà bạn có thể kích hoạt theo ý muốn là đã được sửa một nửa. Hãy cố tìm chuỗi bước ngắn nhất gây ra nó.

Hãy tự hỏi:

• Nó có xảy ra mỗi lần không? Nếu chỉ thỉnh thoảng, điều gì khác đi khi nó xảy ra — một bản ghi cụ thể, kết nối chậm, hay đang bị đăng xuất?
• Nó có xảy ra với mọi người dùng không? Đăng nhập bằng một tài khoản khác. Nhiều lỗi chỉ hiện ra với người dùng mới chưa có dữ liệu, hoặc với người dùng có vai trò khác.
• Nó có xảy ra trên mọi thiết bị không? Thử màn hình rộng bằng điện thoại và một trình duyệt khác.
• Nó có bắt đầu sau một thay đổi cụ thể không? Nếu hôm qua vẫn chạy, vài thay đổi gần nhất là nghi phạm chính.

Ghi các bước dưới dạng một danh sách đánh số ngắn. Bạn sẽ dán nó vào prompt sau.

Bước 2: Đọc thông báo lỗi

Thông báo lỗi trông có vẻ đáng sợ, nhưng bạn chỉ cần vài phần trong đó.

Bạn không cần hiểu nó; bạn cần sao chép chính xác. "Cannot read properties of undefined (reading 'name')" cho AI biết rằng mã đã mong đợi một dữ liệu nào đó (có lẽ là một đặt chỗ hoặc một người dùng) nhưng nó không có. Nếu diễn đạt lại như "một lỗi undefined nào đó" thì mất đi thông tin đó.

Một vài lỗi phổ biến, dịch đại ý:

• Lỗi undefined / null — mã mong đợi dữ liệu nhưng nó không đến. Thường là trạng thái đang tải hoặc một danh sách rỗng mà mã không xử lý.
• 404 Not Found — trang hoặc địa chỉ API không tồn tại. Thường là lỗi gõ trong một đường dẫn hoặc liên kết đến trang đã đổi tên.
• 401 Unauthorized / 403 Forbidden — yêu cầu chưa đăng nhập, hoặc người dùng không được phép làm điều đó.
• 500 Internal Server Error — mã phía máy chủ bị crash. Nguyên nhân thật nằm trong nhật ký máy chủ, không phải trình duyệt.
• Lỗi CORS — trình duyệt đã chặn một yêu cầu đến một tên miền khác. Thường là vấn đề cấu hình phía máy chủ.

Bước 3: Dùng công cụ dành cho nhà phát triển của trình duyệt

Mọi trình duyệt trên máy tính đều có công cụ dành cho nhà phát triển tích hợp ("devtools"). Chúng cho thấy trang đang làm gì ở hậu trường. Trên Chrome, Edge và Firefox, nhấp chuột phải vào bất kỳ đâu trên trang và chọn Inspect (Kiểm tra), hoặc nhấn F12 (Cmd+Option+I trên Mac). Trên Safari, trước tiên hãy bật menu Develop trong phần cài đặt của Safari.

Bạn chỉ cần ba tab.

Console

Tab Console liệt kê lỗi và thông báo từ mã của trang. Lỗi hiển thị màu đỏ. Nếu một nút không làm gì khi bạn nhấn, console thường sẽ hiển thị một lỗi đỏ đúng vào thời điểm bạn nhấn. Sao chép toàn bộ nội dung lỗi (nhấp chuột phải để tìm tùy chọn sao chép trong hầu hết trình duyệt).

Network

Tab Network liệt kê mọi yêu cầu mà trang gửi đi — tải dữ liệu, lưu form, đăng nhập. Mở nó lên, rồi lặp lại các bước gây ra lỗi.

• Tìm các dòng màu đỏ hoặc có trạng thái từ 400 trở lên.
• Nhấp vào dòng thất bại để xem Response. Lỗi máy chủ thường có một thông báo ở đó hữu ích hơn bất cứ thứ gì trên màn hình.
• Ghi lại URL và mã trạng thái của yêu cầu — "POST tới /api/bookings trả về 500" là một câu rất hữu ích để đưa cho AI.

Bật Preserve log nếu lỗi liên quan đến việc tải lại trang hoặc chuyển hướng, để các yêu cầu không biến mất.

Elements

Tab Elements (hoặc Inspector) hiển thị cấu trúc và kiểu dáng của trang. Nó hữu ích nhất cho lỗi bố cục: di chuột qua một phần tử để xem kích thước và khoảng cách được làm nổi bật. Bạn không cần chỉnh sửa gì ở đây; chỉ cần nói "chân trang rộng 2.000 pixel trên điện thoại và đẩy trang sang ngang" là đủ.

Bước 4: Kiểm tra nhật ký máy chủ

Một số lỗi xảy ra trên máy chủ, nơi trình duyệt không thấy được. Lỗi 500 trong tab network là dấu hiệu kinh điển. Nhật ký máy chủ — đầu ra văn bản của backend khi nó chạy — thường chứa lỗi thật kèm stack trace (danh sách các hàm đang chạy khi nó thất bại).

Bạn tìm thấy chúng ở đâu tùy thuộc vào công cụ. Trong hầu hết các công cụ tạo app bằng AI, bạn có thể mở terminal hoặc màn hình nhật ký của dự án, hoặc đơn giản là hỏi AI: "Kiểm tra nhật ký máy chủ về lỗi từ yêu cầu gần nhất và cho tôi biết điều gì đã thất bại."

Bước 5: Mô tả lỗi cho AI

Hãy đưa những gì bạn đã thu thập vào khuôn dạng này:

Ở trang Bookings, đăng nhập với vai trò thành viên: tôi đã nhấn Cancel cho lớp 9:00 ngày mai. Mong đợi: đặt chỗ biến mất và lớp hiển thị thêm một chỗ trống. Thực tế: trên màn hình không có gì thay đổi. Console hiển thị TypeError: Cannot read properties of undefined (reading 'id') tại BookingCard.tsx:31, và tab network cho thấy DELETE /api/bookings/123 trả về 500. Tìm nguyên nhân, sửa nó, và kiểm tra việc hủy hoạt động cho thành viên chỉ có một đặt chỗ và cho thành viên có nhiều đặt chỗ.

Vì sao mỗi phần đều quan trọng:

• Ở đâu và với vai trò nào thu hẹp phạm vi xuống một màn hình và một vai trò.
• Các bước chính xác cho phép AI tái hiện lỗi.
• Mong đợi so với thực tế định nghĩa thế nào là "đã sửa".
• Nội dung lỗi và yêu cầu thất bại chỉ thẳng vào nguyên nhân.
• "Kiểm tra rằng…" yêu cầu AI xác minh, không chỉ chỉnh sửa.

Nếu AI đã thử sửa hai lần và thất bại, hãy yêu cầu nó giải thích trước khi thay đổi bất cứ thứ gì:

Đừng thay đổi mã vội. Bạn nghĩ điều gì gây ra lỗi này, và bằng chứng nào ủng hộ điều đó?

Một giả thuyết sai rất dễ nhận ra khi được viết ra, và sửa nó tốn ít công hơn nhiều so với sửa một bản vá sai.

Bước 6: Xác minh, rồi kiểm tra vùng lân cận

Khi AI nói đã sửa xong, hãy lặp lại chính xác các bước ở Bước 1. Sau đó kiểm tra những thứ xung quanh:

• Cùng hành động với một vai trò người dùng khác
• Cùng hành động khi không có dữ liệu, và khi có rất nhiều dữ liệu
• Các trang dùng chung thành phần với trang bạn đã sửa
• Màn hình rộng bằng điện thoại, nếu bản sửa có tác động đến bố cục

Những thay đổi của AI đôi khi sửa được một đường đi nhưng lặng lẽ làm hỏng một đường khác. Kiểm tra hai phút ngay bây giờ sẽ tiết kiệm một giờ bối rối sau này.

Bước 7: Khôi phục thay vì chồng thêm

Nếu một bản sửa làm mọi thứ tệ hơn, hoặc bạn đã đi qua ba vòng mà không có tiến triển, hãy quay lại. Khôi phục về phiên bản hoạt động gần nhất và diễn đạt lại với bằng chứng tốt hơn gần như luôn tốt hơn so với việc yêu cầu bản sửa thứ tư chồng lên ba bản sai. Mỗi lần thử thất bại để lại mã, và mã đó làm nhiễu lần thử tiếp theo.

Những thói quen tốt giúp việc khôi phục dễ dàng:

• Kiểm thử sau mỗi thay đổi, để bạn biết thay đổi nào làm hỏng mọi thứ.
• Giữ thay đổi nhỏ — một tính năng hoặc một bản sửa cho mỗi tin nhắn.
• Ghi lại phiên bản hoạt động gần nhất trước khi làm điều gì rủi ro.
• Nếu mã nằm trong Git, hãy commit các phiên bản hoạt động để có thể quay lại.

Các mẫu lỗi phổ biến trong app do AI xây dựng

Khi vấn đề không phải là lỗi

Một số "lỗi" là do AI xây dựng đúng những gì nó được yêu cầu, và mô tả thì mơ hồ. Nếu bản sửa bạn yêu cầu thực chất là thay đổi hành vi, hãy nói thẳng: "Thay đổi để…". Nếu bạn thấy mình không chắc hành vi đúng là gì, hãy quyết định điều đó trước. Hướng dẫn của chúng tôi về viết prompt cho công cụ tạo app bằng AI hướng dẫn cách xác định quy tắc rõ ràng. Và nếu bạn đang chuẩn bị một app cho người dùng thật, đưa prototype AI lên production đề cập đến các kiểm tra nên làm trước khi ra mắt.

Gỡ lỗi trong Mythex

Mythex có công cụ cho mỗi bước của vòng lặp:

• Preview để tái hiện lỗi, bao gồm khung kích thước điện thoại.
• /test để agent nhấp qua bản xem trước trực tiếp của bạn như một người dùng và báo cáo các luồng bị hỏng.
• /fix để chỉ agent vào các lỗi cụ thể.
• Chế độ Plan để agent điều tra và giải thích trước khi chỉnh sửa bất cứ thứ gì.
• Code → terminal để xem nhật ký máy chủ của app.
• Revert to this point trên bất kỳ phản hồi nào sẽ khôi phục dự án về điểm kiểm tra đó.

Nếu việc xuất bản thất bại, hộp thoại xuất bản thường có Fix with AI, đọc đầu ra build hoặc nhật ký của app. Xem Debug your app và Publish troubleshooting trong tài liệu.

Câu hỏi thường gặp