Vì sao công cụ tạo app bằng AI hiển thị dữ liệu giả trước (và vì sao đó là cách làm đúng)

Nếu công cụ tạo app bằng AI lấp đầy các màn hình của bạn bằng người dùng bịa ra và đơn hàng mẫu trước khi đụng đến cơ sở dữ liệu, thì đó không phải đường tắt — mà là cách xây đúng đắn. Đây là lý do.

Bạn mô tả một app cho công cụ tạo app bằng AI. Một phút sau, bạn đang nhìn vào một giao diện hoạt động được — các trang, các nút, một bảng người dùng với những cái tên kiểu như “Alex Rivera” và “Priya Shah”, những mức giá chẳng hợp lý, một “Gói Pro” mà bạn không hề yêu cầu. Chẳng có gì được lưu cả. Nếu bạn tải lại trang, dữ liệu vẫn còn đó. Nếu bạn thêm một người dùng mới, nó biến mất.

Trông như một trò ảo thuật sắp sửa sụp đổ. Không phải vậy đâu. Đó là phần hay của quá trình xây. Dữ liệu giả trên màn hình của bạn là một bước đầu tiên có chủ đích, và nó là lý do vì sao cơ sở dữ liệu đến tiếp sau sẽ thực sự khớp với app mà bạn muốn.

”Dữ liệu giả trước” thật ra nghĩa là gì

Khi một công cụ tạo app bằng AI nhận bản mô tả của bạn, nó không lao thẳng đến cơ sở dữ liệu. Một công cụ tốt sẽ viết các màn hình trước, lấp đầy chúng bằng dữ liệu giữ chỗ hợp lý, rồi — và chỉ khi đó — mới thiết kế cơ sở dữ liệu cho khớp.

Dữ liệu giữ chỗ không phải để trang trí. Nó là một bản giao kèo. Một khi app của bạn nói “mỗi đơn hàng có một tên khách hàng, ba dòng mục, một tổng tiền, và một trạng thái”, thì cơ sở dữ liệu được dựng tiếp theo phải có đúng những thứ đó, đúng hình hài đó. Các màn hình quyết định dữ liệu trông như thế nào, chứ không phải ngược lại.

Cách này ngược với cách một lập trình viên thường bắt đầu. Một lập trình viên truyền thống thiết kế cơ sở dữ liệu trước, rồi mới dựng các màn hình dựa trên nó. Các công cụ AI đã đảo ngược điều đó, và phần lớn mọi người không để ý — họ chỉ thấy mấy người dùng giả và cho rằng công cụ đang làm giả.

Vì sao thứ tự này hoạt động tốt hơn với AI

Chúng tôi đã thử xây cơ sở dữ liệu và các màn hình cùng một lúc. Nó không hiệu quả. Đây là phiên bản ngắn gọn của lý do.

Khi hai tác nhân AI làm những phần khác nhau của một app mà không thấy được đầu ra của nhau, chúng đưa ra những phỏng đoán không tương thích. Tác nhân lo giao diện quyết định người dùng có một trường “name”. Tác nhân lo cơ sở dữ liệu quyết định người dùng có một trường “fullName”. Cả hai đều trông đúng. Ghép lại, chẳng cái gì chạy được. Một tác nhân thứ ba được kéo vào để vá chỗ vênh. Nó cũng phỏng đoán. Giờ có ba phỏng đoán đang lang thang, và cái app bạn xem trước là một thứ Frankenstein chắp ghép từ cả ba.

Cách sửa gần như đáng xấu hổ: làm xong một thứ trước, rồi mới làm thứ kia. Giao diện được xây xong. Nó ghi lại dữ liệu mà nó cần dưới dạng một tệp duy nhất gồm người dùng giả, đơn hàng giả, hay bất-cứ-thứ-gì-app-của-bạn-xoay-quanh giả. Tác nhân cơ sở dữ liệu đọc tệp đó và khớp từng trường một. Không phỏng đoán. Không thương lượng. Không vênh.

Đó là lý do công cụ tạo app bằng AI có thể cho bạn xem một app trông như đã hoàn thiện chỉ trong một phút. Nó không làm giả quá trình xây. Nó đã làm xong một phần tư công việc — phần quyết định mọi thứ khác — và cơ sở dữ liệu là phần việc của mười giây tiếp theo, chứ không phải mười giờ tiếp theo.

Cần để ý gì khi dữ liệu giả hiện trên màn hình

Đây là khoảnh khắc mà phần lớn mọi người lướt qua. Họ thấy dữ liệu giữ chỗ và bắt đầu đòi đổi màu. Nhưng dữ liệu giữ chỗ là một câu hỏi đang được đặt ra cho bạn. Hãy đọc nó.

