Khi làm module web app, bạn nên xây phần nền tảng trước, rồi mới đến nghiệp vụ riêng: với app quản lý theo kiểu phòng ban, thứ tự khởi đầu là phòng ban, chức vụ, nhân viên, sau đó đến thông tin công ty, phân quyền và chi nhánh. Trong các module này, module nhân viên nên được làm chuẩn nhất để lấy làm mẫu nhân bản cho phần còn lại. Bài này tôi giải thích lại nội dung một video về vibe coding (làm web app bằng AI) và thêm góc nhìn khi áp dụng cho doanh nghiệp vừa và nhỏ ở Việt Nam.
Nguồn: video «Seri Vibe Coding: Nên xây module nào trước khi phát triển WebApp?» của kênh Nghiện AppSheet, xem tại youtube.com/watch?v=LiVpxJw_DO4.
Vì sao không nên làm thẳng chức năng nghiệp vụ?
Vì nếu bỏ qua phần nền, dự án sẽ khó mở rộng, phân quyền thiếu nhất quán và phải sửa lại nhiều chỗ khi hệ thống lớn hơn. Đây cũng là lời cảnh báo trong phần mô tả video.
Tôi gặp tình huống này khá thường xuyên: chủ doanh nghiệp muốn có ngay màn hình báo giá hoặc đơn hàng vì đó là việc đang đau đầu nhất. Làm xong mới nhớ ra cần biết «ai tạo đơn», «thuộc phòng nào», «ai được xem giá vốn». Lúc đó phải quay lại thêm bảng nhân viên, phòng ban, rồi sửa hàng loạt màn hình đã làm. Làm nền trước thì nghiệp vụ nào gắn vào cũng dùng chung một nguồn người dùng và quyền.
Có những loại app nào, và mỗi loại bắt đầu từ đâu?
Theo video có hai trường phái. Cách phân biệt đơn giản là nhìn app của bạn tổ chức người dùng theo «phòng ban – chức vụ» hay theo «vai trò».
| Loại app | Đặc điểm | Ví dụ | Nên bắt đầu từ |
|---|---|---|---|
| Dạng ERP (quản trị nội bộ) | Một hoặc nhiều chi nhánh; cấu trúc phòng ban, chức vụ, nhân viên | Công ty thương mại, văn phòng, xưởng có nhiều bộ phận | Phòng ban, chức vụ, nhân viên |
| App đặc thù theo vai trò | Mỗi nhóm người dùng có vai trò rõ rệt, quyền khác hẳn nhau | App nhà trọ: nhà đầu tư, chủ trọ, nhân viên hỗ trợ, nhân viên kỹ thuật, khách thuê, khách xem website | Bảng người dùng và vai trò |
Phần bên dưới tập trung vào dạng thứ nhất, đúng như video. Với app đặc thù, tôi hiểu tinh thần tương tự: chốt danh sách vai trò trước, vì mọi màn hình sau đó đều phải hỏi «vai trò nào được thấy cái này».
Thứ tự xây các module nền tảng là gì?
Thứ tự gợi ý: phòng ban, chức vụ, nhân viên; tiếp theo là thông tin công ty, phân quyền và chi nhánh (nếu có). Phần mô tả video còn liệt kê một chuỗi rộng hơn mà tôi tóm lại thành các bước sau:
- Đăng nhập và xác thực người dùng.
- Tài khoản và hồ sơ nhân sự (phòng ban, chức vụ, nhân viên).
- Vai trò và phân quyền chức năng.
- Cấu hình hệ thống và dữ liệu dùng chung (thông tin công ty, chi nhánh).
- Nhật ký hoạt động và lịch sử thay đổi.
- Hệ thống thông báo.
- Quản lý tệp và tài liệu.
- Dashboard và báo cáo tổng quan.
- Các module nghiệp vụ riêng của doanh nghiệp.
Mỗi module nền có «kiểu» khác nhau. Theo cách tác giả video phân tích: module phòng ban hay hiển thị dạng cây sơ đồ nên không đại diện được cho các module khác; module chức vụ đi theo module phòng ban; module thông tin công ty chỉ khai báo một lần. Vì vậy chúng không phù hợp để làm khuôn mẫu.
Vì sao module nhân viên nên làm chuẩn nhất?
Vì module nhân viên gần như gom đủ các thành phần giao diện mà một web app quản lý cần dùng. Làm chuẩn một lần thì các module sau chỉ việc nhân bản và chỉnh trường dữ liệu.
Theo video, module này có:
- Xem, thêm, sửa, xoá và thống kê số lượng nhân viên.
- Giao diện nhiều tab, trang chi tiết, và bảng cha – con (bảng quá dài thì tách thành bảng con chia theo tab).
- Các nút bấm, tính năng in, gửi email, các action (thao tác) và hình ảnh.
- Các kiểu trường dữ liệu: email, số điện thoại, tải một ảnh hoặc nhiều ảnh (ví dụ ảnh căn cước công dân, bảo hiểm).
- Module con như thông tin người thân, hồ sơ đính kèm, hợp đồng.
Ví dụ ứng dụng: một công ty phân phối khoảng vài chục người có kho và văn phòng. Nếu dựng module nhân viên đầy đủ (ảnh đại diện, tab hồ sơ, tab hợp đồng, nút in), thì module «Đề xuất mua hàng» hay «Phiếu giao hàng» sau này dùng lại đúng cách bố trí danh sách, form và chi tiết đó. Người dùng cũng quen một kiểu thao tác trên mọi màn hình. Đây là suy luận ứng dụng của tôi, không phải số liệu đo đạc.
Cần dặn AI những từ khoá nào khi dựng module?
Khi vibe coding, từ khoá trong câu lệnh quyết định AI làm chuẩn hay làm sót. Video gợi ý một bộ từ khoá mà bạn có thể đưa vào lệnh:
- Thư viện giao diện: tác giả khuyên dùng một thư viện UI có sẵn (nghe trong video giống shadcn/ui; bạn nên kiểm tra lại tên chính xác) thay vì để AI tự vẽ từng nút.
- Chuyên nghiệp: yêu cầu giao diện ở mức chuyên nghiệp.
- Data grid: bảng dữ liệu có thao tác hàng loạt, đẹp và chuẩn hơn bảng thường.
- Component: thành phần dùng chung theo chuẩn hệ thống, ví dụ ô chọn dạng xổ xuống có nút chọn tất cả, bỏ chọn; ảnh đại diện nếu không có ảnh thì lấy hai chữ viết tắt.
- Business foundation: nhiều component ghép thành một trang hoàn chỉnh, chẳng hạn List view (trang danh sách) có đủ thanh công cụ và chức năng. Theo video, AI thường làm sót nếu bạn không yêu cầu rõ.
- Chuẩn hoá, dễ bảo dưỡng, dễ mở rộng, dùng chung, clean code: chèn tự nhiên vào câu lệnh.
Một câu lệnh mẫu tôi hay viết (bạn tự chỉnh): «Xây module Nhân viên theo chuẩn business foundation: List view có toolbar, data grid, bộ lọc; trang chi tiết nhiều tab; dùng lại component dùng chung; code sạch, dễ mở rộng.»
Không biết tên từng phần giao diện thì làm sao ra lệnh?
Hãy chụp màn hình đúng chỗ cần sửa, khoanh tròn và hỏi thẳng AI: «Phần này tên gọi là gì và sửa giúp tôi lỗi này». Đây là mẹo của tác giả video với ChatGPT và Claude, và tôi thấy rất thực tế với người không làm kỹ thuật.
Một số thuật ngữ được nhắc trong video để bạn làm quen: breadcrumb (đường dẫn trang), hamburger (nút ba gạch mở menu), toolbar (thanh công cụ), notification icon và notification dropdown (chuông và danh sách thông báo), user icon, tab group (nhóm tab), icon only (nút chỉ có biểu tượng, không chữ), card summary, detail action, section (gồm section title, section body). Tác giả cũng nói tên gọi có thể chưa chuẩn tuyệt đối, nên đừng áp lực: dùng nhiều sẽ nhớ.
Nếu cần tra thêm thuật ngữ làm app, bạn xem từ điển thuật ngữ làm app.
Làm sao tính trước các trường hợp phát sinh?
Hãy tự hỏi «sau này thêm thì giao diện xử lý ra sao» ngay từ module mẫu, hoặc bảo AI tính toán thêm các trường hợp. Ví dụ trong video: nếu module nhân viên có nhiều tab hơn, thì trên điện thoại các tab nên chuyển thành dạng dropdown hay cuộn ngang?
Với doanh nghiệp Việt, nhân viên kho, sales thị trường thường dùng điện thoại là chính, nên câu hỏi này không thể để sau. Bạn có thể đọc thêm cách làm giao diện mobile cho web app khi vibe coding. Còn nếu muốn làm bộ khung dùng lại cho nhiều dự án, xem template web app chuẩn.
Module nào làm ngay, module nào bổ sung sau?
Theo ý trong phần mô tả video, nên làm ngay đăng nhập, nhân sự, phân quyền và cấu hình dùng chung vì mọi thứ khác dựa vào chúng. Các module còn lại có thể bổ sung dần. Tôi gợi ý cách chia như sau, mang tính kinh nghiệm cá nhân chứ không phải quy tắc cứng:
| Giai đoạn | Module | Lý do |
|---|---|---|
| Làm ngay | Đăng nhập, phòng ban, chức vụ, nhân viên, phân quyền, thông tin công ty | Mọi nghiệp vụ đều cần biết «ai» và «được làm gì» |
| Làm sớm | Nhật ký hoạt động, tệp tài liệu | Càng muộn càng khó truy vết dữ liệu cũ |
| Bổ sung sau | Thông báo, dashboard, module nghiệp vụ riêng | Cần có dữ liệu thật từ các module trước mới có gì để hiển thị |
Phần thông báo có nhiều điểm cần thiết kế riêng, bạn xem hệ thống thông báo cho web app.
Tóm tắt và bước tiếp theo
Ý chính: làm nền trước, nghiệp vụ sau; với app kiểu phòng ban thì bắt đầu từ phòng ban, chức vụ, nhân viên; lấy module nhân viên làm mẫu chuẩn; dùng bộ từ khoá (data grid, component, business foundation, chuẩn hoá) để AI không làm sót; chụp màn hình hỏi AI khi chưa biết tên thành phần.
Bạn có thể tự làm ngay theo ba bước:
- Liệt kê người dùng của bạn: theo phòng ban – chức vụ hay theo vai trò.
- Nhờ AI dựng module nhân viên đầy đủ (danh sách, chi tiết nhiều tab, upload ảnh, in) rồi kiểm tra kỹ trên cả máy tính và điện thoại.
- Nhân bản mẫu đó sang module đầu tiên của nghiệp vụ, ví dụ đơn hàng hoặc phiếu kho.
Nếu mới làm quen, bộ tài liệu vibe coding miễn phí là chỗ dễ bắt đầu.
Xem thêm
Câu hỏi thường gặp
›Nên làm module nào trước khi xây web app quản lý?
Nên làm các module nền tảng trước: đăng nhập, phòng ban, chức vụ, nhân viên, thông tin công ty và phân quyền. Sau đó mới làm module nghiệp vụ riêng như đơn hàng, kho, báo giá. Làm theo thứ tự này giúp tránh phải sửa lại nhiều khi hệ thống lớn lên.
›Vì sao nên lấy module nhân viên làm mẫu chuẩn?
Vì module nhân viên có gần đủ thành phần giao diện: danh sách, thêm sửa xoá, thống kê, nhiều tab, bảng cha con, nút in, gửi email và tải nhiều ảnh. Làm chuẩn một lần thì các module khác nhân bản lại và chỉ đổi trường dữ liệu.
›Business foundation và component trong vibe coding nghĩa là gì?
Component là thành phần giao diện dùng chung theo chuẩn hệ thống, ví dụ ô chọn xổ xuống hay ảnh đại diện. Business foundation là nhiều component ghép thành một trang hoàn chỉnh như List view có đủ thanh công cụ. Nhắc đúng hai từ khoá này giúp AI ít làm sót chức năng.
›Không biết tên các phần giao diện thì ra lệnh cho AI thế nào?
Chụp màn hình đúng phần cần sửa, khoanh tròn rồi nhờ AI cho biết tên gọi và sửa luôn lỗi đó. Làm vài lần bạn sẽ nhớ dần các thuật ngữ như breadcrumb, toolbar, tab group.
Tác giả
Chuyên gia chuyển đổi số · Đại diện 5F Edu
Hơn 8 năm triển khai và tư vấn chuyển đổi số cho doanh nghiệp vừa và nhỏ: chuẩn hoá quy trình, xây phần mềm quản lý bằng AppSheet và web app, tự động hoá bằng N8N. Người làm kênh YouTube Nghiện AppSheet.
