Cách Đưa Prototype AI Lên Production

Để đưa prototype AI lên production, bạn thu hẹp khoảng cách giữa "nó chạy khi tôi thử" và "nó vẫn chạy khi người khác dùng". Trong thực tế, điều đó gồm năm việc: kiểm thử các luồng chính mỗi khi bạn thay đổi gì đó, khóa chặt ai được xem và sửa gì, đảm bảo bạn biết về lỗi trước khi người dùng báo cho bạn, sao lưu dữ liệu và chứng minh bạn có thể khôi phục, và giữ app đủ nhanh trên điện thoại. Không cần viết lại từ đầu — đây là một danh sách kiểm tra mà bạn làm việc cùng với chính AI đã xây dựng prototype.

Prototype và production: điều gì thực sự thay đổi

Prototype chỉ có một người dùng cẩn thận: chính bạn. Bạn biết nên bấm nút nào, bạn nhập dữ liệu hợp lý, và nếu có lỗi bạn nhún vai rồi nhờ AI sửa. Production có nhiều người dùng bất cẩn, một số tò mò, và thỉnh thoảng có một kẻ thù địch. Code không cần trở thành "doanh nghiệp lớn"; nó cần xử lý được những tình huống mà prototype chưa bao giờ gặp.

Phần còn lại của hướng dẫn này đi qua từng dòng trong bảng.

Bước 1: Chốt phạm vi và ghi lại các luồng chính

Trước khi gia cố bất cứ thứ gì, hãy quyết định phiên bản đầu tiên là gì. Liệt kê ba đến sáu luồng quan trọng nhất — ví dụ "đăng ký, tạo dự án, mời một thành viên, thanh toán". Đây sẽ là kịch bản kiểm thử, các mục tiêu giám sát và những thứ bạn kiểm tra sau mỗi thay đổi.

Bất cứ thứ gì không có trong danh sách hoặc bị cắt bỏ, hoặc được ghi rõ là beta. Làm bốn luồng đáng tin cậy dễ hơn nhiều so với mười bốn luồng.

Bước 2: Kiểm thử như một người lạ, rồi làm cho nó lặp lại được

Các công cụ xây dựng bằng AI giỏi tạo ra code chạy đúng trên đường đi bình thường. Các vấn đề production nằm ở những đường đi không bình thường. Hãy kiểm tra mỗi luồng chính với:

• Đầu vào xấu: trường bắt buộc để trống, tên dài 5.000 ký tự, email không có @, số lượng âm, ngày trong quá khứ.
• Tải lại và nút quay lại: tải lại giữa chừng khi thanh toán; nhấn quay lại sau khi gửi form. Có cái gì bị tạo hai lần không?
• Hai tab, hai người dùng: đăng nhập bằng hai tài khoản khác nhau và thử mở trang của nhau bằng cách đổi ID trên URL.
• Chậm và nhỏ: màn hình cỡ điện thoại và kết nối mạng bị giới hạn (công cụ dev của trình duyệt có thể mô phỏng).
• Trạng thái trống: một tài khoản mới chưa có dữ liệu. Prototype thường được xây với dữ liệu mẫu nên trông hỏng khi không có dữ liệu.

Sau đó, làm cho việc kiểm tra này lặp lại được. Tối thiểu, hãy giữ một danh sách kiểm tra bằng văn bản và chạy trước mỗi lần phát hành. Tốt hơn, hãy nhờ AI viết kiểm thử tự động end-to-end cho những luồng quan trọng nhất:

Thêm kiểm thử end-to-end tự động cho các luồng sau: đăng ký bằng email, tạo dự án, mời người dùng thứ hai, và hoàn tất thanh toán trong chế độ test của Stripe. Cũng thêm kiểm thử xác nhận một người dùng không thể xem hoặc sửa dự án của người khác bằng cách đổi URL.

Những kiểm thử chứng minh một người dùng không thể làm điều gì đó là loại kiểm thử mà prototype thường thiếu nhất.

