0

Từ 1 ảnh sản phẩm đến nhiều visual bán hàng: cách mình xây một workflow AI cho ecommerce bằng Next.js

Từ 1 ảnh sản phẩm đến nhiều visual bán hàng: cách mình xây một workflow AI cho ecommerce bằng Next.js

Một vấn đề mình thấy lặp đi lặp lại ở nhiều shop online là:

Họ không thiếu nhu cầu làm nội dung hình ảnh. Họ thiếu một workflow đủ nhẹ để tạo ra nhiều visual bán hàng từ một đầu vào đơn giản.

Một sản phẩm khi bán online thường không chỉ cần 1 tấm ảnh. Người bán có thể cần:

  • ảnh nền trắng cho listing
  • ảnh lifestyle cho social
  • ảnh banner cho landing page
  • ảnh quảng cáo để test nhiều thông điệp
  • thậm chí là video ngắn từ ảnh tĩnh

Nếu mỗi nhu cầu lại phải quay về quy trình chụp, sửa, cắt, thay nền, đổi format từ đầu thì chi phí thời gian rất lớn.

Từ bài toán đó, mình thử xây một workflow AI nhỏ cho ecommerce bằng Next.js, với mục tiêu rất thực tế: đi từ một ảnh sản phẩm hoặc một brief ngắn sang nhiều đầu ra hình ảnh có thể dùng để bán hàng.

Bài viết này không bàn về “AI có thay thế tất cả không”. Mình chỉ chia sẻ cách mình nhìn bài toán, cách tổ chức workflow, và vài bài học kỹ thuật sau khi triển khai.

  1. Bài toán thực sự không phải là tạo 1 ảnh đẹp

Nếu chỉ nhìn bề mặt, ai cũng nghĩ bài toán là: “làm sao để AI tạo ra một ảnh đẹp”.

Nhưng khi làm cho ecommerce, mình thấy bài toán thật ra là: “làm sao để từ một đầu vào đơn giản, người bán có thể tạo ra nhiều phiên bản hình ảnh phù hợp với nhiều mục đích khác nhau”.

Tức là hệ thống không nên tối ưu cho một lần tạo ảnh duy nhất. Nó nên tối ưu cho:

  • tốc độ thử nghiệm
  • khả năng tạo biến thể
  • khả năng tái sử dụng input
  • và khả năng chuyển từ ảnh sang asset phục vụ bán hàng

Khi nhìn như vậy, kiến trúc sản phẩm cũng thay đổi.

  1. Workflow mình chọn

Workflow mình đi theo khá đơn giản:

Bước 1: Người dùng đưa vào một trong hai thứ:

  • ảnh sản phẩm
  • hoặc prompt/brief ngắn

Bước 2: Người dùng chọn loại asset muốn tạo:

  • listing image
  • product scene
  • ad creative
  • social post
  • banner
  • image-to-video

Bước 3: Hệ thống chuẩn hóa input trước khi gửi sang model:

  • prompt được làm rõ hơn
  • style được map lại
  • ratio được chuẩn hóa
  • một số loại input được ràng buộc theo use case

Bước 4: Gọi model AI để tạo output

Bước 5: Lưu lại generation task, output, credit usage và trạng thái để người dùng có thể quay lại chỉnh tiếp

Mấu chốt ở đây là: thay vì để người dùng bắt đầu từ một ô prompt trống hoàn toàn, mình đẩy sản phẩm về hướng “task-oriented”. Người dùng chọn mục tiêu bán hàng trước, rồi mới tạo ảnh.

Với ecommerce, cách đó hợp lý hơn nhiều.

  1. Vì sao mình chọn Next.js cho lớp ứng dụng

Ở lớp ứng dụng, Next.js khá hợp với kiểu sản phẩm này vì vài lý do:

  • render tốt cho landing page và SEO page
  • làm route cho app và API khá gọn
  • dễ chia phần public page và authenticated workspace
  • hợp với kiểu sản phẩm vừa có content page vừa có tool page

Một điểm mình thấy quan trọng là: sản phẩm AI nếu muốn có tăng trưởng từ search thì phần landing page, generator page, prompt page, FAQ page cần được tổ chức khá rõ.

Nếu chỉ làm một app thuần dashboard thì rất khó mở rộng organic traffic.

Vì vậy mình không xem phần web chỉ là “vỏ bọc cho API”. Mình xem nó là một phần của distribution.

  1. Cách mình tách phần workflow khỏi phần giao diện

Một lỗi dễ gặp khi build tool AI là nhét hết logic vào UI.

Lúc đầu việc đó có vẻ nhanh. Nhưng sau một thời gian, UI sẽ mang luôn:

  • business rule
  • model mapping
  • credit rule
  • prompt optimization
  • generation state
  • error mapping

Khi đó sửa rất mệt.

Cách mình thấy ổn hơn là tách rõ:

UI layer:

  • form nhập prompt
  • upload ảnh
  • chọn style / ratio / model
  • xem kết quả

