Chào các bạn, mình đã quay trở lại với "tập 2" của series Vibe-coding.
Ở bài trước, mình đã chia sẻ về lý do vì sao mình quyết định "đập đi xây lại" K-Hub từ WordPress sang Headless CMS. Hôm nay, mình sẽ bóc tách chi tiết hành trình "đấm nhau" với AI. Mình muốn khẳng định ngay từ đầu: Đây là quá trình một BA dùng AI để lập trình thực thụ, chứ không phải chỉ là gõ vài câu prompt dạo rồi ngồi đợi kết quả.
0. Purpose & Tech Stack: Khi kiến thức nền tảng là "la bàn"
Vì đã làm BA/BrSE được mấy năm, mình may mắn có kiến thức cơ bản về cấu trúc hệ thống: từ tầng UI/UX (Frontend), đến tầng Logic (Backend) và Data (Database).
Từng vận hành một "mối" Monolithic WordPress đủ lâu, mình có tiêu chuẩn rõ ràng để so sánh và biết chính xác mình mong muốn gì ở hệ thống mới. Với kinh nghiệm kinh qua nhiều domain, trong đó có CMS, mình hiểu nếu không dùng WordPress thì có những giải pháp nào thay thế.
Cuối cùng, mình chốt hạ kiến trúc Headless CMS như các bạn đã thấy:
• Backend: Dùng Laravel Filament (V3) để quản trị nội dung.
• Frontend: Dùng Next.js để tối ưu tốc độ và SEO.
• UI Design: Mình lên Figma "quẹo lựa" các component có sẵn của Filament và Front UI Kit để xào nấu lại cho đúng ý đồ cá nhân.
1. Reuse Portfolio: Tận dụng tài liệu cũ làm "nguyên liệu"
Trước đây mình đã mày mò làm Portfolio truyền thống, cũng cân nhắc lên xuống việc chọn domain nào để làm. Thay vì chọn những gì "đao to búa lớn" hay chỉ để làm đẹp CV, mình chọn làm một sản phẩm đáp ứng nhu cầu thật và mình có đủ vision để làm Product Owner.
Cụ thể là hồi học Thạc sĩ, mình từng là một blogger "viết bài dạo" kiếm tiền sống qua ngày, nên mình hiểu được của một người viết blog muốn có gì.
2. Hành trình làm sản phẩm thật: Từ Trigger đến thực tế khắc nghiệt
Làm Portfolio truyền thống xong một thời gian, tiền thuê Dev thì chưa có, mà "nhà nhà AI, người người AI". Trigger lớn nhất là khi thấy một người bạn không hề biết gì về tech mà vẫn tự "vibe-code" được trang web dạy tiếng Hàn. Điều đó thôi thúc mình: "Phải nâng cấp Portfolio lên một tầm cao mới!"
Giai đoạn 1: Thử nghiệm với Antigravity + Gemini Pro
Ban đầu, mình dùng Antigravity kết hợp Gemini Pro vì đã mua sẵn gói này để quản lý tài liệu học tập và email của 1st Korean BA trên Google.
• Kết quả: Dựng được cái khung và các màn hình UI khá nhanh.
• Vấn đề: Hệ thống chạy theo "ý của AI" là chính chứ chưa áp dụng được thiết kế riêng của mình vào. Mình thử dùng UI và ERD viết lại thành SRS (Software Requirement Specification) rồi cho chạy, nhưng vẫn thấy không ổn. Sau đó, mình bắt AI vẽ lại layout dựa trên UI Figma thì thấy kết quả bắt đầu khả quan hơn.
• Cái kết: Vì dùng các "Skill" (kỹ năng) vượt quá trình độ hiện tại, mình nhanh chóng rơi vào tình trạng... hết sạch token. Cảm giác nhức nhối vô cùng vì product vẫn chưa ra hình thù hoàn chỉnh, lúc này mình thấy cần một bạn Dev hơn bao giờ hết!
Giai đoạn 2: Đầu tư Claude Pro - Khi BA "trị" AI bằng quy trình
Sau khi hỏi han khắp nơi, mình quyết định "xuống tiền" mua Claude Pro. Ban đầu định chơi lớn gói Max 200$, nhưng may mắn được anh em Dev bảo kê: "Hệ thống đơn giản, 22$ là đủ dùng rồi".
Và đây là lúc mình chuyển từ giai đoạn dựng khung sang hoàn thiện từng module cả về UI lẫn Logic. Rút kinh nghiệm từ việc "lười" không làm tài liệu mô tả dẫn đến logic và biding (đổ dữ liệu) bị lởm, mình đã thay đổi chiến thuật:
• Không cho Auto-edit 100%: Để tiết kiệm token, mình tự tay làm file mẫu mô tả, viết flow chi tiết cho AI mapping lại rồi mới chạy.
• Dạy AI tự viết "Skill": Mình không dùng các Skill tràn lan trên mạng. Mình cho AI làm thử task nhỏ theo Guideline của mình, sau đó yêu cầu chính AI tự viết lại thành Skill và Flow chuẩn cho nó.
• Module hóa triệt để: Mỗi khi làm component hay module mới, mình yêu cầu AI tạo thành các file riêng biệt phù hợp với Business Module đó.
• Bảo trì Context: Làm xong task nào, mình bắt AI update ngay vào SRS gốc để đảm bảo ngữ cảnh xuyên suốt. Cuối mỗi ngày, mình yêu cầu nó ghi lại log toàn bộ những gì đã implement để đảm bảo "bộ nhớ dài hạn".
Lợi thế của một BA làm Owner: Các file Skill hay Flow mẫu thực chất là sự "số hóa" bản chất các tài liệu BA và quy trình verify kết quả mà mình vẫn làm thường ngày. Vì là Owner, mình đảm bảo được khâu gather requirement và biết chính xác logic nghiệp vụ mong muốn. Khi gặp những lỗi tech quá sâu mà AI không tự debug được, mình sẽ đi "hỏi quyền trợ giúp" từ các bạn Dev quen để lấy keyword cần thiết.
Giai đoạn 3: "Robot" cho AI khi Deploy
Làm xong chạy ngon dưới Local tưởng là xong, nhưng lúc lên Production mới thực sự là thử thách. Ở giai đoạn này, mình biến thành một con "robot" thực thụ: AI bảo gì cài nấy, AI gen lệnh gì thì mình copy-paste lệnh đó để chạy server.
Kết quả là hệ thống đã lên sóng như các bạn thấy! Tập tới mình sẽ kể về những lỗi "ối dồi ôi" của AI và hành trình đi thuê hosting, cấu hình server thực tế. Anh em chờ xem nhé!