Bước 3: Những điều cơ bản về bảo mật mà prototype hay bỏ qua

Hầu hết các lỗ hổng bảo mật trong app do AI xây dựng không phải là thứ kỳ lạ. Chúng là những kiểm tra bị thiếu. Hãy đi qua danh sách này, và xem danh sách kiểm tra bảo mật đầy đủ cho app do AI xây dựng:

• Phân quyền ở phía máy chủ. Ẩn một nút không phải là bảo mật. Mọi yêu cầu đọc hoặc thay đổi dữ liệu phải kiểm tra trên máy chủ rằng người dùng đã đăng nhập được phép làm điều đó. Nếu app của bạn dùng cơ sở dữ liệu có quy tắc theo từng hàng, hãy kiểm tra chúng đã được bật và được kiểm thử.
• Đưa khóa bí mật ra khỏi trình duyệt. Khóa API cho thanh toán, email hoặc nhà cung cấp AI phải nằm trong biến môi trường phía máy chủ, không bao giờ trong code phía giao diện. Nếu bạn không chắc điều đó nghĩa là gì, hãy đọc biến môi trường và bí mật là gì.
• Xác thực ở phía máy chủ. Trình duyệt có thể bị bỏ qua, nên hãy lặp lại mọi kiểm tra quan trọng trên máy chủ.
• Đăng nhập được làm đúng cách. Dùng thư viện hoặc dịch vụ xác thực đã được kiểm nghiệm kỹ thay vì tự lưu mật khẩu. Hướng dẫn thêm đăng nhập vào app trình bày các lựa chọn.
• Giới hạn tần suất cho đăng nhập, đăng ký, đặt lại mật khẩu và mọi thứ gửi email hoặc gọi API trả phí.
• Thông báo lỗi thân thiện. Người dùng chỉ thấy "đã xảy ra lỗi"; chi tiết được ghi vào log của bạn, không hiển thị trên màn hình.
• Thay khóa đã bị rò rỉ. Nếu một khóa thật từng bị dán vào chat, commit hoặc ảnh chụp màn hình, hãy thay nó ở nhà cung cấp.

Một prompt bao quát nhiều phần cùng lúc:

Kiểm tra app này về bảo mật cho môi trường production. Xác nhận mọi API route đều kiểm tra người dùng đã đăng nhập sở hữu bản ghi mà nó đọc hoặc thay đổi, không có khóa bí mật nào được gửi đến trình duyệt, đầu vào được xác thực trên máy chủ, và đăng nhập cùng đặt lại mật khẩu có giới hạn tần suất. Liệt kê những gì bạn tìm thấy trước khi thay đổi bất cứ thứ gì.

Yêu cầu một danh sách trước giúp bạn thấy các vấn đề và quyết định thứ tự xử lý, thay vì nhận về một thay đổi khổng lồ.

Bước 4: Biết khi nào app bị lỗi — ghi log và giám sát

Trong bản xem trước, bạn thấy lỗi ngay khi chúng xảy ra. Ở production, bạn cần app tự báo cho bạn. Có ba lớp, từ rẻ nhất đến hữu ích nhất:

1. Log phía máy chủ. Đảm bảo lỗi được ghi lại với đủ ngữ cảnh để tái hiện: route nào, ID người dùng nào (không phải mật khẩu hay số thẻ), hình dạng đầu vào ra sao. Nhờ AI thêm ghi log có cấu trúc nếu app chỉ in ra console.
2. Theo dõi lỗi. Một dịch vụ như Sentry hoặc công cụ tương tự thu nhận các ngoại lệ phía giao diện và phía máy chủ, nhóm lại và gửi email cho bạn. Với app nhỏ, gói miễn phí của các dịch vụ này thường là đủ; hãy kiểm tra giới hạn hiện tại trên trang của họ.
3. Kiểm tra uptime. Một dịch vụ bên ngoài tải trang chủ và một API route quan trọng vài phút một lần, và cảnh báo bạn nếu chúng lỗi. Điều này bắt được những vấn đề khiến app không ghi log được nữa.