Vài ví dụ về những thứ cần để mắt:

  • Từ ngữ sai. App bạn muốn theo dõi “lô hàng” (shipments). Dữ liệu giữ chỗ lại gọi chúng là “đơn hàng” (orders). Hãy báo cho công cụ. Nếu bây giờ bạn để cho qua, thì mọi màn hình, mọi trường cơ sở dữ liệu, mọi báo cáo sẽ dùng sai từ — và việc đổi tên sau này không phải thao tác một-cú-nhấp trong bất kỳ công cụ nào, dù quảng cáo có nói gì đi nữa.
  • Thiếu trường. Hóa đơn giả có một tổng tiền và một ngày. Bạn còn cần một số PO nữa. Thêm nó ngay bây giờ, khi đang có năm hóa đơn mẫu trên màn hình, sẽ tốt hơn là sau khi cơ sở dữ liệu đã được dựng và đổ đầy dữ liệu khách hàng thật.
  • Hình hài sai. Dữ liệu giả thể hiện “1 khách hàng, 1 địa chỉ”. Khách hàng thực tế của bạn có nhiều địa chỉ. Công cụ không thể suy ra điều đó từ bản mô tả của bạn. Hãy báo cho nó ngay bây giờ, khi việc thay đổi hình hài chẳng tốn gì cả.
  • Những thực thể bất ngờ. Công cụ tự bịa ra một khái niệm “nhóm” mà bạn không hề yêu cầu, vì nó cho rằng đây là app nhiều người dùng. Có thể bạn muốn nó. Có thể không. Dù sao đi nữa, hãy quyết định trước khi cơ sở dữ liệu được dựng xoay quanh nó.

Một quy tắc hữu ích: nếu app của bạn có một danh từ nào đó mà không được thể hiện trong dữ liệu giữ chỗ trên màn hình, thì công cụ vẫn chưa biết về nó. Hãy nhắc đến nó trước khi bạn nhấp “lưu” ở lần xem trước đầu tiên.

Vì sao thứ tự quan trọng cho những gì đến tiếp theo

Một khi dữ liệu giữ chỗ đã đúng, việc dựng cơ sở dữ liệu chỉ còn là máy móc. Công cụ đọc dữ liệu giả của bạn, tạo ra một lược đồ khớp với nó, viết các truy vấn mà các màn hình vốn đã đang cố gọi, và cuối cùng thay các import giữ chỗ bằng những import thật. Chính những màn hình từng hiển thị người dùng giả giờ hiển thị bất cứ thứ gì bạn thực sự nhập vào.

Bạn thường có thể thấy sự hoán đổi này diễn ra theo thời gian thực. Một trang vốn tải tức thì vì nó đang đọc một tệp cục bộ giờ có một trạng thái đang tải kéo dài nửa giây — đó là lúc màn hình trò chuyện với một cơ sở dữ liệu thật lần đầu tiên. Phần lớn mọi người bỏ lỡ điều này và không nhận ra app vừa vượt qua lằn ranh từ “bản demo” sang “thứ có thể lưu trữ dữ liệu thật”.

Lý do cách này hoạt động được là vì mọi thứ ở phía sau — thiết kế cơ sở dữ liệu, các truy vấn, các trạng thái đang tải, các trạng thái trống — đều đã được quyết định bởi những gì bạn thấy trên màn hình trong giai đoạn giữ chỗ. Nếu bạn duyệt ba cột, bạn sẽ có ba cột. Nếu bạn duyệt một trường “status” với các giá trị “draft” và “sent”, thì đó chính xác là thứ cơ sở dữ liệu chấp nhận. Không có bước dịch lần thứ hai nào nơi một sự bàn giao giữa nhà thiết kế và lập trình viên làm mọi thứ méo mó đi.

Một thử nghiệm nhỏ bạn có thể làm

Lần tới khi bạn xây một thứ gì đó, hãy thử điều này: khi dữ liệu giữ chỗ xuất hiện, hãy thay đổi một thứ về nó trước khi yêu cầu bất cứ điều gì khác. Đổi tên một trường. Thêm một cột. Thay “users” bằng “members”. Rồi xem điều gì xảy ra khi cơ sở dữ liệu được dựng.

Bạn sẽ thấy thay đổi đó hiện ra ở khắp nơi — trong thiết kế cơ sở dữ liệu, trong các truy vấn, trong dữ liệu mồi mà công cụ đặt vào khi app hoàn thành. Một từ ở giai đoạn giữ chỗ đã lan tỏa khắp cả app. Đó là đòn bẩy bạn có trong giai đoạn này, và đó là lý do “dữ liệu giả trước” không phải là một mẹo cắt xén công sức. Đó là nơi app thật sự được định đoạt.

Nếu bạn muốn đi sâu hơn, bài viết gần đây của chúng tôi về thực sự có gì bên trong một app xây bằng AI sẽ đưa bạn đi qua những bộ phận chuyển động khác mà bạn không thấy ngay từ cái nhìn đầu tiên. Mô-típ vẫn vậy: phần lớn đòn bẩy nằm ở những phần trông như chẳng quan trọng.