Lovable hoặc Bolt kẹt trong vòng lặp sửa lỗi? Cách hoàn thiện MVP của bạn

Bạn yêu cầu công cụ sửa phần đăng nhập. Đăng nhập chạy được, nhưng giờ bảng điều khiển lại trống trơn. Một prompt khác khôi phục bảng điều khiển và lại làm hỏng đăng nhập. Nếu Lovable hoặc Bolt cứ sửa đi sửa lại cùng một lỗi, bước tiếp theo hữu ích là củng cố bằng chứng xoay quanh một lỗi duy nhất. Thay đổi nhiều hơn không đồng nghĩa với tiến triển nhiều hơn.

Vì sao ứng dụng làm bằng AI bị kẹt trong vòng lặp sửa lỗi?

Vòng lặp sửa lỗi xảy ra khi các thay đổi chỉ xử lý triệu chứng nhìn thấy được mà không xác định và kiểm chứng nguyên nhân gốc. Nhiều lỗi khác nhau có thể tạo ra cùng một màn hình, nên một yêu cầu chung chung khiến công cụ có quá nhiều thứ "có vẻ hợp lý" để thay đổi.

Một bảng điều khiển trống có thể là do một request thất bại, một chính sách phân quyền, kết nối nhầm cơ sở dữ liệu, hoặc thực sự không có dữ liệu. Sửa component có thể làm thông báo lỗi biến mất trong khi request thất bại vẫn còn nguyên. Mục tiêu của bạn là xác định ranh giới nào đã hỏng: trình duyệt, máy chủ, nhà cung cấp xác thực, cơ sở dữ liệu hay tích hợp bên ngoài.

Hãy đặt một quy tắc dừng thực tế: nếu cùng một triệu chứng quay lại sau một lần sửa có trọng tâm, hãy ngừng lặp lại prompt và thu thập một loại bằng chứng khác. Đây là thói quen làm việc, không phải giới hạn được nền tảng công bố. Nó giúp một dự án nhỏ không bị tích tụ những thay đổi không liên quan trong khi chẳng ai giải thích được cái gì đang hỏng.

Bản xem trước của công cụ bị hỏng, hay ứng dụng của bạn bị hỏng?

Hãy kiểm tra môi trường của công cụ tách biệt với ứng dụng trước khi viết lại mã. Một sự cố của nền tảng hay lỗi kết nối bản xem trước không chứng minh rằng kiến trúc sản phẩm của bạn cần thay thế.

Hướng dẫn khắc phục sự cố bản xem trước hiện tại của Bolt khuyên nên kiểm tra trạng thái dịch vụ, thu thập lỗi trong console của trình duyệt, thử bản build production và rà soát các biến môi trường bị thiếu. Hướng dẫn này cũng giải thích rằng việc gửi đi gửi lại cùng một prompt sửa bản xem trước khó có tác dụng sau lần thử đầu tiên không thành công.

Dùng bảng trên để chọn hướng điều tra tiếp theo, chứ không phải để kết luận chẩn đoán. Một network request thất bại vẫn có thể bắt nguồn từ mã ứng dụng, và một màn hình trắng có thể do nhiều nguyên nhân. Hãy ghi lại lỗi có ý nghĩa đầu tiên trước khi các lỗi phát sinh sau che lấp nó.

Cần lưu lại gì trước khi thử sửa thêm lần nữa?

Hãy giữ lại trạng thái mã hữu ích gần nhất và xác định những dữ liệu mà một lần sửa có thể ảnh hưởng. Lịch sử mã và bản sao lưu cơ sở dữ liệu giải quyết những bài toán khôi phục khác nhau.

Tài liệu về lịch sử phiên bản của Lovable mô tả cách xem trước, đánh dấu và khôi phục các phiên bản mã. Tài liệu nói rõ rằng việc khôi phục mã không hoàn tác dữ liệu trong cơ sở dữ liệu. Trước khi khôi phục một phiên bản, hãy kiểm tra xem các thay đổi sau đó có làm thay đổi bản ghi, phân quyền hoặc schema mà mã cũ đang dựa vào hay không.

1. Ghi rõ trạng thái cuối cùng mà hành trình chính còn hoạt động, kèm mốc thời gian hoặc mã định danh commit.
2. Ghi lại lỗi hiện tại và lưu mọi phần việc hữu ích chưa commit theo quy trình mà dự án của bạn hỗ trợ.
3. Tạo bản sao lưu cơ sở dữ liệu phù hợp hoặc một bản sao thử nghiệm an toàn trước khi làm những việc thay đổi dữ liệu hoặc schema.
4. Ghi lại dự án và môi trường nào đang có người dùng thật để có thể kiểm thử bản sửa tách biệt khỏi họ.