Thêm một thói quen nữa: sau mỗi lần phát hành, hãy mở app đang chạy thật và thực hiện danh sách kiểm tra luồng chính trên URL thật, không chỉ trên bản xem trước.

Bước 5: Sao lưu và đường lui

Hai thứ khác nhau cần được bảo vệ, và chúng dễ bị nhầm lẫn.

• Code. Giữ dự án trong hệ thống quản lý phiên bản để mọi thay đổi có thể hoàn tác. Nhiều công cụ xây dựng bằng AI lưu checkpoint các file của bạn; đồng bộ với một kho Git sẽ cho bạn một bản sao nằm ngoài công cụ xây dựng.
• Dữ liệu. Khôi phục code không khôi phục cơ sở dữ liệu. Một migration lỗi hoặc một nút xóa có bug có thể phá hủy các hàng mà không checkpoint code nào mang lại được.

Với dữ liệu, hãy thiết lập sao lưu định kỳ được lưu ở nơi khác ngoài hosting của chính app — với cơ sở dữ liệu Postgres, cách phổ biến là pg_dump theo lịch vào bộ nhớ riêng biệt, và nhiều nhà cung cấp cơ sở dữ liệu được quản lý còn cung cấp sao lưu tự động hoặc khôi phục theo thời điểm. Sau đó, hãy làm bước mà hầu hết mọi người bỏ qua: khôi phục một bản sao lưu vào cơ sở dữ liệu thử nghiệm và kiểm tra dữ liệu có đầy đủ không.

Cũng nhờ AI làm an toàn hơn các thao tác phá hủy: một bước xác nhận khi xóa, và "xóa mềm" (đánh dấu hàng là đã xóa thay vì loại bỏ hẳn) cho những gì người dùng có thể muốn lấy lại.

Bước 6: Hiệu năng đủ tốt trên điện thoại

Prototype chạy nhanh vì bạn là người dùng duy nhất và tập dữ liệu rất nhỏ. Trước khi ra mắt:

• Nạp dữ liệu có kích thước thật. Nhờ AI tạo vài nghìn hàng dữ liệu mẫu và xem trang nào chậm. Danh sách thường cần phân trang, và cơ sở dữ liệu thường cần chỉ mục cho các cột bạn lọc và sắp xếp.
• Thu nhỏ ảnh. Ảnh quá lớn là nguyên nhân phổ biến nhất khiến trang tải chậm. Hãy yêu cầu ảnh được thay kích thước, nén và tải lười (lazy loading) cho phần nằm dưới màn hình.
• Đo lường. Chạy Lighthouse trong công cụ dev của Chrome trên URL thật ở chế độ di động. Các chỉ số Core Web Vitals của Google là mục tiêu hợp lý: Largest Contentful Paint dưới 2,5 giây, Interaction to Next Paint từ 200 ms trở xuống, và Cumulative Layout Shift từ 0,1 trở xuống.
• Theo dõi độ trễ "đánh thức". Hosting tự ngủ khi không dùng giúp tiết kiệm tiền nhưng khiến lần truy cập đầu tiên sau một thời gian vắng chậm hơn. Với app mới, đó thường là sự đánh đổi chấp nhận được; chỉ cần biết là nó đang xảy ra.

Trang danh sách dự án chậm khi có 5.000 hàng. Thêm phân trang phía máy chủ (25 mục mỗi trang), thêm chỉ mục cơ sở dữ liệu cho các cột lọc và sắp xếp, và hiển thị trạng thái đang tải khi trang kế tiếp đang nạp.

Bước 7: Những việc vận hành cơ bản

Một vài việc nhỏ phân biệt một app thử nghiệm với một app mà người ta tin dùng:

• Tên miền riêng với HTTPS. Xem cách kết nối tên miền riêng.
• Email giao dịch từ một tên miền đã được xác minh cho xác nhận đăng ký và đặt lại mật khẩu — được trình bày trong cách gửi email từ app.
• Chính sách bảo mật và điều khoản mô tả đúng những gì bạn thực sự thu thập. Đừng sao chép những cam kết tuân thủ mà bạn chưa đạt được.
• Một kênh hỗ trợ — ngay cả một địa chỉ email được theo dõi.
• Khóa kiểm thử và khóa thật tách biệt cho thanh toán và email, cùng một ghi chú rõ ràng về môi trường nào dùng khóa nào.

Bước 8: Bàn giao gọn gàng

Sớm muộn gì cũng sẽ có người khác làm việc với app: một freelancer, một đồng sáng lập mới, hoặc chính bạn sau sáu tháng. Hãy làm cho việc đó dễ dàng:

• Một README giải thích cách chạy app, các biến môi trường cần thiết (chỉ tên và mục đích, không bao giờ ghi giá trị), và cách triển khai.
• Danh sách kiểm tra luồng chính và các kiểm thử tự động.
• Một ghi chú kiến trúc ngắn: front end, back end, cơ sở dữ liệu, các dịch vụ bên thứ ba, và nơi mỗi thứ được lưu trữ.
• Danh sách quyền truy cập: ai có quyền admin trên tên miền, hosting, cơ sở dữ liệu, tài khoản thanh toán và email. Đặt các tài khoản này dưới email doanh nghiệp, không phải email cá nhân.
• Code trong Git, tốt nhất được đồng bộ với một kho lưu trữ mà bạn sở hữu. Nếu có thể bạn sẽ chuyển hosting sau này, hãy đọc cách xuất và tự lưu trữ app do AI xây dựng.

AI có thể soạn phần lớn những thứ này cho bạn:

Viết README cho dự án này cho một lập trình viên chưa từng thấy nó: app làm gì, tech stack, cách chạy cục bộ, mọi biến môi trường mà app đọc (chỉ tên và mục đích), cách cơ sở dữ liệu được tổ chức, và cách triển khai.

Danh sách kiểm tra sẵn sàng production

• Các luồng chính đã được ghi lại và kiểm thử, bao gồm "không thể truy cập dữ liệu của người khác"
• Phân quyền và xác thực ở phía máy chủ cho mọi route dữ liệu
• Không có khóa bí mật trong code phía giao diện; các khóa bị rò rỉ đã được thay
• Giới hạn tần suất cho xác thực và mọi thứ tốn tiền
• Theo dõi lỗi và cảnh báo uptime gửi đến một hộp thư bạn thực sự đọc
• Sao lưu cơ sở dữ liệu nằm ngoài hosting của app, với một lần khôi phục thử thành công
• Phân trang và chỉ mục đã được kiểm tra với dữ liệu thực tế
• Tên miền riêng, tên miền gửi email đã xác minh, chính sách bảo mật
• README và danh sách quyền truy cập cho người tiếp theo

Làm việc này với Mythex

Nếu bạn xây prototype trong Mythex, phần lớn các bước này là prompt trong cùng dự án. Gõ /test và Mythex sẽ thao tác trên bản xem trước trực tiếp như một người dùng và báo cáo các luồng bị lỗi — xem App Testing. Khóa bí mật được đưa vào phần secret của dự án thay vì chat; mỗi lượt agent thành công đều lưu một checkpoint file của bạn mà bạn có thể quay lại; và xuất bản sẽ cho bạn một URL trực tiếp, với hosting và cơ sở dữ liệu được trừ từ cùng một số dư tín dụng (giới hạn hosting giải thích cách app và cơ sở dữ liệu ngủ và thức dậy). Checkpoint chỉ bao gồm file, không bao gồm hàng trong cơ sở dữ liệu, nên bạn vẫn cần lên kế hoạch sao lưu dữ liệu. Với gói Pro, bạn có thể kết nối tên miền riêng và xuất code hoặc đồng bộ sang kho GitHub của riêng bạn để bàn giao.

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