Workflow layer:

  • validate request
  • chuẩn hóa model
  • dựng provider prompt
  • quyết định có được dùng model đó không
  • tính credit
  • xử lý trạng thái task

Persistence layer:

  • lưu task
  • lưu output
  • lưu usage
  • lưu billing / quota

Khi tách như vậy, việc thêm một use case mới như image-to-video hoặc free daily slot sẽ ít phá code cũ hơn.

  1. Một điểm khó: cùng là “generate”, nhưng luật không giống nhau

Khi bắt đầu build, mình từng nghĩ image generation và video generation có thể đi chung một kiểu flow.

Thực tế thì không hẳn.

Ví dụ:

  • image có thể trả kết quả khá nhanh
  • video có thể chạy bất đồng bộ
  • có model cần credit
  • có model lại nên đi theo quota miễn phí theo ngày
  • có request trả output ngay
  • có request chỉ trả task id để poll tiếp

Điều đó có nghĩa là “generate” chỉ là tên gọi chung. Bên dưới, mỗi loại task cần một contract khá rõ.

Một cách mình thấy hữu ích là: đừng cố ép tất cả model vào một shape quá đẹp ngay từ đầu.

Thay vào đó:

  • thống nhất phần request nội bộ
  • nhưng chấp nhận response flow khác nhau theo loại task
  • và dùng task token / task id để nối tiếp các bước bất đồng bộ

Làm như vậy thực tế hơn nhiều.

  1. Prompt không phải thứ duy nhất quyết định chất lượng

Một hiểu nhầm phổ biến là: muốn output tốt thì chỉ cần prompt tốt.

Sau khi làm một thời gian, mình thấy chất lượng đầu ra phụ thuộc vào ít nhất 4 thứ:

  • chất lượng input image
  • use case người dùng đang làm
  • model được chọn
  • cách mình ép người dùng đi theo workflow nào

Ví dụ cùng là sản phẩm skincare: nếu người dùng chọn “listing image” thì prompt nên sạch, trung tính, ít nhiễu. Nhưng nếu chọn “ad creative” thì prompt nên nhấn vào mood, context, selling angle.

Tức là prompt tốt không phải prompt dài hơn. Prompt tốt là prompt đúng với mục tiêu tạo asset.

Đó cũng là lý do mình thích cách tiếp cận theo use case hơn là để người dùng tự bơi hoàn toàn.

  1. Storage và task history quan trọng hơn mình nghĩ

Ban đầu mình chỉ tập trung vào generate output. Nhưng sau đó mình nhận ra: nếu người dùng không xem lại được lịch sử, không biết mình đã dùng prompt nào, model nào, ratio nào, thì trải nghiệm sẽ rất rời rạc.

Vì vậy phần storage và task history trở nên quan trọng:

  • lưu original prompt
  • lưu optimized prompt
  • lưu model
  • lưu ratio
  • lưu output url
  • lưu credits used
  • lưu status
  • lưu created_at

Nghe có vẻ cơ bản, nhưng đây là nền để sau này làm:

  • regenerate
  • refine
  • compare output
  • analytics
  • billing
  • support debugging

Nói ngắn gọn: AI output chỉ là một phần. Task record mới là thứ giúp sản phẩm dùng được lâu hơn.

  1. Điều mình học được sau khi làm workflow này

Có 3 điều mình thấy đáng giá nhất.

Thứ nhất: đừng build AI tool như một “máy prompt”. Người dùng không thực sự muốn viết prompt. Họ muốn ra được asset đúng mục tiêu bán hàng.

Thứ hai: workflow quan trọng hơn việc nhồi thật nhiều model. Nếu flow không rõ, nhiều model hơn cũng chỉ làm người dùng rối hơn.

Thứ ba: với ecommerce, giá trị lớn không nằm ở một ảnh đẹp duy nhất. Giá trị nằm ở việc tạo ra nhiều phiên bản đủ nhanh để test.

Và khi nhìn sản phẩm theo hướng đó, rất nhiều quyết định kỹ thuật sẽ sáng tỏ hơn:

  • nên tách task như thế nào
  • nên lưu dữ liệu gì
  • nên thiết kế form ra sao
  • nên tối ưu cho page nào
  • nên để free quota ở đâu

Kết luận

Nếu build một AI tool cho ecommerce, mình nghĩ câu hỏi tốt không phải là: “làm sao để model tạo ảnh đẹp hơn một chút?”

Mà là: “làm sao để người bán đi từ input đơn giản đến nhiều asset bán hàng nhanh hơn?”

Khi đổi câu hỏi, mình thấy kiến trúc ứng dụng, UX và cả business rule đều trở nên rõ ràng hơn.

Đó cũng là hướng mình đang thấy hợp lý nhất: AI không chỉ là lớp generate. AI nên là một workflow giúp rút ngắn vòng thử nghiệm nội dung cho người bán online.

Nguồn tham khảo: https://aurivis.ai/vi


All Rights Reserved

Viblo
Let's register a Viblo Account to get more interesting posts.