Một prompt sửa lỗi hữu ích trông như thế nào?

Một prompt sửa lỗi hữu ích nêu đúng một lỗi có thể tái hiện, cung cấp bằng chứng liên quan và giới hạn phạm vi thay đổi được đề xuất. Hãy yêu cầu giải thích nguyên nhân trước khi cho phép triển khai một thay đổi mà bạn không thể đánh giá.

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

Ví dụ trên chỉ mang tính giả định. Hãy thay các chi tiết bằng những gì bạn thực sự quan sát được. Phản hồi 403 là manh mối cho thấy lỗi truy cập; nó không phải là lý do để gỡ bỏ cơ chế phân quyền. Đừng đưa mật khẩu, token, chuỗi kết nối hay dữ liệu khách hàng vào prompt và ảnh chụp màn hình.

Với các dự án Lovable, hướng dẫn về log backend giải thích cách kiểm tra request và lỗi trên các dịch vụ mà dự án của bạn sử dụng. Hãy đối chiếu lỗi với thời điểm và môi trường của thao tác. Một dòng log liên quan đã được lọc thông tin nhạy cảm hữu ích hơn nhiều so với một đống log lớn chưa lọc.

Làm sao biết bản sửa thực sự có hiệu quả?

Bản sửa có hiệu quả khi các bước ban đầu cho ra kết quả mong đợi và các luồng quan trọng lân cận vẫn hoạt động đúng. Hãy kiểm tra trạng thái đã lưu sau khi tải lại trang, chứ không chỉ nhìn thông báo thành công tạm thời.

1. Lặp lại đúng lỗi ban đầu với một tài khoản mới và cùng dữ liệu đầu vào.
2. Tải lại hoặc mở lại ứng dụng và xác nhận kết quả đã được lưu đúng.
3. Lặp lại với một tài khoản thông thường thứ hai và kiểm tra các ranh giới sở hữu đúng như dự định.
4. Thử một trường hợp lỗi, chẳng hạn dữ liệu không hợp lệ hoặc request bị gián đoạn, trong môi trường thử nghiệm an toàn.
5. Kiểm tra các luồng lân cận dùng chung phần mã đã thay đổi, sau đó chạy các bước kiểm tra liên quan của dự án và bản build production.

Khi nào nên nhờ đến lập trình viên?

Hãy nhờ lập trình viên khi bạn không thể tự tin giải thích hoặc kiểm chứng một thay đổi trên luồng quan trọng, hoặc khi đã điều tra có trọng tâm mà vẫn không cô lập được nguyên nhân. Quyền truy cập thanh toán, rò rỉ dữ liệu giữa các tài khoản và những thay đổi cơ sở dữ liệu lặp đi lặp lại cần được đặc biệt thận trọng.

Một đợt rà soát có giới hạn có thể trả lời vấn đề nằm ở cấu hình, một lỗi triển khai nhỏ hay một vấn đề thiết kế lớn hơn. Hãy yêu cầu chẩn đoán, danh sách file hoặc dịch vụ dự kiến thay đổi, các bài kiểm thử nghiệm thu và phương án hoàn tác. Bạn có thể đặt làm đợt rà soát đó trước khi đồng ý xây lại.

Một bản bàn giao tốt bao gồm URL ứng dụng, quyền truy cập dự án hoặc repository theo cách được hỗ trợ, các bước tái hiện, một đoạn quay màn hình ngắn, thông báo lỗi đã lọc thông tin nhạy cảm và phiên bản chạy tốt gần nhất. Hãy bổ sung cột mốc tiếp theo với khách hàng và những tính năng không được đụng tới. Chỉ chia sẻ thông tin đăng nhập qua quy trình chia sẻ bí mật hoặc cấp quyền tài khoản phù hợp.

Bản phát hành tiếp theo nên bao gồm những gì?

Bản phát hành tiếp theo nên khắc phục một nhóm nhỏ, đo lường được các hành trình đang lỗi. Hãy tách riêng các yêu cầu tính năng mới cho đến khi những hành trình đó đã được kiểm thử trên ứng dụng đã xuất bản.

Dùng kế hoạch ra mắt MVP với 12 hạng mục kiểm tra để phát hiện các lỗ hổng liền kề sau khi sửa. Nếu ứng dụng chạy tốt ở bản xem trước nhưng hỏng khi xuất bản trên Replit, hãy dùng danh sách kiểm tra triển khai Replit. Nếu cần hỗ trợ trực tiếp, hãy chọn điểm bắt đầu trên trang Lovable hoặc Bolt và đặt lịch gọi. Hãy mang theo luồng đang lỗi; cuộc trao đổi đầu tiên sẽ giúp xác định một bước tiếp theo hữu ích.